From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Ramakrishnan Muthukrishnan Date: Sun, 25 May 2014 10:41:26 +0530 Message-ID: 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] dual boot Topicbox-Message-UUID: f0ea0cf0-ead8-11e9-9d60-3106f5b1d025 On Sat, May 24, 2014 at 8:04 PM, erik quanstrom wro= te: > 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=3Df0162415 addr=3D0x000000a8 >> panic: kernel fault: no user process pc=3Df0162415 addr=3D0x000000a8 >> 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 !=3D 1) > 384 return -1; >>385 return =C2=B7rtl8169miimiw(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 scre= en. > 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: Yes, I typed them by hand. Sorry about the error. >> 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. 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=3Drc 594: 8c 604: error mk: date for (i ... : exit status=3Drc 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 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. 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. --=20 Ramakrishnan