Bug 12202
Summary: | crappy disk performance after suspend/resume [ata_piix?] | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Carl Michal (michal) |
Component: | Serial ATA | Assignee: | Tejun Heo (tj) |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.28-rc8 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
dmesg from boot/suspend/resume
lspci -nnvvxxx before suspend lspci -nnvvvxxx after suspend ata_piix-preserve-iocfg lspci -nnvvvxxx output before suspend dmesg from resume. ata_piix-preserve-iocfg-1 dmesg output: boot, suspend, resume ata_piix-preserve-iocfg-2 dmesg output: boot, suspend, resume ata_piix-save-iocfg |
Description
Carl Michal
2008-12-11 17:19:25 UTC
Please attach (instead of posting inline) the output of dmesg after suspend/resume. Thanks.b Created attachment 19259 [details]
dmesg from boot/suspend/resume
The resume starts at 57.17 s
I subsequently added a printk into libata-core.c at the start of cable_is_40wire. ap->cbl shows up there as ATA_CBL_PATA40 on resume, but as ATA_CBL_PATA80 on a fresh boot.
Yeah, I had similar report and was testing patch but the bug reporter disappeared before the problem was resolved. Please don't go away. :-) Can you please post the output of "lspci -nnvvvxxx" before and after suspend/resume? Created attachment 19302 [details]
lspci -nnvvxxx before suspend
Created attachment 19303 [details]
lspci -nnvvvxxx after suspend
as requested. I'll try not to disappear.
As a workaround, I found that using the kernel parameter:
libata.force=1.00:udma5
does force it back to udma5. I booted without this option to collect the lspci data.
A printk added at line 630 of ata_piix.c (in ich_pata_cable_detect) shows that the pci config byte is read as decimal 19 on initial boot, but as 1 after resume.
Created attachment 19418 [details]
ata_piix-preserve-iocfg
Sorry about the delay. Can you please test the attached patch? It saves iocfg (the cable detection register) on suspend and restores it on resume. Please report whether it works or not and the output of "lspci -nnvvvxxx -s 00:1f.1" before and after resume with the patch applied. Thanks.
sorry, no joy. dmesg still reports: limited to UDMA/33 due to 40-wire cable.
The only differences in the lspci output are at bytes 4A, 54 and 55.
diff lspci.before lspci.after
16,17c16,17
< 40: 07 e3 00 40 00 00 00 00 01 00 01 00 00 00 00 00
< 50: 00 00 00 00 12 30 00 00 00 00 00 00 00 00 00 00
---
> 40: 07 e3 00 40 00 00 00 00 01 00 02 00 00 00 00 00
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Created attachment 19439 [details]
lspci -nnvvvxxx output before suspend
Can you please post dmesg after resume? Created attachment 19445 [details]
dmesg from resume.
Sorry - should have done this earlier.
The attachment is the dmesg from resume after the first suspend after a clean boot.
Afterwards, I did a hibernate, and the dmesg output from that thaw says:
XXX restored IOCFG to 0x0
with three suspend/resumes in a row, dmesg shows: XXX restored IOCFG to 0x3012 XXX restored IOCFG to 0x1000 XXX restored IOCFG to 0x1000 Created attachment 19465 [details]
ata_piix-preserve-iocfg-1
Hmmm... Something is clearing IOCFG afterwards. Can you please apply the attached patch and post the resulting log?
Created attachment 19466 [details]
dmesg output: boot, suspend, resume
patched as requested. dmesg output attached.
Created attachment 19467 [details]
ata_piix-preserve-iocfg-2
Okay, hopefully the last one. It seems ata_piix is somehow clearing the wrong bits during resume. Can you please repeat the test with the attached patch and post the log? Thanks.
Created attachment 19470 [details]
dmesg output: boot, suspend, resume
somewhere between the two calls to: piix_pata_prereset.
Created attachment 19518 [details]
ata_piix-save-iocfg
Can you please test the attached patch?
That fixes it. I don't understand where the problem comes from in the first place though - since it seems to work in 2.6.24... It's due to the ATA-ACPI support. _STM during resume corrupts iocfg. The other guy who reported this problem tracked it down. The patch is posted upstream. I'll close this one as duplicate. Thanks and happy new year. *** This bug has been marked as a duplicate of bug 11879 *** |