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 <[EMAIL PROTECTED]>: > > 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. >
