Mailing List Archive: Linux: Kernel

Re: mptsas, msi and the dl585 g2

Index | Next | Previous | View Threaded

yinghai at kernel

Jul 4, 2009, 12:30 PM

Post #1 of 8 (206 views)
Permalink

Re: mptsas, msi and the dl585 g2

dann frazier wrote:
> On Tue, Jun 30, 2009 at 11:35:45AM -0700, Yinghai Lu wrote:
>> dann frazier wrote:
>>> hey,
>>> I'm finding problems when booting a dl585g2 w/ an LSISAS1068
>>> controller. In brief, this system system stopped booting once MSI
>>> became disabled by default in mptbase. Passing the parameter
>>> 'mpt_msi_enable_sas=1' to mptbase allows it to work again (tested w/
>>> 2.6.30).
>>>
>>> The symptom is that the system starts up, and we see the following:
>>>
>>> ======== SNIP =========
>>> [ 6.941489] hub 3-2:1.0: USB hub found
>>> [ 6.943705] hub 3-2:1.0: 7 ports detected
>>> [ 6.992639] Copyright (c) 1999-2008 LSI Corporation
>>> [ 7.014262] Fusion MPT SAS Host driver 3.04.07
>>> [ 7.021685] mptsas 0000:42:01.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24
>>> [ 7.026597] usb 1-6.3: new full speed USB device using ehci_hcd and address 3
>>> [ 7.071143] mptbase: ioc0: Initiating bringup
>>> [ 7.102198] usb 1-6.3: New USB device found, idVendor=0e34, idProduct=0204
>>> [ 7.119107] usb 1-6.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
>>> [ 7.128171] usb 1-6.3: Product: iPort/USB I2C Host Adapter
>>> [ 7.160994] usb 1-6.3: Manufacturer: Silicon Labs
>>> [ 7.171468] usb 1-6.3: SerialNumber: 0001248
>>> [ 7.174931] usb 1-6.3: configuration #1 chosen from 1 choice
>>> [ 7.360010] ioc0: LSISAS1068 B0: Capabilities={Initiator}
>>> [ 40.581020] mptbase: ioc0: Initiating recovery
>>> [ 71.190560] Clocksource tsc unstable (delta = 4398041105588 ns)
>>> [ 81.190160] mptbase: ioc0: Initiating recovery
>>> ======== SNIP =========
>>>
>>> These "Initiating recovery" messages are printed periodically, and the
>>> system never recovers.
>> Dann, that could be : ioapic routing in ACPI DSDT is not right somehow.
>>
>> please try to move the card to other slot to get some luck.
>> or pci=routeirq could help too sometimes.
>
> For the record, I tried moving the card to the other PCI-X slot and
> the pci=routeirq boot param, but neither helped.
>

so 2.6.22.1 works on that system with pci=nomsi?

maybe your BIOS is too new, you may try the old BIOS.

updating BIOS is not always a option to deployed systems. maybe sustaining team could break sth.

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

dannf at hp

Jul 6, 2009, 9:57 AM

Post #2 of 8 (173 views)
Permalink

Re: mptsas, msi and the dl585 g2 [In reply to]

dannf at hp

Jul 9, 2009, 11:59 AM

Post #3 of 8 (166 views)
Permalink

Re: mptsas, msi and the dl585 g2 [In reply to]

On Sat, Jul 04, 2009 at 12:30:36PM -0700, Yinghai Lu wrote:
> dann frazier wrote:
> > On Tue, Jun 30, 2009 at 11:35:45AM -0700, Yinghai Lu wrote:
> >> dann frazier wrote:
> >>> hey,
> >>> I'm finding problems when booting a dl585g2 w/ an LSISAS1068
> >>> controller. In brief, this system system stopped booting once MSI
> >>> became disabled by default in mptbase. Passing the parameter
> >>> 'mpt_msi_enable_sas=1' to mptbase allows it to work again (tested w/
> >>> 2.6.30).
> >>>
> >>> The symptom is that the system starts up, and we see the following:
> >>>
> >>> ======== SNIP =========
> >>> [ 6.941489] hub 3-2:1.0: USB hub found
> >>> [ 6.943705] hub 3-2:1.0: 7 ports detected
> >>> [ 6.992639] Copyright (c) 1999-2008 LSI Corporation
> >>> [ 7.014262] Fusion MPT SAS Host driver 3.04.07
> >>> [ 7.021685] mptsas 0000:42:01.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24
> >>> [ 7.026597] usb 1-6.3: new full speed USB device using ehci_hcd and address 3
> >>> [ 7.071143] mptbase: ioc0: Initiating bringup
> >>> [ 7.102198] usb 1-6.3: New USB device found, idVendor=0e34, idProduct=0204
> >>> [ 7.119107] usb 1-6.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> >>> [ 7.128171] usb 1-6.3: Product: iPort/USB I2C Host Adapter
> >>> [ 7.160994] usb 1-6.3: Manufacturer: Silicon Labs
> >>> [ 7.171468] usb 1-6.3: SerialNumber: 0001248
> >>> [ 7.174931] usb 1-6.3: configuration #1 chosen from 1 choice
> >>> [ 7.360010] ioc0: LSISAS1068 B0: Capabilities={Initiator}
> >>> [ 40.581020] mptbase: ioc0: Initiating recovery
> >>> [ 71.190560] Clocksource tsc unstable (delta = 4398041105588 ns)
> >>> [ 81.190160] mptbase: ioc0: Initiating recovery
> >>> ======== SNIP =========
> >>>
> >>> These "Initiating recovery" messages are printed periodically, and the
> >>> system never recovers.
> >> Dann, that could be : ioapic routing in ACPI DSDT is not right somehow.
> >>
> >> please try to move the card to other slot to get some luck.
> >> or pci=routeirq could help too sometimes.
> >
> > For the record, I tried moving the card to the other PCI-X slot and
> > the pci=routeirq boot param, but neither helped.
> >
>
> so 2.6.22.1 works on that system with pci=nomsi?
>
> maybe your BIOS is too new, you may try the old BIOS.
>
> updating BIOS is not always a option to deployed systems. maybe sustaining team could break sth.

Back with more info.

Both of the original bisects I did with cciss and mptsas appeared to
land on commits that just masked the issue. e.g., a cciss hang caused
by a bug w/ no logical drives, and mptsas switching toggling the MSI
default.

I tried to avoid these issues by doing another bisect w/ storage
attached to the cciss controller, and landed on this commit:

--------------------------------------------------------------------
commit 8d539108560ec121d59eee05160236488266221c
Author: Linus Torvalds <torvalds[at]linux-foundation.org>
Date: Thu May 8 18:41:48 2008 -0700

Revert "PCI: remove default PCI expansion ROM memory allocation"

This reverts commit 9f8daccaa05c14e5643bdd4faf5aed9cc8e6f11e, which
was reported to break X startup (xf86-video-ati-6.8.0).
--------------------------------------------------------------------

From that, I found that pci=norom avoids the problem. But, again, this
is just a masking commit - things used to work before 9f8dacc was
there.

I did another bisect, this time keeping the norom patches out
entirely. This landed on:

--------------------------------------------------------------------
commit 30a18d6c3f1e774de656ebd8ff219d53e2ba4029
Author: Yinghai Lu <Yinghai.Lu[at]Sun.COM>
Date: Tue Feb 19 03:21:20 2008 -0800

x86: multi pci root bus with different io resource range, on
64-bit
--------------------------------------------------------------------

This appears to be the commit that actually introduced the issue.
I've attached dmesg w/ PCI DEBUG enabled from both sides of this
changeset, as well as a diff w/o printk timestamps.

Also note that #ifdef'ing out x86_pci_root_bus_res_quirks() in
amd_bus.c seems to avoid the problem as well.

--
dann frazier

Attachments:

pre.dmesg (79.6 KB)

post.dmesg (80.2 KB)

dmesg.diff (15.7 KB)

yinghai at kernel

Jul 9, 2009, 12:17 PM

Post #4 of 8 (167 views)
Permalink

Re: mptsas, msi and the dl585 g2 [In reply to]

dann frazier wrote:
>
> --------------------------------------------------------------------
> commit 30a18d6c3f1e774de656ebd8ff219d53e2ba4029
> Author: Yinghai Lu <Yinghai.Lu[at]Sun.COM>
> Date: Tue Feb 19 03:21:20 2008 -0800
>
> x86: multi pci root bus with different io resource range, on
> 64-bit
> --------------------------------------------------------------------
>
> This appears to be the commit that actually introduced the issue.
> I've attached dmesg w/ PCI DEBUG enabled from both sides of this
> changeset, as well as a diff w/o printk timestamps.
>
> Also note that #ifdef'ing out x86_pci_root_bus_res_quirks() in
> amd_bus.c seems to avoid the problem as well.

your BIOS didn't allocate io resources to some device under HT chain on node1/link2
aka under peer root bus.

Kernel try to allocate resource to them.

and the patch did right thing according to range
bus: 40 index 1 mmio: [d9f00000, dfefffff]

YH

+bus: [00,3f] on node 0 link 1
+bus: 00 index 0 io port: [0, 2fff]
+bus: 00 index 1 mmio: [80000000, d9efffff]
+bus: 00 index 2 mmio: [dff00000, e3ffffff]
+bus: 00 index 3 mmio: [a0000, bffff]
+bus: 00 index 4 mmio: [e8000000, ffffffff]
+bus: 00 index 5 mmio: [480000000, fbffffffff]
+bus: [40,7f] on node 1 link 2
+bus: 40 index 0 io port: [3000, ffff]
+bus: 40 index 1 mmio: [d9f00000, dfefffff]
+bus: 40 index 2 mmio: [e4000000, e7ffffff]
ACPI: bus type pci registered
PCI: Using configuration type 1 for base access
ACPI: EC: Look up EC in DSDT
@@ -646,18 +659,18 @@
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
- got res [88000000:8801ffff] bus [88000000:8801ffff] flags 27200 for BAR 6 of 0000:41:01.0
- got res [88020000:8803ffff] bus [88020000:8803ffff] flags 27200 for BAR 6 of 0000:41:02.0
+ got res [d9f00000:d9f1ffff] bus [d9f00000:d9f1ffff] flags 27200 for BAR 6 of 0000:41:01.0
+ got res [d9f20000:d9f3ffff] bus [d9f20000:d9f3ffff] flags 27200 for BAR 6 of 0000:41:02.0
PCI: Bridge: 0000:40:10.0
IO window: disabled.
MEM window: 0xda000000-0xddffffff
- PREFETCH window: 0x0000000088000000-0x00000000880fffff
- got res [88200000:883fffff] bus [88200000:883fffff] flags 27200 for BAR 6 of 0000:42:01.0
- got res [88100000:8813ffff] bus [88100000:8813ffff] flags 27200 for BAR 6 of 0000:42:02.0
+ PREFETCH window: 0x00000000d9f00000-0x00000000d9ffffff
+ got res [de000000:de1fffff] bus [de000000:de1fffff] flags 27200 for BAR 6 of 0000:42:01.0
+ got res [de200000:de23ffff] bus [de200000:de23ffff] flags 27200 for BAR 6 of 0000:42:02.0
PCI: Bridge: 0000:40:11.0
IO window: 3000-3fff
MEM window: 0xdfe00000-0xdfefffff
- PREFETCH window: 0x0000000088100000-0x00000000883fffff
+ PREFETCH window: 0x00000000de000000-0x00000000de2fffff

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

yinghai at kernel

Jul 9, 2009, 12:34 PM

Post #5 of 8 (167 views)
Permalink

Re: mptsas, msi and the dl585 g2 [In reply to]

Yinghai Lu wrote:
> dann frazier wrote:
>> --------------------------------------------------------------------
>> commit 30a18d6c3f1e774de656ebd8ff219d53e2ba4029
>> Author: Yinghai Lu <Yinghai.Lu[at]Sun.COM>
>> Date: Tue Feb 19 03:21:20 2008 -0800
>>
>> x86: multi pci root bus with different io resource range, on
>> 64-bit
>> --------------------------------------------------------------------
>>
>> This appears to be the commit that actually introduced the issue.
>> I've attached dmesg w/ PCI DEBUG enabled from both sides of this
>> changeset, as well as a diff w/o printk timestamps.
>>
>> Also note that #ifdef'ing out x86_pci_root_bus_res_quirks() in
>> amd_bus.c seems to avoid the problem as well.
>
> your BIOS didn't allocate io resources to some device under HT chain on node1/link2
> aka under peer root bus.
>
> Kernel try to allocate resource to them.
>
> and the patch did right thing according to range
> bus: 40 index 1 mmio: [d9f00000, dfefffff]
>
> YH
>
>
> +bus: [00,3f] on node 0 link 1
> +bus: 00 index 0 io port: [0, 2fff]
> +bus: 00 index 1 mmio: [80000000, d9efffff]
> +bus: 00 index 2 mmio: [dff00000, e3ffffff]
> +bus: 00 index 3 mmio: [a0000, bffff]
> +bus: 00 index 4 mmio: [e8000000, ffffffff]
> +bus: 00 index 5 mmio: [480000000, fbffffffff]
> +bus: [40,7f] on node 1 link 2
> +bus: 40 index 0 io port: [3000, ffff]
> +bus: 40 index 1 mmio: [d9f00000, dfefffff]
> +bus: 40 index 2 mmio: [e4000000, e7ffffff]
> ACPI: bus type pci registered
> PCI: Using configuration type 1 for base access
> ACPI: EC: Look up EC in DSDT
> @@ -646,18 +659,18 @@
> IO window: disabled.
> MEM window: disabled.
> PREFETCH window: disabled.
> - got res [88000000:8801ffff] bus [88000000:8801ffff] flags 27200 for BAR 6 of 0000:41:01.0
> - got res [88020000:8803ffff] bus [88020000:8803ffff] flags 27200 for BAR 6 of 0000:41:02.0
> + got res [d9f00000:d9f1ffff] bus [d9f00000:d9f1ffff] flags 27200 for BAR 6 of 0000:41:01.0
> + got res [d9f20000:d9f3ffff] bus [d9f20000:d9f3ffff] flags 27200 for BAR 6 of 0000:41:02.0
> PCI: Bridge: 0000:40:10.0
> IO window: disabled.
> MEM window: 0xda000000-0xddffffff
> - PREFETCH window: 0x0000000088000000-0x00000000880fffff
> - got res [88200000:883fffff] bus [88200000:883fffff] flags 27200 for BAR 6 of 0000:42:01.0
> - got res [88100000:8813ffff] bus [88100000:8813ffff] flags 27200 for BAR 6 of 0000:42:02.0
> + PREFETCH window: 0x00000000d9f00000-0x00000000d9ffffff
> + got res [de000000:de1fffff] bus [de000000:de1fffff] flags 27200 for BAR 6 of 0000:42:01.0
> + got res [de200000:de23ffff] bus [de200000:de23ffff] flags 27200 for BAR 6 of 0000:42:02.0
> PCI: Bridge: 0000:40:11.0
> IO window: 3000-3fff
> MEM window: 0xdfe00000-0xdfefffff
> - PREFETCH window: 0x0000000088100000-0x00000000883fffff
> + PREFETCH window: 0x00000000de000000-0x00000000de2fffff
>
>

and those range are not overlapping with IOAPIC BAR allocating
[ 0.000000] ACPI: IOAPIC (id[0x08] address[0xd9cf0000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 8, version 0, address 0xd9cf0000, GSI 0-23
[ 0.000000] ACPI: IOAPIC (id[0x09] address[0xd9fd0000] gsi_base[24])
[ 0.000000] IOAPIC[1]: apic_id 9, version 0, address 0xd9fd0000, GSI 24-30
[ 0.000000] ACPI: IOAPIC (id[0x0a] address[0xd9fe0000] gsi_base[31])
[ 0.000000] IOAPIC[2]: apic_id 10, version 0, address 0xd9fe0000, GSI 31-37
[ 0.000000] ACPI: IOAPIC (id[0x0b] address[0xd9ff0000] gsi_base[38])
[ 0.000000] IOAPIC[3]: apic_id 11, version 0, address 0xd9ff0000, GSI 38-61

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

yinghai at kernel

Jul 9, 2009, 12:48 PM

Post #6 of 8 (170 views)
Permalink

Re: mptsas, msi and the dl585 g2 [In reply to]

Yinghai Lu wrote:
> Yinghai Lu wrote:
>> dann frazier wrote:
>>> --------------------------------------------------------------------
>>> commit 30a18d6c3f1e774de656ebd8ff219d53e2ba4029
>>> Author: Yinghai Lu <Yinghai.Lu[at]Sun.COM>
>>> Date: Tue Feb 19 03:21:20 2008 -0800
>>>
>>> x86: multi pci root bus with different io resource range, on
>>> 64-bit
>>> --------------------------------------------------------------------
>>>
>>> This appears to be the commit that actually introduced the issue.
>>> I've attached dmesg w/ PCI DEBUG enabled from both sides of this
>>> changeset, as well as a diff w/o printk timestamps.
>>>
>>> Also note that #ifdef'ing out x86_pci_root_bus_res_quirks() in
>>> amd_bus.c seems to avoid the problem as well.
>> your BIOS didn't allocate io resources to some device under HT chain on node1/link2
>> aka under peer root bus.
>>
>> Kernel try to allocate resource to them.
>>
>> and the patch did right thing according to range
>> bus: 40 index 1 mmio: [d9f00000, dfefffff]
>>
>> YH
>>
>>
>> +bus: [00,3f] on node 0 link 1
>> +bus: 00 index 0 io port: [0, 2fff]
>> +bus: 00 index 1 mmio: [80000000, d9efffff]
>> +bus: 00 index 2 mmio: [dff00000, e3ffffff]
>> +bus: 00 index 3 mmio: [a0000, bffff]
>> +bus: 00 index 4 mmio: [e8000000, ffffffff]
>> +bus: 00 index 5 mmio: [480000000, fbffffffff]
>> +bus: [40,7f] on node 1 link 2
>> +bus: 40 index 0 io port: [3000, ffff]
>> +bus: 40 index 1 mmio: [d9f00000, dfefffff]
>> +bus: 40 index 2 mmio: [e4000000, e7ffffff]
>> ACPI: bus type pci registered
>> PCI: Using configuration type 1 for base access
>> ACPI: EC: Look up EC in DSDT
>> @@ -646,18 +659,18 @@
>> IO window: disabled.
>> MEM window: disabled.
>> PREFETCH window: disabled.
>> - got res [88000000:8801ffff] bus [88000000:8801ffff] flags 27200 for BAR 6 of 0000:41:01.0
>> - got res [88020000:8803ffff] bus [88020000:8803ffff] flags 27200 for BAR 6 of 0000:41:02.0
>> + got res [d9f00000:d9f1ffff] bus [d9f00000:d9f1ffff] flags 27200 for BAR 6 of 0000:41:01.0
>> + got res [d9f20000:d9f3ffff] bus [d9f20000:d9f3ffff] flags 27200 for BAR 6 of 0000:41:02.0
>> PCI: Bridge: 0000:40:10.0
>> IO window: disabled.
>> MEM window: 0xda000000-0xddffffff
>> - PREFETCH window: 0x0000000088000000-0x00000000880fffff
>> - got res [88200000:883fffff] bus [88200000:883fffff] flags 27200 for BAR 6 of 0000:42:01.0
>> - got res [88100000:8813ffff] bus [88100000:8813ffff] flags 27200 for BAR 6 of 0000:42:02.0
>> + PREFETCH window: 0x00000000d9f00000-0x00000000d9ffffff
>> + got res [de000000:de1fffff] bus [de000000:de1fffff] flags 27200 for BAR 6 of 0000:42:01.0
>> + got res [de200000:de23ffff] bus [de200000:de23ffff] flags 27200 for BAR 6 of 0000:42:02.0
>> PCI: Bridge: 0000:40:11.0
>> IO window: 3000-3fff
>> MEM window: 0xdfe00000-0xdfefffff
>> - PREFETCH window: 0x0000000088100000-0x00000000883fffff
>> + PREFETCH window: 0x00000000de000000-0x00000000de2fffff
>>
>>
>
>
> and those range are not overlapping with IOAPIC BAR allocating
> [ 0.000000] ACPI: IOAPIC (id[0x08] address[0xd9cf0000] gsi_base[0])
> [ 0.000000] IOAPIC[0]: apic_id 8, version 0, address 0xd9cf0000, GSI 0-23
> [ 0.000000] ACPI: IOAPIC (id[0x09] address[0xd9fd0000] gsi_base[24])
> [ 0.000000] IOAPIC[1]: apic_id 9, version 0, address 0xd9fd0000, GSI 24-30
> [ 0.000000] ACPI: IOAPIC (id[0x0a] address[0xd9fe0000] gsi_base[31])
> [ 0.000000] IOAPIC[2]: apic_id 10, version 0, address 0xd9fe0000, GSI 31-37
> [ 0.000000] ACPI: IOAPIC (id[0x0b] address[0xd9ff0000] gsi_base[38])
> [ 0.000000] IOAPIC[3]: apic_id 11, version 0, address 0xd9ff0000, GSI 38-61
>

with the new allocation:
[ 4.279139] got res [d9f00000:d9f1ffff] bus [d9f00000:d9f1ffff] flags 27200 for BAR 6 of 0000:41:01.0
[ 4.279142] got res [d9f20000:d9f3ffff] bus [d9f20000:d9f3ffff] flags 27200 for BAR 6 of 0000:41:02.0
[ 4.279144] PCI: Bridge: 0000:40:10.0
[ 4.299135] IO window: disabled.
[ 4.319148] MEM window: 0xda000000-0xddffffff
[ 4.333140] PREFETCH window: 0x00000000d9f00000-0x00000000d9ffffff
[ 4.370170] got res [de000000:de1fffff] bus [de000000:de1fffff] flags 27200 for BAR 6 of 0000:42:01.0
[ 4.370173] got res [de200000:de23ffff] bus [de200000:de23ffff] flags 27200 for BAR 6 of 0000:42:02.0
[ 4.370175] PCI: Bridge: 0000:40:11.0
[ 4.390143] IO window: 3000-3fff
[ 4.410177] MEM window: 0xdfe00000-0xdfefffff
[ 4.435157] PREFETCH window: 0x00000000de000000-0x00000000de2fffff

[ 4.333140] PREFETCH window: 0x00000000d9f00000-0x00000000d9ffffff
are all directed to one 8132 PCI-X bridge.

the the IOAPIC for 9, 10, 11... falling that range...

we need one better to allocate range for that pci-x bridge to aovide ioapic BAR allocated...

anyway your BIOS sucks.

YH

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

James.Bottomley at HansenPartnership

Jul 9, 2009, 1:40 PM

Post #7 of 8 (167 views)
Permalink

Re: mptsas, msi and the dl585 g2 [In reply to]

On Thu, 2009-07-09 at 12:48 -0700, Yinghai Lu wrote:
> [ 4.333140] PREFETCH window: 0x00000000d9f00000-0x00000000d9ffffff
> are all directed to one 8132 PCI-X bridge.
>
> the the IOAPIC for 9, 10, 11... falling that range...
>
> we need one better to allocate range for that pci-x bridge to aovide ioapic BAR allocated...
>
> anyway your BIOS sucks.

It's a sad and very annoying fact of life that most BIOSs suck. If they
didn't suck, our bios handling code wouldn't be a nasty mess of
exceptions, work arounds and quirks.

Can we fix this so that both the DL585 and the opteron multi root stuff
can work? There's a large population of DL585's out there, so we can't
release 2.6.32 like this ... and I'd rather not have to choose between
breaking the DL585's and breaking the Sun Opterons.

James

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

yhlu.kernel at gmail

Jul 9, 2009, 2:12 PM

Post #8 of 8 (168 views)
Permalink

Re: mptsas, msi and the dl585 g2 [In reply to]

On Thu, Jul 9, 2009 at 1:40 PM, James
Bottomley<James.Bottomley[at]hansenpartnership.com> wrote:
> On Thu, 2009-07-09 at 12:48 -0700, Yinghai Lu wrote:
>> [ � �4.333140] � PREFETCH window: 0x00000000d9f00000-0x00000000d9ffffff
>> are all directed to one 8132 PCI-X bridge.
>>
>> the the IOAPIC for 9, 10, 11... falling that range...
>>
>> we need one better to allocate range for that pci-x bridge to aovide ioapic BAR allocated...
>>
>> anyway your BIOS sucks.
>
> It's a sad and very annoying fact of life that most BIOSs suck. �If they
> didn't suck, our bios handling code wouldn't be a nasty mess of
> exceptions, work arounds and quirks.
>
> Can we fix this so that both the DL585 and the opteron multi root stuff
> can work? �There's a large population of DL585's out there, so we can't
> release 2.6.32 like this ... and I'd rather not have to choose between
> breaking the DL585's and breaking the Sun Opterons.

sure. will send out one patch after get some sanity test here.

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com