Comment 71 for bug 1107150

Revision history for this message
Stijn Volckaert (stijn-volckaert) wrote : Re: B75 Chipset I/O Problems

Great to finally see this bug being worked on... I found a bunch of similar bug reports that were finally closed (and supposedly solved) because the original bug reporter ended up installing a 64-bit kernel instead.

Here's what I found out so far:
* This bug only affects writing to block devices. Read speeds are absolutely fine. It would be nice if the other people could confirm this!
* This bug isn't related to the B75 chipset. I'm also experiencing this bug on a somewhat older chipset. I believe I'm using an Intel Q57 Express chipset but I doubt whether this is really relevant.
* It will only trigger with the x86 kernel, not the amd64 kernel.
* This bug _probably_ isn't limited to Ubuntu, Ubuntu is just the only distro that triggers it. I tested the following distributions:

  + Fedora 19 (32 bit) live cd (3.9.x kernel) -> works fine
  + OpenSuSe 13.1 (32 bit) live cd (3.11 kernel) -> works fine
  + Ubuntu 13.10 (32 bit) live cd (3.11 kernel) -> doesn't work
  + Ubuntu 13.10 (64 bit) live cd (3.11 kernel) -> works fine
  + Linux Mint 16 (32 bit) live cd (3.11 kernel) -> doesn't work
  + Debian 7.2 (32 bit) live cd (3.2 kernel) -> works fine

I then went back to Ubuntu 12.10 32 bit (3.5.5 kernel) and confirmed that:

  + Running with only 8 Gigs of RAM gives me write speeds of 180-200Mb/sec
  + Running with 16 Gigs of RAM gives me write speeds of 160-180Mb/sec
  + Running with 32 Gigs of RAM gives me write speeds of 1.5-5.5Mb/sec

I downloaded a stock 3.5.5 kernel tarball and compiled it with the ubuntu kernel config. The problem persists.

There is a similar bug where pc's suddenly get terrible write speeds to block devices after waking up from suspend. This bug is caused by the fact that on some pc's MTRR registers change after waking up. After comparing Ubuntu, Fedora and Suse kernel configs, I noticed that Ubuntu is the only distro using the MTRR sanitizer. I disabled it but the problem persists.

This definitely seems like an mm problem to me. I'd like to test the latest test kernel you've built but it's only available for amd64 (which never had the problem anyway).