Re: [9fans] 'no fat' - boot failure
On Mon May 14 22:57:54 EDT 2012, s...@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 0xfee0, flags 0x0001 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 fec0 base 0 (mp) ioapic 9 addr fec01000 base 24 (mp) ioapic 10 addr fec4 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 proc0 be0 proc1 0100 0100 0100 e 12 proc2 0200 0200 0200 e2 proc3 0300 0300 0300 e 13 proc4 0400 0400 0400 e3 proc5 0500 0500 0500 e 14 proc6 0600 0600 0600 e4 proc7 0700 0700 0700 e 15 ioapic 8 e0 proc8 0800 0800 0800 e5 ioapic 9 e0 proc9 0900 0900 0900 e 16 ioapic a e0 proca 0a00 0a00 0a00 e6 procb 0b00 0b00 0b00 e 17 proc 20 2000 2000 2000 e1 proc 21 2100 2100 2100 e 18 proc 22 2200 2200 2200 e7 proc 23 2300 2300 2300 e 19 proc 24 2400 2400 2400 e8 proc 25 2500 2500 2500 e 20 proc 26 2600 2600 2600 e9 proc 27 2700 2700 2700 e 21 proc 28 2800 2800 2800 e 10 proc 29 2900 2900 2900 e 22 proc 2a 2a00 2a00 2a00 e 11 proc 2b 2b00 2b00 2b00 e 23
Re: [9fans] 'no fat' - boot failure
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
Here's some relevant output of linux dmesg regarding MP on my machine: [...] [0.00] 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
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
On Tue, May 15, 2012 at 3:31 AM, erik quanstrom quans...@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
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
On Tue May 15 08:20:29 EDT 2012, burton.samog...@gmail.com wrote: On Tue, May 15, 2012 at 3:31 AM, erik quanstrom quans...@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
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
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
On Tue May 15 10:14:38 EDT 2012, burton.samog...@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
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 @ FEC0) 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
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
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.00] ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) 109: [0.00] IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23 118: [0.00] nr_irqs_gsi: 40 611: [0.575784] pci :00:01.0: PCI INT A - GSI 16 (level, low) - IRQ 16 613: [0.575796] pci :00:1c.0: PCI INT A - GSI 20 (level, low) - IRQ 20 615: [0.575810] pci :00:1c.1: PCI INT B - GSI 21 (level, low) - IRQ 21 617: [0.575824] pci :00:1c.2: PCI INT C - GSI 22 (level, low) - IRQ 22 619: [0.575838] pci :00:1c.3: PCI INT D - GSI 23 (level, low) - IRQ 23 621: [0.575850] pci :00:1c.4: PCI INT A - GSI 20 (level, low) - IRQ 20 625: [0.575875] pci :15:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 730: [1.010177] serial :00:03.3: PCI INT B - GSI 17 (level, low) - IRQ 17 738: [1.032435] ata_piix :00:1f.1: PCI INT C - GSI 16 (level, low) - IRQ 16 745: [1.033155] pata_acpi :00:03.2: PCI INT C - GSI 18 (level, low) - IRQ 18 749: [1.033236] ata_generic :00:03.2: PCI INT C - GSI 18 (level, low) - IRQ 18 762: [1.034141] ehci_hcd :00:1a.7: PCI INT C - GSI 22 (level, low) - IRQ 22 773: [1.090199] ehci_hcd :00:1d.7: PCI INT D - GSI 19 (level, low) - IRQ 19 785: [1.160231] uhci_hcd :00:1a.0: PCI INT A - GSI 20 (level, low) - IRQ 20 794: [1.160507] uhci_hcd :00:1a.1: PCI INT B - GSI 21 (level, low) - IRQ 21 803: [1.160783] uhci_hcd :00:1d.0: PCI INT A - GSI 16 (level, low) - IRQ 16 810: [1.161055] uhci_hcd :00:1d.1: PCI INT B - GSI 17 (level, low) - IRQ 17 819: [1.161324] uhci_hcd :00:1d.2: PCI INT C - GSI 18 (level, low) - IRQ 18 866: [1.507624] sdhci-pci :15:00.2: PCI INT C - GSI 18 (level, low) - IRQ 18 873: [1.515999] e1000e :00:19.0: PCI INT A - GSI 20 (level, low) - IRQ 20 877: [1.544416] firewire_ohci :15:00.1: PCI INT B - GSI 17 (level, low) - IRQ 17 884: [2.052404] ahci :00:1f.2: PCI INT B - GSI 16 (level, low) - IRQ 16 938: [ 11.919940] nouveau :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 973: [ 12.007486] HDA Intel :00:1b.0: PCI INT B - GSI 17 (level, low) - IRQ 17 984: [ 12.011732] r852 :15:00.5: PCI INT C - GSI 18 (level, low) - IRQ 18 1024: [ 12.354855] iwl3945 :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 INTPdev*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
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
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
excellent, thanks. - boot linux, save dmesg. - boot 9front with *dumpmp= option, then save /dev/kmesg output. -- cinap
Re: [9fans] 'no fat' - boot failure
the *mp=400 line should be on the top right before *mp0= ... sorry about that. (9boot quirk :-)) -- cinap
Re: [9fans] 'no fat' - boot failure
the *mp=400 line should be on the top right before *mp0= ... sorry about that. (9boot quirk :-)) Works on my T61. -sl
Re: [9fans] 'no fat' - boot failure
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
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
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
On Mon, May 14, 2012 at 8:05 PM, s...@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
On Mon, May 14, 2012 at 8:36 PM, Burton Samograd burton.samog...@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.00] found SMP MP-table at [880fe200] fe200 [0.00] initial memory mapped : 0 - 2000 [0.00] Base memory trampoline at [88099000] 99000 size 20480 [0.00] init_memory_mapping: -cfc0 [0.00] 00 - 00cfc0 page 2M [0.00] kernel direct mapping tables up to cfc0 @ cfb8d000-cfb92000 [0.00] init_memory_mapping: 0001-00022c00 [0.00] 01 - 022c00 page 2M [0.00] kernel direct mapping tables up to 22c00 @ 22bff6000-22c00 [0.00] Using ACPI (MADT) for SMP configuration information [0.00] ACPI: HPET id: 0x8086a301 base: 0xfed0 [0.00] SMP: Allowing 4 CPUs, 0 hotplug CPUs [0.00] nr_irqs_gsi: 40 [0.00] PM: Registered nosave memory: 0009e000 - 000a [0.00] PM: Registered nosave memory: 000a - 000e [0.00] PM: Registered nosave memory: 000e - 0010 [0.00] PM: Registered nosave memory: ce7db000 - ce89e000 [0.00] PM: Registered nosave memory: cfa9c000 - cfa9e000 [0.00] PM: Registered nosave memory: cfb92000 - cfb9d000 [0.00] PM: Registered nosave memory: cfb9d000 - cfba [0.00] PM: Registered nosave memory: cfba - cfbea000 [0.00] PM: Registered nosave memory: cfbea000 - cfbf2000 [0.00] PM: Registered nosave memory: cfbf3000 - cfbff000 [0.00] PM: Registered nosave memory: cfc0 - d000 [0.00] PM: Registered nosave memory: d000 - f000 [0.00] PM: Registered nosave memory: f000 - f800 [0.00] PM: Registered nosave memory: f800 - fff0 [0.00] PM: Registered nosave memory: fff0 - 0001 [0.00] Allocating PCI resources starting at d000 (gap: d000:2000) [0.00] Booting paravirtualized kernel on bare hardware [0.00] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:4 nr_node_ids:1 [0.00] PERCPU: Embedded 27 pages/cpu @88022bc0 s79616 r8192 d22784 u524288 [0.00] pcpu-alloc: s79616 r8192 d22784 u524288 alloc=1*2097152 [0.00] pcpu-alloc: [0] 0 1 2 3 -- Burton Samograd
Re: [9fans] 'no fat' - boot failure
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
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
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
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
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.samog...@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
On Sun May 13 21:20:40 EDT 2012, burton.samog...@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
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 quans...@quanstro.net wrote: On Sun May 13 21:20:40 EDT 2012, burton.samog...@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 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
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
On Sun, 13 May 2012 18:22:02 -0600 Burton Samograd burton.samog...@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.
