Bug 37042 - linux 3.0.0-rc2 libata-eh.c:4018 ata_scsi_port_error_handler+0x80/0x53d on s2disk
linux 3.0.0-rc2 libata-eh.c:4018 ata_scsi_port_error_handler+0x80/0x53d on s2...
Status: CLOSED CODE_FIX
Product: IO/Storage
Classification: Unclassified
Component: Serial ATA
All Linux
: P1 normal
Assigned To: Jeff Garzik
:
Depends on:
Blocks: 7216 32012
  Show dependency treegraph
 
Reported: 2011-06-09 08:22 UTC by Alex Zhavnerchik
Modified: 2011-08-09 08:27 UTC (History)
6 users (show)

See Also:
Kernel Version: 3.0.0-rc2
Tree: Mainline
Regression: Yes


Attachments
kernel.log (260.59 KB, text/plain)
2011-06-09 08:22 UTC, Alex Zhavnerchik
Details

Description Alex Zhavnerchik 2011-06-09 08:22:38 UTC
Created attachment 61332 [details]
kernel.log

Hi,

I'm using linux kernel 3.0.0-rc2 from git and seems s2disk functionality is broken, s2ram also doesn't work, I suspect that bith these regressions have same roots. And yes this is a regression because it worked OK in linux 2.6.39
Comment 1 Alex Zhavnerchik 2011-06-19 22:50:54 UTC
Nobody interested in fixing this bug?
Comment 2 Florian Mickler 2011-06-22 08:18:38 UTC
Does this help: http://www.spinics.net/lists/dri-devel/msg12162.html ?
Comment 3 Alex Zhavnerchik 2011-06-22 08:56:39 UTC
Nope, it doesn't help.
Comment 4 Tejun Heo 2011-06-22 10:03:04 UTC
Hmmm... the libata warnings are because libata resume() assumes suspend() was called before and PM core, when something goes wrong, ends up calling reusme() without preceding suspend().  We can change so that resume() becomes noop if the port wasn't suspended before but it would be nice if PM doesn't call resume() if the device hasn't been suspended before.  Rafael, what do you think?

Anyways, the libata warning messages shouldn't be harmful and are symptoms of s2disk failing not the cause.  It seems like the part which tells why s2disk is failing is missing from the dmesg.
Comment 5 Rafael J. Wysocki 2011-06-22 19:36:54 UTC
(In reply to comment #4)
> Hmmm... the libata warnings are because libata resume() assumes suspend() was
> called before and PM core, when something goes wrong, ends up calling reusme()
> without preceding suspend().

This shouldn't happen.  If it does, then this is a bug.

Perhaps this patch will help:
https://patchwork.kernel.org/patch/893722/
but it requires this one before:
https://patchwork.kernel.org/patch/892422/

Both are going to be pushed to Linus shortly.
Comment 6 Rafael J. Wysocki 2011-06-26 22:24:50 UTC
Please test the current Linus' tree and report back.
Comment 7 Florian Mickler 2011-08-09 07:19:49 UTC
Ping
Comment 8 Alex Zhavnerchik 2011-08-09 08:15:45 UTC
Hi,

Sorry for delay, now all works OK. I think you can close this bug
Comment 9 Florian Mickler 2011-08-09 08:26:52 UTC
Thx for the feedback. Closing.

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