Bug 37042
Summary: | linux 3.0.0-rc2 libata-eh.c:4018 ata_scsi_port_error_handler+0x80/0x53d on s2disk | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Alex Zhavnerchik (alex.vizor) |
Component: | Serial ATA | Assignee: | Jeff Garzik (jgarzik) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | akpm, alex.vizor, florian, maciej.rutecki, rjw, tj |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.0.0-rc2 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 7216, 32012 | ||
Attachments: | kernel.log |
Nobody interested in fixing this bug? Does this help: http://www.spinics.net/lists/dri-devel/msg12162.html ? Nope, it doesn't help. 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. (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. Please test the current Linus' tree and report back. Ping Hi, Sorry for delay, now all works OK. I think you can close this bug Thx for the feedback. Closing. |
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