Bug#299562: dev=/dev/cdrom crashed/hung X
Tim Baverstock <[EMAIL PROTECTED]> wrote: > On Wednesday 30 March 2005 3:53 pm, you wrote: > > > 'dev=/dev/cdrom' would have been confusing, but something like > > > "Impossible SCSI address [-2, -2, -2] - have you specified dev= > > > properly?" would have been good. > > > > Well, first you did call cdrecord with a _wrong_ dev= parameter and should > > not be amazed by the results. RTFM for the correct parameters. > > Not amazed, but disappointed. RTFM is all very well, but making a program > behave helpfully in the face of improper input is matter of good taste, Allowing a program to be useful for experimantal usagees is even better and this is what cdrecord does. In case of incorrect usagem it writes a warning that you seemed to oversee. > particularly if that input is subsequently processed in a relatively obscure > way, as in the translation from /dev/cdrom to -2,-2,-2: You already warn > about the image file being too large before trying to write it, I think. If you like to get an explanation about the obscurre device mapping in the Linux kernel, please ask the Linux kernel hackers for help. I am a victim the same way as you are 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
Bug#299562: dev=/dev/cdrom crashed/hung X
On Wednesday 30 March 2005 3:53 pm, you wrote: > > 'dev=/dev/cdrom' would have been confusing, but something like > > "Impossible SCSI address [-2, -2, -2] - have you specified dev= > > properly?" would have been good. > > Well, first you did call cdrecord with a _wrong_ dev= parameter and should > not be amazed by the results. RTFM for the correct parameters. Not amazed, but disappointed. RTFM is all very well, but making a program behave helpfully in the face of improper input is matter of good taste, particularly if that input is subsequently processed in a relatively obscure way, as in the translation from /dev/cdrom to -2,-2,-2: You already warn about the image file being too large before trying to write it, I think. I try to make my software give helpful messages if someone gets it wrong (so the program is in some senses an extension of the manual) but I also try to name the options in a way to avoid confusion: The parameter 'dev' is short for 'device' which has long meant /dev/ files on Unix, so I think the confusion is quite reasonable. Calling the parameter something like 'scsiaddr=' would probably have been a better choice. Still, it's your code, and I have to thank you for making it available, because when everything's right, it works well. > Solaris is currently free of charge for any type of usage and it will be > Open Source for everybody very soon (I already have access to the Mm. Certainly the new kernel-level debugging facilities are very tempting, but I think driver support isn't quite as good. I'll think about it. Anyway, I'd better stop hassling you. Thanks again. Tim -- Most incoming HTML email is caught by my SPAM FILTER. http://www.baverstock.org.uk/tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299562: dev=/dev/cdrom crashed/hung X
Tim Baverstock <[EMAIL PROTECTED]> wrote: > Hi. > > I'm running the Debian/Woody package for both cdrecord and 2.4 > kernel-sources, so the ioctls should be compatible (even if they're 4 years > old). So far as I know, I'm not using any GUI-based volume management (I use > fvwm2, not Gnome or KDE) but are there any processes or kernel modules I > should check for? I am not sure if this assumption is true. Debian did already compile cdrtools on a Linux-2.4 kernel and allowed people to partially downgrade the kernel to Linux-2.2 in the past. So in order to be sore I would encourage you to self compile an original cdrtools source. http://www.fokus.fhg.de/research/cc/glone/employees/joerg.schilling/private/problems.html > It sounds like you're saying this is a kernel bug. Perhaps you would be kind > enough to forward the report to the kernel package team if that's the case? Some time ago, I gave up trying to send bug reports to the Linux kernel people. They don't seem to be interested in fixing their bugs :-( > As an aside, while clearly nothing should cause a kernel to crash, I would > have expected a program that deals specifically with the SCSI interface, to > the extent of scanning the bus, to notice that it was about to try to talk to > an unlikely/impossible SCSI address and give a warning to the user: a message > like 'ENOTTY: No such device' in response to 'dev=/dev/cdrom' would have been > confusing, but something like "Impossible SCSI address [-2, -2, -2] - have > you specified dev= properly?" would have been good. Well, first you did call cdrecord with a _wrong_ dev= parameter and should not be amazed by the results. RTFM for the correct parameters. > I sympathise with your frustration over Linux ioctl changes. You'd suggest > that I use Windows or Solaris instead? Well, Win32 does not have the problems you report but it is not free or free of charge and the Win32 authors don't care about bug reports too. Solaris is currently free of charge for any type of usage and it will be Open Source for everybody very soon (I already have access to the OpenSolaris sources). The big advantage I see with Solaris is that the authors of the code listen to bug reports and fix bugs from time to time :-) 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
Bug#299562: dev=/dev/cdrom crashed/hung X
Hi. I'm running the Debian/Woody package for both cdrecord and 2.4 kernel-sources, so the ioctls should be compatible (even if they're 4 years old). So far as I know, I'm not using any GUI-based volume management (I use fvwm2, not Gnome or KDE) but are there any processes or kernel modules I should check for? It sounds like you're saying this is a kernel bug. Perhaps you would be kind enough to forward the report to the kernel package team if that's the case? As an aside, while clearly nothing should cause a kernel to crash, I would have expected a program that deals specifically with the SCSI interface, to the extent of scanning the bus, to notice that it was about to try to talk to an unlikely/impossible SCSI address and give a warning to the user: a message like 'ENOTTY: No such device' in response to 'dev=/dev/cdrom' would have been confusing, but something like "Impossible SCSI address [-2, -2, -2] - have you specified dev= properly?" would have been good. I sympathise with your frustration over Linux ioctl changes. You'd suggest that I use Windows or Solaris instead? Best wishes, Tim Baverstock. On Sunday 27 March 2005 1:14 pm, Joerg Schilling wrote: > I am sorry, but there is no relation between your problem and cdrercord. > > > Your problem is either caused by an ill-designed kernel (in > a decently designed kernel, all ioctl function codes are different > and for this reason, sending an ioctl to an improper device > will just cause a kernel error code of ENOTTY but no hang) > > ... or you found a bug in the volume management that is build into > some GUIs on Linux because the Linux kernel is missing support > for changeable volume management > > In any case: Note that you are using a 4 year old cdrecord! > > If Linux was a kernel where the authors did take care about the > users and thus did care about stable interfaces this should be no problem. > > Unfortunately this is not true for Linux. The Linux kernel authors > are proud of the fact that they constantly change interfaces in order > to show you that you need the sources of your applications. You need > to recompile them all every time you install a new kernel. Of course, > you need to fetch the latest source before as not all interface changes are > dealt by a recompile only.the authors of applications are forced > tp constantly add new work arounds for the fact that Linux kernel > interfaces are not stable. > > Jörg -- Most incoming HTML email is caught by my SPAM FILTER. http://www.baverstock.org.uk/tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299562: dev=/dev/cdrom crashed/hung X
I am sorry, but there is no relation between your problem and cdrercord. Your problem is either caused by an ill-designed kernel (in a decently designed kernel, all ioctl function codes are different and for this reason, sending an ioctl to an improper device will just cause a kernel error code of ENOTTY but no hang) ... or you found a bug in the volume management that is build into some GUIs on Linux because the Linux kernel is missing support for changeable volume management In any case: Note that you are using a 4 year old cdrecord! If Linux was a kernel where the authors did take care about the users and thus did care about stable interfaces this should be no problem. Unfortunately this is not true for Linux. The Linux kernel authors are proud of the fact that they constantly change interfaces in order to show you that you need the sources of your applications. You need to recompile them all every time you install a new kernel. Of course, you need to fetch the latest source before as not all interface changes are dealt by a recompile only.the authors of applications are forced tp constantly add new work arounds for the fact that Linux kernel interfaces are not stable. 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
Bug#299562: dev=/dev/cdrom crashed/hung X
I am sorry, but there is no relation betwee your problem and cdrercord. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299562: dev=/dev/cdrom crashed/hung X
Package: cdrecord Version: 4:1.10-7 Severity: normal I tried to write a CD without reading the documentation properly, and typed 'cdrecord dev=/dev/cdrom karan.iso'. This decided that I wanted to use -2,-2,-2 and unsurprisingly cdrecord hung. I pressed ^C and (being the simple soul that I am) typed the same command with the softlink translated to /dev/sr0. This time, X froze - even the keyboard numlock etc didn't toggle - and I had to hard-reset the computer. (Sadly, the PDA I've used on other occasions had broken, so I couldn't try to get in through ttyS1.) The journalling file systems kicked in, so I don't think I've lost anything (although they complained about some inodes), but I was a little startled. My cdrecord -scanbus: Linux sg driver version: 3.1.22 Cdrecord 1.10 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jörg Schilling Using libscg version 'schily-0.5' scsibus0: 0,0,0 0) 'HL-DT-ST' 'DVDRAM GSA-4081B' 'A100' Removable CD-ROM 0,1,0 1) * 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * I've since changed my defaults file so it knows the CD writer lives at 0,0,0 and successfully written a CD ROM. Oh, my root cmd: auto BOOT_IMAGE=Linux ro root=301 hdd=ide-scsi The only slightly weird thing with my machine that comes to mind - I have an nvidia card and use their proprietary driver. Oh, and I have a wacom graphics tablet whose Xdriver I had to compile from (open) source. Cheers. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux cardinal 2.4.18.20040523 #1 Sat Apr 24 01:30:06 BST 2004 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages cdrecord depends on: ii debconf 1.0.32 Debian configuration management sy ii libc6 2.2.5-11.8 GNU C Library: Shared libraries an ii makedev 2.3.1-58 Creates device files in /dev. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
