Created attachment 151041 [details] normal dmesg, when all is ok I use kernel 3.16.3 with archlinux 64 bits, my motherboard is : Gigabyte P31-DS3L/P31-DS3L, BIOS F10A 07/30/2008 I notice if I choose "standby" in kde menu then something strange will occur : - the standby procedure seems ok, my PC shutdown in "standby mode", - when I wake-up my pc the wake up seems Ok but in fact there is a problem : my IDE hardisk connected in a PCI-E "SATA/IDE controler JBMicron JMB363 SATA/IDE Controller (rev 10)" doesn't work, I can not open files located in this hardisk ( there is 2 ntfs partitions in this hardisk ) in dmesg I can see this : Memory corruption detected in low memory exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.01: failed command: READ DMA ata3.01: cmd c8/00:08:5f:a2:ba/00:00:00:00:00/f0 tag 0 dma 4096 in res 40/00:00:00:4f:c2/00:00:00:00:00/10 Emask 0x20 (host bus error) ata3.01: status: { DRDY } the problem occurs only with "standby mode" option, if I use the "shutdown" classic procedure ( poweroff ) then there is no problem, I tried to downgrade kernel to kernel 3.15.8 and the problem is still here, but I remember that with old kernel versions ( maybe 3.13.x version ) I don't have this problem, so there is something wrong in kernel 3.16.x related to the standby mode shutdown, something that create a memory corruption and prevent my JBMicron IDE/SATA controler PCI-E to work, I notice also that the "hibernation" mode doesn't work ( I get a normal shutdown instead of a hibernation )
Created attachment 151051 [details] the error messages when I choose the standby shutdown hardisk connected to my PCIe "JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 10)" doesn't work after I select standby mode shutdown
Created attachment 151061 [details] normal dmesg, when all is ok
please attach the acpidump output. Usually, the low memory corruption suggests a BIOS bug, so if you want to make sure "there is something wrong in kernel 3.16.x related to the standby mode shutdown, ", please help check any earlier kernel release and find out one without this problem.
I tried with an old kernel version : 3.12.8, and with this 3.12.8 version I don't have the bug, my SATA/IDE controler JMicron Technology Corp. JMB363/JMB368 can work without problem even after a standby mode, with 3.12.8 I still have the error message "memory corruption" but I don't have the other error message related to a "read DMA error", that's why the JMicron JMB363/JMB368 can work, so now we are sure that it's a regression because kernel 3.12.8 doesn't have the bug, here is "lspci -v" related to JBMicron : 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: <access denied> 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: <access denied> Kernel driver in use: pata_jmicron Kernel modules: pata_jmicron, pata_acpi, ata_generic
Created attachment 151231 [details] acpi tables if I run in root "acpidump" I get this error : Cannot map /dev/mem Could not map table at 0x00000000000F6890 length CFEE3040 Could not get ACPI tables, AE_ACCESS so I found a workaround in order to get the acpi tables : # cat /sys/firmware/acpi/tables/DSDT > dsdt.dat and then : iasl -d dsdt.dat I get a dsdt.dsl text file who represents the ACPI tables of my gigabyte motherboard GA-P31-DSL3
please attach the dmesg output of 3.12.8 kernel after returning from "standby" mode. Please attach the full dmesg output of 3.16 kernel after resuming from "standby". please try echo 0 > /sys/power/async in 3.16 kernel, before entering standby mode and see if the problem still exists.
please try 3.17-rc5 kernel, which already includes a fix for Jmoncron ata controller, and see if the problem still exists.
(In reply to Zhang Rui from comment #7) > please try 3.17-rc5 kernel, which already includes a fix for Jmoncron ata > controller you can check if this is a duplicate of bug 81551.
(In reply to Zhang Rui from comment #8) > you can check if this is a duplicate of bug 81551. it's a very interesting link, if I check the dmesg after a standby I can see this : kernel: pata_jmicron 0000:03:00.1: Refused to change power state, currently in D3 Is it this patch who solves the problem ? : https://bugzilla.kernel.org/attachment.cgi?id=148751 because I could rebuild kernel 3.16.3 with your patch, it would be great if the next version of kernel 3.16.x can include your patch, your patch seems safe and probably a lot of people use SATA/IDE controler JMicron JMB363/JMB368
I applied your patch with kernel 3.16.3: https://bugzilla.kernel.org/attachment.cgi?id=148751 and it doesn't solve the problem, I still have a big problem with my Micron Technology Corp. JMB368 IDE controler, the IDE harddisk attached to this controler doesn't work after a standby mode, I can see this information in dmesg after a standby : pata_jmicron 0000:03:00.1: Refused to change power state, currently in D3 the only solution is to disable pm_async with this command in root before doing a standby : echo 0 > /sys/power/pm_async so your patch is not completed, something is missing, I notice I have a Jmicron JMB368 ( IDE ) and a Jmicron JMB363 ( SATA ) if I type "lscpi -v", but in your patch I don't see "JMB368", I see only "PCI_DEVICE_ID_JMICRON_JMB363" and "PCI_DEVICE_ID_JMICRON_JMB361", I think you should add "PCI_DEVICE_ID_JMICRON_JMB368" in the "if statement", like this : + 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 ?
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 151311 [details] the dmesg 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 151371 [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 }
Created attachment 151381 [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 }
re-assign this to Chuansheng, who is the author of https://bugzilla.kernel.org/attachment.cgi?id=148751
Chuansheng has published a new patch, this patch seems to solve the problem, with this patch for all Jmicron controlers models the "async" feature will be disabled : 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);
*** This bug has been marked as a duplicate of bug 81551 ***
I still have the bug with kernel 3.17.2-1, I use kernel 3.17.2 with archlinux 64 bits, my motherboard is : Gigabyte P31-DS3L/P31-DS3L, BIOS F10A 07/30/2008 if I choose "standby" in kde menu then something strange will occur : - the standby procedure seems ok, my PC shutdown in "standby mode", - when I wake-up my pc the wake up seems Ok but in fact there is a problem : my IDE hardisk connected in a PCI-E "SATA/IDE controler JBMicron JMB363-JMB368 SATA/IDE Controller (rev 10)" doesn't work, I can not open files located in this hardisk ( there is 2 ntfs partitions in this hardisk ) in dmesg I see this : [ 452.839988] pata_jmicron 0000:03:00.1: Refused to change power state, currently in D3 and this : [ 516.436644] ata3: lost interrupt (Status 0x58) [ 516.460603] ata3: drained 65536 bytes to clear DRQ [ 516.562867] ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 [ 516.562871] ata3.01: failed command: READ DMA [ 516.562874] ata3.01: cmd c8/00:08:ef:a1:ba/00:00:00:00:00/f0 tag 0 dma 4096 in res 40/00:00:00:4f:c2/00:00:00:00:00/10 Emask 0x20 (host bus error) [ 516.562876] ata3.01: status: { DRDY } [ 516.630658] ata3.01: configured for UDMA/100 [ 516.630667] ata3.01: device reported invalid CHS sector 0 [ 516.630687] ata3: EH complete [ 547.369977] ata3: lost interrupt (Status 0x58) [ 547.385148] ata3: drained 65536 bytes to clear DRQ [ 547.497352] ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 [ 547.497358] ata3.01: failed command: READ DMA [ 547.497362] ata3.01: cmd c8/00:08:ef:a1:ba/00:00:00:00:00/f0 tag 0 dma 4096 in res 40/00:00:00:4f:c2/00:00:00:00:00/10 Emask 0x20 (host bus error) [ 547.497364] ata3.01: status: { DRDY } [ 547.563999] ata3.01: configured for UDMA/100 [ 547.564007] ata3.01: device reported invalid CHS sector 0 [ 547.564030] ata3: EH complete something in kernel 3.17.2 seems to have disable the patch of Chuansheng
Created attachment 156281 [details] here is the dmesg output after a standby here is the dmesg output after a standby
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);
so, Barto, are you going to push this patch upstream? anyway, I think we can mark this bug as Resolved as the patch is already available.
(In reply to Zhang Rui from comment #22) > so, Barto, are you going to push this patch upstream? > anyway, I think we can mark this bug as Resolved as the patch is already > available. I don't have the possibility to push a patch ( I don't have the rights, I'm not a developper, just a user ),
Hello Barto, The upstream patch is here: https://lkml.org/2014/9/24/68 You also are in the mail loop, could you give confirm for that patch to get merged? Thanks.
(In reply to chuansheng.liu from comment #24) > Hello Barto, > > The upstream patch is here: > https://lkml.org/2014/9/24/68 > Sorry, this Link: https://lkml.org/lkml/2014/9/24/68
(In reply to chuansheng.liu from comment #24) > Hello Barto, > > The upstream patch is here: > https://lkml.org/2014/9/24/68 > > You also are in the mail loop, could you give confirm for that patch to get > merged? > > Thanks. yes this patch works for me, I have already tried this patch with kernel 3.17 and 3.18, so it would be great if this patch can be merged
(In reply to Barto from comment #26) > (In reply to chuansheng.liu from comment #24) > > Hello Barto, > > > > The upstream patch is here: > > https://lkml.org/2014/9/24/68 > > > > You also are in the mail loop, could you give confirm for that patch to get > > merged? > > > > Thanks. > > yes this patch works for me, I have already tried this patch with kernel > 3.17 and 3.18, > > so it would be great if this patch can be merged Only kernel maintainer can merge the patch, so if you can reply the email loop to give the maintainer confidence for the patch, it will help the patch to be merged.
(In reply to chuansheng.liu from comment #27) > Only kernel maintainer can merge the patch, so if you can reply the email > loop to give the maintainer confidence for the patch, it will help the patch > to be merged. I don't understand what I must do, I must wait an email from the maintainer ? or I must contact this maintainer by email ?
The patch references in comment #25 is not upstream in Linux-3.18-rc1, and is also not in today's linux-next -- so apparently no upstream maintainer has paid attention to it yet. On the LKML thread, I do not see a reply from Chuan to Aaron Lu to the suggestion that the fix should likely be in the PCI init code, rather than the SATA init code. In any case, this bug is closed as a duplicate of bug 81551, and so discussion of the fix and the patch should be there, not here. *** This bug has been marked as a duplicate of bug 81551 ***
Hello Barto, Could you try this patch according to Aaron's suggestion? And let us the result, thanks. ====== The JMicron chip 361/363/368 contains one SATA controller and one PATA controller, they are brother-relation ship in PCI tree, but for powering on these both controller, we must follow the sequence one by one, otherwise one of them can not be powered on successfully. So here we disable the async suspend method for Jmicron chip. Cc: stable@vger.kernel.org # 3.15+ Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com> --- drivers/pci/pci.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 625a4ac..53128f0 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -2046,7 +2046,17 @@ void pci_pm_init(struct pci_dev *dev) pm_runtime_forbid(&dev->dev); pm_runtime_set_active(&dev->dev); pm_runtime_enable(&dev->dev); - device_enable_async_suspend(&dev->dev); + + /* + * The JMicron chip 361/363/368 contains one SATA controller and + * one PATA controller, they are brother-relation ship in PCI tree, + * but for powering on these both controller, we must follow the + * sequence one by one, otherwise one of them can not be powered on + * successfully, so here we disable the async suspend method for + * Jmicron chip. + */ + if (dev->vendor != PCI_VENDOR_ID_JMICRON) + device_enable_async_suspend(&dev->dev); dev->wakeup_prepared = false; dev->pm_cap = 0; -- 1.7.9.5 ====
I tried the patch, it solves the problem, but I had to create the patch in order to be compatible with 3.18rc3 source code, your patch doesn't want te be applied with 3.18rc3 source code : patching file drivers/pci/pci.c Hunk #1 FAILED at 2046. 1 out of 1 hunk FAILED -- saving rejects to file drivers/pci/pci.c.rej here is the correct patch for kernel 3.18rc3 source code : diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -2046,7 +2046,17 @@ void pci_pm_init(struct pci_dev *dev) pm_runtime_forbid(&dev->dev); pm_runtime_set_active(&dev->dev); pm_runtime_enable(&dev->dev); - device_enable_async_suspend(&dev->dev); + + /* + * The JMicron chip 361/363/368 contains one SATA controller and + * one PATA controller, they are brother-relation ship in PCI tree, + * but for powering on these both controller, we must follow the + * sequence one by one, otherwise one of them can not be powered on + * successfully, so here we disable the async suspend method for + * Jmicron chip. + */ + if (dev->vendor != PCI_VENDOR_ID_JMICRON) + device_enable_async_suspend(&dev->dev); dev->wakeup_prepared = false; dev->pm_cap = 0; Le 05/11/2014 02:28, bugzilla-daemon@bugzilla.kernel.org a écrit : > https://bugzilla.kernel.org/show_bug.cgi?id=84861 > > --- Comment #30 from chuansheng.liu@intel.com --- > Hello Barto, > > Could you try this patch according to Aaron's suggestion? And let us the > result, thanks.
Created attachment 156901 [details] dmesg when jmicron fails after a standby dmesg when jmicron fails after a standby
the patch made by Chuanseng is not in 3.18rc5, why ? his patch is good, it works without problems by using the /drivers/pci/quirks.c file : 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,
Created attachment 158231 [details] disable_async_suspend_jmicron Chuanseng's patch, it solves the bug related to async_suspend with JMicron Sata/IDE PCie card