Re: [9fans] Missing interrupts in 9pxeload?

[Dan Cross <crossd@gmail.com>]

On Fri, Jun 5, 2009 at 2:28 PM, erik quanstrom<quanstro@quanstro.net> wrote:
>> I am attempting to PXE boot it from my file/auth/boot/cpu server (the
>> aforementioned machine that is having some problems).  The machine
>> DHCP's fine, and will load 9pxeload via TFTP, but then hangs.  I
>> started playing around with 9pxeload to see what was going on,
>> including updating the driver in /sys/src/boot/pc using Erik's latest
>> from his directory on sources, but still no go.  I finally traced
>> through the code far enough to see that it is getting stuck in the
>> wait() routine in ether.c; that is defined in l.s, and just calls

(Argh; it looks like I cut a line out of my original message.  Mea
culpa; the function I referred to in l.s is the idle() routine).

>> 'HLT' and 'RET'.  Ie, do nothing until you receipt of an interrupt and
>> return.  However, no interrupts ever arrive; modifying wait() to
>> comment out the call to idle() and then printing m->ticks every
>> million or so iterations through the loop shows that m->ticks doesn't
>> change.  It's as if all interrupts somehow got turned off prior to the
>> call to wait().  Has anyone else seen this?  Could there be something
>> somewhere that's disabling interrupts that I should look into?  Could
>> things be being routed weirdly on an Atom processor?
>
> how are you verifying that this machine isn't getting any
> interrupts?  the wait loop will loop if an interrupt is rx'd
> unless ring->owner != owner or it times out.

I verified by modifying wait() and performing several experiments.
For instance, manually inspecting (via a print() statement) the value
of, e.g., m->ticks and noting that it doesn't change.  Since it is
incremented in clockintr(), I'd expect it to if the machine was
servicing clock interrupts, but it stays as either '2' or '3'
depending on what else happens on the machine before it gets into
wait() (e.g., what debugging statements I add)..  Further, the call to
idle() never returns, no matter what happens that *should* be
generating an interrupt: entering key strokes on the keyboard, mouse
clicks, sending packets directly to the Ethernet interface by mucking
with the arp tables on a different machine and running ping from there
or sending to the broadcast address, etc.  If nothing else, I'd expect
clock interrupts to disrupt the HLT and thus make idle() return.  But
none of that happens.

If I comment out the call to idle() (which is how I see that m->ticks
never changes) then wait() just loops forever.

>  are you saying that wait doesn't even timeout?

That's exactly what I'm saying.

> or do you mean that it's not getting any ethernet interrupts?

It ain't getting any interrupts period: none from the ethernet, and
not even from the clock.  Of it if is, they're doing really strange
things that I cannot understand.  Or my understanding of these things
is even worse than I thought that it was.

> what irq is being enabled by ether8269.c?

According to the status messages, IRQ 11.

I should note that the machine can successfully boot (and run) OpenBSD
via PXE (by first loading the OpenBSD PXE loader and then loading and
booting an OpenBSD miniroot), so I don't think it's a hardware
problem.  That the clock doesn't seem to be interrupting at all and
that I pulled a new RTL8169 driver out of your directory on sources
and wedged it into 9pxeload with the same results makes me think that
it's not an ethernet driver issue.  I suspect that either the
interrupt vector is being incorrectly set or corrupted, or that
interrupts are somehow being disabled and never re-enabled.  The
latter doesn't seem particularly likely to me.

        - Dan C.