Slow sata disk with ahci driver after resume on Ubuntu Natty

Bug #371212 reported by lnprs
This bug report is a duplicate of:  Bug #363693: harddisk becomes slow after standby. Edit Remove
60
This bug affects 10 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: kernel-image-2.6.28-11-generic-di

On a sony laptop with a 250 Go HD WD2500BEVS (5400 rpm) running Ubuntu 9.04 - Kernel 2.6.28-11.42-generic, suspend and resume works fine, but after resuming the whole system becomes extremely slow and completely unusable. The hard disk becomes absolutely unresponsive and very slow, as it can be showned by applying the hdparm command :

Before suspend, "hdparm -tT /dev/sda" gives :

 Timing cached reads: 1900 MB in 2.00 seconds = 950.18 MB/sec
 Timing buffered disk reads: 162 MB in 3.01 seconds = 53.83 MB/sec

after suspend, the same command gives :

  Timing cached reads: 1156 MB in 2.00 seconds = 578.00 MB/sec
  Timing buffered disk reads: 8 MB in 3.20 seconds = 2.50 MB/sec

This issue seems to be related to the use of the ahci driver for managing the disk, and also probably to a IRQ conflict (the SATA and the ethernet controllers share in fact the same IRQ). A workaround is to use the ata_piix driver instead of ahci, but because the ahci driver is built-in and therefore cant be blacklisted, this workaround requires to recompile the kernel with the ahci driver as module. With a kernel 2.6.28-11.42 recompiled in this way, the disk doesn't slow down any more after resuming :

With the ata_piix driver in use (in a recompiled kernel), "hdparm -tT /dev/sda" gives before suspend :

  Timing cached reads: 1732 MB in 2.00 seconds = 866.17 MB/sec
  Timing buffered disk reads: 164 MB in 3.01 seconds = 54.52 MB/sec

After suspend, the same command gives :

  Timing cached reads: 1838 MB in 2.00 seconds = 919.26 MB/sec
  Timing buffered disk reads: 164 MB in 3.00 seconds = 54.61 MB/sec

Another problem related to the first one is that the system doesn't restart properly, it hangs at "The system will now restart". With the ata_piix driver, the restart is fine.

ProblemType: Bug
Architecture: i386
CurrentDmesg:
 [ 30.322677] r8169: eth0: link up
 [ 30.323819] ADDRCONF(NETDEV_UP): eth1: link is not ready
 [ 41.220016] eth0: no IPv6 routers present
DistroRelease: Ubuntu 9.04
HibernationDevice: RESUME=UUID=a455774b-d44d-4827-96d4-d7a3fb0cd26f
MachineType: Sony Corporation VGN-A417M
Package: linux-image-2.6.28-11-generic 2.6.28-11.42
ProcCmdLine: root=UUID=c039a0be-449d-4966-a1b3-07ce4489b67c ro quiet splash locale=fr_FR crashkernel=384M-2G:64M@16M,2G-:128M@16M
ProcEnviron:
 PATH=(custom, user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-11.42-generic
SourcePackage: linux

Revision history for this message
lnprs (lnprs9) wrote :
Revision history for this message
nedosa (nedosa) wrote :

I can verify that I get the same behavior on a Vaio VGN-S5XP with a an Intel Corporation 82801FBM SATA controller and a FUJITSU MHV2100BH 100GB disk. On the latest Jaunty kernel (2.6.28-11-generic), after a resume disk performance completely deteriorates.

The sar utility reports excessive iowait use between 70% and 90%.

I have reverted to kernel 2.6.27-14-generic, where resume works as expected.

Revision history for this message
Sandi (radiofreeearth) wrote :

I found this while researching the same symptoms on a Dell Vostro 1700 1.8ghz Core 2 Duo, 2gb, Kernel 2.6.28-11. Tested and confirmed that prior to resuming system functions normally. Post a resume, disk access slows significantly until a restart.

Revision history for this message
Ben Bacarisse (launchpad-bsb) wrote :

I have the same issue on a Sony Vaio VGN-S4XP. Same SATA controllers as "nedosa". More details if they'd help but the first report seems very thorough.

Revision history for this message
Tom Pesman (tom-tnux) wrote :

I have also the same issue on a Sony Vaio VGN-S5HP.

sudo hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads: 1630 MB in 2.00 seconds = 814.85 MB/sec
 Timing buffered disk reads: 102 MB in 3.01 seconds = 33.88 MB/sec

sudo hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads: 908 MB in 2.00 seconds = 453.65 MB/sec
 Timing buffered disk reads: 8 MB in 3.20 seconds = 2.50 MB/sec

Revision history for this message
Cees de Groot (casedeg) wrote :

Same on Dell Latitude D830 with ST9160823AS drive. hdparm -tT goes down to <10MB buffered disk reads, hdparm -I only has a single diff:

26c26
< R/W multiple sector transfer: Max = 16 Current = ?
---
> R/W multiple sector transfer: Max = 16 Current = 8

where the top line is after resume (=broken), the bottom line after reboot (=working).

Kernel 2.6.28-13-generic #44-Ubuntu

Revision history for this message
Cees de Groot (casedeg) wrote :
Download full text (3.7 KiB)

Just discovered in kern.log:

Jun 24 10:40:37 cees-laptop kernel: [ 971.656026] ACPI: Waking up from system sleep state S3
Jun 24 10:40:37 cees-laptop kernel: [ 971.740095] ACPI: \_SB_.PCI0.PCIE.GDCK - docking
Jun 24 10:40:37 cees-laptop kernel: [ 972.042534] irq 18: nobody cared (try booting with the "irqpoll" option)
Jun 24 10:40:37 cees-laptop kernel: [ 972.042537] Pid: 9, comm: events/0 Tainted: P 2.6.28-13-generic #44-Ubuntu
Jun 24 10:40:37 cees-laptop kernel: [ 972.042538] Call Trace:
Jun 24 10:40:37 cees-laptop kernel: [ 972.042544] [<c04fca36>] ? printk+0x18/0x1a
Jun 24 10:40:37 cees-laptop kernel: [ 972.042547] [<c017fd47>] __report_bad_irq+0x27/0x90
Jun 24 10:40:37 cees-laptop kernel: [ 972.042551] [<c0305a85>] ? acpi_ns_search_one_scope+0x15/0x3a
Jun 24 10:40:37 cees-laptop kernel: [ 972.042553] [<c017ff0e>] note_interrupt+0x15e/0x1a0
Jun 24 10:40:37 cees-laptop kernel: [ 972.042555] [<c017ead9>] ? handle_IRQ_event+0x39/0x70
Jun 24 10:40:37 cees-laptop kernel: [ 972.042557] [<c01804d3>] handle_fasteoi_irq+0xa3/0xd0
Jun 24 10:40:37 cees-laptop kernel: [ 972.042560] [<c030d841>] ? acpi_ut_delete_internal_obj+0x13d/0x145
Jun 24 10:40:37 cees-laptop kernel: [ 972.042562] [<c010684e>] do_IRQ+0x7e/0xa0
Jun 24 10:40:37 cees-laptop kernel: [ 972.042564] [<c01051f3>] common_interrupt+0x23/0x30
Jun 24 10:40:37 cees-laptop kernel: [ 972.042567] [<c030e36a>] ? acpi_ut_create_generic_state+0x43/0x4e
Jun 24 10:40:37 cees-laptop kernel: [ 972.042569] [<c03095b2>] acpi_ps_push_scope+0x15/0x63
Jun 24 10:40:37 cees-laptop kernel: [ 972.042571] [<c0309266>] acpi_ps_parse_loop+0x1a5/0x2a7
Jun 24 10:40:37 cees-laptop kernel: [ 972.042572] [<c03085a4>] acpi_ps_parse_aml+0x6d/0x267
Jun 24 10:40:37 cees-laptop kernel: [ 972.042574] [<c0309895>] acpi_ps_execute_method+0x11c/0x1d3
Jun 24 10:40:37 cees-laptop kernel: [ 972.042576] [<c0306450>] acpi_ns_evaluate+0x11c/0x1e4
Jun 24 10:40:37 cees-laptop kernel: [ 972.042579] [<c0305fed>] acpi_evaluate_object+0xdd/0x1bc
Jun 24 10:40:37 cees-laptop kernel: [ 972.042582] [<c02f80ed>] ? acpi_os_execute_hp_deferred+0x0/0x36
Jun 24 10:40:37 cees-laptop kernel: [ 972.042584] [<c02f80ed>] ? acpi_os_execute_hp_deferred+0x0/0x36
Jun 24 10:40:37 cees-laptop kernel: [ 972.042586] [<c0314104>] handle_dock+0x82/0xc0
Jun 24 10:40:37 cees-laptop kernel: [ 972.042588] [<c0305c49>] ? acpi_get_data+0x51/0x60
Jun 24 10:40:37 cees-laptop kernel: [ 972.042590] [<c03144aa>] dock_notify+0x5c/0x197
Jun 24 10:40:37 cees-laptop kernel: [ 972.042592] [<c014b4ed>] ? flush_workqueue+0x3d/0x50
Jun 24 10:40:37 cees-laptop kernel: [ 972.042594] [<c03145f8>] acpi_dock_deferred_cb+0x13/0x1d
Jun 24 10:40:37 cees-laptop kernel: [ 972.042596] [<c02f8115>] acpi_os_execute_hp_deferred+0x28/0x36
Jun 24 10:40:37 cees-laptop kernel: [ 972.042598] [<c014afbd>] run_workqueue+0x8d/0x150
Jun 24 10:40:37 cees-laptop kernel: [ 972.042600] [<c014ef0a>] ? prepare_to_wait+0x3a/0x70
Jun 24 10:40:37 cees-laptop kernel: [ 972.042602] [<c014b238>] worker_thread+0x88/0xf0
Jun 24 10:40:37 cees-laptop kernel: [ 972.042604] [<c014ecb0>] ? autoremove_wake_function+0x0/0x50
Jun 24 10:40:37 cees-laptop k...

Read more...

Revision history for this message
Cees de Groot (casedeg) wrote :

Just confirmed over a couple of standby/resume cycles - so far there's a perfect correlation between the "nobody cared about IRQ 18" log message and a slow drive. Doesn't happen all the time, but does happen most of the time.

Revision history for this message
Cees de Groot (casedeg) wrote :

upgraded to 2.6.30-020630-generic - suspend/resume works like a charm :)

Revision history for this message
mehturt (mehturt) wrote :

I see the same problem on Dell D630, both slow HDD after suspend and restart problem.

Revision history for this message
nedosa (nedosa) wrote :

I still the same problem in karmic as in Jaunty on the same Sony Vaio laptop as in comment #2.

Revision history for this message
Dean Fox (spam-myname) wrote :

It's not just with ACHI and not just after resume. I don't have ACHI turned on in my BIOS (tried both on and off) and I haven't just resumed... I stumbled across this looking for my own answer. I'm doing large file transfers between SATA drives on a AMD64.

Both drives:
/dev/sda:
 Timing cached reads: 7228 MB in 2.00 seconds = 3615.06 MB/sec
 Timing buffered disk reads: 300 MB in 3.01 seconds = 99.83 MB/sec
dfox@dfox-asus:~$ sudo hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads: 7284 MB in 2.00 seconds = 3643.72 MB/sec
 Timing buffered disk reads: 318 MB in 3.01 seconds = 105.59 MB/sec

But when I drag and drop a 4gig folder between the two I'm lucky to get file transfer speeds of 8 Mb/s. More likely it's in the 5 Mb/s range. I'm reading in other blogs this is an exclusive Ubuntu and perhaps a Ubuntu AMD64 problem as it's not happening under OpenSuSE or Windows 7 with the same servers. I just upgraded to 9.10 too.

Revision history for this message
Camille Dominique (cduntu) wrote :

I confirm this bug on a Latitude D630, both under Jaunty i386 (currently kernel 2.6.28-17-generic) and Karmic amd64 (kernel 2.6.31-17-generic). Is this bug going to be fixed any time soon? Does it need more information?

Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

Hi lnprs,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-upstream-testing
tags: added: kj-triage
Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
mehturt (mehturt) wrote :

I just installed 2.6.34 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.34-rc1/ and so far it looks good after suspend/resume, I tried to suspend/resume 3 times.

Revision history for this message
Bojan Cekrlic (bojan-cekrlic) wrote :

As noted in #6, same computer (Dell D830), different drive WD 300G, 2.6.32-22-generic #36-Ubuntu, x86_64

Revision history for this message
xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob) wrote :

This bug seems to have resurfaced.

Revision history for this message
Brad Figg (brad-figg) wrote : Unsupported series, setting status to "Won't Fix".

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: Confirmed → Won't Fix
Revision history for this message
xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob) wrote :

Please add all your commetns at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/363693 and also mark the bug as affecting you at that bug location too.

summary: - Slow sata disk with ahci driver after resume on Ubuntu Jaunty
+ Slow sata disk with ahci driver after resume on Ubuntu Natty
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.