Since the libburn update to 0.5.2, I'm experiencing a segfault with xfburn on an amd64 platform. To reproduce the segfault, I have two burning devices: - an IDE internal device - an external USB device The bug is fixed when downgrading to libburn-0.4.4. Reproducible: Always Steps to Reproduce: 1.launch xfburn 2.Insert a CD-RW in the USB burning device (second device) 3.click on "Blank Disc" button 4.select the second burning device in the list (external USB device) Actual Results: xfburn segfaults. Expected Results: xfburn should not crash. See http://forums.gentoo.org/viewtopic-p-5280525.html#5280525 for more details about the gentoo platform on which the bug occurs.
1) Please post your `emerge --info' too. 2) Collect all relevant information here (don't point to forums.g.o). 3) Then reopen this bug.
emerge --info shows: Portage 2.1.4.5 (default/linux/amd64/2008.0, gcc-4.1.2, glibc-2.7-r2, 2.6.25-gentoo-r7-20081016 x86_64) ================================================================= System uname: 2.6.25-gentoo-r7-20081016 x86_64 Intel(R) Core(TM)2 CPU 6420 @ 2.13GHz Timestamp of tree: Thu, 06 Nov 2008 05:02:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.5.2-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.5, 1.7.9-r1, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.free.fr/mirrors/ftp.gentoo.org/" LDFLAGS="-Wl,-O1" LINGUAS="fr en_US" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/askell /usr/local/portage/layman/java-overlay" SYNC="rsync://portage/gentoo-portage" USE="X acl acpi alsa amd64 bash-completion berkdb bzip2 cairo caps cdr cracklib crypt cscope cups cxx dbus dvdr exif ftp gif gmp gtk hal imap java javascript jpeg jpeg2k ldap libffi lm_sensors maildir midi mime mmap mmx mng multilib ncurses nls nptl nsplugin opengl pam pcre pdf png posix ppds python raw rdesktop readline samba sharedmem smp sqlite sse sse2 ssl startup-notification subversion svg symlink syslog threads tiff truetype unicode usb vim-syntax xcomposite xfce xml xosd xpm xscreensaver xulrunner zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="cfontz cfontz633 ncurses" LINGUAS="fr en_US" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I've compiled xfburn with the debug use flag and I've got this stack trace with gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fa943af36f0 (LWP 5520)] 0x00007fa9436872d4 in burn_disc_cd_toc_extensions () from /usr/lib/libburn.so.4 (gdb) bt #0 0x00007fa9436872d4 in burn_disc_cd_toc_extensions () from /usr/lib/libburn.so.4 #1 0x00007fa94367ed54 in ?? () from /usr/lib/libburn.so.4 #2 0x00007fa94367edcb in mmc_read_toc () from /usr/lib/libburn.so.4 #3 0x00007fa94367f0c2 in mmc_read_disc_info () from /usr/lib/libburn.so.4 #4 0x00007fa9436861c3 in spc_sense_write_params () from /usr/lib/libburn.so.4 #5 0x00007fa94367359d in burn_drive_inquire_media () from /usr/lib/libburn.so.4 #6 0x00007fa943675551 in burn_drive_grab () from /usr/lib/libburn.so.4 #7 0x00007fa943676c03 in burn_drive_scan_and_grab () from /usr/lib/libburn.so.4 #8 0x0000000000415b0f in ?? () #9 0x0000000000415eec in ?? () #10 0x00000000004149fd in ?? () #11 0x00007fa93e442b28 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #12 0x00007fa93e4528e1 in ?? () from /usr/lib/libgobject-2.0.so.0 #13 0x00007fa93e453b95 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #14 0x00007fa93e453d73 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #15 0x00007fa9411d787e in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #16 0x00007fa9411d8bf4 in gtk_combo_box_set_active_iter () from /usr/lib/libgtk-x11-2.0.so.0 #17 0x00007fa9411d8cdd in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #18 0x00007fa93e442b28 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #19 0x00007fa93e4528e1 in ?? () from /usr/lib/libgobject-2.0.so.0 #20 0x00007fa93e453b95 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #21 0x00007fa93e453d73 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #22 0x00007fa941373e5a in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 #23 0x00007fa941279230 in gtk_menu_shell_activate_item () from /usr/lib/libgtk-x11-2.0.so.0 #24 0x00007fa94127ac26 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #25 0x00007fa94126cf8d in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #26 0x00007fa93e442be0 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #27 0x00007fa93e452a7f in ?? () from /usr/lib/libgobject-2.0.so.0 #28 0x00007fa93e45395e in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #29 0x00007fa93e453d73 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #30 0x00007fa94136fc4e in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #31 0x00007fa94126631f in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #32 0x00007fa941267357 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #33 0x00007fa940cca76c in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #34 0x00007fa93dd8a262 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #35 0x00007fa93dd8d545 in ?? () from /usr/lib/libglib-2.0.so.0 #36 0x00007fa93dd8d83d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #37 0x00007fa9411f000a in gtk_dialog_run () from /usr/lib/libgtk-x11-2.0.so.0 #38 0x0000000000418dd4 in ?? () #39 0x00007fa93e442b28 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #40 0x00007fa93e4528e1 in ?? () from /usr/lib/libgobject-2.0.so.0 #41 0x00007fa93e453b95 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #42 0x00007fa93e453d73 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #43 0x00007fa941194223 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #44 0x00007fa93e442b28 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #45 0x00007fa93e4528e1 in ?? () from /usr/lib/libgobject-2.0.so.0 #46 0x00007fa93e453b95 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #47 0x00007fa93e456616 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #48 0x00007fa93e442b28 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #49 0x00007fa93e4528e1 in ?? () from /usr/lib/libgobject-2.0.so.0 #50 0x00007fa93e453b95 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #51 0x00007fa93e453d73 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #52 0x00007fa9411aa679 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #53 0x00007fa93e442b28 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #54 0x00007fa93e45256d in ?? () from /usr/lib/libgobject-2.0.so.0 #55 0x00007fa93e453b95 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #56 0x00007fa93e453d73 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #57 0x00007fa9411a8f39 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #58 0x00007fa94126cf8d in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #59 0x00007fa93e442b28 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #60 0x00007fa93e452a7f in ?? () from /usr/lib/libgobject-2.0.so.0 #61 0x00007fa93e45395e in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #62 0x00007fa93e453d73 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #63 0x00007fa94136fc4e in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #64 0x00007fa94126631f in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #65 0x00007fa941267357 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #66 0x00007fa940cca76c in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #67 0x00007fa93dd8a262 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #68 0x00007fa93dd8d545 in ?? () from /usr/lib/libglib-2.0.so.0 #69 0x00007fa93dd8d83d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #70 0x00007fa941267692 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #71 0x0000000000417f03 in ?? () #72 0x00007fa93d3d21f4 in __libc_start_main () from /lib/libc.so.6 #73 0x000000000040d1f9 in ?? () #74 0x00007fff4bb1f6f8 in ?? () #75 0x0000000000000000 in ?? ()
libburn-0.5.4 does not fix the problem. I have also tried with xfburn-0.3.91 (thinking the bug was perhaps due to a misuse of libburn), but it is even worse.
(In reply to comment #4) > libburn-0.5.4 does not fix the problem. > I have also tried with xfburn-0.3.91 (thinking the bug was perhaps due to a > misuse of libburn), but it is even worse. In the meantime, we've gotten libburn-0.5.6 into portage, so I have to ask: Does that fix your bug?
(In reply to comment #4) > libburn-0.5.4 does not fix the problem. > I have also tried with xfburn-0.3.91 (thinking the bug was perhaps due to a > misuse of libburn), but it is even worse. Define "it is even worse" for me please...
I am the upstream of libburn and was informed about the problem today. xfburn is not a suspect for now. > #0 0x00007fa9436872d4 in burn_disc_cd_toc_extensions () from > /usr/lib/libburn.so.4 > #1 0x00007fa94367ed54 in ?? () from /usr/lib/libburn.so.4 > #2 0x00007fa94367edcb in mmc_read_toc () from /usr/lib/libburn.so.4 > #3 0x00007fa94367f0c2 in mmc_read_disc_info () from /usr/lib/libburn.so.4 > #4 0x00007fa9436861c3 in spc_sense_write_params () from /usr/lib/libburn.so.4 > #5 0x00007fa94367359d in burn_drive_inquire_media () from > /usr/lib/libburn.so.4 > #6 0x00007fa943675551 in burn_drive_grab () from /usr/lib/libburn.so.4 > #7 0x00007fa943676c03 in burn_drive_scan_and_grab () from This happened while the Table-Of-Content of a CD was to be converted into the more easy to handle format which libburn uses for DVD. This happened while the Table-Of-Content of a CD was to be converted into the more easy to handle format which libburn uses for DVD. The function which crashes was introduced in August 2008, just before release of 0.5.2. So it is clear why earlier versions do not show the problem. The problem is not common. There must be something peculiar about drive and/or media. (I start pointing to alleged kernel bugs only if i run out of ideas, ok ?) ------------------------------------------------- I will now examine the theoretical reasons for a SIGSEGV in there and how this can be triggered by a peculiarity of drive and/or media. ------------------------------------------------- But a really debuggable version of libburn would help to find out at least the exact crash site. Is it possible to provide a gentoo libburn produced equivalently to the following way ? Get: http://files.libburnia-project.org/releases/libburn-0.5.6.pl00.tar.gz untar it cd libburn-0.5.6 sed -e 's/CFLAGS="-g -O2"/CFLAGS="-g"/' -e 's/CFLAGS="-O2"/CFLAGS=/' \ <configure >configure_gdb chmod u+x configure_gdb ./configure_gdb make make install And could Thibault please install it, crash and try whether he can get me a stack trace with line numbers and function parameters ? If important news are to report, please notify me via http://libburnia-project.org/ticket/146
I uploaded a new development version of libburn. http://scdbackup.sourceforge.net/cdrskin-0.5.7.tar.gz It is a cdrskin tarball, because there are no development tarballs of libburn. Nevertheless it compiles and installs a dynamic libburn. Alternatively you can get the same via SVN from http://svn.libburnia-project.org/libburn/trunk Do not distribute this version for general use. Its API is not fully guaranteed to persist. But it is usable as replacement for libburn-0.5.6, of course. ------------------------------------------------------------- In this version the crashing function checks NULL-pointers before dereferencing them. In case a NULL is detected, a message will be emitted. Like: FAILURE : Damaged CD table-of-content detected and truncated. In burn_disc_cd_toc_extensions: session 2 of 22, track 1 of 1, entry == NULL The table-of-content will then be mangled to a safe size. This will normally prevent that more sessions can be appended to the media, i fear. So only blanking or reading will work. This will not help against potential rogue array indice or other causes of a SIGSEGV. But i deem it most likely that the number of available TOC entries does not match the announcement about sessions and tracks. ------------------------------------------------------------- In order to get the message and to learn more about the cause, i ask you for doing this test with cdrskin-0.5.7 before the offending CD-RW gets blanked: cdrskin -toc If you have more than one CD drive in the computer then you have to select one by option "dev=/dev/... " (You may re-use your cdrecord skills with cdrskin)
Hi everybody, Sorry for lagging lately. I'll have to wait until monday to make the tests you asked for. In the meantime, a few answers: For David: "it is even worse" means xfburn crashes earlier so I cannot get to the point where the previous test was crashing (I'll have to test again if you want more details). For Peter: I will test again with the latest gentoo version of libburn monday (test platform is at my workplace). For Thomas: - I will try to recompile the latest releases of libburn and xfburn in debug mode monday and try to reproduce the bug. - I will also try cdrskin with the failing media. I keep you all informed monday (evening) of what happened.
> - I will try to recompile the latest releases of libburn and xfburn in debug > mode monday and try to reproduce the bug. To be exacting: - no need to change anything with xfburn (unless libburn is linked statically) - cdrskin-0.5.7 is not a release. No release contains the potential remedy yet. Questions: Does this only happen with a particular media or does it happen with any CD-RW ? Is it related to drive or to media ? My current theory is that there is a session without leadout entry in the reply of the READ TOC command. That could lure all releases into dereferencing a NULL pointer. 0.5.7 should be safe.
I didn't have time to do so much testing today. Anyway here is the result of "crdskin -toc" on the failing device, it seems to confirm what Thomas said in comment #8: thild@askell ~/stow/cdrskin-0.5.7/bin $ ./cdrskin -toc -dev=/dev/sr1 cdrskin 0.5.7 : limited cdrecord compatibility wrapper for libburn cdrskin: NOTE : greying out all drives besides given dev='/dev/sr1' cdrskin: scanning for devices ... cdrskin: ... scanning for devices done cdrskin: pseudo-atip on drive 0 cdrskin: FAILURE : Damaged CD table-of-content detected and truncated. In burn_disc_cd_toc_extensions: session 0 of 1, track 5 of 5, entry == NULL cdrskin: status 4 burn_disc_full "There is a disc with data on it in the drive" scsidev: '10,0,0' Device type : Removable CD-ROM Vendor_info : '_NEC' Identifikation : 'DVD_RW ND-2500A' Revision : '1.07' Driver flags : BURNFREE Supported modes: TAO SAO RAW/RAW96R cdrskin: burn_drive_get_write_speed = 706 (4.0x) ATIP info from disk: Is erasable ATIP start of lead in: -11635 (97:26/65) ATIP start of lead out: 359849 (79:59/74) 1T speed low: 4 1T speed high: 4 first: 1 last 0
> cdrskin: FAILURE : Damaged CD table-of-content detected and truncated. In > burn_disc_cd_toc_extensions: session 0 of 1, track 5 of 5, entry == NULL Bingo. That's the leadout entry. If it is NULL then the drive replied to the MMC command READ TOC/PMA/ATIP by a set of Track Descriptors with no leadout entry among them. That's very unusual. Ok. There's a first patch on it now. If you install this libburn by "make install" then xfburn is supposed to survive the selection of that drive-or-media. You should be able to blank the media (currently it is closed and not writeable). Most interesting question before you do that: Is it the drive or is it the media ? I plan to release libburn-0.5.8 soon. There are enhancements with BD-RE pending. Before doing that i will consider how i could save more of the table-of-content in this case. The leadout entry marks the end of the last track. Without it, i don't know that track's size. The others should be recoverable ...
I didn't try xfburn with libburn 0.5.7 yet but in the meantime I can answer this question partially: > Most interesting question before you do that: > Is it the drive or is it the media ? I was able to blank the media with my internal drive, so this is not only due to the media. I said "only" because I didn't test the failing drive with another CD-RW, so perhaps something on the CD-RW cause the drive to reveal such a behavior.
> I was able to blank the media with my internal drive, > so this is not only due to the media. Yes. There is at least one component in the drive's firmware which contributes to the problem. It would be interesting to learn whether it does this with any written CD-RW, only with closed ones, only with particular individual discs, ... But as far as the software is concerned i have learned what is needed. Now i need to react a bit less coarse than in 0.5.7 and release 0.5.8. I will post a message here, when this is done. Many thanks for debugging and being patient. :)
I uploaded the release candidate for libburn-0.5.8 as cdrskin development package. Release is planned for end of this week. http://scdbackup.sourceforge.net/cdrskin-0.5.7.tar.gz MD5 is 15f792f05ae4f86046c9430430feb0c0 cdrskin -version shall put out: Version timestamp : 2008.12.03.085915 (or later). libburn now checks the sessions for missing leadout entries and tries to resolve the problem by truncating the table-of-content entry of the sessions last track to size 0. This will keep all eventual mount point addresses visible in the table-of-content. Thibault, it would be great if you could test this relase candidate with the real trouble-maker - if it still is reproducible at all. I simulated ill sessions but this is of course not the same as the real thing. Expect a message like this libburn : WARNING : Session 2 of 22 encountered without leadout and if the ill session contained only one track: libburn : WARNING : Empty session 2 deleted. Now 21 sessions.
Self correction: > and if the ill session contained only one track: > libburn : WARNING : Empty session 2 deleted. Now 21 sessions. This will happen if the session contained no track at all. If there is one track then it will show up with size 0.
libburn-0.5.8 is released now. It is supposed to fix this bug. Thank you for helping with the improvement of our software.
(In reply to comment #17) > libburn-0.5.8 is released now. It is supposed to fix this bug. > > Thank you for helping with the improvement of our software. > Thanks. 0.5.8 is now our CVS, in Portage.
Sorry, I'm again a week late. I have tested xfburn 0.3.2 with libburn 0.5.8 and I was not able to reproduce the bug. Before doing that, I've reproduced the bug once again with libburn 0.5.2. xfburn (in fact libburn) doesn't segfault anymore so I can confirm that the bug is fixed. It is still impossible to blank the disk, the "blank" button in the "Blank CD-RW" box is grayed out and the "Blank mode" list is empty. Anyway, thanks for the bug fix, the segfault was far more annoying.
> It is still impossible to blank the disk, the "blank" button in the "Blank > CD-RW" box is grayed out and the "Blank mode" list is empty. It would be interesting to know which libburn API calls are used to decide about the greying of the blank button. From previously Thibault's reported output of cdrskin -toc -dev=/dev/sr1 : > status 4 burn_disc_full "There is a disc with data on it in the drive" > ... > ATIP info from disk: > Is erasable I would expect this was worth being blanked. Check whether such a grey-button media still reports above statements. If so: What happens if you perform the blanking by cdrskin ? cdrskin -vvv dev=/dev/sr1 blank=fast
Thomas, here is the output of cdrskin you've asked for, I've used a home build from the following package: http://scdbackup.sourceforge.net/cdrskin-0.5.8.pl00.tar.gz Just before using cdrskin, I've tested again with xfburn to ensure it crashes as usual (with libburn 0.5.2) thild@askell ~ $ cdrskin -vvv dev=/dev/sr1 blank=fast cdrskin 0.5.8 : limited cdrecord compatibility wrapper for libburn cdrskin: DEBUG : burn_drive_convert_fs_adr( /dev/sr1 ) cdrskin: DEBUG : burn_drive_is_enumerable_adr( /dev/sr1 ) is true cdrskin: NOTE : greying out all drives besides given dev='/dev/sr1' cdrskin: scanning for devices ... cdrskin: ... scanning for devices done cdrskin: blank mode : blank=fast cdrskin: installed hard abort handler. cdrskin: active drive number : 0 '/dev/sr1' cdrskin: called as : cdrskin cdrskin: DEBUG : Async waiting after START UNIT (+ LOAD) succeeded after 0.1 seconds cdrskin: DEBUG : Async START UNIT succeeded after 0.1 seconds cdrskin: DEBUG : SCSI command 43h indicates host or driver error: host_status= 7h , driver_status= 0h cdrskin: WARNING : Session 1 of 1 encountered without leadout cdrskin: status 4 burn_disc_full "There is a disc with data on it in the drive" Current: CD-RW cdrskin: beginning to blank disc cdrskin_debug: k_speed= 0 Starting to write CD/DVD at speed MAX in real BLANK mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. cdrskin: blanking done Blanking time: 48.004s cdrskin_debug: demands_cdrecord_caps= 0 , demands_cdrskin_caps= 0
Stop wasting time with versions below 0.5.8 and use that for testing.. It's in portage!
(In reply to comment #22) > Stop wasting time with versions below 0.5.8 and use that for testing.. It's in > portage! > Add these to /etc/portage/package.keywords: dev-libs/libburn dev-libs/libisofs dev-libs/libisoburn Thanks.
> cdrskin: DEBUG : SCSI command 43h indicates host or driver error: host_status= 7h , driver_status= 0h Now i have to look in the Linux SCSI Howto what that shall mean. But it happens with the READ TOC command that shall provide the data which are missed afterwards. > cdrskin: WARNING : Session 1 of 1 encountered without leadout The plague is either in your drive or in your OS driver. (Can you get another USB drive to test with ?) -------------------------------------------------------------------- As for blanking: me and cdrskin see no reason why the drive and the media should not be blanked. It would be worthwhile to find out whether xfburn is really linked with libburn-0.5.8. E.g. which xfburn ldd .../xfburn | grep libburn ls -l .../libburn.so.4 the effective libburn.so should be libburn.so.4.23.0 (if not the build process inflicts its own .so numbering) If this is asserted then one should look why xfburn still sees the media as invalid for blanking. It gets its info from libburn, but has of course its own ways to react to them.
> cdrskin: DEBUG : SCSI command 43h indicates host or driver error: host_status= 7h , driver_status= 0h According to http://tldp.org/HOWTO/SCSI-Generic-HOWTO/x291.html#FTN.AEN312 : " 6.18. host_status SG_ERR_DID_ERROR [0x07] Internal error detected in the host adapter. This may not be fatal (and the command may have succeeded). The aic7xxx and sym53c8xx adapter drivers sometimes report this for data underruns or overruns. [1] 6.19. driver_status SG_ERR_DRIVER_OK [0x00] Typically no suggestion " The only theory i can make from those texts is that something is wrong with the virtual SCSI adapter (which actually is USB hardware). It is not discernible whether hardware of software is to blame. There are some more debugging hints in http://tldp.org/HOWTO/SCSI-Generic-HOWTO/debugging.html I personally feel unable to debug kernel or hardware, though.
