From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; sv-SE; rv:1.7.3) Gecko/20041020 Description of problem: Using the new possibility in kernel 2.6.10 to write directly to a DVD device I tried to write a multi-volume tar archive on disks this way. It ran for quite some time, but then it stopped and hang. Version-Release number of selected component (if applicable): kernel-2.6.10-1.741_FC3 How reproducible: Always Steps to Reproduce: 1.tar --create --blocking-factor=64 --listed-incremental=New.time --file=/dev/cdwriter --multi-volume --verbose --totals --label='S�kerhetskopia niv� TEST' /usr/local/games/TheSims 2. Wait for a while Actual Results: Tar runs for quite some time, but suddenly stops. (Reproducibility "every time" isn't strictly true. If I just write a small archive, it works most of the time. But I have never been able to write a full DVD, let alone continue on a second.) Doing ps; it looks like this: F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 4 D root 8228 8164 3 78 0 - 1351 get_re 15:39 pts/6 00:00:45 tar --create --blocking-factor=64 --listed-incremental=New.time --file=/dev/cdwriter --multi-volume --verbose --totals --label=S�kerhetskopia niv� TEST /usr/local/games/TheSims Some other commands also hangs, apparently when trying to access files, but not everything is locked. Trying to reboot the system hangs. Additional info: The DVD burner I'm using identifies as: _NEC DVD+RW ND-1100A There are several messages in the log which I guess relates to this: Jan 15 15:51:49 mimmi kernel: hdb: media error (bad sector): status=0x51 { DriveReady SeekComplete Error } Jan 15 15:51:49 mimmi kernel: hdb: media error (bad sector): error=0x34 Jan 15 15:51:49 mimmi kernel: ide: failed opcode was 100 Jan 15 15:51:49 mimmi kernel: ATAPI device hdb: Jan 15 15:51:49 mimmi kernel: Error: Medium error -- (Sense key=0x03) Jan 15 15:51:49 mimmi kernel: Write error -- (asc=0x0c, ascq=0x00) Jan 15 15:51:49 mimmi kernel: The failed "Write 10" packet command was: Jan 15 15:51:49 mimmi kernel: "2a 00 00 03 e2 c4 00 00 40 00 00 00 00 00 00 00 " Jan 15 15:51:49 mimmi kernel: end_request: I/O error, dev hdb, sector 1018640 Jan 15 15:51:49 mimmi kernel: printk: 22 messages suppressed. Jan 15 15:51:49 mimmi kernel: Buffer I/O error on device hdb, logical block 127330 Jan 15 15:51:49 mimmi kernel: lost page write due to I/O error on hdb And then it goes on like that. After a little while, messages like these start appearing: Jan 15 15:58:55 mimmi kernel: ide-cd: write_intr: oops Jan 15 15:58:55 mimmi kernel: hdb: lost interrupt I have previously used a 2.4 kernel I built myself on this machine with the patches from Andy Polyakov (http://fy.chalmers.se/~appro/linux/DVD+RW/). As I understand it, his modifications are part of the base of what is now included in the standard kernel. I had some problems similar to these in the beginning, but Andy suggested I should attach a raw device and use that instead. Doing that, and making sure tar wrote aligned blocks, I never had any similar problems any more. I never investigated why things didn't work in the first version. Since the raw devices are no longer supported (bug 121985), that workaround is no longer an option.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
I have upgraded to FC4, and can't easily test with FC3. But I did test with the current kernel for FC4 (2.6.12-1.1398_FC4). The command works now. I managed tow write a two-volume archive; one full DVD and a little bit on a second. It is obviously a very slow way to write a DVD. It took almost 10 hours to write the first DVD. So this will in practice not be an alternative to the /dev/raw method I used previously in most cases. But it did finish, and didn't hang as before. So the bug I originally reported here seems to be gone in current FC4.