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 [email protected] 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/20120628210135.GA7536@burratino
