# System stutters when USB drive is connected

## penetrode

I have a Transcend Storejet 500 GB USB 2.0 external hard disk. The system is an IBM Thinkpad T40, in case that is relevant.

Whenever this disk is attached to the system (which I have confirmed supports USB 2.0, both hardware and in kernel), I have problems with real-time applications (such as audio and video). About every 10 seconds or so, the video stutters or skips.

This happens whether the video is on the USB disk or not. The effect is system-wide. I have had problems with Amarok as well, which is frustrating, since my music collection is also on this USB drive.

I had usb-storage debugging switched on in the kernel, but it wasn't showing any errors -- everything looks peachy. I turned off debugging, thinking that the extra overhead might be causing the problem. No change.

The system is running KDE 4. Strigi is deactivated. hald is not polling the device because it doesn't treat it as removable, so that's not it, but the system does automount. There is nothing in the CD-ROM drive.

The moment I unmount the disk and disconnect it, the problem disappears. I have other USB devices connected to the system over an external USB hub, and those don't cause any problems. The Storejet, when connected, is always connected directly to the system (no hub in between).

The system is not that old and has oodles of RAM (2 GB), and it works well without the drive connected, so I can't help but think this is a tuning/configuration problem.

Any ideas? Help is appreciated!

----------

## timeBandit

Do USB hard drives support DMA? (I don't own any.) The first thing I'd check is whether DMA is possible and active and, if not, enable it (using hdparm).

----------

## eccerr0r

Depends on the USB host adapter, I'd think...  Though I'm not familiar enough with USB internals... Either way it can't be enabled with hdparm.

Currently I (temporarily) run Gentoo on my EeePC off of an external 40G USB2 disk, I don't see the stuttering, it seems to run as smoothly as if it were on an internal disk.  This is with an ICH7 and 945GM.

penetrode, do you see kernel messages in your syslog/dmesg?  Are USB interrupts enabled?

----------

## penetrode

 *timeBandit wrote:*   

> Do USB hard drives support DMA? (I don't own any.) The first thing I'd check is whether DMA is possible and active and, if not, enable it (using hdparm).

 

I ran hdparm on the drive when connected and got this:

 *Quote:*   

> # mount
> 
> /dev/hda5 on / type ext3 (rw,noatime)
> 
> proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
> ...

 

 *Quote:*   

> 
> 
> # hdparm /dev/sda
> 
> /dev/sda:
> ...

 

It sees a drive, but it can't get any useful information from it. Anyway, DMA only applies for internal bus connected drives.

This behaviour sure looks like an interrupt problem.

----------

## penetrode

 *eccerr0r wrote:*   

> Depends on the USB host adapter, I'd think...  Though I'm not familiar enough with USB internals... Either way it can't be enabled with hdparm.
> 
> Currently I (temporarily) run Gentoo on my EeePC off of an external 40G USB2 disk, I don't see the stuttering, it seems to run as smoothly as if it were on an internal disk.  This is with an ICH7 and 945GM.
> 
> penetrode, do you see kernel messages in your syslog/dmesg?  Are USB interrupts enabled?

 

I started with the debug kernel again and see this in dmesg:

```
usb-storage: Bulk data transfer result 0x0                                     

usb-storage: Attempting to get CSW...                                          

usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes                         

usb-storage: Status code 0; transferred 13/13                                  

usb-storage: -- transfer complete                                              

usb-storage: Bulk status result = 0                                            

usb-storage: Bulk Status S 0x53425355 T 0x7885 R 0 Stat 0x0                    

usb-storage: scsi cmd done, result=0x0                                         

usb-storage: *** thread sleeping.                                              

usb-storage: queuecommand called                                               

usb-storage: *** thread awakened.                                              

usb-storage: Command READ_10 (10 bytes)                                        

usb-storage:  28 00 00 66 38 33 00 00 80 00                                    

usb-storage: Bulk Command S 0x43425355 T 0x7886 L 65536 F 128 Trg 0 LUN 0 CL 10

usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes                         

usb-storage: Status code 0; transferred 31/31                                  

usb-storage: -- transfer complete                                              

usb-storage: Bulk command transfer result=0                                    

usb-storage: usb_stor_bulk_transfer_sglist: xfer 65536 bytes, 16 entries       

usb-storage: Status code 0; transferred 65536/65536                            

usb-storage: -- transfer complete                                              

usb-storage: Bulk data transfer result 0x0                                     

usb-storage: Attempting to get CSW...                                          

usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes                         

usb-storage: Status code 0; transferred 13/13                                  

usb-storage: -- transfer complete                                              

usb-storage: Bulk status result = 0                                            

usb-storage: Bulk Status S 0x53425355 T 0x7886 R 0 Stat 0x0                    

usb-storage: scsi cmd done, result=0x0                                         

usb-storage: *** thread sleeping.                                              

usb-storage: queuecommand called                                               

usb-storage: *** thread awakened.                                              

usb-storage: Command READ_10 (10 bytes)                                        

usb-storage:  28 00 00 66 38 b3 00 00 80 00                                    

usb-storage: Bulk Command S 0x43425355 T 0x7887 L 65536 F 128 Trg 0 LUN 0 CL 10

usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes                         

usb-storage: Status code 0; transferred 31/31                                  

usb-storage: -- transfer complete                                              

usb-storage: Bulk command transfer result=0                                    

usb-storage: usb_stor_bulk_transfer_sglist: xfer 65536 bytes, 16 entries       

usb-storage: Status code 0; transferred 65536/65536                            

usb-storage: -- transfer complete                                              

usb-storage: Bulk data transfer result 0x0                                     

usb-storage: Attempting to get CSW...                                          

usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes                         

usb-storage: Status code 0; transferred 13/13                                  

usb-storage: -- transfer complete                                              

usb-storage: Bulk status result = 0                                            

usb-storage: Bulk Status S 0x53425355 T 0x7887 R 0 Stat 0x0                    

usb-storage: scsi cmd done, result=0x0                                         

usb-storage: *** thread sleeping.                                              

usb-storage: queuecommand called                                               

usb-storage: *** thread awakened.                                              

usb-storage: Command READ_10 (10 bytes)                                        

usb-storage:  28 00 00 66 39 33 00 00 80 00                                    

usb-storage: Bulk Command S 0x43425355 T 0x7888 L 65536 F 128 Trg 0 LUN 0 CL 10

usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes                         

usb-storage: Status code 0; transferred 31/31                                  

usb-storage: -- transfer complete

usb-storage: Bulk command transfer result=0

usb-storage: usb_stor_bulk_transfer_sglist: xfer 65536 bytes, 1 entries

usb-storage: Status code 0; transferred 65536/65536

usb-storage: -- transfer complete

usb-storage: Bulk data transfer result 0x0

usb-storage: Attempting to get CSW...

usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes

usb-storage: Status code 0; transferred 13/13

usb-storage: -- transfer complete

usb-storage: Bulk status result = 0

usb-storage: Bulk Status S 0x53425355 T 0x7888 R 0 Stat 0x0

usb-storage: scsi cmd done, result=0x0

usb-storage: *** thread sleeping.

usb-storage: queuecommand called

usb-storage: *** thread awakened.

usb-storage: Command READ_10 (10 bytes)

usb-storage:  28 00 00 66 39 b3 00 00 80 00

usb-storage: Bulk Command S 0x43425355 T 0x7889 L 65536 F 128 Trg 0 LUN 0 CL 10

usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes

usb-storage: Status code 0; transferred 31/31

usb-storage: -- transfer complete

usb-storage: Bulk command transfer result=0

usb-storage: usb_stor_bulk_transfer_sglist: xfer 65536 bytes, 1 entries

usb-storage: Status code 0; transferred 65536/65536

usb-storage: -- transfer complete

usb-storage: Bulk data transfer result 0x0

usb-storage: Attempting to get CSW...

usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes

usb-storage: Status code 0; transferred 13/13

usb-storage: -- transfer complete

usb-storage: Bulk status result = 0

usb-storage: Bulk Status S 0x53425355 T 0x7889 R 0 Stat 0x0

usb-storage: scsi cmd done, result=0x0

usb-storage: *** thread sleeping.

```

Lots of noise, but nothing untoward.

How do I determine if USB interrupts are enabled?

----------

## eccerr0r

The interrupts are usually a BIOS config.  You should see ehci_hcd taking an interrupt in /proc/interrupts.

Does it do this with just that disk or with any USB disk?

----------

## penetrode

Yes, it appears to be sharing IRQ 11:

```
$ cat /proc/interrupts

           CPU0

  0:     635705    XT-PIC-XT        timer

  1:       8625    XT-PIC-XT        i8042

  2:          0    XT-PIC-XT        cascade

  3:          4    XT-PIC-XT

  4:          6    XT-PIC-XT

  5:          3    XT-PIC-XT

  6:          5    XT-PIC-XT        floppy

  7:          0    XT-PIC-XT        parport0

  8:          2    XT-PIC-XT        rtc0

  9:       7652    XT-PIC-XT        acpi

 10:          3    XT-PIC-XT

 11:      13448    XT-PIC-XT        yenta, yenta, ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4, Intel 82801DB-ICH4, Intel 82801DB-ICH4 Modem, eth1, eth0

 12:     184060    XT-PIC-XT        i8042

 14:      18063    XT-PIC-XT        ide0

 15:      57088    XT-PIC-XT        ide1

NMI:          0   Non-maskable interrupts

LOC:          0   Local timer interrupts

SPU:          0   Spurious interrupts

CNT:          0   Performance counter interrupts

PND:          0   Performance pending work

RES:          0   Rescheduling interrupts

CAL:          0   Function call interrupts

TLB:          0   TLB shootdowns

TRM:          0   Thermal event interrupts

THR:          0   Threshold APIC interrupts

MCE:          0   Machine check exceptions

MCP:         22   Machine check polls

ERR:          0

MIS:          0

```

Next question is -- should that be enabled or disabled? Is it already in the state it should be, or should I be turning it off?

----------

## penetrode

 *eccerr0r wrote:*   

> The interrupts are usually a BIOS config.  You should see ehci_hcd taking an interrupt in /proc/interrupts.
> 
> Does it do this with just that disk or with any USB disk?

 

I haven't got another USB disk to test with, unfortunately... should it be using an interrupt, or not?

This is cat /proc/interrupts without the USB drive connected. It doesn't look much different:

```
$ cat /proc/interrupts

           CPU0

  0:    3785494    XT-PIC-XT        timer

  1:      66978    XT-PIC-XT        i8042

  2:          0    XT-PIC-XT        cascade

  3:          4    XT-PIC-XT

  4:          6    XT-PIC-XT

  5:          3    XT-PIC-XT

  6:          6    XT-PIC-XT        floppy

  7:          0    XT-PIC-XT        parport0

  8:          2    XT-PIC-XT        rtc0

  9:      43191    XT-PIC-XT        acpi

 10:          3    XT-PIC-XT

 11:    2023990    XT-PIC-XT        yenta, yenta, ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4, eth1, Intel 82801DB-ICH4, Intel 82801DB-ICH4 Modem, eth0

 12:       1576    XT-PIC-XT        i8042

 14:     122028    XT-PIC-XT        ide0

 15:     338972    XT-PIC-XT        ide1

NMI:          0   Non-maskable interrupts

LOC:          0   Local timer interrupts

SPU:          0   Spurious interrupts

CNT:          0   Performance counter interrupts

PND:          0   Performance pending work

RES:          0   Rescheduling interrupts

CAL:          0   Function call interrupts

TLB:          0   TLB shootdowns

TRM:          0   Thermal event interrupts

THR:          0   Threshold APIC interrupts

MCE:          0   Machine check exceptions

MCP:        129   Machine check polls

ERR:          0

MIS:          0

```

----------

## eccerr0r

Honestly I'm at a loss now, pointing towards defective hardware...

Looks like interrupts are being allocated fine.

One thing that does stick out is that your interrupt system is still using IBM PC/XT style (i.e., ancient) edge triggered interrupts instead of using APIC.  Does APIC work or does it cause other issues?

This is not the reason for the issues as one of my PCs also uses XT edge triggered interrupts and it works fine...

Also...what kernel version?  Perhaps the particular USB subsystem driver got updated to fix these hang issues...

----------

