[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

[c***@gmx.de]

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

[Burton Samograd]

Post by c***@gmx.de
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

[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

Post by Burton Samograd

Post by c***@gmx.de
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

[erik quanstrom]

Post by Burton Samograd
Toggling the bootable flag on the plan9 partition did allow it to start booting.
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

[Burton Samograd]

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

Post by erik quanstrom

Post by Burton Samograd
Toggling the bootable flag on the plan9 partition did allow it to start booting.
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

[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

[c***@gmx.de]

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

[Burton Samograd]

Post by c***@gmx.de
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

[s***@9front.org]

Post by Burton Samograd
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

[erik quanstrom]

Post by s***@9front.org
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

[s***@9front.org]

Post by erik quanstrom

Post by s***@9front.org
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

[erik quanstrom]

Post by s***@9front.org

Post by erik quanstrom

Post by s***@9front.org
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

[Burton Samograd]

Post by s***@9front.org

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

[Burton Samograd]

On Mon, May 14, 2012 at 8:36 PM, Burton Samograd

Post by Burton Samograd
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

[s***@9front.org]

Post by Burton Samograd

Post by s***@9front.org
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

[erik quanstrom]

Post by s***@9front.org

Post by Burton Samograd

Post by s***@9front.org
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

[c***@gmx.de]

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

[erik quanstrom]

Post by c***@gmx.de
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

[c***@gmx.de]

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

[c***@gmx.de]

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

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

[c***@gmx.de]

excellent, thanks.

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

--
cinap

[c***@gmx.de]

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

--
cinap

[s***@9front.org]

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

Works on my T61.

-sl

[erik quanstrom]

[...]

Post by Burton Samograd
[ 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

[erik quanstrom]

Post by Burton Samograd
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

[Burton Samograd]

Post by erik quanstrom
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

[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

[erik quanstrom]

Post by Burton Samograd
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

[erik quanstrom]

Post by Burton Samograd

Post by erik quanstrom
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.

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

[Burton Samograd]

Post by erik quanstrom
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.

[erik quanstrom]

Post by Burton Samograd

Post by erik quanstrom
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

[erik quanstrom]

Post by c***@gmx.de
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

[Ethan Grammatikidis]

On Sun, 13 May 2012 18:22:02 -0600

Post by Burton Samograd

Post by c***@gmx.de
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.