From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: north_ Message-ID: <48effcda.0112011821.629134fe@posting.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit References: <20011123.084311.-2827.0.msenecal1@juno.com> Subject: Re: [9fans] '486 terminal freezes during boot (FIX) Date: Mon, 3 Dec 2001 10:09:14 +0000 Topicbox-Message-UUID: 2e6a4cf2-eaca-11e9-9e20-41e7f4b1d025 msenecal1@juno.com (Matthew W Senecal) wrote in message news:<20011123.084311.-2827.0.msenecal1@juno.com>... > When booting the Plan 9 partition on my '486 terminal, it freezes. At > boot I see this on screen: > > PBS...Plan 9 From Bell Labs > dev A0 port 1F0 config 0C5A capabilities 0101 mwdma 0101 > using sdC0!9fat!Plan9.ini > found 9PCDISK. attr 0x0 start 0x4a len 1441737 > .650381......+489424......+87400=1227205 > entry: 0x80100020 > cpu0:61MHz 486DX (cpuid: Ax 0x0400 Dx 0x000) > dev A0 port 1F0 config 0C5A capabilities 0101 mwdma 0101 dma 00000001 > rwm16 > 7125 free pages > 28500K bytes > 134100K swap > > And that's where it freezes. I've let it sit for a half hour, but still > no go. I tried re-installing Plan 9 (on this '486 that's a 2-hour > chore!), re-installing it with the network card disabled, but neither > worked. The installation disk worked flawlessly, no errors, lock-ups, or > anything. > > Does anyone know what might be causing this? Yes, I also had this same problem yesterday so I thought I'd take a quick poke at it tonight. The following is a HOW-TO to fix the puppy :) BTW, if u r not like me and don't have access to multiple plan9 boxes (me 2 weeks ago) I attached a compiled 9pcdisk kernel that will do the work shown below. Errr this isnt an email (can u tell ive never subscribed to a news group before?) so I'll upload the kernel to: http://blessedchildren.virtualave.net/plan9/9pcdisk I don't think google will let me post a binary file :( I'm sure this will help u but if it doesnt feel free to email me privately and maybe we can discuss the problem more. I'd like a nicer fix put into the current 9tree for poor hackers like myself ;) ----- start fix how-to ----- 1. find the last known action performed on screen in the kernel XXX free pages YYYK bytes ZZZK swap ^--- this is found in /sys/src/9/port/page.c in pageinit() 2. who calls pageinit? a quick scan of my notes shows main() calls pageinit 3. easy enough so far :) simply add in print calls after the last 4 functions called in main() (main.c) to see if it hangs during any of these functions (schedinit()) shouldn't return /sys/src/9/pc/main.c pageinit(); print("XXX meep! \n"); swapinit(); print("XXX north_ has nice socks \n"); userinit(); print("XXX :) \ n"); schedinit(); print("XXX can i get an amen?!?! \n"); /* shouldnt get here */ } 4. mk 'CONF=pcdisk' 9pcdisk ; w/ the new main.c 5. slap the bootdisk into the troubled 486 and boot into the install procedure 6. wait. 7. wait some more. (dont u love 486? ;)) 8. while we wait take the time to throw 9pcdisk onto a web server somewhere. the plan9 box u made it on, a nice lil freebsd box u have handy, a palm pilot available someplace on your network... errrr maybe that ZoomerPDA u have still sitting around your lab :) 9. ok, once booted into the installation program u should still have the inst file on the floppy. therefore all u need to do is 'startether' and then open a new rc terminal. 9a. BTW, if u used a fresh install disk just skip down to 'archconfig' or whatever (just enough to set up ur ethernet/ppp :)) 10. in rc, hget the 9pcdisk from the web server u have it on hget -o 9pcdisk http://192.168.1.1:8080/p9/9pcdisk 11. bust a `9fat:` 12. copy the original kernel /n/9fat/9pcdisk to /n/9fat/9pcorig or whatever 13. install your 9pcdisk in the /n/9fat/ directory ;) 14. go back to the install window and select 'finish' 15. reboot and watch the magic Apparently what happens is the code goes into an interrupt spin waiting for any interrupt what-so-ever. Well, I first posed this theory to myself when I'd hit CTRL-ALT-DEL when the kernel was supposedly hung and get a big kernel trace dump on the screen. I noticed that once that interrupt was emulated the kernel continued to try and run because it was waiting specifically for an interrupt. There is no other reason for the kernel to attempt to run a normal process during an event which is supposed to set the system into a halted state :) it should be starting shutdown tasks. So, by printing data to the screen we automatically create an interrupt before going into the scheduling 'loop'. This satisfies the kernel on the 486 enough to stop waiting and continue on with normal process. I was immediately tossed into rio :) yay! Its Saturday night, though, so I thought I'd go out and have some fun. Can't fix the entire problem tonight, I will start tomorrow! Best of Luck, north_ http://blessedchildren.virtualave.net/northern p.s. this takes about a total of 10 minutes p.p.s. i need money im poor hehe