Bug 15403
| Summary: | cd/dvd burning fails due to spurious AN on LG GH22NS50 | ||
|---|---|---|---|
| Product: | IO/Storage | Reporter: | Matthias-Christian Ott (ott) |
| Component: | Serial ATA | Assignee: | Tejun Heo (tj) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | axboe, carlos, kay, tj |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.32 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Matthias-Christian Ott
2010-02-26 16:16:31 UTC
Hmmmm... the model seems to have problems on Linux. It's a pretty cheap one so I'll go ahead and order one and see whether I can reproduce the problem locally. Does it work in other OSes? Thanks. Can you also please post the output of hdparm -I on the drive? # hdparm -I /dev/cdrw /dev/cdrw: ATAPI CD-ROM, with removable media Model Number: HL-DT-ST DVDRAM GH22NS50 Serial Number: K1998RJ2657 Firmware Revision: TN01 Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6 Standards: Likely used CD-ROM ATAPI-1 Configuration: DRQ response: 50us. Packet size: 12 bytes cache/buffer size = unknown Capabilities: LBA, IORDY(can be disabled) DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns According to http://www.lge.com/us/support/product/support-product-profile.jsp?customerModelCode=GH22NS50 a new firmware version (TN02) is available, but I don't have Microsoft Windows, so I can't test it. I have the drive now. Haven't had time to work on it yet tho. I'll get to it in a few days. Please wait a bit. Thanks. I see this too, on a TSSTcorp CDDVDW SN-S082H, whenever I insert blank media or an audio CD. It behaves itself with a data CD-ROM. The drive seems to work fine reading data. This is with 2.6.33.1, I don't recall seeing this on 2.6.31. From dmesg, with a blank CD-R: Buffer I/O error on device sr0, logical block 0 sr 3:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE sr 3:0:0:0: [sr0] Sense Key : Illegal Request [current] sr 3:0:0:0: [sr0] Add. Sense: Logical block address out of range sr 3:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00 end_request: I/O error, dev sr0, sector 0 and with an audio CD: sr 3:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE sr 3:0:0:0: [sr0] Sense Key : Illegal Request [current] sr 3:0:0:0: [sr0] Add. Sense: Illegal mode for this track sr 3:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 00 00 00 00 40 00 end_request: I/O error, dev sr0, sector 0 Buffer I/O error on device sr0, logical block 0 Buffer I/O error on device sr0, logical block 1 Buffer I/O error on device sr0, logical block 2 Buffer I/O error on device sr0, logical block 3 Buffer I/O error on device sr0, logical block 4 Buffer I/O error on device sr0, logical block 5 Buffer I/O error on device sr0, logical block 6 Buffer I/O error on device sr0, logical block 7 Buffer I/O error on device sr0, logical block 8 sr 3:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE sr 3:0:0:0: [sr0] Sense Key : Illegal Request [current] sr 3:0:0:0: [sr0] Add. Sense: Illegal mode for this track sr 3:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 00 00 00 00 02 00 end_request: I/O error, dev sr0, sector 0 The drive's hdparm info: /dev/sr0: ATAPI CD-ROM, with removable media Model Number: TSSTcorp CDDVDW SN-S082H Serial Number: Firmware Revision: SB00 Standards: Supported: CD-ROM ATAPI-3 -4 -5 -6 -7 Configuration: DRQ response: 50us. Packet size: 12 bytes cache/buffer size = unknown Capabilities: LBA, IORDY(can be disabled) DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=383ns IORDY flow control=120ns Commands/features: Enabled Supported: * Power Management feature set * PACKET command feature set * DEVICE_RESET command * NOP cmd HW reset results: CBLID- below Vih Device num = 0 determined by CSEL My drive doesn't work with 2.6.30, so I think our bugs are related, because mine doesn't seem to be an regression bug. s/related/not related/ Perhaps, then again I may have been mistaken (I don't use optical media very often). I also see this on another machine (with an ATI-IXP chipset) with a HL-DT-STCD-RW/DVD DRIVE GCC-4241N drive: put in a blank or audio CD, and get cdrom: This disc doesn't have any tracks I recognize! sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE sr 1:0:0:0: [sr0] Sense Key : Illegal Request [current] Info fld=0x0, ILI sr 1:0:0:0: [sr0] Add. Sense: Illegal mode for this track sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00 end_request: I/O error, dev sr0, sector 0 Buffer I/O error on device sr0, logical block 0 This also happens on 2.6.31 in this machine (the one from Comment #6 doesn't have a 2.6.31 on it), the only difference being the absence of CDB: Read in that case... Hmmm... my drive has the new firmware TN02 but shows the same problem. I tried with different write sizes but once the recording of the first chunk is complete, the drive aborts further write requests with invalid write address. This doesn't seem to be a driver issue tho. The data transport seems to work just fine. Probably the drive needs a different recording command sequence / timing / whatever. I'll play with it a bit more. Thanks. Here are things I've found so far. * It's not a kernel regression. 2.6.30 behaves the same and other drives work fine. * There seems to be a regression in cdrom open path which makes media presence polling continuously trigger read errors under the current kernel for some drives but this doesn't seem to have much to do with the burning failures. * ata_piix/ahci does make difference. In piix mode, it works, in ahci it doesn't even when the command stream for burning is identical. I'll keep digging and the kernel read error messages shouldn't be too hard to fix but the burning failure seems like a subtle compatibility issue and could be difficult to diagnose and work around w/o bus tracer. :-( Thanks. Another interesting data point. * Both ich8 and jmb ahci's fail. On my computer the drive didn't work with IDE compatibility and ATA mode. But thanks for all the efforts you make. On further investigation, the problem seems to be caused by how udev polls for media presence events and spurious AN events during burning interacts with it. Does stopping udevd make burning work? Thanks. No, not really. Wodim burned the CD without any complaints, but it only contained 2048 bytes of zeros, when I tried to read it. However, I saw the burning light flashing and heard the CD rotating. Hmmm... that's strange. Can you please try once more just in case and eject and reload the media before trying to read it back? Thanks. That did it. A 80 MiB file got correctly burned onto the CD, though the drive was quite noisy. This drive is very noisy on Windows as well - I suspect that is just the nature of these drives, rather than anything Linux specific. This problem happens like the following. * Device generates spurious AN when burning starts. * udev/hal opens the device and issues commands to investigate the event. * Device replies to those unexpected probing commands and fails burning. This can be fixed by updating probing programs to open w/ O_EXCL. Kay Sievers already fixed upstream. Please report to your distro so that they can apply the fix. While investigating the problem, an issue in block device open path also was discovered where O_EXCL open attempts can interfere with the existing O_EXCL open. Patches to address this issue have been posted. http://thread.gmane.org/gmane.linux.kernel/971119 Resolving as CODE_FIX. Thanks. Updated bug title for later reference. The repeated read failures during probing are probably caused by drive responding unusually to READ TOC making the driver believe that the present media is not blank. This doesn't have anything to do with the burning failure. The only consequence is ugly messages and considerable delay until the drive is ready to use after blank media is inserted. I think there are a couple of things we can try to work around this one. Can one of you guys please open a separate bug entry for this and assign it to me? Thanks. I reported this to the Debian maintainer: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577256 (In reply to comment #20) > Updated bug title for later reference. The repeated read failures during > probing are probably caused by drive responding unusually to READ TOC making > the driver believe that the present media is not blank. This doesn't have > anything to do with the burning failure. The only consequence is ugly > messages > and considerable delay until the drive is ready to use after blank media is > inserted. I think there are a couple of things we can try to work around > this > one. Can one of you guys please open a separate bug entry for this and > assign > it to me? Filed bug 15757 as requested. |