Re: Re: USB controller resets when burning CD
I now have a workaround for my problem with the Teac W5000U DVD drive and 64 bit computer. Was somewhat hard to find, but I obtained a USB controller card new enough to be PCI express but old enough not to support USB 3.0. So far, have not suffered any more controller resets. The card uses the ehci rather than xhci drivers. This suggests but does not prove some sort of incompatibility between the DVD drive and xhci. Since xhci is what everyone is supposed to be using these days, this qualifies more as a workaround than a solution. But it is good enough for me. Thanks all of you for your suggestions.
Re: USB controller resets when burning CD
Hi, David Farrier wrote: > $ cdrskin --list_features > [...] > PhysInterface=2/ATAPI , INQ2=0 , DBE=0 Indeed the drive firmware believes to talk via an IDE/ATAPI controller. Ye olde Parallel SCSI would be Physical Interface Standard 1. SATA would be 7. Direct connection to USB would be 8. Regrettably the firmware does not tell its release date. Have a nice day :) Thomas
Re: USB controller resets when burning CD
Since cdrskin-1.5.2 you can inquire whether the drive announces its internal bus controller type and its firmware timestamp: cdrskin dev=/dev/sr0 --list_features | fgrep PhysInterface= cdrskin dev=/dev/sr0 --list_features | fgrep Date= I installed Debian "testing" on an external drive. Mainly because I had done all my investigation with "stable" and earlier, but also so I could obtain version 1.5.2 of cdrskin and try Thomas Scmitt's above suggestion. The big news, "testing" behaves the same as earlier Debian versions as far as burning CDs is concerned. Meanwhile, below is the entire output of the list_features subcommand (it's not all that long) in case one of you sees something relevant: $ cdrskin --list_features cdrskin 1.5.2 : limited cdrecord compatibility wrapper for libburn cdrskin: scanning for devices ... cdrskin: ... scanning for devices done SCSI Features reported by the drive: + = Current, - = Not Current, P = Persistent, N = Not Persistent Code C : Name : Version,Persistent Additional data if present (hex bytes) Parsed info if available (fieldname=content) + : Profile List : 0,P 00 2b 00 00 00 1b 00 00 00 1a 00 00 00 16 00 00 00 15 00 00 00 14 00 00 00 13 00 00 00 11 00 00 00 10 00 00 00 0a 00 00 00 09 00 00 00 08 00 00 0001 + : Core : 2,P 00 00 00 02 01 00 00 00 PhysInterface=2/ATAPI , INQ2=0 , DBE=0 0002 + : Morphing : 1,P 02 00 00 00 0003 + : Removable Medium : 1,P 39 00 00 00 LoadMechType=1/Tray , Eject=1 , PvntJmpr=0 , Lock=1 0004 - : Write Protect : 2,N 02 00 00 00 0010 - : Random Readable : 0,N 00 00 08 00 00 01 01 00 BlockSize=2048 , Blocking=1 , PP=1 001d - : Multi-Read : 0,N 001e - : CD Read : 2,N 03 00 00 00 DAP=0 , C2Flags=1 , CDText=1 001f - : DVD Read : 2,N 00 00 01 00 MULTI10=0 , DualR=1 0020 - : Random Writable : 1,N 00 00 00 00 00 00 08 00 00 10 01 00 LastLBA=0 , BlockSize=2048 , Blocking=16 , PP=1 0021 - : Incremental Streaming Writable : 3,N 01 00 00 01 10 00 00 00 DataBlockTypes=0100 , TRIO=0 , ARSV=0 , BUF=0 , NumLinkSizes=1 0023 - : Formattable : 2,N 00 00 00 00 00 00 00 00 RENoSA=0 , Expand=0 , QCert=0 , Cert=0 , RRM=0 0026 - : Restricted Overwrite : 0,N 002a - : DVD+RW : 1,N 01 00 00 00 Write=1 , QuickStart=0 , CloseOnly=0 002b - : DVD+R : 0,N 01 00 00 00 Write=1 002c - : Rigid Restricted Overwrite : 0,N 03 00 00 00 DSDG=0 , DSDR=0 , Intermediate=1 , Blank=1 002d - : CD Track at Once : 2,N 46 00 3f 01 BUF=1 , RWRaw=0 , RWPack=0 , TestWrite=1 , CD-RW=1 , RWSubcode=0 , DataTypeSupp=3f01 002e - : CD Mastering : 1,N 6f 00 16 00 BUF=1 , SAO=1 , RawMS=0 , Raw=1 , TestWrite=1 , CD-RW=1 , RW=1 , MaxCueSheetLen=5632 002f - : DVD-R/-RW Write : 2,N 4e 00 00 00 BUF=1 , RDL=1 , TestWrite=1 , DVDRW=1 0033 - : Layer Jump Recording : 0,N 00 00 00 01 10 00 00 00 NumLinkSizes=1 0037 - : CD-RW Media Write Support : 0,N 00 0f 00 00 Subtype7=0 , Subtype6=0 , Subtype5=0 , Subtype4=0 , Subtype3=1 , Subtype2=1 , Subtype1=1 , Subtype0=1 003b - : DVD+R Dual Layer : 0,N 01 00 00 00 Write=1 0100 + : Power Management : 0,P 0103 - : (Legacy) : 0,N 07 00 01 00 0104 + : Microcode Upgrade : 1,N 00 00 00 00 0105 + : Timeout : 1,P 01 00 00 00 Group3=1 , UnitLength=0 0106 - : DVD-CSS : 0,N 00 00 00 01 CSSVersion=1 0107 - : Real Time Streaming : 4,N 1e 00 00 00 RBCB=1 , SCS=1 , MP2A=1 , WSPD=1 , SW=0 0108 + : Drive Serial Number : 0,P 4b 48 30 32 31 32 38 35 34 36 57 4c SerialNumber=KH02128546WL 010a - : DCBs : 0,N 46 44 43 00 53 44 43 00 54 4f 43 00 SuppEntry0=46444300 , SuppEntry1=53444300 , SuppEntry2=544f4300 010b - : DVD CPRM : 0,N 00 00 00 01 CPRMVersion=1
Re: USB controller resets when burning CD
deloptes wrote: Unfortunately, trying different USB ports does not make any difference, as all my external USB ports belong to the same controller. Would like to try your other suggestion, unloading xhci_hcd and let the system fall back to ehci_hcd. How do I do that? I tried blacklisting xhci_hcd, following the instructions in the Debian Kernel Manual Chapter 6. When I rebooted, xhci_hcd loaded anyhow. sudo rmmod xhci_hcd ? Unfortunately, it is not that simple. The initial challenge is rmmod refuses to remove xhci_hcd, saying it is already in use. I figured out that challenge. First you have to remove xhci_pci, then it will let you remove xhci_hcd. The bigger challenge is, removing the xhci modules leaves all the external USB ports disabled. I was hoping the system would fall back to using ehci_hcd for those ports, but no such luck. Maybe I need to reinitialize something?
Re: USB controller resets when burning CD
David Farrier wrote: > Unfortunately, trying different USB ports does not make any difference, as > all my external USB ports belong to the same controller. Would like to try > your other suggestion, unloading xhci_hcd and let the system fall back to > ehci_hcd. How do I do that? I tried blacklisting xhci_hcd, following the > instructions in the Debian Kernel Manual Chapter 6. When I rebooted, > xhci_hcd loaded anyhow. sudo rmmod xhci_hcd ?
Re: USB controller resets when burning CD
deloptes wrote: I would suggest try using usb2 port if the PC has one or unloading the xhci_hcd. Your old pc did not have usb3 for sure and you reported it worked well there. Unfortunately, trying different USB ports does not make any difference, as all my external USB ports belong to the same controller. Would like to try your other suggestion, unloading xhci_hcd and let the system fall back to ehci_hcd. How do I do that? I tried blacklisting xhci_hcd, following the instructions in the Debian Kernel Manual Chapter 6. When I rebooted, xhci_hcd loaded anyhow.
Re: USB controller resets when burning CD
David Farrier wrote: > Thanks. That is good advice for a drive that gets its power from the USB > port. I should have mentioned this particular drive has its own power > supply. Hi, yes I found this in the log you posted - look at my next post from yesterday regarding usb3 driver regards
Re: USB controller resets when burning CD
Hi, are you aware that there were more replies on the list which did not Cc you ? David Farrier wrote: > I have even entertained the thought the design might be so > ancient as to be a repackaged SCSI drive. I doubt that. The main difference between SCSI and IDE/ATAPI drives in the was the price. Any IDE stuff was much cheaper than the SCSI counterparts and nothing in an optical drive needed the luxury of Ultra/Fast SCSI. Since cdrskin-1.5.2 you can inquire whether the drive announces its internal bus controller type and its firmware timestamp: cdrskin dev=/dev/sr0 --list_features | fgrep PhysInterface= cdrskin dev=/dev/sr0 --list_features | fgrep Date= I get on my oldest still active drive PhysInterface=7/Serial_ATAPI , INQ2=0 , DBE=0 Date=20080509123456 As told by man cdrskin, one needs SCSI specs volume MMC to understand what all the feature parameters mean. But the meaning of these two lines is quite obvious. Not all drives announce this. Some tell funny firmware dates like 2113. cdrskin-1.5.2 is still in Debian "testing". But you may compile it from its standalone source tarball and run it without installation and thus without endangering Debian's package integrity. http://scdbackup.sourceforge.net/cdrskin_eng.html#download Just stop reading its README after cdrskin/cdrskin -version works and tells its version. Then use cdrskin by the absolute path of the produced program file ./cdrskin/cdrskin > Some trivia: the flagship of this line of products was the DV-W5000S. A > standalone machine with built-in go/nogo display for verifying disks burned > on another drive. No computer required! Yeah. I came to those when sniffing after your initial report line iProduct 76 Disk Checker DK-5000S but deloptes beat me with announcing that http://teac-ipd.com/dk-5000/ says Power Source 100-240V AC, 50-60Hz and thus indicates an own power supply which converts to low voltage DC. - So we have as main suspects for the problem: - The drive's inner electrics and mechanics. - The power supply of the drive's box. - The converter in the box from the drive's own bus controller to USB. (Ye olde Parallel SCSI, old IDE, and SATA are candidates.) - The USB controller in your computer (and its internal connections). More than one could be involved. Opportunities are manifold. But i doubt that the USB cable could get tired after 130 MB. Have a nice day :) Thomas
Re: USB controller resets when burning CD
Yes, I think you understand the situation well. It does look like the DV-W5000U might be an internal IDE drive repackaged to be a modern external USB drive. I have even entertained the thought the design might be so ancient as to be a repackaged SCSI drive. Some trivia: the flagship of this line of products was the DV-W5000S. A standalone machine with built-in go/nogo display for verifying disks burned on another drive. No computer required! On Fri, 22 May 2020, Thomas Schmitt wrote: Hi, David Farrier wrote: will use cdrskin as an example, as I think its error messages more useful. :) Track 01: 139 of 640 MB written (fifo 100%) [buf 98%] 4.0x.cdrskin: FAILURE : SCSI command 2Ah yielded host problem: 0x7 SG_ERR_DID_ERROR (Internal error detected in the host adapter) That's an error reply from the kernel call ioctl(SGI_IO) which shall transport SCSI commands to the drive. Lots of them succeeded transporting 32 kiB of data per call. Now one of them suddenly failed with no error message from the drive's firmware. May 22 09:00:51 penguin kernel: [45975.237515] usb 2-9: reset high-speed USB device number 3 using xhci_hcd May 22 09:00:52 penguin kernel: [45976.212240] sr 7:0:0:0: Power-on or device reset occurred This is probably the reason for above error reply. The USB connection went away and the file descriptor became invalid while it was waiting for the outcome of the pending SCSI transaction. Hard to say what makes the involved controllers mad after a while of burning. The rotation speed might grow and thus consume more power. But you had effective CD speed 4, which is rather moderate. Did you already try to plug it into a different USB port of the computer ? Does it have its own power supply (or does it have two USB cables) ? DV-W5000U CD/DVD Premium reputation but probably as old as the first cdrskin release. :)) Photos look like it's a full height drive in a USB box. Those quite surely have internal SATA or IDE controllers connected to a USB bridge in the box. One can buy 5.25 inch USB enclosures with SATA-USB at about the price of a new Blu-ray burner. IDE-USB might be a matter of virtual yard sales. So before you throw your TEAC away it might be worth to cautiously crack its enclosure and to look whether there is a SATA or IDE cable to see and the drive can be unscrewed from the box. If so, then it is up to you whether you invest in a new USB box at the risk that it is the drive's controller which goes mad. In this sad case, you could then buy a DVD burner for the box (again, IDE is rare now). It is hard to find expensive ones, nowadays. Have a nice day :) Thomas
Re: USB controller resets when burning CD
Thanks. That is good advice for a drive that gets its power from the USB port. I should have mentioned this particular drive has its own power supply. On Fri, 22 May 2020, Dan Ritter wrote: My nearly baseless suspicion: the drive needs more power than it is getting from this USB port. Suggestions to verify/eliminate this: move it to a different USB port (not nearby); put it on a USB hub that get power via an AC adapter. -dsr-
Re: USB controller resets when burning CD
deloptes wrote: > Dan Ritter wrote: > >> Suggestions to verify/eliminate this: move it to a different USB >> port (not nearby); put it on a USB hub that get power via an AC >> adapter. > > the burners (usb2) that I have provide dual usb cable exactly for this. > as we know typical usb2 provide 0.5A, so might be your suspicion is > correct. > > but if we knew the make and model, it were easier to check. It seems it comes with external power supply http://teac-ipd.com/dk-5000/ But what I noticed is the use of USB3 port USB device number 3 using xhci_hcd I would suggest try using usb2 port if the PC has one or unloading the xhci_hcd. Your old pc did not have usb3 for sure and you reported it worked well there.
Re: USB controller resets when burning CD
Dan Ritter wrote: > Suggestions to verify/eliminate this: move it to a different USB > port (not nearby); put it on a USB hub that get power via an AC > adapter. the burners (usb2) that I have provide dual usb cable exactly for this. as we know typical usb2 provide 0.5A, so might be your suspicion is correct. but if we knew the make and model, it were easier to check.
Re: USB controller resets when burning CD
Hi, David Farrier wrote: > will use cdrskin as an example, as I think its error messages more useful. :) > Track 01: 139 of 640 MB written (fifo 100%) [buf 98%] 4.0x.cdrskin: > FAILURE : SCSI command 2Ah yielded host problem: 0x7 SG_ERR_DID_ERROR > (Internal error detected in the host adapter) That's an error reply from the kernel call ioctl(SGI_IO) which shall transport SCSI commands to the drive. Lots of them succeeded transporting 32 kiB of data per call. Now one of them suddenly failed with no error message from the drive's firmware. > May 22 09:00:51 penguin kernel: [45975.237515] usb 2-9: reset high-speed USB > device number 3 using xhci_hcd > May 22 09:00:52 penguin kernel: [45976.212240] sr 7:0:0:0: Power-on or > device reset occurred This is probably the reason for above error reply. The USB connection went away and the file descriptor became invalid while it was waiting for the outcome of the pending SCSI transaction. Hard to say what makes the involved controllers mad after a while of burning. The rotation speed might grow and thus consume more power. But you had effective CD speed 4, which is rather moderate. Did you already try to plug it into a different USB port of the computer ? Does it have its own power supply (or does it have two USB cables) ? > DV-W5000U CD/DVD Premium reputation but probably as old as the first cdrskin release. :)) Photos look like it's a full height drive in a USB box. Those quite surely have internal SATA or IDE controllers connected to a USB bridge in the box. One can buy 5.25 inch USB enclosures with SATA-USB at about the price of a new Blu-ray burner. IDE-USB might be a matter of virtual yard sales. So before you throw your TEAC away it might be worth to cautiously crack its enclosure and to look whether there is a SATA or IDE cable to see and the drive can be unscrewed from the box. If so, then it is up to you whether you invest in a new USB box at the risk that it is the drive's controller which goes mad. In this sad case, you could then buy a DVD burner for the box (again, IDE is rare now). It is hard to find expensive ones, nowadays. Have a nice day :) Thomas
Re: USB controller resets when burning CD
On Friday 22 May 2020 13:57:33 David Farrier wrote: > Please help debug a communication problem with my TEAC DV-W5000U > CD/DVD burner. It read and wrote reliably with my 686 PC. I retired > that machine, and recently tried to move the burner to one of my > 64-bit computers. It reads reliably, but when writing, fails after > transferring approximately 150 Mb. Writing disk images smaller than > that usually works. > > Have tried various burning software, however will use cdrskin as an > example, as I think its error messages more useful. At the point > cdrskin prematurely quits burning, it complains about the host > adapter. So, I looked in syslog, and about the time cdrskin fails, > syslog reports the controller xhci_hcd reset the USB device. > > Any suggestions appreciated. I hate to give up on the DV-W5000U > because it is designed to do especially high-quality burns. Seems to > be an ordinary TEAC drive except built to tighter tolerances. > > More details: > > Version of Debian: > When I first discovered this problem, I had the old computer and one > of the new computers both running stretch, set up nearly the same > except one was 686 pae and the other amd64. Since retiring the old > computer, have tried buster with kernel 4.0.19 and backported 5.0.4. > Have not tried testing or unstable. > > Information about the DV-W5000U, from lsusb: > Bus 002 Device 003: ID 0644:1010 TEAC Corp. > Device Descriptor: >bLength18 >bDescriptorType 1 >bcdUSB 2.00 >bDeviceClass0 >bDeviceSubClass 0 >bDeviceProtocol 0 >bMaxPacketSize064 >idVendor 0x0644 TEAC Corp. >idProduct 0x1010 >bcdDevice2.40 >iManufacturer 98 TEAC >iProduct 76 Disk Checker DK-5000S >iSerial63 DEF1151C028D >bNumConfigurations 1 >Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 0x0027 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xc0 >Self Powered > MaxPower2mA > Interface Descriptor: >bLength 9 >bDescriptorType 4 >bInterfaceNumber0 >bAlternateSetting 0 >bNumEndpoints 3 >bInterfaceClass 8 Mass Storage >bInterfaceSubClass 6 SCSI >bInterfaceProtocol 80 Bulk-Only >iInterface 0 >Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes2 >Transfer TypeBulk >Synch Type None >Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 >Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x86 EP 6 IN > bmAttributes2 >Transfer TypeBulk >Synch Type None >Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 >Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes3 >Transfer TypeInterrupt >Synch Type None >Usage Type Data > wMaxPacketSize 0x0002 1x 2 bytes > bInterval 12 > Device Qualifier (for other device speed): >bLength10 >bDescriptorType 6 >bcdUSB 2.00 >bDeviceClass0 >bDeviceSubClass 0 >bDeviceProtocol 0 >bMaxPacketSize064 >bNumConfigurations 1 > can't get debug descriptor: Resource temporarily unavailable > Device Status: 0x0001 >Self Powered > > An example burn command, followed by the relevant error messages: > cdrskin -v dev=1 speed=4 fs=8m blank=as_needed -eject padsize=300k > 640mbfile.iso > ... > Track 01: 139 of 640 MB written (fifo 100%) [buf 98%] > 4.0x.cdrskin: FAILURE : SCSI command 2Ah yielded host problem: 0x7 > SG_ERR_DID_ERROR (Internal error detected in the host adapter) > cdrskin: FATAL : Lost connection to drive > cdrskin: FAILURE : Failed to synchronize drive cache. SCSI error : [0 > 00 00] (No error reported by SCSI transaction) > ... > > The relevant lines from syslog: > May 22 09:00:51 penguin kernel: [45975.237515] usb 2-9: reset > high-speed USB device number 3 using xhci_hcd > May 22 09:00:52 penguin kernel: [45976.212240] sr 7:0:0:0: Power-on or > device reset occurred
Re: USB controller resets when burning CD
David Farrier wrote: > Please help debug a communication problem with my TEAC DV-W5000U CD/DVD > burner. It read and wrote reliably with my 686 PC. I retired that machine, > and recently tried to move the burner to one of my 64-bit computers. It > reads reliably, but when writing, fails after transferring approximately 150 > Mb. Writing disk images smaller than that usually works. > > Have tried various burning software, however will use cdrskin as an example, > as I think its error messages more useful. At the point cdrskin prematurely > quits burning, it complains about the host adapter. So, I looked in syslog, > and about the time cdrskin fails, syslog reports the controller xhci_hcd > reset the USB device. > My nearly baseless suspicion: the drive needs more power than it is getting from this USB port. Suggestions to verify/eliminate this: move it to a different USB port (not nearby); put it on a USB hub that get power via an AC adapter. -dsr-
