Alex Chiang wrote: > * Kenji Kaneshige <kaneshige.kenji@xxxxxxxxxxxxxx>: >> Alex Chiang wrote: >>> * Kenji Kaneshige <kaneshige.kenji@xxxxxxxxxxxxxx>: >>>> Kenji Kaneshige wrote: >>>>> Alex Chiang wrote: >>>>>> Hi Kenji-san, >>>>>> >>>>>> * Kenji Kaneshige <kaneshige.kenji@xxxxxxxxxxxxxx>: >>>>>>> There had been reported a problem that pciehp driver mis-detect the >>>>>>> non hot-pluggable slot as hot-pluggable on some platforms. The cause >>>>>>> of this problem is hot-plug capable bit in Slot Capabilities register >>>>>>> is set improperly by BIOS or hardware. It seems BIOS/hardware problem, >>>>>>> but I think pciehp driver needs workaround for this problem. >>>>>> Do you know the magnitude of how many machines have broekn BIOS? >>>>>> >>>>>> I see from your patch 2/2 that there is a strong correlation >>>>>> between duplicate slot names and incorrect hot-plug capable bit. >>>>>> If that's true, then I guess there are a lot of broken machines >>>>>> out there... >>>>>> >>>>>> http://www.kerneloops.org/searchweek.php?search=pci_create_slot >>>>>> >>>>>> I was just wondering if we could quirk this somehow, but if you >>>>>> think there are too many broken machines out there, then your >>>>>> approach seems pretty reasonable. >>>>>> >>>>> Please note that pciehp and ACPI PCI slot detection driver have >>>>> different naming method. The pciehp driver uses Physical Slot Number >>>>> bit in Slot Capabilities register for slot naming. On the other hand, >>>>> ACPI PCI slot detection driver uses ACPI _SUN method for slot naming. >>>>> So, pciehp's duplicate slot name problem is different from the problem >>>>> reported in the above URL, I think. >>>>> >>>> Maybe I was wrong. >>>> Is the cause that pciehp driver registered a slot with a wrong name >>>> before ACPI PCI slot detection driver tried to register slots? >>> No, I think you were right. My guess is that those warnings came >>> from a broken ACPI namespace. >>> >> Oh, that's bad news also for my patches, because my patch has an >> assumption that PCI hotplug slots are properly defined in ACPI >> Namespace even if hotplug capable bit is wrongly set in the slot >> capabilities register. For those machines, maybe we need quirk >> approach one by one, I think. > > It may be the case that BIOS sets the capability bit incorrectly > but has correctly programmed ACPI. I really don't know... > >> By the way, do you have DSDT dump image of those broken ACPI >> Namespace? I would like to look, if possible. > > I asked Arjan to include a dmidecode with kerneloops in the > future, but we don't have anything today. I'm just going off of > what is reported on the web page, so I'm sorry, but I don't have > the data. :( > >>> In that case, I still wonder how many machines have broken native >>> PCIe hotplug that have the wrong bit set in the capabilities >>> register (and also falsely advertise hotplug). >>> >>> Do you know? >> I don't know the actual number. But the reported machines on the >> ML were popular laptop, so I think the number is relatively large. >> In addition, I got a x86 server recently and it has this problem >> (This is why I can make patches this time. I had been looking for >> the reproduction environment, and I finally got it). > > Ok, I think your patches can help, so let's try them out and see > if they improve the situation. > Ok, I'll update patches and post them soon. Thanks, Kenji Kaneshige -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
