Solid State Drives
Support for Issues Related to Intel® Solid State Drives
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
4365 Discussions

System slow after going back from idle

Community Manager


I got problem with Intel X25-M SATA SSD (SSDSA2MJ080G2C1) drive, it making system runs slow after resuming from idle period. When system just booted everything normal, but if leave PC idle for around 20 mins and then use it again- gnome interface and video playing becomes slow. CPU load become very high



And this is live-time shooting

My primary system is Gentoo Linux amd64 installed on SSD.


And just for test i have installed Ubuntu 11.04 to separate ordinary not SSD harddrive then left PC idle for night then tested video playing and gnome interface- everything was ok.


But when I mounted SSD partion - all become slow.

And dmesg showed this one:


[28697.852920] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts:




[28730.150690] irq 16: nobody cared (try booting with the "irqpoll" option)


[28730.150692] Pid: 0, comm: swapper Tainted: P 2.6.38-8-generic


# 42-Ubuntu


[28730.150693] Call Trace:


[28730.150694] [] ?




[28730.150700] [] ? note_interrupt+0x19a/0x1e0


[28730.150701] [] ? handle_fasteoi_irq+0xdd/0x110


[28730.150703] [] ? handle_irq+0x22/0x40


[28730.150706] [] ? do_IRQ+0x5d/0xe0


[28730.150707] [] ? ret_from_intr+0x0/0x15


[28730.150708] [] ? poll_idle+0x46/0x80


[28730.150711] [] ? poll_idle+0x13/0x80


[28730.150713] [] ? menu_select+0x149/0x340


[28730.150714] [] ? cpuidle_idle_call+0xaa/0x1b0


[28730.150717] [] ? cpu_idle+0xa6/0xf0


[28730.150718] [] ? rest_init+0x75/0x80


[28730.150721] [] ? start_kernel+0x3f5/0x400


[28730.150723] [] ? x86_64_start_reservations+0x132/0x136


[28730.150724] [] ? zap_identity_mappings+0x3e/0x41


[28730.150726] [] ? x86_64_start_kernel+0xcc/0xdb


[28730.150726] handlers:


[28730.150727] [] (rtl8169_interrupt+0x0/0x250 [r8169])


[28730.150733] [] (nv_kern_isr+0x0/0x80 [nvidia])


[28730.150818] Disabling IRQ # 16


[28877.369428] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts:



SSD formated as ext4 in fdisk with default options. Maybe i need some special formating for it?


CPU: Intel Corei7 2600K 3.4 Ghz

Motherboard: Asus P8P67 EVO rev.2.0

3 Replies
Community Manager

When you say "resuming from idle period", do you have your Linux machine set to go into S1, S3, S4, or S5 sleep state (not processor sleep state, actual machine sleep state)? If so, what you could be seeing is any number of on-board chips (southbridge, video card, NIC, USB, etc... -- pick a device of your choice!) not respond to IRQs after waking up/coming out of sleep mode. This is incredibly common, and is usually addressable via driver/kernel fixes. Try disabling S1/S3/S4/S5 sleep mode entirely (meaning do not put your PC to sleep; either leave it running or shut it off when not used). System sleep modes are incredibly common on laptops.

If you're not putting the system into sleep mode:

Is your system using CPU sleep states (not system sleep states) at all, e.g. the CPU configured to drop into C1, C2, or -- worse -- C3 or lower mode when idle? If so, be aware that C3 and "deeper" CPU sleep states are known to cause all sorts of interrupt issues upon resume. For this reason I recommend to folks to not drop their CPU into anything lower than C2 sleep state. You can read about this problem everywhere, on every OS (FreeBSD, Linux, Windows, etc.). Linux and FreeBSD both provide methods to limit what the lowest/deepest sleep state is for the processor.

Be aware that CPU sleep states should be universally applied; e.g. an 8-core system limiting to C2 should apply to all 8 cores. You *can* set the limit on a per-core basis (FreeBSD lets you do this; unsure about Linux), but you SHOULD NOT do that. You want to make sure all the cores are doing the same thing. And just to make it crystal clear: there's no evidence as of this time that CPU sleep states are even the problem. It's pure speculation on my part.

Other ideas/comments:

What you're seeing in your Youtube video looks like sub-par system or video performance; the kernel is probably spending all of its time doing something unoptimally. I do not believe this is TRIM related (TRIM on ext4fs only applies if you mount the filesystem with the "discard" option in fstab).

Also, take a moment to ask yourself something: how exactly would the GNOME interface become slow to use as a result of the SSD? How would dragging a window around, using the GUI, etc. be the fault of the SSD? Unless, of course, GNOME does something stupid like during "sleep mode" shove all of the OSes memory to disk, then try to load it all on resume (Windows calls this "hibernate" mode); I can see a system performing poorly after this.

Ultimately, and above all else: you need to report this problem to the Ubuntu people and not on the Intel SSD forum. I can't stress this enough. Put pressure on the Linux folks to figure this one out.

Community Manager

Hello, thanks for great explanation, realy i was very confused about this issue. For this state i almost sure the problem related to interrupts conflicts, the kernel can't handle proper interrupts after resuming from idle period or else. And good news - I found how to get rid this,

For now i have disabled all non essential hardware in BIOS, because i found that few devices uses one IRQ16.

This one before disabling:



16: 836485 0 0 0 0 0 0 0 IO-APIC-fasteoi xhci_hcd:usb4, eth0, nvidia

And after disabling Firewire, first Realtek network card , USB3.0, Bluetooth



16: 12375 0 0 0 0 0 0 0 IO-APIC-fasteoi nvidia

Actually i have posted this issue to kernel developers and distro developers, related topics

And how you can see - no any understandable explanation there.

Only this thread gave me some clue how to fix that.

p.s. I don't use any sleep modes in Gnome. "Put computer in sleep" disabled

Community Manager

I wonder if your motherboard lacks a LAPIC. Note that IOAPIC and LAPIC are two different things; the former handles routing interrupts to a device on the bus, and the latter handles the actual interrupts. IOAPICs and LAPICs are pretty standard on motherboards these days (anything made in the past 10 years), so possibly Linux has a bug somewhere in it. Also please note not to confuse the terms ACPI and APIC.

Details on APIC infrastructure:

The Linux folks should be able to help you determine what's going on here. I will do my best to follow the threads you've referenced and follow along to see what people determine the issue to be.