From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <5557ac66b8ce61ab8ec505beefdcd20e@quanstro.net> References: <5557ac66b8ce61ab8ec505beefdcd20e@quanstro.net> Date: Sat, 6 Jun 2009 02:57:25 -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: 05ebc958-ead5-11e9-9d60-3106f5b1d025 On Fri, Jun 5, 2009 at 10:18 PM, erik quanstrom wrot= e: > 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. =C2=A0in 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. =C2=A0then 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.