Bug 56531

Sorry, due to a physical mishap, the laptop is now out of order. I will not be able to test any patches, thus closing the bug.

The laptop has been repaired, and I am ready to follow your debugging instructions.

An updated dmesg (from 3.10-rc4) is available in bug 59501

I have some idea about issue, the resource assignment logic is not so strong for ACPI based pci hotplug. Could you please help to test this patch as a prove of concept?

---
diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
index d0699ed..9675d74 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -695,7 +695,7 @@ static int __ref enable_device(struct acpiphp_slot *slot)
                            dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
                                max = pci_scan_bridge(bus, dev, max, pass);
                                if (pass && dev->subordinate) {
-                                       check_hotplug_bridge(slot, dev);
+                                       /*check_hotplug_bridge(slot, dev); */
                                        pci_bus_size_bridges(dev->subordinate);
                                }
                        }
---

Created attachment 104491 [details]
Dmesg after the patch

I have booted with a patched kernel and then docked the laptop. As you can see from the dmesg, the patch doesn't affect the problem.

Note that the "can't assign mem/io" messages happen even in the initially-docked case, but then they don't prevent devices from working. See e.g. https://bugzilla.kernel.org/attachment.cgi?id=104331 around timestamp 0.727453.

This bug is caused by the a difference in resource assignment between boot time and runtime hotplug. Basically acpiphp ignores resource assignment from firmware and tries to do that by itself. 

Could you please help to test this?

---
diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
index d0699ed..aba3efb 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -696,13 +696,12 @@ static int __ref enable_device(struct acpiphp_slot *slot)
                                max = pci_scan_bridge(bus, dev, max, pass);
                                if (pass && dev->subordinate) {
                                        check_hotplug_bridge(slot, dev);
-                                       pci_bus_size_bridges(dev->subordinate);
                                }
                        }
                }
        }
 
-       pci_bus_assign_resources(bus);
+       pci_assign_unassigned_bus_resources(bus);
        acpiphp_sanitize_bus(bus);
        acpiphp_set_hpp_values(bus);
        acpiphp_set_acpi_region(slot);
---

Created attachment 104531 [details]
Dmesg after the patch about pci_assign_unassigned_bus_resources

Your patch didn't fully help. However, it cured the hotplug case of bug 59581.

Do you mean all devices function properly after docking with this patch applied? If so, I think we have found the solution for this. On the other hand, we can't get rid of all resource allocation failures because BIOS only allocates limited resources. The target is to make hotplug works as boot time.

The patch only helps with the pata_marvell controller and the BluRay drive. Please see bug 59581.

Then what's the issue left? Any device on dock station functions abnormally?
Could you please help to send the content of /proc/iomem and /proc/ioport, for both boot docked and boot undocked cases? So we could easily compare the differences in resource assignment between boot time and runtime hotplug.

Oops, my latest test was invalid. I have applied the patch from comment #7, but not from #4. Will retest and also compare /proc/iomem and /proc/ioport when I return to my laptop.

As for "what's left" - before your patch from comment #7, nothing in the dock station worked, and after your patch, r8169 and pata_marvell devices in the dock station work while radeon and snd_hda_intel don't.

Hm. I need more coffee. From the context, it is obvious that the patches from comments #4 and #7 are not meant to be applied together. And it doesn't help anyway.

Created attachment 104571 [details]
/proc/ioports after booting with the dock station

These ioports and iomem files are from the 3.10-rc4 kernel with the following patches applied:

[PATCH] ACPI: initialize dock subsystem before scanning PCI root buses
ACPIPHP: fix device destroying order issue in handling dock notification
The fixup moving acpi_scan_lock_acquire()/release(), fixed up to actually apply
The patch from comment #7

Created attachment 104581 [details]
/proc/iomem after booting with the dock station

Created attachment 104591 [details]
/proc/ioports when booting undocked, before docking

Created attachment 104601 [details]
/proc/iomem when booting undocked, before docking

Created attachment 104611 [details]
/proc/ioports when booting undocked, after docking

Created attachment 104621 [details]
/proc/iomem when booting undocked, after docking

I hope that these /proc dumps help you to progress with this bug.

According to my investigation, the issue is caused by difference in PCI resource
assignment between boot time and runtime hotplug. On x86 platforms, it respects PCI resource assignment from BIOS and only reassign resources for unassigned BARs. But with acpiphp, it ignores BIOS resource assignment and reassign all resources by OS.
   If we have enough resources, reassigning all PCI resources should work too, but may fail if we are under resource constraints. On the other handle, current PCI IOMM align algorithm may waste huge MMIO address space if we have some PCI devices with huge IOMM BAR.
   On this Sony laptop, BIOS allocates limited IOMM resources for the dock station and the dock station has a gfx which has a 256MB IOMM BAR. So current acpiphp driver fails to allocate resources for most devices on the dock station.
    Currently I'm trying to change acpiphp to respect BIOS resource assignment by calling pcibios_survey_resource_bus(), as in pci_root.c. The other way is to change the IOMM resource allocation algorithm, but obviously it's much more risky of regressions if changing the algorithm. 

So could please help to test this patch?
---
diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
index 270fdba..12e3f6e 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -837,13 +837,13 @@ static int __ref enable_device(struct acpiphp_slot *slot)
                                max = pci_scan_bridge(bus, dev, max, pass);
                                if (pass && dev->subordinate) {
                                        check_hotplug_bridge(slot, dev);
-                                       pci_bus_size_bridges(dev->subordinate);
+                                       pcibios_resource_survey_bus(dev->subordinate);
                                }
                        }
                }
        }

-       pci_bus_assign_resources(bus);
+       pci_assign_unassigned_bus_resources(bus);
        acpiphp_sanitize_bus(bus);
        acpiphp_set_hpp_values(bus);
        acpiphp_set_acpi_region(slot);
---

The patch helped. Now even radeon doesn't error out.

Created attachment 104681 [details]
Dmesg after the patch

Created attachment 104691 [details]
/proc/ioports after the patch

Created attachment 104701 [details]
/proc/iomem after the patch