Bug 121997 - uhci_hcd + usb_storage + scsi_core + sg mod fail to identify SCSI device attached to USB
Summary: uhci_hcd + usb_storage + scsi_core + sg mod fail to identify SCSI device atta...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 2
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-29 16:51 UTC by Casimiro de Almeida Barreto
Modified: 2007-11-30 22:10 UTC (History)
0 users

Clone Of:
Last Closed: 2004-07-12 15:07:04 UTC

Attachments (Terms of Use)

Description Casimiro de Almeida Barreto 2004-04-29 16:51:25 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.6)
Gecko/20040207 Firefox/0.8

Description of problem:
Attaching a ZIP CD-RW 640 to any USB port (direct, not via hub),
usb_storage identifies correctly the device. It is registered to
/dev/sr0 and /dev/scd0. But IT IS NOT registered to /dev/sg0.

This way, it is possible to mount and read CD's in this driver, but it
is not possible to write CDs.

When a short-cut is tried, such as: cdrecord dev=/dev/scd0, we get the

[root@200-207-17-55 TRACKS]# cdrecord dev=/dev/scd0 -raw16 -overburn
-v *cd1*
Cdrecord-Clone 2.01a27-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004
J�rg Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to
Note: The author of cdrecord should not be bothered with problems in
this version.
TOC Type: 1 = CD-ROM
scsidev: '/dev/scd0'
devname: '/dev/scd0'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.
Linux sg driver version: 3.5.27
Using libscg version 'schily-0.8'.
cdrecord: Warning: using inofficial libscg transport code version
(schily - Red Hat-scsi-linux-sg.c-1.80-RH '@(#)scsi-linux-sg.c      
1.80 04/03/08 Copyright 1997 J. Schilling').
SCSI buffer size: 0
cdrecord: Invalid argument. Cannot get SCSI I/O buffer.

Ant then, the debug message is:

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 0xc49 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 0xc49 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.

And I have the following situation in /proc/...

When I dump /proc/bus/usb/devices I get:

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.5-1.327 uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:04.2
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=059b ProdID=0050 Rev= 1.00
S:  Manufacturer=Iomega
S:  Product=USB Zip CD
S:  SerialNumber=00000000000000000000
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=   2 Ivl=32ms

Then, when I dump /proc/scsi/scsi I get:

Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: IOMEGA   Model: ZIPCD 650 USB    Rev: P1.9
  Type:   CD-ROM                           ANSI SCSI revision: 02

Yet, when I dump /proc/scsi/usb_storage/0 I get:

   Host scsi0: usb-storage
       Vendor: Iomega
      Product: USB Zip CD
Serial Number: 00000000000000000000
     Protocol: Transparent SCSI
    Transport: Bulk

But all entries in /proc/scsi/sg are empty !!!

So, let's go to /sys/bus/scsi/devices/0:0:0:0/

detach-state: 0
model: ZIPCD 650 USB
max-sectors: 240
queue-depth: 1
Rev: P1.9
scsi_level: 3
state: running
type: 5
vendor: IOMEGA

And I have a "block" symbolic link block ->
../../../../../../../../block/sr0 (that means nothing ...) and so on,
so forth.
Notice that there is not a char symlink to point to ...sg
sg directories have only empty entries...

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Boot the system with usb_core enabled and uhci_hcd enabled
2. cdrecord (or any other operation using /dev/sg by default)

Actual Results:  Error is issued about "no devices identifyied at
/dev/sg0 and /dev/pg0

Expected Results:  Clean access to drive

Additional info:

Never try to boot with the unity attached and a clean CD inside: kudzu

Comment 1 Jürgen Botz 2004-04-29 18:47:23 UTC
Me too.

Same thing except I'm using a USB Plextor CD-RW.  sg doesn't seem to
see any devices.

Comment 2 Casimiro de Almeida Barreto 2004-05-01 13:48:49 UTC
Bug is not present in kernel 2.6.6-rc3-bk2 from www.kernel.org. My
humble suggestion: get the correct code and inserti it inside kernel

Comment 3 Arjan van de Ven 2004-05-01 14:12:49 UTC
but the $5m question is if you actually can burn with the kernel.org
kernel, not jsut if sg sees the device... :)

Comment 4 Casimiro de Almeida Barreto 2004-05-01 16:31:13 UTC
It records, but not without its pains.

sg is not really stable: you need to start the driver with a valid
recorded CD in (otherwise it won't recognise the unity or, worse, if
you try to run KUDZU it will crash the SO (freeze) and the only
solution is the Microsoft solution (the reset key :) ).

Timing are also much more critical than in rh9: buffer underruns seems
to happen much more frequently.

Anyways, I think that it is a start for generating patch code.

Comment 5 Arjan van de Ven 2004-05-03 10:19:02 UTC
one culprit has been identified; cdrecord seems to try to set a IO
size of 255 sectors while USB in those kernels can do 240 maximum. SG
ignores that setting but may blow up later when you actually try to do
255; SG_IO will refuse the setting in the first place.

kernel 349 in http://people.redhat.com/arjanv/2.6 has the USB maximum
transfersize increased to 255 so that burning should be more reliable.
(the fact remains that cdrecord somehow tries 255 while this is very
much the wrong number because the kernel should have said 240)

Comment 6 Casimiro de Almeida Barreto 2004-05-28 04:08:45 UTC

With kernel 2.6.6 I am able to write CDs on /dev/sg0. A fact brought
me some light: when I cause an IO event (for instance an X-Windows IO
event like moving a window or clicking a button) recording crashes...

Either the interrupts are slowing buffer transfer and we get recording
buffers running out or we have other problems with the interrupt

Note You need to log in before you can comment on or make changes to this bug.