Good day! After resume from suspend (I use "save to both") my PC's ATAPI-CD-ROM-drive doesn't respond any more. I get this message "syslogd: "kernel:[2784.783099] Disabling IRQ #17". This is the IRQ that the modularized adapter-driver (JMicron) uses. This happens with an unmodified distribution kernel (openSuse "stable", 3.15.7) and with all self-built kernels since 3.15.(0). This issue does not exist with 3.14 and earlier (same hardware/same kernel-configuration). Kind regards Jay
Possible to do a git bisect from v3.14 to v3.15?
(In reply to Aaron Lu from comment #1) > Possible to do a git bisect from v3.14 to v3.15? I'm afraid a git-bisect is beyond my current abilities and it would certainly take me some time to figure out how to do it. Perhaps I should have mentioned that the PC also has an SCSI-CD-ROM-drive which seems to share IRQ #17 with the ATAPI-drive. But this SCSI-drive is absolutely OK after resume. Only the IDE/ATAPI-drive doesn't work. I don't want to lead you in a wrong direction but when I encountered this problem my first thought was that it might have something to do with this new async-feature: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=200421a80f6e0a9e39d698944cc35cba103eb6ce https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3c31b52f96f7b559d950b16113c0f68c72a1985e But I may be completely wrong and apologize in advance to the developers! Jay
Maybe this excerpt from the kernel-log (3.15.8) is of help. After system-start: ... systemd-udevd[335] starting version 195 BIOS EDD facility v0.16 2004-Jun-25, 2 devices found pata_jmicron 0000 2:00.1: enabling device (0000 -> 0001) scsi8 pata_jmicron scsi9 pata_jmicron ata9 PATA max UDMA/100 cmd 0xcc00 ctl 0xc880 bmdma 0xc400 irq 17 ata10 PATA max UDMA/100 cmd 0xc800 ctl 0xc480 bmdma 0xc408 irq 17 i801_smbus 0000 0:1f.3: SMBus using PCI Interrupt ACPI Warning SystemIO range 0x0000000000000828-0x000000000000082f conflicts with OpRegion 0x0000000000000800-0x000000000000084f (\PMRG) (20140214/utaddress-258) ACPI If an ACPI driver is available for this device, you should use it instead of the native driver lpc_ich Resource conflict(s) found affecting gpio_ich input PC Speaker as /devices/platform/pcspkr/input/input4 sd 0 :0:0: Attached scsi generic sg0 type 0 sd 1 :0:0: Attached scsi generic sg1 type 0 ... After resume: ... CPU3 is up ACPI Waking up from system sleep state S3 ehci-pci 0000 0:1d.0: System wakeup disabled by ACPI pata_jmicron 0000 2:00.1: Refused to change power state, currently in D3 ehci-pci 0000 0:1a.0: System wakeup disabled by ACPI PM noirq resume of devices complete after 61.868 msecs PM early resume of devices complete after 0.221 msecs ... Jay
Is building kernel possible for you?
(In reply to Aaron Lu from comment #4) > Is building kernel possible for you? Yes.
You live and learn - as they say. I did a "git bisect" between 3.14 and 3.15. This was the outcome after 13 steps: jr@linux-tez8:~/Downloads/linux-stable> git bisect bad 3d2699bc179a10eee7d2aa1db50f822be01636f7 is the first bad commit commit 3d2699bc179a10eee7d2aa1db50f822be01636f7 Author: Liu, Chuansheng <chuansheng.liu@intel.com> Date: Tue Feb 18 10:28:44 2014 +0800 PM / sleep: Two flags for async suspend_noirq and suspend_late The patch is a helper adding two new flags for implementing async threads for suspend_noirq and suspend_late. Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> :040000 040000 8e646f3aca4f23e3f695107f17cc53c830b71be2 e1a01fb5b148342a4251b6374a9ad656067654d4 M drivers :040000 040000 a28cd1453c85ef1533dda9ad76ce0a340d3371e8 0d579b7c315c284b272f1c0d1c3916391e983676 M include jr@linux-tez8:~/Downloads/linux-stable> Looks like a good starting point. But please consider the fact that this was my first "git bisect" - so I may have made a mistake. Jay
Good to see this, thanks. I think you can verify by building the said commit and then the commit immediately before it. If the first kernel failed and the 2nd kernel works, then it is very likely to be the culprit.
It was late yesterday. To be on the safe side I did another "git bisect" today but narrowed the search to "drivers/base/power" (see "git bisect log" below). Obviously I made a mistake yesterday (probably once bootet the wrong kernel) because today I got this result which I checked twice: jr@linux-tez8:~/Downloads/linux-stable> git bisect good 76569faa62c46382e080c3e190c66e19515aae1c is the first bad commit commit 76569faa62c46382e080c3e190c66e19515aae1c Author: Liu, Chuansheng <chuansheng.liu@intel.com> Date: Tue Feb 18 10:28:45 2014 +0800 PM / sleep: Asynchronous threads for resume_noirq In analogy with commits 5af84b82701a and 97df8c12995, using asynchronous threads can improve the overall resume_noirq time significantly. One typical case is: In resume_noirq phase and for the PCI devices, the function pci_pm_resume_noirq() will be called, and there is one d3_delay (10ms) at least. With the way of asynchronous threads, we just need wait d3_delay time once in parallel for each calling, which saves much time to resume quickly. Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> :040000 040000 e1a01fb5b148342a4251b6374a9ad656067654d4 ab0a5adf507c133d47dd410f8af3a00177f45cee M drivers jr@linux-tez8:~/Downloads/linux-stable> I'm pretty confident that this is the real culprit. Jay --------------------------- jr@linux-tez8:~/Downloads/linux-stable> git bisect log git bisect start '--' 'drivers/base/power' # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14 git bisect good 455c6fdbd219161bd09b1165f11699d6d73de11c # bad: [1860e379875dfe7271c649058aeddffe5afd9d0d] Linux 3.15 git bisect bad 1860e379875dfe7271c649058aeddffe5afd9d0d # good: [165f5fd04aa898fa7dbe4fbe2819cf80453d3bb9] Merge branches 'pm-qos', 'pm-domains' and 'pm-drivers' git bisect good 165f5fd04aa898fa7dbe4fbe2819cf80453d3bb9 # bad: [36cc86e8ec1a0ab309052bc9b25e48a31288b8a5] Merge branches 'pm-runtime' and 'pm-sleep' git bisect bad 36cc86e8ec1a0ab309052bc9b25e48a31288b8a5 # bad: [9e5e7910df824ba02aedd2b5d2ca556426ea6d0b] PM / sleep: Asynchronous threads for resume_early git bisect bad 9e5e7910df824ba02aedd2b5d2ca556426ea6d0b # bad: [76569faa62c46382e080c3e190c66e19515aae1c] PM / sleep: Asynchronous threads for resume_noirq git bisect bad 76569faa62c46382e080c3e190c66e19515aae1c # good: [3d2699bc179a10eee7d2aa1db50f822be01636f7] PM / sleep: Two flags for async suspend_noirq and suspend_late git bisect good 3d2699bc179a10eee7d2aa1db50f822be01636f7 jr@linux-tez8:~/Downloads/linux-stable> ---------------------------
Hi Jay, Could we get one more detailed log/dmesg for this issue? You can enable the printk log more detailed level, and disable console suspend with the below command: echo "N" > /sys/module/printk/parameters/console_suspend Thanks. From the log "kernel:[2784.783099] Disabling IRQ #17", it seems be related with shared irq thing.
One confusing thing is, from #comment 2: " Perhaps I should have mentioned that the PC also has an SCSI-CD-ROM-drive which seems to share IRQ #17 with the ATAPI-drive. But this SCSI-drive is absolutely OK after resume. Only the IDE/ATAPI-drive doesn't work. " If IRQ #17 is disabled, how can the SCSI CDROM drive still work well? ...
Hi Jay, BTW, could you share the info of command? #cat /proc/interrupts The log "Disabling IRQ #17" mostly means the IRQ #17 is coming out without handling for many times, then kernel irq code disabled it.
Created attachment 147541 [details] Bug_81551_Kernel_3.15.9_Log Hi! I have attached the IRQ-table and two excerpts from the kernel-log which hopefully offer enough detail: one from kernel 3.14.17 (OK), the other from 3.15.9. They show what happened after initiating suspend and then resume after a fresh system start. Major differences can be seen from line 98 on. Have a good day. Jay
Created attachment 147551 [details] Bug_81551_Kernel_3.14.17_Log
Created attachment 147561 [details] Bug_81551_Kernel_3.15.9_IRQs
(In reply to chuansheng.liu from comment #9) > Hi Jay, > > Could we get one more detailed log/dmesg for this issue? > You can enable the printk log more detailed level, and disable console > suspend > with the below command: > > echo "N" > /sys/module/printk/parameters/console_suspend > > Thanks. > > From the log "kernel:[2784.783099] Disabling IRQ #17", it seems be related > with shared irq thing. Hi! Did a little experiment (kernel 3.16 / has the same problem) which suggests that the issue is probably not the sharing of an IRQ but pata_jmicron not waking up: To get rid of the SCSI-adapter and the sharing of IRQ #17 I de-selected all SCSI-options except for "*SCSI disk support" and compiled the kernel. As you can see, IRQ #17 now belonged to pata_jmicron alone: ~> cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 119 0 0 0 IO-APIC-edge timer 1: 1476 186 173 177 IO-APIC-edge i8042 8: 0 0 0 1 IO-APIC-edge rtc0 9: 13 1 0 1 IO-APIC-fasteoi acpi 16: 4279 284 274 277 IO-APIC-fasteoi ahci, ehci_hcd:usb1, AVM.1 17: 199995 3 2 1 IO-APIC-fasteoi pata_jmicron 18: 0 0 0 0 IO-APIC-fasteoi i801_smbus 23: 63 15 17 16 IO-APIC-fasteoi ehci_hcd:usb2 40: 6 7 7 6 PCI-MSI-edge mei_me 41: 12529 7089 7076 7024 PCI-MSI-edge ahci 42: 378 98 104 107 PCI-MSI-edge eth0 43: 7850 9087 8685 8144 PCI-MSI-edge i915 44: 47 45 43 45 PCI-MSI-edge snd_hda_intel NMI: 0 0 0 0 Non-maskable interrupts LOC: 86674 66333 59531 56750 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts snip------------------------ Even so, during resume after the first suspend, pata_jmicron refuses to change power state, IRQ #17 complains that "nobody cared" and gets disabled: ... [ 297.560221] ACPI: Waking up from system sleep state S3 [ 297.571257] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI [ 297.571268] ehci-pci 0000:00:1a.0: System wakeup disabled by ACPI [ 297.571287] pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3 [ 297.622560] PM: noirq resume of devices complete after 62.212 msecs [ 297.622754] PM: early resume of devices complete after 0.173 msecs [ 297.622838] mei_me 0000:00:16.0: irq 40 for MSI/MSI-X [ 297.623084] snd_hda_intel 0000:00:1b.0: irq 44 for MSI/MSI-X [ 297.623276] pcieport 0000:00:1c.5: System wakeup disabled by ACPI [ 297.623454] i8042 kbd 00:02: System wakeup disabled by ACPI [ 297.623970] serial 00:06: activated [ 297.629380] sd 0:0:0:0: [sda] Starting disk [ 297.629396] sd 1:0:0:0: [sdb] Starting disk [ 297.680709] r8169 0000:03:00.0 eth0: link down [ 297.794614] ata9.00: configured for UDMA/33 [ 297.852109] i915: No ACPI video bus found [ 297.930086] ata3: SATA link down (SStatus 0 SControl 300) [ 297.935080] ata6: SATA link down (SStatus 0 SControl 300) [ 297.936091] ata5: SATA link down (SStatus 0 SControl 300) [ 297.938085] ata4: SATA link down (SStatus 0 SControl 300) [ 297.939101] ata8: SATA link down (SStatus 0 SControl 300) [ 297.939138] ata7: SATA link down (SStatus 0 SControl 300) [ 297.983093] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 297.985829] ata2.00: configured for UDMA/133 [ 299.221098] irq 17: nobody cared (try booting with the "irqpoll" option) [ 299.221101] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-1.g8038aea-desktop #4 [ 299.221101] Hardware name: MSI MS-7637/H55-GD65 (MS-7637) , BIOS V1.5 09/16/2010 [ 299.221103] 0000000000000000 ffff880329779c8c ffffffff81599f59 ffff880329779c00 [ 299.221104] ffffffff810a30f6 ffff880329779c00 0000000000000011 0000000000000000 [ 299.221105] ffffffff810a3636 ffffffffffd1170a 0000000000000000 0000000000000000 [ 299.221106] Call Trace: [ 299.221112] <IRQ> [<ffffffff81599f59>] ? dump_stack+0x49/0x6a [ 299.221117] [<ffffffff810a30f6>] ? __report_bad_irq+0x36/0xd0 [ 299.221118] [<ffffffff810a3636>] ? note_interrupt+0x266/0x2c0 [ 299.221120] [<ffffffff810a0db7>] ? handle_irq_event_percpu+0x87/0x1f0 [ 299.221121] [<ffffffff810a0f61>] ? handle_irq_event+0x41/0x70 [ 299.221122] [<ffffffff810a4195>] ? handle_fasteoi_irq+0x85/0x150 [ 299.221125] [<ffffffff81005485>] ? handle_irq+0x15/0x20 [ 299.221126] [<ffffffff81004db8>] ? do_IRQ+0x58/0x110 [ 299.221128] [<ffffffff815a076d>] ? common_interrupt+0x6d/0x6d [ 299.221132] <EOI> [<ffffffff81482d49>] ? cpuidle_enter_state+0x59/0xe0 [ 299.221133] [<ffffffff81482d42>] ? cpuidle_enter_state+0x52/0xe0 [ 299.221135] [<ffffffff81090401>] ? cpu_startup_entry+0x2c1/0x490 [ 299.221138] [<ffffffff8182e028>] ? start_kernel+0x454/0x45f [ 299.221139] [<ffffffff8182d9ec>] ? set_init_arg+0x50/0x50 [ 299.221141] [<ffffffff8182d117>] ? early_idt_handlers+0x117/0x120 [ 299.221142] [<ffffffff8182d117>] ? early_idt_handlers+0x117/0x120 [ 299.221143] [<ffffffff8182d704>] ? x86_64_start_kernel+0x152/0x161 [ 299.221144] handlers: [ 299.221147] [<ffffffff8140c3b0>] ata_bmdma_interrupt [ 299.221147] Disabling IRQ #17 [ 299.292022] r8169 0000:03:00.0 eth0: link up [ 299.815672] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 299.828839] ata1.00: configured for UDMA/133 [ 299.832885] input input1: event field not found [ 299.832887] input input1: event field not found [ 299.832888] input input1: event field not found [ 299.832889] input input1: event field not found [ 299.832891] input input1: event field not found [ 299.832892] input input1: event field not found [ 299.832893] input input1: event field not found [ 299.833015] PM: resume of devices complete after 2210.818 msecs [ 299.944185] Restarting kernel threads ... done. [ 299.944376] Restarting tasks ... done. [ 301.535566] IPv4: martian source 255.255.255.255 from xxx.xxx.x.x, on dev eth0 [ 301.535574] ll header: 00000000: ff ff ff ff ff ff 00 0f b5 50 0e 88 08 00 .........P.... [ 301.554978] IPv4: martian source 255.255.255.255 from xxx.xxx.x.x, on dev eth0 [ 301.554998] ll header: 00000000: ff ff ff ff ff ff 00 0f b5 50 0e 88 08 00 .........P.... [ 302.792918] ata9.00: qc timeout (cmd 0xa0) [ 302.792923] ata9.00: TEST_UNIT_READY failed (err_mask=0x5) [ 302.953450] ata9.00: configured for UDMA/33 [ 307.951568] ata9.00: qc timeout (cmd 0xa0) [ 307.951577] ata9.00: TEST_UNIT_READY failed (err_mask=0x5) [ 307.951583] ata9.00: limiting speed to UDMA/33:PIO3 [ 308.112032] ata9.00: configured for UDMA/33 [ 313.110354] ata9.00: qc timeout (cmd 0xa0) [ 313.110363] ata9.00: TEST_UNIT_READY failed (err_mask=0x5) [ 313.110367] ata9.00: disabled [ 313.110396] ata9: soft resetting link [ 313.261355] ata9: EH complete ----------------------------------------------------- Hope this helps. Jay
Good finding, Jay. The log "pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3" should be from pci_pm_resume_noirq() calling. If enabling async, it is possible the pata_jmicron pci_pm_resume_noirq()'s execution is mixed with his parent or children. So, Could you help to give one pci tree list? And could you help to check if the device pata_jmicron is enabling async PM? Thanks.
BTW, Jay, could you help to try the below debugging patch to see if it is the issue about d3_delay? Thanks. diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c index 4d1a5d2..fa02003 100644 --- a/drivers/ata/pata_jmicron.c +++ b/drivers/ata/pata_jmicron.c @@ -142,6 +142,7 @@ static int jmicron_init_one (struct pci_dev *pdev, const struct pci_device_id *i .port_ops = &jmicron_ops, }; const struct ata_port_info *ppi[] = { &info, NULL }; + pdev->d3_delay = 200; return ata_pci_bmdma_init_one(pdev, ppi, &jmicron_sht, NULL, 0); }
(In reply to chuansheng.liu from comment #17) > BTW, Jay, could you help to try the below debugging patch to see if it is > the issue about d3_delay? > > Thanks. > > diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c > index 4d1a5d2..fa02003 100644 > --- a/drivers/ata/pata_jmicron.c > +++ b/drivers/ata/pata_jmicron.c > @@ -142,6 +142,7 @@ static int jmicron_init_one (struct pci_dev *pdev, const > struct pci_device_id *i > .port_ops = &jmicron_ops, > }; > const struct ata_port_info *ppi[] = { &info, NULL }; > + pdev->d3_delay = 200; > > return ata_pci_bmdma_init_one(pdev, ppi, &jmicron_sht, NULL, 0); > } Hi Liu! Patch works! Thank you! Details later. Jay
Jay, Could you help to do the below two experiment again? 1/ Disabling the pm_async to see if issue exists; #cat /sys/power/pm_async #echo 0 > /sys/power/pm_async 2/ Changing the d3_delay to 20 to see if it is enough; + pdev->d3_delay = 20; BTW, please share your lspci -v -v -v result if possible. Thanks.
(In reply to chuansheng.liu from comment #19) > Jay, > > Could you help to do the below two experiment again? > 1/ Disabling the pm_async to see if issue exists; > #cat /sys/power/pm_async > #echo 0 > /sys/power/pm_async > > 2/ Changing the d3_delay to 20 to see if it is enough; > + pdev->d3_delay = 20; > > BTW, please share your lspci -v -v -v result if possible. > > Thanks. Hi! After some more testing... ad 1) Tested with 3.15.9 #echo 0 > /sys/power/pm_async Works, problem gone. But only if executed BEFORE the first suspend/resume. [ 350.787603] ACPI: Waking up from system sleep state S3 [ 350.820498] ehci-pci 0000:00:1a.0: System wakeup disabled by ACPI [ 350.842488] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI [ 350.936685] PM: noirq resume of devices complete after 148.973 msecs [ 350.936824] PM: early resume of devices complete after 0.118 msecs [ 351.406335] i915: No ACPI video bus found [ 351.407349] mei_me 0000:00:16.0: irq 40 for MSI/MSI-X ad 2) Tested with 3.16.0 20/40: bad 50/60: good - but message: "pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3" 70/80/90/100: good good = After suspend/resume and inserting a CD the drive is automatically recognized and the CD can be accessed. bad = The drive is not automatically recognized and the CD cannot be accessed. For 70: [ 130.397797] ACPI: Waking up from system sleep state S3 [ 130.408881] ehci-pci 0000:00:1a.0: System wakeup disabled by ACPI [ 130.408906] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI [ 130.468719] PM: noirq resume of devices complete after 70.795 msecs [ 130.468894] PM: early resume of devices complete after 0.154 msecs [ 130.468978] mei_me 0000:00:16.0: irq 40 for MSI/MSI-X For 100: [ 196.684920] ACPI: Waking up from system sleep state S3 [ 196.695931] ehci-pci 0000:00:1a.0: System wakeup disabled by ACPI [ 196.696028] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI [ 196.785888] PM: noirq resume of devices complete after 100.847 msecs [ 196.786106] PM: early resume of devices complete after 0.197 msecs [ 196.786202] mei_me 0000:00:16.0: irq 40 for MSI/MSI-X ------------------------------------------- lspci -v -v -v for the JMicron- and the Symbios-adapter. 02:00.1 IDE interface: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 03) (prog-if 85 [Master SecO PriO]) Subsystem: Micro-Star International Co., Ltd. Device 7637 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 Interrupt: pin B routed to IRQ 17 Region 0: I/O ports at cc00 [size=8] Region 1: I/O ports at c880 [size=4] Region 2: I/O ports at c800 [size=8] Region 3: I/O ports at c480 [size=4] Region 4: I/O ports at c400 [size=16] Capabilities: [68] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: pata_jmicron 04:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c810 (rev 12) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (2000ns min, 16000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 17 Region 0: I/O ports at e000 [size=256] Region 1: Memory at fbfff800 (32-bit, non-prefetchable) [size=256] Kernel driver in use: sym53c8xx ------------------------------------------- Have a good day! Jay p.s.: At the end of line #6 ("struct...") of your patch something is missing. And you owe me an aspirin now ;)
Thanks your details, Jay! Here 70ms is one good point, but we can not explain why disabling async can let the issue gone; Could you help again? 1/ lspci -v -t 2/ Try again with delay=60,70ms and without async with below debugging patch? We need to understand if this device is depended on other devices powering on, but the depended devices are not its parent, then .... diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index b67d9ae..fe52629 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -479,6 +479,8 @@ static int device_resume_noirq(struct device *dev, pm_message_t state, bool asyn TRACE_DEVICE(dev); TRACE_RESUME(0); + dev_info(&dev->dev, "async = %d\n", async); + if (dev->power.syscore || dev->power.direct_complete) goto Out;
(In reply to chuansheng.liu from comment #21) > Thanks your details, Jay! > > Here 70ms is one good point, but we can not explain why disabling async can > let the issue gone; > > Could you help again? > 1/ lspci -v -t > > 2/ Try again with delay=60,70ms and without async with below debugging patch? > We need to understand if this device is depended on other devices powering > on, > but the depended devices are not its parent, then .... > > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c > index b67d9ae..fe52629 100644 > --- a/drivers/base/power/main.c > +++ b/drivers/base/power/main.c > @@ -479,6 +479,8 @@ static int device_resume_noirq(struct device *dev, > pm_message_t state, bool asyn > TRACE_DEVICE(dev); > TRACE_RESUME(0); > > + dev_info(&dev->dev, "async = %d\n", async); > + > if (dev->power.syscore || dev->power.direct_complete) > goto Out; OK ad 1) lspci -v -t -+-[0000:ff]-+-00.0 Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers | +-00.1 Intel Corporation Core Processor QuickPath Architecture System Address Decoder | +-02.0 Intel Corporation Core Processor QPI Link 0 | +-02.1 Intel Corporation Core Processor QPI Physical 0 | +-02.2 Intel Corporation Core Processor Reserved | \-02.3 Intel Corporation Core Processor Reserved \-[0000:00]-+-00.0 Intel Corporation Core Processor DRAM Controller +-02.0 Intel Corporation Core Processor Integrated Graphics Controller +-16.0 Intel Corporation 5 Series/3400 Series Chipset HECI Controller +-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller +-1b.0 Intel Corporation 5 Series/3400 Series Chipset High Definition Audio +-1c.0-[01]-- +-1c.4-[02]--+-00.0 JMicron Technology Corp. JMB363 SATA/IDE Controller | \-00.1 JMicron Technology Corp. JMB363 SATA/IDE Controller +-1c.5-[03]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller +-1d.0 Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller +-1e.0-[04]--+-00.0 AVM GmbH A1 ISDN [Fritz] | \-01.0 LSI Logic / Symbios Logic 53c810 +-1f.0 Intel Corporation 5 Series Chipset LPC Interface Controller +-1f.2 Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller \-1f.3 Intel Corporation 5 Series/3400 Series Chipset SMBus Controller ad 2) Tomorrow (you time). Jay
(In reply to chuansheng.liu from comment #21) > 2/ Try again with delay=60,70ms and without async with below debugging patch? > > + dev_info(&dev->dev, "async = %d\n", async); > + > if (dev->power.syscore || dev->power.direct_complete) > goto Out; Thanks Jay. It should be: diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index b67d9ae..0408ecd 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -479,6 +479,8 @@ static int device_resume_noirq(struct device *dev, pm_message_t state, bool asyn TRACE_DEVICE(dev); TRACE_RESUME(0); + dev_info(dev, "async = %d\n", async); + if (dev->power.syscore || dev->power.direct_complete) goto Out;
Updated the debugging info patch again: diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index b67d9ae..8c8e6dd 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -479,6 +479,8 @@ static int device_resume_noirq(struct device *dev, pm_message_t state, bool asyn TRACE_DEVICE(dev); TRACE_RESUME(0); + dev_info(dev, "async = %d, start\n", async); + if (dev->power.syscore || dev->power.direct_complete) goto Out; @@ -512,6 +514,7 @@ static int device_resume_noirq(struct device *dev, pm_message_t state, bool asyn Out: complete_all(&dev->power.completion); TRACE_RESUME(error); + dev_info(dev, "error = %d, end\n", error); return error; }
Created attachment 148161 [details] 2014-08-25_dmesg_patch_2_60ms
Created attachment 148171 [details] 2014-08-25_dmesg_patch_2_70ms
Created attachment 148181 [details] 2014-08-25_dmesg_patch_2_20ms_pm_async_0
Hi! Please find attached the dmesg-output for pdev->d3_delay = 60; pdev->d3_delay = 70; pdev->d3_delay = 20 with pm_async = 0; I couldn't find anything with "Aha!"-potential for me. But perhaps with the eyes of the expert... Good luck! The functional outcome was the same as already reported. Jay.
Hi Jay, My fault, the log you caught are good. Could you catch one BAD case? Such as pdev->d3_delay = 20 with pm_async = 1; Thanks.
BTW, in the 60ms and 70ms log, I didn't find the start for device pata_jmicron: [ 222.158394] pata_jmicron 0000:02:00.1: error = 0, end Just ending is there.
Ah. Jay, From the 60ms and 70ms log, it seems device "pata_jmicron 0000:02:00.1" depends on the device "ahci 0000:02:00.0", but pata_jmicron is async mode, and ahci is non-async mode, need your complete log to confirm. But from the device tree, we didn't find relationship for both devices. +-1c.4-[02]--+-00.0 JMicron Technology Corp. JMB363 SATA/IDE Controller | \-00.1 JMicron Technology Corp. JMB363 SATA/IDE Controller
(In reply to chuansheng.liu from comment #31) > Ah. > > Jay, > > From the 60ms and 70ms log, it seems device "pata_jmicron 0000:02:00.1" > depends on > the device "ahci 0000:02:00.0", but pata_jmicron is async mode, and ahci is > non-async mode, need your complete log to confirm. > > But from the device tree, we didn't find relationship for both devices. > > +-1c.4-[02]--+-00.0 JMicron Technology Corp. JMB363 SATA/IDE > Controller > | \-00.1 JMicron Technology Corp. JMB363 SATA/IDE > Controller Jay, So could you try the below patch? Thanks. Seems it is just JMB363 related issue, that two controllers have the dependency. Here let's disable the async method for it. diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c index 4d1a5d2..52f1353 100644 --- a/drivers/ata/pata_jmicron.c +++ b/drivers/ata/pata_jmicron.c @@ -142,7 +142,7 @@ static int jmicron_init_one (struct pci_dev *pdev, const struct pci_device_id *i .port_ops = &jmicron_ops, }; const struct ata_port_info *ppi[] = { &info, NULL }; - + device_disable_async_suspend(&pdev->dev); return ata_pci_bmdma_init_one(pdev, ppi, &jmicron_sht, NULL, 0); }
Or like this: diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c index 4d1a5d2..c98c7c7 100644 --- a/drivers/ata/pata_jmicron.c +++ b/drivers/ata/pata_jmicron.c @@ -132,6 +132,7 @@ static struct ata_port_operations jmicron_ops = { static int jmicron_init_one (struct pci_dev *pdev, const struct pci_device_id *id) { + int error; static const struct ata_port_info info = { .flags = ATA_FLAG_SLAVE_POSS, @@ -143,7 +144,11 @@ static int jmicron_init_one (struct pci_dev *pdev, const struct pci_device_id *i }; const struct ata_port_info *ppi[] = { &info, NULL }; - return ata_pci_bmdma_init_one(pdev, ppi, &jmicron_sht, NULL, 0); + error = ata_pci_bmdma_init_one(pdev, ppi, &jmicron_sht, NULL, 0); + if (!error) + device_disable_async_suspend(&pdev->dev); + + return error; }
(In reply to chuansheng.liu from comment #30) > BTW, in the 60ms and 70ms log, I didn't find the start for device > pata_jmicron: > > [ 222.158394] pata_jmicron 0000:02:00.1: error = 0, end > > Just ending is there. OK - that was a bit sparse. Sorry. See new attachement. Jay
Created attachment 148381 [details] 2014-08-25_dmesg_patch_2_70ms_complete
(In reply to chuansheng.liu from comment #29) > Hi Jay, > > My fault, the log you caught are good. > Could you catch one BAD case? Such as pdev->d3_delay = 20 with pm_async = 1; > > Thanks. No problem. See new attachement. But not much new info.
Created attachment 148391 [details] 2014-08-25_dmesg_patch_2_20ms_pm_async_1
(In reply to chuansheng.liu from comment #33) > Or like this: > diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c > index 4d1a5d2..c98c7c7 100644 > --- a/drivers/ata/pata_jmicron.c > +++ b/drivers/ata/pata_jmicron.c > @@ -132,6 +132,7 @@ static struct ata_port_operations jmicron_ops = { > > static int jmicron_init_one (struct pci_dev *pdev, const struct > pci_device_id *id) > { > + int error; > static const struct ata_port_info info = { > .flags = ATA_FLAG_SLAVE_POSS, > > @@ -143,7 +144,11 @@ static int jmicron_init_one (struct pci_dev *pdev, > const struct pci_device_id *i > }; > const struct ata_port_info *ppi[] = { &info, NULL }; > > - return ata_pci_bmdma_init_one(pdev, ppi, &jmicron_sht, NULL, 0); > + error = ata_pci_bmdma_init_one(pdev, ppi, &jmicron_sht, NULL, 0); > + if (!error) > + device_disable_async_suspend(&pdev->dev); > + > + return error; > } Hi! Tried this patch (named it "3b") first, but could not apply it (kernel 3.16.0): "patch: **** malformed patch at line 7: static int jmicron_init_one (struct pci_dev *pdev, const struct pci_device_id *id)" So I edited the pata_jmicron.c directly, according to your patch and without "pdev->d3_delay = 70;" However, after suspend/resume: [ 177.948595] pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3 ... [ 179.414978] irq 17: nobody cared (try booting with the "irqpoll" option) [ 179.414981] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 3.16.0-1.g8038aea-desktop #23 [ 179.414982] Hardware name: MSI MS-7637/H55-GD65 (MS-7637) , BIOS V1.5 09/16/2010 [ 179.414984] 0000000000000000 ffff880329777c8c ffffffff81599de9 ffff880329777c00 [ 179.414985] ffffffff810a30f6 ffff880329777c00 0000000000000011 0000000000000000 [ 179.414987] ffffffff810a3636 ffffffffffd1170a 0000000000000000 0000000000000000 [ 179.414987] Call Trace: [ 179.414996] <IRQ> [<ffffffff81599de9>] ? dump_stack+0x49/0x6a snip [ 179.415039] [<ffffffff8140c3d0>] ata_bmdma_interrupt [ 179.415039] Disabling IRQ #17 Then tried the first patch ("3a"; worked): Now with this patch and without "pdev->d3_delay = 70;": [ 179.770127] pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3 ... [ 179.820960] PM: noirq resume of devices complete after 62.340 msecs [ 179.821175] PM: early resume of devices complete after 0.195 msecs [ 179.821254] mei_me 0000:00:16.0: irq 40 for MSI/MSI-X [ 179.822215] pcieport 0000:00:1c.5: System wakeup disabled by ACPI [ 179.822303] snd_hda_intel 0000:00:1b.0: irq 44 for MSI/MSI-X And after inserting the CD it wasn't recognized and could not be accessed. And after a second suspend/resume: [ 3457.132686] irq 17: nobody cared (try booting with the "irqpoll" option) [ 3457.132689] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 3.16.0-1.g8038aea-desktop #23 [ 3457.132690] Hardware name: MSI MS-7637/H55-GD65 (MS-7637) , BIOS V1.5 09/16/2010 [ 3457.132692] 0000000000000000 ffff880329779c8c ffffffff81599de9 ffff880329779c00 [ 3457.132693] ffffffff810a30f6 ffff880329779c00 0000000000000011 0000000000000000 [ 3457.132694] ffffffff810a3636 ffffffffffd1170a 0000000000000000 0000000000000000 snip [ 3457.132748] [<ffffffff8140c3d0>] ata_bmdma_interrupt [ 3457.132749] Disabling IRQ #17 To me it seems that the JMicron-adapter simply does not react to "device_disable_async_suspend(&pdev->dev);" but only to "pm_async = 0". Apparently the async-method cannot be switched off for this adapter alone. After going back to "pdev->d3_delay = 70;" everything is fine again. Jay
(In reply to Jay from comment #35) > Created attachment 148381 [details] > 2014-08-25_dmesg_patch_2_70ms_complete Still missed some info here? It is due to your log buffer is limited. Could you help to enlarge it to try? CONFIG_LOG_BUF_SHIFT
(In reply to Jay from comment #38) > (In reply to chuansheng.liu from comment #33) > To me it seems that the JMicron-adapter simply does not react to > "device_disable_async_suspend(&pdev->dev);" but only to "pm_async = 0". > Apparently the async-method cannot be switched off for this adapter alone. Thanks Jay. Could you check the below async files to see something? #cat /sys/devices/..../0000:02:00.0/power/async #cat /sys/devices/..../0000:02:00.1/power/async If you can not find the "async" file, please try to enable CONFIG_PM_ADVANCED_DEBUG at first. And if these both files are enabled, please try to disable them to see if the issue still existed.
Hi! Thanks for your messages. I'm afraid the kernel-log-buffer is already set to its max: CONFIG_LOG_BUF_SHIFT = 17 = 128kb. Even after enabling PM_ADVANCED_DEBUG I could not find #cat /sys/devices/..../0000:02:00.0/power/async #cat /sys/devices/..../0000:02:00.1/power/async What I found is this: cat /sys/devices/breakpoint/power/async disabled cat /sys/devices/cpu/power/async disabled cat /sys/devices/software/power/async disabled cat /sys/devices/tracepoint/power/async disabled cat /sys/devices/uncore/power/async disabled Here is an excerpt from the demsg -k after the first suspend/resume after a fresh system-start (see new attachment): Is it OK that the CD-ROM-drive (ata9) is starting in async-mode? Or is this unrelated to device_disable_async_suspend? ... [ 879.261744] ata9: async = 1, start [ 879.261758] ata10: async = 1, start [ 879.261772] scsi host8: async = 1, start [ 879.261786] scsi_host host8: async = 1, start [ 879.261800] scsi host9: async = 1, start [ 879.261813] scsi_host host9: async = 1, start [ 879.261827] scsi target8:0:0: async = 1, start [ 879.261839] sr 8:0:0:0: async = 1, start [ 879.261852] scsi_device 8:0:0:0: async = 1, start [ 879.271446] pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3 ... [ 880.509826] Disabling IRQ #17 ... Jay
Created attachment 148431 [details] 2014-08-27_dmesg_patch_3a
(In reply to Jay from comment #41) > Hi! > > Thanks for your messages. > > I'm afraid the kernel-log-buffer is already set to its max: > CONFIG_LOG_BUF_SHIFT = 17 = 128kb. Could it be 18 or 19? > > Even after enabling PM_ADVANCED_DEBUG I could not find Hmm. Are you sure it is enabled? You should enable PM_DEBUG also since PM_ADVANCED_DEBUG depends on it. > #cat /sys/devices/..../0000:02:00.0/power/async > #cat /sys/devices/..../0000:02:00.1/power/async >
(In reply to chuansheng.liu from comment #43) > (In reply to Jay from comment #41) > > Hi! > > > > Thanks for your messages. > > > > I'm afraid the kernel-log-buffer is already set to its max: > > CONFIG_LOG_BUF_SHIFT = 17 = 128kb. > Could it be 18 or 19? Now set to 19, see new attachement. > > > > Even after enabling PM_ADVANCED_DEBUG I could not find > Hmm. Are you sure it is enabled? > You should enable PM_DEBUG also since PM_ADVANCED_DEBUG depends on it. Both were enabled. > > > #cat /sys/devices/..../0000:02:00.0/power/async > > #cat /sys/devices/..../0000:02:00.1/power/async I cannot find these paths in /sys/devices/ on my system. Where shall I look for the files? Please take a look at the attachment (.jepg). Jay
Created attachment 148441 [details] 2014-08-27_dmesg_patch_3a_2
Created attachment 148451 [details] Bug 81551_contents_sys_devices
(In reply to Jay from comment #44) > (In reply to chuansheng.liu from comment #43) > Now set to 19, see new attachement. Now we can see the device: [ 116.654313] pata_jmicron 0000:02:00.1: async = 0, start But still missed some logs, could you set BUF to 21? > > > #cat /sys/devices/..../0000:02:00.0/power/async > > > #cat /sys/devices/..../0000:02:00.1/power/async > > I cannot find these paths in /sys/devices/ on my system. Where shall I look > for the files? Please take a look at the attachment (.jepg). The file should in the directory /sys/device/pci0000:00/0000:00:1c.4/, there should be two async files in deeper sub-directory.
Thanks for your assistance. One step closer to a solution now, I think. > cat /sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/power/async enabled > cat /sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.1/power/async disabled # echo disabled > /sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/power/async > cat /sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/power/async disabled Success. After suspend/resume the CD was automatically recognized and accessible. Same after a second suspend/resume. No warnings in the dmesg-output (see attachment). The noirq-resume-time of 72.394 ms is interesting as it is approximately the d3_delay-value where the "Refused to change power state,..."-warning disappeared. ... [ 322.163865] PM: noirq resume of devices complete after 72.394 msecs [ 322.164148] PM: early resume of devices complete after 0.262 msecs ... See below for a lspci-v-v-v - synopsis of the JMicron-controller. Jay 02:00.0 SATA controller: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 03) (prog-if 01 [AHCI 1.0]) Subsystem: Micro-Star International Co., Ltd. Device 7637 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: 32 bytes Interrupt: pin A routed to IRQ 16 Region 5: Memory at fbdfe000 (32-bit, non-prefetchable) [size=8K] Capabilities: [68] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Express (v1) Legacy Endpoint, MSI 01 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Kernel driver in use: ahci 02:00.1 IDE interface: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 03) (prog-if 85 [Master SecO PriO]) Subsystem: Micro-Star International Co., Ltd. Device 7637 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 Interrupt: pin B routed to IRQ 17 Region 0: I/O ports at cc00 [size=8] Region 1: I/O ports at c880 [size=4] Region 2: I/O ports at c800 [size=8] Region 3: I/O ports at c480 [size=4] Region 4: I/O ports at c400 [size=16] Capabilities: [68] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: pata_jmicron
Created attachment 148521 [details] 2014-08-27_dmesg_patch_3a_both_async_disabled
How about the test result with below command? #echo disabled > /sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/power/async #echo enabled > /sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.1/power/async Thanks.
(In reply to chuansheng.liu from comment #50) > How about the test result with below command? > > #echo disabled > > /sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/power/async > #echo enabled > /sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.1/power/async > > Thanks. Hi! > cat /sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/power/async disabled > cat /sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.1/power/async enabled Doesn't work: "[ 617.147932] Disabling IRQ #17" Jay
Thanks Jay. That proved that the two controller 02:00.0 and 02:00.1 have the powering on dependency, although they don't have child-parent relationship. Could you try this patch? Before you do the suspend test, you can check if the two devices async have been disabled as the patch expected. Thanks.
Created attachment 148751 [details] Disabling the async for 363/361 SATA/PATA controllers
Hi! Received the e-mails somewhat delayed, probably due to problems at my provider. Well - good news and bad news. The good news first: Applied your latest patch to kernels 3.16.0 and 3.15.9 and it worked for both. Tested it thoroughly, I think. As I see it, Bug 81551 is solved. Thank you! Now for the bad news. While testing, another problem surfaced that at first I thought was perhaps connected to the patch - but it is not: After two successful suspends (and checking the CD-ROM-drive) the third s2disk-process (save2both) was aborted after only a part of the image had been written to disk. The system then returned to the desktop. This happened although only a small amount of RAM was used (ca. 7%) and although there is ample space in the swap-partition. The CD-ROM-drive was always unaffected by this, it still worked after the aborted suspend. The reason why I'm sure that this is a different issue is because I not only saw it with 3.16 and 3.15.9, but later also with 3.14.17. Where I had not seen it before. But until now I surely never made 3 suspends in a row like in the tests. It was reproducible and except for one instance always happened after the third suspend. Any ideas? A new bug-report? Kind regards. Jay p.s.: After applying the patch in 3.16 and before the first suspend/resume: > cat /sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/power/async disabled > cat /sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.1/power/async disabled
(In reply to Jay from comment #54) > Well - good news and bad news. > > The good news first: Applied your latest patch to kernels 3.16.0 and 3.15.9 > and it worked for both. Tested it thoroughly, I think. > > As I see it, Bug 81551 is solved. > > Thank you! Thanks your help indeed. > > Now for the bad news. > > While testing, another problem surfaced that at first I thought was perhaps > connected to the patch - but it is not: > > The reason why I'm sure that this is a different issue is because I not only > saw it with 3.16 and 3.15.9, but later also with 3.14.17. Where I had not > seen it before. But until now I surely never made 3 suspends in a row like > in the tests. So even with the original 3.14.17, the issue still existed? not connected to the patch? Thanks. > Any ideas? A new bug-report? If it happened also at original 3.14.17, then it should be one new BUG. Please help to upload some logs with one new BUG, and the async series patchset just existed from 3.15. It is better to do some bisection for it also.
(In reply to Jay from comment #54) [cut] > Any ideas? A new bug-report? Yes, a new report, please.
I still have the bug despite the patch : https://bugzilla.kernel.org/attachment.cgi?id=148751 because probably the patch seems incomplete, I have a Jmicron JMB363/JMB368 SATA/IDE controler, and an IDE hardisk is attached on JMB368 ( IDE controler ), you should add a new condition in your "if statement" in order to target also "PCI_DEVICE_ID_JMICRON_JMB368" and not only JMB363/JMB368 : + if (pdev->vendor == PCI_VENDOR_ID_JMICRON && + (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 || + pdev->device == PCI_DEVICE_ID_JMICRON_JMB361 || + pdev->device == PCI_DEVICE_ID_JMICRON_JMB368 )) + device_disable_async_suspend(&pdev->dev); what do you think ?
lspci -v : 03:00.0 SATA controller: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 10) (prog-if 01 [AHCI 1.0]) Subsystem: JMicron Technology Corp. JMB363 SATA/IDE Controller Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at e7000000 (32-bit, non-prefetchable) [size=512] [virtual] Expansion ROM at e6000000 [disabled] [size=64K] Capabilities: [8c] Power Management version 3 Capabilities: [50] Express Legacy Endpoint, MSI 00 Kernel driver in use: ahci Kernel modules: ahci 03:00.1 IDE interface: JMicron Technology Corp. JMB368 IDE controller (rev 10) (prog-if 85 [Master SecO PriO]) Subsystem: JMicron Technology Corp. Device 1368 Flags: bus master, fast devsel, latency 0, IRQ 18 I/O ports at b000 [size=8] I/O ports at b100 [size=4] I/O ports at b200 [size=8] I/O ports at b300 [size=4] I/O ports at b400 [size=16] Capabilities: [8c] Power Management version 3 Capabilities: [50] Express Legacy Endpoint, MSI 00 Kernel driver in use: pata_jmicron Kernel modules: pata_jmicron, pata_acpi, ata_generic we need to be sure that the patch will also target "JMB368 IDE controller" and not only JMB361/JMB363
well I tried to add "pdev->device == PCI_DEVICE_ID_JMICRON_JMB368" in the "if statement" in the patch : + if (pdev->vendor == PCI_VENDOR_ID_JMICRON && + (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 || + pdev->device == PCI_DEVICE_ID_JMICRON_JMB361 || + pdev->device == PCI_DEVICE_ID_JMICRON_JMB368 )) + device_disable_async_suspend(&pdev->dev); but I still get the bug, my JMB363/368 SATA/IDE controler refuses to work after a standby : [ 96.893714] pata_jmicron 0000:03:00.1: Refused to change power state, currently in D3 the only solution is to do a "echo 0 > /sys/power/pm_async" before doing a standby
Created attachment 151321 [details] dmesg output after a standby here is the dmesg output after a standby, we can see this line : [ 96.893714] pata_jmicron 0000:03:00.1: Refused to change power state, currently in D3 and my IDE harddisk connected to Jmicron JMB363/368 doesn't work after a standby, the kernel used was 3.16.3 with this patch : https://bugzilla.kernel.org/attachment.cgi?id=148751
Created attachment 151391 [details] dmesg output with kernel 3.17rc06 after standby, bug is still here I tried with kernel 3.17rc6 and it's the same problem : "SATA/IDE controler Jmicron JMB363/368" doesn't work after a standby, here is the dmesg output after the standby, I still have these messages error : [ 137.363555] pata_jmicron 0000:03:00.1: Refused to change power state, currently in D3 and [ 304.379996] ata1: lost interrupt (Status 0x58) [ 304.395183] ata1: drained 65536 bytes to clear DRQ [ 304.507727] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 [ 304.507734] ata1.01: failed command: READ DMA [ 304.507738] ata1.01: cmd c8/00:08:97:a9:40/00:00:00:00:00/f2 tag 0 dma 4096 in res 40/00:00:00:4f:c2/00:00:00:00:00/10 Emask 0x20 (host bus error) [ 304.507739] ata1.01: status: { DRDY }
Hello Barto, Please try this patch based on the latest code base, thanks. diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index a0cc0ed..ae1cd4d 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -1346,9 +1346,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) * powered on successfully, so here we disable the async suspend * method for these chips. */ - if (pdev->vendor == PCI_VENDOR_ID_JMICRON && - (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 || - pdev->device == PCI_DEVICE_ID_JMICRON_JMB361)) + if (pdev->vendor == PCI_VENDOR_ID_JMICRON) device_disable_async_suspend(&pdev->dev); /* acquire resources */ diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c index 47e418b..2150d3d 100644 --- a/drivers/ata/pata_jmicron.c +++ b/drivers/ata/pata_jmicron.c @@ -150,9 +150,7 @@ static int jmicron_init_one (struct pci_dev *pdev, const struct pci_device_id *i * powered on successfully, so here we disable the async suspend * method for these chips. */ - if (pdev->vendor == PCI_VENDOR_ID_JMICRON && - (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 || - pdev->device == PCI_DEVICE_ID_JMICRON_JMB361)) + if (pdev->vendor == PCI_VENDOR_ID_JMICRON) device_disable_async_suspend(&pdev->dev); return ata_pci_bmdma_init_one(pdev, ppi, &jmicron_sht, NULL, 0);
Hello Chuansheng, I have an error message if I want to apply your patch : patching file drivers/ata/ahci.c Hunk #1 FAILED at 1346. 1 out of 1 hunk FAILED -- saving rejects to file drivers/ata/ahci.c.rej patching file drivers/ata/pata_jmicron.c Hunk #1 FAILED at 150. 1 out of 1 hunk FAILED -- saving rejects to file drivers/ata/pata_jmicron.c.rej I tried with kernel 3.17-rc6, can you provide a compatible patch for kernel 3.17-rc6 ?
This patch is based on 3.17-rc6, which is the same as before. diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index a0cc0ed..ae1cd4d 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -1346,9 +1346,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) * powered on successfully, so here we disable the async suspend * method for these chips. */ - if (pdev->vendor == PCI_VENDOR_ID_JMICRON && - (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 || - pdev->device == PCI_DEVICE_ID_JMICRON_JMB361)) + if (pdev->vendor == PCI_VENDOR_ID_JMICRON) device_disable_async_suspend(&pdev->dev); /* acquire resources */ diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c index 47e418b..2150d3d 100644 --- a/drivers/ata/pata_jmicron.c +++ b/drivers/ata/pata_jmicron.c @@ -150,9 +150,7 @@ static int jmicron_init_one (struct pci_dev *pdev, const struct pci_device_id *i * powered on successfully, so here we disable the async suspend * method for these chips. */ - if (pdev->vendor == PCI_VENDOR_ID_JMICRON && - (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 || - pdev->device == PCI_DEVICE_ID_JMICRON_JMB361)) + if (pdev->vendor == PCI_VENDOR_ID_JMICRON) device_disable_async_suspend(&pdev->dev); return ata_pci_bmdma_init_one(pdev, ppi, &jmicron_sht, NULL, 0);
My code base HEAD is: commit 0f33be009b89d2268e94194dc4fd01a7851b6d51 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Sun Sep 21 15:43:02 2014 -0700 Linux 3.17-rc6
Hello Chuansheng, I tested your new patch and it's ok now, the bug is gone, my Jmicron JMB363/368 can work after a standby, if I understand : your patch tries to disable "async_suspend feature" for all devices who have the vendor id "PCI_VENDOR_ID_JMICRON" ? so for all Jmicron controlers models this feature will be disabled with this patch ?
Hello Barto, Thanks your confirm, then it is the same root cause that non parent-children relationship's Jmicron controllers have power dependency. Here we can directly exclude all Jmicron controller for pm_async feature. I will submit one patch to upstream to improve it. Best Regards Chuansheng
*** Bug 84861 has been marked as a duplicate of this bug. ***
the bug is still here with kernel 3.17.2, something seems to have canceled the effect of the patch of chuansheng, see my bugreport : https://bugzilla.kernel.org/show_bug.cgi?id=84861
I found the explication : in fact Chuansheng's patch has not been applied in official version kernel 3.17.1 and 3.17.2 source code, that's why the bug is still here, it would be great if someone can push his patch for the next version ( kernel 3.17.3 ), it's not normal to leave this bug unfixed because the importance of this bug is "high"
this is the patch that someone has forgot to push in git : diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index a0cc0ed..ae1cd4d 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -1346,9 +1346,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) * powered on successfully, so here we disable the async suspend * method for these chips. */ - if (pdev->vendor == PCI_VENDOR_ID_JMICRON && - (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 || - pdev->device == PCI_DEVICE_ID_JMICRON_JMB361)) + if (pdev->vendor == PCI_VENDOR_ID_JMICRON) device_disable_async_suspend(&pdev->dev); /* acquire resources */ diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c index 47e418b..2150d3d 100644 --- a/drivers/ata/pata_jmicron.c +++ b/drivers/ata/pata_jmicron.c @@ -150,9 +150,7 @@ static int jmicron_init_one (struct pci_dev *pdev, const struct pci_device_id *i * powered on successfully, so here we disable the async suspend * method for these chips. */ - if (pdev->vendor == PCI_VENDOR_ID_JMICRON && - (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 || - pdev->device == PCI_DEVICE_ID_JMICRON_JMB361)) + if (pdev->vendor == PCI_VENDOR_ID_JMICRON) device_disable_async_suspend(&pdev->dev); return ata_pci_bmdma_init_one(pdev, ppi, &jmicron_sht, NULL, 0);
Created attachment 156301 [details] the final patch for JMB JMicron family IDE/SATA controler the final patch for JMB JMicron family IDE/SATA controler ( the author is Chuanseng ) the goal of this patch is to disable async_suspend for all JMicron sata/ide controlers, it's the only solution because there is too much models of JMicron who have problems with async_suspend feature
On the list, there is an outstanding question about that patch, regarding whether it should be done in PCI init instead. Until the question is answered, it can't be called "final".
I hope that this bug will not be forgotten by the developpers and a "final/better" solution will be found, like an updated IDE/SATA driver for JMicron JMBxxx, or a complete rewrite of the async_suspend feature, for example a better mechanism with an automatic deactivation if the PCI device is not compatible with async_suspend feature, a kind of "try/catch" feature, some lines for testing the PCI device about the async_suspend, without the need of manual fixing in the source code, it should be automatic, a dynamic process by the code himself
(In reply to Len Brown from comment #74) > On the list, there is an outstanding question about that patch, > regarding whether it should be done in PCI init instead. > Until the question is answered, it can't be called "final". Time is a factor here. More users will run into this when upgrading to kernel 3.15 or later. openSuse 13.2 is out today with kernel 3.16, for instance. The latest Ubuntu (14.10) also uses 3.16. Therefore, a more pragmatic approach would be to use the available patch and then take time to find a better solution. Or - as Patton once said: "A good plan today is better than a perfect plan tomorrow." Jay
Created attachment 158351 [details] disable_async_suspend_jmicron by using /drivers/pci/quirks.c file Chuanseng's patch who solves the bug by using the /drivers/pci/quirks.c file, it's time to push his patch to kernel 3.18rc6
Chuanseng, please put patchwork URL here, and set this to RESOLVED. when it ships upstream, then we will mark it CLOSED.
Chuansheng, what is the status of the patch?
Rui, According to experts' comments, I have implemented two version patches: 1/ WA in the Jmicron driver code; 2/ Add one quirk for the Jmicron; But now new request is coming here from Alan: == > You know, this is exactly why device_pm_wait_for_dev() exists -- so > that asynchronous power-management operations can wait for other > devices even when there's no parent-child relation. > > You should try to use device_pm_wait_for_dev() instead of disabling > async suspend/resume. == But I think it makes things to be difficult, need understanding here.
yes, aync resume not work means we have an implicit dependency that is not met with pm_async is enabled. And Alan just want you to describe this dependency explicitly in the driver, just like Alan has done with ehci_wait_for_companions().
Chuansheng, is there any update about the new patch?
Ping chuansheng...
(In reply to Zhang Rui from comment #83) > Ping chuansheng... maybe you should also contact Alan if Chuansheng can't be contacted
Rui will try to copy what ehci_wait_for_completions() does into the ATAPI code and come up with a test patch. Ideally, we want to *keep* async resume for its performance, and simply correctly manage the dependencies.
The routine is ehci_wait_for_companions() (in drivers/usb/core/hcd-pci.c), not ehci_wait_for_completions(). Here's a simple explanation of how you use it. Let's say you've got two devices A and B, where A must be powered on before B. Then at the start of B's resume_noirq callback routine, add a line that does: device_pm_wait_for_dev(&B->dev, &A->dev); (where A and B are the variables pointing to the pci_dev structures). That's all you have to do.
Created attachment 172621 [details] patch fix jmicron controller dependency please check if this patch helps or not.
Note that if there is more than one JMicron controller device in the same PCI slot, your patch will make all of them wait for each other! Do you think the patch should also test the function number (only wait for devices whose function is < the current device's function)? Even better would be if you could tell which device was the AHCI controller and only wait for it.
(In reply to Zhang Rui from comment #87) > Created attachment 172621 [details] > patch fix jmicron controller dependency > > please check if this patch helps or not. I tested your patch and it doesn't work, I think it's because my Jmicron PCIe card has both a SATA port and an IDE port, Alan Stern has explained why your patch fails, don't forget that JMicron PCIe has often both Sata ports and one IDE port ( hybrid card )
please attach the full output of lspci -vvx?
(In reply to Barto from comment #89) > (In reply to Zhang Rui from comment #87) > > Created attachment 172621 [details] > > patch fix jmicron controller dependency > > > > please check if this patch helps or not. > > I tested your patch and it doesn't work, > > I think it's because my Jmicron PCIe card has both a SATA port and an IDE > port, > Yes, I know. > Alan Stern has explained why your patch fails, don't forget that JMicron > PCIe has often both Sata ports and one IDE port ( hybrid card ) But, TBH, I still don't understand why the patch fails. The patch in comment #87 makes the pata_jmicron device (IDE controller) to wait until the AHCI host controller is resumed, do I miss something?
(In reply to Zhang Rui from comment #90) > please attach the full output of lspci -vvx? a "lspci --vvx | grep JMicron" : lspci -vvx | grep JMicron 03:00.0 SATA controller: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 10) (prog-if 01 [AHCI 1.0]) Subsystem: JMicron Technology Corp. JMB363 SATA/IDE Controller 03:00.1 IDE interface: JMicron Technology Corp. JMB368 IDE controller (rev 10) (prog-if 85 [Master SecO PriO]) Subsystem: JMicron Technology Corp. Device 1368 and the full output of "lspci -vvx" : 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller (rev 10) Subsystem: Gigabyte Technology Co., Ltd Device 5000 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 Capabilities: <access denied> Kernel modules: intel_agp 00: 86 80 c0 29 06 00 90 20 10 00 00 06 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 00 50 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root Port (rev 10) (prog-if 00 [Normal decode]) 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: 32 bytes Interrupt: pin A routed to IRQ 24 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 0000a000-0000afff Memory behind bridge: e4000000-e5ffffff Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport Kernel modules: shpchp 00: 86 80 c1 29 07 04 10 00 10 00 04 06 08 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 a0 a0 00 20 20: 00 e4 f0 e5 01 d0 f1 df 00 00 00 00 00 00 00 00 30: 00 00 00 00 88 00 00 00 00 00 00 00 03 01 08 00 00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 01) Subsystem: Gigabyte Technology Co., Ltd GA-D525TUD (Realtek ALC887) 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: 32 bytes Interrupt: pin A routed to IRQ 29 Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00: 86 80 d8 27 06 04 10 00 01 00 03 04 08 00 00 00 10: 04 00 00 f0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 02 a0 30: 00 00 00 00 50 00 00 00 00 00 00 00 03 01 00 00 00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1 (rev 01) (prog-if 00 [Normal decode]) 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: 32 bytes Interrupt: pin A routed to IRQ 25 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 00009000-00009fff Memory behind bridge: f0100000-f02fffff Prefetchable memory behind bridge: 00000000f0300000-00000000f04fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport Kernel modules: shpchp 00: 86 80 d0 27 07 04 10 00 01 00 04 06 08 00 81 00 10: 00 00 00 00 00 00 00 00 00 02 02 00 90 90 00 20 20: 10 f0 20 f0 31 f0 41 f0 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 03 01 00 00 00:1c.1 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 2 (rev 01) (prog-if 00 [Normal decode]) 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: 32 bytes Interrupt: pin B routed to IRQ 26 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: 0000b000-0000bfff Memory behind bridge: e6000000-e7ffffff Prefetchable memory behind bridge: 00000000f0500000-00000000f06fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport Kernel modules: shpchp 00: 86 80 d2 27 07 04 10 00 01 00 04 06 08 00 81 00 10: 00 00 00 00 00 00 00 00 00 03 03 00 b0 b0 00 20 20: 00 e6 f0 e7 51 f0 61 f0 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 02 00 00 00:1c.3 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 4 (rev 01) (prog-if 00 [Normal decode]) 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: 32 bytes Interrupt: pin D routed to IRQ 27 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: 0000c000-0000cfff Memory behind bridge: e8000000-e9ffffff Prefetchable memory behind bridge: 00000000f0700000-00000000f08fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport Kernel modules: shpchp 00: 86 80 d6 27 07 04 10 00 01 00 04 06 08 00 81 00 10: 00 00 00 00 00 00 00 00 00 04 04 00 c0 c0 00 20 20: 00 e8 f0 e9 71 f0 81 f0 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 04 00 00 00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 01) (prog-if 00 [UHCI]) Subsystem: Gigabyte Technology Co., Ltd GA-D525TUD Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 23 Region 4: I/O ports at e300 [size=32] Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00: 86 80 c8 27 05 00 80 02 01 00 03 0c 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 e3 00 00 00 00 00 00 00 00 00 00 58 14 04 50 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 00 00 00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 01) (prog-if 00 [UHCI]) Subsystem: Gigabyte Technology Co., Ltd GA-D525TUD Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin B routed to IRQ 19 Region 4: I/O ports at e000 [size=32] Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00: 86 80 c9 27 05 00 80 02 01 00 03 0c 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 e0 00 00 00 00 00 00 00 00 00 00 58 14 04 50 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 02 00 00 00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 01) (prog-if 00 [UHCI]) Subsystem: Gigabyte Technology Co., Ltd GA-D525TUD Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin C routed to IRQ 18 Region 4: I/O ports at e100 [size=32] Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00: 86 80 ca 27 05 00 80 02 01 00 03 0c 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 e1 00 00 00 00 00 00 00 00 00 00 58 14 04 50 30: 00 00 00 00 00 00 00 00 00 00 00 00 06 03 00 00 00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 01) (prog-if 00 [UHCI]) Subsystem: Gigabyte Technology Co., Ltd GA-D525TUD Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin D routed to IRQ 16 Region 4: I/O ports at e200 [size=32] Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00: 86 80 cb 27 05 00 80 02 01 00 03 0c 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 e2 00 00 00 00 00 00 00 00 00 00 58 14 04 50 30: 00 00 00 00 00 00 00 00 00 00 00 00 03 04 00 00 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI]) Subsystem: Gigabyte Technology Co., Ltd GA-D525TUD Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 23 Region 0: Memory at f0004000 (32-bit, non-prefetchable) [size=1K] Capabilities: <access denied> Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00: 86 80 cc 27 06 00 90 02 01 20 03 0c 00 00 00 00 10: 00 40 00 f0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 06 50 30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 00 00 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) (prog-if 01 [Subtractive decode]) 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 Bus: primary=00, secondary=05, subordinate=05, sec-latency=32 I/O behind bridge: 0000d000-0000dfff Memory behind bridge: ea000000-efffffff Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> 00: 86 80 4e 24 07 00 10 00 e1 01 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 05 05 20 d0 d0 80 22 20: 00 ea f0 ef f1 ff 01 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 00 00 00 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) Subsystem: Gigabyte Technology Co., Ltd Device 5001 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Capabilities: <access denied> Kernel driver in use: lpc_ich Kernel modules: intel_rng, lpc_ich, leds_ss4200 00: 86 80 b8 27 07 01 10 02 01 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 01 50 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) (prog-if 8a [Master SecP PriP]) Subsystem: Gigabyte Technology Co., Ltd Device b001 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 18 Region 0: I/O ports at 01f0 [size=8] Region 1: I/O ports at 03f4 Region 2: I/O ports at 0170 [size=8] Region 3: I/O ports at 0374 Region 4: I/O ports at f000 [size=16] Kernel driver in use: ata_piix Kernel modules: ata_piix, pata_acpi, ata_generic 00: 86 80 df 27 05 00 80 02 01 8a 01 01 00 00 00 00 10: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 20: 01 f0 00 00 00 00 00 00 00 00 00 00 58 14 01 b0 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00:1f.2 IDE interface: Intel Corporation NM10/ICH7 Family SATA Controller [IDE mode] (rev 01) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: Gigabyte Technology Co., Ltd Device b002 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin B routed to IRQ 19 Region 0: I/O ports at e800 [size=8] Region 1: I/O ports at e900 [size=4] Region 2: I/O ports at ea00 [size=8] Region 3: I/O ports at eb00 [size=4] Region 4: I/O ports at ec00 [size=16] Capabilities: <access denied> Kernel driver in use: ata_piix Kernel modules: ata_piix, pata_acpi, ata_generic 00: 86 80 c0 27 05 00 b0 02 01 8f 01 01 00 00 00 00 10: 01 e8 00 00 01 e9 00 00 01 ea 00 00 01 eb 00 00 20: 01 ec 00 00 00 00 00 00 00 00 00 00 58 14 02 b0 30: 00 00 00 00 70 00 00 00 00 00 00 00 0b 02 00 00 00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 01) Subsystem: Gigabyte Technology Co., Ltd GA-8I945PG-RH/GA-D525TUD Mainboard Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin B routed to IRQ 19 Region 4: I/O ports at 0500 [size=32] Kernel driver in use: i801_smbus Kernel modules: i2c_i801 00: 86 80 da 27 01 00 80 02 01 00 05 0c 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 05 00 00 00 00 00 00 00 00 00 00 58 14 01 50 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 02 00 00 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV730 PRO [Radeon HD 4650] (prog-if 00 [VGA controller]) Subsystem: Hightech Information System Ltd. Device 2269 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: 32 bytes Interrupt: pin A routed to IRQ 28 Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at e5000000 (64-bit, non-prefetchable) [size=64K] Region 4: I/O ports at a000 [size=256] [virtual] Expansion ROM at e4000000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: radeon Kernel modules: radeon 00: 02 10 98 94 07 04 10 00 00 00 00 03 08 00 80 00 10: 0c 00 00 d0 00 00 00 00 04 00 00 e5 00 00 00 00 20: 01 a0 00 00 00 00 00 00 00 00 00 00 87 17 69 22 30: 00 00 00 00 50 00 00 00 00 00 00 00 03 01 00 00 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RV710/730 HDMI Audio [Radeon HD 4000 series] Subsystem: Hightech Information System Ltd. Device aa38 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: 32 bytes Interrupt: pin B routed to IRQ 30 Region 0: Memory at e5010000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00: 02 10 38 aa 07 04 10 00 00 00 03 04 08 00 80 00 10: 04 00 01 e5 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 87 17 38 aa 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 02 00 00 03:00.0 SATA controller: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 10) (prog-if 01 [AHCI 1.0]) Subsystem: JMicron Technology Corp. JMB363 SATA/IDE Controller 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: 32 bytes Interrupt: pin A routed to IRQ 17 Region 5: Memory at e7000000 (32-bit, non-prefetchable) [size=512] [virtual] Expansion ROM at e6000000 [disabled] [size=64K] Capabilities: <access denied> Kernel driver in use: ahci Kernel modules: ahci 00: 7b 19 63 23 07 00 10 00 10 01 06 01 08 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 e7 00 00 00 00 7b 19 63 23 30: 00 00 00 00 8c 00 00 00 00 00 00 00 0a 01 00 00 03:00.1 IDE interface: JMicron Technology Corp. JMB368 IDE controller (rev 10) (prog-if 85 [Master SecO PriO]) Subsystem: JMicron Technology Corp. Device 1368 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 Interrupt: pin B routed to IRQ 18 Region 0: I/O ports at b000 [size=8] Region 1: I/O ports at b100 [size=4] Region 2: I/O ports at b200 [size=8] Region 3: I/O ports at b300 [size=4] Region 4: I/O ports at b400 [size=16] Capabilities: <access denied> Kernel driver in use: pata_jmicron Kernel modules: pata_jmicron, pata_acpi, ata_generic 00: 7b 19 68 03 05 00 10 00 10 85 01 01 00 00 80 00 10: 01 b0 00 00 01 b1 00 00 01 b2 00 00 01 b3 00 00 20: 01 b4 00 00 00 00 00 00 00 00 00 00 7b 19 68 13 30: 00 00 00 00 8c 00 00 00 00 00 00 00 00 02 00 00 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01) Subsystem: Gigabyte Technology Co., Ltd Motherboard 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: 32 bytes Interrupt: pin A routed to IRQ 31 Region 0: I/O ports at c000 [size=256] Region 2: Memory at e9000000 (64-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at e8000000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: r8169 Kernel modules: r8169 00: ec 10 68 81 07 04 10 00 01 00 00 02 08 00 00 00 10: 01 c0 00 00 00 00 00 00 04 00 00 e9 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 00 e0 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00 05:00.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) Subsystem: LeadTek Research Inc. WinFast DTV1000-T Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (5000ns min, 13750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 20 Region 0: Memory at ea000000 (32-bit, non-prefetchable) [size=16M] Capabilities: <access denied> Kernel driver in use: cx8800 Kernel modules: cx8800 00: f1 14 00 88 06 00 90 02 05 00 00 04 08 40 80 00 10: 00 00 00 ea 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 7d 10 5f 66 30: 00 00 00 00 44 00 00 00 00 00 00 00 09 01 14 37 05:00.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) Subsystem: LeadTek Research Inc. WinFast DTV1000-T Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (1500ns min, 22000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 20 Region 0: Memory at eb000000 (32-bit, non-prefetchable) [size=16M] Capabilities: <access denied> Kernel driver in use: cx88-mpeg driver manager Kernel modules: cx8802 00: f1 14 02 88 06 00 90 02 05 00 80 04 08 40 80 00 10: 00 00 00 eb 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 7d 10 5f 66 30: 00 00 00 00 4c 00 00 00 00 00 00 00 09 01 06 58 05:01.0 Multimedia audio controller: Yamaha Corporation YMF-744B [DS-1S Audio Controller] (rev 02) Subsystem: Yamaha Corporation DS-XG PCI Audio CODEC Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (1250ns min, 6250ns max) Interrupt: pin A routed to IRQ 19 Region 0: Memory at ef000000 (32-bit, non-prefetchable) [size=32K] Region 1: I/O ports at d000 [size=64] Region 2: I/O ports at d100 [size=4] Capabilities: <access denied> Kernel driver in use: snd_ymfpci Kernel modules: snd_ymfpci 00: 73 10 10 00 07 00 10 02 02 00 01 04 00 40 00 00 10: 00 00 00 ef 01 d0 00 00 01 d1 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 73 10 10 00 30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 05 19 05:02.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) Subsystem: LeadTek Research Inc. Device 6654 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (5000ns min, 13750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at ec000000 (32-bit, non-prefetchable) [size=16M] Capabilities: <access denied> Kernel driver in use: cx8800 Kernel modules: cx8800 00: f1 14 00 88 06 00 90 02 05 00 00 04 08 40 80 00 10: 00 00 00 ec 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 7d 10 54 66 30: 00 00 00 00 44 00 00 00 00 00 00 00 06 01 14 37 05:02.1 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] (rev 05) Subsystem: LeadTek Research Inc. Device 6654 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (1000ns min, 63750ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at ed000000 (32-bit, non-prefetchable) [size=16M] Capabilities: <access denied> Kernel driver in use: cx88_audio Kernel modules: cx88_alsa 00: f1 14 01 88 06 00 90 02 05 00 80 04 08 40 80 00 10: 00 00 00 ed 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 7d 10 54 66 30: 00 00 00 00 4c 00 00 00 00 00 00 00 06 01 04 ff 05:02.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) Subsystem: LeadTek Research Inc. Device 6654 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (1500ns min, 22000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at ee000000 (32-bit, non-prefetchable) [size=16M] Capabilities: <access denied> Kernel driver in use: cx88-mpeg driver manager Kernel modules: cx8802 00: f1 14 02 88 06 00 90 02 05 00 80 04 08 40 80 00 10: 00 00 00 ee 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 7d 10 54 66 30: 00 00 00 00 4c 00 00 00 00 00 00 00 06 01 06 58
Rui, I remembered the power on of the PCI device happened during the resume_noirq phase, so you need to do the wait there, i.e. by adding a resume_noirq callback for the pata jmicro driver and wait for its sibling to finish first.
(In reply to Zhang Rui from comment #87) > Created attachment 172621 [details] > patch fix jmicron controller dependency > > please check if this patch helps or not. Your patch works here (3.18.11). Hardware as originally posted. Three suspends/resumes, the CD-ROM-drive was always OK. Is it meant to be an addition to the former patch (lines 153 - 158) or a replacement?
(In reply to Jay from comment #94) > Your patch works here (3.18.11). > > Hardware as originally posted. Three suspends/resumes, the CD-ROM-drive was > always OK. > in order to avoid confusing : do you have an hybrid Jmicron Pcie card ? ( both SATA and IDE ports on the same card ) if you have only an IDE Jmicron card then it's normal if the patch works, the problem here ( my problem ) only occurs if the Jmicron card has both Sata and IDE ports
(In reply to Barto from comment #95) > (In reply to Jay from comment #94) > > > Your patch works here (3.18.11). > > > > Hardware as originally posted. Three suspends/resumes, the CD-ROM-drive was > > always OK. > > > > in order to avoid confusing : do you have an hybrid Jmicron Pcie card ? ( > both SATA and IDE ports on the same card ) > > if you have only an IDE Jmicron card then it's normal if the patch works, > > the problem here ( my problem ) only occurs if the Jmicron card has both > Sata and IDE ports See Comment 20 (lspci).
(In reply to Jay from comment #96) > > See Comment 20 (lspci). I have already seen your comment, it's quite confusing because of the name "JMB363 SATA/IDE Controller (rev 03) (prog-if 85 [Master SecO PriO]", but I assume you have only an IDE port an no sata ports on your JMB363 Jmicron card
(In reply to Barto from comment #97) > (In reply to Jay from comment #96) > > > > See Comment 20 (lspci). > > I have already seen your comment, it's quite confusing because of the name > "JMB363 SATA/IDE Controller (rev 03) (prog-if 85 [Master SecO PriO]", > > but I assume you have only an IDE port an no sata ports on your JMB363 > Jmicron card 3.18.11 would have been OK anyway - because it contains the former patch (lines 153 - 158). Therefore my question to Rui. Now, when I say "it works" I mean that it doesn't cause any problems with 3.18.11 and the CD-ROM-drive wakes up as expected. That's all I can say - sine ira et studio. BTW: Assumptions are one of the best ways to disaster - because more often than not they turn out to be wrong. Like in this case: as lspci already suggests, the controller has an IDE- AND a SATA-port. They are physically there on the mainboard. Honestly!
(In reply to Jay from comment #98) > Like in this case: as lspci already suggests, the controller has an IDE- AND > a SATA-port. They are physically there on the mainboard. Honestly! you use an IDE CD-ROM drive for your test, but in my case there are 2 devices connected on my JMB368-363 : - a SATA DVD burner - an IDE hard disk so the use case is not exactly the same, it would be interesting if you could connect also an IDE hard disk on your JMB363 and a SATA device, in order to see if the wake-up process still works after a standby
(In reply to Jay from comment #94) > > Is it meant to be an addition to the former patch (lines 153 - 158) or a > replacement? I think the last patch is a replacement, not an addition, if you talk about the chuanseng's patch then it simply deactivates the async method for JMB363 and JMB361 : https://bugzilla.kernel.org/attachment.cgi?id=148751 + /* The JMicron chip 361/363 contains one SATA controller and + * one PATA controller,for powering on these both controllers, + * we must follow the sequence one by one, otherwise one of them + * can not be powered on successfully. + * So here we disabled the async suspend method for these chips. + */ + if (pdev->vendor == PCI_VENDOR_ID_JMICRON && + (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 || + pdev->device == PCI_DEVICE_ID_JMICRON_JMB361)) + device_disable_async_suspend(&pdev->dev); + return ata_pci_bmdma_init_one(pdev, ppi, &jmicron_sht, NULL, 0); } that's why your problem seems solved, I think if you want to test the last patch ( comment 87 ) you should cancel the first patch, in my case ( JMB368-363 ) I must use another patch from chuanseng who uses the file quirk.c in order to disable async for all JMicron models : https://bugzilla.kernel.org/attachment.cgi?id=158351 but I hope developpers will find the solution, they seem close to succeed
(In reply to Barto from comment #100) > (In reply to Jay from comment #94) > > ... > > I think if you want to test the last patch ( comment 87 ) you should cancel > the first patch, > Chuansheng's patch is in the sources now. A replacement needs to address this anyhow. So I'd rather wait for a new one. ...
Hi, All, After discussing with Aaron, Lu, I think the patch in comment #72 should be the right fix. Because, on this platform, pci_resume_noirq() of IDE controller must happen after pci_resume_noirq() of AHCI controller. But as .resume_noirq() of the pata_jmicron driver is no-op, this suggests that it is the PCI common actions, aka, pci_pm_default_resume_early(), have the dependency. To fix this, using device_pm_wait_for_dev() in pata_jmicron driver is not helpful (even in the .resume_noirq() callback) because we should wait BEFORE pci_pm_default_resume_early() being invoked, in pci_pm_resume_noirq(). Plus, as it is the PCI common actions that have the dependency, it is reasonable to fix it in PCI bus code, rather than driver code. Alan, what do you think?
(In reply to Zhang Rui from comment #102) > Hi, All, > > After discussing with Aaron, Lu, I think the patch in comment #72 should be > the right fix. there is also another patch by Chuanseng who uses the same logic in /drivers/pci/quirks.c file ( disabling the async_suspend method for JMicron chips ), I think you should use this patch : https://bugzilla.kernel.org/attachment.cgi?id=158351 diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 90acb32..b40485f 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -29,6 +29,21 @@ #include "pci.h" /* + * For JMicron chips, we need to disable the async_suspend method, otherwise + * they will hit the power-on issue when doing device resume, add one quick + * solution to disable the async_suspend method. + */ +static void pci_async_suspend_fixup(struct pci_dev *pdev) +{ + /* + * disabling the async_suspend method for JMicron chips to + * avoid device resuming issue. + */ + device_disable_async_suspend(&pdev->dev); +} +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, pci_async_suspend_fixup); + +/* * Decoding should be disabled for a PCI device during BAR sizing to avoid * conflict. But doing so may cause problems on host bridge and perhaps other * key system devices. For devices that need to have mmio decoding always-on,
(In reply to Barto from comment #103) > (In reply to Zhang Rui from comment #102) > > Hi, All, > > > > After discussing with Aaron, Lu, I think the patch in comment #72 should be > > the right fix. > > there is also another patch by Chuanseng who uses the same logic in > /drivers/pci/quirks.c file ( disabling the async_suspend method for JMicron > chips ), I think you should use this patch : I prefer this too. > > > https://bugzilla.kernel.org/attachment.cgi?id=158351 > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index 90acb32..b40485f 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -29,6 +29,21 @@ > #include "pci.h" > /* > + * For JMicron chips, we need to disable the async_suspend method, otherwise > + * they will hit the power-on issue when doing device resume, add one quick > + * solution to disable the async_suspend method. > + */ > +static void pci_async_suspend_fixup(struct pci_dev *pdev) > +{ > + /* > + * disabling the async_suspend method for JMicron chips to > + * avoid device resuming issue. > + */ > + device_disable_async_suspend(&pdev->dev); > +} > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, > pci_async_suspend_fixup); > + > +/* > * Decoding should be disabled for a PCI device during BAR sizing to avoid > * conflict. But doing so may cause problems on host bridge and perhaps > other > * key system devices. For devices that need to have mmio decoding > always-on,
(In reply to Barto from comment #103) > (In reply to Zhang Rui from comment #102) > > Hi, All, > > > > After discussing with Aaron, Lu, I think the patch in comment #72 should be > > the right fix. > > there is also another patch by Chuanseng who uses the same logic in > /drivers/pci/quirks.c file ( disabling the async_suspend method for JMicron > chips ), I think you should use this patch : > sorry, my mistake, this is the patch I wanted to refer as well, instead of the patch in comment #72. > > https://bugzilla.kernel.org/attachment.cgi?id=158351 > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index 90acb32..b40485f 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -29,6 +29,21 @@ > #include "pci.h" > /* > + * For JMicron chips, we need to disable the async_suspend method, otherwise > + * they will hit the power-on issue when doing device resume, add one quick > + * solution to disable the async_suspend method. > + */ > +static void pci_async_suspend_fixup(struct pci_dev *pdev) > +{ > + /* > + * disabling the async_suspend method for JMicron chips to > + * avoid device resuming issue. > + */ > + device_disable_async_suspend(&pdev->dev); > +} > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, > pci_async_suspend_fixup); > + > +/* > * Decoding should be disabled for a PCI device during BAR sizing to avoid > * conflict. But doing so may cause problems on host bridge and perhaps > other > * key system devices. For devices that need to have mmio decoding > always-on,
Under the circumstances this seems like the best solution. Unless someone wants to fix up the code in comment #87 and add it as a quirk to the pci_pm_default_resume_early() routine.
Hi, Chuansheng, can you please refresh the patch referred in comment #77 and send it for upstream? Note that you'd better revert commit e6b7e41cdd8cae0591e04d9519b65470110e2d44 in your patch as well.
Created attachment 183761 [details] Patch for upstream Hi, all, this is the refreshed patch that I'd like to push for upstream. Please kindly test it.
(In reply to Zhang Rui from comment #108) > Created attachment 183761 [details] > Patch for upstream > > Hi, all, > this is the refreshed patch that I'd like to push for upstream. Please > kindly test it. Works here with kernel 3.18.18 (s. below). No problems so far after several resumes from s2both. Thanks for your work! Jay _________________________ /Kernel/linux-3.18.18> patch -p1 <../0001-PCI-Disable-async-suspend-resume-for-Jmicron-chip.patch patching file drivers/ata/ahci.c Hunk #1 succeeded at 1378 with fuzz 2 (offset -73 lines). patching file drivers/ata/pata_jmicron.c patching file drivers/pci/quirks.c
all is ok for me with your patch with the kernel 4.1.2 ( archlinux 64 bits ), you can push it for upstream, thanks for your patch (In reply to Zhang Rui from comment #108) > Created attachment 183761 [details] > Patch for upstream > > Hi, all, > this is the refreshed patch that I'd like to push for upstream. Please > kindly test it.
Patch sent out. https://patchwork.kernel.org/patch/6878961/ Mark the bug as Resovled for now, and will close it once the patch hits upstream.
commit 91f15fb30c77d4a0d0d9b97e5cec647650853145 Author: Zhang Rui <rui.zhang@intel.com> Date: Mon Aug 24 15:27:11 2015 -0500 PCI: Disable async suspend/resume for JMicron multi-function SATA/AHCI Entered Linus tree as of v4.3-rc1.