Re: [9fans] dual boot

[erik quanstrom <quanstro@quanstro.net>]

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:
> 
> 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?

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:
> 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.

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.

- erik