Bug#543308: [lenny -> squeeze regression] MPT Fusion SCSI drives no longer appear

[Jonathan Nieder <jrnieder@gmail.com>]

reassign 543308 src:linux-2.6 2.6.30-5
found 543308 linux-2.6/2.6.30-6
found 543308 linux-2.6/2.6.32-5
tags 543308 - fixed-upstream
quit

Hi,

Sean M. Pappalardo wrote:

> Since upgrading to the 2.6.30 kernel, drives attached to my LSI/MPT
> SCSI controller are no longer visible. If I boot using the 2.6.26-2
> kernel, it works fine.
[...]
> Ah, I just found a workaround: my BIOS offers the option to disable ACPI bus
> segmentation. Its help text explicitly mentions this issue of PCI-X devices not
> showing up on Linux. When I do that, the devices show up again in the later
> kernels.
>
> The question is: is this a solution or do the newer kernels need fixing?

Matthew Wilcox wrote:

> I don't consider this an acceptable solution (and I wish BIOS people would talk
> to us instead of adding options to disable features).
>
> I see this message in your dmesg:
>
> [    0.358390] PCI: BIOS Bug: MCFG area at e0000000 is not reserved in ACPI motherboard resources

Yinghai Lu wrote:
> Bjorn Helgaas wrote:

>> Can you also attach a dmesg log from a current kernel, e.g., 3.4 or
>> newer?  We now print a lot more information during PCI enumeration.
>>
>> But I guess the problem is that 2.6.26 finds devices in domains 1 and
>> 2, while 2.6.32 does not.  I think MMCONFIG is the only config access
>> method we have for domains other than 0.  That suggests that MMCONFIG
>> used to work but doesn't any more.  The dmesg logs claim that we're
>> not using MMCONFIG in either 2.6.26 or 2.6.32 though, so I don't know
>> why we found anything in 2.6.26.
>
> in short: the bios is broken, it return wrong segment in DSDT.
>
> in both case, only pci_conf1 is used.  CPU is not new enough.
>
> after comparing the code 2.6.26 and 2.6.32.  2.6.26 is not checking
> seg in pci_conf1_read. but 2.6.32 check that...
[...]
> please get to get new BIOS from your vendor.
> or you need to override your DSDT.

Sean M. Pappalardo wrote:

> I just called HP and the system is too old for them to put any resources on
> making a new BIOS. So in light of that and your comment Yinghai, this is in
> fact not a kernel bug (rather an unintended consequence of a fix,) and my only
> option is to use the BIOS-provided workaround (Disable ACPI bus segmentation.)
>
> Let me know if any of that is incorrect.

Alan Cox then closed the bug with resolution INSUFFICIENT_DATA
(I guess he was waiting on the 3.4.y log).

Since the BIOS setting is not easily discoverable, I do not consider
it an adequate workaround.  Would you happen to have a fixed DSDT
available to test?  The people at linux-acpi@vger.kernel.org might be
able to help with that.  Please cc either me or this bug log if
pursuing that so we can track it.

I'd also be interested in how the 3.4.y kernel from experimental
behaves.  The only packages from outside squeeze that should be needed
for this test are the kernel itself, linux-base, and initramfs-tools.

Thanks for your help and patience,
Jonathan