From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 5 Jun 2009 16:49:32 -0400 Message-ID: From: Dan Cross To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Missing interrupts in 9pxeload? Topicbox-Message-UUID: 05734b2c-ead5-11e9-9d60-3106f5b1d025 On Fri, Jun 5, 2009 at 2:28 PM, erik quanstrom wrote= : >> I am attempting to PXE boot it from my file/auth/boot/cpu server (the >> aforementioned machine that is having some problems). =C2=A0The machine >> DHCP's fine, and will load 9pxeload via TFTP, but then hangs. =C2=A0I >> 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. =C2=A0I 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'. =C2=A0Ie, do nothing until you receipt of an interrupt = and >> return. =C2=A0However, 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. =C2=A0It's as if all interrupts somehow got turned off prior to = the >> call to wait(). =C2=A0Has anyone else seen this? =C2=A0Could there be so= mething >> somewhere that's disabling interrupts that I should look into? =C2=A0Cou= ld >> things be being routed weirdly on an Atom processor? > > how are you verifying that this machine isn't getting any > interrupts? =C2=A0the wait loop will loop if an interrupt is rx'd > unless ring->owner !=3D 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. > =C2=A0are 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.