External USB2 HDD affects speed hda

External USB2 HDD affects speed hda

[Rene Herman]

Hi Bartlomiej.

My Maxtor 6Y120P0 on AMD756 (UDMA66) normally gives me 50 MB/s according 
to hdparm -t:

===
# hdparm -t /dev/hda

/dev/hda:
  Timing buffered disk reads:  152 MB in  3.01 seconds =  50.57 MB/sec
===

However, the second I switch on my external USB2 drive (Western Digital 
Essential 160G, connected via a PCI card USB2 controller, on a private IRQ):

===
usb 1-3: new high speed USB device using ehci_hcd and address 3
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
   Vendor: WD        Model: 1600BB External   Rev: 0412
   Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
sda: assuming drive cache: write through
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
sda: assuming drive cache: write through
  sda: sda1 sda2
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
usb-storage: device scan complete
===

the hdparm -t result drops down to 42MB/s:

===
# hdparm -t /dev/hda

/dev/hda:
  Timing buffered disk reads:  130 MB in  3.04 seconds =  42.77 MB/sec
===

Switching the USB2 HDD off again does not work to bring back the 50 MB/s:

===
# eject sda
# hdparm -t /dev/hda

/dev/hda:
  Timing buffered disk reads:  128 MB in  3.01 seconds =  42.57 MB/sec

[ push button ]

usb 1-3: USB disconnect, address 3

# hdparm -t /dev/hda

/dev/hda:
  Timing buffered disk reads:  130 MB in  3.04 seconds =  42.73 MB/sec
===

After a reboot, it's 50 MB/s again. Any idea what this is?

The USB HDD is not firing interrupts or anything. It just sits idle. 
Fully repeatable on 2.6.11.11 and 2.6.12-rc5.

Rene.

Re: External USB2 HDD affects speed hda

[Pavel Machek]

On Út 31-05-05 01:21:37, Rene Herman wrote:
> Hi Bartlomiej.
> 
> My Maxtor 6Y120P0 on AMD756 (UDMA66) normally gives me 50 MB/s according 
> to hdparm -t:
> 
> ===
> # hdparm -t /dev/hda
> 
> /dev/hda:
>  Timing buffered disk reads:  152 MB in  3.01 seconds =  50.57 MB/sec
> ===
> 
> However, the second I switch on my external USB2 drive (Western Digital 
> Essential 160G, connected via a PCI card USB2 controller, on a private IRQ):
> 
> ===
> usb 1-3: new high speed USB device using ehci_hcd and address 3
> scsi0 : SCSI emulation for USB Mass Storage devices
> usb-storage: device found at 3
> usb-storage: waiting for device to settle before scanning
>   Vendor: WD        Model: 1600BB External   Rev: 0412
>   Type:   Direct-Access                      ANSI SCSI revision: 00
> SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
> sda: assuming drive cache: write through
> SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
> sda: assuming drive cache: write through
>  sda: sda1 sda2
> Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
> usb-storage: device scan complete
> ===
> 
> the hdparm -t result drops down to 42MB/s:
> 
> ===
> # hdparm -t /dev/hda
> 
> /dev/hda:
>  Timing buffered disk reads:  130 MB in  3.04 seconds =  42.77 MB/sec
> ===
> 
> Switching the USB2 HDD off again does not work to bring back the 50 MB/s:
> 
> ===
> # eject sda
> # hdparm -t /dev/hda
> 
> /dev/hda:
>  Timing buffered disk reads:  128 MB in  3.01 seconds =  42.57 MB/sec
> 
> [ push button ]
> 
> usb 1-3: USB disconnect, address 3
> 
> # hdparm -t /dev/hda
> 
> /dev/hda:
>  Timing buffered disk reads:  130 MB in  3.04 seconds =  42.73 MB/sec
> ===
> 
> After a reboot, it's 50 MB/s again. Any idea what this is?
> 
> The USB HDD is not firing interrupts or anything. It just sits idle. 
> Fully repeatable on 2.6.11.11 and 2.6.12-rc5.

USB controller generating extra DMA load? Try rmmoding usb to see if
it goes away.
								Pavel

Re: External USB2 HDD affects speed hda

[Mark Lord]

Look at "cat /proc/interrupts" and see if the USB is sharing
an IRQ line with ide0.  If so, then the best explanation I can
see is that the USB driver must have a *really slow* interrupt
handler up to the point where it determines that the interrupt
is not for it.

-ml

Re: External USB2 HDD affects speed hda

[Rene Herman]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

Pavel Machek wrote:

EHCI maintainter (as given by MAINTAINERS) added to CC.

> On Út 31-05-05 01:21:37, Rene Herman wrote:

[ internal IDE HDD slowdown after switching on external USB2 HDD ]

> USB controller generating extra DMA load? Try rmmoding usb to see if
> it goes away.

I was sceptical about this since the drive is idle (or even switched off 
again) but I recompiled EHCI modular and rmmodding ehci_hcd does in fact 
bring back my 50 MB/s:

				: hdparm -t /dev/hda = 50 MB/s
1. modprobe ehci_hcd		: hdparm -t /dev/hda = 50 MB/s
2. switch on USB2 drive		: hdparm -t /dev/hda = 42 MB/s
3. switch off USB drive		: hdparm -t /dev/hda = 42 MB/s
4. modprobe -r ehci_hcd		: hdparm -t /dev/hda = 50 MB/s

There would not seem to be any extra DMA load with a drive that's idle 
or switched off again though? Is the (VIA) USB2 controller playing bus 
monopolizing tricks or something sinister like that? (the speed doesn't 
drop immediately after loading ehci_hcd though, only after switching on 
the USB2 HDD)

More detail --- it's a VIA VT6212L EHCI controller, on unshared IRQ3. 
IDE0 is AMD756 on unshared IRQ14/15. The USB2 HDD does 30 MB/s (after a 
hdparm -a 1024; with the default 256 it's 25MB/s) which I did think was 
a very good speed.

lspci -vv attached, in case it's useful.

Many thanks in advance to anyone for any additional insight...

Rene.


[-- Attachment #2: LSPCI --]
[-- Type: text/plain, Size: 7240 bytes --]

00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] System Controller (rev 25)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 120
	Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M]
	Region 1: Memory at efbff000 (32-bit, prefetchable) [size=4K]
	Region 2: I/O ports at d800 [disabled] [size=4]
	Capabilities: [a0] AGP version 1.0
		Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2
		Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x2

00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] AGP Bridge (rev 01) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 120
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	I/O behind bridge: 0000a000-0000bfff
	Memory behind bridge: efc00000-efcfffff
	Prefetchable memory behind bridge: dfa00000-e7afffff
	BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-

00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-756 [Viper] ISA (rev 01)
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-756 [Viper] IDE (rev 07) (prog-if 8a [Master SecP PriP])
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Region 4: I/O ports at f000 [size=16]

00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-756 [Viper] ACPI (rev 03)
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:08.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01)
	Subsystem: TERRATEC Electronic GmbH: Unknown device 112e
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (1000ns min, 6000ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at efffd000 (32-bit, non-prefetchable) [size=4K]
	Region 1: Memory at efe00000 (32-bit, non-prefetchable) [size=1M]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk+ DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:09.0 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 61) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. VT6202 [USB 2.0 controller]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64, cache line size 08
	Interrupt: pin A routed to IRQ 12
	Region 4: I/O ports at da00 [size=32]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:09.1 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 61) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. VT6202 [USB 2.0 controller]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64, cache line size 08
	Interrupt: pin B routed to IRQ 10
	Region 4: I/O ports at dc00 [size=32]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:09.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) (prog-if 20 [EHCI])
	Subsystem: VIA Technologies, Inc. USB 2.0
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64, cache line size 10
	Interrupt: pin C routed to IRQ 3
	Region 0: Memory at effffe00 (32-bit, non-prefetchable) [size=256]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:09.3 FireWire (IEEE 1394): NEC Corporation: Unknown device 00e7 (rev 01) (prog-if 10 [OHCI])
	Subsystem: NEC Corporation: Unknown device 00ce
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64, cache line size 08
	Interrupt: pin A routed to IRQ 12
	Region 0: Memory at efffe000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0a.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 74)
	Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (2500ns min, 2500ns max), cache line size 08
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at de00 [size=128]
	Region 1: Memory at efffff80 (32-bit, non-prefetchable) [size=128]
	Expansion ROM at effc0000 [disabled] [size=128K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-

01:05.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF/SG AGP (prog-if 00 [VGA])
	Subsystem: ATI Technologies Inc: Unknown device 0048
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (2000ns min), cache line size 08
	Interrupt: pin A routed to IRQ 12
	Region 0: Memory at e0000000 (32-bit, prefetchable) [size=64M]
	Region 1: I/O ports at b800 [size=256]
	Region 2: Memory at efcfc000 (32-bit, non-prefetchable) [size=16K]
	Expansion ROM at efcc0000 [disabled] [size=128K]
	Capabilities: [50] AGP version 2.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2
		Command: RQ=16 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x2
	Capabilities: [5c] Power Management version 1
		Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Re: External USB2 HDD affects speed hda

[Rene Herman]

Mark Lord wrote:

> Look at "cat /proc/interrupts" and see if the USB is sharing
> an IRQ line with ide0.  If so, then the best explanation I can
> see is that the USB driver must have a *really slow* interrupt
> handler up to the point where it determines that the interrupt
> is not for it.

No, that's not it. Both ide0 (14) and EHCI (3) are on private, unshared 
IRQs. rmmodding ehci_hcd as per Pavel's sugestion gets me back my speed. 
Exactly _why_ I've no idea though. I've just added you to the CC on that 
reply...

Rene.

Re: External USB2 HDD affects speed hda

[Petr Vandrovec]

Rene Herman wrote:
> Mark Lord wrote:
> 
>> Look at "cat /proc/interrupts" and see if the USB is sharing
>> an IRQ line with ide0.  If so, then the best explanation I can
>> see is that the USB driver must have a *really slow* interrupt
>> handler up to the point where it determines that the interrupt
>> is not for it.
> 
> 
> No, that's not it. Both ide0 (14) and EHCI (3) are on private, unshared 
> IRQs. rmmodding ehci_hcd as per Pavel's sugestion gets me back my speed. 
> Exactly _why_ I've no idea though. I've just added you to the CC on that 
> reply...

Because EHCI hardware continuously watches some memory area to
find whether there are some transfers from host to your USB
devices ready...  You just need better memory bandwidth so all
your devices transfers fit on your bus.  Or maybe EHCI driver
could program hardware to not query transfer descriptors
that often. But it would increase latency for people
who use USB only and do not care about other parts of system.

						Petr Vandrovec

Re: External USB2 HDD affects speed hda

[David Brownell]

On Wednesday 01 June 2005 11:25 am, Rene Herman wrote:
> Pavel Machek wrote:
> > On Út 31-05-05 01:21:37, Rene Herman wrote:
> 
> [ internal IDE HDD slowdown after switching on external USB2 HDD ]
> 
> > USB controller generating extra DMA load? Try rmmoding usb to see if
> > it goes away.
> 
> I was sceptical about this since the drive is idle (or even switched off 
> again) but I recompiled EHCI modular and rmmodding ehci_hcd does in fact 
> bring back my 50 MB/s:
> 
> 				: hdparm -t /dev/hda = 50 MB/s
> 1. modprobe ehci_hcd		: hdparm -t /dev/hda = 50 MB/s
> 2. switch on USB2 drive	: hdparm -t /dev/hda = 42 MB/s
> 3. switch off USB drive	: hdparm -t /dev/hda = 42 MB/s
> 4. modprobe -r ehci_hcd	: hdparm -t /dev/hda = 50 MB/s

So it's as if the controller remembers that the drive was once turned
on, and then chews up 8+ MB/sec of bus bandwidth somehow until its driver
is removed -- right?  Unplugging the drive (vs just poweroff), same?

One more experiment to try:  with CONFIG_USB_DEBUG, have a look at
the relevant /sys/class/usb_host/usbN/registers file.  Here's what
one looks like on one system:

	bus pci, device 0000:00:02.2 (driver 10 Dec 2004)
	nVidia Corporation nForce2 USB Controller
	EHCI 1.00, hcd state 1
	ownership 01000001 linux
	SMI sts/enable 0xe0080000
	structural params 0x00102486
	capability params 0x0000a086
	status 0008 FLR
	command 010009 (park)=0 ithresh=1 period=256 RUN
	intrenable 37 IAA FATAL PCD ERR INT
	uframe 0e1e
	port 1 status 001000 POWER sig=se0
	port 2 status 001005 POWER sig=se0 PE CONNECT
	port 3 status 001000 POWER sig=se0
	port 4 status 001000 POWER sig=se0
	port 5 status 003802 POWER OWNER sig=j CSC
	port 6 status 001000 POWER sig=se0
	irq normal 28 err 1 reclaim 18 (lost 0)
	complete 29 unlink 0

So there's a USB2 disk on port 2, a full speed device on port 5,
and the controller isn't doing anything much at all ... the RUN
command bit is set, which means it's sending out SOF tokens on
all enabled port(s).  (And it's not suspended, so there's probably
a clock at 48 MHz or so.)  But no transactions are active -- the
"periodic" and "async" schedules are empty, ditto the Periodic
and Async command bits are clear -- so it should be staying away
from PCI, no DMA load at all.

The experiment:  verify that only the RUN bit is set on your
machine too.  If "Periodic" and/or "Async" bits are set, then
the controller is _supposed_ to be issuing DMA transfers over
PCI, so less bandwidth will be available.  Otherwise, not.


> There would not seem to be any extra DMA load with a drive that's idle 
> or switched off again though? Is the (VIA) USB2 controller playing bus 
> monopolizing tricks or something sinister like that? (the speed doesn't 
> drop immediately after loading ehci_hcd though, only after switching on 
> the USB2 HDD)

VIA's EHCI has been more consistently wierd than any other vendor's
implementation.  The VT6202 (initial implementation) has never seemed
to work right.  And although the newer implementations appear to work
OK with the current driver, that's largely due to workarounds that
address some fairly important IRQ dropouts.  I've always suspected
they have strange things going on with their DMA, too; performance
patterns were just too wierd to explain otherwise.


> More detail --- it's a VIA VT6212L EHCI controller, on unshared IRQ3. 
> IDE0 is AMD756 on unshared IRQ14/15. The USB2 HDD does 30 MB/s (after a 
> hdparm -a 1024; with the default 256 it's 25MB/s) which I did think was 
> a very good speed.

The VT6212 never showed me any problems the last time I tested with it,
other than the IRQ lossage I've seen with all VIA EHCI silicon.  And
yes, 30 MB/sec is pretty good; not all disks, or hosts, will do that.

A more hardware-oriented experiment would be to see if a non-VIA card
does the same thing ... most NEC cards won't get you that same data
transfer rate (newer ones might), maybe ALI will.

The most hardware-oriented experiment is to stick a logic analyser on
your PCI bus and see what's up.  Maybe it's not doing DMA, but it's
still arbitrating for the bus or something.  And maybe the AMD PCI is
fighting with the VIA PCI somehow; I seem to recall problems of that
ilk from chips of that era.

- Dave

Re: External USB2 HDD affects speed hda

[Rene Herman]

Petr Vandrovec wrote:

> Rene Herman wrote:

>> No, that's not it. Both ide0 (14) and EHCI (3) are on private, 
>> unshared IRQs. rmmodding ehci_hcd as per Pavel's sugestion gets me 
>> back my speed. Exactly _why_ I've no idea though. I've just added you 
>> to the CC on that reply...
> 
> 
> Because EHCI hardware continuously watches some memory area to
> find whether there are some transfers from host to your USB
> devices ready...  You just need better memory bandwidth so all
> your devices transfers fit on your bus.  Or maybe EHCI driver
> could program hardware to not query transfer descriptors
> that often. But it would increase latency for people
> who use USB only and do not care about other parts of system.

I see. I was totally unaware of that, many thanks for the information. 
Getting more memory bandwidth (to/from the PCI bus at least) will have 
to wait for my next system, I suppose.

Added EHCI maintainer to this one as well. If possible, this looks like 
a good candidate for a /proc or /sys knob?

Or maybe even starting out with a low querying frequency and dynamically 
adjusting it up (and down again!) with traffic? Probably not that. I'd 
like to have the knob though, so that I can have EHCI builtin and still 
tell the controller to take it easy (certainly after I've switched of 
the external HDD again, but on this system possibly also while in use).

Rene.

Re: External USB2 HDD affects speed hda

[David Brownell]

On Wednesday 01 June 2005 12:45 pm, Rene Herman wrote:
> Petr Vandrovec wrote:
> 
> > Rene Herman wrote:
> 
> >> No, that's not it. Both ide0 (14) and EHCI (3) are on private, 
> >> unshared IRQs. rmmodding ehci_hcd as per Pavel's sugestion gets me 
> >> back my speed. Exactly _why_ I've no idea though. I've just added you 
> >> to the CC on that reply...
> > 
> > 
> > Because EHCI hardware continuously watches some memory area to
> > find whether there are some transfers from host to your USB
> > devices ready... 

No it doesn't ... it's not supposed to issue any DMA requests unless
it's been told to do so by activating one of the two transfer schedules
(async or periodic).  The problem Rene is seeing is altoghether more
wierd than that.

So for example USB network drivers do something similar ... they post
a read, and so the EHCI controller will be polling more or less eight
times per millisecond, even if no other USB transfers are active.  It's
never going to be "continuously"; and network drivers are atypical.

But something like usb-storage isn't going to post a request until
it's told to read or write a disk block, which means there'll be no
need for DMA most of the time.  And no DMA activity.

You might be thinking about UHCI, which _will_ do DMA all the time
and has no way to turn off the DMA.  Or even OHCI in certain modes,
where it'll write a frame counter to memory once per millisecond
unless the controller suspended itself.


> > You just need better memory bandwidth so all 
> > your devices transfers fit on your bus.  Or maybe EHCI driver
> > could program hardware to not query transfer descriptors
> > that often. But it would increase latency for people
> > who use USB only and do not care about other parts of system.
> 
> I see. I was totally unaware of that, many thanks for the information. 
> Getting more memory bandwidth (to/from the PCI bus at least) will have 
> to wait for my next system, I suppose.
> 
> Added EHCI maintainer to this one as well. If possible, this looks like 
> a good candidate for a /proc or /sys knob?

No, it's based on a mis-understanding of the hardware.

The controller should only be doing DMA when some driver has submitted
an URB and that URB hasn't yet completed.  Pretty much like any other
hardware, like a disk or network controller.


> Or maybe even starting out with a low querying frequency and dynamically 
> adjusting it up (and down again!) with traffic? Probably not that. I'd 
> like to have the knob though, so that I can have EHCI builtin and still 
> tell the controller to take it easy (certainly after I've switched of 
> the external HDD again, but on this system possibly also while in use).

For periodic transfers -- interrupt, isochronous, neither used for
disk I/O -- the driver issuing the transfer always has control over
the polling period.  But that's mostly related to the USB activity;
if a periodic transfer is active, then the current segment of the
periodic schedule has to be scanned (by DMA) every microframe (8x/msec).
If that segment is empty, that's just one word (32 bits).  If there
are transfers, it's got to read them and maybe perform them.

- Dave



> 
> Rene.
> 

Re: External USB2 HDD affects speed hda

[Rene Herman]

David Brownell wrote:

> On Wednesday 01 June 2005 11:25 am, Rene Herman wrote:

>>				: hdparm -t /dev/hda = 50 MB/s
>>1. modprobe ehci_hcd		: hdparm -t /dev/hda = 50 MB/s
>>2. switch on USB2 drive	: hdparm -t /dev/hda = 42 MB/s
>>3. switch off USB drive	: hdparm -t /dev/hda = 42 MB/s
>>4. modprobe -r ehci_hcd	: hdparm -t /dev/hda = 50 MB/s
> 
> 
> So it's as if the controller remembers that the drive was once turned
> on, and then chews up 8+ MB/sec of bus bandwidth somehow until its driver
> is removed -- right?

Right.

> Unplugging the drive (vs just poweroff), same?

Yes, unplugging does not make a difference.

> One more experiment to try:  with CONFIG_USB_DEBUG, have a look at
> the relevant /sys/class/usb_host/usbN/registers file.

[ snip ]

> The experiment: verify that only the RUN bit is set on your machine
> too. If "Periodic" and/or "Async" bits are set, then the controller
> is _supposed_ to be issuing DMA transfers over PCI, so less bandwidth
> will be available. Otherwise, not.

Thanks for all the explanation. Indeed only the run bit is set here it 
seems. Here are two instances of /sys/class/usb_host/usb1/registers; the 
first one immediately after modprobe ehci_hcd, while hdparm -t /dev/hda 
still gives me 50 MB/s:

===
bus pci, device 0000:00:09.2 (driver 10 Dec 2004)
EHCI 1.00, hcd state 1
structural params 0x00002204
capability params 0x00006872
status 0008 FLR
command 010009 (park)=0 ithresh=1 period=256 RUN
intrenable 37 IAA FATAL PCD ERR INT
uframe 01d4
port 1 status 001000 POWER sig=se0
port 2 status 001000 POWER sig=se0
port 3 status 001000 POWER sig=se0
port 4 status 001000 POWER sig=se0
irq normal 0 err 0 reclaim 0 (lost 0)
complete 0 unlink 0
===

and one after switching on the USB2 HDD, when the hdparm result for hda 
has dropped to 42 MB/s:

===
bus pci, device 0000:00:09.2 (driver 10 Dec 2004)
EHCI 1.00, hcd state 1
structural params 0x00002204
capability params 0x00006872
status a008 Async Recl FLR
command 010009 (park)=0 ithresh=1 period=256 RUN
intrenable 37 IAA FATAL PCD ERR INT
uframe 21cc
port 1 status 001005 POWER sig=se0  PE CONNECT
port 2 status 001000 POWER sig=se0
port 3 status 001000 POWER sig=se0
port 4 status 001000 POWER sig=se0
irq normal 136 err 0 reclaim 17 (lost 0)
complete 27 unlink 0
===

Not much difference between the two but I though I'd post them both in 
case that "reclaim" number means anything to you. In any case, the 
"command" line is the same as the example one you posted so no answers 
there it seems.

> VIA's EHCI has been more consistently wierd than any other vendor's
> implementation.  The VT6202 (initial implementation) has never seemed
> to work right.  And although the newer implementations appear to work
> OK with the current driver, that's largely due to workarounds that
> address some fairly important IRQ dropouts.  I've always suspected
> they have strange things going on with their DMA, too; performance
> patterns were just too wierd to explain otherwise.

"Strange goings on" I can confirm at least. By the way, as seen from the 
above, the USB2 HDD is now on port1. It was on port 3, with a (Iiyama 
monitor) USB 1.1 HUB on port 1, with my mouse connected to that hub. 
After seeing you comment in the other thread that UHCI did always do DMA 
I compiled out UHCI, re-enabled my onboard OHCI controller (I have it 
disabled since I put in this controller since it takes yet another IRQ 
and seems rather superfluous) and plugged the monitor hub into that again.

No change whatsoever unfortunately (but I guess I should keep it this 
way, EHCI and OHCI, no UHCI?)

No change with UHCI _nor_ OHCI loaded either.

The VT6212 is on a combo controller with a unused NEC firewire 
controller, different IRQ. Also no change between ohci1394 loaded or 
unloaded.

Which was to be expected, but hey, I'll try anything by now...

>>More detail --- it's a VIA VT6212L EHCI controller, on unshared IRQ3. 
>>IDE0 is AMD756 on unshared IRQ14/15. The USB2 HDD does 30 MB/s (after a 
>>hdparm -a 1024; with the default 256 it's 25MB/s) which I did think was 
>>a very good speed.
> 
> 
> The VT6212 never showed me any problems the last time I tested with it,
> other than the IRQ lossage I've seen with all VIA EHCI silicon.  And
> yes, 30 MB/sec is pretty good; not all disks, or hosts, will do that.

The disk is a Western Digital Essential 160G.

> A more hardware-oriented experiment would be to see if a non-VIA card
> does the same thing ... most NEC cards won't get you that same data
> transfer rate (newer ones might), maybe ALI will.

Unfortunately I don't have a second controller available to test. Until 
recently I only had the onboard OHCI controller. Bought this one 
together with the drive. Thought I was buying a NEC one by the way; the 
information on the manufacturer's website said so, but when it arrived 
it was a "Rev. B" with the VIA VT6212L. I _really_ hope this is not some 
VIA specific crapola again...

> The most hardware-oriented experiment is to stick a logic analyser on
> your PCI bus and see what's up.  Maybe it's not doing DMA, but it's
> still arbitrating for the bus or something.  And maybe the AMD PCI is
> fighting with the VIA PCI somehow; I seem to recall problems of that
> ilk from chips of that era.

Sound scary. Must say I do generally have a lot of faith in this chipset 
(AMD751/756). The machine's been as stable as a rock for years now. A 
logic analyser I do not have, nor the ability to interpret it if I did.

I did just now try two different PCI slots. Again no change.

Erhhm. rmmoding ehci-hcd works. I suppose it tells the hardware to shut 
up on module_exit. is there any way to have it tell the hardware the 
same while keeping it loaded? Any other ideas?

Thanks,
Rene.

Re: External USB2 HDD affects speed hda

[Rene Herman]

David Brownell wrote:

>>Added EHCI maintainer to this one as well. If possible, this looks like 
>>a good candidate for a /proc or /sys knob?
> 
> 
> No, it's based on a mis-understanding of the hardware.
> 
> The controller should only be doing DMA when some driver has submitted
> an URB and that URB hasn't yet completed.  Pretty much like any other
> hardware, like a disk or network controller.

Okay, thanks, and okay, crap. Sounded like a nice, plausible explanation...

> For periodic transfers -- interrupt, isochronous, neither used for
> disk I/O -- the driver issuing the transfer always has control over
> the polling period.  But that's mostly related to the USB activity;
> if a periodic transfer is active, then the current segment of the
> periodic schedule has to be scanned (by DMA) every microframe (8x/msec).
> If that segment is empty, that's just one word (32 bits).  If there
> are transfers, it's got to read them and maybe perform them.

I see. Well, sort of at least. "Even if the HDD were using periodic 
transfers, which it isn't, it would be DMAing 32-bits 8x per msec while 
idle, which certainly isn't going to cost 8MB/s bus bandwidth". Right?

Rene.

Re: External USB2 HDD affects speed hda

[Rene Herman]

Rene Herman wrote:

> David Brownell wrote:

>> The experiment: verify that only the RUN bit is set on your machine
>> too. If "Periodic" and/or "Async" bits are set, then the controller
>> is _supposed_ to be issuing DMA transfers over PCI, so less bandwidth
>> will be available. Otherwise, not.

[ snip ]

> and one after switching on the USB2 HDD, when the hdparm result for hda 
> has dropped to 42 MB/s:
> 
> ===
> bus pci, device 0000:00:09.2 (driver 10 Dec 2004)
> EHCI 1.00, hcd state 1
> structural params 0x00002204
> capability params 0x00006872
> status a008 Async Recl FLR

Only see that "Async" now while rereading. Did you mean that one? If so, 
I'm right now catting the registers file and that "Async" is toggling on 
and off continuously. 4 cats in a row:

status 0008 FLR
status 8008 Async FLR
status a008 Async Recl FLR
status 0008 FLR

Rene.

Re: External USB2 HDD affects speed hda

[David Brownell]

On Wednesday 01 June 2005 3:24 pm, Rene Herman wrote:

> I see. Well, sort of at least. "Even if the HDD were using periodic 
> transfers, which it isn't, it would be DMAing 32-bits 8x per msec while 
> idle, which certainly isn't going to cost 8MB/s bus bandwidth". Right?

Well, "certainly" is hard to say without the kind of PCI-bus level
logic analyser thing.  Flakey PCI implementations could chew up lots
of bandwidth.  It _should_ not take 8 MB/s bandwidth.  But if it's
chewing up bandwidth, and you're already near the limit in terms
of throughput on that hardware (doesn't need to be at the theoretical
ceiling!) then regular small demands could conceivably chew up more
bandwidth than you'd like.

- Dave

Re: External USB2 HDD affects speed hda

[David Brownell]

On Wednesday 01 June 2005 3:33 pm, Rene Herman wrote:
> Rene Herman wrote:
> 
> > David Brownell wrote:
> 
> >> The experiment: verify that only the RUN bit is set on your machine
> >> too. If "Periodic" and/or "Async" bits are set, then the controller
> >> is _supposed_ to be issuing DMA transfers over PCI, so less bandwidth
> >> will be available. Otherwise, not.
> 
> [ snip ]
> 
> > and one after switching on the USB2 HDD, when the hdparm result for hda 
> > has dropped to 42 MB/s:
> > 
> > ===
> > bus pci, device 0000:00:09.2 (driver 10 Dec 2004)
> > EHCI 1.00, hcd state 1
> > structural params 0x00002204
> > capability params 0x00006872
> > status a008 Async Recl FLR
> 
> Only see that "Async" now while rereading. Did you mean that one? If so, 
> I'm right now catting the registers file and that "Async" is toggling on 
> and off continuously. 4 cats in a row:
> 
> status 0008 FLR
> status 8008 Async FLR
> status a008 Async Recl FLR
> status 0008 FLR

Tbat's strange ... shouldn't do that unless someone's issuing
requests to the bus.  Which shouldn't happen if no devices are
hooked up to that bus.  If the "command" register isn't turning
on async requests, that's particularly strange.

- Dave

Re: External USB2 HDD affects speed hda

[Mikulas Patocka]

On Wed, 1 Jun 2005, David Brownell wrote:

> On Wednesday 01 June 2005 3:33 pm, Rene Herman wrote:
> > Rene Herman wrote:
> >
> > > David Brownell wrote:
> >
> > >> The experiment: verify that only the RUN bit is set on your machine
> > >> too. If "Periodic" and/or "Async" bits are set, then the controller
> > >> is _supposed_ to be issuing DMA transfers over PCI, so less bandwidth
> > >> will be available. Otherwise, not.
> >
> > [ snip ]
> >
> > > and one after switching on the USB2 HDD, when the hdparm result for hda
> > > has dropped to 42 MB/s:
> > >
> > > ===
> > > bus pci, device 0000:00:09.2 (driver 10 Dec 2004)
> > > EHCI 1.00, hcd state 1
> > > structural params 0x00002204
> > > capability params 0x00006872
> > > status a008 Async Recl FLR
> >
> > Only see that "Async" now while rereading. Did you mean that one? If so,
> > I'm right now catting the registers file and that "Async" is toggling on
> > and off continuously. 4 cats in a row:
> >
> > status 0008 FLR
> > status 8008 Async FLR
> > status a008 Async Recl FLR
> > status 0008 FLR
>
> Tbat's strange ... shouldn't do that unless someone's issuing
> requests to the bus.  Which shouldn't happen if no devices are
> hooked up to that bus.  If the "command" register isn't turning
> on async requests, that's particularly strange.
>
> - Dave

Hi

Didn't you just forget to set H-bit in exactly one queue head? If there's
no entry with H-bit set, controller will loop over list of empty heads
again and again.

Mikulas

Re: External USB2 HDD affects speed hda

[David Brownell]

On Wednesday 01 June 2005 6:23 pm, Mikulas Patocka wrote:
> 
> Didn't you just forget to set H-bit in exactly one queue head? If there's
> no entry with H-bit set, controller will loop over list of empty heads
> again and again.

Two things:

 - Why do you ask that?  There's only one QH that _ever_ has that bit set.
   And it's never removed from the async ring.

 - The question should be why the schedule is getting turned on in the
   first place, given there's no work for it to do.

Until I have some time available to actually look at this, all I can do
is answer questions and say "hmm, that's strange" given wierd facts.  The
wierdness here is why that "Async" status bit is ever getting set when
there's no work for it to do.

- Dave
 

Re: External USB2 HDD affects speed hda

[Rene Herman]

Lennart Sorensen wrote:

> I just tried pluging in my usb2 flash reader which ought to d the same
> thing to usb-storage as pluging in the external usb2 hd.
> 
> Reading from a 120G SATA WD drive gets about 41MB/s without the USB2
> drive connected and about the same with.  That is on an nforce2
> motherboard with it's builtin usb controller and using 2.6.10.
> 
> Trying on an Athlon64 with a 250G SATA WD drive and the same usb flash
> reader, I get 57MB/s both with and without the usb2 drive connected.
> That one uses a VIA K8T800 chipset and also 2.6.10.
> 
> I wonder what is different with your hardware/software mix.

Many thanks for trying but our systems really are quite different. I'm 
on an old fashioned north/south-bridge system, where everything does 
compete for bus bandwidth but on newer systems it's all some form of 
"hub architecture" (intel nomenclature) or whatever nVidia calls it. I'm 
not too familiar with it, but I do believe that on that system one 
needn't really expect a misbehaving EHCI controller to have (much?) 
effect on IDE throughput.

Would you be willing to enable CONFIG_USB_DEBUG and then look at 
/sys/class/usb_host/usbN/registers, for usbN your EHCI bus (the second 
line of that file will say EHCI for that one)? Example for me:

bus pci, device 0000:00:09.2 (driver 10 Dec 2004)
EHCI 1.00, hcd state 1
structural params 0x00002204
capability params 0x00006872
status 0008 FLR
command 010009 (park)=0 ithresh=1 period=256 RUN
intrenable 37 IAA FATAL PCD ERR INT
uframe 2dee
port 1 status 001000 POWER sig=se0
port 2 status 001000 POWER sig=se0
port 3 status 001000 POWER sig=se0
port 4 status 001000 POWER sig=se0
irq normal 0 err 0 reclaim 0 (lost 0)
complete 0 unlink 0

When my IDE throughput is normal, the "status" line is always as above, 
but after switching on the USB2 HDD (and even after switching if off 
again and/or unplugging it) "Async" and/or "Recl" start toggling on and 
off (and IDE throughput drops) until I rmmod ehci-hcd. You'd need to 
check the file a few times in a row...

In fact, anyone who could do the same would be much welcome. Certainly 
with the EHCI controller on a PCI card, and even more certainly with a 
VIA VT6212 EHCI controller on a PCI card.

> I tried unloading everything to do with usb to try and see if I could
> make it get a higher speed with hdparm, but no change no matter what.

Your 41MB/s for the SATA disk on nForce2 does seem a bit low. The 50 
here is with a PATA Maxtor 120G on a UDMA66 controller. I just checked 
and I see that with current kernels hdparm -a hasn't as much influence 
as it used to have on the hdparm -t result, but try after a "hdparm -a N 
/dev/sda" (sda for SATA, right?) for at least N = 256, 512, 1024, 2048 
and 4096...

Rene.

Re: External USB2 HDD affects speed hda

[Rene Herman]

David Brownell wrote:

> On Wednesday 01 June 2005 6:23 pm, Mikulas Patocka wrote:
> 
>>Didn't you just forget to set H-bit in exactly one queue head? If there's
>>no entry with H-bit set, controller will loop over list of empty heads
>>again and again.
> 
> 
> Two things:
> 
>  - Why do you ask that?  There's only one QH that _ever_ has that bit set.
>    And it's never removed from the async ring.
> 
>  - The question should be why the schedule is getting turned on in the
>    first place, given there's no work for it to do.
> 
> Until I have some time available to actually look at this, all I can do
> is answer questions and say "hmm, that's strange" given wierd facts.  The
> wierdness here is why that "Async" status bit is ever getting set when
> there's no work for it to do.

I'll be available for testing...

One more data point: I just checked 2.4.31 and it behaves the same.

I also tried checking Windows (98SE) but that may not have been too 
useful. It shows no difference in disk throughput with or without the 
USB2 HDD switched on, but it's only giving me 28 MB/s anyway (on C:, 
which is a 4G VFAT partition right at the end of the disk; the slowest 
part) which might not be enough to notice a misbehaving EHCI controller. 
Also tried giving it a D: partition at the start of the disk, but the 
blasted thing only gave me 16 MB/s there...

Rene.

Re: External USB2 HDD affects speed hda

[Lennart Sorensen]

On Thu, Jun 02, 2005 at 12:14:16AM +0200, Rene Herman wrote:
> Sound scary. Must say I do generally have a lot of faith in this chipset 
> (AMD751/756). The machine's been as stable as a rock for years now. A 
> logic analyser I do not have, nor the ability to interpret it if I did.
> 
> I did just now try two different PCI slots. Again no change.
> 
> Erhhm. rmmoding ehci-hcd works. I suppose it tells the hardware to shut 
> up on module_exit. is there any way to have it tell the hardware the 
> same while keeping it loaded? Any other ideas?

I just tried pluging in my usb2 flash reader which ought to d the same
thing to usb-storage as pluging in the external usb2 hd.

Reading from a 120G SATA WD drive gets about 41MB/s without the USB2
drive connected and about the same with.  That is on an nforce2
motherboard with it's builtin usb controller and using 2.6.10.

Trying on an Athlon64 with a 250G SATA WD drive and the same usb flash
reader, I get 57MB/s both with and without the usb2 drive connected.
That one uses a VIA K8T800 chipset and also 2.6.10.

I wonder what is different with your hardware/software mix.

I tried unloading everything to do with usb to try and see if I could
make it get a higher speed with hdparm, but no change no matter what.

Len Sorensen

Re: External USB2 HDD affects speed hda

[Lennart Sorensen]

On Thu, Jun 02, 2005 at 03:11:12PM +0200, Rene Herman wrote:
> Many thanks for trying but our systems really are quite different. I'm 
> on an old fashioned north/south-bridge system, where everything does 
> compete for bus bandwidth but on newer systems it's all some form of 
> "hub architecture" (intel nomenclature) or whatever nVidia calls it. I'm 
> not too familiar with it, but I do believe that on that system one 
> needn't really expect a misbehaving EHCI controller to have (much?) 
> effect on IDE throughput.
> 
> Would you be willing to enable CONFIG_USB_DEBUG and then look at 
> /sys/class/usb_host/usbN/registers, for usbN your EHCI bus (the second 
> line of that file will say EHCI for that one)? Example for me:

I will try and do that when I get a chance.  I can also try it on a
machine with an add in ehci card (Via KT133 chipset + NEC ehci card).

> bus pci, device 0000:00:09.2 (driver 10 Dec 2004)
> EHCI 1.00, hcd state 1
> structural params 0x00002204
> capability params 0x00006872
> status 0008 FLR
> command 010009 (park)=0 ithresh=1 period=256 RUN
> intrenable 37 IAA FATAL PCD ERR INT
> uframe 2dee
> port 1 status 001000 POWER sig=se0
> port 2 status 001000 POWER sig=se0
> port 3 status 001000 POWER sig=se0
> port 4 status 001000 POWER sig=se0
> irq normal 0 err 0 reclaim 0 (lost 0)
> complete 0 unlink 0
> 
> When my IDE throughput is normal, the "status" line is always as above, 
> but after switching on the USB2 HDD (and even after switching if off 
> again and/or unplugging it) "Async" and/or "Recl" start toggling on and 
> off (and IDE throughput drops) until I rmmod ehci-hcd. You'd need to 
> check the file a few times in a row...
> 
> In fact, anyone who could do the same would be much welcome. Certainly 
> with the EHCI controller on a PCI card, and even more certainly with a 
> VIA VT6212 EHCI controller on a PCI card.

> Your 41MB/s for the SATA disk on nForce2 does seem a bit low. The 50 
> here is with a PATA Maxtor 120G on a UDMA66 controller. I just checked 
> and I see that with current kernels hdparm -a hasn't as much influence 
> as it used to have on the hdparm -t result, but try after a "hdparm -a N 
> /dev/sda" (sda for SATA, right?) for at least N = 256, 512, 1024, 2048 
> and 4096...

Well the SATA is using an Sil3112A controller.  Not sure how fast they
are.

The system also isn't entirely idle, so who knows what might affect the
speed.  I only get 30M/s at the moment on the same type of WD 120G SATA
drive on an ICH5R chipset, although I am pretty sure I have got more
than that when it was idle before.

Len Sorensen

Re: External USB2 HDD affects speed hda

[Grant Coady]

On Thu, 02 Jun 2005 15:11:12 +0200, Rene Herman <rene.herman@keyaccess.nl> wrote:
>
>In fact, anyone who could do the same would be much welcome. Certainly 
>with the EHCI controller on a PCI card, and even more certainly with a 
>VIA VT6212 EHCI controller on a PCI card.

Not quite what you asked, following is with 6GB laptop HDD in USB 
enclosure on /dev/sdb, main drive is Seagate SATA /dev/sda. 
More hardware info on http://scatter.mine.nu/test/boxen/sempro/ 
 includes an lspci -v, mobo, CPU, HDD info

nVidia driver not loaded, box running headless to ssh terminal.
USB optical mouse only other device plugged in
USB drive plugged in prior to reboot both times

Summary: interrupts being lost on latest?  No HDD slowdown. 
 All USB ports use IRQ18, SATA on IRQ17

More info on request.

--Grant.

stable then latest:

2.6.11.11: after many runs, plus hardware info:

root@sempro:~# cat /sys/class/usb_host/usb1/registers
bus pci, device 0000:00:10.4 (driver 10 Dec 2004)
EHCI 1.00, hcd state 1
structural params 0x00004208
capability params 0x00006872
status a008 Async Recl FLR
command 010009 (park)=0 ithresh=1 period=256 RUN
intrenable 37 IAA FATAL PCD ERR INT
uframe 02c2
port 1 status 003402 POWER OWNER sig=k  CSC
port 2 status 001000 POWER sig=se0
port 3 status 001000 POWER sig=se0
port 4 status 001000 POWER sig=se0
port 5 status 001005 POWER sig=se0  PE CONNECT
port 6 status 001000 POWER sig=se0
port 7 status 001000 POWER sig=se0
port 8 status 001000 POWER sig=se0
irq normal 5470 err 0 reclaim 3645 (lost 0)
complete 5904 unlink 0
root@sempro:~# hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   1160 MB in  2.01 seconds = 578.35 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
 Timing buffered disk reads:  170 MB in  3.01 seconds =  56.51 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
root@sempro:~# hdparm -Tt /dev/sdb

/dev/sdb:
 Timing cached reads:   1172 MB in  2.00 seconds = 584.63 MB/sec
 Timing buffered disk reads:   26 MB in  3.17 seconds =   8.21 MB/sec

root@sempro:~# lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8378 [KM400/A] Chipset Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78)
01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev a2)

root@sempro:~# lsmod
Module                  Size  Used by
w83627hf               28456  0
i2c_sensor              2944  1 w83627hf
usb_storage            41024  0
via_agp                 7552  1
agpgart                28456  1 via_agp
ide_floppy             16704  0
root@sempro:~#

2.6.12-rc5-mm2a third run

/dev/sda:
 Timing cached reads:   1096 MB in  2.00 seconds = 546.87 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
 Timing buffered disk reads:  172 MB in  3.03 seconds =  56.72 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
root@sempro:~# hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads:   1224 MB in  2.00 seconds = 610.74 MB/sec
 Timing buffered disk reads:   26 MB in  3.16 seconds =   8.23 MB/sec
root@sempro:~# cat /sys/class/usb_host/usb1/registers
bus pci, device 0000:00:10.4 (driver 10 Dec 2004)
VIA Technologies, Inc. USB 2.0
EHCI 1.00, hcd state 1
ownership 01000001 linux
SMI sts/enable 0xe0080000
structural params 0x00004208
capability params 0x00006872
status 0008 FLR
command 010009 (park)=0 ithresh=1 period=256 RUN
intrenable 37 IAA FATAL PCD ERR INT
uframe 2365
port 1 status 003402 POWER OWNER sig=k CSC
port 2 status 001000 POWER sig=se0
port 3 status 001000 POWER sig=se0
port 4 status 001000 POWER sig=se0
port 5 status 001005 POWER sig=se0 PE CONNECT
port 6 status 001000 POWER sig=se0
port 7 status 001000 POWER sig=se0
port 8 status 001000 POWER sig=se0
irq normal 8184 err 0 reclaim 5387 (lost 82)
complete 8785 unlink 0
root@sempro:~# uname -a
Linux sempro 2.6.12-rc5-mm2a #5 Fri Jun 3 08:14:01 EST 2005 i686 unknown unknown GNU/Linux
root@sempro:~# cat /proc/interrupts
           CPU0
  0:     242764    IO-APIC-edge  timer
  1:         20    IO-APIC-edge  i8042
  8:          1    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 14:         13    IO-APIC-edge  ide0
 15:         68    IO-APIC-edge  ide1
 16:        744   IO-APIC-level  eth0
 17:       7441   IO-APIC-level  libata
 18:      13314   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4, uhci_hcd:usb5
 19:          0   IO-APIC-level  VIA8237
NMI:          0
LOC:     242657
ERR:          0
MIS:          0

#end :o)

Re: External USB2 HDD affects speed hda

[Rene Herman]

Grant Coady wrote:

> On Thu, 02 Jun 2005 15:11:12 +0200, Rene Herman <rene.herman@keyaccess.nl> wrote:
> 
>>In fact, anyone who could do the same would be much welcome. Certainly 
>>with the EHCI controller on a PCI card, and even more certainly with a 
>>VIA VT6212 EHCI controller on a PCI card.
> 
> 
> Not quite what you asked, following is with 6GB laptop HDD in USB 
> enclosure on /dev/sdb, main drive is Seagate SATA /dev/sda. 
> More hardware info on http://scatter.mine.nu/test/boxen/sempro/ 
>  includes an lspci -v, mobo, CPU, HDD info
> 
> nVidia driver not loaded, box running headless to ssh terminal.
> USB optical mouse only other device plugged in
> USB drive plugged in prior to reboot both times

Okay, great, thanks...

> 2.6.11.11: after many runs, plus hardware info:
> 
> root@sempro:~# cat /sys/class/usb_host/usb1/registers
> bus pci, device 0000:00:10.4 (driver 10 Dec 2004)
> EHCI 1.00, hcd state 1
> structural params 0x00004208
> capability params 0x00006872
> status a008 Async Recl FLR
> command 010009 (park)=0 ithresh=1 period=256 RUN

David, did I understand correctly that the Async status bit should not 
be set without the Async command bit, period? Or was that just in my 
case, with everything idle/off/disconnected?

If first, then I'm happy that it's not just me ...

> 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)

... although maybe still just VIA.

> 2.6.12-rc5-mm2a third run

[ snip, no Async or Recl status bit ]

> irq normal 8184 err 0 reclaim 5387 (lost 82)

No idea about those. Not seeing lost interrupts here, even after 
generating quite some traffic.

Rene.

Re: External USB2 HDD affects speed hda

[David Brownell]

On Thursday 02 June 2005 4:56 pm, Rene Herman wrote:
> Grant Coady wrote:
> 
> > root@sempro:~# cat /sys/class/usb_host/usb1/registers
> > bus pci, device 0000:00:10.4 (driver 10 Dec 2004)
> > EHCI 1.00, hcd state 1
> > structural params 0x00004208
> > capability params 0x00006872
> > status a008 Async Recl FLR
> > command 010009 (park)=0 ithresh=1 period=256 RUN
> 
> David, did I understand correctly that the Async status bit should not 
> be set without the Async command bit, period? Or was that just in my 
> case, with everything idle/off/disconnected?

It's like this:  turn on the command bit, then after a while the status
bit changes and shows the command took effect.  Turn off the command bit,
ditto.  And if everything is idle/disconnected, nothing should be
turning the bit on ... both bits should stay off at all times.

The driver needs to avoid doing certain things while the chip is in
the middle of activating or de-activating one of the schedules, so
it checks to see whether the bits agree.  If they disagree, the chip
hasn't finished the last enable/disable command.


> If first, then I'm happy that it's not just me ...
> 
> > 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
> 
> ... although maybe still just VIA.

Maybe.  Thing is, normally it should take just no more than a
millisecond or two for the command to take effect.  So the fact
that either of you can consistently see something happening there
is pretty strange.  Something would seem to be turning the async
schedule on/off a lot.  The driver isn't _supposed_ to do that.
But then, neither is the chip (without the driver telling it to
do so) ... something's being annoying there.


> 
> > 2.6.12-rc5-mm2a third run
> 
> [ snip, no Async or Recl status bit ]
> 
> > irq normal 8184 err 0 reclaim 5387 (lost 82)
> 
> No idea about those. Not seeing lost interrupts here, even after 
> generating quite some traffic.

The "lost" interrupts are cases where the VIA hardware (it's never
been seen by me on any other hardware) is supposed to issue an IRQ
as part of the reclaim process, but doesn't.  

- Dave

Re: External USB2 HDD affects speed hda

[Rene Herman]

Rene Herman wrote:

> David Brownell wrote:

>> Until I have some time available to actually look at this, all I can do
>> is answer questions and say "hmm, that's strange" given wierd facts.  The
>> wierdness here is why that "Async" status bit is ever getting set when
>> there's no work for it to do.
> 
> I'll be available for testing...
> 
> One more data point: I just checked 2.4.31 and it behaves the same.

Hi David. Has there been any progress on this issue?

(thread at http://marc.theaimsgroup.com/?t=111749614000002&r=1&w=2)

Rene.

Re: External USB2 HDD affects speed hda

[David Brownell]

> Hi David. Has there been any progress on this issue?
>
> (thread at http://marc.theaimsgroup.com/?t=111749614000002&r=1&w=2)

Taking a look at that, I found one case that _might_ explain it.  That
scenario could crop more (or less) based on loads and timings, and I've
suspected that the VIA chips have significantly different timings for
certain things.  This patch handles that case differently, just expecting
the unlink completion code (later) to restart the schedule.

I sanity tested this, but that's all.

- Dave

--- g26.orig/drivers/usb/host/ehci-q.c	2005-09-12 17:58:21.000000000 -0700
+++ g26/drivers/usb/host/ehci-q.c	2005-09-14 10:26:07.000000000 -0700
@@ -781,7 +781,7 @@ static void qh_link_async (struct ehci_h
 	/* (re)start the async schedule? */
 	head = ehci->async;
 	timer_action_done (ehci, TIMER_ASYNC_OFF);
-	if (!head->qh_next.qh) {
+	if (!head->qh_next.qh && !ehci->reclaim) {
 		u32	cmd = readl (&ehci->regs->command);
 
 		if (!(cmd & CMD_ASE)) {

Re: External USB2 HDD affects speed hda

[Rene Herman]

David Brownell wrote:

>>Hi David. Has there been any progress on this issue?
>>
>>(thread at http://marc.theaimsgroup.com/?t=111749614000002&r=1&w=2)
> 
> 
> Taking a look at that, I found one case that _might_ explain it.  That
> scenario could crop more (or less) based on loads and timings, and I've
> suspected that the VIA chips have significantly different timings for
> certain things.  This patch handles that case differently, just expecting
> the unlink completion code (later) to restart the schedule.
> 
> I sanity tested this, but that's all.

[ snip ]

> -	if (!head->qh_next.qh) {
> +	if (!head->qh_next.qh && !ehci->reclaim) {

Thanks, but unfortunately no change. That is, still have that "Async" 
status flag toggling on and off in /sys/class/usb_host/usb?/registers 
(and the ~ 8MB/s drop in IDE throughput).

Rene.

Re: External USB2 HDD affects speed hda

[Rene Herman]

Rene Herman wrote:

(thread at http://marc.theaimsgroup.com/?t=111749614000002&r=1&w=2)

> David Brownell wrote:

>> -    if (!head->qh_next.qh) {
>> +    if (!head->qh_next.qh && !ehci->reclaim) {
> 
> 
> Thanks, but unfortunately no change. That is, still have that "Async" 
> status flag toggling on and off in /sys/class/usb_host/usb?/registers 
> (and the ~ 8MB/s drop in IDE throughput).

Maybe useful informateion: no problems when the disk is accessed through 
uhci-hcd at the same port. Only using it through ehci-hcd triggers the 
problem ("async" status flag toggling on/off, drop in IDE throughput).

Rene.

Re: External USB2 HDD affects speed hda

[Helmut Toplitzer]

Hi!

I stumbled into a quite simmilar problem as Rene Herman. 
So he asked me to mail to you. Here a short intro:

My VIA USB driver using EHCI is disconnecting my video
encoder device (Hauppauge PVRUSB2) after working for
about 10 minutes.

Details (including usb-debug output, lspci, lsusb, lsmdo) can be found at:
http://marc.theaimsgroup.com/?l=linux-usb-users&m=113508572205777&w=2

Any suggestions what to test/to do?

TIA
Helmut

-- 
My GNUpg fingerprint http://www.gnupg.org
4563 F4FB 0B7E 8698 53CD  00E9 E319 35BD 6A91 1656

Re: External USB2 HDD affects speed hda

[Rene Herman]

Helmut Toplitzer wrote:

> I stumbled into a quite simmilar problem as Rene Herman. 
> So he asked me to mail to you. Here a short intro:
> 
> My VIA USB driver using EHCI is disconnecting my video
> encoder device (Hauppauge PVRUSB2) after working for
> about 10 minutes.
> 
> Details (including usb-debug output, lspci, lsusb, lsmdo) can be found at:
> http://marc.theaimsgroup.com/?l=linux-usb-users&m=113508572205777&w=2
> 
> Any suggestions what to test/to do?

Just to make it clear -- the striking similarity is that he also has the 
IDE throughput drop; 34MB/s to 15MB/s in his case. No idea if his async 
schedule should be turning on and off with the USB PVR, but it seems 
very likely the same problem...

(hope I don't break the thread; replying through the gmane news gateway)

Rene.