Re: cdrecord problems
On Friday 27 July 2007 17:52, Thomas Schmitt wrote: This does not match the current problem. pengsens' drive refuses on any write mode which yields this message in wodim's output Supported modes: while in bug=413960 the according message is: Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P and the wodim run fails much later in the course of processing. The one of pengsens failed before any writing began. The failure depends on timing between wodim and hal. IMHO there is a chance that it fails earlier if hal polls the drive in the right moment. I think that updating wodim is a good idea anyway, because I don't know about any LG drive, where this bug does not appear. Vladimir Nadvornik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Hi, The failure depends on timing between wodim and hal. IMHO there is a chance that it fails earlier if hal polls the drive in the right moment. Not impossible, i have to confess. But reading wodim's source for write-mode detection i have to conclude that hald would have to _reliably_ sabotage at least half a dozen consequtive attempts to set the write parameters by mode page 05h. There are other points against your theory. - The known hald vulnerability of CD burning is with the actual process of writing. This is not a sin of LG but complies to MMC-5, 6.44 WRITE (10) Command While writing is occurring, the Drive may not be able to process all commands. The following is a list of commands that shall function during writing without causing a SYNCHRONIZE CACHE. 1. TEST UNIT READY ... 8. GET EVENT STATUS NOTIFICATION All other commands shall process normally, but may force a SYNCHRONIZE CACHE before executing. SYNCHRONIZE CACHE implies the (premature) end of the burn. That's what we usually experience when hald spits into our soup. (If one wants to be picky then above statement belongs to 6.44.3.3 SAO Raw on CD-R/-RW, DAO and Incremental on DVD-R/-RW and would not necessarily apply to TAO.) - There is another drive on pengsens' system which works without problems. Both occurences of zero supported write modes are with a LG GSA-H30N drive. I concede that this still does not outrule hald problems. I think that updating wodim is a good idea anyway, Agreed. To pengsens (if you are still reading): Please make the following experiments - Try dev=/dev/sr0 rather than dev=1,0,0. - Kill your hald process and try wether your burner works better afterwards. - Try wodim-1.1.6. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Vladimir Nadvornik [EMAIL PROTECTED] wrote: On Friday 27 July 2007 17:52, Thomas Schmitt wrote: This does not match the current problem. pengsens' drive refuses on any write mode which yields this message in wodim's output Supported modes: while in bug=413960 the according message is: Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P and the wodim run fails much later in the course of processing. The one of pengsens failed before any writing began. The failure depends on timing between wodim and hal. IMHO there is a chance that it fails earlier if hal polls the drive in the right moment. Looks like you are missing skills and experiences in SCSI programming in special and Kernel programming in general. You are true that hal on Linux is a nightmare, but it is definitely not responsible for the problem of the OP. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Thomas Schmitt [EMAIL PROTECTED] wrote: But reading wodim's source for write-mode detection i have to conclude that hald would have to _reliably_ sabotage at least half a dozen consequtive attempts to set the write parameters by mode page 05h. If this part of wodim has bot been bastardized, cdrecord would behave the same but the only way to find this out is to try a non-bastardized source from http://cdrecord.berlios.de/ The people who did create the wodim fork did add many intentional indentation changes in order to pretend work in progress. As wodim is also based on a very old version of cdrecord, it is hard to compare the source I think that updating wodim is a good idea anyway, Agreed. NO, it definitely does not make sense to put any effort in a dead fork. Another point against wodim is that it intentionally added bugs during it's lifetime because it's maintainer did believe it is possible to write CDs on Linux without having root privileges. These bugs never have been removed before the fork died 3 months ago. Offtopic: Hal on Linux is a nightmare. As long as the Linux kernel developers and the developers for hal on Linux do not listen to experienced people, there is little hope that this will ever change. Solaris did change to hal a year ago (because of Gnome). Before, Solaris did use the old 1992 Sun vold that did never have any problem with CD/DVD writing. For this reason, I was afraid that Solaris was changing from software that worked on Solaris for many years to something that creates a lot of problems on Linux. The big difference between the Linux folks and the Solaris folks is that the Solaris folks take possible issues with CD/DVD recording very seriously. The person who did implement the code transition did listen very carefully to my explanations on why cdrecord works on Solaris and why it does not work on Linux. This is why there are no kown problems even after the change. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Chris Ahlstrom wrote: * Greg Wooledge [EMAIL PROTECTED] [2007-07-27 11:55:19 -0400]: On Fri, Jul 27, 2007 at 09:59:36AM -0400, Chris Ahlstrom wrote: Perhaps I am talking out of turn here, but isn't this mailing list restricted to covering the Debian fork (reference http://lists.debian.org/debian-devel-announce/2006/09/msg2.html)? No, this mailing list predates 2006 by quite some time. It's a general list for discussion of all CD and DVD writing software, although in practice, it's just for Unix-type systems. It just happens to be hosted by Debian. Thanks. Don't let the flame wars get to you... wodim is just as much on-topic here as cdrecord is, and each one has its place. Oh, I'm used to flame wars, but not so used to paranoia. Actually, paranoia has it's own mailing list, although the credits in cdrecord mention that some of the ripping code originated in the cdparanoia library. These days it's mainly used for ripping less than perfect audio CDs, and not much discussed here. I'm on the list, not on this machine, and would get you an address if you (a) want to join and (b) can't easily find it. I do have a question, though. I know about cdrecord, wodim, and dvd+rw-tools. But are there any other CD/DVD writing engines out their? Ones with source code, that is. You didn't mention cdrskin, that has some cdrecord compatibility modes, but will work in Linux without being root. I did recently discover that it has limitations doing odd raw burns, but that's not a usual requirement, and it politely says I can't do that instead of doing it wrong. I don't mean alternate front ends, but engines. Is there a good site with a feature matrix? This site, though amusing, does not have one: http://en.wikipedia.org/wiki/Cdrecord Perhaps someone who is not an author of an engine could update and improve that. A neutral third party. One more bit of more sour amusement: http://www.arklinux.org/projects/dvdrtools/ This page is temporarily down because of spammer attacks; until it comes back, you can download dvdrtools from svn ... Now who would do a thing like that? Who can understand the anti-social mind anyway? -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Thomas Schmitt wrote: Hi, me: growisofs claims to be able, cdrecord claims to be able. Joerg Schilling: I cannot speak for growisofs but cdrecord is definitely able to correctly copy DVD-Video with DVD+R/DL and driveropts=layerbreak=# claims does not mean i doubt it. I just did not test it myself. Different from other things which i carefully tested with all our wealth of burn programs. I have not yet been able to set the layer break for DVD-R/DL. Reading MMC-5 i am not sure wether it is mandatory to set a layer break explicitely. Paragraph 4.3.5 DVD-R Dual Layer talks much about Layer Jump Recording (flip-flopping between layers) but is quite silent about DAO and Incremental. I saw a discussion on one of the lists I read about using a DL as though it were two media, and selecting between them. I confess it doesn't seem to solve any problems I have, and I didn't spend much time studying the matter, I may be incorrect about the claims. Paragraph 4.3.7 DVD+R Dual Layer is much more detailed about the layer hop. Nevertheless there is a statement which makes me believe it is worth a try to just write to it as to a fat DVD+R. That seems to work. I did some backups that way, creating big files and just burning them. I believe I used growisofs but I can't be sure after the fact. Reading the data back produced no read errors and a correct md5sum, I did wipe the original and test restore, though. ;-) In 4.3.7.5 Recording on DVD+R DL: The Host is permitted to select a smaller address for this location (See 6.34). 6.34 describes MMC command BFh SEND DISC STRUCTURE. I guess they mean: 6.34.3.2.4 Format = 20h: Layer Boundary Information I would be interested to learn about your opinion and experiences. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Joerg Schilling wrote: Thomas Schmitt [EMAIL PROTECTED] wrote: But reading wodim's source for write-mode detection i have to conclude that hald would have to _reliably_ sabotage at least half a dozen consequtive attempts to set the write parameters by mode page 05h. If this part of wodim has bot been bastardized, cdrecord would behave the same but the only way to find this out is to try a non-bastardized source from http://cdrecord.berlios.de/ The people who did create the wodim fork did add many intentional indentation changes in order to pretend work in progress. As wodim is also based on a very old version of cdrecord, it is hard to compare the source I think that updating wodim is a good idea anyway, Agreed. NO, it definitely does not make sense to put any effort in a dead fork. Another point against wodim is that it intentionally added bugs during it's lifetime because it's maintainer did believe it is possible to write CDs on Linux without having root privileges. Yes, and important capability cdrecord still lacks. And a good reason to try other software, because most sensible administrators don't want all their users having root access. Burning as root is suitable for personal, home, and hobby systems, but is not acceptable as a solution to application software limitations in a production environment. These bugs never have been removed before the fork died 3 months ago. Offtopic: Hal on Linux is a nightmare. As long as the Linux kernel developers and the developers for hal on Linux do not listen to experienced people, there is little hope that this will ever change. If there are problems in hal (and I totally agree there are), they are in hal, and it's not a kernel problem if someone writes an ill-behaved application and then runs it as root. And I think nightmare is an exaggeration, annoyance might be closer, since hal is not a required process. Solaris did change to hal a year ago (because of Gnome). Before, Solaris did use the old 1992 Sun vold that did never have any problem with CD/DVD writing. For this reason, I was afraid that Solaris was changing from software that worked on Solaris for many years to something that creates a lot of problems on Linux. The big difference between the Linux folks and the Solaris folks is that the Solaris folks take possible issues with CD/DVD recording very seriously. The person who did implement the code transition did listen very carefully to my explanations on why cdrecord works on Solaris and why it does not work on Linux. This is why there are no kown problems even after the change. And all this time I thought it was because everyone else could figure out how to do burning on Linux without root and you can't. Or because you wanted to claim the problems are in the kernel instead of limitations in your own software. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Hi, Bill Davidsen: I did recently discover that it [cdrskin] has limitations doing odd raw burns, but that's not a usual requirement, Would it be indiscrete to ask for the use case and what cdrecord write mode option you wanted to apply ? libburn contains code for raw write modes and i implemented in cdrskin option -raw96r without knowing much of the technical background. But to my experience this mode is unappealing for data recording although it allows higher throughput and capacity: - The time sharing granularity of my system becomes awful, - one of my drives can become totally unusable afterwards, - the higher capacity is at expense of less error detection and correction. Nevertheless, if you give me hints about what and why then i would begin and try to learn about subchannels and all. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Hi, Vladimir Nadvornik: I think that updating wodim is a good idea anyway, me: Agreed. Joerg Schilling: NO Independend of the question wether to use cdrecord, wodim or cdrskin, it makes sense to upgrade from earlier wodims to 1.1.6. It eases the hald problem if one uses the block device on Linux kernel 2.6. wodim-1.1.6 does this by default. If only all hal demons would use O_RDWR|O_EXCL with all their open(2) calls then the world would be nearly ok. We would still have a race condition about who may use the drive at all - but the failures would be less costly and much more understandable to the user. Joerg Schilling: Hal on Linux is a nightmare. Rob Bogus: If there are problems in hal (and I totally agree there are), they are in hal, and it's not a kernel problem if someone writes an ill-behaved application and then runs it as root. There are also other usage scenarios where open O_EXCL is not a viable alternative. What we need is a system enforced mandatory locking mechanism by which we can keep any other process from sending commands to our burner drive via any of the various system drivers. The bug refered to by Vladimir Nadvornik caused Eduard Bloch to write to LKML. The reply caused me to explore the existing possibilities with the friendly help of Ted T'so and his use cases of libblkid. The result was clear: On Linux there is currently no reliable means to protect a drive from interference by a process which has read-access to the drive. Any precaution can get circumvented by accident, with no bad intention, and unavoidable within the respective use case. It is a bit depressing. Shall i appeal to LKML ? This seems equivalent to the question wether i am ready to dive into Linux kernel development. Eduard Bloch was told that there is no problem if only we userland applications coordinate neatly. But Ted and me found no way to coordinate cdrskin with libblkid ... and we really tried. We detect each other in the moment when the coaster occurs. Not earlier. If i just re-iterate Eduard Bloch's request, then i will very probably receive the same reply. So i can as well skip that step and start my own kernel (cough cough). Are there LKML regulars around here who could give me some advise ? (Not about forking Linux but about convincing the kernel developers.) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Bill Davidsen [EMAIL PROTECTED] wrote: http://www.arklinux.org/projects/dvdrtools/ This page is temporarily down because of spammer attacks; until it comes back, you can download dvdrtools from svn ... Now who would do a thing like that? Who can understand the anti-social mind anyway? It looks a bit strange that the first person who did abuse the cdrtools code for his anti-social games, tries to hide behind alleged net attacks. In special as it is obvious that he himself did only remove _all_ dvdrtools related pages from his webserver while other pages remained accessible. I would be interested to know why he did this surprisingly at the same time when other people started another speudo-fork on cdrtools. These other people did start another anti-social game against OSS users. Is there some kind of relationship? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Bill Davidsen [EMAIL PROTECTED] wrote: Paragraph 4.3.7 DVD+R Dual Layer is much more detailed about the layer hop. Nevertheless there is a statement which makes me believe it is worth a try to just write to it as to a fat DVD+R. That seems to work. I did some backups that way, creating big files and just burning them. I believe I used growisofs but I can't be sure after the fact. Reading the data back produced no read errors and a correct md5sum, I did wipe the original and test restore, though. ;-) As you don't know what you did, it is a good idea not to believe you... Not setting the layer break on DVD+R/DL may work in principle but it causes a lot of headaches. If you do not set the layer break, you need to write both complete surfaces. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Thomas Schmitt [EMAIL PROTECTED] wrote: Independend of the question wether to use cdrecord, wodim or cdrskin, it makes sense to upgrade from earlier wodims to 1.1.6. What do you gain from using a probably less defective version of a dead fork from an old version of cdrecord if you have the opportunity to use the working original? It eases the hald problem if one uses the block device on Linux kernel 2.6. wodim-1.1.6 does this by default. If only all hal demons would use O_RDWR|O_EXCL with all their open(2) calls then the world would be nearly ok. People who believe that they may solve the hald problem by using O_EXCL did not understand the problem. The result was clear: On Linux there is currently no reliable means to protect a drive from interference by a process which has read-access to the drive. Any precaution can get circumvented by accident, with no bad intention, and unavoidable within the respective use case. The only reliable way would be to make hald on Linux behave cooperatively. It is a bit depressing. Shall i appeal to LKML ? The problem may only be solved if the authors of hald and the relahed people from the linux kernel did talk with me. This did work with Solaris, it will work for Linux the same way. The fact that Linus T. is not interested in a cleanly planned SCSI driver subsystem that only implements a single fully working path to each piece of HW mahes this most unlikely to ever happen as long as Linus T. influences the Linux kernel. This seems equivalent to the question wether i am ready to dive into Linux kernel development. Eduard Bloch was told that there is no problem if only we userland applications coordinate neatly. Alan Cox did write a lot of wrong things in the past, with his answers to Mr. Bloch, he was correct, but I did not see him writing this claim. If he did really write that it is a Linux userland only problem, he is of course wrong. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Hi, me: Eduard Bloch was told that there is no problem if only we userland applications coordinate neatly. Joerg Schilling: Alan Cox [...] with his answers to Mr. Bloch, he was correct, but I did not see him writing this claim. That's what i understand from this statement by Alan Cox http://lkml.org/lkml/2007/3/31/175 I interpret this like: Kids, manage this yourself, like the Terminalovski brothers from the neighbor house did. Well, Dialup Terminalovski is an ageing web criminal now. Uucp Terminalovksi lost his job to the Internet. Kermit Terminalovski went back to showbiz. Do they really want us to end up like that ?! Joerg Schilling: If he did really write that it is a Linux userland only problem, he is of course wrong. This becomes evident by my failure to coordinate cdrskin and libblkid. Ted T'so is my witness that i did consider any known locking mechanism and that each of them failed to match our needs. Those needs are not exotic. We have: - Contemporary Linux 2.6. - A library which wants to learn wether any interesting data are available. It is willing to stay away from anything that is marked as occupied but it runs with superuser authority and on very sparse systems. It wants to make peek reads from mounted filesystems. - A burn program which wants to be undisturbed while it makes its efforts to populate the world with CD or DVD. Constraints: - Intolerable would be stale locks. I.e. if the lock holder crashes then the lock has to be released automatically within a reasonable time. The lock must not survive reboots. - The lock must be bullet proof. I.e. no sneak-in via an alternative device file path or device driver. - It is allowed to be advisory. I.e. applications would have to be extended to participate in the effort. - An older meaning of O_EXCL with block devices mounted as filesystems has to be respected. The locking aspect of O_EXCL which came from sg to sr is exclusive, while the older one allows read access. (sigh) I'm open to proposals. (Expect some counter arguments from my side but be assured that i hope to lose in my role as advocatus diavoli.) Joerg Schilling: People who believe that they may solve the hald problem by using O_EXCL did not understand the problem. I strace'd the activities of hald on a SuSE 9.3 which serves as my 2.6 test system. I found out that hald does some open(O_EXCL) but soon closes that fd and opens new fds without O_EXCL. With those it performs read(), poll() and ioctl(,CDROM_DRIVE_STATUS,) which obviously cause trouble. Please give me some hints if you know more about the course of those collisions. The only reliable way would be to make hald on Linux behave cooperatively. I am not so sure wether this is possible at all. We surely lack of means of mutual detection. I can hardly cooperate if i don't know that there is somebody else. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
