You are not logged in.
Anyone else having this problem? As far as I can tell it took place at the same time as the 2.6.19 upgrade and the switch to cdrkit. My IDE dvd-rw drive is loaded as sr0/sg0 as I understand it should be after 2.6.19, and all of the required modules are loaded (sg and sr_mod - correct?) Running wodim -scanbus, things look fine. Here's the relevant error dump of a recent failure in k3b:
System
-----------------------
K3b Version: 0.12.17
KDE Version: 3.5.5
QT Version: 3.3.6
Kernel: 2.6.19-ARCH
Devices
-----------------------
HL-DT-ST DVDRAM GSA-4163B A104 (/dev/sr0, /dev/sg0) at [CD-R; CD-RW; CD-ROM; DVD-ROM; DVD-RAM; DVD-R; DVD-RW; DVD+R; DVD+RW; DVD+R DL] [DVD-ROM; DVD-R Sequential; DVD-RAM; DVD-RW Restricted Overwrite; DVD-RW Sequential; DVD+RW; DVD+R; DVD+R Double Layer; CD-ROM; CD-R; CD-RW] [SAO; TAO; RAW; SAO/R96P; SAO/R96R; RAW/R16; RAW/R96P; RAW/R96R; Restricted Overwrite]
K3b
-----------------------
Size of filesystem calculated: 2126059
Used versions
-----------------------
growisofs: 7.0
growisofs
-----------------------
Executing 'builtin_dd if=/dev/fd/0 of=/dev/sr0 obs=32k seek=0'
/dev/sr0: "Current Write Speed" is 16.4x1352KBps.
1114112/4354168832 ( 0.0%) @0.0x, remaining 455:50 RBU 100.0% UBU 2.9%
1114112/4354168832 ( 0.0%) @0.0x, remaining 651:11 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 846:33 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 1107:02 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 1302:23 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 1562:52 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 1758:14 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 1953:35 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 2214:04 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 2409:26 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 2604:47 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 2865:16 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 3060:38 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 3255:59 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 3516:28 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 3711:50 RBU 100.0% UBU 100.0%
1114112/4354168832 ( 0.0%) @0.0x, remaining 3907:11 RBU 100.0% UBU 100.0%
:-[ WRITE@LBA=220h failed with SK=0h/ASC=00h/ACQ=03h]: Input/output error
:-( write failed: Input/output error
/dev/sr0: flushing cache
:-[ SYNCHRONOUS FLUSH CACHE failed with SK=4h/ASC=A0h/ACQ=80h]: Input/output error
I'm also seeing the following in messages.log:
Dec 17 17:07:48 pinkwater ata1: soft resetting port
Dec 17 17:07:48 pinkwater ata1.00: configured for UDMA/33
Dec 17 17:07:48 pinkwater ata1: EH complete
Not sure if that's standard or not, but I don't recall ever seeing it before.
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
I should also point out that I am not using the pata hook in mkinitcpio.conf yet.
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
Have you changed media types recently? Or started on a new batch of discs?
Just checking the obvious... apologies if too obvious!
Francis
Offline
Not too obvious at all, actually, and I meant to include in my initial post that I'm halfway through a spindle of DVDs and had no issues prior to this in this spindle. They're verbatim DVD+Rs. I generally use DVD-Rs, but my wife found these for half price a while ago, and like I say, so far they're been doing just fine. I never do multisession burns, so that's not an issue either. It's absolutely possible that it's a media issue and has nothing to do with the recent updates, but it seems a little unlikely all things considered. Of course I can't explain why an app would fail occasionally rather than constantly if it were an issue with the tools, either. I suppose I could break out a spindle of Taiyo Yuden and see if I continue to have the problem.
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
I'm starting to think this is definitely a bug and not flaky media. I've seen postings on LKML about people having problems with similar issues, though not specifically the same. I added "earlymodules=piix" to my kernel options, and this changed my drive back to /dev/hda. I then burned a couple disks in a row w/o any problems, but then encountered this issue:
Dec 17 22:57:30 pinkwater ide: failed opcode was: unknown
Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown
Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown
Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown
Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown
Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown
...snip...
During this, K3B was reporting zero FIFO buffer but finished burning the disk like it was good, and even reported success. My DVD drive was basically spinning full speed, and showed no signs of stopping - I let it run for nearly 5 min. I could not eject the media ,even as root, and eventually had to reboot the box.
My mobo has an ICH7 chipset that I've never been able to get to boot while using AHCI, so I've been using IDE mode. I have one SATA drive on the on-board controller, and one IDE drive (my DVD-RW) - I also have a 3ware 9xxx card with a raid5 setup in a PCI-X slot. Prior to recent changes, I've had the occasional hiccup, but this is the first time I've actually been killing discs (the discs all claim to still be empty after a failed burn, but they have been hit at least briefly with a laser, and even trying to multisession on these discs will fail. Coaster city.)
I guess I'll keep googling.
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
OK - I may have solved this. My drive is working a hell of a lot better at least. After saying I've never gotten ahci working, I decided to take a stab at that again - all that was really required was adding it to the modules line in mkinitcpio - adding it to my rc.conf modules array was not enough, I guess. Once I did that, I still had issues until I removed the earlymodules=piix line from my grub options. Now burns start after a few seconds rather than sitting idle for nearly a minute, and I have an sg and an sr device for my (ide) burner. I'm holding off on calling this "fixed" until I have some more time to dick with it, but I did solve at least one issue (no ahci).
EDIT: FWIW it is not fixed - I'm still burning a ton of coasters, and I guess the quick start time was a fluke since it's back to a minute plus before burns start, if they even do. I'm having the same problems with the beyond kernel as well.
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
I had similar problems when I forgot to enable DMA on my drives..... just use hdparm -d1 /dev/xdx
James
Offline
I had similar problems when I forgot to enable DMA on my drives..... just use hdparm -d1 /dev/xdx
James
On sata drives? I was under the impression you couldn't set hdparm on sata.
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
Well, the issue is not fixed, unfortunately. Still having the exact same problems.
Iphitus - I tried setting the hd parm on the DVDRW drive and got this error:
/dev/sr0:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Function not implemented
or:
/dev/sg0:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
Ah well, I'll see if switching spindles helps any.
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
I have exactly the same problem here, but also no solution. :?:
Offline
Dec 17 22:57:30 pinkwater ide: failed opcode was: unknown Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown ...snip...
The last time I got these errors it was from a bad eide cable. It would operate intermitantly with DMA errors all the time as well as those drive ready seeks above. You may want to double check that if you haven't already.
Offline
Same thing here, 50% coasters after 2.6.19 (pata_via) and switch to cdrkit, happens for a friend of mine as well, with completely different hardware. I don't know if it's .19, pata or cdrkit messing up, didn't get much in the way of helpful errors, but I'll try and switch a few things around. And ya, halfway through a spindle which worked perfect before.
I'm inclined just waiting for next cdrkit and .20 before trying again, maybe the problem fixes itself, annoying.
Offline
I'm stumped. I've tried everything I can think of, and I'm still having the same issue. I can only assume it's some change in 2.6.19. I did swap out the IDE cable, but it didn't improve anything (I only got those errors when I was using earlymodules=piix in any event). What's really strange is how intermittent the issue is - I'd certainly agree that it *sounds* like failing hardware or bad discs, but it really doesn't seem to be the case. The reason I say this is:
I can burn discs from this same spindle with 100% success on other boxen using different OSes or versions of Linux.
When I threw an old hard drive I had with an earlier version of Arch on it into this same case, I had none of the problems I'm having now. Burns start in 15 to 30 seconds, not 1 minute or more, and I didn't burn a single coaster out of 5 test DVDs.
I'll just give it a while, I guess. Thanks for the input everyone!
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
Huh - T-Dawg posted a link to a post I'd made a while back about a spindle of Verbatim I had that would only burn at 8X instead of 16x - I'd completely forgotten about that, and had given that spindle to my brother. Truthfully, though, those would fail in an entirely different way - they'd actually burn a portion of the disc, but would barf about halfway through unless I downgraded the speed to 8x. I'd chalked those up to being mislabeled as 16x since 8x burned more or less flawlessly.
Maybe Verbatim are starting to churn out garbage discs? Maybe this particular burner doesn't get along well with Verbatim discs? I've got another DVD-RW drive in the mail (LG - yeah, I know not top of the line, but I've had good luck with LG for years), and I'll pick up a completely different type of media and see if that makes any difference. I also see that there is a firmware update for my drive, so I'll give that a shot too. All I can say is that this is puzzling.
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
To pick up on hdparm ... what does 'hdparm -i /dev/<burner>' (and maybe your hdd too) tell you? I noticed that with 2.6.19 some device/controller combinations seem use a slower UDMA mode or even disable DMA completely, and for me that is true for both libata and ide.
1000
Offline
I'm having the same problem here. I guess it happens since the PATA stuff.
All your base are belong to us
Offline
Snarkout wrote:Dec 17 22:57:30 pinkwater ide: failed opcode was: unknown Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown Dec 17 22:57:32 pinkwater hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } Dec 17 22:57:32 pinkwater ide: failed opcode was: unknown ...snip...
The last time I got these errors it was from a bad eide cable. It would operate intermitantly with DMA errors all the time as well as those drive ready seeks above. You may want to double check that if you haven't already.
I had the exact errors _when_ using hdparm a while ago... After disabling all hdparm-tweaks there were no errors anymore, and the kernel also found out the correct values for my drives automatically.
want a modular and tweaked KDE for arch? try kdemod
Offline
I had the exact errors _when_ using hdparm a while ago... After disabling all hdparm-tweaks there were no errors anymore, and the kernel also found out the correct values for my drives automatically.
Which tweaks? Were these ones you had put in place? I haven't tweaked hdparm at all on this drive. I kind of doubt it's an hdparm issue since it fails about the same % of the time as /dev/hda as it does /dev/sr0. When the drive is forced to /dev/hda with earlymodules=piix the crashes tend to require a reboot, though.
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
I did an -Syu today and got a new kernel and cdkit - so far things seem much better. I'll still have to see what shakes loose for a while, but 9 test burns and 9 successes is much better than I was doing before the upgrade.
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
The problem is that you are using the wrong tools for the job. I am surprised that you even get 50% of the coasters that you place in your dvd drive to burn. All you need is a simple lighter and I can guarantee you a much higher burn rate (close to 100%). Plus, you will not have to worry about possibly catching your whole computer on fire as well. If you HAVE to have something on your computer burn the coaster, you could also use a usb powered cigarette lighter like what is found here: http://www.clickonit.com/product.php?product=132069
Offline
Hello,
I've got exactly the same issue. the messages in dmesg, the dvd-burner lock...
So far, I don't even installed hdparm.
I'm up to date (using cdrkit 1.1.2-1 kernel26-2.6.19.2-1).
What should I do ? I've got every 2 month I wan't to use my burner an upgrade issue :cry:
Offline
If you were having better luck before 2.6.19 then why not downgrade the kernel?
Offline
Because I didn't use my burner since 2 month, and I don't know to which kernel version I should downgrade.
I don't have the kernel package anymore in cache, and I don't wan't to try and break some other stuff :cry:
Basicaly, I'm just too afraid to downgrade. I've seen that some peoples have found a fix, but I don't know how.
Offline
Oliv:
I haven't decided if this is fixed for me or not, FWIW, it just seems better. I've been fooled before, though, and haven't had much time to dick with it since my last post. Please be specific about your issue, though, and also please provide some hardware info. Several people have had issues with DVD/CD burning recently, but it turns out that there have also been several different issues, some of which are not new at all. I can't even say what the issue I'm experiencing is being caused by, TBH.
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
Don't think this will fix everyone's problem but for me it has worked, for some reason when I tried to burn a disk it would bomb out when 95% done, This was with trying to burn an iso image or a normal data cd and audio disks, I found that if I changed the writing mode from Auto to DAO for iso it works, and TAO for the others it works also. This is with k3b and I also added myself to a burning group. I've had a perfect run doing this so far.
"When once you have tasted flight, you will forever walk the earth with your eyes turned skyward, for there you have been, and there you will always long to return."
Offline