** Changed in: linux-2.6 (Debian)
Status: Unknown = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/28210
Title:
cdrecord hangs with kernel = 2.6.10 and cyberdrive cdrw
Jan, it seems you have a different issue than what was originally
reported here. Please open a new bug report. Thanks.
** Changed in: linux (Ubuntu)
Status: New = Fix Released
--
cdrecord hangs with kernel = 2.6.10 and cyberdrive cdrw
https://bugs.launchpad.net/bugs/28210
You received
Can't blank recordable DVD+
Kubuntu 9.10 64bit
Linux version 2.6.28-12-generic (bui...@crested) (gcc version 4.3.3 (Ubuntu
4.3.3-5ubuntu4) ) #43-Ubuntu SMP Fri May 1 19:31:32 UTC 2009
# cdrecord -v dev=/dev/sr0 -blank=fast
TOC Type: 1 = CD-ROM
scsidev:
Reportedly fixed with kernel = 2.6.24, i. e. hardy and up. Please yell
if you still have problems.
** Changed in: linux-2.6 (Debian)
Sourcepackagename: cdrtools = linux-2.6
Bugwatch: Debian Bug tracker #265747 = Debian Bug tracker #416388
Status: Fix Released = Unknown
** Changed in:
** Changed in: cdrtools (Debian)
Status: New = Fix Released
--
cdrecord hangs with kernel = 2.6.10 and cyberdrive cdrw
https://bugs.launchpad.net/bugs/28210
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing
Thank you to all of you who posted information here-very useful!
It took me all night searching the net to find how to get my Cyberdrive
CW038D working under Debian.
All I had to do in the end was add CDR_NODMATEST=true (without quotes) to
/etc/environment.
I also disabled autofs by putting a #
I have had the same problem. Pretty good reproducable. I was able to
burn after installing original cdrtools and (!) killing hald before
burning. No I found a workaround, that seems to be acceptable for me:I
added in {{/etc/rc.local}} the line {{hal-disable-polling --device
/dev/scd1}} (7dev(sd1
Moving to hal as the problem has been verified to be caused
by the existence of hald.
Note: This is Linux specific hald bug as it does not happen on Solaris.
** Changed in: hal (Ubuntu)
Sourcepackagename: cdrtools = hal
--
cdrecord hangs with kernel = 2.6.10 and cyberdrive cdrw
Your log file does not even contain the start of the blanking command.
If you like to help, please run cdrecord -V blank=fast -v and
later cut/paste the past ~50 lines from ther terminal.
I would guess that your problem may be related to HALD. Could you kill
hald before running the test?
--
As requested by Schily, I stopped the hald process
[EMAIL PROTECTED]:~# /etc/init.d/hal stop
* Stopping Hardware abstraction layer hald
[ OK ]
and I did :
cdrecord dev=0,1,0 -V blank=fast -v | tee cdrecordNOhald.lst
Logging to a USB drive might work. Assuming you have one mounted at
/media/disk, try this:
script -f /media/disk/log
--
cdrecord hangs with kernel = 2.6.10 and cyberdrive cdrw
https://bugs.launchpad.net/bugs/28210
You received this bug notification because you are a member of Ubuntu
Bugs, which
Le 11/01/2008 11:42, Schily écrivait :
Your log file does not even contain the start of the blanking command.
If you like to help, please run cdrecord -V blank=fast -v and
later cut/paste the past ~50 lines from ther terminal.
I'd love to provide more lines ;-) The trouble is that I can't
I cannot help here as this is a HAL bug.
On Solaris, there is no such problem. For this reason, this is a Linux specific
HAL problem. Let me explain the differences between Solaris and Linux:
- On Solaris, it is not hald that tries to find the state changes on the
drive/media
but the sd
Hi,
I'm just bumping into the same problem : when I try to erase a CDRW with the
latest cdrecord the machine freezes completely as soon as I need a file system
access.
I tried the ts=30k then ts=1k with the same result : I've got to hit the reset
button and all pending I/O has been lost (namely
The bug report looks like it has been done against a cdrecord version from 2004.
No real cdrecord output has been attached, do it cannot be even called a
confirmed bug.
Please test again with the new original cdrecord package from
gutsy/multiverse
If the problem goes away, this was a problem
Your problem is most likely caused by a well known linu xkernel bug
that has been accepted a long time ago that for that a 5 line patch
exists for a long time..
Check the net for the Linux USB DMA size bug.
If the kernel tells cdrecord that it is capable of doing big size DMA
but later
** Bug watch removed: Linux Kernel Bug Tracker #3741
http://bugzilla.kernel.org/show_bug.cgi?id=3741
** Bug watch added: Linux Kernel Bug Tracker #3741
http://bugzilla.kernel.org/show_bug.cgi?id=3741
--
cdrecord hangs with kernel = 2.6.10 and cyberdrive cdrw
** Bug 60154 has been marked a duplicate of this bug
** Bug 48504 has been marked a duplicate of this bug
--
cdrecord hangs with kernel = 2.6.10 and cyberdrive cdrw
https://launchpad.net/bugs/28210
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Instead of disabling the check explicitly, the code could (and should)
be modified so it doesn't do the check unless it's needed - i.e.,
CDR_FORCESPEED is not set, -force is not specified, and burnfree is not
specified on the command line. As a general rule, hardware shouldn't be
relied on to
19 matches
Mail list logo
