[9fans] 'no fat' - boot failure

[9fans] 'no fat' - boot failure

[Burton Samograd]

Hello

I just installed 9front onto the second partition of my main SSD drive
and when I boot
using grub with 'chainloader +1' I get a PBS check which looks to pass
and then the
message 'no fat'.  I am thinking that my installation might be out of
sector range on the
drive; I installed on the second primary partition after a 50ish gig
first parition.  Does that
sound like it's my problem?  If not, any other ideas?

Here's what's in my grub.cfg which I got from another posting on 9fans:


menuentry "Plan9 (9front)" {
    insmod chain
    insmod fat16
    set root=(hd0,msdos2)
    chainloader +1
}

I got the (hd0,msdos2) from using the grub command line completion.
I've never seen that
format before so I'm thinking it's new, but then again I haven't
played with grub for a while.

--
Burton Samograd

Re: [9fans] 'no fat' - boot failure

[cinap_lenrek]

the pbs managed to load 9bootfat but 9bootfat wasnt able
to find the fat partition it came from.

we pass 32bit lba's to the bios read sector routines,
so theres nothing inside 9boot itself that would prevent
this from working i think.

9bootfat does its search by walking all partition table
entries (primary and secondary) on the bootdrive that
are marked as "active".

maybe you'r missing some grub command to mark the
particular plan9 partition as active before chainloading?

--
cinap

Re: [9fans] 'no fat' - boot failure

[Burton Samograd]

> 9bootfat does its search by walking all partition table
> entries (primary and secondary) on the bootdrive that
> are marked as "active".

Reading the grub docs, it sounds like an active partition is marked
bootable and only one partition can be marked that way.  Currently my
linux partition is marked bootable but I'm not sure if it needs to be
since grub is installed in the MBR.  Any thoughts?  I might just try to
set my plan9 partition bootable and see what happens; I'm sure i can fix
things if I can't boot later.

--
Burton Samograd

Re: [9fans] 'no fat' - boot failure

[Burton Samograd]

Toggling the bootable flag on the plan9 partition did allow it to start booting.
It then looked to be iterating over the drives, where on my harddisks I got:

sdE0 <disk name/id>
bad disk
bad disk
bad disk
bad disk
bad disk
sdE5 <disk name/id>
bad disk
bad disk
bad disk
bad disk
bad disk

This happened for both of my SATA hard drives, the DVD got through
this stage fine.
It appeared to be reading the disks completely; my SSD took about a
minute to get
before it went to the next drive which was 2T and I didn't  bother
waiting around longer
than 5 minutes to see if it would complete.

I've had nothing but problems with this hardware anyways so I'm not
surprised that plan9 has a
hard time working on it.  I might try it on this hardware again, but
I've got another system coming
soon anyways that I'm pretty sure will work just fine.

I tried 9front because the standard distro had a problem with my
disks, or at least finding the
boot partition/floppy on the cd.  9front would boot fine as a
live/install cd so I thought I was in
the clear but unfortunately not.

--
Burton Samograd

On Sun, May 13, 2012 at 6:22 PM, Burton Samograd
<burton.samograd@gmail.com> wrote:
>> 9bootfat does its search by walking all partition table
>> entries (primary and secondary) on the bootdrive that
>> are marked as "active".
>
> Reading the grub docs, it sounds like an active partition is marked
> bootable and only one partition can be marked that way.  Currently my
> linux partition is marked bootable but I'm not sure if it needs to be
> since grub is installed in the MBR.  Any thoughts?  I might just try to
> set my plan9 partition bootable and see what happens; I'm sure i can fix
> things if I can't boot later.
>
> --
> Burton Samograd

Re: [9fans] 'no fat' - boot failure

[erik quanstrom]

On Sun May 13 21:20:40 EDT 2012, burton.samograd@gmail.com wrote:
> Toggling the bootable flag on the plan9 partition did allow it to start booting.
> It then looked to be iterating over the drives, where on my harddisks I got:
>
> sdE0 <disk name/id>
> bad disk
> bad disk
> bad disk
> bad disk
> bad disk

i'm not sure of the lineage of the 9front driver, or what hardware you're using.
this sort of sounds like a hardware funny (which may be already fixed) or
puis (power-up in standby).  the output of the "pci" command, or lspci
on linux would be helpful.  if you could also get the output of "cat /dev/sdE5/ctl"
that would be good as well.

- erik

Re: [9fans] 'no fat' - boot failure

[Burton Samograd]

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

Attached is the output of lspci.  I'll see if I can get it to fully
boot to get the output of the other command.

--
Burton

On Sun, May 13, 2012 at 8:56 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Sun May 13 21:20:40 EDT 2012, burton.samograd@gmail.com wrote:
>> Toggling the bootable flag on the plan9 partition did allow it to start booting.
>> It then looked to be iterating over the drives, where on my harddisks I got:
>>
>> sdE0 <disk name/id>
>> bad disk
>> bad disk
>> bad disk
>> bad disk
>> bad disk
>
> i'm not sure of the lineage of the 9front driver, or what hardware you're using.
> this sort of sounds like a hardware funny (which may be already fixed) or
> puis (power-up in standby).  the output of the "pci" command, or lspci
> on linux would be helpful.  if you could also get the output of "cat /dev/sdE5/ctl"
> that would be good as well.
>
> - erik
>

[-- Attachment #2: lspci.txt --]
[-- Type: text/plain, Size: 2280 bytes --]

00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller (rev 02)
00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root Port (rev 02)
00:03.0 Communication controller: Intel Corporation 82G33/G31/P35/P31 Express MEI Controller (rev 02)
00:19.0 Ethernet controller: Intel Corporation 82566DC-2 Gigabit Network Connection (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 02)
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation 82801IH (ICH9DH) LPC Interface Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation GT218 [GeForce 210] (rev a2)
01:00.1 Audio device: nVidia Corporation High Definition Audio Controller (rev a1)
03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6101/6102 single-port PATA133 interface (rev b1)

Re: [9fans] 'no fat' - boot failure

[erik quanstrom]

> 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02)
> 03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6101/6102 single-port PATA133 interface (rev b1)

i assume that you're attached to 00:1f:2, the sata controller due to the message.
this controller is close to the one i originally built the ahci driver on, so i doubt
that you're hitting a serious controller problem right off the bat.  i'm going to guess
that you have a puis-enabled drive and assume this isn't an irq issue.  it could be that,
but that's a lower probability.  earlier versions of the ahci driver didn't support
puis because puis wasn't around back then.  among its anti-social features, puis
allows the return of identify device to be incomplete, requiring one know the magic
interoccular tap to rise said drive out of its slumber.  it might be that you can jumper
your drive so it doesn't puis.  read the manual.  if you don't know, send along the
model / serial #, and it's not too hard to look up.

- erik

Re: [9fans] 'no fat' - boot failure

[Ethan Grammatikidis]

On Sun, 13 May 2012 18:22:02 -0600
Burton Samograd <burton.samograd@gmail.com> wrote:

> > 9bootfat does its search by walking all partition table
> > entries (primary and secondary) on the bootdrive that
> > are marked as "active".
>
> Reading the grub docs, it sounds like an active partition is marked
> bootable and only one partition can be marked that way.  Currently my
> linux partition is marked bootable but I'm not sure if it needs to be
> since grub is installed in the MBR.  Any thoughts?  I might just try to
> set my plan9 partition bootable and see what happens; I'm sure i can fix
> things if I can't boot later.

The active flag is quite irrelevant to Linux. I'm surprised 9bootfat
uses it.

Re: [9fans] 'no fat' - boot failure

[cinap_lenrek]

if hes using 9front, then eriks ahci driver should support
puis. there also should have been different diagnostic prints
when it failed to spinup looking at ahciidentify().

so looks like jammed interrupt problem? is the cdrom also sata
or is it ide?

what puzzles me is that you said it booted fine from the
live cd. the kernels are identical on the cd and what gets
installed. you can even boot into a installed system
using the livecd. did you managed to install it to the
harddrive from the livecd?

did you had no harddrives attached to sata when trying
the livecd?

maybe the bios leaves the sata drives in some unusable
state (only) when booting from harddrive?

really would like to see answers to these questions.

--
cinap

Re: [9fans] 'no fat' - boot failure

[Burton Samograd]

> so looks like jammed interrupt problem?

It was an MP problem.  I had commented out *nomp=1 in my plan9.ini
and after I tried to boot again and saw a number of errors with
mpintreenable and intreenable I put it back in and it booted correctly.
So no MP for this machine for now.

Of course I screwed up the secstore part of the boot sequence by giving
a non-existant (yet) username so I'll have to figure out how to invalidate
the nvram again or reinstall.

--
Burton Samograd

Re: [9fans] 'no fat' - boot failure

[sl]

> It was an MP problem.  I had commented out *nomp=1 in my plan9.ini
> and after I tried to boot again and saw a number of errors with
> mpintreenable and intreenable I put it back in and it booted correctly.
> So no MP for this machine for now.

Can you try getting rid of *nomp=1 and setting *msi=1

On the Thinkpad T61, the hard drive is sometimes not detected on the
first attempt. After thirty seconds or so it usually succeeds and
boots as normal.

-sl

Re: [9fans] 'no fat' - boot failure

[erik quanstrom]

> maybe the bios leaves the sata drives in some unusable
> state (only) when booting from harddrive?

i don't see how.  controller reset should comreset the drives.
it's almost got to be an interrupt issue.

- erik

Re: [9fans] 'no fat' - boot failure

[erik quanstrom]

> Can you try getting rid of *nomp=1 and setting *msi=1
>
> On the Thinkpad T61, the hard drive is sometimes not detected on the
> first attempt. After thirty seconds or so it usually succeeds and
> boots as normal.

have you done any debugging of this?  that sounds like a condition i haven't
observed.

- erik

Re: [9fans] 'no fat' - boot failure

[Burton Samograd]

On Mon, May 14, 2012 at 8:05 PM,  <sl@9front.org> wrote:
>> It was an MP problem.  I had commented out *nomp=1 in my plan9.ini
>> and after I tried to boot again and saw a number of errors with
>> mpintreenable and intreenable I put it back in and it booted correctly.
>> So no MP for this machine for now.
>
> Can you try getting rid of *nomp=1 and setting *msi=1
>

I tried removing *nomp and adding *msi and got similar errors,
but with ioapicenable and mpreenable.  The disks got recognized
a lot faster this time, which was better, but my keyboard didn't work :-/
I can't really capture the full output as a lot of it scrolls off the screen
 but I can write a more detailed description if anybody is interested.

--
Burton Samograd

Re: [9fans] 'no fat' - boot failure

[Burton Samograd]

On Mon, May 14, 2012 at 8:36 PM, Burton Samograd
<burton.samograd@gmail.com> wrote:
>>> So no MP for this machine for now.

Here's some relevant output of linux dmesg regarding MP on my machine:

[    0.000000] found SMP MP-table at [ffff8800000fe200] fe200
[    0.000000] initial memory mapped : 0 - 20000000
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 20480
[    0.000000] init_memory_mapping: 0000000000000000-00000000cfc00000
[    0.000000]  0000000000 - 00cfc00000 page 2M
[    0.000000] kernel direct mapping tables up to cfc00000 @ cfb8d000-cfb92000
[    0.000000] init_memory_mapping: 0000000100000000-000000022c000000
[    0.000000]  0100000000 - 022c000000 page 2M
[    0.000000] kernel direct mapping tables up to 22c000000 @
22bff6000-22c000000

[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000
[    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 40
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 00000000ce7db000 - 00000000ce89e000
[    0.000000] PM: Registered nosave memory: 00000000cfa9c000 - 00000000cfa9e000
[    0.000000] PM: Registered nosave memory: 00000000cfb92000 - 00000000cfb9d000
[    0.000000] PM: Registered nosave memory: 00000000cfb9d000 - 00000000cfba0000
[    0.000000] PM: Registered nosave memory: 00000000cfba0000 - 00000000cfbea000
[    0.000000] PM: Registered nosave memory: 00000000cfbea000 - 00000000cfbf2000
[    0.000000] PM: Registered nosave memory: 00000000cfbf3000 - 00000000cfbff000
[    0.000000] PM: Registered nosave memory: 00000000cfc00000 - 00000000d0000000
[    0.000000] PM: Registered nosave memory: 00000000d0000000 - 00000000f0000000
[    0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f8000000
[    0.000000] PM: Registered nosave memory: 00000000f8000000 - 00000000fff00000
[    0.000000] PM: Registered nosave memory: 00000000fff00000 - 0000000100000000
[    0.000000] Allocating PCI resources starting at d0000000 (gap:
d0000000:20000000)
[    0.000000] Booting paravirtualized kernel on bare hardware
[    0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256
nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 27 pages/cpu @ffff88022bc00000 s79616
r8192 d22784 u524288
[    0.000000] pcpu-alloc: s79616 r8192 d22784 u524288 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3

--
Burton Samograd

Re: [9fans] 'no fat' - boot failure

[sl]

> > On the Thinkpad T61, the hard drive is sometimes not detected on the
> > first attempt. After thirty seconds or so it usually succeeds and
> > boots as normal.
>
> have you done any debugging of this?  that sounds like a condition i haven't
> observed.

On my Thinkcentre M55 there is actually a BIOS screen that warns of the SATA
drive possibly taking several seconds to spin up, but on that machine, the
drives are always detected on the first pass (perhaps owing to the delay at
the SATA BIOS screen).

On the T61 there is no special BIOS warning. I have not attempted to debug
the problem beyond simply observing what happens when I try to boot the
machine. IIRC there was no such trouble when running in legacy IDE mode.

-sl

Re: [9fans] 'no fat' - boot failure

[sl]

> > Can you try getting rid of *nomp=1 and setting *msi=1
> >
>
> I tried removing *nomp and adding *msi and got similar errors,
> but with ioapicenable and mpreenable.  The disks got recognized
> a lot faster this time, which was better, but my keyboard didn't work :-/
> I can't really capture the full output as a lot of it scrolls off the screen
> but I can write a more detailed description if anybody is interested.

Some combination of *msi=1, *nousbehci=1 and/or *nousbuhci=1 may enable
the SATA drive and USB keyboard simultaneously (especially if your system
is capable of falling back to PS2 keyboard emulation), but in these cases
USB itself has never worked for me. This is all hit or miss; it's a bit
surprising that so many modern mp systems seem to work as well as they do.
Prior to aiju's msi hack, my T61 was not able to use mp and its Ethernet
port at the same time.

By the way, do you happen to know which iso you used for the installation?

-sl

Re: [9fans] 'no fat' - boot failure

[erik quanstrom]

On Mon May 14 22:57:54 EDT 2012, sl@9front.org wrote:
> > > Can you try getting rid of *nomp=1 and setting *msi=1
> > >
> >
> > I tried removing *nomp and adding *msi and got similar errors,
> > but with ioapicenable and mpreenable.  The disks got recognized
> > a lot faster this time, which was better, but my keyboard didn't work :-/
> > I can't really capture the full output as a lot of it scrolls off the screen
> > but I can write a more detailed description if anybody is interested.
>
> Some combination of *msi=1, *nousbehci=1 and/or *nousbuhci=1 may enable
> the SATA drive and USB keyboard simultaneously (especially if your system
> is capable of falling back to PS2 keyboard emulation), but in these cases
> USB itself has never worked for me. This is all hit or miss; it's a bit
> surprising that so many modern mp systems seem to work as well as they do.
> Prior to aiju's msi hack, my T61 was not able to use mp and its Ethernet
> port at the same time.

are you calling msi a hack, or the implementation?

imho, msi interrupts are quite nice.  much better than mp interrupts
through an ioapic.

in any event, i would be interested in a dump of these machine's ioapics and lapics.
one thing that i've found to be a problem with plan 9 is the incorrect
assumption that ioapics and lapics occupy the same apic id space.  this
is not true.  in addition, the mp table seldom has much information.
the acpi tables often need consulting.  the 9atom kernel has support
for all this.  (perhaps bordering on overkill.  :-)) i've included a listing
of an odd machine i have to illustrate the wierd setups some machines have.

- erik

ibmblade; grep -i apic /dev/kmesg
APIC lapic addr 0xfee00000, flags 0x00000001
apic proc 0/0 apicid 0 flags  (mp)
apic proc 1/2 apicid 2 flags
apic proc 2/3 apicid 4 flags
apic proc 3/4 apicid 6 flags
apic proc 4/5 apicid 8 flags
apic proc 5/6 apicid 10 flags
apic proc 6/1 apicid 32 flags  (mp)
apic proc 7/7 apicid 34 flags
apic proc 8/8 apicid 36 flags
apic proc 9/9 apicid 38 flags
apic proc 10/10 apicid 40 flags
apic proc 11/11 apicid 42 flags
apic proc 12/12 apicid 1 flags
apic proc 13/13 apicid 3 flags
apic proc 14/14 apicid 5 flags
apic proc 15/15 apicid 7 flags
apic proc 16/16 apicid 9 flags
apic proc 17/17 apicid 11 flags
apic proc 18/18 apicid 33 flags
apic proc 19/19 apicid 35 flags
apic proc 20/20 apicid 37 flags
apic proc 21/21 apicid 39 flags
apic proc 22/22 apicid 41 flags
apic proc 23/23 apicid 43 flags
ioapic 8 addr fec00000 base 0 (mp)
ioapic 9 addr fec01000 base 24 (mp)
ioapic 10 addr fec40000 base 48 (mp)
apicnos: 00/00 01/01 02/02 03/03 04/04 05/05 06/06 07/07 08/08 09/09 0a/0a 0b/0b 20/20 21/21 22/22 23/23 24/24 25/25 26/26 27/27 28/28 29/29 2a/2a 2b/2b
apic: 24 machs started; phys mode vectors
ibmblade; cat /dev/mpapic
proc            0 00000000 00000000 00000000 be            0
proc            1 01000000 01000000 01000000  e           12
proc            2 02000000 02000000 02000000  e            2
proc            3 03000000 03000000 03000000  e           13
proc            4 04000000 04000000 04000000  e            3
proc            5 05000000 05000000 05000000  e           14
proc            6 06000000 06000000 06000000  e            4
proc            7 07000000 07000000 07000000  e           15
ioapic          8 00000000 00000000 00000000  e            0
proc            8 08000000 08000000 08000000  e            5
ioapic          9 00000000 00000000 00000000  e            0
proc            9 09000000 09000000 09000000  e           16
ioapic          a 00000000 00000000 00000000  e            0
proc            a 0a000000 0a000000 0a000000  e            6
proc            b 0b000000 0b000000 0b000000  e           17
proc           20 20000000 20000000 20000000  e            1
proc           21 21000000 21000000 21000000  e           18
proc           22 22000000 22000000 22000000  e            7
proc           23 23000000 23000000 23000000  e           19
proc           24 24000000 24000000 24000000  e            8
proc           25 25000000 25000000 25000000  e           20
proc           26 26000000 26000000 26000000  e            9
proc           27 27000000 27000000 27000000  e           21
proc           28 28000000 28000000 28000000  e           10
proc           29 29000000 29000000 29000000  e           22
proc           2a 2a000000 2a000000 2a000000  e           11
proc           2b 2b000000 2b000000 2b000000  e           23

Re: [9fans] 'no fat' - boot failure

[erik quanstrom]

> > > On the Thinkpad T61, the hard drive is sometimes not detected on the
> > > first attempt. After thirty seconds or so it usually succeeds and
> > > boots as normal.
> >
> > have you done any debugging of this?  that sounds like a condition i haven't
> > observed.
>
> On my Thinkcentre M55 there is actually a BIOS screen that warns of the SATA
> drive possibly taking several seconds to spin up, but on that machine, the
> drives are always detected on the first pass (perhaps owing to the delay at
> the SATA BIOS screen).
>
> On the T61 there is no special BIOS warning. I have not attempted to debug
> the problem beyond simply observing what happens when I try to boot the
> machine. IIRC there was no such trouble when running in legacy IDE mode.

this does sound a lot like standard spinup.  the firmware running in the sb
probablly spins up drives running in ide emulation.  there's probablly a knob
in bios you can tweak....

- erik

Re: [9fans] 'no fat' - boot failure

[erik quanstrom]

> Here's some relevant output of linux dmesg regarding MP on my machine:
[...]
> [    0.000000] Using ACPI (MADT) for SMP configuration information

i think this is the salient bit.  linux is not using the mp tables.  it's using acpi.

- erik

Re: [9fans] 'no fat' - boot failure

[erik quanstrom]

> I tried removing *nomp and adding *msi and got similar errors,
> but with ioapicenable and mpreenable.  The disks got recognized
> a lot faster this time, which was better, but my keyboard didn't work :-/
> I can't really capture the full output as a lot of it scrolls off the screen
>  but I can write a more detailed description if anybody is interested.

i'd be interested in if a 9atom kernel works on this machine.
(hget http://ftp.quanstro.net/other/9pccd.gz)  unfortunately, i don't
think i can easily boot to a cwfs root file system.

- erik

Re: [9fans] 'no fat' - boot failure

[Burton Samograd]

On Tue, May 15, 2012 at 3:31 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> i'd be interested in if a 9atom kernel works on this machine.
> (hget http://ftp.quanstro.net/other/9pccd.gz)  unfortunately, i don't
> think i can easily boot to a cwfs root file system.

I trued the 9atom kernel and I got similar messages as with the 9front kernel:

ipapicirq: can't find bus type 12
mpintreenable: out of choices eisa -1 isa -1 tbdf 0xc00ea00 irq 11
intreenable: couldn't enable irq 11, tbdf 0xC00EA00 for usbuhci

There are approximately 8 or more outputs similar to above for
different subsystems
including ahci.  Also, the keyboard again didn't work, which is a PS2
keyboard/mouse
combo.  I couldn't get past the fs prompt due to this.

--
Burton Samograd

Re: [9fans] 'no fat' - boot failure

[Burton Samograd]

In any case my T61 should be showing up today or tomorrow so I'll
have dedicated computer for my plan9 experiments.  Hopefully that
will work better as it was recommended by some others on the list.

Eric, I noticed you have a blade server which I would guess means
they work with plan9.  I was looking at them yesterday; are there
particular models that work well/at all?

--
Burton Samograd

Re: [9fans] 'no fat' - boot failure

[erik quanstrom]

On Tue May 15 08:20:29 EDT 2012, burton.samograd@gmail.com wrote:
> On Tue, May 15, 2012 at 3:31 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> > i'd be interested in if a 9atom kernel works on this machine.
> > (hget http://ftp.quanstro.net/other/9pccd.gz)  unfortunately, i don't
> > think i can easily boot to a cwfs root file system.
> 
> I trued the 9atom kernel and I got similar messages as with the 9front kernel:
> 
> ipapicirq: can't find bus type 12
> mpintreenable: out of choices eisa -1 isa -1 tbdf 0xc00ea00 irq 11
> intreenable: couldn't enable irq 11, tbdf 0xC00EA00 for usbuhci
> 
> There are approximately 8 or more outputs similar to above for
> different subsystems
> including ahci.  Also, the keyboard again didn't work, which is a PS2
> keyboard/mouse
> combo.  I couldn't get past the fs prompt due to this.

seems pretty clear that your mp table is junk.  too bad.

- erik

Re: [9fans] 'no fat' - boot failure

[erik quanstrom]

> Eric, I noticed you have a blade server which I would guess means
> they work with plan9.  I was looking at them yesterday; are there
> particular models that work well/at all?

the hs23 does work with the intel 82599 or myricom 10gbe mezzanine
cards.  no emulex support at this time.

i have had plan 9 running on recent hp3000/hp7000/dell and ibm
blade systems.  just be careful of the nic.  etherbcm doesn't support
the "s" model nic found in blades.  also be aware that there's no
direct support for the lsi mpt disk controllers.

- erik

Re: [9fans] 'no fat' - boot failure

[Burton Samograd]

> seems pretty clear that your mp table is junk.  too bad.

Ironic given I bought an Intel MB to keep from having problems like this.

--
Burton Samograd

This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page? for contact information on our offices worldwide.

Re: [9fans] 'no fat' - boot failure

[erik quanstrom]

On Tue May 15 10:14:38 EDT 2012, burton.samograd@markit.com wrote:
>
> > seems pretty clear that your mp table is junk.  too bad.
>
> Ironic given I bought an Intel MB to keep from having problems like this.

intel generally doesn't provide complete mp tables.

- erik

Re: [9fans] 'no fat' - boot failure

[cinap_lenrek]

should add irq type and interrupt counts to a arch file like
erik did in 9atom. but for now, some awk did the trick.

theres the mp table from sl's t61. (sorry for the raw nature of
this dump)

processor: 00 00 14 03 FB 06 00 00 FF FB EB BF 00 00 00 00 00 00 00 00
processor: 00 01 14 01 FB 06 00 00 FF FB EB BF 00 00 00 00 00 00 00 00
bus: 01 00 50 43 49 20 20 20 (PCI.0)
bus: 01 03 50 43 49 20 20 20 (PCI.3)
bus: 01 15 50 43 49 20 20 20 (PCI.21)
bus: 01 16 49 53 41 20 20 20 (ISA.22)
ioapic: 02 02 20 01 00 00 C0 FE (ioapic 2 @ FEC00000)
iointr: 03 03 05 00 16 00 02 00 (Ext, ISA.22, irq0, ioapic 2 @ intin0)
iointr: 03 00 05 00 16 01 02 01 (Int, ISA.22, irq1, ioapic 2 @ intin1)
iointr: 03 00 05 00 16 00 02 02 (Int, ISA.22, irq0, ioapic 2 @ intin2)
iointr: 03 00 05 00 16 03 02 03 (Int, ISA.22, irq3, ioapic 2 @ intin3)
iointr: 03 00 05 00 16 04 02 04 (Int, ISA.22, irq4, ioapic 2 @ intin4)
iointr: 03 00 05 00 16 05 02 05 (Int, ISA.22, irq5, ioapic 2 @ intin5)
iointr: 03 00 05 00 16 06 02 06 .....
iointr: 03 00 05 00 16 07 02 07
iointr: 03 00 05 00 16 08 02 08
iointr: 03 00 05 00 16 09 02 09
iointr: 03 00 05 00 16 0A 02 0A
iointr: 03 00 05 00 16 0B 02 0B
iointr: 03 00 05 00 16 0C 02 0C
iointr: 03 00 05 00 16 0D 02 0D
iointr: 03 00 05 00 16 0E 02 0E
iointr: 03 00 05 00 16 0F 02 0F
lintr: 04 03 05 00 16 00 FF 00
lintr: 04 01 05 00 16 00 FF 01

as i said before, this mp table of this machine identity maps
all irq's to isa interrupts wich are edge triggered. mpintrenablex()
code refused to share edge triggered interrupts causing half the usb
controllers not receiving ther irq's in mp mode.

if we allow sharing these edge triggered interrupts, then usb starts
working. (but it might miss interrupts from time to time)

this change is commited in the repository, but havnt build a new iso yet.

to get the real pci irq mapping one would need to implement acpi
interpreter. :(

--
cinap

Re: [9fans] 'no fat' - boot failure

[erik quanstrom]

> as i said before, this mp table of this machine identity maps
> all irq's to isa interrupts wich are edge triggered. mpintrenablex()
> code refused to share edge triggered interrupts causing half the usb
> controllers not receiving ther irq's in mp mode.

that's probablly just wrong.  have you tried interpreting these
as level?  they're going through an ioapic.  one generally expects
them to do level interrupt emulation.

- erik

Re: [9fans] 'no fat' - boot failure

[cinap_lenrek]

no. the i/o apics are programmed like before as specified in the iointr
entry from the mp table. i have no way differentiating if this is a
real isa bus or some compatibilty hack or just plain wrong mp table.

i looked in openbsd code and just figured they allow sharing edge
interrupts so i just removed the level check.

Each I/O APIC is assigned a base GSI by the BIOS. Each input pin on the
I/O APIC is mapped to a GSI number by adding the pin number (zero-based)
to the base GSI. Thus, if an I/O APIC has a base GSI of N, pin 0 on that
I/O APIC has a GSI of N, pin 1 has a GSI of N + 1, etc. The I/O APIC with
a base GSI of 0 maps the ISA IRQs onto its first 16 input pins. Thus, the
ISA IRQs are effectively always mapped 1:1 onto GSIs. More details about
GSIs can be found in Section 5.2.11 of the ACPI 2.0c spec [2].

looking at a random linux dmesg of a T61 from the web, i see that our
ioapic indeed has GSI base of 0. so ioapic pins 0-15 are the (fake)
isa irq's like they are specified in the mptable.

term% grep -in GSI /tmp/dmesg
108: [    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
109: [    0.000000] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
118: [    0.000000] nr_irqs_gsi: 40
611: [    0.575784] pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
613: [    0.575796] pci 0000:00:1c.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
615: [    0.575810] pci 0000:00:1c.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21
617: [    0.575824] pci 0000:00:1c.2: PCI INT C -> GSI 22 (level, low) -> IRQ 22
619: [    0.575838] pci 0000:00:1c.3: PCI INT D -> GSI 23 (level, low) -> IRQ 23
621: [    0.575850] pci 0000:00:1c.4: PCI INT A -> GSI 20 (level, low) -> IRQ 20
625: [    0.575875] pci 0000:15:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
730: [    1.010177] serial 0000:00:03.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17
738: [    1.032435] ata_piix 0000:00:1f.1: PCI INT C -> GSI 16 (level, low) -> IRQ 16
745: [    1.033155] pata_acpi 0000:00:03.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
749: [    1.033236] ata_generic 0000:00:03.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
762: [    1.034141] ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 22 (level, low) -> IRQ 22
773: [    1.090199] ehci_hcd 0000:00:1d.7: PCI INT D -> GSI 19 (level, low) -> IRQ 19
785: [    1.160231] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
794: [    1.160507] uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21
803: [    1.160783] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
810: [    1.161055] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
819: [    1.161324] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
866: [    1.507624] sdhci-pci 0000:15:00.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
873: [    1.515999] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
877: [    1.544416] firewire_ohci 0000:15:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
884: [    2.052404] ahci 0000:00:1f.2: PCI INT B -> GSI 16 (level, low) -> IRQ 16
938: [   11.919940] nouveau 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
973: [   12.007486] HDA Intel 0000:00:1b.0: PCI INT B -> GSI 17 (level, low) -> IRQ 17
984: [   12.011732] r852 0000:15:00.5: PCI INT C -> GSI 18 (level, low) -> IRQ 18
1024: [   12.354855] iwl3945 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17

so this would give the following mapping for pci devices to the
ioapic intrin pins:

bus	dev	INTP	dev*4+(INTP-1)	intrin
0	1	1	4		16
0	3	2	13		17
0	3	3	14		18
0	25	1	100		20
0	26	1	104		20
0	26	2	105		21
0	26	3	106		22
0	28	1	112		20
0	28	2	113		21
0	28	3	114		22
0	28	4	115		23
0	29	1	116		16
0	29	2	117		17
0	29	3	118		18
0	29	4	119		19
0	31	2	125		16
0	31	3	126		16
1	0	1	0		16
3	0	1	0		17
21	0	1	0		16
21	0	2	1		17
21	0	3	2		18

could generate a new mp table from this mapping. 9front kernel
lets you override the mp table. will try this...

--
cinap

Re: [9fans] 'no fat' - boot failure

[cinap_lenrek]

wrote a awk script that generate iointr mp table
entries from linux dmesg output.

i merged the info into the mp table from that T61,
but i got the dmesg from the a random google search
so it might be wrong. someone provide me with a linux
dmesg of that machine?

anyway, theres the mptable override for plan9.ini
if anyone wants to try:

(table is the same up to *mp13=, then i added the
pci iointr entries)

*mp0=00 00 14 03 fb 06 00 00 ff fb eb bf 00 00 00 00
*mp1=00 00 00 00 00 01 14 01 fb 06 00 00 ff fb eb bf
*mp2=00 00 00 00 00 00 00 00 01 00 50 43 49 20 20 20
*mp3=01 03 50 43 49 20 20 20 01 15 50 43 49 20 20 20
*mp4=01 16 49 53 41 20 20 20 02 02 20 01 00 00 c0 fe
*mp5=03 03 05 00 16 00 02 00 03 00 05 00 16 01 02 01
*mp6=03 00 05 00 16 00 02 02 03 00 05 00 16 03 02 03
*mp7=03 00 05 00 16 04 02 04 03 00 05 00 16 05 02 05
*mp8=03 00 05 00 16 06 02 06 03 00 05 00 16 07 02 07
*mp9=03 00 05 00 16 08 02 08 03 00 05 00 16 09 02 09
*mp10=03 00 05 00 16 0a 02 0a 03 00 05 00 16 0b 02 0b
*mp11=03 00 05 00 16 0c 02 0c 03 00 05 00 16 0d 02 0d
*mp12=03 00 05 00 16 0e 02 0e 03 00 05 00 16 0f 02 0f
*mp13=04 03 05 00 16 00 ff 00 04 01 05 00 16 00 ff 01
*mp14=03 00 00 00 00 04 02 10 03 00 00 00 00 0D 02 11
*mp15=03 00 00 00 00 0E 02 12 03 00 00 00 00 64 02 14
*mp16=03 00 00 00 00 68 02 14 03 00 00 00 00 69 02 15
*mp17=03 00 00 00 00 6A 02 16 03 00 00 00 00 6D 02 11
*mp18=03 00 00 00 00 70 02 14 03 00 00 00 00 71 02 15
*mp19=03 00 00 00 00 72 02 16 03 00 00 00 00 73 02 17
*mp20=03 00 00 00 00 74 02 10 03 00 00 00 00 75 02 11
*mp21=03 00 00 00 00 76 02 12 03 00 00 00 00 77 02 13
*mp22=03 00 00 00 00 7D 02 10 03 00 00 00 00 7E 02 10
*mp23=03 00 00 00 03 00 02 11 03 00 00 00 15 00 02 10
*mp24=03 00 00 00 15 01 02 11 03 00 00 00 15 02 02 12
*mp=400

--
cinap

Re: [9fans] 'no fat' - boot failure

[Burton Samograd]

> i merged the info into the mp table from that T61, but
> i got the dmesg from the a random google search so it
> might be wrong. someone provide me with a linux dmesg
> of that machine?

I should be getting my T61 tonite so I can provide the output
for you in case nobody responds before then.

--
Burton Samograd


This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page? for contact information on our offices worldwide.

Re: [9fans] 'no fat' - boot failure

[cinap_lenrek]

excellent, thanks.

- boot linux, save dmesg.
- boot 9front with *dumpmp= option, then save /dev/kmesg output.

--
cinap

Re: [9fans] 'no fat' - boot failure

[cinap_lenrek]

the *mp=400 line should be on the top right before *mp0= ... sorry
about that. (9boot quirk :-))

--
cinap

Re: [9fans] 'no fat' - boot failure

[sl]

> the *mp=400 line should be on the top right before *mp0= ... sorry
> about that. (9boot quirk :-))

Works on my T61.

-sl