0

After resuming from suspend to RAM, my Arch Linux system freezes and becomes permanently unresponsive. However, I managed to pull the following kernel log:

kernel: sas: Enter sas_scsi_recover_host busy: 2 failed: 2
kernel: sas: trying to find task 0xfff880008b5b680
kernel: sas: sas_scsi_find_task: aborting task 0xfff880008b5b680
kernel: sas: sas_scsi_find_task: task 0xfff880008b5b680 is aborted
kernel: sas: sas_eh_handle_sas_errors: task 0xfff880008b5b680 is aborted
kernel: sas: trying to find task 0xffff8804606ccb40
kernel: sas: sas_scsi_find_task: aborting task 0xffff8804606ccb40
kernel: sas: sas_scsi_find_task: task 0xffff8804606ccb40 is aborted
kernel: sas: sas_eh_handle_sas_errors: task 0xffff8804606ccb40 is aborted
kernel: sas: ata7: end_device-0:0: cmd error handler
kernel: sas: ata8: end_device-0:1: cmd error handler
kernel: sas: ata7: end_device-0:0: dev error handler
kernel: ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
kernel: ata7.00: failed command: READ VERIFY SECTOR(S)
kernel: ata7.00: cmd 40/00:01:00:00:00/00:00:00:00:00/e0 tag 11
                 res 40/00:48:a0:79:88/00:00:07:00:00/40 Emask 0x4 (timeout)
kernel: ata7.00: status { DRDY }
kernel: ata7: hard resetting link
kernel: sas: ata8: end_device-0:1: dev error handler
kernel: ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
kernel: ata8.00: failed command: READ VERIFY SECTOR(S)
kernel: ata8.00: cmd 40/00:01:00:00:00/00:00:00:00:00/e0 tag 11
                 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
kernel: ata8.00: status { DRDY }
kernel: ata8: hard resetting link

The storage device in question is:

$ lspci
06:00.0 SCSI storage controller: OCZ Technology Group, Inc. Device 1021 (rev 02)

$ lsblk -St
NAME HCTL       TYPE VENDOR   MODEL             REV TRAN   NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE  RA WSAME
sdc  0:0:0:0    disk ATA      OCZ-REVODRIVE3   2.25 sas    sdc          0    512      0     512     512    0 cfq       128 128    0B
sdd  0:0:1:0    disk ATA      OCZ-REVODRIVE3   2.25 sas    sdd          0    512      0     512     512    0 cfq       128 128    0B

$ lsblk -f
sdc                                                                       
└─sdc1  linux_raid_member home:0     208937dc-2904-e71c-435a-9928671e07a3 
  └─md0 ext4              revodrive  ffe9d38f-87f2-44e1-ae26-f36c910af3c5 /home
sdd                                                                       
└─sdd1  linux_raid_member home:0     208937dc-2904-e71c-435a-9928671e07a3 
  └─md0 ext4              revodrive  ffe9d38f-87f2-44e1-ae26-f36c910af3c5 /home

All suspend debugging modes in /sys/power/pm_test, namely freezer, devices, platform, processors, and core do neither freeze the system nor produce these error messages. Only if the system is suspended after a

# echo none > /sys/power/pm_test

to disable testing the error occurs on suspending to RAM.

What does the error mean and what can I do to fix it?

EDIT: The issue is not related to the file system or a disk failure:

# e2fsck -cyv /dev/md0 | tee fsck.log
revodrive: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

revodrive: ***** FILE SYSTEM WAS MODIFIED *****

      241444 inodes used (1.65%, out of 14647296)
         536 non-contiguous files (0.2%)
         364 non-contiguous directories (0.2%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 241103/117/1
    22526883 blocks used (38.46%, out of 58576896)
           0 bad blocks
          11 large files

      219077 regular files
       22022 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
         335 symbolic links (214 fast symbolic links)
           1 socket
------------
      241435 files
  • @goldilocks: I edited the question; it's not a disk failure. – tropiarch Feb 4 '15 at 12:13
  • @goldilocks: Sorry, I added the command I used. – tropiarch Feb 4 '15 at 12:24
0

I've a weird bug like that is quite specific to WD caviar blacks:

see here for Kernel bug report:

https://bugzilla.kernel.org/show_bug.cgi?id=91921

I need to git bisect it when I have the time as it seems to be caused by some commit in kernel 3.13. It worked in Kernel 3.12 and below.

Try this:

echo 0 > /sys/power/pm_async

Then try s2ram

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.