[9fans] 9pcf debugging - Plan9

This is a discussion on [9fans] 9pcf debugging - Plan9 ; 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, ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: [9fans] 9pcf debugging

  1. [9fans] 9pcf debugging

    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.

  2. Re: [9fans] 9pcf debugging

    > 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.

  3. Re: [9fans] 9pcf debugging

    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 :
    > > 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.
    >


  4. Re: [9fans] 9pcf debugging

    ron minnich wrote:
    ....
    >
    > Ah, USB. 24+ chapters and not a single good idea :-)
    > [ok, maybe one: powered cables are nice]

    ....

    This should be a fortune (with or without the second line...

    Martin

  5. Re: [9fans] 9pcf debugging

    LluĂ*s Batlle wrote:

    >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.
    >
    >

    My VIA C7 based machine has the same problem:

    0.18.0: net 02.00.00 1106/3065 10 0:0000f001 256 1:fdffe000 256
    VIA Technology VT6102 Rhine II PCI Fast Ethernet Controller

    so i could help you testing that thing :-)


    cinap

+ Reply to Thread