Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
On 17 June 2012 01:08, Tom Gundersen t...@jklm.no wrote: On Sat, Jun 16, 2012 at 9:14 PM, Lukáš Jirkovský l.jirkov...@gmail.com wrote: On 11 June 2012 12:05, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: BTW: the fact that there is no documentation[1] for this new driver looks like a reason for not including it. That's a perfectly valid reason. FWIW: this is up to the kernel devs, and not us. 'bsg' is supported/loaded because the kernel says so. The only thing that changed recently was that a hack was removed from udev to foricbly load the 'sg' module. The reason this hack was needed is that (as far as i understand) the 'sg' module does not have support for the being automatically loaded as almost all other modules (including 'bsg') does. Yep, we can do hardly anything about that. However, I completely understand why Joerg doesn't want to implement it when there's no documentation. Using some badly/undocumented interfaces is a nightmare and, as Joerg said, it becomes even more funny when the interface changes as you don't have a slight idea what parts of the API are considered stable and public. But as I said in my previous post the reason why there's no documentation might be that it has the same interface as the 'sg' driver… A way around this is to add back the hack but make it specific to the packages that need it (such as cdrecord), rather than having it on all systems. This is essentially what the modules-load.d fragment I proposed does. -t I implemented the modules-load.d thing in the cdrtools 3.01a07-4. Thank you for that. Lukas
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
Sorry I forgot to reply earlier (real-life duties). Fortunately I had added this to my to-do list so it didn't get forgotten completely. I've just uploaded a new package which uses /usr/lib/modules-load.d/cdrecord.conf to autoload the sg module (thanks, Tom!). On 11 June 2012 12:05, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: BTW: the fact that there is no documentation[1] for this new driver looks like a reason for not including it. That's a perfectly valid reason. [1] Or could you find documentation for it? Not exactly. What I found is that according to [1] it supports the sg interface: The bsg driver has device names of the form /dev/bsg/0:1:2:3 and supports the SG_IO ioctl with the sg version 3 interface. It might be that only device names changed. I took a quick look at the sg3_utils package [2] and the code I checked seems to be almost the same for both sg and bsg – the only bigger difference I saw was in the finding of relevant device names. Lukas [1] http://sg.danny.cz/sg/#mozTocId921329 [2] http://sg.danny.cz/sg/sg3_utils.html
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
On Sat, Jun 16, 2012 at 9:14 PM, Lukáš Jirkovský l.jirkov...@gmail.com wrote: On 11 June 2012 12:05, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: BTW: the fact that there is no documentation[1] for this new driver looks like a reason for not including it. That's a perfectly valid reason. FWIW: this is up to the kernel devs, and not us. 'bsg' is supported/loaded because the kernel says so. The only thing that changed recently was that a hack was removed from udev to foricbly load the 'sg' module. The reason this hack was needed is that (as far as i understand) the 'sg' module does not have support for the being automatically loaded as almost all other modules (including 'bsg') does. A way around this is to add back the hack but make it specific to the packages that need it (such as cdrecord), rather than having it on all systems. This is essentially what the modules-load.d fragment I proposed does. -t
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
Tom Gundersen t...@jklm.no wrote: On Sun, Jun 10, 2012 at 12:06 PM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Why should someone call an important driver legacy? I assume it is because it has some problems, and has been replaced by something else. But you'd have to take it up with the udev maintainer, as he is the one who made the change, or the kernel maintainer to find out more about his reasons for introducing bsg. I'm just letting you know about the issue (I expect this change will hit most distributions soon if it has not already). Of course, sg has problems and I talk about them since a long time. Unfortunately, there does not seem to be any interest from the Linux Kernel folks to fix the problems. It is bad practice to replace one driver by another just to cause incompatibilities instead of enhancing existing software. Maybe so, I'm just pointing out what has happened and what we have to deal with. I don't really know the reasons very well. I would expect that people who like to fix problems in this area first contact me for a list of problems and fix proposals. This software seems to be a result of a change made by one person alone without asking potential users. and btw. this supposed sg replacement is undocumented. I could not find much about it, but if anyone is interested I found a few sources [0][1]. Notice that the motivation for this stuff seems to be cdrecord[2], so it is very strange that this has not been brought to your attention before. Thank you for undxerstanding the problem! [0]: https://lwn.net/Articles/96547/ This is just code and absolutely no documentation :-( [1]: https://lwn.net/Articles/174469/ See above... [2]: After all that SG_IO and cdrecord talk, I decided to brush off the bsg driver I wrote some time ago. The problem on Linux is not that we need to replace one driver by another one delivering the same faulty interface just in a slightly modified way that prevents existing software from being able to use it. The real problems with SCSI on Linux are: - Not all devices that talk SCSI are available via the same driver name space. Example: ATAPI via PATA is excluded, ATAPI via SATA is included. - Missing working support for DMA residual counts. - No useful and predictable way to get/set the maximum DMA size for a given device. - The SCSI status code in the Linux SCSI glue layer is stored in a modified form that causes frequent problems with drivers that forget about that fact and cause the Generic SCSI layer to report wrong status codes. - A specific device is accessible via more than one driver and there is no locking between these drivers. Introducing another driver in this list will just cause more problems. - The existence of hostile software like hald and similar followups that repeatedly send SCSI commands to many devices. These commands interrupt the CD/DVD/PluRay writing process. This is a result of the fact that the author of hald and it's successorts has no clue on the state model of SCSI devices with changeable media ans is not willing to listen to people who like to help him to understand the background. If you know how SCSI devices work in this area, it is of course possible to avoid the Linux specific problems. As you see, there is plenty of work to do. From what I see, Mr. Axboe did not address a single of the problems in the list with his work. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
Luká?? Jirkovský l.jirkov...@gmail.com wrote: Yeah, I'm pretty surprised that the developer arguments with cdrecord without contacting Jörg beforehand. Anyway, the motivation might be to use the SCSI numbers instead of random numbers determined by udev. Not asking the right people seems to be a method that I did see more than once in the past. The numbering scheme is a less important problem on Linux, in special as the code in libscg knows how to deal with it. There are other more imortant problems on Linux that I would like to see fixed. BTW: the fact that there is no documentation[1] for this new driver looks like a reason for not including it. [1] Or could you find documentation for it? BTW: The reason for having documentation in special in the driver area is that applications that use interfaces would need to know with part of the potential interface features is granted to stay stable in the future. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
On Sat, Jun 9, 2012 at 11:51 PM, Javier Vasquez j.e.vasque...@gmail.com wrote: On Sat, Jun 9, 2012 at 11:24 PM, Jude DaShiell jdash...@shellworld.net wrote: Your drive could need cleaning, or have worn out, or in some way have been disconnected. Those kind of drives have to be replaced every so often. If it's a usb drive, have you done a modprobe usbmass yet? If not, that may be all you need to get things going. If you read dmesg does the cd drive even show up as a valid device now? If not, maybe insmod usbmass will fix that and get you burning. I have both drives, and they both seem OK. IDE one is sr0 and USB one is sr1: [ 4.894446] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray [ 4.894452] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 4.894842] sr 1:0:0:0: Attached scsi CD-ROM sr0 ... [21171.638369] usb 2-2: new high-speed USB device number 5 using xhci_hcd [21171.655770] usb 2-2: ep 0x2 - rounding interval to 32768 microframes, ep desc says 0 microframes [21171.655781] usb 2-2: ep 0x86 - rounding interval to 32768 microframes, ep desc says 0 microframes [21171.700222] usbcore: registered new interface driver uas [21171.704428] Initializing USB Mass Storage driver... [21171.704526] usbcore: registered new interface driver usb-storage [21171.704530] USB Mass Storage support registered. [21171.706759] scsi7 : usb-storage 2-2:1.0 [21171.707035] usbcore: registered new interface driver ums-cypress [21174.637779] scsi 7:0:0:0: CD-ROM TSSTcorp CDDVDW SH-S202J SB02 PQ: 0 ANSI: 0 [21174.745896] sr1: scsi3-mmc drive: 12x/48x writer dvd-ram cd/rw xa/form2 cdda tray [21174.746166] sr 7:0:0:0: Attached scsi CD-ROM sr1 I don't think any of the drives has worn out... It's too much of a coincidence cdrecord has problems with both... Your comment suggests that you would expect cdrecord to work OK. So maybe you don't have any problems with it... Forgot to mention, I can mount ISO DVDs/CDs with both drives without problems. So even though that's different than burning, gives the clue that maybe it's not about the HW this time, :-) Thanks, -- Javier.
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
On 10 June 2012 01:41, Javier Vasquez j.e.vasque...@gmail.com wrote: Hi, I've been using the original cdrecord (cdrtools) for more than 10 years now, however I hadn't burned anything in the last 3 months (or even more). With the current linux kernel image from Arch: % uname -a Linux jvasquez14 3.3.8-1-ARCH #1 SMP PREEMPT Tue Jun 5 15:20:32 CEST 2012 x86_64 GNU/Linux I can't get cdrecord to recognize any cd/dvd writer, not the laptop one neither an external USB one... I might be mistaken, but with 3.0 image I believe things worked (can't be sure, as I said I haven't been burning anything for months). When I try to identify the cd/dvd writers: % cdrecord -scanbus Cdrecord-ProDVD-ProBD-Clone 3.01a07 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2012 Joerg Schilling cdrecord: No such file or directory. Cannot open '/dev/pg*'. Cannot open or use SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. cdrecord: For possible transport specifiers try 'cdrecord dev=help'. I looked through google, but the responses I get are pretty old, some from 2004, talking about early 2.6 kernels... I found one page (an old one as well) that suggests using ide-scsi emulation, but that seems to me old as well: http://xpt.sourceforge.net/techdocs/media/cd/cd03-DeviceConfiguration/ar01s06.html Besides for quiet a while we don't get hdc or sdc, just plain sr0/sr1 (even the scd0/scd1 was removed), and that seemed to work before if I'm not mistaken... Perhaps now the way is sr0=scsi? Any ways, maybe someone knows better, :-) I can try the boot loading thing, but before, I wanted to see if someone has experienced this, and there's a known work around. Thanks, -- Javier. Sure we know better :-) It is known problem that made it even to the install file: https://projects.archlinux.org/svntogit/community.git/tree/trunk/cdrtools.install?h=packages/cdrtools Maybe I should add it to post_upgrade() as well, so the loyal users of this package get this warning too. Or better – try to find why this module is no longer loaded. Lukas
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
On Sun, Jun 10, 2012 at 1:34 AM, Lukáš Jirkovský l.jirkov...@gmail.com wrote: On 10 June 2012 01:41, Javier Vasquez j.e.vasque...@gmail.com wrote: Hi, I've been using the original cdrecord (cdrtools) for more than 10 years now, however I hadn't burned anything in the last 3 months (or even more). With the current linux kernel image from Arch: % uname -a Linux jvasquez14 3.3.8-1-ARCH #1 SMP PREEMPT Tue Jun 5 15:20:32 CEST 2012 x86_64 GNU/Linux I can't get cdrecord to recognize any cd/dvd writer, not the laptop one neither an external USB one... I might be mistaken, but with 3.0 image I believe things worked (can't be sure, as I said I haven't been burning anything for months). When I try to identify the cd/dvd writers: % cdrecord -scanbus Cdrecord-ProDVD-ProBD-Clone 3.01a07 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2012 Joerg Schilling cdrecord: No such file or directory. Cannot open '/dev/pg*'. Cannot open or use SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. cdrecord: For possible transport specifiers try 'cdrecord dev=help'. I looked through google, but the responses I get are pretty old, some from 2004, talking about early 2.6 kernels... I found one page (an old one as well) that suggests using ide-scsi emulation, but that seems to me old as well: http://xpt.sourceforge.net/techdocs/media/cd/cd03-DeviceConfiguration/ar01s06.html Besides for quiet a while we don't get hdc or sdc, just plain sr0/sr1 (even the scd0/scd1 was removed), and that seemed to work before if I'm not mistaken... Perhaps now the way is sr0=scsi? Any ways, maybe someone knows better, :-) I can try the boot loading thing, but before, I wanted to see if someone has experienced this, and there's a known work around. Thanks, -- Javier. Sure we know better :-) It is known problem that made it even to the install file: https://projects.archlinux.org/svntogit/community.git/tree/trunk/cdrtools.install?h=packages/cdrtools Maybe I should add it to post_upgrade() as well, so the loyal users of this package get this warning too. Or better – try to find why this module is no longer loaded. Lukas Shame on me, :-) Thanks a lot, that was it, now -scanbus works as usual... I'll add sg to the MODULES list, so I don't have to remember... Thanks again, -- Javier.
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
Javier Vasquez j.e.vasque...@gmail.com wrote: Hi, I've been using the original cdrecord (cdrtools) for more than 10 years now, however I hadn't burned anything in the last 3 months (or even more). With the current linux kernel image from Arch: % uname -a Linux jvasquez14 3.3.8-1-ARCH #1 SMP PREEMPT Tue Jun 5 15:20:32 CEST 2012 x86_64 GNU/Linux I can't get cdrecord to recognize any cd/dvd writer, not the laptop one neither an external USB one... I might be mistaken, but with 3.0 image I believe things worked (can't be sure, as I said I haven't been burning anything for months). When I try to identify the cd/dvd writers: % cdrecord -scanbus Cdrecord-ProDVD-ProBD-Clone 3.01a07 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2012 Joerg Schilling cdrecord: No such file or directory. Cannot open '/dev/pg*'. Cannot open or use SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. cdrecord: For possible transport specifiers try 'cdrecord dev=help'. Looks like a missconfigured kernel that does not include support for or for some strange reason does not load the SCSI generic driver Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
Jörg, Lukáš, On Sun, Jun 10, 2012 at 11:23 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Looks like a missconfigured kernel that does not include support for or for some strange reason does not load the SCSI generic driver Our kernel does in fact include the sg module. However, it is considered legacy [0] and udev intentionally does not autoload it [1]. If I understand correctly it should not be hard to replace it's use. Otherwise, you wight want to add to a README or something that this module must be loaded (as I guess most people are not aware of this issue). Out of interest: does the current version of cdrecord always, or at least in most cases, require this module to function, or is it only for some pieces of hardware or some functionality? On Sun, Jun 10, 2012 at 9:34 AM, Lukáš Jirkovský l.jirkov...@gmail.com wrote: Maybe I should add it to post_upgrade() as well, so the loyal users of this package get this warning too. Or better – try to find why this module is no longer loaded. If this module is wanted by a majority of cdrecord users, then you might want to simply install a file /usr/lib/modules-load.d/cdrecord.conf containing the string sg. That will load the module on boot for anyone with cdrecord installed. For more details see [2]. The module-load.d directory is supported by us, as well as all distros using systemd. So Jörg, you might consider including this upstream, if it is the sg module is really needed. Cheers, Tom [0]: http://www.spinics.net/lists/hotplug/msg05189.html [1]: http://cgit.freedesktop.org/systemd/systemd/commit/?id=09637f743414e2c36d6c5b032d77d76dbeb86b31 [2]: http://0pointer.de/public/systemd-man/modules-load.d.html
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
Tom Gundersen t...@jklm.no wrote: Jörg, Luká??, On Sun, Jun 10, 2012 at 11:23 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Looks like a missconfigured kernel that does not include support for or for some strange reason does not load the SCSI generic driver Our kernel does in fact include the sg module. However, it is considered legacy [0] and udev intentionally does not autoload it [1]. If I understand correctly it should not be hard to replace it's use. Otherwise, you wight want to add to a README or something that this module must be loaded (as I guess most people are not aware of this issue). Why should someone call an important driver legacy? Out of interest: does the current version of cdrecord always, or at least in most cases, require this module to function, or is it only for some pieces of hardware or some functionality? The sg driver is the official documented method to access any SCSI device and for this reason, libscg (the SCSI generic library) uses it. As nobody from the linux kernel folks did ever contact me related to the sg driver, it is obvious that not supporting sg is a bug. [0]: http://www.spinics.net/lists/hotplug/msg05189.html It is bad practice to replace one driver by another just to cause incompatibilities instead of enhancing existing software. [1]: http://cgit.freedesktop.org/systemd/systemd/commit/?id=09637f743414e2c36d6c5b032d77d76dbeb86b31 [2]: http://0pointer.de/public/systemd-man/modules-load.d.html and btw. this supposed sg replacement is undocumented. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
On Sun, Jun 10, 2012 at 12:06 PM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Why should someone call an important driver legacy? I assume it is because it has some problems, and has been replaced by something else. But you'd have to take it up with the udev maintainer, as he is the one who made the change, or the kernel maintainer to find out more about his reasons for introducing bsg. I'm just letting you know about the issue (I expect this change will hit most distributions soon if it has not already). As nobody from the linux kernel folks did ever contact me related to the sg driver, it is obvious that not supporting sg is a bug. Just to clarify: the kernel, and Arch, supports the sg driver just fine. However, it is not automatically loaded by udev, so people (or packages) would have to force-load it. It is bad practice to replace one driver by another just to cause incompatibilities instead of enhancing existing software. Maybe so, I'm just pointing out what has happened and what we have to deal with. I don't really know the reasons very well. and btw. this supposed sg replacement is undocumented. I could not find much about it, but if anyone is interested I found a few sources [0][1]. Notice that the motivation for this stuff seems to be cdrecord[2], so it is very strange that this has not been brought to your attention before. -t [0]: https://lwn.net/Articles/96547/ [1]: https://lwn.net/Articles/174469/ [2]: After all that SG_IO and cdrecord talk, I decided to brush off the bsg driver I wrote some time ago.
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
On 10 June 2012 11:57, Tom Gundersen t...@jklm.no wrote: The module-load.d directory is supported by us, as well as all distros using systemd. So Jörg, you might consider including this upstream, if it is the sg module is really needed. Tom, Jörg, nice to see you two interested. Tom, I don't know much about this modules-load.d stuff. Does it work with plain udev? Otherwise it wouldn't help much including that file for users that doesn't use systemd (and I'm one of them). On 10 June 2012 12:46, Tom Gundersen t...@jklm.no wrote: I could not find much about it, but if anyone is interested I found a few sources [0][1]. Notice that the motivation for this stuff seems to be cdrecord[2], so it is very strange that this has not been brought to your attention before. Yeah, I'm pretty surprised that the developer arguments with cdrecord without contacting Jörg beforehand. Anyway, the motivation might be to use the SCSI numbers instead of random numbers determined by udev. Lukas
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
On Sun, Jun 10, 2012 at 1:51 PM, Lukáš Jirkovský l.jirkov...@gmail.com wrote: Tom, I don't know much about this modules-load.d stuff. Does it work with plain udev? Otherwise it wouldn't help much including that file for users that doesn't use systemd (and I'm one of them). It works the same with initscripts and with systemd. It is strictly speaking not udev that loads these modules but a separate tool: /usr/lib/systemd/systemd-modules-load, which is shipped in the same package as udev (systemd-tools). It probably will not work on other distros that don't use systemd (though I don't really know), so that's something for upstream to keep in mind. Cheers, Tom
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
On 10 June 2012 14:05, Tom Gundersen t...@jklm.no wrote: It works the same with initscripts and with systemd. It is strictly speaking not udev that loads these modules but a separate tool: /usr/lib/systemd/systemd-modules-load, which is shipped in the same package as udev (systemd-tools). Great, I'll include it in our package then. It probably will not work on other distros that don't use systemd (though I don't really know), so that's something for upstream to keep in mind. That's what I'm afraid of – there might be more users having this problem in the future. Lukas
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
On 06/10/2012 05:23 AM, Joerg Schilling wrote: Javier Vasquez j.e.vasque...@gmail.com wrote: Hi, I've been using the original cdrecord (cdrtools) for more than 10 years now, however I hadn't burned anything in the last 3 months (or even more). With the current linux kernel image from Arch: % uname -a Linux jvasquez14 3.3.8-1-ARCH #1 SMP PREEMPT Tue Jun 5 15:20:32 CEST 2012 x86_64 GNU/Linux I can't get cdrecord to recognize any cd/dvd writer, not the laptop one neither an external USB one... I might be mistaken, but with 3.0 image I believe things worked (can't be sure, as I said I haven't been burning anything for months). When I try to identify the cd/dvd writers: % cdrecord -scanbus Cdrecord-ProDVD-ProBD-Clone 3.01a07 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2012 Joerg Schilling cdrecord: No such file or directory. Cannot open '/dev/pg*'. Cannot open or use SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. cdrecord: For possible transport specifiers try 'cdrecord dev=help'. Looks like a missconfigured kernel that does not include support for or for some strange reason does not load the SCSI generic driver Jörg cdrtools aka wodim work fine.
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
On Sun, Jun 10, 2012 at 1:47 PM, Baho Utot baho-u...@columbus.rr.com wrote: On 06/10/2012 05:23 AM, Joerg Schilling wrote: Javier Vasquez j.e.vasque...@gmail.com wrote: I've been using the original cdrecord (cdrtools) for more than 10 cdrtools aka wodim work fine. Is aka a synonym for I'm a troll?
Re: [arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
On Sat, Jun 9, 2012 at 11:24 PM, Jude DaShiell jdash...@shellworld.net wrote: Your drive could need cleaning, or have worn out, or in some way have been disconnected. Those kind of drives have to be replaced every so often. If it's a usb drive, have you done a modprobe usbmass yet? If not, that may be all you need to get things going. If you read dmesg does the cd drive even show up as a valid device now? If not, maybe insmod usbmass will fix that and get you burning. I have both drives, and they both seem OK. IDE one is sr0 and USB one is sr1: [4.894446] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray [4.894452] cdrom: Uniform CD-ROM driver Revision: 3.20 [4.894842] sr 1:0:0:0: Attached scsi CD-ROM sr0 ... [21171.638369] usb 2-2: new high-speed USB device number 5 using xhci_hcd [21171.655770] usb 2-2: ep 0x2 - rounding interval to 32768 microframes, ep desc says 0 microframes [21171.655781] usb 2-2: ep 0x86 - rounding interval to 32768 microframes, ep desc says 0 microframes [21171.700222] usbcore: registered new interface driver uas [21171.704428] Initializing USB Mass Storage driver... [21171.704526] usbcore: registered new interface driver usb-storage [21171.704530] USB Mass Storage support registered. [21171.706759] scsi7 : usb-storage 2-2:1.0 [21171.707035] usbcore: registered new interface driver ums-cypress [21174.637779] scsi 7:0:0:0: CD-ROMTSSTcorp CDDVDW SH-S202J SB02 PQ: 0 ANSI: 0 [21174.745896] sr1: scsi3-mmc drive: 12x/48x writer dvd-ram cd/rw xa/form2 cdda tray [21174.746166] sr 7:0:0:0: Attached scsi CD-ROM sr1 I don't think any of the drives has worn out... It's too much of a coincidence cdrecord has problems with both... Your comment suggests that you would expect cdrecord to work OK. So maybe you don't have any problems with it... Thanks, -- Javier.
