On Mon, Jun 6, 2011 at 5:08 PM, Greg KH <greg@xxxxxxxxx> wrote: > On Mon, Jun 06, 2011 at 01:24:15PM -0600, Bjorn Helgaas wrote: >> On Mon, Jun 6, 2011 at 12:03 PM, Carl Karsten <carl@xxxxxxxxxxxxxxxxx> wrote: >> > On Sun, Jun 5, 2011 at 8:51 PM, Kenji Kaneshige >> > <kaneshige.kenji@xxxxxxxxxxxxxx> wrote: >> >> (2011/06/06 8:36), Bjorn Helgaas wrote: >> >>> >> >>> On Sun, Jun 5, 2011 at 5:57 AM, Carl Karsten<carl@xxxxxxxxxxxxxxxxx> >> >>> wrote: >> >>>> >> >>>> I am wondering why I see a difference between 2 similar setups: >> >>>> >> >>>> I have 2 laptops, ubuntu 2.6.39-3-generic on both. >> >>>> pciehp is included, acpiphp built but not inserted by default. >> >>>> >> >>>> HP EliteBook 8530w (KS051UA#ABA) >> >>>> HP Pavilion dv6700 Notebook PC (KC300UA#ABA) >> >>>> >> >>>> On the EliteBook, hotplug works: lspci entries come and go, modules >> >>>> un/load, udev reports add/remove. good. >> >>>> >> >>>> On the Pavilion, if I load acpiphp (via /etc/modules), hotplug works. >> >>>> If I don't load any additional modules hotplug does not work: insert >> >>>> card - nothing in syslog, lspci, udev. If a card is in the slot when >> >>>> the kernel loads, it shows in syslog, lscpi and the drivers get >> >>>> loaded. If I pull it out, nothing changes: still listed in lspci, >> >>>> modules still loaded, dev nodes still around. >> >>>> >> >>>> Here is some logs lines from Pavilion: >> >>>> >> >>>> stock module, doesn't work: >> >>>> [ 0.560575] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 >> >>>> [ 0.560605] pciehp: PCI Express Hot Plug Controller Driver version: >> >>>> 0.4 >> >>> >> >>> It might be useful to see the entire dmesg log and the "lspci -vv" >> >>> output from the Pavilion. >> >> I think the problem is just that pciehp is for native PCIe hotplug and >> your PCIe bridges don't seem to support that; they don't have the >> "Hot-Plug Capable" bit set in the Slot Capability register: >> >> 00:0c.0 PCI bridge: nVidia Corporation MCP67 PCI Express Bridge (rev >> a2) (prog-if 00 [Normal decode]) >> Bus: primary=00, secondary=04, subordinate=05, sec-latency=0 >> Capabilities: [80] Express (v1) Root Port (Slot+), MSI 00 ... >> SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- >> HotPlug- Surprise- >> >> 00:0d.0 PCI bridge: nVidia Corporation MCP67 PCI Express Bridge (rev >> a2) (prog-if 00 [Normal decode]) >> Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 >> Capabilities: [80] Express (v1) Root Port (Slot+), MSI 00 >> SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- >> HotPlug- Surprise- >> >> It seems like it'd be nice to have acpiphp loaded automatically >> somehow, so things would "just work." I don't know Ubuntu's strategy >> in that regard. It definitely feels like a broken user experience as >> things are. One might argue that if there's no way to autoload >> acpiphp, it ought to be built in statically. > > No, distros can't do that as there were whole classes of machines that > if you loaded the acpiphp driver, they would crash in bad ways as no one > had ever tested the api pci hotplug code in them. That was because > Windows at the time didn't support it. > > So unless you can guarantee that we will not break those older machines, > this can't happen, sorry. Maybe acpiphp can't be built in statically in its current form, but I don't think we should necessarily give up and say "well, we just can't make this platform work." It's likely that hotplug "just works" under Windows, so it's probably *possible* to make it work well under Linux. My guess is that this is not really a distro issue (e.g., decisions about config, autoload, /etc/modules, etc.), but rather an indication that we could make something better in the kernel. Whether that's some kind of acpiphp improvement, some date-based checking, or what, I don't know. And it may be that nobody has the right combination of interest/expertise/time/test machines to really solve it (I know I don't). Bjorn -- 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
