Bug 1028203 - suspend results in readonly filesystem on resume [NEEDINFO]
suspend results in readonly filesystem on resume
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
20
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-07 16:54 EST by Jeremy Harris
Modified: 2014-12-10 10:00 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-12-10 10:00:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jforbes: needinfo?


Attachments (Terms of Use)
screen photo of dmesg, showing disk error (766.19 KB, image/jpeg)
2013-11-07 17:49 EST, Jeremy Harris
no flags Details

  None (edit)
Description Jeremy Harris 2013-11-07 16:54:42 EST
Description of problem:
  Allowing f20 / xfce, on a T530, to lie idle long enough to auto-suspend,
then hitting the power button to resume - user home directory writes (eg.
"touch foo" are denied with "read-only filesystem".  I suspect a fs, scsi or
disk error on an inode (from previous peeks at logs) results in a deliberate
transition to RO.


Version-Release number of selected component (if applicable):
  3.11.7-300.fc20.x86_64

How reproducible:
  >80%.  Both mains & battery operation.  Note that deliberate suspend (or hibernate) from the xfce menu
does *not* seem to induce it.


Steps to Reproduce:
1. Boot system & log in
2. Leave idle until suspend happens, then resume
3. Attempt a file write

Actual results:
  Write to filesystem fails, EROFS.  "mount" still shows RW.

Expected results:
  Write operates normally.


Additional info:
  Have configured for kdump & taken one in the EROFS state.  At 105MB I can't
attach here, but I'll keep it around in case of interest.
Comment 1 Jeremy Harris 2013-11-07 17:46:45 EST
Can also duplicate on 3.11.6-302.fc20.x86_64 .   From this one I photo'd
dmesg after resume; it shows an I/O error on sdb, which happens to
be an inode:
(manually retyped)

PM: Finishing wakeup
Restarting tasks ... done.
usb 2-1.6: USB disconnect, device number 3
video LNXVIDEO:00: Restoring backlight state
sd 6:0:0:0: [sdb] Unhandled error code
sd 6:0:0:0: [sdb]
Result: hostbyte=DID_NO_CONNECT droverbyte=DRIVER_OK
sd 6:0:0:0: [sdb] CDB:
Write(10): 2a 00 03 53 d0 00 00 00 08 00
end_request: I/O error, dev sdb, sector 55824384
Comment 2 Jeremy Harris 2013-11-07 17:49:00 EST
Created attachment 821330 [details]
screen photo of dmesg, showing disk error
Comment 3 Jeremy Harris 2014-01-06 04:42:39 EST
Still present in 3.12.5-302.fc20.x86_64
Comment 4 Jeremy Harris 2014-02-01 10:24:43 EST
Also on 3.12.8-300.fc20.x86_64 - this time a deliberate suspend-to-ram.
Comment 5 Justin M. Forbes 2014-02-24 08:57:02 EST
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.13.4-200.fc20.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 6 Justin M. Forbes 2014-03-17 14:46:00 EDT
*********** MASS BUG UPDATE **************

This bug has been in a needinfo state for several weeks and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 20, please feel free to reopen the bug and provide the additional information requested.
Comment 7 Jeremy Harris 2014-03-19 07:14:32 EDT
Still present on 3.13.6-200.fc20.x86_64, triggered by deliberate suspend.
Comment 8 Justin M. Forbes 2014-05-21 15:39:02 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.14.4-200.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 9 Jeremy Harris 2014-05-22 05:40:13 EDT
Still present on 3.14.4-200.fc20.x86_64
Comment 10 Justin M. Forbes 2014-11-13 11:00:15 EST
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.17.2-200.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.

If you experience different issues, please open a new bug report for those.
Comment 11 Justin M. Forbes 2014-12-10 10:00:10 EST
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

Note You need to log in before you can comment on or make changes to this bug.