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

[balaji <balaji.srinivasa+plan9@gmail.com>]

I have had the same problems... With a Dell Precision 470.
In my case it was a SATA controller that was enabled/connected.

The pxeboot will load the boot agent however after that there
will be no network activity. What this means is the PXE agent
on the NIC is good and can bring down the initial agent. However
once it gets going, it has trouble communicating over the network.

It has to be an interrupt issue, and I could never figure it out. I pulled
the SATA disk out, disabled the controller via BIOS and all was good.

Something similar is happening in yours... Check what peripherals
you have and see if anything that is not necessary can be disabled
till you get past this boot process.

HTH

On Fri, Jun 5, 2009 at 1:49 PM, Dan Cross<crossd@gmail.com> wrote:
> 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.
>
>