Created attachment 711769 [details] lspci -vvv - wotan.walhalla Since the transition to kernel 3.8.x my PATA DVD-RW drive TSST TSSTcorpCD/DVDW SH-S182D, SB07 is behaving erratically when recording DVD-R's (CD-R's and CD-RW's do record OK). First of all, regardless of presence of media, when booting the machine the following messages appear on /var/log/messages: Mar 18 02:24:02 wotan kernel: [ 3.308122] ata9.00: ATAPI: TSSTcorpCD/DVDW SH-S182D, SB07, max UDMA/33 Mar 18 02:24:02 wotan kernel: [ 3.314127] ata9.00: configured for UDMA/33 Mar 18 02:24:05 wotan kernel: [ 24.073841] ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Mar 18 02:24:05 wotan kernel: [ 24.073883] ata9.00: cmd a0/01:00:00:60:00/00:00:00:00:00/a0 tag 0 dma 96 in Mar 18 02:24:05 wotan kernel: [ 24.073891] ata9.00: status: { DRDY } Mar 18 02:24:10 wotan kernel: [ 29.119971] ata9: link is slow to respond, please be patient (ready=0) Mar 18 02:24:15 wotan kernel: [ 34.119207] ata9: device not ready (errno=-16), forcing hardreset Mar 18 02:24:15 wotan kernel: [ 34.119224] ata9: soft resetting link Mar 18 02:24:15 wotan kernel: [ 34.327644] ata9.00: configured for UDMA/33 Mar 18 02:24:15 wotan kernel: [ 34.338706] ata9: EH complete Mar 18 02:24:46 wotan kernel: [ 64.302542] ata9.00: limiting speed to UDMA/25:PIO4 Mar 18 02:24:46 wotan kernel: [ 64.302554] ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Mar 18 02:24:46 wotan kernel: [ 64.302718] ata9.00: cmd a0/01:00:00:80:00/00:00:00:00:00/a0 tag 0 dma 16512 in Mar 18 02:24:46 wotan kernel: [ 64.302933] ata9.00: status: { DRDY } Mar 18 02:24:51 wotan kernel: [ 69.348716] ata9: link is slow to respond, please be patient (ready=0) Mar 18 02:24:56 wotan kernel: [ 74.343909] ata9: device not ready (errno=-16), forcing hardreset Mar 18 02:24:56 wotan kernel: [ 74.343925] ata9: soft resetting link Mar 18 02:24:56 wotan kernel: [ 74.505588] ata9.00: configured for UDMA/25 Mar 18 02:24:56 wotan kernel: [ 74.506741] ata9: EH complete Mar 18 02:25:04 wotan kernel: [ 82.276537] ata9.00: limiting speed to PIO4 Mar 18 02:25:04 wotan kernel: [ 82.276549] ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Mar 18 02:25:04 wotan kernel: [ 82.276713] ata9.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in Mar 18 02:25:04 wotan kernel: [ 82.276928] ata9.00: status: { DRDY } Mar 18 02:25:09 wotan kernel: [ 87.322697] ata9: link is slow to respond, please be patient (ready=0) Mar 18 02:25:14 wotan kernel: [ 92.317952] ata9: device not ready (errno=-16), forcing hardreset Mar 18 02:25:14 wotan kernel: [ 92.317968] ata9: soft resetting link Mar 18 02:25:14 wotan kernel: [ 92.478360] ata9.00: configured for PIO4 Mar 18 02:25:14 wotan kernel: [ 92.478698] ata9: EH complete So the drive initially gets attached at UDMA/33 and then its speed falls down to PIO4. The first time I've seen this I've tried to exchange the cables - I'm using 80-wire cables for this drive. Nothing happened. I've also updated the drive's firmware to the latest version (from SB06 to SB07) with the very same results. Searching through my log files, I've seen that regressions started after Linux Kernel 3.8 was introduced. Kernel 3.7.9 shows the following for this device: Feb 28 16:08:31 wotan kernel: [ 3.203002] ata9: PATA max UDMA/100 cmd 0xdc00 ctl 0xd880 bmdma 0xd400 irq 45 Feb 28 16:08:31 wotan kernel: [ 3.358181] ata9.00: ATAPI: TSSTcorpCD/DVDW SH-S182D, SB06, max UDMA/33 Feb 28 16:08:31 wotan kernel: [ 3.364118] ata9.00: configured for UDMA/33 Mar 1 08:46:54 wotan kernel: [32075.274946] ata9.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered out Mar 1 08:46:54 wotan kernel: [32075.274948] ata9.00: ACPI cmd ef/03:46:00:00:00:a0 (SET FEATURES) filtered out Mar 1 08:46:54 wotan kernel: [32075.280939] ata9.00: configured for UDMA/33 With Linux kernels up to the last release of 3.7 series, I had absolutely no problems recording DVD's on this drive. However, since from the update to 3.8 series, DVD's are recorded with extremely low speeds (from 0.4x to 1.3x) when media clearly supports at least 16x recording. Hardware buffer utilization is low too, often going down to 5%. $ wodim dev=/dev/sr0 -v some-dvd-image.iso wodim: No write mode specified. wodim: Assuming -tao mode. wodim: Future versions of wodim may have different drive dependent defaults. TOC Type: 1 = CD-ROM wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits. scsidev:/dev/sr0' devname:'/dev/sr0' scsibus: -2 target: -2 lun: -2 Linux sg driver version: 3.5.27 Wodim version: 1.1.11 SCSI buffer size: 64512 Device type : Removable CD-ROM Version : 5 Response Format: 2 Capabilities : Vendor_info : 'TSSTcorp' Identification : 'CD/DVDW SH-S182D' Revision : 'SB07' Device seems to be: Generic mmc2 DVD-R/DVD-RW. Current: 0x0011 (DVD-R sequential recording) Profile: 0x0015 (DVD-R/DL sequential recording) Profile: 0x0016 (DVD-R/DL layer jump recording) Profile: 0x002B (DVD+R/DL) Profile: 0x001B (DVD+R) Profile: 0x001A (DVD+RW) Profile: 0x0014 (DVD-RW sequential recording) Profile: 0x0013 (DVD-RW restricted overwrite) Profile: 0x0012 (DVD-RAM) Profile: 0x0011 (DVD-R sequential recording) (current) Profile: 0x0010 (DVD-ROM) Profile: 0x000A (CD-RW) Profile: 0x0009 (CD-R) Profile: 0x0008 (CD-ROM) Profile: 0x0002 (Removable disk) Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd). Driver flags : SWABAUDIO BURNFREE Supported modes: PACKET SAO Drive buf size : 1048576 = 1024 KB Beginning DMA speed test. Set CDR_NODMATEST environment variable if device communication breaks or freezes immediately after that. FIFO size : 4194304 = 4096 KB Track 01: data 2277 MB Total size: 2616 MB (259:10.33) = 1166275 sectors Lout start: 2616 MB (259:12/25) = 1166275 sectors Current Secsize: 2048 HINT: use dvd+rw-mediainfo from dvd+rw-tools for information extraction. Blocks total: 2298496 Blocks current: 2298496 Blocks remaining: 1132221 Speed set to 22160 KB/s Starting to write CD/DVD at speed 17.0 in real unknown mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Performing OPC... Starting new track at sector: 0 Track 01: 1356 of 2277 MB written (fifo 100%) [buf 35%] 0.5x. Track 01: 1357 of 2277 MB written (fifo 100%) [buf 19%] 0.5x. This particular tentative failed at last with the message wodim: faio_wait_on_buffer for writer timed out. Track 01: 1358 of 2277 MB written (fifo 75%) [buf 100%] 0.0x. Errno: 5 (Input/output error), write_g1 scsi sendcmd: no error CDB: 2A 00 00 0A 9C 03 00 00 1F 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 02 00 00 00 00 0A 00 00 00 00 30 05 00 00 Sense Key: 0x2 Not Ready, Segment 0 Sense Code: 0x30 Qual 0x05 (cannot write medium - incompatible format) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.004s timeout 40s write track data: error after 1423972352 bytes wodim: A write error occured. wodim: Please properly read the error message above. Writing time: 2150.193s Average write speed 0.8x. Min drive buffer fill was 3% Total of 46 possible drive buffer underruns predicted. While the problem is happening, there are absolutely no error messages on /var/log/messages - error messages regarding this drive appear only when the machine boots. I've recorded this very media on this very drive previously. lspci -vvv is attached to this bug report.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. It has been over a month since we asked you to test the 3.11 kernel updates and let us know if your issue has been resolved or is still a problem. When this happened, the bug was set to needinfo. Because the needinfo is still set, we assume either this is no longer a problem, or you cannot provide additional information to help us resolve the issue. As a result we are closing with insufficient data. If this is still a problem, we apologize, feel free to reopen the bug and provide more information so that we can work towards a resolution If you experience different issues, please open a new bug report for those.