Hide Forgot
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 following: [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 <warly@mandrakesoft.com>. 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 Quirks: 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): kernel-2.6.5-1.327 How reproducible: Always 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) 3. 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 locks...
Me too. Same thing except I'm using a USB Plextor CD-RW. sg doesn't seem to see any devices.
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 2.6.5-1.327...
but the $5m question is if you actually can burn with the kernel.org kernel, not jsut if sg sees the device... :)
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.
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)
Ok, 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 interface...