9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Ramakrishnan Muthukrishnan <vu3rdd@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] dual boot
Date: Sun, 25 May 2014 10:41:26 +0530	[thread overview]
Message-ID: <CAA6Yd9U08Fk91h7sfsCgGCitioP254EvDsOzgmxKN_8e--Y8Rg@mail.gmail.com> (raw)
In-Reply-To: <d0c39206beaab6307a95f0bdbf3dceb7@brasstown.quanstro.net>

On Sat, May 24, 2014 at 8:04 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> 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?

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



  reply	other threads:[~2014-05-25  5:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-23 12:40 Ramakrishnan Muthukrishnan
2014-05-23 12:47 ` erik quanstrom
2014-05-23 12:51 ` Jacob Todd
2014-05-24  6:43   ` Ramakrishnan Muthukrishnan
2014-05-24  6:47     ` Ramakrishnan Muthukrishnan
2014-05-24 11:33       ` Ramakrishnan Muthukrishnan
2014-05-24 12:01         ` Nick Owens
2014-05-24 12:13           ` Ramakrishnan Muthukrishnan
2014-05-24 14:34     ` erik quanstrom
2014-05-25  5:11       ` Ramakrishnan Muthukrishnan [this message]
2014-05-25  5:28         ` Ramakrishnan Muthukrishnan
2014-05-25  5:37         ` erik quanstrom
2014-05-25  8:09           ` Ramakrishnan Muthukrishnan
2014-05-25  9:08             ` Ramakrishnan Muthukrishnan
2014-05-25 17:25               ` Brian L. Stuart
2014-05-25 17:51                 ` Ramakrishnan Muthukrishnan
2014-05-25 23:05                   ` Brian L. Stuart
2014-05-25 21:49             ` erik quanstrom
2014-05-26 10:37               ` Ramakrishnan Muthukrishnan
2014-05-26 12:49                 ` erik quanstrom
2014-05-24 14:35     ` erik quanstrom
2014-05-25  5:12       ` Ramakrishnan Muthukrishnan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA6Yd9U08Fk91h7sfsCgGCitioP254EvDsOzgmxKN_8e--Y8Rg@mail.gmail.com \
    --to=vu3rdd@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).