On Sat, May 24, 2014 at 8:04 PM, erik quanstrom <[email protected]> wrote: > On Sat May 24 02:46:08 EDT 2014, [email protected] wrote: >> I downloaded the usbinstamd64 image from the 9atom webpage and booted >> it up. First, I tried amd64 (selection 0), in a second or so, some >> text went past the screen quickly and the machine rebooted. I then >> tried selection 1 (386pae), that booted up but quickly halted with >> this: >> >> Plan 9 >> E820: .... >> ... >> apic: 6 machs started; flat mode vectors >> winbont ffff.ff hw fff8 >> no capabilities >> panic: kernel fault: no user process pc=f0162415 addr=0x000000a8 >> panic: kernel fault: no user process pc=f0162415 addr=0x000000a8 >> dumpstack disabled >> cpu0: exiting >> cpu0: spurious interrupt 39, last 0 >> >> and it hangs there. >> >> Is there any options I can try to move past this step? >> -- >> Ramakrishnan >> > > well, first sorry. this is not a usb issue. since you're using > the 9paed kernel, this is the crash site: > > acid; src(0xf0162415) > /sys/src/9/pcpae/ether8169.c:385 > 380 static int > 381 rtl8169miimiw(Mii *mii, int pa, int ra, int data) > 382 { > 383 if(pa != 1) > 384 return -1; >>385 return ·rtl8169miimiw(mii->ctlr, pa, ra, data); > 386 } > 387 > 388 static Mii* > 389 rtl8169mii(Ctlr* ctlr) > 390 { > > and after a little inspection, i see the issue. and i've applied a patch. > does the amd64 kernel behave differently?
Thanks. :) Yes, the amd64 kernel just reboots before I could read anything on the screen. > one thing i am confused about, you have > >> panic: kernel fault: no user process pc=f0162415 addr=0x000000a8 >> panic: kernel fault: no user process pc=f0162415 addr=0x000000a8 > > i assume this was typed by hand? i would expect it to read: Yes, I typed them by hand. Sorry about the error. >> panic: kernel fault: no user process pc=0xf0162415 addr=0x000000a8 >> panic: kernel fault: no user process pc=0xf0162415 addr=0x000000a8 > > there is a new TEST image @ http://ftp.9atom.org/other/+usbinstamd64.bz2 > i have not had a chance to try it myself, but the crash seems obvious enough. Thanks. I just tried it and indeed, with the pae kernel, it gets me into the installer. At some point, I mistakenly selected ("arches to install" as amd64, well I really wanted to install amd64 but perhaps the kernel has not been rebuilt for amd64 I guess. Now, it proceeds to "build full set of amd64 executables?" which I selected "yes". I then get a build error: 8c -FTVw s_tolower.c s_rdinstack.c:13 not a function s_rdinstack.c:13 syntax error, last name: Sinstack mk: 8c -FTVw s_rdinstack.c : exit status=rc 594: 8c 604: error mk: date for (i ... : exit status=rc 509: rc 563: mk 565: error halt system? (yes, no, skip)[no default] I am going to try installing a 386 system instead (after sending out this email). Also the amd64 kernel still didn't boot. When I selected amd64 (selection 0), it just printed something that I couldn't read and rebooted the system. > one warning: yesterday i applied some changes to the amd64 scheduler, > to generate the correct load average, and to calm down the absolute > mach affinity. this would cause dramatic unfairness whever nrdy > nmach. > this is because on some cpu, two processes would get assigned. they would > share the cpu fairly, but on nmach-1 maches, the busy process would get a > whole > cpu. the solution was to watch how long a process has been ready and use that > as a hint that it should be run, even if there is a proc with greater > affinity. > > (thanks to jyu and gsoc!) but removing the obvious bugs has > put the scheduler a bit out of tune, and things like ping may see a 20µs > "delay" in some cases. i'm working on it. > > the good news is that we now see correct load averages, fairness, and kernel > compile times have dropped 40% from before. Very eager to try these out. If you have any new builds and want to test them out (and can bear the time zone difference -- I am in GMT+5.30), I will be glad to test them out. -- Ramakrishnan
