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

[Dan Cross <crossd@gmail.com>]

On Fri, Jun 5, 2009 at 10:18 PM, erik quanstrom<quanstro@quanstro.net> wrote:
> i think there are two general possiblities.
> (a) the southbridge is not recognized and irq routing is not
> properly initialized
> (b) 9load is stepping on low memory that bios tells us
> is not available.  in general x86 platforms have been shrinking
> the amount of low memory available.
>
> to tell what is going on, i think it would make sense to strip
> everything out of 9load and just get to main() and set up
> a clock interrupt at the default 86Hz and print something each
> time through.  then call HLT.
>
> i can't see how this could fail (i.e. print nothing), but if it does
> at least we know where to start.
>
> if it works, then we can start investigating other possibilties.

Short summary: I got it working.  Short analysis: Well....  That was a
hell of a thing.

Longer analysis: Based on your advice, I started playing around in
9pxeload to disable things and see if I could run with just the clock
enabled.  That worked.  Then, I started to put things back in; I got
to the point where I realized that the rtl8169init() function wasn't
returning correctly.  Looking at it, I saw that the likely culprit was
the switch statement testing ctlr->macv; sure enough, my macv
(0x24800000 - I guess I was a little wrong about exactly what chipset
it is) didn't have a case associated with it.  So, I added one (that
just did break;).  Voila the kernel loaded (and so did the plan9.ini
from /cfg/pxe).  My next step was to add the same case to the
corresponding driver in the kernel.  Now, I got to the 'boot from'
prompt, selected tcp and was able to login.  The VESA video started
up, and I was good to go.  The terminal is running fine.  Hooray.

So that was it; a one line change to add a case statement to a switch
(two if you count the definition of a symbolic constant; three if you
count adding a print() before returning from rtl8169init()).  I knew
it would end up being something like that.

I guess when rtl8169init() returned, it had left interrupts off or
something; certainly, the adapter was only partially setup.  I was a
bit surprised that there wasn't more in the way of an error in that
case.  Oh well.

Now, my next big challenge is to get the VESA video modes to map up to
what the monitor that's running this expects (the monitor can do
1680x1050, but VESA doesn't support that).  I don't suppose anybody
has a "real" driver for the Intel 945?  Or some other way to force it
to change resolution?

        - Dan C.