Hi, The 1394 initial process will fail and show " Apr 2 11:42:20 localhost kernel: firewire_ohci: Register access failure - please notify linux1394-devel@lists.sf.net". This issue has happened in the O2 micro SD/MMC+1394 combo function chip + DELL platform Vans or Latitude E5520. We can find the same issue in J-micro USB+1394 combo pci expresses card + DELL platform Vans or Latitude E5520. We found the problem was caused by the initialization process. If the two devices have initial in the same time, the 1394 device can't work. If we have plug in the 1394 device and boot into OS, the 1394 device can work well. Best regards, Jennifer
Current discussion: http://marc.info/?t=133346965500001 Potential solutions, not yet fully confirmed: (a) After the CycleTimer acces in ohci_enable(), clear regAccessFail and proceed with controller initialization. Patch series: http://git.kernel.org/?p=linux/kernel/git/ieee1394/linux1394.git;a=shortlog;h=refs/heads/o2micro Configure a file in /etc/modprobe.d/ with the line: options firewire-ohci cycle_timer_hard_fail=0 sclk_retries=0 Or (b) Defer ohci->bus_time initialization and updates until the bus time CSR is accessed for the first time. Patch: http://marc.info/?l=linux1394-devel&m=133611307930958
Hi, I have tried those solution and it is unwoekable. Could you provide any other solutions?
Information update: The Firewire driver has failed on "ohci_enable" routine. After that, it will show the "register access failure" message from irq_handler routine. Maybe there are something wrong in the "ohci_enable" register setting process.
(In reply to comment #1) > Current discussion: > http://marc.info/?t=133346965500001 > > Potential solutions, not yet fully confirmed: > > (a) After the CycleTimer acces in ohci_enable(), clear regAccessFail and > proceed with controller initialization. > Patch series: > > http://git.kernel.org/?p=linux/kernel/git/ieee1394/linux1394.git;a=shortlog;h=refs/heads/o2micro > Configure a file in /etc/modprobe.d/ with the line: > options firewire-ohci cycle_timer_hard_fail=0 sclk_retries=0 > [Jennifer] Please see the attached picture "screenshot.png". I have tried to add the " options firewire-ohci cycle_timer_hard_fail=0 sclk_retries=0" in the conf files under "/etc/modprobe.d/". After that, reboot it. > Or > > (b) Defer ohci->bus_time initialization and updates until the bus time CSR is > accessed for the first time. > Patch: > http://marc.info/?l=linux1394-devel&m=133611307930958 [Jennifer] Please see the attached file ochi.c. I have added the patch on ohci.c. (without the solution (A) ) OS: Fedora 16 Kernel version: 3.1.07 & 3.4 rc6
-Update information- If the OS has entered the suspend mode, the 1394 device can work after the OS resume. OS: Fedora 16 Kernel: 3.3.5 or 3.3.7 Steps: 1. Suspend 2. Resume. 3. Plug in the 1394 device and the 1394 device is workable. Steps: 1. Suspend 2. Resume. 3. Power off the notebook 4. Power on the notebook 5. Enter Fedora 16 and plug in 1394 device. The 1394 device is work.
The attachments from comment 4 are missing. Did something go wrong with the upload? Is comment 5 referring to unmodified Fedora kernels?
Created attachment 73441 [details] The ohci file for comment#4 The ohci file for comment#4
Created attachment 73442 [details] The picture for comment#4 The picture for comment#4
Yes, I didn't modify the Fedora 16 (3.3.5 & 3.3.7 ) kernels.
(In reply to comment #5) > -Update information- > > If the OS has entered the suspend mode, the 1394 device can work after the OS > resume. > OS: Fedora 16 > Kernel: 3.3.5 or 3.3.7 > > Steps: > 1. Suspend > 2. Resume. > 3. Plug in the 1394 device and the 1394 device is workable. > Sorry, this process was wrong. When we power off and restart the notebook, the 1394 device still unrecognized. > Steps: > 1. Suspend > 2. Resume. > 3. Power off the notebook > 4. Power on the notebook > 5. Enter Fedora 16 and plug in 1394 device. The 1394 device is work. I have get the messages from Fedora16+3.3.7kernel. Please see the messages file. Message Test process: 1. Boot into Fedora16+3.3.7kernel 2. Plug in the 1394 Harddisk 3. 1394 HD was unrecognized. 4. Plug out the 1394 HD. 5. Suspend 6. Resume 7. Plug in the 1394 Harddisk 8. 1394 HD was recognized. 9. Eject the 1394 HD. 10. Plug in the SD card and copy file to SD card.
Created attachment 73443 [details] Log Message for commet#10. Log Message for commet#10.
Thanks for your suggestions. This is my reply. Clemens Ladisch wrote: >Jennifer, does this chip has any PCI configuration registers that control PHY >>power management, or PHY reset/initialization ? No, we don't have any PCI configuration registers that control PHY power management, or PHY reset/initialization. Stefan Richter wrote: >OHCI 1.1 says: "Software may only set [HCControl.BIBimageValid] when >>HCControl.linkEnable is zero." This let's me wonder whether setting these >two >bits simultaneously could confuse some controllers. To be safe, maybe >set >them in separate MMIOs? Should we even read HCControl back to check that >>BIBimageValid has become 1 before we set linkEnable? >Observations: > - The reported cases of "device not detected if plugged into O2Micro > controller after controller was enabled" are about SBP-2 devices, > and the devices are actually detected but the SBP-2 login procedure > is not completed. One of the login steps that could have gone wrong > is when the target tries to read the initiator's EUI-64 in its bus > info block. On the other hand, SBP-2 and -3 require this to be done > in two quadlet read requests; per OHCI spec these are served by the > OHCI physical response unit based on the GlobalUniqueID register > rather than the BIB image. > - BIBimageValid was added in OHCI 1.1; the bit is reserved in > OHCI 1.0. The old ohci1394 driver in kernel 2.6.36 and older never > set this bit but also did not use the atomic config ROM image update > protocol of OHCI 1.1. >--- >The patch should be applicable to any recent kernel without regAccessFail >>patches. > > drivers/firewire/ohci.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) >--- a/drivers/firewire/ohci.c >+++ b/drivers/firewire/ohci.c >@@ -2384,10 +2384,8 @@ static int ohci_enable(struct fw_card *c > irqs |= OHCI1394_busReset; > reg_write(ohci, OHCI1394_IntMaskSet, irqs); > >- reg_write(ohci, OHCI1394_HCControlSet, >- OHCI1394_HCControl_linkEnable | >- OHCI1394_HCControl_BIBimageValid); >- >+ reg_write(ohci, OHCI1394_HCControlSet, >>OHCI1394_HCControl_BIBimageValid); >+ reg_write(ohci, OHCI1394_HCControlSet, OHCI1394_HCControl_linkEnable); > reg_write(ohci, OHCI1394_LinkControlSet, > OHCI1394_LinkControl_rcvSelfID | I have tried it and it is unworkable.
Hi, Does anyone have any suggestions about this issue?
On Jun 19 bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=43247 > > --- Comment #13 from jennifer <jennifer.li@o2micro.com> 2012-06-19 02:05:31 > --- > Hi, > > Does anyone have any suggestions about this issue? Sorry for the delay. The next step would be to test the suggestion from Clemens, May 28, of a limited loop over - soft reset - perhaps an added wait - request LPS on - wait - check LPS - read cycle timer, check regAccessFail in ohci_enable. I shall write a patch for testing when I get some spare time. However 1. the prior reports about failure to access SBP-2 storage devices (everything up until SBP-2 login exclusive did actually work, only one of the steps during login did not proceed) still let me suspect that the issue is not entirely localized to the phy--link interface state; 2. what if the mentioned loop never gets past reading the cycle timer without regAccessFail? Could there be an interaction between initialization of the two or three functions of the combination controller? (FireWire OHCI 1217:13f7 rev 05 and SDHCI 1217:8321 rev 05; or FireWire OHCI 1217:11f7 rev 05 and SDHCI 1217:8320 rev 5 and Mass storage controller 1217:8330 rev 05)
(In reply to comment #14) Thanks for your reply! > Sorry for the delay. The next step would be to test the suggestion from > Clemens, May 28, of a limited loop over > - soft reset Jennifer: I have added the soft reset before and it looks unworkable. > - perhaps an added wait > - request LPS on > - wait > - check LPS > - read cycle timer, check regAccessFail > in ohci_enable. I shall write a patch for testing when I get some > spare time. > > However > 1. the prior reports about failure to access SBP-2 storage devices > (everything up until SBP-2 login exclusive did actually work, only one > of the steps during login did not proceed) still let me suspect that the > issue is not entirely localized to the phy--link interface state; > 2. what if the mentioned loop never gets past reading the cycle timer > without regAccessFail? Jennifer: I don't understand this question. If we didn't have the "regAccessFail" message and we didn't have the 1394 problem. > > Could there be an interaction between initialization of the two or three > functions of the combination controller? (FireWire OHCI 1217:13f7 rev 05 > and SDHCI 1217:8321 rev 05; or FireWire OHCI 1217:11f7 rev 05 and SDHCI > 1217:8320 rev 5 and Mass storage controller 1217:8330 rev 05) This problems happened in the default Linux driver + combination controller only. If we have initialed the combo device separately (manually), we didn't see the problems. If OS have initialed the combo device, we will see the problems. Linux have the default 1394 and SD driver only. So, we didn't meet the problems in (Mass storage controller 1217:8330 rev 05+FireWire OHCI 1217:13f7 rev 05)
On Jun 27 bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=43247 > > --- Comment #15 from jennifer <jennifer.li@o2micro.com> 2012-06-27 06:31:50 > --- > (In reply to comment #14) > Thanks for your reply! > > Sorry for the delay. The next step would be to test the suggestion from > > Clemens, May 28, of a limited loop over > > - soft reset > > Jennifer: I have added the soft reset before and it looks unworkable. > > > - perhaps an added wait > > - request LPS on > > - wait > > - check LPS > > - read cycle timer, check regAccessFail > > in ohci_enable. I shall write a patch for testing when I get some > > spare time. I guess we should nevertheless still try the loop, but I don't have much hope for that. > > However > > 1. the prior reports about failure to access SBP-2 storage devices > > (everything up until SBP-2 login exclusive did actually work, only one > > of the steps during login did not proceed) still let me suspect that the > > issue is not entirely localized to the phy--link interface state; On the other hand, Cyril's new report shows the symptoms of a completely disabled phy--link interface. http://marc.info/?l=linux1394-devel&m=134074880424956 > > 2. what if the mentioned loop never gets past reading the cycle timer > > without regAccessFail? > > Jennifer: I don't understand this question. If we didn't have the > "regAccessFail" message and we didn't have the 1394 problem. It was a hypothetical question regrading what might happen with the above mentioned loop. > > Could there be an interaction between initialization of the two or three > > functions of the combination controller? (FireWire OHCI 1217:13f7 rev 05 > > and SDHCI 1217:8321 rev 05; or FireWire OHCI 1217:11f7 rev 05 and SDHCI > > 1217:8320 rev 5 and Mass storage controller 1217:8330 rev 05) > > This problems happened in the default Linux driver + combination controller > only. If we have initialed the combo device separately (manually), we didn't > see the problems. If OS have initialed the combo device, we will see the > problems. > Linux have the default 1394 and SD driver only. So, we didn't meet the > problems > in (Mass storage controller 1217:8330 rev 05+FireWire OHCI 1217:13f7 rev 05) Was your manual initialization done in hardware or by software? If the latter, - where there steps done in a different oder than the Linux driver does, - did you omit steps which the Linux driver performs?
(In reply to comment #16) > On Jun 27 bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=43247 > > > > --- Comment #15 from jennifer <jennifer.li@o2micro.com> 2012-06-27 > 06:31:50 --- > > (In reply to comment #14) > > Thanks for your reply! > > > Sorry for the delay. The next step would be to test the suggestion from > > > Clemens, May 28, of a limited loop over > > > - soft reset > > > > Jennifer: I have added the soft reset before and it looks unworkable. > > > > > - perhaps an added wait > > > - request LPS on > > > - wait > > > - check LPS > > > - read cycle timer, check regAccessFail > > > in ohci_enable. I shall write a patch for testing when I get some > > > spare time. > > I guess we should nevertheless still try the loop, but I don't have much > hope for that. Yes, it is unworkable. I have tested it. > > > > However > > > 1. the prior reports about failure to access SBP-2 storage devices > > > (everything up until SBP-2 login exclusive did actually work, only one > > > of the steps during login did not proceed) still let me suspect that > the > > > issue is not entirely localized to the phy--link interface state; > > On the other hand, Cyril's new report shows the symptoms of a completely > disabled phy--link interface. > http://marc.info/?l=linux1394-devel&m=134074880424956 > > > > 2. what if the mentioned loop never gets past reading the cycle timer > > > without regAccessFail? > > > > Jennifer: I don't understand this question. If we didn't have the > > "regAccessFail" message and we didn't have the 1394 problem. > > It was a hypothetical question regrading what might happen with the above > mentioned loop. > > > > Could there be an interaction between initialization of the two or three > > > functions of the combination controller? (FireWire OHCI 1217:13f7 rev 05 > > > and SDHCI 1217:8321 rev 05; or FireWire OHCI 1217:11f7 rev 05 and SDHCI > > > 1217:8320 rev 5 and Mass storage controller 1217:8330 rev 05) > > > > This problems happened in the default Linux driver + combination controller > > only. If we have initialed the combo device separately (manually), we > didn't > > see the problems. If OS have initialed the combo device, we will see the > > problems. > > Linux have the default 1394 and SD driver only. So, we didn't meet the > problems > > in (Mass storage controller 1217:8330 rev 05+FireWire OHCI 1217:13f7 rev > 05) > > Was your manual initialization done in hardware or by software? If the > latter, > - where there steps done in a different oder than the Linux driver does, > - did you omit steps which the Linux driver performs? Those steps done in the same order. It was arranged by OS. I didn't modify the Linux OS and it has arrange by default Linux OS.
> --- Comment #17 from jennifer <jennifer.li@o2micro.com> 2012-07-06 10:14:46 > --- > (In reply to comment #16) > > On Jun 27 bugzilla-daemon@bugzilla.kernel.org wrote: > > > https://bugzilla.kernel.org/show_bug.cgi?id=43247 > > I guess we should nevertheless still try the loop, but I don't have much > > hope for that. > > Yes, it is unworkable. I have tested it. [...] > > > This problems happened in the default Linux driver + combination > controller > > > only. If we have initialed the combo device separately (manually), we > didn't > > > see the problems. If OS have initialed the combo device, we will see the > > > problems. [...] > > Was your manual initialization done in hardware or by software? If the > > latter, > > - where there steps done in a different oder than the Linux driver does, > > - did you omit steps which the Linux driver performs? > > Those steps done in the same order. It was arranged by OS. I didn't modify > the > Linux OS and it has arrange by default Linux OS. I am not sure whether I understood correctly: Do you mean by that that the original Linux driver works for you if you boot Linux but do not let the driver be automatically loaded during boot, but instead load the driver later by 'modprobe firewire-ohci' after the rest of the system has finished booting up? And if yes, did you also need to load the sdhci-pci driver manually this way? And further, does it matter whether sdhci-pci is loaded before firewire-ohci or the other way around?
(In reply to comment #18) > > --- Comment #17 from jennifer <jennifer.li@o2micro.com> 2012-07-06 > 10:14:46 --- > > (In reply to comment #16) > > > On Jun 27 bugzilla-daemon@bugzilla.kernel.org wrote: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=43247 > > > I guess we should nevertheless still try the loop, but I don't have much > > > hope for that. > > > > Yes, it is unworkable. I have tested it. > > [...] > > > > This problems happened in the default Linux driver + combination > controller > > > > only. If we have initialed the combo device separately (manually), we > didn't > > > > see the problems. If OS have initialed the combo device, we will see > the > > > > problems. > [...] > > > Was your manual initialization done in hardware or by software? If the > > > latter, > > > - where there steps done in a different oder than the Linux driver > does, > > > - did you omit steps which the Linux driver performs? > > > > Those steps done in the same order. It was arranged by OS. I didn't modify > the > > Linux OS and it has arrange by default Linux OS. > > I am not sure whether I understood correctly: Do you mean by that that > the original Linux driver works for you if you boot Linux but do not let > the driver be automatically loaded during boot, but instead load the driver > later by 'modprobe firewire-ohci' after the rest of the system has finished > booting up? Yes. > > And if yes, did you also need to load the sdhci-pci driver manually this > way? There are 4 ways which can pass the issue. 1. Load 1394 by OS + Load sdhci-pci by manually. 2. Load sdhci-pci by OS + Load 1394 by manually. 3. Load 1394 by manually + load sdhci-pci by manually. 4. Load sdhci-pci by manually + load 1394 by manually. > And further, does it matter whether sdhci-pci is loaded before > firewire-ohci or the other way around? According to our test result, if we load the driver by manually and the issue will disappear. It didn't has the relationship about the loaded priority. But, if we load those drivers by OS and the issue will happen.
On Jul 10 bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=43247 > > --- Comment #19 from jennifer <jennifer.li@o2micro.com> 2012-07-10 11:02:16 > --- [...] > > Do you mean by that that > > the original Linux driver works for you if you boot Linux but do not let > > the driver be automatically loaded during boot, but instead load the driver > > later by 'modprobe firewire-ohci' after the rest of the system has finished > > booting up? > > Yes. > > > > > And if yes, did you also need to load the sdhci-pci driver manually this > > way? > > There are 4 ways which can pass the issue. > 1. Load 1394 by OS + Load sdhci-pci by manually. > 2. Load sdhci-pci by OS + Load 1394 by manually. > 3. Load 1394 by manually + load sdhci-pci by manually. > 4. Load sdhci-pci by manually + load 1394 by manually. > > > And further, does it matter whether sdhci-pci is loaded before > > firewire-ohci or the other way around? > > According to our test result, if we load the driver by manually and the issue > will disappear. It didn't has the relationship about the loaded priority. > But, if we load those drivers by OS and the issue will happen. Could somebody at linux-pci@vger.kernel.org please advise? 1.) Is there a kernel parameter which Jennifer could try in order to force serialized PCI driver probing? 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 you reply to this via bugzilla mail, please add Cc: linux-pci@vger.kernel.org in your reply. I am not aware of a way to add it to bugzilla.kernel.org's Cc list of bug 43247.]
> 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?
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/
> 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.
(In reply to comment #23) > 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. > We have tried to load/inload the firewire driver but it is unworkable. This is the test process: boot into Linux -> rmmod firewire -> insmod firewire -> firewire device still unworkable
(In reply to comment #0) > This issue has happened in the O2 micro SD/MMC+1394 combo function chip + > DELL > platform Vans or Latitude E5520. We can find the same issue in J-micro > USB+1394 > combo pci expresses card + DELL platform Vans or Latitude E5520. Do you mean by "J-micro USB+1394 combo pci expresses card" the combo chip in these Dell laptops, or are you referring to a separate add-on card which features the same or similar combo chip like the controllers in the Dells? If it is an add-on card: I haven't found such a card by web search. Is it not a released product yet? Or could you provide me a link to a vendor or shop webpage about the card, so that I could look into getting one myself? (A European source would work best for me.)
(In reply to comment #25) > (In reply to comment #0) > > This issue has happened in the O2 micro SD/MMC+1394 combo function chip + > DELL > > platform Vans or Latitude E5520. We can find the same issue in J-micro > USB+1394 > > combo pci expresses card + DELL platform Vans or Latitude E5520. > > Do you mean by "J-micro USB+1394 combo pci expresses card" the combo chip in > these Dell laptops, or are you referring to a separate add-on card which > features the same or similar combo chip like the controllers in the Dells? > > If it is an add-on card: I haven't found such a card by web search. Is it > not > a released product yet? Or could you provide me a link to a vendor or shop > webpage about the card, so that I could look into getting one myself? (A > European source would work best for me.) Yes, it is a separate add-on card. But I can't find a shop in European. This is the Taiwan's shop link. http://buy.yahoo.com.tw/gdsale/gdsale.asp?gdid=1289116 UPTECH UTE110 (1394+USB) According to my test result, this issue happened in DELL E5520 platform only. If possible, maybe you should buy a DELL E5520 in the same time.
On Jul 27 Ayan George wrote: > Hey Stefan, > > I'm sorry I haven't been responsive when it comes to this bug. I just > wanted to let you know that the workaround one of the OEM team members > came up with is to reload the driver after a drive is connected. The workaround could be implemented in the kernel at the cost of respectively many lines of code: Wrap all of the controller initialization into a self-rearming worqueue job. The job attempts to initialize the controller, checks for regAccessFail, if yes, shuts down the controller and requeues itself for e.g. 5 seconds later. Additional care must be taken about .suspend(), .resume(), and module_exit(). However, this would be such a gross hack --- there must be something simpler than that. Perhaps serialization against initialization of the SDHCI part would be the key, but so far it is unclear how that could be systematically tested and (if successful) be properly implemented. > I hope that information helps determine the root cause of the problem. This finding would be consistent with the earlier finding that it also works if a FireWire device is already connected when the laptop is powered up IIRC. On the other hand, Jennifer wrote in https://bugzilla.kernel.org/show_bug.cgi?id=43247#c24: | > You might be able to try loading/unloading the modules in a loop to | > reproduce the issue in a single boot. | | We have tried to load/inload the firewire driver but it is unworkable. | This is the test process: boot into Linux -> rmmod firewire -> insmod | firewire -> firewire device still unworkable So I guess this was tested without anything connected.
(In reply to comment #27) > | > You might be able to try loading/unloading the modules in a loop to > | > reproduce the issue in a single boot. > | > | We have tried to load/inload the firewire driver but it is unworkable. > | This is the test process: boot into Linux -> rmmod firewire -> insmod > | firewire -> firewire device still unworkable > > So I guess this was tested without anything connected. Yes, this was tested without anything connected.
Created attachment 107601 [details] screenshot from Dell Latitude E5420, Ubuntu 12-04 Date: Tue, 3 Sep 2013 19:41:03 -0400 From: Frej Tulin <frej.tulin@gmail.com> To: linux1394-devel@lists.sf.net Subject: ubuntu 12.04 power management discrepance & crash failure Hi I'm running ubuntu 12.04 on a dell latitude E5420. When the computer wakes up from sleep it displays several lines containing "power management discrepancy", e.g. [ 3944.693579] [drm:gem6_sanitize_pm] *ERROR* Power management discrepancy: GEM6_RP_INTERRUPT_LIMITS expected 1a000000, was 12060000" it also tells me to notify linux1394-devel@lists.sf.net, which is why i'm writing here. The computer also crashes regularly and nothing but a hard reboot helps. I haven't noticed any pattern as to when it typically crashes. It seems to be random. I'm guessing the error message and the frequent crashing are connected. Please let me know if you have any insight into this. I'm attaching a picture I managed to snap of the error message screen. It only ever up for about 1 second or less. many thanks /frej -- Frej Tulin Fred Cross lab Rockefeller University
(In reply to Bjorn Helgaas from comment #23) > > 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. I think this may be a hardware bug with concurrent PCI Configuration transactions to different functions of the O2 multi-function device. Either the PCI-to-PCI bridge is conflating different transactions to different functions on the same device or the device is. When sdhci and firewire-ohci are probing simultaneously, the sdhci driver gets a bad BAR size (in addition to the firewire-ohci error): sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman firewire_ohci: Register access failure - please notify linux1394-dev@lists.sf.net firewire_ohci: Added fw-ohci device 0000:09:00.0, OHCI v1.10, 8 IR + 8 IT contexts, quirks 0x10 sdhci-pci 0000:09:00.1: SDHCI controller found [1217:8321] (rev 5) sdhci-pci 0000:09:00.1: Invalid iomem size. You may experience problems. mmc0: SDHCI controller on PCI [0000:09:00.1] using DMA Would anyone with this hardware be willing to run an instrumentation patch I could supply?
(In reply to Bjorn Helgaas from comment #23) > > 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 think there is a way to serialize these probes: 1. load the pci-stub driver early to claim one of the PCI ids, eg. the firewire id 1217:13f7 2. create a udev rule that matches the other PCI id, eg. the SD host controller id 1217:8321, but runs a script that unbinds pci-stub and modprobes firewire-ohci This may even be possible without pci-stub, and only using udev rules by matching the pci MODALIAS for one of the pci functions but doing nothing, like: ACTION=="add", SUBSYSTEM=="pci", ENV{MODALIAS}=="pci:v000011C1d00005811*", RUN:="" and then doing step 2 above (maybe in the same udev rules file): ACTION=="add", DRIVER="sdhci", ATTR{idVendor}=="1217", ATTR{idProduct}=="8321", RUN+="/sbin/modprobe firewire-ohci" This won't work for a built-in firewire-ohci but that's not very common, and this doesn't fix resume.
If concurrent initialization is the problem, could a simple if (dev->vendor == 0x1217 && (dev->device == 0x11f7 || dev->device == 0x13f7)) ssleep(7); /* 7 is lucky */ right at the top of firewire-ohci's pci_probe() and pci_resume() do the trick? Or is it already too late at the time when PCI core calls the driver methods? Is probing and PM resume parallelized in _all_ kernel configurations, or would this hack to be dependent on some CONFIG_XYZ variable to avoid a global stall by this hack?