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
2
  • @goldilocks: I edited the question; it's not a disk failure.
    – tropiarch
    Commented Feb 4, 2015 at 12:13
  • @goldilocks: Sorry, I added the command I used.
    – tropiarch
    Commented Feb 4, 2015 at 12:24

1 Answer 1

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .