[9fans] kernels

[9fans] kernels

[David Presotto]

I brought the kernel and libc sources up to date with what we're
running at the labs.  Problems to me.

Re: [9fans] kernels

[Bruce Ellis]

John "Iron Bar" Mackin would have approved.

brucee

On 3/11/06, Ronald G. Minnich <rminnich@lanl.gov> wrote:
> > interesting, i haven't had any problems with the Big Red Switch.
> > although i can't boot plan9 from cd.
>
>
> This L440GX+ thread is just killing me. I had 128 of these dogs in 1999,
> and the bios was so bad that it caused me to start the linuxbios project.
> I'm hearing about lots of nice bugs on these boards, that I never
> suspected, and I'm glad I didn't have to deal with them.
>
> I had all kinds of creative ways of disposing of these boards when they
> fried. My favorite was to take an 8" long piece of railroad rail I had
> (approx weight 25 lbs) and do a competition: if the L440GX+ was dropped on
> the rail, or the rail was dropped on the l440GX+, who won? Also, of
> course, angle of entry of the rail could be investigated, as could drop
> height, ... the possibilities were endless.
>
> Ah, the L440GX+ ... may it burn in pennsauken.
>
> ron
>

Re: [9fans] kernels

[Jack Johnson]

On 3/10/06, Ronald G. Minnich <rminnich@lanl.gov> wrote:
> I had all kinds of creative ways of disposing of these boards when they
> fried.

I like sending my toxin-filled, bug-riddled, aging technology to third
world countries to burden their economy, keeping their labor pool
cheap enough to build my Matrix.

But that's just me.

-Jack

Re: [9fans] kernels

[Charles Forsyth]

> I had all kinds of creative ways of disposing of these boards when they
> fried. My favorite was to take an 8" long piece of railroad rail I had
> (approx weight 25 lbs) and do a competition: if the L440GX+ was dropped on
> the rail, or the rail was dropped on the l440GX+, who won? Also, of
> course, angle of entry of the rail could be investigated, as could drop
> height, ... the possibilities were endless.

i took a similar approach with travelstars, latterly preemptively, but i'd got
nothing as classy as that for the test drops.

just a moment: was that the original inspiration for ruby on rails?

Re: [9fans] kernels

[erik quanstrom]

well, ya. the Big Red Switch is a Big Red Switch on any machine.
even if the switch is a button and that button is black.

it leaves less to the imagination if you have a original IBM PC.

the 2200 (i think) i have sitting on top of my minifridge
has a really bright blue nightlight and 3 other leds. i think
they're green and yellow. there's both a reset and a power switch.

it's not a fancy new one with a front cover like you've got.

- erik

jmk@plan9.bell-labs.com writes

|
| See, that's the problem right there - these VA Linux boxes
| have a switch with a very bright and annoying BLUE LED, not red.
| Of course, you can't see the switch/LED if the front cover is on,
| but what's the point of that, then you can't access the switch.
|
| On Fri Mar 10 22:16:12 EST 2006, quanstro@quanstro.net wrote:
| > interesting, i haven't had any problems with the Big Red Switch.
| > although i can't boot plan9 from cd.
| >
| > - erik
| >
| > jmk@plan9.bell-labs.com writes
| >
| > |
| > | On Fri Mar 10 21:05:14 EST 2006, geoff@collyer.net wrote:
| > | > I helped a friend add a second processor to an l440gx+ in 2003.  It
| > | > was running RedHat and needed a fix to one of the file system
| > | > implementations (ext3?) but I also have a faint memory of needing to
| > | > upgrade its firmware to make SMP work reliably.
| > |
| > | I had problems with the first of these systems I tried (the system was
| > | always on, took no notice of the front power or reset buttons) until I
| > | upgraded the firmware (still available on the Intel site). Now, whenever
| > | I liberate one of these machines from its miserable life of servitude
| > | running Linux I automatically upgrade it and let it run free, no longer
| > | shackled to the whims of rotating media.

Re: [9fans] kernels

[jmk]

See, that's the problem right there - these VA Linux boxes
have a switch with a very bright and annoying BLUE LED, not red.
Of course, you can't see the switch/LED if the front cover is on,
but what's the point of that, then you can't access the switch.

On Fri Mar 10 22:16:12 EST 2006, quanstro@quanstro.net wrote:
> interesting, i haven't had any problems with the Big Red Switch.
> although i can't boot plan9 from cd.
>
> - erik
>
> jmk@plan9.bell-labs.com writes
>
> |
> | On Fri Mar 10 21:05:14 EST 2006, geoff@collyer.net wrote:
> | > I helped a friend add a second processor to an l440gx+ in 2003.  It
> | > was running RedHat and needed a fix to one of the file system
> | > implementations (ext3?) but I also have a faint memory of needing to
> | > upgrade its firmware to make SMP work reliably.
> |
> | I had problems with the first of these systems I tried (the system was
> | always on, took no notice of the front power or reset buttons) until I
> | upgraded the firmware (still available on the Intel site). Now, whenever
> | I liberate one of these machines from its miserable life of servitude
> | running Linux I automatically upgrade it and let it run free, no longer
> | shackled to the whims of rotating media.

Re: [9fans] kernels

[erik quanstrom]

ron, you need to get out more!

unfortunately i'd have to admit to having similar fun this week, 
but on a different scale:
3000# toyota vs. 76000# flatbed semi. it would have 
been a bit better with an ibm rs/6000 590 mounted on the grill.

i am accepting donations of better hardware. ;-)

- erik

"Ronald G. Minnich" <rminnich@lanl.gov> writes

| 
| > interesting, i haven't had any problems with the Big Red Switch.
| > although i can't boot plan9 from cd.
| 
| 
| This L440GX+ thread is just killing me. I had 128 of these dogs in 1999,
| and the bios was so bad that it caused me to start the linuxbios project.
| I'm hearing about lots of nice bugs on these boards, that I never
| suspected, and I'm glad I didn't have to deal with them.
| 
| I had all kinds of creative ways of disposing of these boards when they
| fried. My favorite was to take an 8" long piece of railroad rail I had
| (approx weight 25 lbs) and do a competition: if the L440GX+ was dropped on
| the rail, or the rail was dropped on the l440GX+, who won? Also, of
| course, angle of entry of the rail could be investigated, as could drop
| height, ... the possibilities were endless.
| 
| Ah, the L440GX+ ... may it burn in pennsauken.
| 
| ron

Re: [9fans] kernels

[Ronald G. Minnich]

> interesting, i haven't had any problems with the Big Red Switch.
> although i can't boot plan9 from cd.


This L440GX+ thread is just killing me. I had 128 of these dogs in 1999,
and the bios was so bad that it caused me to start the linuxbios project.
I'm hearing about lots of nice bugs on these boards, that I never
suspected, and I'm glad I didn't have to deal with them.

I had all kinds of creative ways of disposing of these boards when they
fried. My favorite was to take an 8" long piece of railroad rail I had
(approx weight 25 lbs) and do a competition: if the L440GX+ was dropped on
the rail, or the rail was dropped on the l440GX+, who won? Also, of
course, angle of entry of the rail could be investigated, as could drop
height, ... the possibilities were endless.

Ah, the L440GX+ ... may it burn in pennsauken.

ron

Re: [9fans] kernels

[erik quanstrom]

interesting, i haven't had any problems with the Big Red Switch.
although i can't boot plan9 from cd.

- erik

jmk@plan9.bell-labs.com writes

|
| On Fri Mar 10 21:05:14 EST 2006, geoff@collyer.net wrote:
| > I helped a friend add a second processor to an l440gx+ in 2003.  It
| > was running RedHat and needed a fix to one of the file system
| > implementations (ext3?) but I also have a faint memory of needing to
| > upgrade its firmware to make SMP work reliably.
|
| I had problems with the first of these systems I tried (the system was
| always on, took no notice of the front power or reset buttons) until I
| upgraded the firmware (still available on the Intel site). Now, whenever
| I liberate one of these machines from its miserable life of servitude
| running Linux I automatically upgrade it and let it run free, no longer
| shackled to the whims of rotating media.

Re: [9fans] kernels

[erik quanstrom]

i believe those problems were inherent to the code, not the platform.
early versions of 2.4 did not work with l440gx+ machines at all.

- erik

geoff@collyer.net writes

|
| I helped a friend add a second processor to an l440gx+ in 2003.  It
| was running RedHat and needed a fix to one of the file system
| implementations (ext3?) but I also have a faint memory of needing to
| upgrade its firmware to make SMP work reliably.

Re: [9fans] kernels

[jmk]

On Fri Mar 10 21:05:14 EST 2006, geoff@collyer.net wrote:
> I helped a friend add a second processor to an l440gx+ in 2003.  It
> was running RedHat and needed a fix to one of the file system
> implementations (ext3?) but I also have a faint memory of needing to
> upgrade its firmware to make SMP work reliably.

I had problems with the first of these systems I tried (the system was
always on, took no notice of the front power or reset buttons) until I
upgraded the firmware (still available on the Intel site). Now, whenever
I liberate one of these machines from its miserable life of servitude
running Linux I automatically upgrade it and let it run free, no longer
shackled to the whims of rotating media.

Re: [9fans] kernels

[geoff]

I helped a friend add a second processor to an l440gx+ in 2003.  It
was running RedHat and needed a fix to one of the file system
implementations (ext3?) but I also have a faint memory of needing to
upgrade its firmware to make SMP work reliably.

Re: [9fans] kernels

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 108 bytes --]

8i is just under 7,000 lines, but could perhaps be reduced.
or, since it's intel/bios related, increased!

[-- Attachment #2: Type: message/rfc822, Size: 3163 bytes --]

From: Ronald G Minnich <rminnich@lanl.gov>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] kernels
Date: Fri, 10 Mar 2006 15:53:21 -0700
Message-ID: <44120361.5050902@lanl.gov>

Russ Cox wrote:

> (keep the kernel a little smaller, a little safer).

now that you mention this ...
source to an out-of-kernel emulator is in the linuxbios tree in
/LinuxBIOSv2/util/vgabios/

btw: most of this is from X11. I just broke it out, fixed some bugs,
Ollie fixed some more, and made it all work standalone.

It could be ported to plan 9 without too much trouble.

I think the standalone prog is the way to go, too.

ron

Re: [9fans] kernels

[Russ Cox]

> As cool as I think the VESA stuff is, our experience is that it's also a
> mistake to do it via switch to 16-bit mode. Making it work right gets
> really tricky, as you just learned with SMP; that's only one possible
> hazard. We've been enabling graphics with an emulator-based approach for
> a few years now, and it does work well. Code available in the linuxbios
> source tree, if anybody wants to mess around with it.

>> You can also use VM86 mode on 386 (but not AMD/x86-64).
>> It actually isn't so bad -- I'd have to think it would
>> be much easier than going back to real mode.  Of course,
>> it isn't an option on 64-bit machines, which may effectively
>> leave you in the same place.

If anyone wants to do either of these, be my guest.
They're both better approaches than what is there now.
I lean toward the emulator, and it would be nice if it could
be done with the bulk of the code outside the kernel
(keep the kernel a little smaller, a little safer).

Russ

Re: [9fans] kernels

[Ronald G Minnich]

Russ Cox wrote:

> (keep the kernel a little smaller, a little safer).

now that you mention this ...
source to an out-of-kernel emulator is in the linuxbios tree in
/LinuxBIOSv2/util/vgabios/

btw: most of this is from X11. I just broke it out, fixed some bugs,
Ollie fixed some more, and made it all work standalone.

It could be ported to plan 9 without too much trouble.

I think the standalone prog is the way to go, too.

ron

Re: [9fans] kernels

[Ronald G Minnich]

David Leimbach wrote:

> Where would that be...?

well, goodness, if I said where it was, then it would get to be a noisy
channel again. That's already happened several times.


ron

Re: [9fans] kernels

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

On 3/10/06, Ronald G. Minnich <rminnich@lanl.gov> wrote:
>
> Russ, any time spent reading IRC is a waste of your neurons -- unless
> you're mainly reading it for amusement. I have to admit the last two day's
> posts have been pretty damn funny.
>
> We need to start a closed channel for people who do actual work.
>
> Oh wait, I forgot, there is one. Never mind.


Where would that be...? uriel is my #1 Plan 9 buzzkill these days.

Dave


ron
>

[-- Attachment #2: Type: text/html, Size: 908 bytes --]

Re: [9fans] kernels

[Ronald G Minnich]

William Josephson wrote:
> On Fri, Mar 10, 2006 at 04:31:31PM -0500, jmk@plan9.bell-labs.com wrote:
>
>>To be fair, it's not the 'standard's that are at fault here.
>>Using VESA requires taking the processor out of protected mode
>>and jumping into the BIOS and that's difficult with 2 processors
>>as we need to make sure they are all agreed on what's going on
>>and interrupts are properly disabled, etc. The Plan 9 x86 SMP
>>code wasn't written with those goals in mind. It should be possible
>>but clearly we didn't get it right and it's a low-priority item.
>
>
> You can also use VM86 mode on 386 (but not AMD/x86-64).
> It actually isn't so bad -- I'd have to think it would
> be much easier than going back to real mode.  Of course,
> it isn't an option on 64-bit machines, which may effectively
> leave you in the same place.

As cool as I think the VESA stuff is, our experience is that it's also a
mistake to do it via switch to 16-bit mode. Making it work right gets
really tricky, as you just learned with SMP; that's only one possible
hazard. We've been enabling graphics with an emulator-based approach for
a few years now, and it does work well. Code available in the linuxbios
source tree, if anybody wants to mess around with it.

thanks

ron

Re: [9fans] kernels

[William Josephson]

On Fri, Mar 10, 2006 at 04:31:31PM -0500, jmk@plan9.bell-labs.com wrote:
> To be fair, it's not the 'standard's that are at fault here.
> Using VESA requires taking the processor out of protected mode
> and jumping into the BIOS and that's difficult with 2 processors
> as we need to make sure they are all agreed on what's going on
> and interrupts are properly disabled, etc. The Plan 9 x86 SMP
> code wasn't written with those goals in mind. It should be possible
> but clearly we didn't get it right and it's a low-priority item.

You can also use VM86 mode on 386 (but not AMD/x86-64).
It actually isn't so bad -- I'd have to think it would
be much easier than going back to real mode.  Of course,
it isn't an option on 64-bit machines, which may effectively
leave you in the same place.

Re: [9fans] kernels

[jmk]

To be fair, it's not the 'standard's that are at fault here.
Using VESA requires taking the processor out of protected mode
and jumping into the BIOS and that's difficult with 2 processors
as we need to make sure they are all agreed on what's going on
and interrupts are properly disabled, etc. The Plan 9 x86 SMP
code wasn't written with those goals in mind. It should be possible
but clearly we didn't get it right and it's a low-priority item.

You will need to get the changes I made today for
/sys/src/cmd/aux/vga/clgd542x.c and /sys/src/9/pc/vgaclgd542x.c,
make a new kernel and aux/vga. Run aux/vga -B | sed 20q and check
the new entry in /lib/vgadb matches the starting position of
the string in the BIOS output. If it's all OK then change the
plan9.ini monitor= to something real (not VESA) and reboot.

--jim

On Fri Mar 10 16:17:55 EST 2006, quanstro@quanstro.net wrote:
> hey, thanks! i didn't know that there was a problem with vesa and smp.
> (how do they come up with these standards.)
>
> do i need to change my configuration to take advantage of this?
>
> here's what i currently have: (i know the bootdisk line is wrong;
> i killed my 9fat partition somehow. i didn't trust the install with
> my fossil so i cooked this up (incorrectly) by hand.)
>
> ; cat plan9.ini
> *nomp=1
> bootfile=sdC0!9fat!9pcf
> bootdisk=local!#S/sdC0/fossil
> mouseport=ps2
> monitor=vesa
> vgasize=1280x1024x8
>
> jmk@plan9.bell-labs.com writes
> |
> | Ah. There's a pile of those in my office (recycled VA Linux servers),
> | let's hook one up...
> |
> | The problem is you cannot run VESA with SMP, one of the processors
> | ends up looping somewhere it shouldn't (it has probably crashed) and
> | the CL-GD5480 chip is not recognised by aux/vga. So...
> |
> | new /lib/vgadb, /sys/src/cmd/aux/vga/clgd542x.c and /sys/src/9/pc/vgaclgd542x.c
> | on sources.
> |
> | --jim
> |

Re: [9fans] kernels

[Russ Cox]

> here's what i currently have: (i know the bootdisk line is wrong;
> i killed my 9fat partition somehow. i didn't trust the install with
> my fossil so i cooked this up (incorrectly) by hand.)

after you pull a new vga binary
you should be able to remove the *nomp=1
and then use monitor=multisync135 or multisync110.

russ

Re: [9fans] kernels

[erik quanstrom]

hey, thanks! i didn't know that there was a problem with vesa and smp.
(how do they come up with these standards.)

do i need to change my configuration to take advantage of this?

here's what i currently have: (i know the bootdisk line is wrong;
i killed my 9fat partition somehow. i didn't trust the install with
my fossil so i cooked this up (incorrectly) by hand.)

; cat plan9.ini
*nomp=1
bootfile=sdC0!9fat!9pcf
bootdisk=local!#S/sdC0/fossil
mouseport=ps2
monitor=vesa
vgasize=1280x1024x8

jmk@plan9.bell-labs.com writes
|
| Ah. There's a pile of those in my office (recycled VA Linux servers),
| let's hook one up...
|
| The problem is you cannot run VESA with SMP, one of the processors
| ends up looping somewhere it shouldn't (it has probably crashed) and
| the CL-GD5480 chip is not recognised by aux/vga. So...
|
| new /lib/vgadb, /sys/src/cmd/aux/vga/clgd542x.c and /sys/src/9/pc/vgaclgd542x.c
| on sources.
|
| --jim
|

Re: [9fans] kernels

[Sam Hopkins]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

On 3/10/06, Ronald G. Minnich <rminnich@lanl.gov> wrote:
>
> Russ, any time spent reading IRC is a waste of your neurons -- unless
> you're mainly reading it for amusement. I have to admit the last two day's
> posts have been pretty damn funny.
>
>
While it is comical, it's also disappointing how much time Russ et al must
spend correcting the disinformation spread by folks who simply like to hear
themselves talk.

It's this kind of unsupportive ignorance that drives good people from this
community.

[-- Attachment #2: Type: text/html, Size: 873 bytes --]

Re: [9fans] kernels

[jmk]

Ah. There's a pile of those in my office (recycled VA Linux servers),
let's hook one up...

The problem is you cannot run VESA with SMP, one of the processors
ends up looping somewhere it shouldn't (it has probably crashed) and
the CL-GD5480 chip is not recognised by aux/vga. So...

new /lib/vgadb, /sys/src/cmd/aux/vga/clgd542x.c and /sys/src/9/pc/vgaclgd542x.c
on sources.

--jim

On Fri Mar 10 12:46:11 EST 2006, quanstro@quanstro.net wrote:
> it's an intel l440gx+ motherboard with 2 pIII xeons and, a 440GX
> chipset. it's also got
> 1. 15G ide drive /dev/sdC0
> 2. cdrom /dev/sdD0
> 3. motherboard-based aic-7896 (nothing attached and not recognized)
> 	irq 11, io port 0x2800
> 4. pci-based dac960 (not recognized)
> 	irq 11, io port f4206000
> 5. 1gb registered ecc ram 2x256.
> 6. motherboard-based cirrus logic vga chipset with 2MB vram.
>
> it hangs. no reboot at all.
>
> "Ronald G. Minnich" <rminnich@lanl.gov> writes
>
> |
> |
> | > if anybody can give me some pointers on where to start looking,
> | > i'd like to see why my machine is failing on mp startup.
> | >
> |
> | sorry, had not been paying attention, what happens? Any errors at all? or
> | just spontaneous reboot?
> |
> | 2 cpu? What kind?
> |
> | ron

Re: [9fans] kernels

[Ronald G. Minnich]

> it's an intel l440gx+ motherboard with 2 pIII xeons and, a 440GX
> chipset.

my second linuxbios port was to these.

What's the console output? how far does it get?

ron

Re: [9fans] kernels

[erik quanstrom]

it's an intel l440gx+ motherboard with 2 pIII xeons and, a 440GX
chipset. it's also got
1. 15G ide drive /dev/sdC0
2. cdrom /dev/sdD0
3. motherboard-based aic-7896 (nothing attached and not recognized)
	irq 11, io port 0x2800
4. pci-based dac960 (not recognized)
	irq 11, io port f4206000
5. 1gb registered ecc ram 2x256.
6. motherboard-based cirrus logic vga chipset with 2MB vram.

it hangs. no reboot at all.

"Ronald G. Minnich" <rminnich@lanl.gov> writes

|
|
| > if anybody can give me some pointers on where to start looking,
| > i'd like to see why my machine is failing on mp startup.
| >
|
| sorry, had not been paying attention, what happens? Any errors at all? or
| just spontaneous reboot?
|
| 2 cpu? What kind?
|
| ron

Re: [9fans] kernels

[Ronald G. Minnich]

> if anybody can give me some pointers on where to start looking,
> i'd like to see why my machine is failing on mp startup.
>

sorry, had not been paying attention, what happens? Any errors at all? or
just spontaneous reboot?

2 cpu? What kind?

ron

Re: [9fans] kernels

[Tim Wiess]

    i don't use Linux much, but on BSD and other Unix systems
    this is actually quite normal. and it's done for many of the
    same reasons Russ mentioned.

[9fans] kernels

[erik quanstrom]

i consider the fact that you can cut down your configuration to a
minimum and get a kernel with a limp rather than nothing
a big bonus.

if anybody can give me some pointers on where to start looking,
i'd like to see why my machine is failing on mp startup.

- erik

"Russ Cox" <rsc@swtch.com> writes

| What causes differences between the three situations usually *isn't* the
| kernel but rather the kernel configuration or plan9.ini.  For example,
| the installer kernel doesn't include devusb, devlpt, or devaudio, all
| to keep it a little smaller.  We've seen problems where people install
| successfully and then something about the usb scan during the regular boot
| makes their system not boot.  There's very little one could do about that
| besides put usb into the installer kernel so that it breaks earlier.
| But we can't, for space reasons.  As another example, the plan9.ini
| during the install sets *nomp=1 but the regular plan9.ini does not.
| So if you something about the SMP code doesn't like your system, as we
| saw a few days ago, then the installed system won't boot.  These are all
| bugs to be fixed, but forcing us to debug them on the boot floppy instead
| of after install time doesn't really seem like the right solution to me.

Re: [9fans] kernels

[Ronald G. Minnich]

Russ, any time spent reading IRC is a waste of your neurons -- unless
you're mainly reading it for amusement. I have to admit the last two day's
posts have been pretty damn funny.

We need to start a closed channel for people who do actual work.

Oh wait, I forgot, there is one. Never mind.

ron

[9fans] kernels

[Russ Cox]

    uriel
              abhey: the fact that the kernels are out of sync OTOH
              is reason enough to have russ beaten up until he fucking
              understands THAT THE GOD DAMNED KERNELS SHOULD BE IN
              SYNC

    noselasd  uriel: which kernels are out of sync ?

    uriel     noselasd: CD-boot, installer, and installed; as usual
              *sigh*

It's actually hard to imagine how much more in sync these three kernels
could be.  They're all built from the same source, and the CD and
installer kernels are rebuilt every night.  I do tend not to push out the
"real" kernels every time there is a change, just to avoid making people
download new kernels constantly.  (The kernels embed the build time in
their binaries, so if you just did a straight cmp you'd think they were
new every night.)

I thought you were worried about kernels built from other trees not
being in sync, like 9load and the Inferno kernels.  I see you've moved
on to more pressing concerns.

It's true that in an ideal world, if one of the kernels booted on a machine,
all three would boot.  One way to do that would be to use the same kernel
in all three cases.  Another would be to fix the kernel so that it can handle
all the possible hardware configurations out there without bugs.
The first way is silly and doesn't solve the problem; the second is difficult
but is what we're working toward, slowly.  You're welcome to help.

We *cannot* use the same kernel for all three situations.  At the least,
the root file server connection mechanism is different whether you're
booting from a CD in the CD-ROM drive, a small in-memory ram file system
hard-coded into the kernel, or a local fossil.  Sure, we could put all
three into one big kernel and only use that, but it's nonsense to encode
the installer's ramfs into every kernel used everywhere.

What causes differences between the three situations usually *isn't* the
kernel but rather the kernel configuration or plan9.ini.  For example,
the installer kernel doesn't include devusb, devlpt, or devaudio, all
to keep it a little smaller.  We've seen problems where people install
successfully and then something about the usb scan during the regular boot
makes their system not boot.  There's very little one could do about that
besides put usb into the installer kernel so that it breaks earlier.
But we can't, for space reasons.  As another example, the plan9.ini
during the install sets *nomp=1 but the regular plan9.ini does not.
So if you something about the SMP code doesn't like your system, as we
saw a few days ago, then the installed system won't boot.  These are all
bugs to be fixed, but forcing us to debug them on the boot floppy instead
of after install time doesn't really seem like the right solution to me.

This is Plan 9, not Red Hat.  It's a research system.  Some hardware
configurations haven't been tried before and won't work.  With bug
reports, we are usually able to fix them.  If you'd like to fix any of
the lapses in driver support so that the kernels run flawlessly on more
systems, then by all means go ahead.  It's not useful just to jump up
and down shouting solutions (in this case, "THE GOD DAMNED KERNELS
SHOULD BE IN SYNC") that don't make any sense and don't even fix the
problem in many cases.

It's too bad you weren't around when the install was text-only and then
people would boot the installed system only to find out that their vga
card wasn't supported.  Those were the good old days.  You would have
loved that.

Russ