Bug 4744

Summary:	usb storage errors with amd64 frequency scaling
Product:	Power Management	Reporter:	Pawel Golik (pgolik)
Component:	cpufreq	Assignee:	cpufreq (cpufreq)
Status:	CLOSED UNREPRODUCIBLE
Severity:	normal	CC:	greg, kernel, lenb
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.11, 2.6.12_rc6	Subsystem:
Regression:	No	Bisected commit-id:

Description Pawel Golik 2005-06-14 02:03:01 UTC

Distribution:Gentoo 2005.0  
Hardware Environment:VIA K8T800 motherboard (Gigabyte); Athlon64 3000+ s754;   
Kingston  DataTraveler 2.0 Pendrive  
Software Environment:bash  
Problem Description:  
With the CPU frequency reduced by the kernel ondemand scaler usb storage  
devices (a Kingston Pendrive) are not recognized properly - the error in the  
system log is as follows:  
  
ehci_hcd 0000:00:10.4: port 2 reset error -110  
hub 1-0:1.0: hub_port_status failed (err = -32)  
  
With the cpu at full frequency the device gets recognized correctly:  
  
usb 2-2: new full speed USB device using uhci_hcd and address 7  
scsi9 : SCSI emulation for USB Mass Storage devices  
usb-storage: device found at 7  
usb-storage: waiting for device to settle before scanning  
  Vendor: Kingston  Model: DataTraveler 2.0  Rev: 4.10  
  Type:   Direct-Access                      ANSI SCSI revision: 02  
SCSI device sdd: 503808 512-byte hdwr sectors (258 MB)  
sdd: assuming Write Enabled  
sdd: assuming drive cache: write through  
SCSI device sdd: 503808 512-byte hdwr sectors (258 MB)  
sdd: assuming Write Enabled  
sdd: assuming drive cache: write through  
 /dev/scsi/host9/bus0/target0/lun0: p1  
Attached scsi removable disk sdd at scsi9, channel 0, id 0, lun 0  
Attached scsi generic sg3 at scsi9, channel 0, id 0, lun 0,  type 0  
usb-storage: device scan complete  
  
This is an USB1.1 device, it appears that with cpufreq lowered it tries to  
connect it through EHCI and fails, while on full speed it gets though with  
UHCI.  
  
With the cpu at the lowest frequency, when I   
plug in the USB pendrive for the first time, I get the error above. When I   
unplug it and plug in again, it gets recognized correctly. Now when I unplug   
and plug again it fails, on the fourth attempt it works and so on. So it gets   
recognized correctly every other time - error on attempt 1, 3, 5 etc.; works on   
attempt 2, 4, 6 etc.; with each attempt being simply plugging the pendrive in   
and checking the dmesg output.  
 
Relevant portions of .config: 
CONFIG_X86_64=y 
CONFIG_64BIT=y 
CONFIG_X86=y 
CONFIG_MMU=y 
CONFIG_RWSEM_GENERIC_SPINLOCK=y 
CONFIG_GENERIC_CALIBRATE_DELAY=y 
CONFIG_X86_CMPXCHG=y 
CONFIG_EARLY_PRINTK=y 
CONFIG_HPET_TIMER=y 
CONFIG_HPET_EMULATE_RTC=y 
CONFIG_GENERIC_ISA_DMA=y 
CONFIG_GENERIC_IOMAP=y 
CONFIG_MK8=y 
CONFIG_X86_MSR=y 
CONFIG_X86_CPUID=y 
CONFIG_X86_IO_APIC=y 
CONFIG_X86_LOCAL_APIC=y 
CONFIG_MTRR=y 
# CONFIG_SMP is not set 
# CONFIG_PREEMPT is not set 
# CONFIG_NUMA is not set 
# CONFIG_GART_IOMMU is not set 
CONFIG_DUMMY_IOMMU=y 
CONFIG_X86_MCE=y 
CONFIG_PM=y 
# CONFIG_PM_DEBUG is not set 
# CONFIG_SOFTWARE_SUSPEND is not set 
 
# 
# ACPI (Advanced Configuration and Power Interface) Support 
# 
CONFIG_ACPI=y 
CONFIG_ACPI_BOOT=y 
CONFIG_ACPI_INTERPRETER=y 
CONFIG_ACPI_SLEEP=y 
CONFIG_ACPI_SLEEP_PROC_FS=y 
CONFIG_CPU_FREQ=y 
# CONFIG_CPU_FREQ_DEBUG is not set 
CONFIG_CPU_FREQ_STAT=y 
CONFIG_CPU_FREQ_STAT_DETAILS=y 
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y 
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set 
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y 
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set 
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set 
CONFIG_CPU_FREQ_GOV_ONDEMAND=y 
CCONFIG_X86_POWERNOW_K8=y 
CONFIG_X86_POWERNOW_K8_ACPI=y 
ONFIG_CPU_FREQ_TABLE=y 
CONFIG_USB=y 
CONFIG_USB_ARCH_HAS_HCD=y 
CONFIG_USB_ARCH_HAS_OHCI=y 
CONFIG_USB_EHCI_HCD=y 
# CONFIG_USB_EHCI_SPLIT_ISO is not set 
CONFIG_USB_EHCI_ROOT_HUB_TT=y 
# CONFIG_USB_OHCI_HCD is not set 
CONFIG_USB_UHCI_HCD=y 
# CONFIG_USB_SL811_HCD is not set 
CONFIG_USB_STORAGE=m 
 
 
 
 
Steps to reproduce:  
When the CPU runs at minimum frequency 1000MHz plug the Pendrive into the USB  
port. See dmesg output (error).  
Unplug and plug again - device recognized.  
Unplug and plug again - error  
etc.

Comment 1 Thien Nguyen 2005-06-14 11:03:14 UTC

Distribution:Gentoo 2005.0  
Hardware Environment:nvidia nForce4 motherboard (Gigabyte); Athlon64 3000+ s939;   
USB external hard drive

USB 2 device gets ehci_hcd errors when cpu is not at full frequency.  Upon
unloading ehci_hcd module the computer immediately detects the drive and works
normally except at USB 1.1 speeds.  No reconnect of device required.

Comment 2 Pawel Golik 2005-06-14 12:54:40 UTC

Interesting, at home I have an nForce3 system, and USB storage works perfectly, 
even with frequency at the lowest. I thought it was VIA-specific. Are you using  
ohci_hcd on the nForce for USB1.1? (My VIA uses uhci_hcd).

Comment 3 Dan Laba 2005-06-14 16:58:14 UTC

"additional comment #1" confirmed on a nforce3 motherboard  
  
Power problem:  
could it be a problem with the computer, like not giving enough power for USB2  
ports at low frequency?  
  
Timing problem:  
could it be that when the computer boots it is at the high speed, it  
calculates jiffies, and then when it is at low frequency and it wants to delay  
a while it has a different frequency and it doesn't wait enough for the device  
to be recognized?  
  
ohci_hcd always works for my USB2 device but is painfully slow.

Comment 4 Pawel Golik 2005-06-16 13:34:37 UTC

Obvoiusly this happens on some hardware and not on another, and is not simply 
tied to one particular chipset.  
USB devices that are present at boot are not affected, the kernel doesn't begin 
to scale down frequency until it is told so, either by issuing  
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 
or by an userspace daemon. 
An USB 2 device I tried (a card reader) works every time. I have experienced 
this problem only with USB storage devices.

Comment 5 Daniel Drake 2005-09-17 09:59:58 UTC

Downstream bug report: http://bugs.gentoo.org/show_bug.cgi?id=94496

Comment 6 Markus Rechberger 2007-02-08 04:29:15 UTC

does this problem still exist with the latest 2.6.20 kernel?

Markus

Comment 7 Pawel Golik 2007-02-08 06:10:08 UTC

No problem since 2.6.19 for me.