Heavy I/O on Sandybridge systems with small memory footprints causes system hangs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OEM Priority Project |
Fix Released
|
Critical
|
Chris Van Hoof | ||
linux (Ubuntu) |
Fix Released
|
Critical
|
Colin Ian King | ||
Natty |
Fix Released
|
Critical
|
Colin Ian King |
Bug Description
System hangs have been observed when performing heavy i/o on sandybridge systems with small memory footprints (less than 4GB of memory in this case).
The issue was first discovered when running an a customized Natty installer from an OEM. The installer initially copies all the files off to a partition on the hard drive, and then the system is installed from the hard disk. It is during the file copy phase that the systems will hang. The hang is either indefinite or sometimes the system will recover and complete the installation after several minutes.
A way to reproduce this behavior on a vanilla natty AMD64 image installer image is as follows. You will need a sandybridge system with UMA graphics, and preferably only 1GB of memory installed. 1GB seems to reproduce it the most frequently.
1) Boot the image up in single user mode
2) Run this attached script
It sometimes doesn't happen on the first try, but usually by the second or third try the behavior will happen (a tell tale sign is the HDD indicator freezes).
The script wraps around the ubiquity file copy routine as it's very I/O intensive since everything will be md5'ed as it's copied. It first copies from the USB stick to a 2G partition, and then from that 2G partition to another partition.
Changed in oem-priority: | |
importance: | Undecided → Critical |
tags: | added: hwe-blocker |
Changed in oem-priority: | |
assignee: | nobody → Canonical Platform QA Team (canonical-platform-qa) |
Changed in linux (Ubuntu): | |
assignee: | nobody → Chris Van Hoof (vanhoof) |
importance: | Undecided → Critical |
Changed in linux (Ubuntu): | |
assignee: | Chris Van Hoof (vanhoof) → Colin King (colin-king) |
Changed in oem-priority: | |
assignee: | Canonical Platform QA Team (canonical-platform-qa) → Chris Van Hoof (vanhoof) |
status: | New → Confirmed |
summary: |
- heavy i/o on sandybridge systems with small memory footprints causes + Heavy I/O on Sandybridge systems with small memory footprints causes system hangs |
Changed in linux (Ubuntu): | |
status: | In Progress → Fix Released |
Changed in linux (Ubuntu Natty): | |
assignee: | nobody → Colin King (colin-king) |
status: | New → Fix Committed |
Changed in oem-priority: | |
status: | Confirmed → Fix Committed |
Changed in linux (Ubuntu Natty): | |
importance: | Undecided → Critical |
Changed in oem-priority: | |
status: | Fix Committed → Fix Released |
I did some testing on this issue, and initially thought I had a culprit with mkfs.ext4:
http:// people. canonical. com/~vanhoof/ lazy_itable_ init_testing_ plus_dirty/
However it has been proven to occur even with a more generic file copy operation.
I was able to grab some perf top results today during an instance of this lockup:
http:// people. canonical. com/~vanhoof/ lazy_itable_ init_testing_ plus_dirty/ perftop/
Which does show a large spike in shrink_slab when this hits.