From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 24 May 2014 10:34:35 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] dual boot Topicbox-Message-UUID: f058b6b0-ead8-11e9-9d60-3106f5b1d025 On Sat May 24 02:46:08 EDT 2014, vu3rdd@gmail.com 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: >=20 > Plan 9 > E820: .... > ... > apic: 6 machs started; flat mode vectors > winbont ffff.ff hw fff8 > no capabilities > panic: kernel fault: no user process pc=3Df0162415 addr=3D0x000000a8 > panic: kernel fault: no user process pc=3Df0162415 addr=3D0x000000a8 > dumpstack disabled > cpu0: exiting > cpu0: spurious interrupt 39, last 0 >=20 > and it hangs there. >=20 > Is there any options I can try to move past this step? > --=20 > Ramakrishnan >=20 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 !=3D 1) 384 return -1; >385 return =C2=B7rtl8169miimiw(mii->ctlr, pa, ra, data); 386 } 387=09 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? one thing i am confused about, you have > panic: kernel fault: no user process pc=3Df0162415 addr=3D0x000000a8 > panic: kernel fault: no user process pc=3Df0162415 addr=3D0x000000a8 i assume this was typed by hand? i would expect it to read: > panic: kernel fault: no user process pc=3D0xf0162415 addr=3D0x000000a8 > panic: kernel fault: no user process pc=3D0xf0162415 addr=3D0x000000a8 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 eno= ugh. 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 woul= d 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 aff= inity. (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=C2= =B5s "delay" in some cases. i'm working on it. the good news is that we now see correct load averages, fairness, and ker= nel compile times have dropped 40% from before. - erik