Re: [9fans] 9pcf debugging
- From: viriketo@xxxxxxxxx (Lluís Batlle)
- Date: Mon, 4 Feb 2008 20:12:07 GMT
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@xxxxxxxxxx>:
.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.
- References:
- Re: [9fans] 9pcf debugging
- From: erik quanstrom
- Re: [9fans] 9pcf debugging
- Prev by Date: Re: [9fans] A newbie question...
- Next by Date: Re: [9fans] drawterm crash log
- Previous by thread: Re: [9fans] 9pcf debugging
- Next by thread: Re: [9fans] 9pcf debugging
- Index(es):
Relevant Pages
|
