12

My desktop is usually very responsive, even under heavy load. But when I copy files to a USB drive, it always locks up after some time. By "lock up", I mean:

  • Moving focus from one window to another can take 10-20s
  • Switching desktops can take 10-20s
  • Videos don't update anymore (in YouTube, the audio continues to play, only the video freezes)

The system load isn't exceptionally high when this happens. Sometimes, I see a lot of white on xosview indicating that the kernel is busy somewhere.

At first glance, it looks as if copying files to the USB drive would interfere somehow with compiz but I can't imagine what the connection could be.

Here is the output of htop:

Output of htop shortly after the hang

Here is the output of iostat -c -z -t -x -d 1 during a 2 minute hang:

19.07.2012 20:38:22
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1,27    0,00    0,38   37,52    0,00   60,84

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdg               0,00     2,00    0,00  216,00     0,00 109248,00  1011,56   247,75  677,69    0,00  677,69   4,63 100,00

As you can see, only the external harddisk is active. Here is the complete log: http://pastebin.com/YNWTAkh4

The hang started at 20:38:01 and ended at 20:40:19.

Software information:

  • openSUSE 12.1
  • KDE 4.7.x
  • Filesystems: reiserfs and btrfs on my internal harddisk, btrfs on the USB drive
Aaron Digulla
  • 6,098
  • 1
    Have you tried mounting the USB drive sync to see what effect (if any) this has? – Alexios Jul 11 '12 at 15:00
  • 2
    A disadvantage of USB is the fact that it heavily relies on the CPU for IO. What sort of CPU do does your system have? Append the output of grep name /proc/cpuinfo to your question please. – jippie Jul 11 '12 at 16:15
  • 1
    Do you drag and drop the files using dolphin? If so, try cp from the command line to exclude possible dolphin bugs. – Jari Laamanen Jul 11 '12 at 23:39
  • @JariLaamanen: I'm using rsync from the command line. – Aaron Digulla Jul 12 '12 at 07:01
  • @jippie: I have an i7-3770 and 16GB RAM. CPU power shouldn't be a problem. The system doesn't swap when it happend. I can see about 10GB cached data in memory in xosview – Aaron Digulla Jul 16 '12 at 09:47
  • Can you add the output of top to your question? Make sure it shows the separate cores (strike 1) and the State column 'S' is shown. – jippie Jul 16 '12 at 20:33
  • 1
    @jippie: Not really because the UI locks up when it happens, so I can't make a screenshot. I'll try to create a log with iostat -c -z -d 1 – Aaron Digulla Jul 17 '12 at 08:34
  • I had the same problem with cp instead of rsync. Using nice fixed it for me. – Marco Jul 19 '12 at 19:24

4 Answers4

4

My first guess was btrfs since the I/O processes of this file system sometimes take over. But it wouldn't explain why X locks up.

Looking at the interrupts, I see this:

# cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       
  0:        179          0          0          0          0          0          0          0  IR-IO-APIC-edge      timer
  1:          6          0          0          0          0          0          0          0  IR-IO-APIC-edge      i8042
  8:          1          0          0          0          0          0          0          0  IR-IO-APIC-edge      rtc0
  9:          0          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   acpi
 12:         10          0          0          0          0          0          0          0  IR-IO-APIC-edge      i8042
 16:    3306384          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb1, nvidia, mei, eth1

Well, duh. The USB driver uses the same IRQ as the graphics card and it is first in the chain. If it locks up (because the file system does something expensive), the graphics card starves (and the network, too).

Aaron Digulla
  • 6,098
2

I had seen similar problems with openSUSE 12.1's linux-3.1 kernel and found that disabling transparent huge pages helped:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

The underlying problem is that if an application allocates 4MB or more, the kernel will try to give it a huge page, for which it needs a whole contiguous 4MB RAM. Now, if there are many dirty pages around, that still need to be written to a slow USB device, it waits for that IO to finish before continuing with the memory allocation.

Aaron Digulla
  • 6,098
Bernhard M.
  • 198
  • 1
  • 6
1

As mentioned, this probably has to do with the kernel hugepages setup. I know several people with this problem. You can find several documentation about it in the web, e.g.

I have completely fixed the problem on my setup by doing the following. Notice YMMV, not all the fixes below may be necessary, and maybe they'll not be sufficient. I may have forgotten something to be honest. Anyhow that's my setup and it works.

  • Use linux-ck kernel
  • echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
  • echo never > /sys/kernel/mm/transparent_hugepage/defrag
Community
  • 1
AF7
  • 818
-2

Change the cable. Remove oxid from usb port/cables.

luis
  • 1