* 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. Thanks. /ac -- 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
