Re: [9fans] 9pcf debugging

["Lluís Batlle" <viriketo@gmail.com>]

Thank you all...
In fact I managed to get the ethernet driver working at the first code
change I tried today!
This means that by now I won't try to debug the kernel, but I really
like to have known of these kernel debugging techniques.

Btw, I had problems with the Rhine ethernet driver. I got much help
from #plan9... the driver wanted to align some structures to the cache
line size. The driver read the cls from the pci configuration space,
and my card had that register *bad* (0x04 instead of 0x08, for the x86
architecture I use).
As the driver allocates several Ds structures with a big malloc, and
dividing the allocated area to (p+=cls) parts, each for each Ds
structure, the driver required that cls >= sizeof Ds. That wasn't met
in my system, and the driver decided not to load.
I simply set manually the alignement to 32 bytes (0x08 dwords,
according to pci cls terminology), and it worked well for several
minutes, until I had to turn off the system.

Yesterday I tried aligning to 64 bytes, which I thought should work,
but it only worked for some tens of packets, and then the card
'hanged'. I cannot describe that hang better than the simple user
experience of no network packet receiving any answer, since some pings
worked and I could mount sources.

That's all. Poor helpful people in #9fans already know this. :)

2008/2/4, erik quanstrom <quanstro@coraid.com>:
> > I've seen there is rdbfs for debugging the 9pc kernel through a serial port...
> >
> > The computer the driver fails on doesn't have a serial port. I'd like
> > to the debug the ethernet driver, so I don't have ethernet. :)
> >
> > Any ideas, over the common lot-of-print() ?
> >
> > Thanks in advance.
>
> yes.  we have a small embedded kernel with no user space. since
> it's hard to find serial these days, serial didn't seem like the best
> solution.  so we export the segments, stack and memory as aoe
> targets.  this won't help in the very early phases of boot, and
> requires a working ethernet driver.  but our example is about
> 250 lines of code.  with aoedbfs (/n/sources/contrib/quanstro/src/aoedbfs)
> acid or db can be used to debug the target with acid or db.
>
> with the plan 9 kernel, i think the right solution would be to
> put the aoe debugger in 9load.  this would require the plan 9
> kernel leaving  9load in core (wasting 8 mb or so) and having
> a mechanism for passing control back to 9load. this mechanism
> could replace doublefault() and be inserted into debugbpt
> and (on the 386) fault386.
>
> - erik
>
> p.s. there's also a program called aoesnap in
> /n/sources/contrib/quanstro/src that will take a snapshot
> of a process exporting debugging via aoe.  there may be some
> assumptions that are unique to our situation and the code is
> somewhat convoluted due to the fact that we typically snapshot
> processes using gigabytes of memory, so the image needs to be
> streamed out rather than processed in a serial manner like
> snap.  it also contains compatability goo so it compiles on
> linux.
>