Bug 440343
| Summary: | k3b fails to verify written data: "No tracks to verify found" | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael Schwendt <bugs.michael> |
| Component: | k3b | Assignee: | Roman Rakus <rrakus> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 11 | CC: | agk, airfullbete, bill, brentrbrian, cpanceac, fedora, horsley1953, i.mortimer, juhani.jaakola, landonmkelsey, lazlow, matt, m.chattle, mesat, mihailim, mishu, pcfe, pjs1, rafalzaq, rdieter, robatino, rrakus, smparrish, tsmetana, ttn, zero456 |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 1.0.5-9.fc9 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-07-01 13:12:19 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 444344 | ||
| Attachments: | |||
|
Description
Michael Schwendt
2008-04-02 23:04:33 UTC
I have seen the exact same behavior with all the .24 kernels(up to 2.6.24.4-64.fc8 so far). I can burn the exact same iso on the same disk (rw) with .23 without issue. I am on 64bit F8. *** Bug 430656 has been marked as a duplicate of this bug. *** With F9-Beta the "verify written data" step fails earlier, directly after automatically ejecting+reloading the tray: "No tracks to verify found." $ uname -r 2.6.25-0.121.rc5.git4.fc9 Needless to say, the burnt CD is fine (and readcd can confirm that without problems). Another test, since I just had to burn a CD-RW:
kernel-2.6.23.15-137.fc8 : SUCCESS
kernel-2.6.24.4-64.fc8 : FAILURE
With the presumably bad kernel, the only difference in k3b debug
output is this after reloading the tray for verification:
(K3bDevice::ScsiCommand) failed:
command: SET SPEED (bb)
errorcode: 70
sense key: NOT READY (2)
asc: 3a
ascq: 0
Followed by a couple of:
(K3bDevice::ScsiCommand) failed:
command: READ (10) (28)
errorcode: 70
sense key: NOT READY (2)
asc: 3a
ascq: 0
(K3bDevice::Device) /dev/sr0: READ 10 failed!
They don't appear in the good-kernel-k3b-output.
I was only able to do a short test, because I've had problems to install a 2.6.23 on my normal machine. And I only had access to this test machine this sunday. Test was done with k3b-1.0.4-5.fc8 on i386. Media was Fedora-8-i386-rescuecd.iso and a CD-RW. Kernel: 2.6.24.3-34.fc8 k3b: verify failed SHA1SUM: ok 2.6.24.4-64.fc8 k3b: verify failed SHA1SUM: ok Kernel: 2.6.23.15-137.fc8 k3b: verify succeeded SHA1SUM: ok Oh, sorry. This was intended to be a answer to https://bugzilla.redhat.com/show_bug.cgi?id=430656#c6 Rawhide/F9 still affected, too (as in comment 3): kernel-2.6.25-0.234.rc9.git1.fc9.i686 k3b: No tracks to verify found. Looks like bug 444344 may be a duplicate of this. I just had the same issue. First time I tried to burn to a DVD since getting
this computer. After burning the downloaded ISO image using k3b, the verify
failed. I checked the checksum using
sha1sum /dev/sr0
was different than the source sha1sum.
I burned the ISO image using
wodim -v dev=/dev/cdrom driveropts=burnfree CAELinux2008.iso
and then ejected and reloaded media and finally confirmed the sha1sum.
[rlaing@eagle1 TEST]$ sha1sum /dev/sr0
b207d27d9803487e332ad5f372a22e74dd14cc6f /dev/sr0
[rlaing@eagle1 TEST]$ sha1sum CAELinux2008.iso
b207d27d9803487e332ad5f372a22e74dd14cc6f CAELinux2008.iso
kernel-2.6.24.4-64.fc8
k3b-1.0.4-5.fc8
Hope this gets fixed soon.
I couldn't find anything in the log files.
Two DVD-R and one DVD-RW failed with k3b. No issues using wodim.
No messages in k3b's lastlog.log file.
"sha1sum /dev/sr0" is not reliable, though it might by luck work on some hardware. To check reliably, you need to know the exact size of the ISO, which you can do using the isoinfo command, then read off that exact size using dd. The rawread script from http://www.troubleshooters.com/linux/coasterless.htm does this automatically, it's just an 18-line Bourne shell script. (I tried using readcd to do the same thing but couldn't figure out the proper usage.) To be sure that wasn't why the original DVD failed to verify, try that instead. readcd dev=/dev/scd0 then '11' and RETURN several times as all defaults are appropriate. Doesn't work. For the Fedora 8 i386 DVD, it returns a file of 3424911360 bytes instead of the correct size of 3424749568 bytes for Fedora-8-i386-DVD.iso, which rawread handles properly. The two files match up to the size of the smaller one, but sha1sum won't work properly with the extra padding. This is the same problem I had earlier, which caused me not to use readcd. Is there another way to get readcd to get the exact-size file without the padding? If not, maybe this should be reported as a bug or RFE against wodim (the package that readcd belongs to). I refer to the working _old_ kernel at the top of this ticket. Here: | Enter selection: 0 (0 - 20)/<cr>:11 | Capacity: 1672241 Blocks = 3344482 kBytes = 3266 MBytes = 3424 prMB | Sectorsize: 2048 Bytes which is 3424749568 with F8 i386 DVD. The size you refer to is 79 sectors more than that. Strange. Anyway, bugzilla is inappropriate for long discussions. Let's not flood this bug report with too many comments. Problems related to padding instead of DAO/SAO-mode writing are not interesting either. Something in the 2.6.24* kernels breaks k3b image verification. I downloaded K9 at a time when 1000000000 other people were doing the same. The sha1sum test passed. I burned 4 copies with K3B. Burning an ISO image with verification fails prob because the image does not compare to "files" However, using kdiff3, I verified that all 4 copies are identical. Thank heavens for kdiff3!!! k3b also failed to copy a single track from JS Bach's St Matthew's Passion! I forced it to work and the CD does not work in any device except the computer! 2.6.24.7-92.fc8 still has the problem. 2.6.25.4-10.fc8 seems to have a new variant on the issue. When the drive opens after the write (but before it starts to verify), it spits out an error unable to access drive. I get the same in Fedora 9 i386 with ordinary PC and LiteOn DH20A3P. Verify fails with "No tracks to verify found." before even trying. k3b-1.0.4-6.fc9.i386 kernel-2.6.25.4-30.fc9.i686 Same again on another machine running Fedora 9 x86_64. Also Settings->Advanced->Do not eject has no effect: it still ejects. Since the recent KDE updates (yesterday), K3b on F9 won't burn anything now, as well as the "No tracks to verify found" problem. It keeps coming up with write error message, and ejects the medium. (In reply to comment #18) > Since the recent KDE updates (yesterday), K3b on F9 won't burn anything now, as > well as the "No tracks to verify found" problem. It keeps coming up with write > error message, and ejects the medium. Further testing revealed that F9 doesn't work with my Optiarc DVD writer. I know the device works because I tested it on another system just in case. I installed an old CD burner that I know is working, instead of the Optiarc, and K3b now works again. The Optiarc kept producing 'write error' and 'input/output' errors. *** Bug 444344 has been marked as a duplicate of this bug. *** *** Bug 446340 has been marked as a duplicate of this bug. *** Kernel-2.6.25.6-27.f8 is now down to No Tracks found. Disks are of course just fine. This has become a real PITA. I HAVE to verify the disks I burn. This means that I am still running 2.6.23.15-137.fc8. If you need us to provide some more information or to try something then just ask. Michael Schwendt Can you bump the severity of this up, please? It will not allow me to do so as you are the starter of the bug. Bug was set to ASSIGNED by John Poelstra on 2008-04-21. Perhaps John has news for us or any questions? [somebody closed bug 444344 (k3b) as duplicate, so I re-added the external KDE ticket here] [severity is ignored by many unless set by maintainers themselves] Once triaged a bug moves to ASSIGNED. https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow Michael Schwendt pointed out: "k3b 1.0.5 changelog says: * Always wait for the drive to become ready before starting verification." I'm spinning some k3b-1.0.5 builds so people can test: F-8: http://koji.fedoraproject.org/koji/buildinfo?buildID=53847 F-9: http://koji.fedoraproject.org/koji/buildinfo?buildID=53848 feedback appreciated. Still same error here on: Installed Packages Name : k3b Arch : x86_64 Version: 1.0.5 Release: 2.fc8 Size : 27 M Repo : installed [fred@localhost ~]$ uname -a Linux localhost.localdomain 2.6.25.6-27.fc8 #1 SMP Fri Jun 13 16:17:54 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux Thanks for trying Progress here: 2x success with CD-RW Fedora 8 i686 k3b-1.0.5-2.fc8 kernel-2.6.25.6-27.fc8 With k3b-1.0.4-5.fc8 as double-check, "No tracks to verify found." k3b 1.0.5 is very nervous when reloading the disc. It immediately opens a dialog "No medium present". I let it auto-close itself each time. there are many reports on the web suggesting the problem is (or was) wodim. google "k3b fail to verify cd wodim" btw, it's happening on f9 too. $ rpm -q wodim wodim-1.1.6-11.fc9.i386 while on homepage http://www.cdrkit.org/ "2008/03/17 Cdrkit 1.1.7.1 has been released." If wodim is to blame why would the same version work fine with the .23 kernel (just boot to different kernel no other change)? Re: comment 29 There is cdrkit 1.1.8 already from end of May. It's included in Fedora Development. That Fedora 9 is affected has been mentioned early on in this ticket. New comments at http://bugs.kde.org/show_bug.cgi?id=157186#c12 say that this bug is still reproducible in k3b 1.0.5 with Debian. (In reply to comment #26) > Michael Schwendt pointed out: > "k3b 1.0.5 changelog says: > * Always wait for the drive to become ready before starting verification." > > I'm spinning some k3b-1.0.5 builds so people can test: > > F-8: http://koji.fedoraproject.org/koji/buildinfo?buildID=53847 > F-9: http://koji.fedoraproject.org/koji/buildinfo?buildID=53848 > > feedback appreciated. Success: disc load window popped up and automatically disappeared. F9 with kernel 2.6.25.6-55.fc9.x86_64, k3b-1.0.5-2.fc9.x86_64 Old k3b-1.0.4-6 failed with no tracks to verify in a test just minutes before installing the new rpm. Still fails to verify data with the error message "No tracks to verify found" on the K3b F9 respin F-9: http://koji.fedoraproject.org/koji/buildinfo?buildID=53848 (k3b-1.0.5-2.fc9.i386.rpm). Data burns successfully, and CD drawer opens after burn, but closes ready for verify and immediately on the drawer closing, the error message comes up, as before. On checking the data on the DVD manually, all data have burned successfully to the DVD (DVD+RW). System: F9 on an i686, Pentium 4 1800, LG DVD burner, 750MB memory, kernel-2.6.25.6-55.fc9.i686.rpm All the latest F9 package updates applied as of 30/06/2008 I am also using an LG burner. How about you Michael Schwendt and others? LG (GSA-H10N) LiteOn 20A3P has this problem (can't test k3b-1.0.5-2.fc9.x86_64 fix yet) and yet my NEC ND-4570A on an identical machine/OS has no problem at all. LiteOn LH-20A1P has this problem and is fixed by k3b-1.0.5-2.fc9.x86_64. I don't know if anyone else has tested it, but I tried the package k3b-1.0.5-3.fc9.i386.rpm, which was on the F9 testing repository last evening, and it seems to fix the verify problem in F9. It pops up an extra window telling me to load the disk that has just been burned, but it automatically loads it after a second or two, then successfully verifies the data. 1.0.5-3.fc6.64bit still fails here. I get the popup window, it automatically reloads the disk, and then it fails "No track found to verify". linux localhost.localdomain 2.6.25.9-40.fc8 #1 SMP Fri Jun 27 16:05:49 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux New kernel did not help either. Same error but did not see popup this time. 1.0.5-4.fc8.64bit still fails here. No tracks to verify. Post #39 should have been FC8 too. Fedora 8 / k3b-1.0.5-3.fc8 / kernel-2.6.25.9-40.fc8 It is still happening to me, as well -- most of the time. Roughly 75% of my DVD-R burns, the burn will complete, k3b will eject & reload the disc, and then spit out the "No tracks found to verify" message. But 25% of the burns will successfully recognize the burned disc and successfully verify it. What I have noticed lately, in general, is that it is taking longer for the system to recognize & mount DVD media after the tray is closed. This has affected not only k3b for me, but also some shell scripts I'd written years ago to mount & read from DVD-R. In my scripts, I had to add a 10-second sleep between "eject -t" and "mount" to allow the disc to be recognized. Maybe this is affecting k3b too. Perhaps a configurable delay could be added to the verifications process to allow k3b more time to see the disc after reclosing the tray? Just a thought. My drive is a "LITE-ON DVDRW LH-20A1P KL05" 2.6.25.10-47.fc8 #1 SMP Mon Jul 7 18:31:41 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux and 1.0.5-4 still gives the No tracks to verify. Created attachment 312432 [details]
k3b output into a terminal when run from command line
Hopefully the above attachemnt gives more insight into what goes wrong with k3b burn/verify. I just happened to run k3b from command line and got he output just attached (there would appear to be problems with HAL with k3b). Additional info: --- [ttn@mad112g ~]$ uname -a Linux mad112g.cc.jyu.fi 2.6.25.9-40.fc8 #1 SMP Fri Jun 27 16:25:53 EDT 2008 i686 i686 i386 GNU/Linux [ttn@mad112g ~]$ [ttn@mad112g ~]$ rpm -qa|grep k3b k3b-extras-nonfree-1.0.3-1.lvn8 k3b-1.0.5-3.fc8 [ttn@mad112g ~]$ --- Created attachment 312475 [details]
another output from k3b with "no tracks to verify" (no HAL erros this time)
The HAL problem seemed to go away with a reboot (kernel appears to have been
updated since last reboot:). No tracks to verify in k3b still persists though.
Here's another output from terminal of k3b failing to find any tracks to
verify.
Version details below:
---
[ttn@mad112g ~]$ uname -a
Linux mad112g.cc.jyu.fi 2.6.25.10-47.fc8 #1 SMP Mon Jul 7 18:39:51 EDT 2008
i686 i686 i386 GNU/Linux
[ttn@mad112g ~]$ rpm -qa|grep k3b
k3b-extras-nonfree-1.0.3-1.lvn8
k3b-1.0.5-3.fc8
[ttn@mad112g ~]$
---
PS. The burnt DVD still automounts and would appear to be ok.
Linux localhost.localdomain 2.6.25.11-60.fc8 #1 SMP Mon Jul 21 01:40:51 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux k3b-1.0.5-4.fc8 No tracks found to verify. Linux localhost.localdomain 2.6.25.14-69.fc8 #1 SMP Mon Aug 4 14:00:45 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux Still the same, no tracks to verify found. If you guys need any more information just ask. $ rpm -q kernel kernel-2.6.26.3-12.fc8 "No tracks to verify found" has returned. Linux localhost.localdomain 2.6.26.3-14.fc8 #1 SMP Wed Sep 3 03:17:52 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux "No tracks to verify found". Name : kernel Arch : x86_64 Version : 2.6.26.5 Release : 28.fc8 "No tracks to verify found". (In reply to comment #46) > Created an attachment (id=312475) [details] > another output from k3b with "no tracks to verify" (no HAL erros this time) > > The HAL problem seemed to go away with a reboot (kernel appears to have been > updated since last reboot:). No tracks to verify in k3b still persists though. > Here's another output from terminal of k3b failing to find any tracks to > verify. > > Version details below: > > --- > [ttn@mad112g ~]$ uname -a > Linux mad112g.cc.jyu.fi 2.6.25.10-47.fc8 #1 SMP Mon Jul 7 18:39:51 EDT 2008 > i686 i686 i386 GNU/Linux > [ttn@mad112g ~]$ rpm -qa|grep k3b > k3b-extras-nonfree-1.0.3-1.lvn8 > k3b-1.0.5-3.fc8 > [ttn@mad112g ~]$ > --- > > PS. The burnt DVD still automounts and would appear to be ok. > It seems (for me at least) that the verify problem only occurs with DVDs - CDs burn and verify ok with k3b. T:Tero I had accumulated enough data to fill a backup DVD, so I decided to try my F10 beta rawhide system with k3b to see how things work with latest kernel. It wrote all the data, ejected the disk, then the disk stayed ejected. I tried pushing the try back in manually, but k3b was completely hosed at 100% cpu, pushing the tray back in didn't do anything to help. I had to kill -9 the k3b process. This is a 64 bit system, the kernel and k3b installed are: kernel-2.6.27.4-47.rc3.fc10.x86_64 k3b-1.0.5-6.fc10.x86_64 By the way, eject -T can correctly both eject and reload the dvd drive on this system, so I'm not sure why k3b wasn't able to reload the disk. I just finished a comparison of checksums, and in addition to the problem with doing the verify, I get an I/O error when I try to read one of the files from the DVD (all the others read OK and match the checksums). This was a dual layer DVD-R, possibly the file with the I/O error crosses layers? (Not sure how to tell the physical layout). Tried another dual layer writing experiment again, this time on 32 bit fedora 10 beta: kernel-2.6.27.4-68.fc10.i686, k3b-1.0.5-6.fc10.i386. Once again it wrote all the data, ejected the tray, then never reloaded the tray in order to do the verify. Pushing the tray back in manually didn't help, mounting the media manually didn't help, it just never started the verify operation. Unlike the previous experiment, it didn't go into an infinite CPU loop. The GUI remained responsive to things like the cancel button, but it just never started the verify. Also the write was completely successful this time. A manual comparison of the sha1sum for all the files on the DVD and the originals from the had disk shows a perfect match, so that is better than the previous experiment. (Don't know if this was media related, I was using 8x DVD+R DL this time instead of DVD-R DL). I'll attach an strace of a few seconds of it sitting around not doing the verify in case that can tell anyone anything, and also the debug output from k3b saved after cancelling the verify operation. Created attachment 322185 [details] strace output from k3b as mentioned in comment #54 Created attachment 322186 [details] debug output from k3b as mentioned in comment #54 This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping reassigning -> rawhide, still hearing reports of this on fedora-test list. I upgraded from Fedora 7 to Fedora 9 and K3B verify does not work any more! If I burn a DVD, the disc is ejected and is never reloaded, so verify fails. If I verify the files manually afterwards they are all OK. Then I checked option "Do not eject medium after write process" and then I burned the F10 CD image. I got error "No tracks to verify found". Afterwards command "cmp /dev/cdrom F10-i686-Live.iso" does not find any differences. Command "eject -T" is able to eject and reload the disc. My system is fully updated but I'm using kernel 2.6.25-14.fc9.i686 because the newer kernels break my rt2500pci network and bluetooth browsing... This is my third major bug with Fedora 9! $ uname -a Linux tik.jsoft.fi 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT 2008 i686 athlon i386 GNU/Linux $ rpm -qa | grep k3b k3b-1.0.5-3.fc9.i386 k3b-extras-freeworld-1.0.5-4.fc9.i386 $ rpm -q hal hal-0.5.11-2.fc9.i386 For those of you reporting failure to verify/reload, if you haven't done so already, please provide the make/model of your burner. My CD/DVD burner is: $ dmesg | grep 1:0:0:0 scsi 1:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4167B DL10 PQ: 0 ANSI: 5 sr 1:0:0:0: Attached scsi CD-ROM sr0 sr 1:0:0:0: Attached scsi generic sg1 type 5 K3B shows this in its log: HL-DT-ST DVDRAM GSA-4167B DL10 (/dev/sr0, ) [CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R DL, DVD+R, DVD+RW, DVD+R DL] [DVD-ROM, DVD-R Sequential, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RAM, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Restricted Overwrite] There seems to be one consistency for me in F9 which might be of interest. When I burn a DVD, I first make sure there is enough RAM, restarting Konqueror if necessary. Next I press the burn menu button in k3b to get the burn dialog and then physically load the DVD. The important bit is that I don't actually press burn in the burn dialog window until the Devices recently plugged in pop up window has displayed AND DISAPPEARED. If I press burn before it goes away, I frequently have failures to verify. If I wait till it disappears, it will verify OK. This may be some localized effect on my box only, but it does seem remarkably consistent here. My current symptom continues to be that k3b ejects the tray after writing, then never reloads it. Meanwhile k3b itself goes into a 100% cpu bound state (I checked with strace - it is not making any system calls). This is on x86_64 fedora 10 with a dvd writer that calls itself: TSSTcorp CDDVDW SH-S203N I'm using Circuit City NEXXTECH DVD+R DL media at the moment. The actual writing always seems to be successful as verified after the fact by checksum comparisons of the individual files. Today, I wrote another dvd with identical results as comment #63 above, but today I had free time to download a batch of debuginfo rpms and attach to k3b and find out what the heck it was doing. I was watching when it finished writing the DVD and the 100% cpu spike hit instantly as soon as it ejected the media. At the micro level, I found it executing this 4 instruction loop it will clearly take a while to get out of: x/4i $pc _ZN18K3bVerificationJob9readTrackEi+1128: 378= 0x0000003fc37c1558 <+1128>: addq $0x1,%rdx 379 0x0000003fc37c155c <+1132>: movq (%rax),%rax 378 0x0000003fc37c155f <+1135>: cmpq %rdx,%r14 378 0x0000003fc37c1562 <+1138>: ja 0x3fc37c1558 <+1128> # aka: jnbe p/x $rdx $3: $rdx = 0x27283bcc690 p/x $rax $4: $rax = 0x2d96b50 x/1x $rax 0x02d96b50: 0x0000000002d96b50 p/x $r14 $5: $r14 = 0xffffffffffffffff I suppose $rdx will eventually wrap around to -1, but in the time it took to download and install the debuginfo rpms and attach to the process, it apparently only made it to 0x27283bcc690, so it still has a ways to go. If you trust the debuginfo generated by g++ (always a risky proposition :-), that corresponds to the loop in this template: template <class T> Q_INLINE_TEMPLATES Q_TYPENAME QValueListPrivate<T>::NodePtr QValueListPrivate<T>::at( size_type i ) const { Q_ASSERT( i <= nodes ); NodePtr p = node->next; for( size_type x = 0; x < i; ++x ) p = p->next; return p; } Apparently p->next == p, so that will go for a while without hitting a NULL pointer or anything like that. And that was invoked somewhere (directly or indirectly) on this line if( d->toc[d->tracks[trackIndex].trackNumber-1].type() == K3bDevice::Track::DATA ) { which is in the void K3bVerificationJob::readTrack( int trackIndex ) function. (I'm getting the impression it believes it has already started the verify, even though it never appeared to make any attempt to reload the DVD). At the macro level, the walkback looks like: #0 0x0000003fc37c1558 in QValueList<K3bVerificationJobTrackEntry>::operator[]( unsigned long long i = cannot retrieve value) at qt-3.3/include/qvaluelist.h line 378 #1 0x0000003fc37c1558 in K3bVerificationJob::readTrack( int trackIndex = 1750384256) at k3bverificationjob.cpp line 243 #2 0x0000003fc37c263f in K3bVerificationJob::slotDiskInfoReady( class K3bDevice::DeviceHandler * dh = 0x7f226853d9b0) at k3bverificationjob.cpp line 224 #3 0x0000003fc37c2877 in K3bVerificationJob::qt_invoke( int _id = 15, struct QUObject * _o = 0x7fff767386c0) at k3bverificationjob.moc line 147 #4 0x0000003fc15605bc in QObject::activate_signal( class QConnectionList * clist = 0x7f22681f2c10, struct QUObject * o = 0x7fff767386c0) at qobject.cpp line 2359 #5 0x0000003fc377e4e8 in DeviceHandler::finished( class K3bDevice::DeviceHandler * t0 = 0x7f2268558b40) at k3bdevicehandler.moc line 126 #6 0x0000003fc378013e in DeviceHandler::customEvent( class QCustomEvent * e = 0x7f22681f7b90) at k3bdevicehandler.cpp line 319 #7 0x0000003fc156070b in QObject::event(class QEvent * e = 0x7f22681f7b90) at qobject.cpp line 758 #8 0x0000003fc14fecc2 in QApplication::internalNotify( class QObject * receiver = 0x7f2268558b40, class QEvent * e = 0x7f22681f7b90) at qapplication.cpp line 2638 #9 0x0000003fc14ffc71 in QApplication::notify( class QObject * receiver = 0x7f2268558b40, class QEvent * e = 0x7f22681f7b90) at qapplication.cpp line 2361 #10 0x0000003fc31d703d in KApplication::notify( class QObject * receiver = 0x7f2268558b40, class QEvent * event = 0x7f22681f7b90) at kapplication.cpp line 550 #11 0x0000003fc1500b34 in QApplication::sendEvent( class QObject * receiver = cannot retrieve value, class QEvent * event = cannot retrieve value) at kernel/qapplication.h line 523 #12 0x0000003fc1500b34 in QApplication::sendPostedEvents( class QObject * receiver = 0, int event_type = 0) at qapplication.cpp line 3302 #13 0x0000003fc14ad018 in QEventLoop::processEvents(unsigned int flags = 4) at qeventloop_x11.cpp line 147 #14 0x0000003fc15175fb in QEventLoop::enterLoop() at qeventloop.cpp line 201 #15 0x0048c04e in K3bJobProgressDialog::startJob( class K3bJob * job = 0x2d8e300) at k3bjobprogressdialog.cpp line 622 #16 0x0055a6a7 in K3bProjectBurnDialog::slotStartClicked() at k3bprojectburndialog.cpp line 239 #17 0x00587d6f in K3bDvdBurnDialog::slotStartClicked() at k3bdvdburndialog.cpp line 297 #18 0x0047cafc in K3bInteractionDialog::slotStartClickedInternal() at k3binteractiondialog.cpp line 346 #19 0x0047d013 in K3bInteractionDialog::qt_invoke( int _id = 79, struct QUObject * _o = 0x7fff767391e0) at k3binteractiondialog.moc line 254 #20 0x0000003fc15605bc in QObject::activate_signal( class QConnectionList * clist = 0x2cd6260, struct QUObject * o = 0x7fff767391e0) at qobject.cpp line 2359 #21 0x0000003fc1561efd in QObject::activate_signal(int signal = 69) at qobject.cpp line 2328 #22 0x0000003fc1598207 in QWidget::event(class QEvent * e = 0x7fff76739660) at qwidget.cpp line 4705 #23 0x0000003fc14fecc2 in QApplication::internalNotify( class QObject * receiver = 0x2d00e10, class QEvent * e = 0x7fff76739660) at qapplication.cpp line 2638 #24 0x0000003fc14ffe2a in QApplication::notify( class QObject * receiver = 0x2d00e10, class QEvent * e = 0x7fff76739660) at qapplication.cpp line 2424 #25 0x0000003fc31d703d in KApplication::notify( class QObject * receiver = 0x2d00e10, class QEvent * event = 0x7fff76739660) at kapplication.cpp line 550 #26 0x0000003fc149d148 in QETWidget::translateMouseEvent( const union _XEvent * event = 0x3) at qapplication_x11.cpp line 4339 #27 0x0000003fc149c0bb in QApplication::x11ProcessEvent( union _XEvent * event = 0x7fff76739b70) at qapplication_x11.cpp line 3603 #28 0x0000003fc14ad0b2 in QEventLoop::processEvents(unsigned int flags = 4) at qeventloop_x11.cpp line 195 #29 0x0000003fc15175fb in QEventLoop::enterLoop() at qeventloop.cpp line 201 #30 0x0048aeb3 in K3bInteractionDialog::exec(bool returnOnHide = true (69)) at k3binteractiondialog.cpp line 592 #31 0x0054d0f1 in K3bDataView::slotBurn() at k3bdataview.cpp line 177 #32 0x00547736 in K3bView::qt_invoke( int _id = 46, struct QUObject * _o = 0x7fff76739d90) at k3bview.moc line 98 #33 0x0000003fc15605bc in QObject::activate_signal( class QConnectionList * clist = 0x7f2268215630, struct QUObject * o = 0x7fff76739d90) at qobject.cpp line 2359 #34 0x0000003fc1561efd in QPtrVector<QConnectionList>::at( unsigned int i = cannot retrieve value) at qobject.cpp line 2328 #35 0x0000003fc1561efd in QSignalVec::at( unsigned int index = cannot retrieve value) at kernel/qsignalslotimp.h line 86 #36 0x0000003fc1561efd in QObject::activate_signal(int signal = 69) at qobject.cpp line 2324 #37 0x0000003fc3e93067 in KAction::qt_invoke( int _id = 12, struct QUObject * _o = 0x7fff76739e60) at kaction.moc line 215 #38 0x0000003fc15605bc in QObject::activate_signal( class QConnectionList * clist = 0x7f2268211840, struct QUObject * o = 0x7fff76739e60) at qobject.cpp line 2359 #39 0x0000003fc1561efd in QPtrVector<QConnectionList>::at( unsigned int i = cannot retrieve value) at qobject.cpp line 2328 #40 0x0000003fc1561efd in QSignalVec::at( unsigned int index = cannot retrieve value) at kernel/qsignalslotimp.h line 86 #41 0x0000003fc1561efd in QObject::activate_signal(int signal = 69) at qobject.cpp line 2324 #42 0x0000003fc1598207 in QWidget::event(class QEvent * e = 0x7fff7673a2e0) at qwidget.cpp line 4705 #43 0x0000003fc14fecc2 in QApplication::internalNotify( class QObject * receiver = 0x7f22681c4000, class QEvent * e = 0x7fff7673a2e0) at qapplication.cpp line 2638 #44 0x0000003fc14ffe2a in QApplication::notify( class QObject * receiver = 0x7f22681c4000, class QEvent * e = 0x7fff7673a2e0) at qapplication.cpp line 2424 #45 0x0000003fc31d703d in KApplication::notify( class QObject * receiver = 0x7f22681c4000, class QEvent * event = 0x7fff7673a2e0) at kapplication.cpp line 550 #46 0x0000003fc149d148 in QETWidget::translateMouseEvent( const union _XEvent * event = 0x3) at qapplication_x11.cpp line 4339 #47 0x0000003fc149c0bb in QWidget::isDesktop() at qapplication_x11.cpp line 3603 #48 0x0000003fc149c0bb in QApplication::x11ProcessEvent( union _XEvent * event = 0x7fff7673a7f0) at qapplication_x11.cpp line 3569 #49 0x0000003fc14ad0b2 in QEventLoop::processEvents(unsigned int flags = 4) at qeventloop_x11.cpp line 195 #50 0x0000003fc15175fb in QEventLoop::enterLoop() at qeventloop.cpp line 201 #51 0x0000003fc15174bc in QEventLoop::exec() at qeventloop.cpp line 148 #52 0x004a032a in main( int argc = 1, char ** argv = 0x7fff7673aa00) at main.cpp line 150 #53 0x000000318fa1e572 in __libc_start_main( int (* main)() = 0x4a0060 main+0, int argc = 1, char ** ubp_av = 0x7fff7673acd8, int (* init)() = 0x5afd70 __libc_csu_init+0, void (* fini)() = cannot retrieve value, void (* rtld_fini)() = cannot retrieve value, void * stack_end = 0x7fff7673acc8) at libc-start.c line 220 bug 457441 deals with the rt2500pci issue, if you are interested We're seeing the same issue of 100% CPU in K3bVerificationJob::readTrack, with: Updated Fedora 10 x64 k3b 1.0.5-6.fc10 kernel 2.6.27.21-170.2.56.fc10.x86_64 LG DVDRAM GSA-4167B burner DVD-R media There was a >2GB file, so k3b prompted something about UDF - no idea if that is relevant. There is a request from [upstream] Sebastian Trüg "to test with K3b 1.65.0". This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping In the interests of science, I just tried to write a DVD-R in my newly installed fedora 11 system, and I get the same failure mode as always. It gets to the verify step, ejects the disk, and never reloads it, going into a 100% cpu loop instead of doing anything useful. This is with: k3b-1.0.5-8.fc11.x86_64 kernel-2.6.29.4-167.fc11.x86_64 Also as always, verifying the files by hand shows that the write worked fine. k3b-1.0.5-9.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/k3b-1.0.5-9.fc11 k3b-1.0.5-9.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/k3b-1.0.5-9.fc9 k3b-1.0.5-9.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/k3b-1.0.5-9.fc10 Just updated to k3b-1.0.5-9.fc11 with k3b-libs-1.0.5-9.fc11.i586.rpm on an Intel 875 motherboard, and LG DVD burner using a re-writable DVD and tracks were successfully verified. K3b appears to prevent ejecting the media after burning to allow verification. This seems to be a good fix to the verifying data problem, at least in F11. k3b-1.0.5-9.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update k3b'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-6524 On F11, k3b-1.0.5-9.fc11.x86_64 still doesn't verify the data. I just downloaded and tried to run this version. It was better than k3b-1.0.5-8.fc11.x86_64 which just stopped. Now at least the DVD is ejected and reloaded before k3b freezes. ps aux shows robin 19387 24.7 1.5 568236 62116 ? Rl 21:32 4:47 /usr/bin/k3b What is interesting is k3b is using about 100% of one processor. 19387 robin 20 0 554m 60m 19m R 99.3 1.5 10:22.15 k3b strace -fp 19387 provides the attached file output. I hope this gets fixed. Created attachment 349506 [details] strace output - Comment #75 k3b-1.0.5-9.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. k3b-1.0.5-9.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report. k3b-1.0.5-9.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. Re-opened per comment #75 I just used k3b-1.0.5-9.fc11.x86_64 to successfully write a DVD+R DL disk and verify after writing! I can't even remember the last time that worked :-). I've got an atapi Pioneer DVD-RW DVR-117D drive now (the drive I had when I first chimed in to this bug died a while ago). Interesting. Let's go with closing this then, per the positive feedback, for anyone with remaining issues, please open a new bug. well, i believe cleaning up this issue is a good thing (by starting a new bug), but i'm not that sure the isse is fixed, because recently, more often than not, k3b verified the writing. however, i'm positive i've seen somewhere a message from sebastian trueg askin' for testing of this issue on recent builds of k3b, like 1.66.X. are somewhere fedora rpms for 1.6x series? k3b-1.6x builds are in rawhide, and kde-redhat/unstable repos for F-10/F-11 thnx a lot. I suspect that closing this bug is more about the politics than about technical matters. This bug has been open since F8 and there are MANY such bugs. Fedora has been taking a lot of heat about these "legacy" (multi release) bugs. When this bug is closed the problem will just sit (as this bug did for so long) and very little work is likely to be done on it until it reaches old age (like this bug). Brad, are you still having problems and/or can you contribute something constructive here? Yes, the bug still exists with me on F11 and 105-9, so does the disk transfer bug introduced in F7. To be clear, this is bug tracking the issue of getting the error: No tracks to verify found Are you still seeing this or something else? Using k3b-1.0.5-9.fc11.x86_64
KDE desktop fully updated.
I have been to busy to look into this until tonight.
Will not verify any DVD I have tried to record. Either Video or DATA DVD.
Program ejects the DVD and reloads only to have k3b freeze.
k3b won't redraw the screen as it is now just blank windows.
This is what was shown in the terminal window when I ran k3b
[robin@eagle1 ~]$ (K3bDevice::HalConnection) initializing HAL >= 0.5
Mapping udi /org/freedesktop/Hal/devices/storage_model_DVD_RAM_GSA_H54N to device /dev/sr0
/dev/sr0 resolved to /dev/sr0
/dev/sr0 is block device (0)
/dev/sr0 seems to be cdrom
bus: 6, id: 0, lun: 0
(K3bDevice::Device) /dev/sr0: init()
(K3bDevice::Device) /dev/sr0 feature: CD Mastering
(K3bDevice::Device) /dev/sr0 feature: CD Track At Once
(K3bDevice::Device) /dev/sr0 feature: DVD Read (MMC5)
(K3bDevice::Device) /dev/sr0 feature: DVD+R
(K3bDevice::Device) /dev/sr0 feature: DVD+RW
(K3bDevice::Device) /dev/sr0 feature: DVD+R Double Layer
(K3bDevice::Device) /dev/sr0 feature: DVD-R/-RW Write
(K3bDevice::Device) /dev/sr0 feature: Rigid Restricted Overwrite
(K3bDevice::Device) /dev/sr0 feature: Layer Jump Recording
(K3bDevice::Device) /dev/sr0 unknown profile: 2
(K3bDevice::Device) /dev/sr0: dataLen: 60
(K3bDevice::Device) /dev/sr0: checking for TAO
(K3bDevice::Device) /dev/sr0: checking for SAO
(K3bDevice::Device) /dev/sr0: checking for SAO_R96P
(K3bDevice::Device) /dev/sr0: checking for SAO_R96R
(K3bDevice::Device) /dev/sr0: checking for RAW_R16
(K3bDevice::Device) /dev/sr0: checking for RAW_R96P
(K3bDevice::Device) /dev/sr0: checking for RAW_R96R
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE dataLen = 72
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE successful with reported length: 68
(K3bDevice::Device) /dev/sr0: Number of supported write speeds via GET PERFORMANCE: 4
(K3bDevice::Device) /dev/sr0 : 22160 KB/s
(K3bDevice::Device) /dev/sr0 : 16620 KB/s
(K3bDevice::Device) /dev/sr0 : 11080 KB/s
(K3bDevice::Device) /dev/sr0 : 5540 KB/s
(K3bDevice::DeviceManager) setting current write speed of device /dev/sr0 to 22160
Could not resolve /dev/hdd
/dev/hdd resolved to /dev/hdd
(K3bDevice::Device) could not open device /dev/hdd for reading
(No such file or directory)
could not open device /dev/hdd (No such file or directory)
Could not resolve /dev/hdc
/dev/hdc resolved to /dev/hdc
(K3bDevice::Device) could not open device /dev/hdc for reading
(No such file or directory)
could not open device /dev/hdc (No such file or directory)
/dev/scd0 resolved to /dev/sr0
(K3bDevice::DeviceManager) dev /dev/sr0 already found
/dev/sr0 resolved to /dev/sr0
(K3bDevice::DeviceManager) dev /dev/sr0 already found
(K3bDevice::DeviceManager) found config entry for devicetype: HL-DT-ST DVD-RAM GSA-H54N
First sec data area: 43:41:33 (LBA 196608) (402653184
Last sec data area: 553:42:61 (LBA 2491711) (5103024128 Bytes)
Last sec layer 1: 00:00:00 (LBA 0) (0 Bytes)
Layer 1 length: 00:00:01 (LBA 1) (2048 Bytes)
Layer 2 length: 553:42:61 (LBA 2491711) (5103024128 Bytes)
DiskInfo:
Mediatype: DVD+R
Current Profile: DVD+R
Disk state: empty
Empty: 1
Rewritable: 0
Appendable: 0
Sessions: 0
Tracks: 0
Layers: 1
Capacity: 510:01:29 (LBA 2295104) (4700372992 Bytes)
Remaining size: 510:01:29 (LBA 2295104) (4700372992 Bytes)
Used Size: 00:00:00 (LBA 0) (0 Bytes)
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE dataLen = 72
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE successful with reported length: 68
(K3bDevice::Device) /dev/sr0: Number of supported write speeds via GET PERFORMANCE: 4
(K3bDevice::Device) /dev/sr0 : 22160 KB/s
(K3bDevice::Device) /dev/sr0 : 16620 KB/s
(K3bDevice::Device) /dev/sr0 : 11080 KB/s
(K3bDevice::Device) /dev/sr0 : 5540 KB/s
Devices:
------------------------------
Blockdevice: /dev/sr0
Generic device:
Vendor: HL-DT-ST
Description: DVD-RAM GSA-H54N
Version: 1.00
Write speed: 3324
Profiles: DVD-ROM, DVD-R Sequential, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RAM, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW
Read Cap: DVD-ROM, DVD-R, DVD-R Sequential, DVD-R Dual Layer, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RW, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+RW Dual Layer, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW
Write Cap: DVD-R, DVD-R Sequential, DVD-R Dual Layer, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RW, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-R, CD-RW
Writing modes: SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Restricted Overwrite, Layer Jump
Reader aliases: /dev/sr0, /dev/scd0
------------------------------
adding udi /org/freedesktop/Hal/devices/volume_empty_dvd_plus_r
First sec data area: 43:41:33 (LBA 196608) (402653184
Last sec data area: 553:42:61 (LBA 2491711) (5103024128 Bytes)
Last sec layer 1: 00:00:00 (LBA 0) (0 Bytes)
Layer 1 length: 00:00:01 (LBA 1) (2048 Bytes)
Layer 2 length: 553:42:61 (LBA 2491711) (5103024128 Bytes)
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE dataLen = 72
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE successful with reported length: 68
(K3bDevice::Device) /dev/sr0: Number of supported write speeds via GET PERFORMANCE: 4
(K3bDevice::Device) /dev/sr0 : 22160 KB/s
(K3bDevice::Device) /dev/sr0 : 16620 KB/s
(K3bDevice::Device) /dev/sr0 : 11080 KB/s
(K3bDevice::Device) /dev/sr0 : 5540 KB/s
(K3bDevice::HalConnection) lock queued for /org/freedesktop/Hal/devices/storage_model_DVD_RAM_GSA_H54N
(K3bDevice::HalConnection) unlock queued for /org/freedesktop/Hal/devices/storage_model_DVD_RAM_GSA_H54N
First sec data area: 43:41:33 (LBA 196608) (402653184
Last sec data area: 553:42:61 (LBA 2491711) (5103024128 Bytes)
Last sec layer 1: 00:00:00 (LBA 0) (0 Bytes)
Layer 1 length: 00:00:01 (LBA 1) (2048 Bytes)
Layer 2 length: 553:42:61 (LBA 2491711) (5103024128 Bytes)
DiskInfo:
Mediatype: DVD+R
Current Profile: DVD+R
Disk state: incomplete
Empty: 0
Rewritable: 0
Appendable: 1
Sessions: 1
Tracks: 1
Layers: 1
Capacity: 510:01:29 (LBA 2295104) (4700372992 Bytes)
Remaining size: 47:00:36 (LBA 211536) (433225728 Bytes)
Used Size: 463:00:68 (LBA 2083568) (4267147264 Bytes)
(K3bDevice::Device) /dev/sr0 current profile 0. Checking current profile list instead.
(K3bDevice::Device) /dev/sr0: GET CONFIGURATION length det failed.
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE dataLen = 8
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE reports bogus dataLen: 8
(K3bDevice::Device) /dev/sr0: Number of supported write speeds via 2A: 4
(K3bDevice::Device) /dev/sr0 : 8468 KB/s
(K3bDevice::Device) /dev/sr0 : 7056 KB/s
(K3bDevice::Device) /dev/sr0 : 4234 KB/s
(K3bDevice::Device) /dev/sr0 : 2824 KB/s
removing udi /org/freedesktop/Hal/devices/volume_empty_dvd_plus_r
(K3bDevice::Device) /dev/sr0 current profile 0. Checking current profile list instead.
(K3bDevice::Device) /dev/sr0: GET CONFIGURATION length det failed.
ASSERT: "i <= nodes" in /usr/lib64/qt-3.3/include/qvaluelist.h (376)
First sec data area: 43:41:33 (LBA 196608) (402653184
Last sec data area: 553:42:61 (LBA 2491711) (5103024128 Bytes)
Last sec layer 1: 00:00:00 (LBA 0) (0 Bytes)
Layer 1 length: 00:00:01 (LBA 1) (2048 Bytes)
Layer 2 length: 553:42:61 (LBA 2491711) (5103024128 Bytes)
DiskInfo:
Mediatype: DVD+R
Current Profile: DVD+R
Disk state: incomplete
Empty: 0
Rewritable: 0
Appendable: 1
Sessions: 1
Tracks: 1
Layers: 1
Capacity: 510:01:29 (LBA 2295104) (4700372992 Bytes)
Remaining size: 47:00:36 (LBA 211536) (433225728 Bytes)
Used Size: 463:00:68 (LBA 2083568) (4267147264 Bytes)
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE dataLen = 72
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE successful with reported length: 68
(K3bDevice::Device) /dev/sr0: Number of supported write speeds via GET PERFORMANCE: 4
(K3bDevice::Device) /dev/sr0 : 22160 KB/s
(K3bDevice::Device) /dev/sr0 : 16620 KB/s
(K3bDevice::Device) /dev/sr0 : 11080 KB/s
(K3bDevice::Device) /dev/sr0 : 5540 KB/s
This is an strace of k3b after it reloads the disk. This is a thread that is created from k3b. It is not under the PID for k3b. I had to use strace -ff -p{pid} -o{file_name} to get anything.
This just repeats over and over.
futex(0x7f8437d33fc0, FUTEX_WAKE_PRIVATE, 1) = 0
uname({sys="Linux", node="eagle1.tardis.localdomain", ...}) = 0
open("/dev/sr0", O_RDONLY|O_NONBLOCK) = 16
ioctl(16, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[00, 00, 00, 00, 00, 00], mx_sb_len=64, iovec_count=0, dxfer_len=0, timeout=5000, flags=0x3, status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=0, info=0}) = 0
close(16) = 0
futex(0x7f8437d33f94, FUTEX_WAIT_PRIVATE, 1, {1, 999997206}) = -1 ETIMEDOUT (Connection timed out)
I had to killed k3b with killall k3b.
KDE recognizes the DVD and prompts for what to do with the DVD.
Hope it gets fixed.
Should I open a new bug for k3b not verifying?
Just following-up on comment 73 above, I've burned data to a re-writable DVD again and again successfully verified the tracks on an i686. This is also after the recent swathe of updates (to 9th July 2009). It would seem the problem is now with some fc11.x86_64 set-ups, as others with i686 set-ups don't seem to be reporting further verifying tracks issues. Reference to Comment 90. Last night I recorded a DVD and it verified the DVD. Tonight I burned a DVD and it failed to verify. The only difference was last night K3B didn't eject the DVD while tonight it did. K3B seems to freeze as soon as KDE's device notifier shows that the disk has loaded into the player. K3B is now dead to the world and needs to be killed to get the drive back. I'm experiencing the same issue as comment 91: I just upgraded to x86_64 and while the bug is fixed on i586, it seems that it still exists on x86_64. Just added F11 updates (to 19th July 2009) and K3b on an i686 now ejects after immediately after burning and automatically re-loads immediately to verify the data (as it used to do), which it verifies successfully. This seems to have reverted K3b to the normal set-up before the verify data problems occurred, at least on an i686. Perhaps this re-load sequence is connected with the problems remaining with .x86_64 set-ups? Following recent updates, K3b once again fails to verify data on an i686. It burns the data, ejects and reloads ready for verification, but instead of verifying the data, it mounts the media and freezes. This is on kernel-PAE-2.6.29.6-217.2.7.fc11.i686.rpm An update. Yesterday I burned a couple of DVD's and k3b came up with an error message that it couldn't eject the media between the burn and verify phases. Tonight using the same procedure, the DVD's are ejecting again but not verifying. I am now back at getting the "device notifier" popping up when the DVD is re-loaded and then k3b hangs waiting for the DVD player. I have to manually kill k3b to get the DVD drive back and to continue using k3b. If the drive doesn't eject, then the media is tested. I see that this bug is closed due to ERRATA, what errata and can a link be provided? It would have been nice to see that this is related to a kernel problem. What bug? Please refer to early comments and comment #89 in particular. This bug is tracking the "No tracks to verify found" issue. If experiencing something *other* than this, commenting here is... not productive. Please file a new bug. |