On Sat, Jun 9, 2012 at 11:51 PM, Javier Vasquez <j.e.vasquez.v@gmail.com> wrote:

On Sat, Jun 9, 2012 at 11:24 PM, Jude DaShiell <jdashiel@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.

On Sun, Jun 10, 2012 at 1:34 AM, Lukáš Jirkovský <l.jirkovsky@gmail.com> wrote:

On 10 June 2012 01:41, Javier Vasquez <j.e.vasquez.v@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/ar01s0...

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.in...

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.

Jörg, Lukáš, On Sun, Jun 10, 2012 at 11:23 AM, Joerg Schilling <Joerg.Schilling@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.jirkovsky@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>

On Sun, Jun 10, 2012 at 12:06 PM, Joerg Schilling <Joerg.Schilling@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."

On 10 June 2012 11:57, Tom Gundersen <teg@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 <teg@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

On 10 June 2012 14:05, Tom Gundersen <teg@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

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.Schilling@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

On 17 June 2012 01:08, Tom Gundersen <teg@jklm.no> wrote:

On Sat, Jun 16, 2012 at 9:14 PM, Lukáš Jirkovský <l.jirkovsky@gmail.com> wrote:

...

On 11 June 2012 12:05, Joerg Schilling <Joerg.Schilling@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

On Sun, Jun 10, 2012 at 1:47 PM, Baho Utot <baho-utot@columbus.rr.com> wrote:

On 06/10/2012 05:23 AM, Joerg Schilling wrote:

...

Javier Vasquez <j.e.vasquez.v@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"?