[BUG] 2.6.24-git usb reset problems

[BUG] 2.6.24-git usb reset problems

[Jens Axboe]

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

Hi,

Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and
connecting my cf usb storage device yields and endless stream of:

Initializing USB Mass Storage driver...
scsi6 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
scsi 6:0:0:0: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
ANSI: 0
sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
sd 6:0:0:0: [sdb] Write Protect is off
sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
sd 6:0:0:0: [sdb] Assuming drive cache: write through
sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
sd 6:0:0:0: [sdb] Write Protect is off
sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
sd 6:0:0:0: [sdb] Assuming drive cache: write through
 sdb: sdb1
sd 6:0:0:0: [sdb] Attached SCSI removable disk
sd 6:0:0:0: Attached scsi generic sg1 type 0
scsi 6:0:0:1: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
ANSI: 0
usb 5-1: reset high speed USB device using ehci_hcd and address 2
usb 5-1: reset high speed USB device using ehci_hcd and address 2
usb 5-1: reset high speed USB device using ehci_hcd and address 2
usb 5-1: reset high speed USB device using ehci_hcd and address 2
usb 5-1: reset high speed USB device using ehci_hcd and address 2
usb 5-1: reset high speed USB device using ehci_hcd and address 2
usb 5-1: reset high speed USB device using ehci_hcd and address 2
[...]

until I disconnect it. The device doesn't work. Worked fine in 2.6.24.
I'm attaching boot messages and my .config.

-- 
Jens Axboe


[-- Attachment #2: boot.msg --]
[-- Type: text/plain, Size: 21258 bytes --]

Linux version 2.6.24 (axboe@carl) (gcc version 4.2.1 (SUSE Linux)) #72 SMP Mon Jan 28 14:14:38 CET 2008
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
 BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000007f6d0000 (usable)
 BIOS-e820: 000000007f6d0000 - 000000007f6df000 (ACPI data)
 BIOS-e820: 000000007f6df000 - 000000007f700000 (ACPI NVS)
 BIOS-e820: 000000007f700000 - 0000000080000000 (reserved)
 BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
 BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
 BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
 BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)
2038MB LOWMEM available.
found SMP MP-table at 000f67f0
Entering add_active_range(0, 0, 521936) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   521936
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->   521936
On node 0 totalpages: 521936
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 4045 pages used for memmap
  Normal zone: 513795 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
DMI present.
ACPI: RSDP 000F67C0, 0024 (r2 LENOVO)
ACPI: XSDT 7F6D191C, 0084 (r1 LENOVO TP-7B        2140  LTP        0)
ACPI: FACP 7F6D1A00, 00F4 (r3 LENOVO TP-7B        2140 LNVO        1)
ACPI Warning (tbfadt-0442): Optional field "Gpe1Block" has zero address or length: 000000000000102C/0 [20070126]
ACPI: DSDT 7F6D1D90, CFB9 (r1 LENOVO TP-7B        2140 MSFT  100000E)
ACPI: FACS 7F6F4000, 0040
ACPI: SSDT 7F6D1BB4, 01DC (r1 LENOVO TP-7B        2140 MSFT  100000E)
ACPI: ECDT 7F6DED49, 0052 (r1 LENOVO TP-7B        2140 LNVO        1)
ACPI: TCPA 7F6DED9B, 0032 (r2 LENOVO TP-7B        2140 LNVO        1)
ACPI: APIC 7F6DEDCD, 0068 (r1 LENOVO TP-7B        2140 LNVO        1)
ACPI: MCFG 7F6DEE35, 003C (r1 LENOVO TP-7B        2140 LNVO        1)
ACPI: HPET 7F6DEE71, 0038 (r1 LENOVO TP-7B        2140 LNVO        1)
ACPI: BOOT 7F6DEFD8, 0028 (r1 LENOVO TP-7B        2140  LTP        1)
ACPI: SSDT 7F6F2645, 025F (r1 LENOVO TP-7B        2140 INTL 20050513)
ACPI: SSDT 7F6F28A4, 00A6 (r1 LENOVO TP-7B        2140 INTL 20050513)
ACPI: SSDT 7F6F294A, 04F7 (r1 LENOVO TP-7B        2140 INTL 20050513)
ACPI: SSDT 7F6F2E41, 01D8 (r1 LENOVO TP-7B        2140 INTL 20050513)
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:14 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 6:14 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
ACPI: HPET id: 0x8086a201 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 88000000 (gap: 80000000:70000000)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 517859
Kernel command line: root=/dev/sda2 vga=ext resume=/dev/sda5 acpi_sleep=s3_bios
mapped APIC to ffffb000 (fee00000)
mapped IOAPIC to ffffa000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=7840c000 soft=7840a000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Detected 1828.775 MHz processor.
Console: colour VGA+ 80x50
console [tty0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:    8
... MAX_LOCK_DEPTH:          30
... MAX_LOCKDEP_KEYS:        2048
... CLASSHASH_SIZE:           1024
... MAX_LOCKDEP_ENTRIES:     8192
... MAX_LOCKDEP_CHAINS:      16384
... CHAINHASH_SIZE:          8192
 memory used by lock dependency info: 992 kB
 per task-struct memory footprint: 1200 bytes
Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
Memory: 2057604k/2087744k available (1922k kernel code, 29480k reserved, 951k data, 208k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffb4000 - 0xfffff000   ( 300 kB)
    vmalloc : 0xf8000000 - 0xfffb2000   ( 127 MB)
    lowmem  : 0x78000000 - 0xf76d0000   (2038 MB)
      .init : 0x783d3000 - 0x78407000   ( 208 kB)
      .data : 0x782e0941 - 0x783ce694   ( 951 kB)
      .text : 0x78100000 - 0x782e0941   (1922 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
hpet clockevent registered
Calibrating delay using timer specific routine.. 3663.03 BogoMIPS (lpj=1831518)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfe9fbff 00100000 00000000 00000000 0000c1a9 00000000 00000000 00000000
monitor/mwait feature present.
using mwait in idle threads.
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU: After all inits, caps: bfe9fbff 00100000 00000000 00002940 0000c1a9 00000000 00000000 00000000
Compat vDSO mapped to ffffe000.
Checking 'hlt' instruction... OK.
lockdep: not fixing up alternatives.
ACPI: Core revision 20070126
CPU0: Intel Genuine Intel(R) CPU           T2400  @ 1.83GHz stepping 08
lockdep: not fixing up alternatives.
Booting processor 1/1 eip 3000
CPU 1 irqstacks, hard=7840d000 soft=7840b000
Initializing CPU#1
Calibrating delay using timer specific routine.. 3657.61 BogoMIPS (lpj=1828806)
CPU: After generic identify, caps: bfe9fbff 00100000 00000000 00000000 0000c1a9 00000000 00000000 00000000
monitor/mwait feature present.
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU: After all inits, caps: bfe9fbff 00100000 00000000 00002940 0000c1a9 00000000 00000000 00000000
CPU1: Intel Genuine Intel(R) CPU           T2400  @ 1.83GHz stepping 08
Total of 2 processors activated (7320.64 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization [CPU#0 -> CPU#1]:
Measured 579029 cycles TSC warp between CPUs, turning off TSC clock.
Marking TSC unstable due to: check_tsc_sync_source failed.
Brought up 2 CPUs
CPU0 attaching sched-domain:
 domain 0: span 3
  groups: 1 2
CPU1 attaching sched-domain:
 domain 0: span 3
  groups: 2 1
net_namespace: 76 bytes
Booting paravirtualized kernel on bare hardware
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using MMCONFIG
Setting up standard PCI resources
ACPI: EC: EC description table is found, configuring boot EC
ACPI: EC: non-query interrupt received, switching to interrupt mode
ACPI: Interpreter enabled
ACPI: (supports S0 S3 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: EC: GPE = 0x1c, I/O: command/status = 0x66, data = 0x62
ACPI: EC: driver started in poll mode
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
PCI quirk: region 1180-11bf claimed by ICH6 GPIO
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: EC: non-query interrupt received, switching to interrupt mode
ACPI: Power Resource [PUBS] (on)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnpacpi: exceeded the max number of mem resources: 12
pnp: PnP ACPI: found 11 devices
ACPI: ACPI bus type pnp unregistered
SCSI subsystem initialized
libata version 3.00 loaded.
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
hpet0: 3 64-bit timers, 14318180 Hz
Time: hpet clocksource has been installed.
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
system 00:00: iomem range 0x0-0x9ffff could not be reserved
system 00:00: iomem range 0xc0000-0xc3fff could not be reserved
system 00:00: iomem range 0xc4000-0xc7fff could not be reserved
system 00:00: iomem range 0xc8000-0xcbfff has been reserved
system 00:00: iomem range 0xcc000-0xcffff has been reserved
system 00:00: iomem range 0x0-0x0 could not be reserved
system 00:00: iomem range 0x0-0x0 could not be reserved
system 00:00: iomem range 0x0-0x0 could not be reserved
system 00:00: iomem range 0xdc000-0xdffff has been reserved
system 00:00: iomem range 0xe0000-0xe3fff has been reserved
system 00:00: iomem range 0xe4000-0xe7fff has been reserved
system 00:00: iomem range 0xe8000-0xebfff has been reserved
system 00:02: ioport range 0x164e-0x164f has been reserved
system 00:02: ioport range 0x1000-0x107f has been reserved
system 00:02: ioport range 0x1180-0x11bf has been reserved
system 00:02: ioport range 0x800-0x80f has been reserved
system 00:02: ioport range 0x15e0-0x15ef has been reserved
system 00:02: ioport range 0x1600-0x165f could not be reserved
system 00:02: iomem range 0xf0000000-0xf3ffffff could not be reserved
system 00:02: iomem range 0xfed1c000-0xfed1ffff could not be reserved
system 00:02: iomem range 0xfed14000-0xfed17fff could not be reserved
system 00:02: iomem range 0xfed18000-0xfed18fff could not be reserved
system 00:02: iomem range 0xfed19000-0xfed19fff could not be reserved
PCI: Bridge: 0000:00:1c.0
  IO window: 2000-2fff
  MEM window: ee000000-ee0fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.1
  IO window: 3000-4fff
  MEM window: ec000000-edffffff
  PREFETCH window: e4000000-e40fffff
PCI: Bridge: 0000:00:1c.2
  IO window: 5000-6fff
  MEM window: e8000000-e9ffffff
  PREFETCH window: e4100000-e41fffff
PCI: Bridge: 0000:00:1c.3
  IO window: 7000-8fff
  MEM window: ea000000-ebffffff
  PREFETCH window: e4200000-e42fffff
PCI: Bus 22, cardbus bridge: 0000:15:00.0
  IO window: 00009000-000090ff
  IO window: 00009400-000094ff
  PREFETCH window: e0000000-e3ffffff
  MEM window: 88000000-8bffffff
PCI: Bridge: 0000:00:1e.0
  IO window: 9000-cfff
  MEM window: e4300000-e7ffffff
  PREFETCH window: e0000000-e3ffffff
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 20 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.0 to 64
ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 21 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.1 to 64
ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 22 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1c.2 to 64
ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 23 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1c.3 to 64
PCI: Enabling device 0000:00:1e.0 (0005 -> 0007)
PCI: Setting latency timer of device 0000:00:1e.0 to 64
ACPI: PCI Interrupt 0000:15:00.0[A] -> GSI 16 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:15:00.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 6, 262144 bytes)
TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 9, 2097152 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
Unpacking initramfs... done
Freeing initrd memory: 5959k freed
Simple Boot Flag at 0x35 set to 0x1
io scheduler noop registered
io scheduler cfq registered (default)
Boot video device is 0000:00:02.0
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.0:pcie00]
Allocate Port Service[0000:00:1c.0:pcie02]
Allocate Port Service[0000:00:1c.0:pcie03]
PCI: Setting latency timer of device 0000:00:1c.1 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.1:pcie00]
Allocate Port Service[0000:00:1c.1:pcie02]
Allocate Port Service[0000:00:1c.1:pcie03]
PCI: Setting latency timer of device 0000:00:1c.2 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.2:pcie00]
Allocate Port Service[0000:00:1c.2:pcie02]
Allocate Port Service[0000:00:1c.2:pcie03]
PCI: Setting latency timer of device 0000:00:1c.3 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.3:pcie00]
Allocate Port Service[0000:00:1c.3:pcie02]
Allocate Port Service[0000:00:1c.3:pcie03]
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Real Time Clock Driver v1.12ac
hpet_resources: 0xfed00000 is busy
Linux agpgart interface v0.102
agpgart: Detected an Intel 945GM Chipset.
agpgart: Detected 7932K stolen memory.
agpgart: AGP aperture is 256M @ 0xd0000000
Driver 'sd' needs updating - please use bus_type methods
PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input0
input: PC Speaker as /class/input/input1
IBM TrackPoint firmware: 0x0e, buttons: 3/3
input: TPPS/2 IBM TrackPoint as /class/input/input2
cpuidle: using governor ladder
cpuidle: using governor menu
TCP cubic registered
NET: Registered protocol family 1
Using IPI No-Shortcut mode
Freeing unused kernel memory: 208k freed
Write protecting the kernel read-only data: 779k
ACPI: SSDT 7F6F1D26, 0240 (r1  PmRef  Cpu0Ist      100 INTL 20050513)
ACPI: SSDT 7F6F1FEB, 065A (r1  PmRef  Cpu0Cst      100 INTL 20050513)
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: SSDT 7F6F1C5E, 00C8 (r1  PmRef  Cpu1Ist      100 INTL 20050513)
ACPI: SSDT 7F6F1F66, 0085 (r1  PmRef  Cpu1Cst      100 INTL 20050513)
ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
ACPI: Processor [CPU1] (supports 8 throttling states)
ACPI: Thermal Zone [THM0] (46 C)
ACPI: Thermal Zone [THM1] (46 C)
ahci 0000:00:1f.2: version 3.0
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 16 (level, low) -> IRQ 20
ahci 0000:00:1f.2: nr_ports (4) and implemented port map (0x1) don't match, using nr_ports
ahci 0000:00:1f.2: forcing PORTS_IMPL to 0xf
Clocksource tsc unstable (delta = -469895959 ns)
ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 1.5 Gbps 0xf impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part 
PCI: Setting latency timer of device 0000:00:1f.2 to 64
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
ata1: SATA max UDMA/133 abar m1024@0xee444400 port 0xee444500 irq 219
ata2: SATA max UDMA/133 abar m1024@0xee444400 port 0xee444580 irq 219
ata3: SATA max UDMA/133 abar m1024@0xee444400 port 0xee444600 irq 219
ata4: SATA max UDMA/133 abar m1024@0xee444400 port 0xee444680 irq 219
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7: HTS721010G9SA00, MCZOC10H, max UDMA/100
ata1.00: 195371568 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 0)
ata3: SATA link down (SStatus 0 SControl 0)
ata4: SATA link down (SStatus 0 SControl 0)
scsi 0:0:0:0: Direct-Access     ATA      HTS721010G9SA00  MCZO PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 >
sd 0:0:0:0: [sda] Attached SCSI disk
ata_piix 0000:00:1f.1: version 2.12
ACPI: PCI Interrupt 0000:00:1f.1[C] -> GSI 16 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:1f.1 to 64
scsi4 : ata_piix
scsi5 : ata_piix
ata5: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x1810 irq 14
ata6: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15
ata6: port disabled. ignoring.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1d.0: irq 20, io base 0x00001820
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 17 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.1: irq 21, io base 0x00001840
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 22
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.2: irq 22, io base 0x00001860
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 19 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.3: irq 23, io base 0x00001880
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 19 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 23, io mem 0xee444000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 8 ports detected
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
sd 0:0:0:0: Attached scsi generic sg0 type 0
input: Power Button (FF) as /class/input/input3
ACPI: Power Button (FF) [PWRF]
input: Lid Switch as /class/input/input4
ACPI: Lid Switch [LID]
input: Sleep Button (CM) as /class/input/input5
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:02:00.0 to 64
ACPI: Sleep Button (CM) [SLPB]
e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:d3:31:39:4d
ACPI: Battery Slot [BAT0] (battery present)
ACPI: AC Adapter [AC] (off-line)
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
Yenta: CardBus bridge found at 0000:15:00.0 [17aa:201c]
ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 21
hda_intel: probe_mask set to 0x1 for device 17aa:2010
PCI: Setting latency timer of device 0000:00:1b.0 to 64
Yenta: ISA IRQ mask 0x0cb8, PCI irq 20
Socket status: 30000006
pcmcia: parent PCI bridge I/O window: 0x9000 - 0xcfff
pcmcia: parent PCI bridge Memory window: 0xe4300000 - 0xe7ffffff
pcmcia: parent PCI bridge Memory window: 0xe0000000 - 0xe3ffffff
ALSA sound/pci/hda/hda_intel.c:576: hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x005b8000
Adding 2096472k swap on /dev/sda5.  Priority:-1 extents:1 across:2096472k
loop: module loaded
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
fuse init (API version 7.9)

[-- Attachment #3: .config --]
[-- Type: application/x-config, Size: 38624 bytes --]

Re: [BUG] 2.6.24-git usb reset problems

[Greg KH]

On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote:
> Hi,
> 
> Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and
> connecting my cf usb storage device yields and endless stream of:
> 
> Initializing USB Mass Storage driver...
> scsi6 : SCSI emulation for USB Mass Storage devices
> usb-storage: device found at 2
> usb-storage: waiting for device to settle before scanning
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> scsi 6:0:0:0: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
> ANSI: 0
> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
> sd 6:0:0:0: [sdb] Write Protect is off
> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
> sd 6:0:0:0: [sdb] Assuming drive cache: write through
> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
> sd 6:0:0:0: [sdb] Write Protect is off
> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
> sd 6:0:0:0: [sdb] Assuming drive cache: write through
>  sdb: sdb1
> sd 6:0:0:0: [sdb] Attached SCSI removable disk
> sd 6:0:0:0: Attached scsi generic sg1 type 0
> scsi 6:0:0:1: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
> ANSI: 0
> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> [...]
> 
> until I disconnect it. The device doesn't work. Worked fine in 2.6.24.
> I'm attaching boot messages and my .config.

That's a bit wierd, as we haven't added any USB patches to the -git tree
yet after 2.6.24 :)

Could this be caused by some scsi changes perhaps?

thanks,

greg k-h

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Mon, Jan 28 2008, Greg KH wrote:
> On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote:
> > Hi,
> > 
> > Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and
> > connecting my cf usb storage device yields and endless stream of:
> > 
> > Initializing USB Mass Storage driver...
> > scsi6 : SCSI emulation for USB Mass Storage devices
> > usb-storage: device found at 2
> > usb-storage: waiting for device to settle before scanning
> > usbcore: registered new interface driver usb-storage
> > USB Mass Storage support registered.
> > scsi 6:0:0:0: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
> > ANSI: 0
> > sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
> > sd 6:0:0:0: [sdb] Write Protect is off
> > sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
> > sd 6:0:0:0: [sdb] Assuming drive cache: write through
> > sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
> > sd 6:0:0:0: [sdb] Write Protect is off
> > sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
> > sd 6:0:0:0: [sdb] Assuming drive cache: write through
> >  sdb: sdb1
> > sd 6:0:0:0: [sdb] Attached SCSI removable disk
> > sd 6:0:0:0: Attached scsi generic sg1 type 0
> > scsi 6:0:0:1: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
> > ANSI: 0
> > usb 5-1: reset high speed USB device using ehci_hcd and address 2
> > usb 5-1: reset high speed USB device using ehci_hcd and address 2
> > usb 5-1: reset high speed USB device using ehci_hcd and address 2
> > usb 5-1: reset high speed USB device using ehci_hcd and address 2
> > usb 5-1: reset high speed USB device using ehci_hcd and address 2
> > usb 5-1: reset high speed USB device using ehci_hcd and address 2
> > usb 5-1: reset high speed USB device using ehci_hcd and address 2
> > [...]
> > 
> > until I disconnect it. The device doesn't work. Worked fine in 2.6.24.
> > I'm attaching boot messages and my .config.
> 
> That's a bit wierd, as we haven't added any USB patches to the -git tree
> yet after 2.6.24 :)
> 
> Could this be caused by some scsi changes perhaps?

Heh, I guess it could! I'll double check, I reproduced it with two
distinct boots before posting.

-- 
Jens Axboe

Re: [BUG] 2.6.24-git usb reset problems

[Boaz Harrosh]

Greg KH wrote:
> On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote:
>> Hi,
>>
>> Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and
>> connecting my cf usb storage device yields and endless stream of:
>>
>> Initializing USB Mass Storage driver...
>> scsi6 : SCSI emulation for USB Mass Storage devices
>> usb-storage: device found at 2
>> usb-storage: waiting for device to settle before scanning
>> usbcore: registered new interface driver usb-storage
>> USB Mass Storage support registered.
>> scsi 6:0:0:0: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
>> ANSI: 0
>> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
>> sd 6:0:0:0: [sdb] Write Protect is off
>> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
>> sd 6:0:0:0: [sdb] Assuming drive cache: write through
>> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
>> sd 6:0:0:0: [sdb] Write Protect is off
>> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
>> sd 6:0:0:0: [sdb] Assuming drive cache: write through
>>  sdb: sdb1
>> sd 6:0:0:0: [sdb] Attached SCSI removable disk
>> sd 6:0:0:0: Attached scsi generic sg1 type 0
>> scsi 6:0:0:1: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
>> ANSI: 0
>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>> [...]
>>
>> until I disconnect it. The device doesn't work. Worked fine in 2.6.24.
>> I'm attaching boot messages and my .config.
> 
> That's a bit wierd, as we haven't added any USB patches to the -git tree
> yet after 2.6.24 :)
> 
> Could this be caused by some scsi changes perhaps?
> 
> thanks,
> 
> greg k-h
> -
Yes it is ;)

Jens could you test the patch below? if it works I'll submit a proper
patch. Please forgive me for the bug.

Matthew, Greg, Is there a way to extract from messages the usb storage transport
used? I'm guessing it is freecom do to the fact that I find a bug there.

Thanks
Boaz

---
 drivers/usb/storage/freecom.c   |    4 ++--
 drivers/usb/storage/transport.c |   12 +++++++++---
 drivers/usb/storage/transport.h |    3 ++-
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/storage/freecom.c b/drivers/usb/storage/freecom.c
index f5a4e8d..8d77603 100644
--- a/drivers/usb/storage/freecom.c
+++ b/drivers/usb/storage/freecom.c
@@ -132,7 +132,7 @@ freecom_readdata (struct scsi_cmnd *srb, struct us_data *us,
 
 	/* Now transfer all of our blocks. */
 	US_DEBUGP("Start of read\n");
-	result = usb_stor_bulk_srb(us, ipipe, srb);
+	result = usb_stor_bulk_srb_length(us, ipipe, srb, count);
 	US_DEBUGP("freecom_readdata done!\n");
 
 	if (result > USB_STOR_XFER_SHORT)
@@ -165,7 +165,7 @@ freecom_writedata (struct scsi_cmnd *srb, struct us_data *us,
 
 	/* Now transfer all of our blocks. */
 	US_DEBUGP("Start of write\n");
-	result = usb_stor_bulk_srb(us, opipe, srb);
+	result = usb_stor_bulk_srb_length(us, opipe, srb, count);
 
 	US_DEBUGP("freecom_writedata done!\n");
 	if (result > USB_STOR_XFER_SHORT)
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index d9f4912..5072235 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe,
  * Common used function. Transfer a complete command
  * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
  */
-int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
-		      struct scsi_cmnd* srb)
+int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
+		      struct scsi_cmnd* srb, unsigned length)
 {
 	unsigned int partial;
 	int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
-				      scsi_sg_count(srb), scsi_bufflen(srb),
+				      scsi_sg_count(srb), length,
 				      &partial);
 
 	scsi_set_resid(srb, scsi_bufflen(srb) - partial);
 	return result;
 }
 
+int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
+		struct scsi_cmnd* srb)
+{
+	return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
+}
+
 /*
  * Transfer an entire SCSI command's worth of data payload over the bulk
  * pipe.
diff --git a/drivers/usb/storage/transport.h b/drivers/usb/storage/transport.h
index ada7c2f..03e395d 100644
--- a/drivers/usb/storage/transport.h
+++ b/drivers/usb/storage/transport.h
@@ -139,8 +139,9 @@ extern int usb_stor_bulk_transfer_buf(struct us_data *us, unsigned int pipe,
 		void *buf, unsigned int length, unsigned int *act_len);
 extern int usb_stor_bulk_transfer_sg(struct us_data *us, unsigned int pipe,
 		void *buf, unsigned int length, int use_sg, int *residual);
+extern int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
+		struct scsi_cmnd* srb, unsigned length);
 extern int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
 		struct scsi_cmnd* srb);
-
 extern int usb_stor_port_reset(struct us_data *us);
 #endif

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Tue, Jan 29 2008, Boaz Harrosh wrote:
> Greg KH wrote:
> > On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote:
> >> Hi,
> >>
> >> Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and
> >> connecting my cf usb storage device yields and endless stream of:
> >>
> >> Initializing USB Mass Storage driver...
> >> scsi6 : SCSI emulation for USB Mass Storage devices
> >> usb-storage: device found at 2
> >> usb-storage: waiting for device to settle before scanning
> >> usbcore: registered new interface driver usb-storage
> >> USB Mass Storage support registered.
> >> scsi 6:0:0:0: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
> >> ANSI: 0
> >> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
> >> sd 6:0:0:0: [sdb] Write Protect is off
> >> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
> >> sd 6:0:0:0: [sdb] Assuming drive cache: write through
> >> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
> >> sd 6:0:0:0: [sdb] Write Protect is off
> >> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
> >> sd 6:0:0:0: [sdb] Assuming drive cache: write through
> >>  sdb: sdb1
> >> sd 6:0:0:0: [sdb] Attached SCSI removable disk
> >> sd 6:0:0:0: Attached scsi generic sg1 type 0
> >> scsi 6:0:0:1: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
> >> ANSI: 0
> >> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >> [...]
> >>
> >> until I disconnect it. The device doesn't work. Worked fine in 2.6.24.
> >> I'm attaching boot messages and my .config.
> > 
> > That's a bit wierd, as we haven't added any USB patches to the -git tree
> > yet after 2.6.24 :)
> > 
> > Could this be caused by some scsi changes perhaps?
> > 
> > thanks,
> > 
> > greg k-h
> > -
> Yes it is ;)
> 
> Jens could you test the patch below? if it works I'll submit a proper
> patch. Please forgive me for the bug.

No difference, still just a lot of resets.

-- 
Jens Axboe

Re: [BUG] 2.6.24-git usb reset problems

[Boaz Harrosh]

On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> On Tue, Jan 29 2008, Boaz Harrosh wrote:
>> Greg KH wrote:
>>> On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote:
>>>> Hi,
>>>>
>>>> Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and
>>>> connecting my cf usb storage device yields and endless stream of:
>>>>
>>>> Initializing USB Mass Storage driver...
>>>> scsi6 : SCSI emulation for USB Mass Storage devices
>>>> usb-storage: device found at 2
>>>> usb-storage: waiting for device to settle before scanning
>>>> usbcore: registered new interface driver usb-storage
>>>> USB Mass Storage support registered.
>>>> scsi 6:0:0:0: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
>>>> ANSI: 0
>>>> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
>>>> sd 6:0:0:0: [sdb] Write Protect is off
>>>> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
>>>> sd 6:0:0:0: [sdb] Assuming drive cache: write through
>>>> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
>>>> sd 6:0:0:0: [sdb] Write Protect is off
>>>> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
>>>> sd 6:0:0:0: [sdb] Assuming drive cache: write through
>>>>  sdb: sdb1
>>>> sd 6:0:0:0: [sdb] Attached SCSI removable disk
>>>> sd 6:0:0:0: Attached scsi generic sg1 type 0
>>>> scsi 6:0:0:1: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
>>>> ANSI: 0
>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>> [...]
>>>>
>>>> until I disconnect it. The device doesn't work. Worked fine in 2.6.24.
>>>> I'm attaching boot messages and my .config.
>>> That's a bit wierd, as we haven't added any USB patches to the -git tree
>>> yet after 2.6.24 :)
>>>
>>> Could this be caused by some scsi changes perhaps?
>>>
>>> thanks,
>>>
>>> greg k-h
>>> -
>> Yes it is ;)
>>
>> Jens could you test the patch below? if it works I'll submit a proper
>> patch. Please forgive me for the bug.
> 
> No difference, still just a lot of resets.
> 
Where you able to figure out which usb storage transport is used?

in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
functions. I'm not sure if these get stored in sysfs perhaps. This will
pinpoint better where to look. Let me research a bit. 

Thanks for testing
Boaz

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Tue, Jan 29 2008, Boaz Harrosh wrote:
> On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> >> Greg KH wrote:
> >>> On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote:
> >>>> Hi,
> >>>>
> >>>> Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and
> >>>> connecting my cf usb storage device yields and endless stream of:
> >>>>
> >>>> Initializing USB Mass Storage driver...
> >>>> scsi6 : SCSI emulation for USB Mass Storage devices
> >>>> usb-storage: device found at 2
> >>>> usb-storage: waiting for device to settle before scanning
> >>>> usbcore: registered new interface driver usb-storage
> >>>> USB Mass Storage support registered.
> >>>> scsi 6:0:0:0: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
> >>>> ANSI: 0
> >>>> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
> >>>> sd 6:0:0:0: [sdb] Write Protect is off
> >>>> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
> >>>> sd 6:0:0:0: [sdb] Assuming drive cache: write through
> >>>> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
> >>>> sd 6:0:0:0: [sdb] Write Protect is off
> >>>> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
> >>>> sd 6:0:0:0: [sdb] Assuming drive cache: write through
> >>>>  sdb: sdb1
> >>>> sd 6:0:0:0: [sdb] Attached SCSI removable disk
> >>>> sd 6:0:0:0: Attached scsi generic sg1 type 0
> >>>> scsi 6:0:0:1: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
> >>>> ANSI: 0
> >>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >>>> [...]
> >>>>
> >>>> until I disconnect it. The device doesn't work. Worked fine in 2.6.24.
> >>>> I'm attaching boot messages and my .config.
> >>> That's a bit wierd, as we haven't added any USB patches to the -git tree
> >>> yet after 2.6.24 :)
> >>>
> >>> Could this be caused by some scsi changes perhaps?
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>> -
> >> Yes it is ;)
> >>
> >> Jens could you test the patch below? if it works I'll submit a proper
> >> patch. Please forgive me for the bug.
> > 
> > No difference, still just a lot of resets.
> > 
> Where you able to figure out which usb storage transport is used?
> 
> in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> functions. I'm not sure if these get stored in sysfs perhaps. This will
> pinpoint better where to look. Let me research a bit. 

Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
transport is 'Bulk'

-- 
Jens Axboe

Re: [BUG] 2.6.24-git usb reset problems

[Boaz Harrosh]

On Tue, Jan 29 2008 at 16:06 +0200, Boaz Harrosh <bharrosh@panasas.com> wrote:
> On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
>>> Greg KH wrote:
>>>> On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote:
>>>>> Hi,
>>>>>
>>>>> Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and
>>>>> connecting my cf usb storage device yields and endless stream of:
>>>>>
>>>>> Initializing USB Mass Storage driver...
>>>>> scsi6 : SCSI emulation for USB Mass Storage devices
>>>>> usb-storage: device found at 2
>>>>> usb-storage: waiting for device to settle before scanning
>>>>> usbcore: registered new interface driver usb-storage
>>>>> USB Mass Storage support registered.
>>>>> scsi 6:0:0:0: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
>>>>> ANSI: 0
>>>>> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
>>>>> sd 6:0:0:0: [sdb] Write Protect is off
>>>>> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
>>>>> sd 6:0:0:0: [sdb] Assuming drive cache: write through
>>>>> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
>>>>> sd 6:0:0:0: [sdb] Write Protect is off
>>>>> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
>>>>> sd 6:0:0:0: [sdb] Assuming drive cache: write through
>>>>>  sdb: sdb1
>>>>> sd 6:0:0:0: [sdb] Attached SCSI removable disk
>>>>> sd 6:0:0:0: Attached scsi generic sg1 type 0
>>>>> scsi 6:0:0:1: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
>>>>> ANSI: 0
>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>> [...]
>>>>>
>>>>> until I disconnect it. The device doesn't work. Worked fine in 2.6.24.
>>>>> I'm attaching boot messages and my .config.
>>>> That's a bit wierd, as we haven't added any USB patches to the -git tree
>>>> yet after 2.6.24 :)
>>>>
>>>> Could this be caused by some scsi changes perhaps?
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>>> -
>>> Yes it is ;)
>>>
>>> Jens could you test the patch below? if it works I'll submit a proper
>>> patch. Please forgive me for the bug.
>> No difference, still just a lot of resets.
>>
> Where you able to figure out which usb storage transport is used?
> 
> in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> functions. I'm not sure if these get stored in sysfs perhaps. This will
> pinpoint better where to look. Let me research a bit. 
> 
>From inspection of code it should be in /proc/scsi somewhere look for:
	SPRINTF("     Protocol: %s\n", us->protocol_name);
	SPRINTF("    Transport: %s\n", us->transport_name);

(it's proc_info() in drivers/usb/storage/scsiglue.c)

Thanks
Boaz

Re: [BUG] 2.6.24-git usb reset problems

[Boaz Harrosh]

On Tue, Jan 29 2008 at 16:11 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> On Tue, Jan 29 2008, Boaz Harrosh wrote:
>> On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
>>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
>>>> Greg KH wrote:
>>>>> On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and
>>>>>> connecting my cf usb storage device yields and endless stream of:
>>>>>>
>>>>>> Initializing USB Mass Storage driver...
>>>>>> scsi6 : SCSI emulation for USB Mass Storage devices
>>>>>> usb-storage: device found at 2
>>>>>> usb-storage: waiting for device to settle before scanning
>>>>>> usbcore: registered new interface driver usb-storage
>>>>>> USB Mass Storage support registered.
>>>>>> scsi 6:0:0:0: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
>>>>>> ANSI: 0
>>>>>> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
>>>>>> sd 6:0:0:0: [sdb] Write Protect is off
>>>>>> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
>>>>>> sd 6:0:0:0: [sdb] Assuming drive cache: write through
>>>>>> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
>>>>>> sd 6:0:0:0: [sdb] Write Protect is off
>>>>>> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
>>>>>> sd 6:0:0:0: [sdb] Assuming drive cache: write through
>>>>>>  sdb: sdb1
>>>>>> sd 6:0:0:0: [sdb] Attached SCSI removable disk
>>>>>> sd 6:0:0:0: Attached scsi generic sg1 type 0
>>>>>> scsi 6:0:0:1: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
>>>>>> ANSI: 0
>>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>>> [...]
>>>>>>
>>>>>> until I disconnect it. The device doesn't work. Worked fine in 2.6.24.
>>>>>> I'm attaching boot messages and my .config.
>>>>> That's a bit wierd, as we haven't added any USB patches to the -git tree
>>>>> yet after 2.6.24 :)
>>>>>
>>>>> Could this be caused by some scsi changes perhaps?
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>> -
>>>> Yes it is ;)
>>>>
>>>> Jens could you test the patch below? if it works I'll submit a proper
>>>> patch. Please forgive me for the bug.
>>> No difference, still just a lot of resets.
>>>
>> Where you able to figure out which usb storage transport is used?
>>
>> in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
>> functions. I'm not sure if these get stored in sysfs perhaps. This will
>> pinpoint better where to look. Let me research a bit. 
> 
> Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
> transport is 'Bulk'
> 
Sorry for the other noise. Thanks I'll have a look.

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Tue, Jan 29 2008, Oliver Neukum wrote:
> Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
> > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > >> Greg KH wrote:
>  
> > > > No difference, still just a lot of resets.
> > > > 
> > > Where you able to figure out which usb storage transport is used?
> > > 
> > > in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> > > functions. I'm not sure if these get stored in sysfs perhaps. This will
> > > pinpoint better where to look. Let me research a bit. 
> > 
> > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
> > transport is 'Bulk'
> 
> You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
> That should tell the reason for the resets.

Sure, I'll do that. Will post the results tonight.

-- 
Jens Axboe

Re: [BUG] 2.6.24-git usb reset problems

[Oliver Neukum]

Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
> On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > >> Greg KH wrote:
 
> > > No difference, still just a lot of resets.
> > > 
> > Where you able to figure out which usb storage transport is used?
> > 
> > in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> > functions. I'm not sure if these get stored in sysfs perhaps. This will
> > pinpoint better where to look. Let me research a bit. 
> 
> Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
> transport is 'Bulk'

You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
That should tell the reason for the resets.

	Regards
		Oliver

Re: [BUG] 2.6.24-git usb reset problems

[Matthew Dharm]

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

On Tue, Jan 29, 2008 at 02:15:15PM +0200, Boaz Harrosh wrote:
> Greg KH wrote:
> > On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote:
> >> Hi,
> >>
> >> Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and
> >> connecting my cf usb storage device yields and endless stream of:
> >>
> >> Initializing USB Mass Storage driver...
> >> scsi6 : SCSI emulation for USB Mass Storage devices
> >> usb-storage: device found at 2
> >> usb-storage: waiting for device to settle before scanning
> >> usbcore: registered new interface driver usb-storage
> >> USB Mass Storage support registered.
> >> scsi 6:0:0:0: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
> >> ANSI: 0
> >> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
> >> sd 6:0:0:0: [sdb] Write Protect is off
> >> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
> >> sd 6:0:0:0: [sdb] Assuming drive cache: write through
> >> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
> >> sd 6:0:0:0: [sdb] Write Protect is off
> >> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
> >> sd 6:0:0:0: [sdb] Assuming drive cache: write through
> >>  sdb: sdb1
> >> sd 6:0:0:0: [sdb] Attached SCSI removable disk
> >> sd 6:0:0:0: Attached scsi generic sg1 type 0
> >> scsi 6:0:0:1: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0
> >> ANSI: 0
> >> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >> [...]
> >>
> >> until I disconnect it. The device doesn't work. Worked fine in 2.6.24.
> >> I'm attaching boot messages and my .config.
> > 
> > That's a bit wierd, as we haven't added any USB patches to the -git tree
> > yet after 2.6.24 :)
> > 
> > Could this be caused by some scsi changes perhaps?
> > 
> > thanks,
> > 
> > greg k-h
> > -
> Yes it is ;)
> 
> Jens could you test the patch below? if it works I'll submit a proper
> patch. Please forgive me for the bug.
> 
> Matthew, Greg, Is there a way to extract from messages the usb storage transport
> used? I'm guessing it is freecom do to the fact that I find a bug there.

The freecom transport is exceptionally rare these days.  It's primary user
was a device made by a company that went out of business.

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

Way to go, lava boy.
					-- Stef to Greg
User Friendly, 3/26/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [BUG] 2.6.24-git usb reset problems

[Alan Stern]

On Tue, 29 Jan 2008, Boaz Harrosh wrote:

> --- a/drivers/usb/storage/transport.c
> +++ b/drivers/usb/storage/transport.c
> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe,
>   * Common used function. Transfer a complete command
>   * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
>   */
> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> -		      struct scsi_cmnd* srb)
> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
> +		      struct scsi_cmnd* srb, unsigned length)
>  {
>  	unsigned int partial;
>  	int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> -				      scsi_sg_count(srb), scsi_bufflen(srb),
> +				      scsi_sg_count(srb), length,
>  				      &partial);
>  
>  	scsi_set_resid(srb, scsi_bufflen(srb) - partial);
>  	return result;
>  }
>  
> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> +		struct scsi_cmnd* srb)
> +{
> +	return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
> +}
> +

I don't like this patch very much.  Why add another layer of 
indirection when the two subroutines do hardly any work?  Leave 
usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length() 
as a separate routine that simply calls usb_stor_bulk_transfer_sglist() 
and scsi_set_resid().

BTW, the standard coding style calls for a blank line after the list of 
local variables at the start of a function or block.

Alan Stern

Re: [BUG] 2.6.24-git usb reset problems

[Boaz Harrosh]

On Tue, Jan 29 2008 at 16:31 +0200, Oliver Neukum <oliver@neukum.org> wrote:
> Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
>>> On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
>>>>> Greg KH wrote:
>  
>>>> No difference, still just a lot of resets.
>>>>
>>> Where you able to figure out which usb storage transport is used?
>>>
>>> in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
>>> functions. I'm not sure if these get stored in sysfs perhaps. This will
>>> pinpoint better where to look. Let me research a bit. 
>> Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
>> transport is 'Bulk'
> 
> You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
> That should tell the reason for the resets.
> 
> 	Regards
> 		Oliver
> -

I can not see what it is. Yes CONFIG_USB_STORAGE_DEBUG will help.
I have a device here that uses the same trasport/protocol I'll
try to reproduce the failure here.

Boaz

Re: [BUG] 2.6.24-git usb reset problems

[Boaz Harrosh]

On Tue, Jan 29 2008 at 17:36 +0200, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Tue, 29 Jan 2008, Boaz Harrosh wrote:
> 
>> --- a/drivers/usb/storage/transport.c
>> +++ b/drivers/usb/storage/transport.c
>> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe,
>>   * Common used function. Transfer a complete command
>>   * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
>>   */
>> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>> -		      struct scsi_cmnd* srb)
>> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
>> +		      struct scsi_cmnd* srb, unsigned length)
>>  {
>>  	unsigned int partial;
>>  	int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
>> -				      scsi_sg_count(srb), scsi_bufflen(srb),
>> +				      scsi_sg_count(srb), length,
>>  				      &partial);
>>  
>>  	scsi_set_resid(srb, scsi_bufflen(srb) - partial);
>>  	return result;
>>  }
>>  
>> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>> +		struct scsi_cmnd* srb)
>> +{
>> +	return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
>> +}
>> +
> 
> I don't like this patch very much.  Why add another layer of 
> indirection when the two subroutines do hardly any work?  Leave 
> usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length() 
> as a separate routine that simply calls usb_stor_bulk_transfer_sglist() 
> and scsi_set_resid().
> 
> BTW, the standard coding style calls for a blank line after the list of 
> local variables at the start of a function or block.
> 
> Alan Stern
> 
> -
Me neither, it's not a proper patch just a shut to try and find the reported
bug. I will submit a proper bug later.

Thanks for the review, you are right on all accounts
Boaz

Re: [BUG] 2.6.24-git usb reset problems

[James Bottomley]

On Tue, 2008-01-29 at 10:36 -0500, Alan Stern wrote:
> On Tue, 29 Jan 2008, Boaz Harrosh wrote:
> 
> > --- a/drivers/usb/storage/transport.c
> > +++ b/drivers/usb/storage/transport.c
> > @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe,
> >   * Common used function. Transfer a complete command
> >   * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
> >   */
> > -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> > -		      struct scsi_cmnd* srb)
> > +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
> > +		      struct scsi_cmnd* srb, unsigned length)
> >  {
> >  	unsigned int partial;
> >  	int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> > -				      scsi_sg_count(srb), scsi_bufflen(srb),
> > +				      scsi_sg_count(srb), length,
> >  				      &partial);
> >  
> >  	scsi_set_resid(srb, scsi_bufflen(srb) - partial);
> >  	return result;
> >  }
> >  
> > +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> > +		struct scsi_cmnd* srb)
> > +{
> > +	return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
> > +}
> > +
> 
> I don't like this patch very much.  Why add another layer of 
> indirection when the two subroutines do hardly any work?  Leave 
> usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length() 
> as a separate routine that simply calls usb_stor_bulk_transfer_sglist() 
> and scsi_set_resid().
> 
> BTW, the standard coding style calls for a blank line after the list of 
> local variables at the start of a function or block.

There's another bug in the transport.c conversion in that the residuals
are updated with bogus data in several error cases, since
usb_stor_bulk_transfer_sglist() only sets the actual length if the urb
is actually sent.

I'm not sure if this is is the solution to the problem at hand, but it
definitely fixes another bug in the code.

James

diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index d9f4912..bab0858 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe,
 int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
 		      struct scsi_cmnd* srb)
 {
-	unsigned int partial;
+	unsigned int partial = scsi_get_resid(srb);
 	int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
 				      scsi_sg_count(srb), scsi_bufflen(srb),
 				      &partial);

Re: [BUG] 2.6.24-git usb reset problems

[Oliver Neukum]

Am Dienstag, 29. Januar 2008 16:50:35 schrieb Boaz Harrosh:
> On Tue, Jan 29 2008 at 16:31 +0200, Oliver Neukum <oliver@neukum.org> wrote:
 
> I can not see what it is. Yes CONFIG_USB_STORAGE_DEBUG will help.
> I have a device here that uses the same trasport/protocol I'll
> try to reproduce the failure here.

This is the most common combination of transport and protocol. If it were
broken in a larger number of cases, we'd hear more reports. You'll probably
need the debug output to figure out what's wrong.

	Regards
		Oliver

Re: [BUG] 2.6.24-git usb reset problems

[Boaz Harrosh]

On Tue, Jan 29 2008 at 18:34 +0200, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> On Tue, 2008-01-29 at 10:36 -0500, Alan Stern wrote:
>> On Tue, 29 Jan 2008, Boaz Harrosh wrote:
>>
>>> --- a/drivers/usb/storage/transport.c
>>> +++ b/drivers/usb/storage/transport.c
>>> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe,
>>>   * Common used function. Transfer a complete command
>>>   * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
>>>   */
>>> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>>> -		      struct scsi_cmnd* srb)
>>> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
>>> +		      struct scsi_cmnd* srb, unsigned length)
>>>  {
>>>  	unsigned int partial;
>>>  	int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
>>> -				      scsi_sg_count(srb), scsi_bufflen(srb),
>>> +				      scsi_sg_count(srb), length,
>>>  				      &partial);
>>>  
>>>  	scsi_set_resid(srb, scsi_bufflen(srb) - partial);
>>>  	return result;
>>>  }
>>>  
>>> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>>> +		struct scsi_cmnd* srb)
>>> +{
>>> +	return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
>>> +}
>>> +
>> I don't like this patch very much.  Why add another layer of 
>> indirection when the two subroutines do hardly any work?  Leave 
>> usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length() 
>> as a separate routine that simply calls usb_stor_bulk_transfer_sglist() 
>> and scsi_set_resid().
>>
>> BTW, the standard coding style calls for a blank line after the list of 
>> local variables at the start of a function or block.
> 
> There's another bug in the transport.c conversion in that the residuals
> are updated with bogus data in several error cases, since
> usb_stor_bulk_transfer_sglist() only sets the actual length if the urb
> is actually sent.
> 
> I'm not sure if this is is the solution to the problem at hand, but it
> definitely fixes another bug in the code.
> 
> James
> 
> diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
> index d9f4912..bab0858 100644
> --- a/drivers/usb/storage/transport.c
> +++ b/drivers/usb/storage/transport.c
> @@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe,
>  int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>  		      struct scsi_cmnd* srb)
>  {
> -	unsigned int partial;
> +	unsigned int partial = scsi_get_resid(srb);
>  	int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
>  				      scsi_sg_count(srb), scsi_bufflen(srb),
>  				      &partial);
> 
> 
> -
But then this is weird because it is not what usb_stor_bulk_transfer_sg() is doing
which was the one called before.

I have such a device and I get one reset but then every thing works nice.
This is with debug on. I'll try to make it fail.

Boaz

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Tue, Jan 29 2008, Jens Axboe wrote:
> On Tue, Jan 29 2008, Oliver Neukum wrote:
> > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
> > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > >> Greg KH wrote:
> >  
> > > > > No difference, still just a lot of resets.
> > > > > 
> > > > Where you able to figure out which usb storage transport is used?
> > > > 
> > > > in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> > > > functions. I'm not sure if these get stored in sysfs perhaps. This will
> > > > pinpoint better where to look. Let me research a bit. 
> > > 
> > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
> > > transport is 'Bulk'
> > 
> > You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
> > That should tell the reason for the resets.
> 
> Sure, I'll do that. Will post the results tonight.

OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
in the device, waited 10 seconds or so and pulled it out. These are the
messages.

It all looks good until the MODE_SENSE command, where it only transfers
4 of 192 bytes.

usb usb5: usb resume
ehci_hcd 0000:00:1d.7: resume root hub
hub 5-0:1.0: hub_resume
hub 5-0:1.0: state 7 ports 8 chg 0000 evt 0000
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001803 POWER sig=j CSC CONNECT
hub 5-0:1.0: port 1, status 0501, change 0001, 480 Mb/s
hub 5-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x501
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: new high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: default language 0x0409
usb 5-1: uevent
usb 5-1: usb_probe_device
usb 5-1: configuration #1 chosen from 1 choice
usb 5-1: adding 5-1:1.0 (config #1, interface 0)
usb 5-1:1.0: uevent
drivers/usb/core/inode.c: creating file '002'
usb 5-1: new device strings: Mfr=0, Product=3, SerialNumber=4
usb 5-1: Product: Flash Reader
usb 5-1: SerialNumber: 02206
Initializing USB Mass Storage driver...
usb-storage 5-1:1.0: usb_probe_interface
usb-storage 5-1:1.0: usb_probe_interface - got id
usb-storage: USB Mass Storage device detected
usb-storage: -- associate_dev
usb-storage: Vendor: 0x05e3, Product: 0x0760, Revision: 0x0125
usb-storage: Interface Subclass: 0x06, Protocol: 0x50
usb trans Bulk
usb-storage: Transport: Bulk
usb proto Transparent SCSI
usb-storage: Protocol: Transparent SCSI
scsi6 : SCSI emulation for USB Mass Storage devices
usb-storage: *** thread sleeping.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 value=0000 index=00 len=1
usb-storage: GetMaxLUN command result is 1, data is 3
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command INQUIRY (6 bytes)
usb-storage:  12 00 00 00 24 00
usb-storage: Bulk Command S 0x43425355 T 0x1 L 36 F 128 Trg 0 LUN 0 CL 6
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 36 bytes, 1 entries
usb-storage: Status code 0; transferred 36/36
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 0x1 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
scsi 6:0:0:0: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0 ANSI: 0
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x2 L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x2 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_CAPACITY (10 bytes)
usb-storage:  25 00 00 00 00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x3 L 8 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 8 bytes, 1 entries
usb-storage: Status code 0; transferred 8/8
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 0x3 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command MODE_SENSE (6 bytes)
usb-storage:  1a 00 3f 00 c0 00
usb-storage: Bulk Command S 0x43425355 T 0x4 L 192 F 128 Trg 0 LUN 0 CL 6
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 192 bytes, 1 entries
usb-storage: Status code -121; transferred 4/192
usb-storage: -- short read transfer
usb-storage: Bulk data transfer result 0x1
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code -32; transferred 0/13
usb-storage: clearing endpoint halt for pipe 0xc0008280
usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=81 len=0
usb-storage: usb_stor_clear_halt: result = 0
usb-storage: Attempting to get CSW (2nd try)...
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 0x4 R 188 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
sd 6:0:0:0: [sdb] Write Protect is off
sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
sd 6:0:0:0: [sdb] Assuming drive cache: write through
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x5 L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x5 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 ALLOW_MEDIUM_REMOVAL (6 bytes)
usb-storage:  1e 00 00 00 01 00
usb-storage: Bulk Command S 0x43425355 T 0x6 L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x6 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 TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x7 L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x7 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_CAPACITY (10 bytes)
usb-storage:  25 00 00 00 00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x8 L 8 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 8 bytes, 1 entries
usb-storage: Status code 0; transferred 8/8
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 0x8 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB)
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command MODE_SENSE (6 bytes)
usb-storage:  1a 00 3f 00 c0 00
usb-storage: Bulk Command S 0x43425355 T 0x9 L 192 F 128 Trg 0 LUN 0 CL 6
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 192 bytes, 1 entries
usb-storage: Status code -121; transferred 4/192
usb-storage: -- short read transfer
usb-storage: Bulk data transfer result 0x1
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code -32; transferred 0/13
usb-storage: clearing endpoint halt for pipe 0xc0008280
usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=81 len=0
usb-storage: usb_stor_clear_halt: result = 0
usb-storage: Attempting to get CSW (2nd try)...
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 0x9 R 188 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
sd 6:0:0:0: [sdb] Write Protect is off
sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00
sd 6:0:0:0: [sdb] Assuming drive cache: write through
 sdb:<7>usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command READ_10 (10 bytes)
usb-storage:  28 00 00 00 00 00 00 00 08 00
usb-storage: Bulk Command S 0x43425355 T 0xa L 4096 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 4096 bytes, 1 entries
usb-storage: Status code 0; transferred 4096/4096
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 0xa R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
 sdb1
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command ALLOW_MEDIUM_REMOVAL (6 bytes)
usb-storage:  1e 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0xb L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0xb R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
sd 6:0:0:0: [sdb] Attached SCSI removable disk
sd 6:0:0:0: Attached scsi generic sg1 type 0
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command INQUIRY (6 bytes)
usb-storage:  12 00 00 00 24 00
usb-storage: Bulk Command S 0x43425355 T 0xc L 36 F 128 Trg 0 LUN 1 CL 6
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 36 bytes, 1 entries
usb-storage: Status code 0; transferred 36/36
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 0xc R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
scsi 6:0:0:1: Direct-Access     Generic  STORAGE DEVICE   0125 PQ: 0 ANSI: 0
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6
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: 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 0xd R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0xf L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0xf R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x10 L 18 F 128 Trg 0 LUN 0 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x11 L 0 F 0 Trg 0 LUN 1 CL 6
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: 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 0x11 R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x12 L 18 F 128 Trg 0 LUN 1 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x13 L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x13 R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x14 L 18 F 128 Trg 0 LUN 0 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x15 L 0 F 0 Trg 0 LUN 1 CL 6
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: 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 0x15 R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x16 L 18 F 128 Trg 0 LUN 1 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x17 L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x17 R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x18 L 18 F 128 Trg 0 LUN 0 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x19 L 0 F 0 Trg 0 LUN 1 CL 6
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: 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 0x19 R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x1a L 18 F 128 Trg 0 LUN 1 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x1b L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x1b R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x1c L 18 F 128 Trg 0 LUN 0 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x1d L 0 F 0 Trg 0 LUN 1 CL 6
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: 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 0x1d R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x1e L 18 F 128 Trg 0 LUN 1 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x1f L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x1f R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x20 L 18 F 128 Trg 0 LUN 0 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x21 L 0 F 0 Trg 0 LUN 1 CL 6
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: 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 0x21 R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x22 L 18 F 128 Trg 0 LUN 1 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x23 L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x23 R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x24 L 18 F 128 Trg 0 LUN 0 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command READ_CAPACITY (10 bytes)
usb-storage:  25 00 00 00 00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x25 L 8 F 128 Trg 0 LUN 1 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 8 bytes, 1 entries
usb-storage: Status code -32; transferred 0/8
usb-storage: clearing endpoint halt for pipe 0xc0008280
usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=81 len=0
usb-storage: usb_stor_clear_halt: result = 0
usb-storage: Bulk data transfer result 0x2
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 0x25 R 8 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: -- unexpectedly short transfer
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x26 L 18 F 128 Trg 0 LUN 1 CL 6
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 18 bytes, 1 entries
usb-storage: Status code -75; transferred 0/18
usb-storage: -- babble
usb-storage: Bulk data transfer result 0x3
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code -75; transferred 0/13
usb-storage: -- babble
usb-storage: Bulk status result = 3
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x27 L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x27 R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x28 L 18 F 128 Trg 0 LUN 0 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command READ_CAPACITY (10 bytes)
usb-storage:  25 00 00 00 00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x29 L 8 F 128 Trg 0 LUN 1 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 8 bytes, 1 entries
usb-storage: Status code -32; transferred 0/8
usb-storage: clearing endpoint halt for pipe 0xc0008280
usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=81 len=0
usb-storage: usb_stor_clear_halt: result = 0
usb-storage: Bulk data transfer result 0x2
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 0x29 R 8 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: -- unexpectedly short transfer
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x2a L 18 F 128 Trg 0 LUN 1 CL 6
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 18 bytes, 1 entries
usb-storage: Status code -75; transferred 0/18
usb-storage: -- babble
usb-storage: Bulk data transfer result 0x3
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code -75; transferred 0/13
usb-storage: -- babble
usb-storage: Bulk status result = 3
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x2b L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x2b R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x2c L 18 F 128 Trg 0 LUN 0 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command READ_CAPACITY (10 bytes)
usb-storage:  25 00 00 00 00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x2d L 8 F 128 Trg 0 LUN 1 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 8 bytes, 1 entries
usb-storage: Status code -32; transferred 0/8
usb-storage: clearing endpoint halt for pipe 0xc0008280
usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=81 len=0
usb-storage: usb_stor_clear_halt: result = 0
usb-storage: Bulk data transfer result 0x2
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 0x2d R 8 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: -- unexpectedly short transfer
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x2e L 18 F 128 Trg 0 LUN 1 CL 6
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 18 bytes, 1 entries
usb-storage: Status code -75; transferred 0/18
usb-storage: -- babble
usb-storage: Bulk data transfer result 0x3
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code -75; transferred 0/13
usb-storage: -- babble
usb-storage: Bulk status result = 3
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x2f L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x2f R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x30 L 18 F 128 Trg 0 LUN 0 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command READ_CAPACITY (10 bytes)
usb-storage:  25 00 00 00 00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x31 L 8 F 128 Trg 0 LUN 1 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 8 bytes, 1 entries
usb-storage: Status code -32; transferred 0/8
usb-storage: clearing endpoint halt for pipe 0xc0008280
usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=81 len=0
usb-storage: usb_stor_clear_halt: result = 0
usb-storage: Bulk data transfer result 0x2
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 0x31 R 8 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: -- unexpectedly short transfer
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x32 L 18 F 128 Trg 0 LUN 1 CL 6
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 18 bytes, 1 entries
usb-storage: Status code -75; transferred 0/18
usb-storage: -- babble
usb-storage: Bulk data transfer result 0x3
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code -75; transferred 0/13
usb-storage: -- babble
usb-storage: Bulk status result = 3
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x33 L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x33 R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x34 L 18 F 128 Trg 0 LUN 0 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command READ_CAPACITY (10 bytes)
usb-storage:  25 00 00 00 00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x35 L 8 F 128 Trg 0 LUN 1 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 8 bytes, 1 entries
usb-storage: Status code -32; transferred 0/8
usb-storage: clearing endpoint halt for pipe 0xc0008280
usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=81 len=0
usb-storage: usb_stor_clear_halt: result = 0
usb-storage: Bulk data transfer result 0x2
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 0x35 R 8 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: -- unexpectedly short transfer
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x36 L 18 F 128 Trg 0 LUN 1 CL 6
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 18 bytes, 1 entries
usb-storage: Status code -75; transferred 0/18
usb-storage: -- babble
usb-storage: Bulk data transfer result 0x3
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code -75; transferred 0/13
usb-storage: -- babble
usb-storage: Bulk status result = 3
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x37 L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x37 R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x38 L 18 F 128 Trg 0 LUN 0 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command READ_CAPACITY (10 bytes)
usb-storage:  25 00 00 00 00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x39 L 8 F 128 Trg 0 LUN 1 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 8 bytes, 1 entries
usb-storage: Status code -32; transferred 0/8
usb-storage: clearing endpoint halt for pipe 0xc0008280
usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=81 len=0
usb-storage: usb_stor_clear_halt: result = 0
usb-storage: Bulk data transfer result 0x2
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 0x39 R 8 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: -- unexpectedly short transfer
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x3a L 18 F 128 Trg 0 LUN 1 CL 6
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 18 bytes, 1 entries
usb-storage: Status code -75; transferred 0/18
usb-storage: -- babble
usb-storage: Bulk data transfer result 0x3
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code -75; transferred 0/13
usb-storage: -- babble
usb-storage: Bulk status result = 3
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x3b L 0 F 0 Trg 0 LUN 0 CL 6
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: 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 0x3b R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0x3c L 18 F 128 Trg 0 LUN 0 CL 6
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 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd 0000:00:1d.7: port 1 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
hub 5-0:1.0: state 7 ports 8 chg 0000 evt 0002
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd 0000:00:1d.7: devpath 1 ep0in 3strikes
ehci_hcd 0000:00:1d.7: devpath 1 ep0in 3strikes
ehci_hcd 0000:00:1d.7: devpath 1 ep0in 3strikes
ehci_hcd 0000:00:1d.7: devpath 1 ep0in 3strikes
ehci_hcd 0000:00:1d.7: devpath 1 ep0in 3strikes
ehci_hcd 0000:00:1d.7: devpath 1 ep0in 3strikes
ehci_hcd 0000:00:1d.7: devpath 1 ep0in 3strikes
ehci_hcd 0000:00:1d.7: devpath 1 ep0in 3strikes
ehci_hcd 0000:00:1d.7: devpath 1 ep0in 3strikes
ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001002 POWER sig=se0 CSC
hub 5-0:1.0: logical disconnect on port 1
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns -19
usb-storage: usb_stor_Bulk_reset called
usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value=0000 index=00 len=0
usb-storage: Soft reset failed: -19
usb-storage: scsi cmd done, result=0x70000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
hub 5-0:1.0: state 7 ports 8 chg 0002 evt 0002
hub 5-0:1.0: port 1, status 0100, change 0000, 12 Mb/s
usb 5-1: USB disconnect, address 2
usb 5-1: unregistering device
usb 5-1: usb_disable_device nuking all URBs
usb 5-1: unregistering interface 5-1:1.0
usb-storage: storage_disconnect() called
usb-storage: usb_stor_stop_transport called
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
sd 6:0:0:1: [sdc] READ CAPACITY failed
sd 6:0:0:1: [sdc] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
sd 6:0:0:1: [sdc] Sense not available.
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
sd 6:0:0:1: [sdc] Write Protect is off
sd 6:0:0:1: [sdc] Mode Sense: 00 00 00 00
sd 6:0:0:1: [sdc] Assuming drive cache: write through
sd 6:0:0:1: [sdc] Attached SCSI removable disk
sd 6:0:0:1: Attached scsi generic sg2 type 0
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
sd 6:0:0:0: [sdb] READ CAPACITY failed
sd 6:0:0:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
sd 6:0:0:0: [sdb] Sense not available.
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: *** thread awakened.
usb-storage: -- exiting
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
sd 6:0:0:0: [sdb] Write Protect is off
sd 6:0:0:0: [sdb] Mode Sense: 00 00 00 00
sd 6:0:0:0: [sdb] Assuming drive cache: write through
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: queuecommand called
usb-storage: Fail command during disconnect
usb-storage: device scan complete
usb-storage: -- usb_stor_release_resources
usb-storage: -- sending exit command to thread
scsi 6:0:0:0: [sdb] READ CAPACITY failed
scsi 6:0:0:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
scsi 6:0:0:0: [sdb] Sense not available.
scsi 6:0:0:0: rejecting I/O to dead device
scsi 6:0:0:0: [sdb] Write Protect is off
scsi 6:0:0:0: [sdb] Mode Sense: 00 00 00 00
scsi 6:0:0:0: [sdb] Assuming drive cache: write through
scsi 6:0:0:0: rejecting I/O to dead device
usb-storage: -- dissociate_dev
usb 5-1:1.0: uevent
usb 5-1: uevent
hub 5-0:1.0: hub_suspend
usb usb5: bus auto-suspend
ehci_hcd 0000:00:1d.7: suspend root hub

-- 
Jens Axboe

Re: [BUG] 2.6.24-git usb reset problems

[James Bottomley]

On Tue, 2008-01-29 at 20:27 +0200, Boaz Harrosh wrote:
> On Tue, Jan 29 2008 at 18:34 +0200, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > On Tue, 2008-01-29 at 10:36 -0500, Alan Stern wrote:
> >> On Tue, 29 Jan 2008, Boaz Harrosh wrote:
> >>
> >>> --- a/drivers/usb/storage/transport.c
> >>> +++ b/drivers/usb/storage/transport.c
> >>> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe,
> >>>   * Common used function. Transfer a complete command
> >>>   * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
> >>>   */
> >>> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> >>> -		      struct scsi_cmnd* srb)
> >>> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
> >>> +		      struct scsi_cmnd* srb, unsigned length)
> >>>  {
> >>>  	unsigned int partial;
> >>>  	int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> >>> -				      scsi_sg_count(srb), scsi_bufflen(srb),
> >>> +				      scsi_sg_count(srb), length,
> >>>  				      &partial);
> >>>  
> >>>  	scsi_set_resid(srb, scsi_bufflen(srb) - partial);
> >>>  	return result;
> >>>  }
> >>>  
> >>> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> >>> +		struct scsi_cmnd* srb)
> >>> +{
> >>> +	return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
> >>> +}
> >>> +
> >> I don't like this patch very much.  Why add another layer of 
> >> indirection when the two subroutines do hardly any work?  Leave 
> >> usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length() 
> >> as a separate routine that simply calls usb_stor_bulk_transfer_sglist() 
> >> and scsi_set_resid().
> >>
> >> BTW, the standard coding style calls for a blank line after the list of 
> >> local variables at the start of a function or block.
> > 
> > There's another bug in the transport.c conversion in that the residuals
> > are updated with bogus data in several error cases, since
> > usb_stor_bulk_transfer_sglist() only sets the actual length if the urb
> > is actually sent.
> > 
> > I'm not sure if this is is the solution to the problem at hand, but it
> > definitely fixes another bug in the code.
> > 
> > James
> > 
> > diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
> > index d9f4912..bab0858 100644
> > --- a/drivers/usb/storage/transport.c
> > +++ b/drivers/usb/storage/transport.c
> > @@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe,
> >  int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> >  		      struct scsi_cmnd* srb)
> >  {
> > -	unsigned int partial;
> > +	unsigned int partial = scsi_get_resid(srb);
> >  	int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> >  				      scsi_sg_count(srb), scsi_bufflen(srb),
> >  				      &partial);
> > 
> > 
> > -
> But then this is weird because it is not what usb_stor_bulk_transfer_sg() is doing
> which was the one called before.

Um, yes it was.  The original code did this

sb_stor_bulk_transfer_sg(..., &srp->resid, ...)

Which was at liberty not to touch resid, which it chose not to do in the
error legs.

Your new code does

int partial; <- stack uninitialised
sb_stor_bulk_transfer_sglist(..., &partial, ...);
scsi_set_resid(srb, scsi_bufflen(srb) - partial);

If the function doesn't touch partial, as it doesn't in the error legs,
resid now gets set with rubbish.

Actually, my code is still wrong .. we have to set it to
scsi_bufflen(srb) - scsi_resid(srb) so that it comes back the same if
left untouched.

> I have such a device and I get one reset but then every thing works nice.
> This is with debug on. I'll try to make it fail.

James

Re: [BUG] 2.6.24-git usb reset problems

[Boaz Harrosh]

On Tue, Jan 29 2008 at 20:48 +0200, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> On Tue, 2008-01-29 at 20:27 +0200, Boaz Harrosh wrote:
>> On Tue, Jan 29 2008 at 18:34 +0200, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>>> On Tue, 2008-01-29 at 10:36 -0500, Alan Stern wrote:
>>>> On Tue, 29 Jan 2008, Boaz Harrosh wrote:
>>>>
>>>>> --- a/drivers/usb/storage/transport.c
>>>>> +++ b/drivers/usb/storage/transport.c
>>>>> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe,
>>>>>   * Common used function. Transfer a complete command
>>>>>   * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
>>>>>   */
>>>>> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>>>>> -		      struct scsi_cmnd* srb)
>>>>> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
>>>>> +		      struct scsi_cmnd* srb, unsigned length)
>>>>>  {
>>>>>  	unsigned int partial;
>>>>>  	int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
>>>>> -				      scsi_sg_count(srb), scsi_bufflen(srb),
>>>>> +				      scsi_sg_count(srb), length,
>>>>>  				      &partial);
>>>>>  
>>>>>  	scsi_set_resid(srb, scsi_bufflen(srb) - partial);
>>>>>  	return result;
>>>>>  }
>>>>>  
>>>>> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>>>>> +		struct scsi_cmnd* srb)
>>>>> +{
>>>>> +	return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
>>>>> +}
>>>>> +
>>>> I don't like this patch very much.  Why add another layer of 
>>>> indirection when the two subroutines do hardly any work?  Leave 
>>>> usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length() 
>>>> as a separate routine that simply calls usb_stor_bulk_transfer_sglist() 
>>>> and scsi_set_resid().
>>>>
>>>> BTW, the standard coding style calls for a blank line after the list of 
>>>> local variables at the start of a function or block.
>>> There's another bug in the transport.c conversion in that the residuals
>>> are updated with bogus data in several error cases, since
>>> usb_stor_bulk_transfer_sglist() only sets the actual length if the urb
>>> is actually sent.
>>>
>>> I'm not sure if this is is the solution to the problem at hand, but it
>>> definitely fixes another bug in the code.
>>>
>>> James
>>>
>>> diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
>>> index d9f4912..bab0858 100644
>>> --- a/drivers/usb/storage/transport.c
>>> +++ b/drivers/usb/storage/transport.c
>>> @@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe,
>>>  int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>>>  		      struct scsi_cmnd* srb)
>>>  {
>>> -	unsigned int partial;
>>> +	unsigned int partial = scsi_get_resid(srb);
>>>  	int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
>>>  				      scsi_sg_count(srb), scsi_bufflen(srb),
>>>  				      &partial);
>>>
>>>
>>> -
>> But then this is weird because it is not what usb_stor_bulk_transfer_sg() is doing
>> which was the one called before.
> 
> Um, yes it was.  The original code did this
> 
> sb_stor_bulk_transfer_sg(..., &srp->resid, ...)
> 
> Which was at liberty not to touch resid, which it chose not to do in the
> error legs.
> 
> Your new code does
> 
> int partial; <- stack uninitialised
> sb_stor_bulk_transfer_sglist(..., &partial, ...);
> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
> 
> If the function doesn't touch partial, as it doesn't in the error legs,
> resid now gets set with rubbish.
> 
> Actually, my code is still wrong .. we have to set it to
> scsi_bufflen(srb) - scsi_resid(srb) so that it comes back the same if
> left untouched.
> 
>> I have such a device and I get one reset but then every thing works nice.
>> This is with debug on. I'll try to make it fail.
> 
> James
> 
> 
Sorry I still don't see it.

original code did sb_stor_bulk_transfer_sg(..., &srp->resid, ...)

but sb_stor_bulk_transfer_sg does the:
 int partial; <- stack uninitialised
 sb_stor_bulk_transfer_sglist(..., &partial, ...);

and then unconditionally sets *residual = length_left;
I do not see an "error legs" case in sb_stor_bulk_transfer_sg().

I have just cut and pasted the !use_sg from sb_stor_bulk_transfer_sg names
and all

Boaz
  

Re: [BUG] 2.6.24-git usb reset problems

[Boaz Harrosh]

On Tue, Jan 29 2008 at 20:39 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> On Tue, Jan 29 2008, Jens Axboe wrote:
>> On Tue, Jan 29 2008, Oliver Neukum wrote:
>>> Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
>>>>> On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
>>>>>>> Greg KH wrote:
>>>  
>>>>>> No difference, still just a lot of resets.
>>>>>>
>>>>> Where you able to figure out which usb storage transport is used?
>>>>>
>>>>> in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
>>>>> functions. I'm not sure if these get stored in sysfs perhaps. This will
>>>>> pinpoint better where to look. Let me research a bit. 
>>>> Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
>>>> transport is 'Bulk'
>>> You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
>>> That should tell the reason for the resets.
>> Sure, I'll do that. Will post the results tonight.
> 
> OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
> in the device, waited 10 seconds or so and pulled it out. These are the
> messages.
> 
> It all looks good until the MODE_SENSE command, where it only transfers
> 4 of 192 bytes.
> 
<snip>
> usb-storage: Command MODE_SENSE (6 bytes)
> usb-storage:  1a 00 3f 00 c0 00
> usb-storage: Bulk Command S 0x43425355 T 0x4 L 192 F 128 Trg 0 LUN 0 CL 6
> 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 192 bytes, 1 entries
> usb-storage: Status code -121; transferred 4/192
> usb-storage: -- short read transfer
> usb-storage: Bulk data transfer result 0x1
> usb-storage: Attempting to get CSW...
<snip>

I get something similar but better:
usb-storage: Command MODE_SENSE (6 bytes)
usb-storage:  1a 00 3f 00 c0 00
usb-storage: Bulk Command S 0x43425355 T 0x6 L 192 F 128 Trg 0 LUN 0 CL 6
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 192 bytes, 1 entries
usb-storage: Status code -121; transferred 36/192
usb-storage: -- short read transfer
usb-storage: Bulk data transfer result 0x1
usb-storage: Attempting to get CSW...

So I get 36 bytes, then code goes on into one reset, and every thing is then
fine.

Could you put us out of our mesery and revert that patch:
[SCSI] usb: transport - convert to accessors and !use_sg code path removal
(6d416e6173394defda5933e419e805b696681b7e)

to make sure this is it. I hate to do this to you, but I cannot reproduce the
failure down here. If it works please send a log with the debugs on perhaps
we can compare.

You will need to configure out the CONFIG_USB_STORAG_* they will not compile
you should have only have CONFIG_USB_STORAGE & CONFIG_USB_STORAGE_DEBUG. it should
support your HW.


Thanks Jens
Boaz

Re: [BUG] 2.6.24-git usb reset problems

[Matthew Dharm]

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

On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote:
> On Tue, Jan 29 2008, Jens Axboe wrote:
> > On Tue, Jan 29 2008, Oliver Neukum wrote:
> > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
> > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > > >> Greg KH wrote:
> > >  
> > > > > > No difference, still just a lot of resets.
> > > > > > 
> > > > > Where you able to figure out which usb storage transport is used?
> > > > > 
> > > > > in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> > > > > functions. I'm not sure if these get stored in sysfs perhaps. This will
> > > > > pinpoint better where to look. Let me research a bit. 
> > > > 
> > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
> > > > transport is 'Bulk'
> > > 
> > > You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
> > > That should tell the reason for the resets.
> > 
> > Sure, I'll do that. Will post the results tonight.
> 
> OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
> in the device, waited 10 seconds or so and pulled it out. These are the
> messages.
> 
> It all looks good until the MODE_SENSE command, where it only transfers
> 4 of 192 bytes.

No, that's not the problem.  This is the problem:
 
> usb-storage: *** thread awakened.
> usb-storage: Command TEST_UNIT_READY (6 bytes)
> usb-storage:  00 00 00 00 00 00
> usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6
> 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: 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 0xd R 0 Stat 0x1
> usb-storage: -- transport indicates command failure
> usb-storage: Issuing auto-REQUEST_SENSE
> usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6
> 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 18 bytes, 1 entries
> usb-storage: usb_sg_init returned -22
> usb-storage: Bulk data transfer result 0x4
> usb-storage: -- auto-sense failure
> usb-storage: storage_pre_reset
> ehci_hcd 0000:00:1d.7: port 1 high speed
> ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> ehci_hcd 0000:00:1d.7: port 1 high speed
> ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> usb-storage: storage_post_reset
> usb-storage: usb_reset_composite_device returns 0
> usb-storage: scsi cmd done, result=0x70000
> usb-storage: *** thread sleeping.

For some reason, usb_sg_init is boned during auto-sense.

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

It was a new hope.
					-- Dust Puppy
User Friendly, 12/25/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Tue, Jan 29 2008, Matthew Dharm wrote:
> On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote:
> > On Tue, Jan 29 2008, Jens Axboe wrote:
> > > On Tue, Jan 29 2008, Oliver Neukum wrote:
> > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
> > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > > > >> Greg KH wrote:
> > > >  
> > > > > > > No difference, still just a lot of resets.
> > > > > > > 
> > > > > > Where you able to figure out which usb storage transport is used?
> > > > > > 
> > > > > > in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> > > > > > functions. I'm not sure if these get stored in sysfs perhaps. This will
> > > > > > pinpoint better where to look. Let me research a bit. 
> > > > > 
> > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
> > > > > transport is 'Bulk'
> > > > 
> > > > You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
> > > > That should tell the reason for the resets.
> > > 
> > > Sure, I'll do that. Will post the results tonight.
> > 
> > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
> > in the device, waited 10 seconds or so and pulled it out. These are the
> > messages.
> > 
> > It all looks good until the MODE_SENSE command, where it only transfers
> > 4 of 192 bytes.
> 
> No, that's not the problem.  This is the problem:

It's where the problem starts, otherwise there would not be a need to
sense :-)

> > usb-storage: *** thread awakened.
> > usb-storage: Command TEST_UNIT_READY (6 bytes)
> > usb-storage:  00 00 00 00 00 00
> > usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6
> > 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: 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 0xd R 0 Stat 0x1
> > usb-storage: -- transport indicates command failure
> > usb-storage: Issuing auto-REQUEST_SENSE
> > usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6
> > 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 18 bytes, 1 entries
> > usb-storage: usb_sg_init returned -22
> > usb-storage: Bulk data transfer result 0x4
> > usb-storage: -- auto-sense failure
> > usb-storage: storage_pre_reset
> > ehci_hcd 0000:00:1d.7: port 1 high speed
> > ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> > usb 5-1: reset high speed USB device using ehci_hcd and address 2
> > ehci_hcd 0000:00:1d.7: port 1 high speed
> > ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> > usb-storage: storage_post_reset
> > usb-storage: usb_reset_composite_device returns 0
> > usb-storage: scsi cmd done, result=0x70000
> > usb-storage: *** thread sleeping.
> 
> For some reason, usb_sg_init is boned during auto-sense.

My guess would be that sg == NULL, hence the -EINVAL.

-- 
Jens Axboe

Re: [BUG] 2.6.24-git usb reset problems

[James Bottomley]

On Tue, 2008-01-29 at 20:58 +0200, Boaz Harrosh wrote:
> > Your new code does
> > 
> > int partial; <- stack uninitialised
> > sb_stor_bulk_transfer_sglist(..., &partial, ...);
> > scsi_set_resid(srb, scsi_bufflen(srb) - partial);
> > 
> > If the function doesn't touch partial, as it doesn't in the error legs,
> > resid now gets set with rubbish.
> > 
> > Actually, my code is still wrong .. we have to set it to
> > scsi_bufflen(srb) - scsi_resid(srb) so that it comes back the same if
> > left untouched.
> > 
> >> I have such a device and I get one reset but then every thing works nice.
> >> This is with debug on. I'll try to make it fail.
> > 
> > James
> > 
> > 
> Sorry I still don't see it.
> 
> original code did sb_stor_bulk_transfer_sg(..., &srp->resid, ...)
> 
> but sb_stor_bulk_transfer_sg does the:
>  int partial; <- stack uninitialised
>  sb_stor_bulk_transfer_sglist(..., &partial, ...);
> 
> and then unconditionally sets *residual = length_left;
> I do not see an "error legs" case in sb_stor_bulk_transfer_sg().

This is really programming 101. This:

static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned
int pipe,
		struct scatterlist *sg, int num_sg, unsigned int length,
		unsigned int *act_len)
{
	int result;

	/* don't submit s-g requests during abort/disconnect processing */
	if (us->flags & ABORTING_OR_DISCONNECTING)
		return USB_STOR_XFER_ERROR;

The return USB_STOR_XFER_ERROR; is called an error leg.  It returns
without updating *act_len thus leaving &partial uninitialised.

James

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Tue, Jan 29 2008, Jens Axboe wrote:
> On Tue, Jan 29 2008, Matthew Dharm wrote:
> > On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote:
> > > On Tue, Jan 29 2008, Jens Axboe wrote:
> > > > On Tue, Jan 29 2008, Oliver Neukum wrote:
> > > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
> > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > > > > >> Greg KH wrote:
> > > > >  
> > > > > > > > No difference, still just a lot of resets.
> > > > > > > > 
> > > > > > > Where you able to figure out which usb storage transport is used?
> > > > > > > 
> > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> > > > > > > functions. I'm not sure if these get stored in sysfs perhaps. This will
> > > > > > > pinpoint better where to look. Let me research a bit. 
> > > > > > 
> > > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
> > > > > > transport is 'Bulk'
> > > > > 
> > > > > You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
> > > > > That should tell the reason for the resets.
> > > > 
> > > > Sure, I'll do that. Will post the results tonight.
> > > 
> > > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
> > > in the device, waited 10 seconds or so and pulled it out. These are the
> > > messages.
> > > 
> > > It all looks good until the MODE_SENSE command, where it only transfers
> > > 4 of 192 bytes.
> > 
> > No, that's not the problem.  This is the problem:
> 
> It's where the problem starts, otherwise there would not be a need to
> sense :-)
> 
> > > usb-storage: *** thread awakened.
> > > usb-storage: Command TEST_UNIT_READY (6 bytes)
> > > usb-storage:  00 00 00 00 00 00
> > > usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6
> > > 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: 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 0xd R 0 Stat 0x1
> > > usb-storage: -- transport indicates command failure
> > > usb-storage: Issuing auto-REQUEST_SENSE
> > > usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6
> > > 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 18 bytes, 1 entries
> > > usb-storage: usb_sg_init returned -22
> > > usb-storage: Bulk data transfer result 0x4
> > > usb-storage: -- auto-sense failure
> > > usb-storage: storage_pre_reset
> > > ehci_hcd 0000:00:1d.7: port 1 high speed
> > > ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> > > usb 5-1: reset high speed USB device using ehci_hcd and address 2
> > > ehci_hcd 0000:00:1d.7: port 1 high speed
> > > ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> > > usb-storage: storage_post_reset
> > > usb-storage: usb_reset_composite_device returns 0
> > > usb-storage: scsi cmd done, result=0x70000
> > > usb-storage: *** thread sleeping.
> > 
> > For some reason, usb_sg_init is boned during auto-sense.
> 
> My guess would be that sg == NULL, hence the -EINVAL.

Yep, trace below:

WARNING: at drivers/usb/storage/transport.c:426
usb_stor_bulk_transfer_sglist()
Pid: 12536, comm: usb-storage Not tainted 2.6.24 #74
 [<7810541a>] show_trace_log_lvl+0x1a/0x30
 [<78105e82>] show_trace+0x12/0x20
 [<7810689c>] dump_stack+0x6c/0x80
 [<f83e267e>] usb_stor_bulk_transfer_sglist+0x14e/0x160 [usb_storage]
 [<f83e2730>] usb_stor_bulk_srb_length+0x30/0x50 [usb_storage]
 [<f83e2762>] usb_stor_bulk_srb+0x12/0x20 [usb_storage]
 [<f83e2ce0>] usb_stor_Bulk_transport+0x190/0x3d0 [usb_storage]
 [<f83e30d6>] usb_stor_invoke_transport+0x1b6/0x320 [usb_storage]
 [<f83e1a38>] usb_stor_transparent_scsi_command+0x8/0x10 [usb_storage]
 [<f83e3813>] usb_stor_control_thread+0x143/0x2c0 [usb_storage]
 [<7813bc02>] kthread+0x42/0x70
 [<78104fab>] kernel_thread_helper+0x7/0x1c
 =======================
usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries, sg
00000000
usb-storage: usb_sg_init returned -22

-- 
Jens Axboe

Re: [BUG] 2.6.24-git usb reset problems

[Boaz Harrosh]

On Tue, Jan 29 2008 at 21:17 +0200, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> On Tue, 2008-01-29 at 20:58 +0200, Boaz Harrosh wrote:
>>> Your new code does
>>>
>>> int partial; <- stack uninitialised
>>> sb_stor_bulk_transfer_sglist(..., &partial, ...);
>>> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
>>>
>>> If the function doesn't touch partial, as it doesn't in the error legs,
>>> resid now gets set with rubbish.
>>>
>>> Actually, my code is still wrong .. we have to set it to
>>> scsi_bufflen(srb) - scsi_resid(srb) so that it comes back the same if
>>> left untouched.
>>>
>>>> I have such a device and I get one reset but then every thing works nice.
>>>> This is with debug on. I'll try to make it fail.
>>> James
>>>
>>>
>> Sorry I still don't see it.
>>
>> original code did sb_stor_bulk_transfer_sg(..., &srp->resid, ...)
>>
>> but sb_stor_bulk_transfer_sg does the:
>>  int partial; <- stack uninitialised
>>  sb_stor_bulk_transfer_sglist(..., &partial, ...);
>>
>> and then unconditionally sets *residual = length_left;
>> I do not see an "error legs" case in sb_stor_bulk_transfer_sg().
> 
> This is really programming 101. This:
> 
> static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned
> int pipe,
> 		struct scatterlist *sg, int num_sg, unsigned int length,
> 		unsigned int *act_len)
> {
> 	int result;
> 
> 	/* don't submit s-g requests during abort/disconnect processing */
> 	if (us->flags & ABORTING_OR_DISCONNECTING)
> 		return USB_STOR_XFER_ERROR;
> 
> The return USB_STOR_XFER_ERROR; is called an error leg.  It returns
> without updating *act_len thus leaving &partial uninitialised.
> 
> James
> 
Yes you are right this is a bug, but it is a bug that was there before.
perhaps the stack is just different now then what it used to be.

Jens could you please try that:

diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index d9f4912..b18a5e6 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe,
 int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
 		      struct scsi_cmnd* srb)
 {
-	unsigned int partial;
+	unsigned int partial = 0;
 	int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
 				      scsi_sg_count(srb), scsi_bufflen(srb),
 				      &partial);

Re: [BUG] 2.6.24-git usb reset problems

[James Bottomley]

On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
> On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote:
> > On Tue, Jan 29 2008, Jens Axboe wrote:
> > > On Tue, Jan 29 2008, Oliver Neukum wrote:
> > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
> > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > > > >> Greg KH wrote:
> > > >  
> > > > > > > No difference, still just a lot of resets.
> > > > > > > 
> > > > > > Where you able to figure out which usb storage transport is used?
> > > > > > 
> > > > > > in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> > > > > > functions. I'm not sure if these get stored in sysfs perhaps. This will
> > > > > > pinpoint better where to look. Let me research a bit. 
> > > > > 
> > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
> > > > > transport is 'Bulk'
> > > > 
> > > > You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
> > > > That should tell the reason for the resets.
> > > 
> > > Sure, I'll do that. Will post the results tonight.
> > 
> > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
> > in the device, waited 10 seconds or so and pulled it out. These are the
> > messages.
> > 
> > It all looks good until the MODE_SENSE command, where it only transfers
> > 4 of 192 bytes.
> 
> No, that's not the problem.  This is the problem:
>  
> > usb-storage: *** thread awakened.
> > usb-storage: Command TEST_UNIT_READY (6 bytes)
> > usb-storage:  00 00 00 00 00 00
> > usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6
> > 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: 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 0xd R 0 Stat 0x1
> > usb-storage: -- transport indicates command failure
> > usb-storage: Issuing auto-REQUEST_SENSE
> > usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6
> > 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 18 bytes, 1 entries
> > usb-storage: usb_sg_init returned -22
> > usb-storage: Bulk data transfer result 0x4
> > usb-storage: -- auto-sense failure
> > usb-storage: storage_pre_reset
> > ehci_hcd 0000:00:1d.7: port 1 high speed
> > ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> > usb 5-1: reset high speed USB device using ehci_hcd and address 2
> > ehci_hcd 0000:00:1d.7: port 1 high speed
> > ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> > usb-storage: storage_post_reset
> > usb-storage: usb_reset_composite_device returns 0
> > usb-storage: scsi cmd done, result=0x70000
> > usb-storage: *** thread sleeping.
> 
> For some reason, usb_sg_init is boned during auto-sense.

OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
code ... that was also an update in 2.6.24

James

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Tue, Jan 29 2008, James Bottomley wrote:
> On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
> > On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote:
> > > On Tue, Jan 29 2008, Jens Axboe wrote:
> > > > On Tue, Jan 29 2008, Oliver Neukum wrote:
> > > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
> > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > > > > >> Greg KH wrote:
> > > > >  
> > > > > > > > No difference, still just a lot of resets.
> > > > > > > > 
> > > > > > > Where you able to figure out which usb storage transport is used?
> > > > > > > 
> > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> > > > > > > functions. I'm not sure if these get stored in sysfs perhaps. This will
> > > > > > > pinpoint better where to look. Let me research a bit. 
> > > > > > 
> > > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
> > > > > > transport is 'Bulk'
> > > > > 
> > > > > You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
> > > > > That should tell the reason for the resets.
> > > > 
> > > > Sure, I'll do that. Will post the results tonight.
> > > 
> > > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
> > > in the device, waited 10 seconds or so and pulled it out. These are the
> > > messages.
> > > 
> > > It all looks good until the MODE_SENSE command, where it only transfers
> > > 4 of 192 bytes.
> > 
> > No, that's not the problem.  This is the problem:
> >  
> > > usb-storage: *** thread awakened.
> > > usb-storage: Command TEST_UNIT_READY (6 bytes)
> > > usb-storage:  00 00 00 00 00 00
> > > usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6
> > > 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: 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 0xd R 0 Stat 0x1
> > > usb-storage: -- transport indicates command failure
> > > usb-storage: Issuing auto-REQUEST_SENSE
> > > usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6
> > > 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 18 bytes, 1 entries
> > > usb-storage: usb_sg_init returned -22
> > > usb-storage: Bulk data transfer result 0x4
> > > usb-storage: -- auto-sense failure
> > > usb-storage: storage_pre_reset
> > > ehci_hcd 0000:00:1d.7: port 1 high speed
> > > ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> > > usb 5-1: reset high speed USB device using ehci_hcd and address 2
> > > ehci_hcd 0000:00:1d.7: port 1 high speed
> > > ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> > > usb-storage: storage_post_reset
> > > usb-storage: usb_reset_composite_device returns 0
> > > usb-storage: scsi cmd done, result=0x70000
> > > usb-storage: *** thread sleeping.
> > 
> > For some reason, usb_sg_init is boned during auto-sense.
> 
> OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
> code ... that was also an update in 2.6.24

yeah, already found the bug - it's assuming ->request_buffer holds the
sglist, oops. Preparing a fix.

-- 
Jens Axboe

Re: [BUG] 2.6.24-git usb reset problems

[Matthew Dharm]

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

On Tue, Jan 29, 2008 at 08:15:04PM +0100, Jens Axboe wrote:
> On Tue, Jan 29 2008, Matthew Dharm wrote:
> > On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote:
> > > On Tue, Jan 29 2008, Jens Axboe wrote:
> > > > On Tue, Jan 29 2008, Oliver Neukum wrote:
> > > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
> > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > > > > >> Greg KH wrote:
> > > > >  
> > > > > > > > No difference, still just a lot of resets.
> > > > > > > > 
> > > > > > > Where you able to figure out which usb storage transport is used?
> > > > > > > 
> > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> > > > > > > functions. I'm not sure if these get stored in sysfs perhaps. This will
> > > > > > > pinpoint better where to look. Let me research a bit. 
> > > > > > 
> > > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
> > > > > > transport is 'Bulk'
> > > > > 
> > > > > You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
> > > > > That should tell the reason for the resets.
> > > > 
> > > > Sure, I'll do that. Will post the results tonight.
> > > 
> > > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
> > > in the device, waited 10 seconds or so and pulled it out. These are the
> > > messages.
> > > 
> > > It all looks good until the MODE_SENSE command, where it only transfers
> > > 4 of 192 bytes.
> > 
> > No, that's not the problem.  This is the problem:
> 
> It's where the problem starts, otherwise there would not be a need to
> sense :-)

MODE_SENSE has nothing to do with it.  A short MODE_SENSE response is
perfectly valid, and the log shows it was handled correctly and subsequent
commands worked just fine.  It's not until the TUR fails that we get the
problem.

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

P:  Nine more messages in admin.policy.
M: I know, I'm typing as fast as I can!
					-- Pitr and Mike
User Friendly, 11/27/97

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Tue, Jan 29 2008, Jens Axboe wrote:
> On Tue, Jan 29 2008, James Bottomley wrote:
> > On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
> > > On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote:
> > > > On Tue, Jan 29 2008, Jens Axboe wrote:
> > > > > On Tue, Jan 29 2008, Oliver Neukum wrote:
> > > > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
> > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > > > > > > >> Greg KH wrote:
> > > > > >  
> > > > > > > > > No difference, still just a lot of resets.
> > > > > > > > > 
> > > > > > > > Where you able to figure out which usb storage transport is used?
> > > > > > > > 
> > > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> > > > > > > > functions. I'm not sure if these get stored in sysfs perhaps. This will
> > > > > > > > pinpoint better where to look. Let me research a bit. 
> > > > > > > 
> > > > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
> > > > > > > transport is 'Bulk'
> > > > > > 
> > > > > > You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
> > > > > > That should tell the reason for the resets.
> > > > > 
> > > > > Sure, I'll do that. Will post the results tonight.
> > > > 
> > > > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
> > > > in the device, waited 10 seconds or so and pulled it out. These are the
> > > > messages.
> > > > 
> > > > It all looks good until the MODE_SENSE command, where it only transfers
> > > > 4 of 192 bytes.
> > > 
> > > No, that's not the problem.  This is the problem:
> > >  
> > > > usb-storage: *** thread awakened.
> > > > usb-storage: Command TEST_UNIT_READY (6 bytes)
> > > > usb-storage:  00 00 00 00 00 00
> > > > usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6
> > > > 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: 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 0xd R 0 Stat 0x1
> > > > usb-storage: -- transport indicates command failure
> > > > usb-storage: Issuing auto-REQUEST_SENSE
> > > > usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6
> > > > 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 18 bytes, 1 entries
> > > > usb-storage: usb_sg_init returned -22
> > > > usb-storage: Bulk data transfer result 0x4
> > > > usb-storage: -- auto-sense failure
> > > > usb-storage: storage_pre_reset
> > > > ehci_hcd 0000:00:1d.7: port 1 high speed
> > > > ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> > > > usb 5-1: reset high speed USB device using ehci_hcd and address 2
> > > > ehci_hcd 0000:00:1d.7: port 1 high speed
> > > > ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> > > > usb-storage: storage_post_reset
> > > > usb-storage: usb_reset_composite_device returns 0
> > > > usb-storage: scsi cmd done, result=0x70000
> > > > usb-storage: *** thread sleeping.
> > > 
> > > For some reason, usb_sg_init is boned during auto-sense.
> > 
> > OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
> > code ... that was also an update in 2.6.24
> 
> yeah, already found the bug - it's assuming ->request_buffer holds the
> sglist, oops. Preparing a fix.

ok here goes, this saves and restores the sg table correctly. it also
fixes the usb bug for me.

diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 547e85a..12770ef 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct scsi_eh_save *ses,
 	ses->use_sg = scmd->use_sg;
 	ses->resid = scmd->resid;
 	ses->result = scmd->result;
+	memcpy(&ses->sense_sgl, &scmd->sg_table, sizeof(ses->sense_sgl));
 
 	if (sense_bytes) {
 		scmd->request_bufflen = min_t(unsigned,
 		                       SCSI_SENSE_BUFFERSIZE, sense_bytes);
 		sg_init_one(&ses->sense_sgl, scmd->sense_buffer,
 		                                       scmd->request_bufflen);
-		scmd->request_buffer = &ses->sense_sgl;
+		scmd->sg_table.sgl = &ses->sense_sgl;
+		scmd->sg_table.nents = scmd->sg_table.orig_nents = 1;
 		scmd->sc_data_direction = DMA_FROM_DEVICE;
 		scmd->use_sg = 1;
 		memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
@@ -679,6 +681,7 @@ void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd, struct scsi_eh_save *ses)
 	scmd->request_bufflen = ses->bufflen;
 	scmd->request_buffer = ses->buffer;
 	scmd->use_sg = ses->use_sg;
+	memcpy(&scmd->sg_table, &ses->sg_table, sizeof(scmd->sg_table));
 	scmd->resid = ses->resid;
 	scmd->result = ses->result;
 }
diff --git a/include/scsi/scsi_eh.h b/include/scsi/scsi_eh.h
index d21b891..d43dc83 100644
--- a/include/scsi/scsi_eh.h
+++ b/include/scsi/scsi_eh.h
@@ -75,6 +75,7 @@ struct scsi_eh_save {
 
 	void *buffer;
 	unsigned bufflen;
+	struct sg_table sg_table;
 	unsigned short use_sg;
 	int resid;
 

-- 
Jens Axboe

Re: [BUG] 2.6.24-git usb reset problems

[Boaz Harrosh]

On Tue, Jan 29 2008 at 21:45 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> On Tue, Jan 29 2008, Jens Axboe wrote:
>> On Tue, Jan 29 2008, James Bottomley wrote:
>>> On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
>>>> On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote:
>>>>> On Tue, Jan 29 2008, Jens Axboe wrote:
>>>>>> On Tue, Jan 29 2008, Oliver Neukum wrote:
>>>>>>> Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
>>>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
>>>>>>>>> On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
>>>>>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
>>>>>>>>>>> Greg KH wrote:
>>>>>>>  
>>>>>>>>>> No difference, still just a lot of resets.
>>>>>>>>>>
>>>>>>>>> Where you able to figure out which usb storage transport is used?
>>>>>>>>>
>>>>>>>>> in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
>>>>>>>>> functions. I'm not sure if these get stored in sysfs perhaps. This will
>>>>>>>>> pinpoint better where to look. Let me research a bit. 
>>>>>>>> Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
>>>>>>>> transport is 'Bulk'
>>>>>>> You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
>>>>>>> That should tell the reason for the resets.
>>>>>> Sure, I'll do that. Will post the results tonight.
>>>>> OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
>>>>> in the device, waited 10 seconds or so and pulled it out. These are the
>>>>> messages.
>>>>>
>>>>> It all looks good until the MODE_SENSE command, where it only transfers
>>>>> 4 of 192 bytes.
>>>> No, that's not the problem.  This is the problem:
>>>>  
>>>>> usb-storage: *** thread awakened.
>>>>> usb-storage: Command TEST_UNIT_READY (6 bytes)
>>>>> usb-storage:  00 00 00 00 00 00
>>>>> usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6
>>>>> 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: 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 0xd R 0 Stat 0x1
>>>>> usb-storage: -- transport indicates command failure
>>>>> usb-storage: Issuing auto-REQUEST_SENSE
>>>>> usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6
>>>>> 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 18 bytes, 1 entries
>>>>> usb-storage: usb_sg_init returned -22
>>>>> usb-storage: Bulk data transfer result 0x4
>>>>> usb-storage: -- auto-sense failure
>>>>> usb-storage: storage_pre_reset
>>>>> ehci_hcd 0000:00:1d.7: port 1 high speed
>>>>> ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
>>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
>>>>> ehci_hcd 0000:00:1d.7: port 1 high speed
>>>>> ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
>>>>> usb-storage: storage_post_reset
>>>>> usb-storage: usb_reset_composite_device returns 0
>>>>> usb-storage: scsi cmd done, result=0x70000
>>>>> usb-storage: *** thread sleeping.
>>>> For some reason, usb_sg_init is boned during auto-sense.
>>> OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
>>> code ... that was also an update in 2.6.24
>> yeah, already found the bug - it's assuming ->request_buffer holds the
>> sglist, oops. Preparing a fix.
> 
> ok here goes, this saves and restores the sg table correctly. it also
> fixes the usb bug for me.
> 
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index 547e85a..12770ef 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct scsi_eh_save *ses,
>  	ses->use_sg = scmd->use_sg;
>  	ses->resid = scmd->resid;
>  	ses->result = scmd->result;
> +	memcpy(&ses->sense_sgl, &scmd->sg_table, sizeof(ses->sense_sgl));
>  
>  	if (sense_bytes) {
>  		scmd->request_bufflen = min_t(unsigned,
>  		                       SCSI_SENSE_BUFFERSIZE, sense_bytes);
>  		sg_init_one(&ses->sense_sgl, scmd->sense_buffer,
>  		                                       scmd->request_bufflen);
> -		scmd->request_buffer = &ses->sense_sgl;
> +		scmd->sg_table.sgl = &ses->sense_sgl;
> +		scmd->sg_table.nents = scmd->sg_table.orig_nents = 1;
>  		scmd->sc_data_direction = DMA_FROM_DEVICE;
>  		scmd->use_sg = 1;
>  		memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
> @@ -679,6 +681,7 @@ void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd, struct scsi_eh_save *ses)
>  	scmd->request_bufflen = ses->bufflen;
>  	scmd->request_buffer = ses->buffer;
>  	scmd->use_sg = ses->use_sg;
> +	memcpy(&scmd->sg_table, &ses->sg_table, sizeof(scmd->sg_table));
>  	scmd->resid = ses->resid;
>  	scmd->result = ses->result;
>  }
> diff --git a/include/scsi/scsi_eh.h b/include/scsi/scsi_eh.h
> index d21b891..d43dc83 100644
> --- a/include/scsi/scsi_eh.h
> +++ b/include/scsi/scsi_eh.h
> @@ -75,6 +75,7 @@ struct scsi_eh_save {
>  
>  	void *buffer;
>  	unsigned bufflen;
> +	struct sg_table sg_table;
>  	unsigned short use_sg;
>  	int resid;
>  
> 
Ok this is not in Linus tree is it? Hence I did not have that failure.

Boaz

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Tue, Jan 29 2008, Boaz Harrosh wrote:
> On Tue, Jan 29 2008 at 21:45 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > On Tue, Jan 29 2008, Jens Axboe wrote:
> >> On Tue, Jan 29 2008, James Bottomley wrote:
> >>> On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
> >>>> On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote:
> >>>>> On Tue, Jan 29 2008, Jens Axboe wrote:
> >>>>>> On Tue, Jan 29 2008, Oliver Neukum wrote:
> >>>>>>> Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
> >>>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
> >>>>>>>>> On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> >>>>>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
> >>>>>>>>>>> Greg KH wrote:
> >>>>>>>  
> >>>>>>>>>> No difference, still just a lot of resets.
> >>>>>>>>>>
> >>>>>>>>> Where you able to figure out which usb storage transport is used?
> >>>>>>>>>
> >>>>>>>>> in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> >>>>>>>>> functions. I'm not sure if these get stored in sysfs perhaps. This will
> >>>>>>>>> pinpoint better where to look. Let me research a bit. 
> >>>>>>>> Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
> >>>>>>>> transport is 'Bulk'
> >>>>>>> You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
> >>>>>>> That should tell the reason for the resets.
> >>>>>> Sure, I'll do that. Will post the results tonight.
> >>>>> OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
> >>>>> in the device, waited 10 seconds or so and pulled it out. These are the
> >>>>> messages.
> >>>>>
> >>>>> It all looks good until the MODE_SENSE command, where it only transfers
> >>>>> 4 of 192 bytes.
> >>>> No, that's not the problem.  This is the problem:
> >>>>  
> >>>>> usb-storage: *** thread awakened.
> >>>>> usb-storage: Command TEST_UNIT_READY (6 bytes)
> >>>>> usb-storage:  00 00 00 00 00 00
> >>>>> usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6
> >>>>> 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: 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 0xd R 0 Stat 0x1
> >>>>> usb-storage: -- transport indicates command failure
> >>>>> usb-storage: Issuing auto-REQUEST_SENSE
> >>>>> usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6
> >>>>> 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 18 bytes, 1 entries
> >>>>> usb-storage: usb_sg_init returned -22
> >>>>> usb-storage: Bulk data transfer result 0x4
> >>>>> usb-storage: -- auto-sense failure
> >>>>> usb-storage: storage_pre_reset
> >>>>> ehci_hcd 0000:00:1d.7: port 1 high speed
> >>>>> ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> >>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> >>>>> ehci_hcd 0000:00:1d.7: port 1 high speed
> >>>>> ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> >>>>> usb-storage: storage_post_reset
> >>>>> usb-storage: usb_reset_composite_device returns 0
> >>>>> usb-storage: scsi cmd done, result=0x70000
> >>>>> usb-storage: *** thread sleeping.
> >>>> For some reason, usb_sg_init is boned during auto-sense.
> >>> OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
> >>> code ... that was also an update in 2.6.24
> >> yeah, already found the bug - it's assuming ->request_buffer holds the
> >> sglist, oops. Preparing a fix.
> > 
> > ok here goes, this saves and restores the sg table correctly. it also
> > fixes the usb bug for me.
> > 
> > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> > index 547e85a..12770ef 100644
> > --- a/drivers/scsi/scsi_error.c
> > +++ b/drivers/scsi/scsi_error.c
> > @@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct scsi_eh_save *ses,
> >  	ses->use_sg = scmd->use_sg;
> >  	ses->resid = scmd->resid;
> >  	ses->result = scmd->result;
> > +	memcpy(&ses->sense_sgl, &scmd->sg_table, sizeof(ses->sense_sgl));
> >  
> >  	if (sense_bytes) {
> >  		scmd->request_bufflen = min_t(unsigned,
> >  		                       SCSI_SENSE_BUFFERSIZE, sense_bytes);
> >  		sg_init_one(&ses->sense_sgl, scmd->sense_buffer,
> >  		                                       scmd->request_bufflen);
> > -		scmd->request_buffer = &ses->sense_sgl;
> > +		scmd->sg_table.sgl = &ses->sense_sgl;
> > +		scmd->sg_table.nents = scmd->sg_table.orig_nents = 1;
> >  		scmd->sc_data_direction = DMA_FROM_DEVICE;
> >  		scmd->use_sg = 1;
> >  		memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
> > @@ -679,6 +681,7 @@ void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd, struct scsi_eh_save *ses)
> >  	scmd->request_bufflen = ses->bufflen;
> >  	scmd->request_buffer = ses->buffer;
> >  	scmd->use_sg = ses->use_sg;
> > +	memcpy(&scmd->sg_table, &ses->sg_table, sizeof(scmd->sg_table));
> >  	scmd->resid = ses->resid;
> >  	scmd->result = ses->result;
> >  }
> > diff --git a/include/scsi/scsi_eh.h b/include/scsi/scsi_eh.h
> > index d21b891..d43dc83 100644
> > --- a/include/scsi/scsi_eh.h
> > +++ b/include/scsi/scsi_eh.h
> > @@ -75,6 +75,7 @@ struct scsi_eh_save {
> >  
> >  	void *buffer;
> >  	unsigned bufflen;
> > +	struct sg_table sg_table;
> >  	unsigned short use_sg;
> >  	int resid;
> >  
> > 
> Ok this is not in Linus tree is it? Hence I did not have that failure.

Yes it is, it's in current -git! James, comments on the patch? Will you
push it or shall I?

-- 
Jens Axboe

Re: [BUG] 2.6.24-git usb reset problems

[James Bottomley]

On Tue, 2008-01-29 at 21:03 +0100, Jens Axboe wrote:
> On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > On Tue, Jan 29 2008 at 21:45 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > On Tue, Jan 29 2008, Jens Axboe wrote:
> > >> On Tue, Jan 29 2008, James Bottomley wrote:
> > >>> On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
> > >>>> On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote:
> > >>>>> On Tue, Jan 29 2008, Jens Axboe wrote:
> > >>>>>> On Tue, Jan 29 2008, Oliver Neukum wrote:
> > >>>>>>> Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
> > >>>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > >>>>>>>>> On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > >>>>>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > >>>>>>>>>>> Greg KH wrote:
> > >>>>>>>  
> > >>>>>>>>>> No difference, still just a lot of resets.
> > >>>>>>>>>>
> > >>>>>>>>> Where you able to figure out which usb storage transport is used?
> > >>>>>>>>>
> > >>>>>>>>> in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> > >>>>>>>>> functions. I'm not sure if these get stored in sysfs perhaps. This will
> > >>>>>>>>> pinpoint better where to look. Let me research a bit. 
> > >>>>>>>> Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
> > >>>>>>>> transport is 'Bulk'
> > >>>>>>> You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
> > >>>>>>> That should tell the reason for the resets.
> > >>>>>> Sure, I'll do that. Will post the results tonight.
> > >>>>> OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
> > >>>>> in the device, waited 10 seconds or so and pulled it out. These are the
> > >>>>> messages.
> > >>>>>
> > >>>>> It all looks good until the MODE_SENSE command, where it only transfers
> > >>>>> 4 of 192 bytes.
> > >>>> No, that's not the problem.  This is the problem:
> > >>>>  
> > >>>>> usb-storage: *** thread awakened.
> > >>>>> usb-storage: Command TEST_UNIT_READY (6 bytes)
> > >>>>> usb-storage:  00 00 00 00 00 00
> > >>>>> usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6
> > >>>>> 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: 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 0xd R 0 Stat 0x1
> > >>>>> usb-storage: -- transport indicates command failure
> > >>>>> usb-storage: Issuing auto-REQUEST_SENSE
> > >>>>> usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6
> > >>>>> 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 18 bytes, 1 entries
> > >>>>> usb-storage: usb_sg_init returned -22
> > >>>>> usb-storage: Bulk data transfer result 0x4
> > >>>>> usb-storage: -- auto-sense failure
> > >>>>> usb-storage: storage_pre_reset
> > >>>>> ehci_hcd 0000:00:1d.7: port 1 high speed
> > >>>>> ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> > >>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> > >>>>> ehci_hcd 0000:00:1d.7: port 1 high speed
> > >>>>> ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> > >>>>> usb-storage: storage_post_reset
> > >>>>> usb-storage: usb_reset_composite_device returns 0
> > >>>>> usb-storage: scsi cmd done, result=0x70000
> > >>>>> usb-storage: *** thread sleeping.
> > >>>> For some reason, usb_sg_init is boned during auto-sense.
> > >>> OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
> > >>> code ... that was also an update in 2.6.24
> > >> yeah, already found the bug - it's assuming ->request_buffer holds the
> > >> sglist, oops. Preparing a fix.
> > > 
> > > ok here goes, this saves and restores the sg table correctly. it also
> > > fixes the usb bug for me.
> > > 
> > > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> > > index 547e85a..12770ef 100644
> > > --- a/drivers/scsi/scsi_error.c
> > > +++ b/drivers/scsi/scsi_error.c
> > > @@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct scsi_eh_save *ses,
> > >  	ses->use_sg = scmd->use_sg;
> > >  	ses->resid = scmd->resid;
> > >  	ses->result = scmd->result;
> > > +	memcpy(&ses->sense_sgl, &scmd->sg_table, sizeof(ses->sense_sgl));
> > >  
> > >  	if (sense_bytes) {
> > >  		scmd->request_bufflen = min_t(unsigned,
> > >  		                       SCSI_SENSE_BUFFERSIZE, sense_bytes);
> > >  		sg_init_one(&ses->sense_sgl, scmd->sense_buffer,
> > >  		                                       scmd->request_bufflen);
> > > -		scmd->request_buffer = &ses->sense_sgl;
> > > +		scmd->sg_table.sgl = &ses->sense_sgl;
> > > +		scmd->sg_table.nents = scmd->sg_table.orig_nents = 1;
> > >  		scmd->sc_data_direction = DMA_FROM_DEVICE;
> > >  		scmd->use_sg = 1;
> > >  		memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
> > > @@ -679,6 +681,7 @@ void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd, struct scsi_eh_save *ses)
> > >  	scmd->request_bufflen = ses->bufflen;
> > >  	scmd->request_buffer = ses->buffer;
> > >  	scmd->use_sg = ses->use_sg;
> > > +	memcpy(&scmd->sg_table, &ses->sg_table, sizeof(scmd->sg_table));
> > >  	scmd->resid = ses->resid;
> > >  	scmd->result = ses->result;
> > >  }
> > > diff --git a/include/scsi/scsi_eh.h b/include/scsi/scsi_eh.h
> > > index d21b891..d43dc83 100644
> > > --- a/include/scsi/scsi_eh.h
> > > +++ b/include/scsi/scsi_eh.h
> > > @@ -75,6 +75,7 @@ struct scsi_eh_save {
> > >  
> > >  	void *buffer;
> > >  	unsigned bufflen;
> > > +	struct sg_table sg_table;
> > >  	unsigned short use_sg;
> > >  	int resid;
> > >  
> > > 
> > Ok this is not in Linus tree is it? Hence I did not have that failure.
> 
> Yes it is, it's in current -git! James, comments on the patch? Will you
> push it or shall I?

I will ... but it will cause an explosion in the bidirectional tree
again.  I think the bidi updates also fix this.  However, give me time
to rebase and verify.

James

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Tue, Jan 29 2008, James Bottomley wrote:
> On Tue, 2008-01-29 at 21:03 +0100, Jens Axboe wrote:
> > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > On Tue, Jan 29 2008 at 21:45 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > > On Tue, Jan 29 2008, Jens Axboe wrote:
> > > >> On Tue, Jan 29 2008, James Bottomley wrote:
> > > >>> On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
> > > >>>> On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote:
> > > >>>>> On Tue, Jan 29 2008, Jens Axboe wrote:
> > > >>>>>> On Tue, Jan 29 2008, Oliver Neukum wrote:
> > > >>>>>>> Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
> > > >>>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > >>>>>>>>> On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > >>>>>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > >>>>>>>>>>> Greg KH wrote:
> > > >>>>>>>  
> > > >>>>>>>>>> No difference, still just a lot of resets.
> > > >>>>>>>>>>
> > > >>>>>>>>> Where you able to figure out which usb storage transport is used?
> > > >>>>>>>>>
> > > >>>>>>>>> in drivers/usb/storage/usb.c you have get_protocol() and get_transport()
> > > >>>>>>>>> functions. I'm not sure if these get stored in sysfs perhaps. This will
> > > >>>>>>>>> pinpoint better where to look. Let me research a bit. 
> > > >>>>>>>> Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and
> > > >>>>>>>> transport is 'Bulk'
> > > >>>>>>> You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG
> > > >>>>>>> That should tell the reason for the resets.
> > > >>>>>> Sure, I'll do that. Will post the results tonight.
> > > >>>>> OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
> > > >>>>> in the device, waited 10 seconds or so and pulled it out. These are the
> > > >>>>> messages.
> > > >>>>>
> > > >>>>> It all looks good until the MODE_SENSE command, where it only transfers
> > > >>>>> 4 of 192 bytes.
> > > >>>> No, that's not the problem.  This is the problem:
> > > >>>>  
> > > >>>>> usb-storage: *** thread awakened.
> > > >>>>> usb-storage: Command TEST_UNIT_READY (6 bytes)
> > > >>>>> usb-storage:  00 00 00 00 00 00
> > > >>>>> usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6
> > > >>>>> 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: 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 0xd R 0 Stat 0x1
> > > >>>>> usb-storage: -- transport indicates command failure
> > > >>>>> usb-storage: Issuing auto-REQUEST_SENSE
> > > >>>>> usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6
> > > >>>>> 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 18 bytes, 1 entries
> > > >>>>> usb-storage: usb_sg_init returned -22
> > > >>>>> usb-storage: Bulk data transfer result 0x4
> > > >>>>> usb-storage: -- auto-sense failure
> > > >>>>> usb-storage: storage_pre_reset
> > > >>>>> ehci_hcd 0000:00:1d.7: port 1 high speed
> > > >>>>> ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> > > >>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2
> > > >>>>> ehci_hcd 0000:00:1d.7: port 1 high speed
> > > >>>>> ehci_hcd 0000:00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
> > > >>>>> usb-storage: storage_post_reset
> > > >>>>> usb-storage: usb_reset_composite_device returns 0
> > > >>>>> usb-storage: scsi cmd done, result=0x70000
> > > >>>>> usb-storage: *** thread sleeping.
> > > >>>> For some reason, usb_sg_init is boned during auto-sense.
> > > >>> OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
> > > >>> code ... that was also an update in 2.6.24
> > > >> yeah, already found the bug - it's assuming ->request_buffer holds the
> > > >> sglist, oops. Preparing a fix.
> > > > 
> > > > ok here goes, this saves and restores the sg table correctly. it also
> > > > fixes the usb bug for me.
> > > > 
> > > > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> > > > index 547e85a..12770ef 100644
> > > > --- a/drivers/scsi/scsi_error.c
> > > > +++ b/drivers/scsi/scsi_error.c
> > > > @@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct scsi_eh_save *ses,
> > > >  	ses->use_sg = scmd->use_sg;
> > > >  	ses->resid = scmd->resid;
> > > >  	ses->result = scmd->result;
> > > > +	memcpy(&ses->sense_sgl, &scmd->sg_table, sizeof(ses->sense_sgl));
> > > >  
> > > >  	if (sense_bytes) {
> > > >  		scmd->request_bufflen = min_t(unsigned,
> > > >  		                       SCSI_SENSE_BUFFERSIZE, sense_bytes);
> > > >  		sg_init_one(&ses->sense_sgl, scmd->sense_buffer,
> > > >  		                                       scmd->request_bufflen);
> > > > -		scmd->request_buffer = &ses->sense_sgl;
> > > > +		scmd->sg_table.sgl = &ses->sense_sgl;
> > > > +		scmd->sg_table.nents = scmd->sg_table.orig_nents = 1;
> > > >  		scmd->sc_data_direction = DMA_FROM_DEVICE;
> > > >  		scmd->use_sg = 1;
> > > >  		memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
> > > > @@ -679,6 +681,7 @@ void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd, struct scsi_eh_save *ses)
> > > >  	scmd->request_bufflen = ses->bufflen;
> > > >  	scmd->request_buffer = ses->buffer;
> > > >  	scmd->use_sg = ses->use_sg;
> > > > +	memcpy(&scmd->sg_table, &ses->sg_table, sizeof(scmd->sg_table));
> > > >  	scmd->resid = ses->resid;
> > > >  	scmd->result = ses->result;
> > > >  }
> > > > diff --git a/include/scsi/scsi_eh.h b/include/scsi/scsi_eh.h
> > > > index d21b891..d43dc83 100644
> > > > --- a/include/scsi/scsi_eh.h
> > > > +++ b/include/scsi/scsi_eh.h
> > > > @@ -75,6 +75,7 @@ struct scsi_eh_save {
> > > >  
> > > >  	void *buffer;
> > > >  	unsigned bufflen;
> > > > +	struct sg_table sg_table;
> > > >  	unsigned short use_sg;
> > > >  	int resid;
> > > >  
> > > > 
> > > Ok this is not in Linus tree is it? Hence I did not have that failure.
> > 
> > Yes it is, it's in current -git! James, comments on the patch? Will you
> > push it or shall I?
> 
> I will ... but it will cause an explosion in the bidirectional tree
> again.  I think the bidi updates also fix this.  However, give me time
> to rebase and verify.

OK thanks, just wanted to make sure that we didn't both expect each
other to handle it :-)

-- 
Jens Axboe

Re: [BUG] 2.6.24-git usb reset problems

[Boaz Harrosh]

>>
> Ok this is not in Linus tree is it? Hence I did not have that failure.
> 
> Boaz
> 
> 

actually James bidi tree has a fix for this in the scsi_data_buffer patch.

what you sent is not enough there are other places. look at this patch I
sent to the list.

http://www.spinics.net/lists/linux-scsi/msg21938.html

Could we take the 2 SG patches and submit them through the scsi
bidi tree? It is much more natural to have them in one tree as one
patchset then try coordinate with git-merge. Actually if you look at it,
the biggest change is to SCSI. So I think it is more natural this way

Boaz

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Tue, Jan 29 2008, Boaz Harrosh wrote:
> >>
> > Ok this is not in Linus tree is it? Hence I did not have that failure.
> > 
> > Boaz
> > 
> > 
> 
> actually James bidi tree has a fix for this in the scsi_data_buffer patch.
> 
> what you sent is not enough there are other places. look at this patch I
> sent to the list.
> 
> http://www.spinics.net/lists/linux-scsi/msg21938.html

Hard to compare, since its on different bases.

> Could we take the 2 SG patches and submit them through the scsi
> bidi tree? It is much more natural to have them in one tree as one
> patchset then try coordinate with git-merge. Actually if you look at it,
> the biggest change is to SCSI. So I think it is more natural this way

What 2 sg patches do you mean?

-- 
Jens Axboe

Re: [BUG] 2.6.24-git usb reset problems

[James Bottomley]

On Tue, 2008-01-29 at 21:06 +0100, Jens Axboe wrote:
> > I will ... but it will cause an explosion in the bidirectional tree
> > again.  I think the bidi updates also fix this.  However, give me time
> > to rebase and verify.
> 
> OK thanks, just wanted to make sure that we didn't both expect each
> other to handle it :-)

Yes, confirm that; I think this is already fixed in scsi-misc-2.6.
Could you pull from

master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git

and verify with your device?

Thanks,

James

Re: [BUG] 2.6.24-git usb reset problems

[Boaz Harrosh]

On Tue, Jan 29 2008 at 22:13 +0200, Jens Axboe <jens.axboe@oracle.com> wrote:
> On Tue, Jan 29 2008, Boaz Harrosh wrote:
>>> Ok this is not in Linus tree is it? Hence I did not have that failure.
>>>
>>> Boaz
>>>
>>>
>> actually James bidi tree has a fix for this in the scsi_data_buffer patch.
>>
>> what you sent is not enough there are other places. look at this patch I
>> sent to the list.
>>
>> http://www.spinics.net/lists/linux-scsi/msg21938.html
> 
> Hard to compare, since its on different bases.
Yes in this patchset I have taken your sg branch at the time, and
rebased it ontop of scsi_data_buffer patch. Because I felt that
it is more natural for this patch to come after the scsi total
cleanup that is scsi_data_buffer. Then the extraction to sg_table
is simple and trivial.

What I meant to point out with this patch is that all the exact same
places that are touched there should be fixed when moving to sg_table.

Look at it. It is a revised version of your patch.

> 
>> Could we take the 2 SG patches and submit them through the scsi
>> bidi tree? It is much more natural to have them in one tree as one
>> patchset then try coordinate with git-merge. Actually if you look at it,
>> the biggest change is to SCSI. So I think it is more natural this way
> 
> What 2 sg patches do you mean?
> 

I mean the patches that where in sg branch of the linux-block tree, But
I see that it is now to late, and that they are in Linus already

James the most simple is to submit the scsi_data_buff patch that fixes
all these places. If not do you want that I send in fixes?

Boaz

Re: [BUG] 2.6.24-git usb reset problems

[Boaz Harrosh]

On Tue, Jan 29 2008 at 22:24 +0200, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> On Tue, 2008-01-29 at 21:06 +0100, Jens Axboe wrote:
>>> I will ... but it will cause an explosion in the bidirectional tree
>>> again.  I think the bidi updates also fix this.  However, give me time
>>> to rebase and verify.
>> OK thanks, just wanted to make sure that we didn't both expect each
>> other to handle it :-)
> 
> Yes, confirm that; I think this is already fixed in scsi-misc-2.6.
> Could you pull from
> 
> master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
> 
> and verify with your device?
> 
> Thanks,
> 
> James
> 
> 
I still don't see these changes, I wanted to check, make sure...
Are there mirrors on the way to here?

James I would like to remind you that one small piece is missing 
from the bidi tree, as I saw it from here, it's the few patches from
scsi-pending. Mainly arm will break which is a grate loss.

I'm going home now, I'll review all the patches tomorrow and compare
to what I have, to make sure nothing was forgotten. What a waste of a day
I pulled from Linus this morning apparently minutes before the merge, and
chased a none existent bug in my tree. Sigh

Bye
Boaz

Re: [BUG] 2.6.24-git usb reset problems

[Geert Uytterhoeven]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2963 bytes --]

On Tue, 29 Jan 2008, Jens Axboe wrote:
> On Tue, Jan 29 2008, Jens Axboe wrote:
> > On Tue, Jan 29 2008, James Bottomley wrote:
> > > On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
> > > > For some reason, usb_sg_init is boned during auto-sense.
> > > 
> > > OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
> > > code ... that was also an update in 2.6.24
> > 
> > yeah, already found the bug - it's assuming ->request_buffer holds the
> > sglist, oops. Preparing a fix.
> 
> ok here goes, this saves and restores the sg table correctly. it also
> fixes the usb bug for me.

I can confirm this patch fixes the errors I was seeing with current
linux-2.6.git for the USB memory card readers in a Dell TFT connected to a PS3.

> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index 547e85a..12770ef 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct scsi_eh_save *ses,
>  	ses->use_sg = scmd->use_sg;
>  	ses->resid = scmd->resid;
>  	ses->result = scmd->result;
> +	memcpy(&ses->sense_sgl, &scmd->sg_table, sizeof(ses->sense_sgl));
>  
>  	if (sense_bytes) {
>  		scmd->request_bufflen = min_t(unsigned,
>  		                       SCSI_SENSE_BUFFERSIZE, sense_bytes);
>  		sg_init_one(&ses->sense_sgl, scmd->sense_buffer,
>  		                                       scmd->request_bufflen);
> -		scmd->request_buffer = &ses->sense_sgl;
> +		scmd->sg_table.sgl = &ses->sense_sgl;
> +		scmd->sg_table.nents = scmd->sg_table.orig_nents = 1;
>  		scmd->sc_data_direction = DMA_FROM_DEVICE;
>  		scmd->use_sg = 1;
>  		memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
> @@ -679,6 +681,7 @@ void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd, struct scsi_eh_save *ses)
>  	scmd->request_bufflen = ses->bufflen;
>  	scmd->request_buffer = ses->buffer;
>  	scmd->use_sg = ses->use_sg;
> +	memcpy(&scmd->sg_table, &ses->sg_table, sizeof(scmd->sg_table));
>  	scmd->resid = ses->resid;
>  	scmd->result = ses->result;
>  }
> diff --git a/include/scsi/scsi_eh.h b/include/scsi/scsi_eh.h
> index d21b891..d43dc83 100644
> --- a/include/scsi/scsi_eh.h
> +++ b/include/scsi/scsi_eh.h
> @@ -75,6 +75,7 @@ struct scsi_eh_save {
>  
>  	void *buffer;
>  	unsigned bufflen;
> +	struct sg_table sg_table;
>  	unsigned short use_sg;
>  	int resid;
>  

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Wed, Jan 30 2008, Geert Uytterhoeven wrote:
> On Tue, 29 Jan 2008, Jens Axboe wrote:
> > On Tue, Jan 29 2008, Jens Axboe wrote:
> > > On Tue, Jan 29 2008, James Bottomley wrote:
> > > > On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
> > > > > For some reason, usb_sg_init is boned during auto-sense.
> > > > 
> > > > OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
> > > > code ... that was also an update in 2.6.24
> > > 
> > > yeah, already found the bug - it's assuming ->request_buffer holds the
> > > sglist, oops. Preparing a fix.
> > 
> > ok here goes, this saves and restores the sg table correctly. it also
> > fixes the usb bug for me.
> 
> I can confirm this patch fixes the errors I was seeing with current
> linux-2.6.git for the USB memory card readers in a Dell TFT connected
> to a PS3.

James, we need a fix for this pushed asap. So either we should merge the
below now, or push the bidi patchset that also fixes this. It all
depends on when you want to merge the bidi patches...

> > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> > index 547e85a..12770ef 100644
> > --- a/drivers/scsi/scsi_error.c
> > +++ b/drivers/scsi/scsi_error.c
> > @@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct scsi_eh_save *ses,
> >  	ses->use_sg = scmd->use_sg;
> >  	ses->resid = scmd->resid;
> >  	ses->result = scmd->result;
> > +	memcpy(&ses->sense_sgl, &scmd->sg_table, sizeof(ses->sense_sgl));
> >  
> >  	if (sense_bytes) {
> >  		scmd->request_bufflen = min_t(unsigned,
> >  		                       SCSI_SENSE_BUFFERSIZE, sense_bytes);
> >  		sg_init_one(&ses->sense_sgl, scmd->sense_buffer,
> >  		                                       scmd->request_bufflen);
> > -		scmd->request_buffer = &ses->sense_sgl;
> > +		scmd->sg_table.sgl = &ses->sense_sgl;
> > +		scmd->sg_table.nents = scmd->sg_table.orig_nents = 1;
> >  		scmd->sc_data_direction = DMA_FROM_DEVICE;
> >  		scmd->use_sg = 1;
> >  		memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
> > @@ -679,6 +681,7 @@ void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd, struct scsi_eh_save *ses)
> >  	scmd->request_bufflen = ses->bufflen;
> >  	scmd->request_buffer = ses->buffer;
> >  	scmd->use_sg = ses->use_sg;
> > +	memcpy(&scmd->sg_table, &ses->sg_table, sizeof(scmd->sg_table));
> >  	scmd->resid = ses->resid;
> >  	scmd->result = ses->result;
> >  }
> > diff --git a/include/scsi/scsi_eh.h b/include/scsi/scsi_eh.h
> > index d21b891..d43dc83 100644
> > --- a/include/scsi/scsi_eh.h
> > +++ b/include/scsi/scsi_eh.h
> > @@ -75,6 +75,7 @@ struct scsi_eh_save {
> >  
> >  	void *buffer;
> >  	unsigned bufflen;
> > +	struct sg_table sg_table;
> >  	unsigned short use_sg;
> >  	int resid;
> >  

-- 
Jens Axboe

Re: [BUG] 2.6.24-git usb reset problems

[James Bottomley]

On Wed, 2008-01-30 at 11:38 +0100, Jens Axboe wrote:
> On Wed, Jan 30 2008, Geert Uytterhoeven wrote:
> > On Tue, 29 Jan 2008, Jens Axboe wrote:
> > > On Tue, Jan 29 2008, Jens Axboe wrote:
> > > > On Tue, Jan 29 2008, James Bottomley wrote:
> > > > > On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
> > > > > > For some reason, usb_sg_init is boned during auto-sense.
> > > > > 
> > > > > OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
> > > > > code ... that was also an update in 2.6.24
> > > > 
> > > > yeah, already found the bug - it's assuming ->request_buffer holds the
> > > > sglist, oops. Preparing a fix.
> > > 
> > > ok here goes, this saves and restores the sg table correctly. it also
> > > fixes the usb bug for me.
> > 
> > I can confirm this patch fixes the errors I was seeing with current
> > linux-2.6.git for the USB memory card readers in a Dell TFT connected
> > to a PS3.
> 
> James, we need a fix for this pushed asap. So either we should merge the
> below now, or push the bidi patchset that also fixes this. It all
> depends on when you want to merge the bidi patches...

The SCSI patch set (including the bidirectional pieces) is waiting in
scsi-misc ... just for forms sake, could you confirm that it actually
fixes the problem and I'll push it.

James

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Wed, Jan 30 2008, James Bottomley wrote:
> On Wed, 2008-01-30 at 11:38 +0100, Jens Axboe wrote:
> > On Wed, Jan 30 2008, Geert Uytterhoeven wrote:
> > > On Tue, 29 Jan 2008, Jens Axboe wrote:
> > > > On Tue, Jan 29 2008, Jens Axboe wrote:
> > > > > On Tue, Jan 29 2008, James Bottomley wrote:
> > > > > > On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
> > > > > > > For some reason, usb_sg_init is boned during auto-sense.
> > > > > > 
> > > > > > OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
> > > > > > code ... that was also an update in 2.6.24
> > > > > 
> > > > > yeah, already found the bug - it's assuming ->request_buffer holds the
> > > > > sglist, oops. Preparing a fix.
> > > > 
> > > > ok here goes, this saves and restores the sg table correctly. it also
> > > > fixes the usb bug for me.
> > > 
> > > I can confirm this patch fixes the errors I was seeing with current
> > > linux-2.6.git for the USB memory card readers in a Dell TFT connected
> > > to a PS3.
> > 
> > James, we need a fix for this pushed asap. So either we should merge the
> > below now, or push the bidi patchset that also fixes this. It all
> > depends on when you want to merge the bidi patches...
> 
> The SCSI patch set (including the bidirectional pieces) is waiting in
> scsi-misc ... just for forms sake, could you confirm that it actually
> fixes the problem and I'll push it.

Certainly, I'll give it a spin tonight.

-- 
Jens Axboe

Re: [BUG] 2.6.24-git usb reset problems

[Jens Axboe]

On Wed, Jan 30 2008, Jens Axboe wrote:
> On Wed, Jan 30 2008, James Bottomley wrote:
> > On Wed, 2008-01-30 at 11:38 +0100, Jens Axboe wrote:
> > > On Wed, Jan 30 2008, Geert Uytterhoeven wrote:
> > > > On Tue, 29 Jan 2008, Jens Axboe wrote:
> > > > > On Tue, Jan 29 2008, Jens Axboe wrote:
> > > > > > On Tue, Jan 29 2008, James Bottomley wrote:
> > > > > > > On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
> > > > > > > > For some reason, usb_sg_init is boned during auto-sense.
> > > > > > > 
> > > > > > > OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
> > > > > > > code ... that was also an update in 2.6.24
> > > > > > 
> > > > > > yeah, already found the bug - it's assuming ->request_buffer holds the
> > > > > > sglist, oops. Preparing a fix.
> > > > > 
> > > > > ok here goes, this saves and restores the sg table correctly. it also
> > > > > fixes the usb bug for me.
> > > > 
> > > > I can confirm this patch fixes the errors I was seeing with current
> > > > linux-2.6.git for the USB memory card readers in a Dell TFT connected
> > > > to a PS3.
> > > 
> > > James, we need a fix for this pushed asap. So either we should merge the
> > > below now, or push the bidi patchset that also fixes this. It all
> > > depends on when you want to merge the bidi patches...
> > 
> > The SCSI patch set (including the bidirectional pieces) is waiting in
> > scsi-misc ... just for forms sake, could you confirm that it actually
> > fixes the problem and I'll push it.
> 
> Certainly, I'll give it a spin tonight.

Confirmed, pulling your scsi-misc branch into current -git makes the
problem go away as well.

-- 
Jens Axboe