Bug 370111

Summary: pata_jmicron causes suspend to fail sometimes
Product: [Fedora] Fedora Reporter: Bill Peck <bpeck>
Component: kernelAssignee: Aristeu Rozanski <arozansk>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 8CC: alex, anpaza, chris.brown, duck
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-09 07:22:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Bill Peck 2007-11-07 18:41:17 UTC
Description of problem:
pata_jmiron will prevent the system from suspending properly

Version-Release number of selected component (if applicable):
kernel - 2.6.23.1-42.fc8

How reproducible:
Machine needs to be running for a while.  First couple suspends will work

removing the module will allow the system to suspend.

Comment 1 Aristeu Rozanski 2007-11-09 15:57:22 UTC
Bill, do you have the messages in some place? maybe a rhts url?
Thanks


Comment 2 Bill Peck 2007-11-13 17:55:03 UTC
Does this help?

Nov 13 11:43:52 vixen gnome-power-manager: (vpeck) Suspending computer
because System idle
Nov 13 11:43:53 vixen ntpd[13160]: ntpd exiting on signal 15
Nov 13 11:43:57 vixen restorecond: Read error (Interrupted system call)
Nov 13 11:43:57 vixen kernel: Stopping tasks ... done.
Nov 13 11:43:57 vixen kernel: Suspending console(s)
Nov 13 11:43:57 vixen kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Nov 13 11:43:57 vixen kernel: sd 0:0:0:0: [sda] Stopping disk
Nov 13 11:43:57 vixen kernel: pnp: Device 00:0b disabled.
Nov 13 11:43:57 vixen kernel: pnp: Device 00:06 disabled.
Nov 13 11:43:57 vixen kernel: ACPI Exception (exoparg2-0442):
AE_AML_PACKAGE_LIMIT, Index (000000006) is beyond end of object
[20070126]
Nov 13 11:43:57 vixen kernel: ACPI Error (psparse-0537): Method
parse/execution failed [\_SB_.PCI0.P0P8.JMF1.SDE0._GTM] (Node
c20dd858), AE_AML_PACKAGE_LIMIT
Nov 13 11:43:57 vixen kernel: ata7: ACPI get timing mode failed (AE 0x300d)
Nov 13 11:43:57 vixen kernel: pci_device_suspend():
ata_pci_device_suspend+0x0/0x27 [libata]() returns -22
Nov 13 11:43:57 vixen kernel: suspend_device():
pci_device_suspend+0x0/0x47() returns -22
Nov 13 11:43:57 vixen kernel: Could not suspend device 0000:03:00.1: error -22
Nov 13 11:43:57 vixen kernel: pnp: Device 00:06 activated.
Nov 13 11:43:57 vixen kernel: pnp: Device 00:0b activated.
Nov 13 11:43:57 vixen kernel: sd 0:0:0:0: [sda] Starting disk
Nov 13 11:43:57 vixen kernel: Some devices failed to suspend
Nov 13 11:43:57 vixen kernel: Restarting tasks ... done.
Nov 13 11:43:57 vixen acpid: client connected from 2638[0:0]
Nov 13 11:43:57 vixen acpid: 1 client rule loaded
Nov 13 11:43:57 vixen gnome-power-manager: (vpeck) Resuming computer


[root@vixen ~]# lspci
00:00.0 Host bridge: Intel Corporation 82P965/G965 Memory Controller
Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82P965/G965 PCI Express Root Port (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82G965 Integrated
Graphics Controller (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Contoller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2
EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 1 (rev 02)
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 5 (rev 02)
00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 6 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2
EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation 82801HB/HR (ICH8/R) LPC
Interface Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801H (ICH8 Family) 4 port
SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02)
00:1f.5 IDE interface: Intel Corporation 82801H (ICH8 Family) 2 port
SATA IDE Controller (rev 02)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
03:00.0 SATA controller: JMicron Technologies, Inc. JMicron
20360/20363 AHCI Controller (rev 02)
03:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363
AHCI Controller (rev 02)
05:01.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A
IEEE-1394a-2000 Controller (PHY/Link)


Comment 3 Alex Lancaster 2007-11-26 09:56:48 UTC
Don't know if it's the same problem, but I have the same symptom: failure to
suspend and the same error message:

"ACPI get timing mode failed "

on bug #375021.  This used to work perfectly on F-7, I haven't had a successful
suspend with any kernel on F-8.  I am currently using the kernel in
updates-testing: kernel-2.6.23.8-62.fc8.i686 in the hope that might work, but it
still gives me the same ACPI error.

It would be great if somebody could confirm if this is the same underlying issue.



Comment 4 Andrew Zabolotny 2007-12-17 18:18:51 UTC
Don't know if it's the same problem :-D but JMicron 20360/20363 fails to resume
after suspend. Should I open a new bug on this?

04:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCI
Controller (rev 02)
04:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI
Controller (rev 02)
(pci id 197b:2363)

I have an 160Gb IDE drive connected to this controller. kernel-2.6.23.8-63.fc8.

Now going to suspend mode works fine, however after returning from suspend the
controller does not wake up properly:

sd 6:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sdb, sector 62191
Buffer I/O error on device sdb1, logical block 7766
lost page write due to I/O error on sdb1
Buffer I/O error on device sdb1, logical block 7767
lost page write due to I/O error on sdb1
REISERFS: abort (device sdb1): Journal write error in flush_commit_list
REISERFS: Aborting journal for filesystem on sdb1
sd 6:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sdb, sector 0
Buffer I/O error on device sdb, logical block 0
Buffer I/O error on device sdb, logical block 1
Buffer I/O error on device sdb, logical block 2
Buffer I/O error on device sdb, logical block 3
Buffer I/O error on device sdb, logical block 4
Buffer I/O error on device sdb, logical block 5
Buffer I/O error on device sdb, logical block 6
Buffer I/O error on device sdb, logical block 7
Buffer I/O error on device sdb, logical block 8
Buffer I/O error on device sdb, logical block 9
sd 6:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sdb, sector 128

After that the disk goes offline and rejects any I/O to it.

This worked perfectly with Fedora 7 with kernel 2.6.23 just a week ago, so I
think I'll try to downgrade to kernel-2.6.23.8-34.fc7 and I hope the problem
will go away.


Comment 5 Aristeu Rozanski 2008-01-07 16:08:01 UTC
Andrew, did downgrading to 2.6.23-8-34.fc7 solved the problem?


Comment 6 Andrew Zabolotny 2008-01-12 22:52:40 UTC
Yes, using a f7 kernel works just fine. I have used kernel-2.6.23.8-34.fc7,
today I switched to kernel-2.6.23.12-52.fc7 and everything works fine with
JMicron, although there's one small notch in dmesg after waking up (this is with
kernel 2.6.23.12-52.fc7):

Back to C!
Enabling non-boot CPUs ...
SMP alternatives: switching to SMP code
...
ata5: SATA link down (SStatus 0 SControl 300)
ata6: SATA link down (SStatus 0 SControl 300)
sky2 eth0: Link is up at 100 Mbps, full duplex, flow control both
sd 0:0:0:0: [sda] Starting disk
ata7.00: revalidation failed (errno=-2)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ata7: failed to recover some devices, retrying in 5 secs
ata1: port is slow to respond, please be patient (Status 0x80)
ata1.00: Host Protected Area detected:
        current size: 625140335 sectors
        native size: 625142448 sectors
ata1.00: Host Protected Area detected:
        current size: 625140335 sectors
        native size: 625142448 sectors
ata1.00: configured for UDMA/133
sd 0:0:0:0: [sda] 625140335 512-byte hardware sectors (320072 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 7:0:0:0: [sdf] Starting disk
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
ata7.00: Host Protected Area detected:
        current size: 312579695 sectors
        native size: 312581808 sectors
ata7.00: Host Protected Area detected:
        current size: 312579695 sectors
        native size: 312581808 sectors
ata7.00: configured for UDMA/100
ata7: EH pending after completion, repeating EH (cnt=4)
sd 7:0:0:0: [sdf] 312579695 512-byte hardware sectors (160041 MB)
sd 7:0:0:0: [sdf] Write Protect is off
sd 7:0:0:0: [sdf] Mode Sense: 00 3a 00 00
sd 7:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
PM: Finishing wakeup.

The IDE disk is sdf because sda is a SATA disk and sdb-sde are four slots of a
built-in card reader.

Comment 7 Christopher Brown 2008-02-03 23:49:10 UTC
Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Comment 8 Andrew Zabolotny 2008-02-04 07:36:59 UTC
kernel-2.6.23.14-107.fc8 still has the same problem.

kernel-2.6.23.12-52.fc7 does not.


Comment 9 Andrew Zabolotny 2008-04-01 06:26:40 UTC
kernel 2.6.24.3-50.fc8 seems to have this problem fixed, don't know
intentionally or not :-)

I think this bug can be closed then.

Comment 10 Bug Zapper 2008-11-26 08:13:36 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Bug Zapper 2009-01-09 07:22:38 UTC
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.