* FW: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can't work (Register access failure) @ 2012-07-17 1:40 Jennifer Li (TP) 2012-07-17 18:24 ` Bjorn Helgaas 0 siblings, 1 reply; 4+ messages in thread From: Jennifer Li (TP) @ 2012-07-17 1:40 UTC (permalink / raw) To: linux-pci; +Cc: stefanr SGksDQoNCkFkZCBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnDQpEb2VzIGFueW9uZSBjYW4gaGVs cCB1cz8NCg0KQmVzdCByZWdhcmRzLA0KSmVubmZlcg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGJ1Z3ppbGxhLWRhZW1vbkBidWd6aWxsYS5rZXJuZWwub3JnIFttYWlsdG86YnVn emlsbGEtZGFlbW9uQGJ1Z3ppbGxhLmtlcm5lbC5vcmddIA0KU2VudDogU2F0dXJkYXksIEp1bHkg MTQsIDIwMTIgOTowOSBQTQ0KVG86IEplbm5pZmVyIExpIChUUCkNClN1YmplY3Q6IFtCdWcgNDMy NDddIE8yIG1pY3JvIFNEL01NQysxMzk0IGNvbnRyb2xsZXI6IDEzOTQgZGV2aWNlIGNhbid0IHdv cmsgKFJlZ2lzdGVyIGFjY2VzcyBmYWlsdXJlKQ0KDQpodHRwczovL2J1Z3ppbGxhLmtlcm5lbC5v cmcvc2hvd19idWcuY2dpP2lkPTQzMjQ3DQoNCg0KDQoNCg0KLS0tIENvbW1lbnQgIzIwIGZyb20g U3RlZmFuIFJpY2h0ZXIgPHN0ZWZhbnJAczVyNi5pbi1iZXJsaW4uZGU+ICAyMDEyLTA3LTE0IDEz OjA5OjE2IC0tLSBPbiBKdWwgMTAgYnVnemlsbGEtZGFlbW9uQGJ1Z3ppbGxhLmtlcm5lbC5vcmcg d3JvdGU6DQo+IGh0dHBzOi8vYnVnemlsbGEua2VybmVsLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NDMy NDcNCj4gDQo+IC0tLSBDb21tZW50ICMxOSBmcm9tIGplbm5pZmVyIDxqZW5uaWZlci5saUBvMm1p Y3JvLmNvbT4gIDIwMTItMDctMTAgDQo+IDExOjAyOjE2IC0tLQ0KWy4uLl0NCj4gPiBEbyB5b3Ug bWVhbiBieSB0aGF0IHRoYXQNCj4gPiB0aGUgb3JpZ2luYWwgTGludXggZHJpdmVyIHdvcmtzIGZv ciB5b3UgaWYgeW91IGJvb3QgTGludXggYnV0IGRvIG5vdCANCj4gPiBsZXQgdGhlIGRyaXZlciBi ZSBhdXRvbWF0aWNhbGx5IGxvYWRlZCBkdXJpbmcgYm9vdCwgYnV0IGluc3RlYWQgbG9hZCANCj4g PiB0aGUgZHJpdmVyIGxhdGVyIGJ5ICdtb2Rwcm9iZSBmaXJld2lyZS1vaGNpJyBhZnRlciB0aGUg cmVzdCBvZiB0aGUgDQo+ID4gc3lzdGVtIGhhcyBmaW5pc2hlZCBib290aW5nIHVwPw0KPiANCj4g WWVzLg0KPiANCj4gPiANCj4gPiBBbmQgaWYgeWVzLCBkaWQgeW91IGFsc28gbmVlZCB0byBsb2Fk IHRoZSBzZGhjaS1wY2kgZHJpdmVyIG1hbnVhbGx5IA0KPiA+IHRoaXMgd2F5Pw0KPiANCj4gVGhl cmUgYXJlIDQgd2F5cyB3aGljaCBjYW4gcGFzcyB0aGUgaXNzdWUuDQo+IDEuIExvYWQgMTM5NCBi eSBPUyArIExvYWQgc2RoY2ktcGNpIGJ5IG1hbnVhbGx5Lg0KPiAyLiBMb2FkIHNkaGNpLXBjaSBi eSBPUyArIExvYWQgMTM5NCBieSBtYW51YWxseS4NCj4gMy4gTG9hZCAxMzk0IGJ5IG1hbnVhbGx5 ICsgbG9hZCBzZGhjaS1wY2kgYnkgbWFudWFsbHkuDQo+IDQuIExvYWQgc2RoY2ktcGNpIGJ5IG1h bnVhbGx5ICsgbG9hZCAxMzk0IGJ5IG1hbnVhbGx5Lg0KPiANCj4gPiBBbmQgZnVydGhlciwgZG9l cyBpdCBtYXR0ZXIgd2hldGhlciBzZGhjaS1wY2kgaXMgbG9hZGVkIGJlZm9yZSANCj4gPiBmaXJl d2lyZS1vaGNpIG9yIHRoZSBvdGhlciB3YXkgYXJvdW5kPw0KPiANCj4gQWNjb3JkaW5nIHRvIG91 ciB0ZXN0IHJlc3VsdCwgaWYgd2UgbG9hZCB0aGUgZHJpdmVyIGJ5IG1hbnVhbGx5IGFuZCANCj4g dGhlIGlzc3VlIHdpbGwgZGlzYXBwZWFyLiBJdCBkaWRuJ3QgaGFzIHRoZSByZWxhdGlvbnNoaXAg YWJvdXQgdGhlIGxvYWRlZCBwcmlvcml0eS4NCj4gQnV0LCBpZiB3ZSBsb2FkIHRob3NlIGRyaXZl cnMgYnkgT1MgYW5kIHRoZSBpc3N1ZSB3aWxsIGhhcHBlbi4NCg0KDQpDb3VsZCBzb21lYm9keSBh dCBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnIHBsZWFzZSBhZHZpc2U/DQoNCjEuKSAgSXMgdGhl cmUgYSBrZXJuZWwgcGFyYW1ldGVyIHdoaWNoIEplbm5pZmVyIGNvdWxkIHRyeSBpbiBvcmRlciB0 byBmb3JjZSBzZXJpYWxpemVkIFBDSSBkcml2ZXIgcHJvYmluZz8NCg0KMi4pICBJZiB0aGVyZSBp cyBvbmUgYW5kIGlmIHRoaXMgdHVybnMgb3V0IHRvIGN1cmUgdGhlIGlzc3VlIGluIHRlc3Rpbmc6 DQpIb3cgY2FuIEkgaW1wbGVtZW50IHNlcmlhbGl6YXRpb24gYmV0d2VlbiB0aGUgTzJNaWNybyBG aXJlV2lyZSAucHJvYmUoKSBhbmQgLnJlc3VtZSgpIG9uIG9uZSBoYW5kIGFuZCB0aGUgTzJNaWNy byBTREhDSSAucHJvYmUoKSBhbmQgLnJlc3VtZSgpIG9uIHRoZSBvdGhlciBoYW5kPw0KDQoNCltJ ZiB5b3UgcmVwbHkgdG8gdGhpcyB2aWEgYnVnemlsbGEgbWFpbCwgcGxlYXNlIGFkZA0KICAgIENj OiBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnDQppbiB5b3VyIHJlcGx5LiAgSSBhbSBub3QgYXdh cmUgb2YgYSB3YXkgdG8gYWRkIGl0IHRvIGJ1Z3ppbGxhLmtlcm5lbC5vcmcncyBDYyBsaXN0IG9m IGJ1ZyA0MzI0Ny5dDQoNCi0tDQpDb25maWd1cmUgYnVnbWFpbDogaHR0cHM6Ly9idWd6aWxsYS5r ZXJuZWwub3JnL3VzZXJwcmVmcy5jZ2k/dGFiPWVtYWlsDQotLS0tLS0tIFlvdSBhcmUgcmVjZWl2 aW5nIHRoaXMgbWFpbCBiZWNhdXNlOiAtLS0tLS0tIFlvdSByZXBvcnRlZCB0aGUgYnVnLg0KDQoN Cg0KVW5sZXNzIG90aGVyd2lzZSBzdGF0ZWQsIHRoaXMgZS1tYWlsIG1lc3NhZ2UgZG9lcyBub3Qg Y29uc3RpdHV0ZSBhIHNvbGljaXRhdGlvbiB0byBidXkgb3Igc2VsbCBhbnkgcHJvZHVjdHMgb3Ig c2VydmljZXMsIG9yIHRvIHBhcnRpY2lwYXRlIGluIGFueSBwYXJ0aWN1bGFyIHRyYWRpbmcgc3Ry YXRlZ3kuIFRoaXMgZS1tYWlsIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGlj aCBpdCBpcyBhZGRyZXNzZWQgYW5kIG1heSBjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaXMgY29u ZmlkZW50aWFsIG9yIGxlZ2FsbHkgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5h dGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nIG9yIG90aGVyIHVzZSBvZiB0aGlzIG1lc3NhZ2Ug b3IgaXRzIGF0dGFjaG1lbnRzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0 YWNobWVudHMuIE8yTWljcm8gSW50ZXJuYXRpb25hbCBMdGQuLCBhbmQgaXRzIHN1YnNpZGlhcmll cyBhbmQgYWZmaWxpYXRlcywgYXJlIG5laXRoZXIgbGlhYmxlIGZvciB0aGUgcHJvcGVyIGFuZCBj b21wbGV0ZSB0cmFuc21pc3Npb24gb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IGNvbW11bmljYXRpb24sIHRoZSBhY2N1cmFjeSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVk IHRoZXJlaW4sIG5vciBmb3IgYW55IGRlbGF5IGluIGl0cyByZWNlaXB0LiAgDQoNCg0K ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: FW: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can't work (Register access failure) 2012-07-17 1:40 FW: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can't work (Register access failure) Jennifer Li (TP) @ 2012-07-17 18:24 ` Bjorn Helgaas 2012-07-17 19:46 ` Stefan Richter 0 siblings, 1 reply; 4+ messages in thread From: Bjorn Helgaas @ 2012-07-17 18:24 UTC (permalink / raw) To: Jennifer Li (TP); +Cc: linux-pci, stefanr, bugzilla-daemon > 1.) Is there a kernel parameter which Jennifer could try in order to force serialized PCI driver probing? I don't understand the question here. As far as I know, drivers compiled statically into the kernel are already initialized serially, via the do_initcalls() -> do_initcall_level(6) path. The PCI core enumerates all the devices, then when we call each driver's module_init() function (serially), the module_init() function will register the driver, and the driver core will call the driver's .probe() function for every matching PCI device. > 2.) If there is one and if this turns out to cure the issue in testing: > How can I implement serialization between the O2Micro FireWire .probe() and .resume() on one hand and the O2Micro SDHCI .probe() and .resume() on the other hand? If serialization is required between two drivers, that sounds like a driver bug. What are the two drivers involved? ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can't work (Register access failure) 2012-07-17 18:24 ` Bjorn Helgaas @ 2012-07-17 19:46 ` Stefan Richter 2012-07-17 20:55 ` Bjorn Helgaas 0 siblings, 1 reply; 4+ messages in thread From: Stefan Richter @ 2012-07-17 19:46 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: Jennifer Li (TP), linux-pci, bugzilla-daemon On Jul 17 Bjorn Helgaas wrote: > > 1.) Is there a kernel parameter which Jennifer could try in order > > to force serialized PCI driver probing? > > I don't understand the question here. As far as I know, drivers > compiled statically into the kernel are already initialized serially, > via the do_initcalls() -> do_initcall_level(6) path. The PCI core > enumerates all the devices, then when we call each driver's > module_init() function (serially), the module_init() function will > register the driver, and the driver core will call the driver's > .probe() function for every matching PCI device. Jennifer and the other reporters of the issue most certainly all used modular kernels, i.e. got the drivers loaded by udev. module_init() doesn't matter, but - .probe(), - .resume() do. So as you say, if the drivers were statically linked, then at least .probe() would be performed serially, one PCI device after another, right? But AFAIK .resume() would still be performed in parallel by a pool of kernel threads in current kernels. > > 2.) If there is one and if this turns out to cure the issue in > > testing: > > How can I implement serialization between the O2Micro FireWire > > .probe() and .resume() on one hand and the O2Micro SDHCI > > .probe() and .resume() on the other hand? > > If serialization is required between two drivers, that sounds like a > driver bug. What are the two drivers involved? >From what I can tell, there is no driver bug but an unfortunate interaction between parts of a combo controller which in theory should functionally be totally unrelated. First we had lots and lots of slightly different and inconclusive reports from various people about the O2Micro FireWire part (or/and the SDHCI part) failing to work after boot or after PM resume. Jennifer's recent reports show that this happens if the two devices are being .probed() at the same time (or perhaps not exactly at the same time but close together; at least the firewire-ohci .probe() takes long enough to make some overlap probable of the .probe()s were called asynchronously baut close together). The involved drivers are: drivers/firewire/firewire-ohci.ko (drivers/firewire/ohci.c) drivers/mmc/host/sdhci-pci.ko (drivers/mmc/host/sdhci-pci.c) The involved device is either this triple combo device: 0b:00.0 FireWire (IEEE 1394) [0c00]: O2 Micro, Inc. Device [1217:11f7] (rev 05) (prog-if 10 [OHCI]) Subsystem: Dell Device [1028:04a4] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+ Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 42 Region 0: Memory at e0130000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> Kernel driver in use: firewire_ohci Kernel modules: firewire-ohci 0b:00.1 SD Host controller [0805]: O2 Micro, Inc. Device [1217:8320] (rev 05) (prog-if 01) Subsystem: Dell Device [1028:04a4] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 16 Region 0: Memory at e0120000 (32-bit, non-prefetchable) [size=512] Capabilities: <access denied> Kernel driver in use: sdhci-pci Kernel modules: sdhci-pci 0b:00.2 Mass storage controller [0180]: O2 Micro, Inc. Device [1217:8330] (rev 05) Subsystem: Dell Device [1028:04a4] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin C routed to IRQ 10 Region 0: Memory at e0110000 (32-bit, non-prefetchable) [size=1K] Region 2: Memory at e0100000 (32-bit, non-prefetchable) [size=1K] Capabilities: <access denied> Or this dual combo device: 09:00.0 FireWire (IEEE 1394) [0c00]: O2 Micro, Inc. Device [1217:13f7] (rev 05) (prog-if 10 [OHCI]) Subsystem: Dell Device [1028:04b4] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 17 Region 0: Memory at e1a30000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> Kernel driver in use: firewire_ohci Kernel modules: firewire-ohci 09:00.1 SD Host controller [0805]: O2 Micro, Inc. Device [1217:8321] (rev 05) (prog-if 01) Subsystem: Dell Device [1028:04b4] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 18 Region 0: Memory at e1a20000 (32-bit, non-prefetchable) [size=512] Capabilities: <access denied> Kernel driver in use: sdhci-pci Kernel modules: sdhci-pci -- Stefan Richter -=====-===-- -=== =---= http://arcgraph.de/sr/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can't work (Register access failure) 2012-07-17 19:46 ` Stefan Richter @ 2012-07-17 20:55 ` Bjorn Helgaas 0 siblings, 0 replies; 4+ messages in thread From: Bjorn Helgaas @ 2012-07-17 20:55 UTC (permalink / raw) To: Stefan Richter; +Cc: Jennifer Li (TP), linux-pci, bugzilla-daemon > Jennifer and the other reporters of the issue most certainly all used > modular kernels, i.e. got the drivers loaded by udev. > > module_init() doesn't matter, but > - .probe(), > - .resume() > do. So as you say, if the drivers were statically linked, then at least > .probe() would be performed serially, one PCI device after another, > right? But AFAIK .resume() would still be performed in parallel by a > pool of kernel threads in current kernels. OK, I see. When both drivers are loaded near the same time via udev, the firewire driver doesn't work correctly. I don't know of anything that serializes driver registration from dynamically loaded modules. I wouldn't bother with the resume issue until after the load-time issue is resolved because suspend/resume makes things harder to debug. You might be able to try loading/unloading the modules in a loop to reproduce the issue in a single boot. > From what I can tell, there is no driver bug but an unfortunate interaction > between parts of a combo controller which in theory should functionally be > totally unrelated. That's plausible. But I can't think of anything useful the PCI core can do here. If you can identify a hardware issue in the device, it's possible you could write a quirk to work around it. But after the driver has called pci_enable_device() (the last point at which quirks are applied), the PCI core is pretty much out of the picture. Maybe something could be added to one or both drivers to look for these devices and try deal with them? I'm afraid I don't have any good ideas here. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-07-17 20:55 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-07-17 1:40 FW: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can't work (Register access failure) Jennifer Li (TP) 2012-07-17 18:24 ` Bjorn Helgaas 2012-07-17 19:46 ` Stefan Richter 2012-07-17 20:55 ` Bjorn Helgaas
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.