iso under OSX ;-)
Hello again, (sorry for the second thread: I can't reply to myself as I didn't keept my my first email). I managed creating the iso of a cd with sudo umount /Volumes/CD_Name and then the readcd command ;-) Grégoire http://magma.epfl.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED]
Re: plextor px-708uf: cannot get disk type
>From: Andy Polyakov <[EMAIL PROTECTED]> >> >The media is 4x DVD+R from Memorex. This is not an inherent problem >> >with the drive or media, since I can burn the same iso with growisofs. >> >> If something is caused by buggy software outside the application, >> then in many cases it may also work just by luck. >Size of the disc information structure being affected by another >application? Any other conspiracy theories? Anybody? A. I cannot see any relation from the problem observed with the 708 to the text you just send. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
iso under OSX ;-)
Hello again, (sorry for the second thread: I can't reply to myself as I didn't keept my my first email). I managed creating the iso of a cd with sudo umount /Volumes/CD_Name and then the readcd command ;-) Grégoire http://magma.epfl.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: plextor px-708uf: cannot get disk type
> >> I have a Plextor PX-708UF (USB 2.0) on a Red Hat Linux 9 machine. > >> > >> cdrecord.prodvd: Input/output error. read disk info: scsi sendcmd: no error > >> CDB: 51 00 00 00 00 00 00 00 24 00 > >^^ I don't know if following holds true > >for other USB implementations, but Linux USB is very picky about > > First: Cdrecord added support to circumvent Linux USB DMA Bugs about > 3.5 years ago. If I wanted to imply that cdrecord doesn't circumvent USB bugs/specifics I would have written "that's because cdrecord apparently ..." It wrote nothing of that sort!!! I wrote "structure is 32 bytes upon media load, which must be the cause for the trouble." > This happens, if you run the command with a DVD+R medium while > the Kernel SCSI transport is working correctly to the Plextor 708: > > Executing 'read disk info' command on Bus 0 Target 0, Lun 0 timeout 240s > CDB: 51 00 00 00 00 00 00 00 24 00 > cmd finished after 0.000s timeout 240s > Got 36 (0x24), expecting 36 (0x24) bytes of data. > Received Data: 00 22 00 01 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 23 05 40 00 00 00 00 00 00 00 00 00 00 00 00 Is it output from requestor's system? If not is it USB connected unit? But in either case given this new evidence, I have to admit that I might be wrong and it might turn out to be a firmware bug or pecularity... MMC drafts are specific about length of this structure being 32+8*n. So that the reported length is indeed bogus... Well, one has all rights to disregard bogus values... A.
Re: plextor px-708uf: cannot get disk type
>From: Andy Polyakov <[EMAIL PROTECTED]> >> >The media is 4x DVD+R from Memorex. This is not an inherent problem >> >with the drive or media, since I can burn the same iso with growisofs. >> >> If something is caused by buggy software outside the application, >> then in many cases it may also work just by luck. >Size of the disc information structure being affected by another >application? Any other conspiracy theories? Anybody? A. I cannot see any relation from the problem observed with the 708 to the text you just send. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: plextor px-708uf: cannot get disk type
> >The media is 4x DVD+R from Memorex. This is not an inherent problem > >with the drive or media, since I can burn the same iso with growisofs. > > If something is caused by buggy software outside the application, > then in many cases it may also work just by luck. Size of the disc information structure being affected by another application? Any other conspiracy theories? Anybody? A.
Re: Cdrtools-2.01a25 ready
> >Pass-through SG_IO (interface is question) is not specific to /dev/hd*. > >In other words it's not an "/dev/hd* interface" or an IDE-specific hack, > > If you previously did write correct code for the Linux /dev/sg* interface, you > should know better. > > The fact that the interfaces share a single common ioctl() does not make > them equal. Note that I'm not saying that /dev/hd* and /dev/sg* are equivalent. I'm saying that 2.6 *pass-through SG_IO interface* is applicable not only to /dev/hd*, but to *all* *block* storage devices, such as /dev/hd*, /dev/sr*, /dev/sd*. It's unified across all block devices and is perfectly usable interface. In a sense it renders /dev/sg* superfluous [at least in CD recording context] and in my opinion it's actually a step forward. > >Note that SCSI > >command-level programming through "tangible" block device not some > >Linux-specific novelty, but widely accepted implementation strategy. > > Not correct: the most widely spread interface implementation strategy is > to support generic SCSI transport. This is a level _below_ the block device > layer. Note that I made no claims about it being "most widely spread stategy." I said "widely accepted [by OS designers]." E.g. quoting IOCTL_SCSI_PASS_THROUGH page from Windows 2000 DDK: "If a class driver for the target type of device exists, the request must be sent to that class driver. Thus, an application can send this request directly to the system port driver for a target logical unit only if there is no class driver for the type of device connected to that LU." In other words native NT interface *requires* "tangible" block device. BTW, is NT native interface "widely spread" enough? Another example. Quoting Solaris sgen(7D) manual page: "It is important for the administrator to ensure that dev- ices claimed by the sgen driver do not conflict with exist- ing target drivers on the system. For example, if the sgen driver is configured to bind to a direct access device, the standard sd.conf file will usually cause sd to claim the device as well. This can cause unpredictable results. In general, the uscsi(7I) interface exported by sd(7D) or st(7D) should be used to gain access to direct access and sequential devices." Same story again. Native USCSI ioctls should be issued against "tangible" block device entry... > >It's rather contrary. It's not disregarding SCSI protocol layering, but > >affirming it by putting applications to the level they naturally belongs > >in. Layers lower than SCSI command block is pure kernel domain. > > Definitely wrong. > ... the kind of code that support > CD writing scanning and similar belongs into user space. Let's stick to CD writing, because a) that's what we're discussing here and b) recorder units *are* [and will be for foreseeable feature] handled by block drivers. > The highest possible protocol layer is the generic SCSI transport layer. > ... > As CD writing is a user space task, applications that > support these tasks should use the highest possible protocol layer Says who? The commonly acceptable and respected principle is "required minimum." SCSI command block is more that sufficient to implement recording and therefore there is no reason whatsoever to expose lower transport layers to user-land. A.
Re: plextor px-708uf: cannot get disk type
> >> I have a Plextor PX-708UF (USB 2.0) on a Red Hat Linux 9 machine. > >> > >> cdrecord.prodvd: Input/output error. read disk info: scsi sendcmd: no error > >> CDB: 51 00 00 00 00 00 00 00 24 00 > >^^ I don't know if following holds true > >for other USB implementations, but Linux USB is very picky about > > First: Cdrecord added support to circumvent Linux USB DMA Bugs about > 3.5 years ago. If I wanted to imply that cdrecord doesn't circumvent USB bugs/specifics I would have written "that's because cdrecord apparently ..." It wrote nothing of that sort!!! I wrote "structure is 32 bytes upon media load, which must be the cause for the trouble." > This happens, if you run the command with a DVD+R medium while > the Kernel SCSI transport is working correctly to the Plextor 708: > > Executing 'read disk info' command on Bus 0 Target 0, Lun 0 timeout 240s > CDB: 51 00 00 00 00 00 00 00 24 00 > cmd finished after 0.000s timeout 240s > Got 36 (0x24), expecting 36 (0x24) bytes of data. > Received Data: 00 22 00 01 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 23 05 > 40 00 00 00 00 00 00 00 00 00 00 00 00 Is it output from requestor's system? If not is it USB connected unit? But in either case given this new evidence, I have to admit that I might be wrong and it might turn out to be a firmware bug or pecularity... MMC drafts are specific about length of this structure being 32+8*n. So that the reported length is indeed bogus... Well, one has all rights to disregard bogus values... A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: plextor px-708uf: cannot get disk type
> >The media is 4x DVD+R from Memorex. This is not an inherent problem > >with the drive or media, since I can burn the same iso with growisofs. > > If something is caused by buggy software outside the application, > then in many cases it may also work just by luck. Size of the disc information structure being affected by another application? Any other conspiracy theories? Anybody? A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cdrtools-2.01a25 ready
> >Pass-through SG_IO (interface is question) is not specific to /dev/hd*. > >In other words it's not an "/dev/hd* interface" or an IDE-specific hack, > > If you previously did write correct code for the Linux /dev/sg* interface, you > should know better. > > The fact that the interfaces share a single common ioctl() does not make > them equal. Note that I'm not saying that /dev/hd* and /dev/sg* are equivalent. I'm saying that 2.6 *pass-through SG_IO interface* is applicable not only to /dev/hd*, but to *all* *block* storage devices, such as /dev/hd*, /dev/sr*, /dev/sd*. It's unified across all block devices and is perfectly usable interface. In a sense it renders /dev/sg* superfluous [at least in CD recording context] and in my opinion it's actually a step forward. > >Note that SCSI > >command-level programming through "tangible" block device not some > >Linux-specific novelty, but widely accepted implementation strategy. > > Not correct: the most widely spread interface implementation strategy is > to support generic SCSI transport. This is a level _below_ the block device > layer. Note that I made no claims about it being "most widely spread stategy." I said "widely accepted [by OS designers]." E.g. quoting IOCTL_SCSI_PASS_THROUGH page from Windows 2000 DDK: "If a class driver for the target type of device exists, the request must be sent to that class driver. Thus, an application can send this request directly to the system port driver for a target logical unit only if there is no class driver for the type of device connected to that LU." In other words native NT interface *requires* "tangible" block device. BTW, is NT native interface "widely spread" enough? Another example. Quoting Solaris sgen(7D) manual page: "It is important for the administrator to ensure that dev- ices claimed by the sgen driver do not conflict with exist- ing target drivers on the system. For example, if the sgen driver is configured to bind to a direct access device, the standard sd.conf file will usually cause sd to claim the device as well. This can cause unpredictable results. In general, the uscsi(7I) interface exported by sd(7D) or st(7D) should be used to gain access to direct access and sequential devices." Same story again. Native USCSI ioctls should be issued against "tangible" block device entry... > >It's rather contrary. It's not disregarding SCSI protocol layering, but > >affirming it by putting applications to the level they naturally belongs > >in. Layers lower than SCSI command block is pure kernel domain. > > Definitely wrong. > ... the kind of code that support > CD writing scanning and similar belongs into user space. Let's stick to CD writing, because a) that's what we're discussing here and b) recorder units *are* [and will be for foreseeable feature] handled by block drivers. > The highest possible protocol layer is the generic SCSI transport layer. > ... > As CD writing is a user space task, applications that > support these tasks should use the highest possible protocol layer Says who? The commonly acceptable and respected principle is "required minimum." SCSI command block is more that sufficient to implement recording and therefore there is no reason whatsoever to expose lower transport layers to user-land. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
iso creation under OSX?
Hello, I have just compiled reacd under OSX to create an iso from a CD but it result in an error as the finder is also accessing the drive... Is there an easy way to create an iso from the CD under OSX? Thank you very much, Grégoire http://magma.epfl.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED]
iso creation under OSX?
Hello, I have just compiled reacd under OSX to create an iso from a CD but it result in an error as the finder is also accessing the drive... Is there an easy way to create an iso from the CD under OSX? Thank you very much, Grégoire http://magma.epfl.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SONY DRU500-AX and TDK DVD+R 4X problem
ust wanted to tell you that after putting a 80-wire cable, and making my
DVD writer slave from master, now I get the following messages...
Kernel:
hdb: DMA timeout retry
hdb: timeout waiting for DMA
hdb: status timeout: status=0xd0 { Busy }
hdb: status timeout: error=0xd0LastFailedSense 0x0d
hdb: drive not ready for command
hdb: ATAPI reset complete
cdrom_newpc_intr: 32768 residual after xfer
K3b:
System
---
K3b Version: 0.10.99
KDE Version: 3.1.94 (CVS >= 20031206)
QT Version: 3.2.3
growisofs
---
/dev/hdb: "Current Write Speed" is 4.0x1385KBps.
0.02% done, estimate finish Sat Jan 17 08:04:04 2004
0.05% done, estimate finish Sat Jan 17 08:03:11 2004
0.07% done, estimate finish Sat Jan 17 07:39:04 2004
0.09% done, estimate finish Sat Jan 17 07:26:54 2004
:-( unable to [EMAIL PROTECTED]: Input/output error
:-( write failed: Input/output error
/dev/hdb: flushing cache
/dev/hdb: closing track
/dev/hdb: closing disc
growisofs comand:
---
/usr/bin/growisofs -Z /dev/hdb -use-the-force-luke=notray
-use-the-force-luke=tty -use-the-force-luke=dao -speed=4 -gui
-graft-points
-V EFAPAX -volset -A K3B THE CD KREATOR VERSION 0.10.99 (C) 2003
SEBASTIAN TRUEG AND THE K3B TEAM -P -p K3b - Version 0.10.99 -sysid
LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-root/k3buiSzia.tmp
-udf -l -iso-level 2 -path-list /tmp/kde-root/k3b62Cp0b.tmp
dvd+rw-mediainfo /dev/dvd:
INQUIRY:[SONY][DVD RW DRU-500A ][2.0g]
GET [CURRENT] CONFIGURATION:
Mounted Media: 1Bh, DVD+R
Media ID: RICOHJPN/R01
Current Write Speed: 4.0x1385=5540KB/s
Write Speed #0:4.0x1385=5540KB/s
GET PERFORMANCE:
Speed Descriptor#0:00/2295103 [EMAIL PROTECTED] [EMAIL PROTECTED]
Speed Descriptor#1:00/2295103 [EMAIL PROTECTED] [EMAIL PROTECTED]
Speed Descriptor#2:00/2295103 [EMAIL PROTECTED] [EMAIL PROTECTED]
READ DVD STRUCTURE[#0h]:
Media Book Type: A1h, DVD+R book [revision 1]
Legacy lead-out at:2256*2KB=4620288
READ DISC INFORMATION:
Disc status: complete
Number of Sessions:1
State of Last Session: complete
Number of Tracks: 1
READ TRACK INFORMATION[#1]:
Track State: complete
Track Start Address: 0*2KB
Free Blocks: 0*2KB
Track Size:2256*2KB
FABRICATED TOC:
Track#1 : [EMAIL PROTECTED]
Track#AA : [EMAIL PROTECTED]
Multi-session Info:[EMAIL PROTECTED]
Regards
Panagiotis Papadakos
Re: Cdrtools-2.01a25 ready
>From: Andy Polyakov <[EMAIL PROTECTED]>
>> - Try to support the half hearted and badly designed /dev/hd* interface
>> from Linux-2.6 in a more usable way.
>>
>> Note: The Bus mapping function inside the kernel for this interface
>> is
>> a dummy. For this reason, we need to do the mapping ourself.
>> Busnummer is ("/dev/hd*"[7] - 'a') / 2
>> Lun is ("/dev/hd*"[7] - 'a') % 2
> ^^^ Typo?
Yes, thank you this should be "target".
>> Adding SCSI transport to something like /dev/hd*
>Pass-through SG_IO (interface is question) is not specific to /dev/hd*.
>In other words it's not an "/dev/hd* interface" or an IDE-specific hack,
If you previously did write correct code for the Linux /dev/sg* interface, you
should know better.
The fact that the interfaces share a single common ioctl() does not make
them equal.
Even before 2.01a25, I was forced to introduce significant changes on the
adaption code in scsi-linux-sg.c to make it possible that dev=/dev/hdc may
be used. If you like to use /dev/sg* correctly, you need to do things you
are not allowed to do with /dev/hd*
>but a road-map if you wish. Because the idea is to use "tangible" block
>device entries with *all* recorders, not only IDE units. Note that SCSI
>command-level programming through "tangible" block device not some
>Linux-specific novelty, but widely accepted implementation strategy.
Not correct: the most widely spread interface implementation strategy is
to support generic SCSI transport. This is a level _below_ the block device
layer.
>> on an OS that includes
>> a generic SCSI transport driver is disregarding SCSI protocol
>> layering.
>It's rather contrary. It's not disregarding SCSI protocol layering, but
>affirming it by putting applications to the level they naturally belongs
>in. Layers lower than SCSI command block is pure kernel domain. Generic
Definitely wrong.
The UNIX device interface does not allow devices like CD-writers, scanners
and similar to be inplemented in a way that stands more than a year.
Even formatting disks is nothing that may be implemented cleanly inside a
block device driver. For this reson, the kind of code that support
CD writing scanning and similar belongs into user space.
As CD writing and scanning is a user space task, applications that
support these tasks should use the highest possible protocol layer that
may be implemented in a stable (over the time) and device independent
way. Cdrecord and libscg just follow this strategy.
The highest possible protocol layer is the generic SCSI transport layer.
It should be obvious that the naming scheme used by the generic SCSI
transport implementation should only be bound to this layer and not
depend on layers like the block device layer.
Do you really like a scanner support software to open() a block device
node? If you do, please tell me which!
>SCSI should be used with targets which are not controlled by any other
>kernel driver. Preferably generic SCSI should not even hook up all the
>targets, but only those explicitly pointed out (pretty much the way it's
Why do you like to force people to be unable to use a unique and orhogonal
way of accessing SCSI?
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni) If you don't have iso-8859-1
[EMAIL PROTECTED](work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling
ftp://ftp.berlios.de/pub/schily
Re: SONY DRU500-AX and TDK DVD+R 4X problem
ust wanted to tell you that after putting a 80-wire cable, and making my
DVD writer slave from master, now I get the following messages...
Kernel:
hdb: DMA timeout retry
hdb: timeout waiting for DMA
hdb: status timeout: status=0xd0 { Busy }
hdb: status timeout: error=0xd0LastFailedSense 0x0d
hdb: drive not ready for command
hdb: ATAPI reset complete
cdrom_newpc_intr: 32768 residual after xfer
K3b:
System
---
K3b Version: 0.10.99
KDE Version: 3.1.94 (CVS >= 20031206)
QT Version: 3.2.3
growisofs
---
/dev/hdb: "Current Write Speed" is 4.0x1385KBps.
0.02% done, estimate finish Sat Jan 17 08:04:04 2004
0.05% done, estimate finish Sat Jan 17 08:03:11 2004
0.07% done, estimate finish Sat Jan 17 07:39:04 2004
0.09% done, estimate finish Sat Jan 17 07:26:54 2004
:-( unable to [EMAIL PROTECTED]: Input/output error
:-( write failed: Input/output error
/dev/hdb: flushing cache
/dev/hdb: closing track
/dev/hdb: closing disc
growisofs comand:
---
/usr/bin/growisofs -Z /dev/hdb -use-the-force-luke=notray
-use-the-force-luke=tty -use-the-force-luke=dao -speed=4 -gui
-graft-points
-V EFAPAX -volset -A K3B THE CD KREATOR VERSION 0.10.99 (C) 2003
SEBASTIAN TRUEG AND THE K3B TEAM -P -p K3b - Version 0.10.99 -sysid
LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-root/k3buiSzia.tmp
-udf -l -iso-level 2 -path-list /tmp/kde-root/k3b62Cp0b.tmp
dvd+rw-mediainfo /dev/dvd:
INQUIRY:[SONY][DVD RW DRU-500A ][2.0g]
GET [CURRENT] CONFIGURATION:
Mounted Media: 1Bh, DVD+R
Media ID: RICOHJPN/R01
Current Write Speed: 4.0x1385=5540KB/s
Write Speed #0:4.0x1385=5540KB/s
GET PERFORMANCE:
Speed Descriptor#0:00/2295103 [EMAIL PROTECTED] [EMAIL PROTECTED]
Speed Descriptor#1:00/2295103 [EMAIL PROTECTED] [EMAIL PROTECTED]
Speed Descriptor#2:00/2295103 [EMAIL PROTECTED] [EMAIL PROTECTED]
READ DVD STRUCTURE[#0h]:
Media Book Type: A1h, DVD+R book [revision 1]
Legacy lead-out at:2256*2KB=4620288
READ DISC INFORMATION:
Disc status: complete
Number of Sessions:1
State of Last Session: complete
Number of Tracks: 1
READ TRACK INFORMATION[#1]:
Track State: complete
Track Start Address: 0*2KB
Free Blocks: 0*2KB
Track Size:2256*2KB
FABRICATED TOC:
Track#1 : [EMAIL PROTECTED]
Track#AA : [EMAIL PROTECTED]
Multi-session Info:[EMAIL PROTECTED]
Regards
Panagiotis Papadakos
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cdrtools-2.01a25 ready
>From: Andy Polyakov <[EMAIL PROTECTED]>
>> - Try to support the half hearted and badly designed /dev/hd* interface
>> from Linux-2.6 in a more usable way.
>>
>> Note: The Bus mapping function inside the kernel for this interface is
>> a dummy. For this reason, we need to do the mapping ourself.
>> Busnummer is ("/dev/hd*"[7] - 'a') / 2
>> Lun is ("/dev/hd*"[7] - 'a') % 2
> ^^^ Typo?
Yes, thank you this should be "target".
>> Adding SCSI transport to something like /dev/hd*
>Pass-through SG_IO (interface is question) is not specific to /dev/hd*.
>In other words it's not an "/dev/hd* interface" or an IDE-specific hack,
If you previously did write correct code for the Linux /dev/sg* interface, you
should know better.
The fact that the interfaces share a single common ioctl() does not make
them equal.
Even before 2.01a25, I was forced to introduce significant changes on the
adaption code in scsi-linux-sg.c to make it possible that dev=/dev/hdc may
be used. If you like to use /dev/sg* correctly, you need to do things you
are not allowed to do with /dev/hd*
>but a road-map if you wish. Because the idea is to use "tangible" block
>device entries with *all* recorders, not only IDE units. Note that SCSI
>command-level programming through "tangible" block device not some
>Linux-specific novelty, but widely accepted implementation strategy.
Not correct: the most widely spread interface implementation strategy is
to support generic SCSI transport. This is a level _below_ the block device
layer.
>> on an OS that includes
>> a generic SCSI transport driver is disregarding SCSI protocol layering.
>It's rather contrary. It's not disregarding SCSI protocol layering, but
>affirming it by putting applications to the level they naturally belongs
>in. Layers lower than SCSI command block is pure kernel domain. Generic
Definitely wrong.
The UNIX device interface does not allow devices like CD-writers, scanners
and similar to be inplemented in a way that stands more than a year.
Even formatting disks is nothing that may be implemented cleanly inside a
block device driver. For this reson, the kind of code that support
CD writing scanning and similar belongs into user space.
As CD writing and scanning is a user space task, applications that
support these tasks should use the highest possible protocol layer that
may be implemented in a stable (over the time) and device independent
way. Cdrecord and libscg just follow this strategy.
The highest possible protocol layer is the generic SCSI transport layer.
It should be obvious that the naming scheme used by the generic SCSI
transport implementation should only be bound to this layer and not
depend on layers like the block device layer.
Do you really like a scanner support software to open() a block device
node? If you do, please tell me which!
>SCSI should be used with targets which are not controlled by any other
>kernel driver. Preferably generic SCSI should not even hook up all the
>targets, but only those explicitly pointed out (pretty much the way it's
Why do you like to force people to be unable to use a unique and orhogonal
way of accessing SCSI?
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni) If you don't have iso-8859-1
[EMAIL PROTECTED](work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XCDRoast (was: Re: plextor px-708uf: cannot get disk type)
On Sat 17 January 2004 15:19, j_post wrote: > On Saturday 17 January 2004 04:39 am, Joerg Schilling wrote: > > People who used Xcdroast once, mostly don't like to use other > > GUIs anymore. > > Is that because Xcdroast is somehow "better" than the other GUIs, > or just because people tend to think "it works, so why bother > with anything else"? In my case, it was "Huh? Okay, I'll use the command line, that's probably easier to learn" which I subsequently did for a while. Then I found K3B, and although I was a bit afraid that it might be as bad as Xcdroast, I tried it anyway, and found it very intuitive. I now use either K3B or the command line, rather randomly. I think Xcdroast is nice if you (want to) know what happens when you burn a CD, ie creating an image and burning it in a specific way. If you're just an end user who wants to put his latest digital photos on a CD for mum and don't care how or what then I recommend using something else. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: plextor px-708uf: cannot get disk type
On Saturday 17 January 2004 04:39 am, Joerg Schilling wrote: > People who used Xcdroast once, mostly don't like to use other GUIs anymore. > Is that because Xcdroast is somehow "better" than the other GUIs, or just because people tend to think "it works, so why bother with anything else"? JP
Re: XCDRoast (was: Re: plextor px-708uf: cannot get disk type)
On Sat 17 January 2004 15:19, j_post wrote: > On Saturday 17 January 2004 04:39 am, Joerg Schilling wrote: > > People who used Xcdroast once, mostly don't like to use other > > GUIs anymore. > > Is that because Xcdroast is somehow "better" than the other GUIs, > or just because people tend to think "it works, so why bother > with anything else"? In my case, it was "Huh? Okay, I'll use the command line, that's probably easier to learn" which I subsequently did for a while. Then I found K3B, and although I was a bit afraid that it might be as bad as Xcdroast, I tried it anyway, and found it very intuitive. I now use either K3B or the command line, rather randomly. I think Xcdroast is nice if you (want to) know what happens when you burn a CD, ie creating an image and burning it in a specific way. If you're just an end user who wants to put his latest digital photos on a CD for mum and don't care how or what then I recommend using something else. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: plextor px-708uf: cannot get disk type
On Saturday 17 January 2004 04:39 am, Joerg Schilling wrote: > People who used Xcdroast once, mostly don't like to use other GUIs anymore. > Is that because Xcdroast is somehow "better" than the other GUIs, or just because people tend to think "it works, so why bother with anything else"? JP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: plextor px-708uf: cannot get disk type
>From: Andy Polyakov <[EMAIL PROTECTED]> >> I have a Plextor PX-708UF (USB 2.0) on a Red Hat Linux 9 machine. >> >> cdrecord.prodvd: Input/output error. read disk info: scsi sendcmd: no error >> CDB: 51 00 00 00 00 00 00 00 24 00 >^^ I don't know if following holds true >for other USB implementations, but Linux USB is very picky about First: Cdrecord added support to circumvent Linux USB DMA Bugs about 3.5 years ago. In contrary to many other known software, cdrecord uses the official way (documented in the SCSI standard) to find the right DMA transfer size for structures of unknown lenght. This happens, if you run the command with a DVD+R medium while the Kernel SCSI transport is working correctly to the Plextor 708: Executing 'read disk info' command on Bus 0 Target 0, Lun 0 timeout 240s CDB: 51 00 00 00 00 00 00 00 24 00 cmd finished after 0.000s timeout 240s Got 36 (0x24), expecting 36 (0x24) bytes of data. Received Data: 00 22 00 01 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 23 05 40 00 00 00 00 00 00 00 00 00 00 00 00 >> I can burn the same iso with growisofs. >USB deficiency mentioned above was addressed in dvd+rw-tools in August >2002. Cdrecord knows to deal with the Linux USB bugs twice as long as DVD+RW tools exist. This is definitely not a cdrecord problem! >> Xcdroast otherwise works >Note that there're GUI front-ends to growisofs too... People who used Xcdroast once, mostly don't like to use other GUIs anymore. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: plextor px-708uf: cannot get disk type
>From: Thomas J Magliery PhD <[EMAIL PROTECTED]> >I have a Plextor PX-708UF (USB 2.0) on a Red Hat Linux 9 machine. When >I try to burn an ISO from either xcdroast or the dvdrecord command line, >I get the following: > >Unlocked features: ProDVD Clone >Limited features: >This copy of cdrecord is licensed for: >private/research/educational_non-commercial_use >Using libscg version 'schily-0.8'. >Device type: Removable CD-ROM >Version: 2 >Response Format: 1 >Vendor_info: 'PLEXTOR ' >Identifikation : 'DVDR PX-708A ' >Revision : '1.03' The first Firmware from Plextor that is known to work halfway correctly is 1.04. Please first update the firmware, it is possible since more than a month! >Device seems to be: Generic mmc2 DVD-R/DVD-RW. >Using generic SCSI-3/mmc-3 DVD+R driver (mmc_dvdplusr). >Driver flags : DVD MMC-3 SWABAUDIO BURNFREE >Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R >cdrecord.prodvd: Input/output error. read disk info: scsi sendcmd: no error >CDB: 51 00 00 00 00 00 00 00 24 00 >status: 0x2 (CHECK CONDITION) >Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 >Sense Key: 0x0 No Additional Sense, Segment 0 >Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 >Sense flags: Blk 0 (not valid) >cmd finished after 0.002s timeout 240s >cdrecord.prodvd: Cannot get disk type. >= If this _still_ fails after you upgraded to 1.04, then there are two possible reasons: - A Linux Kernel bug - there are many of them. - An unfriendly second application tries to do simultaneous access. A typical well known application is k3b from KDE. In order to make sure this does not apply, boot into single use mode. and try again. >The media is 4x DVD+R from Memorex. This is not an inherent problem >with the drive or media, since I can burn the same iso with growisofs. If something is caused by buggy software outside the application, then in many cases it may also work just by luck. > Xcdroast otherwise works (I used it to make the iso file), and it >correctly detects a CD-R (48x Memorex) when I tap ATIP-Info and it's in >the drive. I don't have DVD-R to test, but I will do that. As DVD+R does not implement a simulation mode, it is recommended to use a DVD-R or DVD-RW for tests. >Perhaps this is a firmware issue--I see there is a version 1.04 >available for this drive. (I gather the 708A is basically the same >drive.) Can one upgrade Plextor firmware in Linux, or do I have to put >this on a Windows machine to do it? Support for upgrading the firmware for the plextor 708 was added 2.5 months ago. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
i got the solution :blanking last few tracks
hi all , i dint know how to blank last few tracks.i tried with blank=session option for cdrecord.which will delete the last track written.if we run more times it will go on deleting previous sessions.this looks enough for me.(but i just want to know how to delete particular track by using blank=track for cdrecord.)thanx. -manu Note: forwarded message attached. Yahoo! India Mobile: Download the latest polyphonic ringtones. Go to http://in.mobile.yahoo.com--- Begin Message --- hi all i am new to this list. i want to blank a few last written tracks from the CDRW. thir is blank=track option is thir for cdrecord. if i have 5 tracks of data on cd-rewritable, i want to blank last 3 tracks can anybody tell me how can i. iam using Redhatlinux 9 on p4. -manu. Yahoo! India Mobile: Download the latest polyphonic ringtones. Go to http://in.mobile.yahoo.com --- End Message ---
Re: plextor px-708uf: cannot get disk type
>From: Andy Polyakov <[EMAIL PROTECTED]> >> I have a Plextor PX-708UF (USB 2.0) on a Red Hat Linux 9 machine. >> >> cdrecord.prodvd: Input/output error. read disk info: scsi sendcmd: no error >> CDB: 51 00 00 00 00 00 00 00 24 00 >^^ I don't know if following holds true >for other USB implementations, but Linux USB is very picky about First: Cdrecord added support to circumvent Linux USB DMA Bugs about 3.5 years ago. In contrary to many other known software, cdrecord uses the official way (documented in the SCSI standard) to find the right DMA transfer size for structures of unknown lenght. This happens, if you run the command with a DVD+R medium while the Kernel SCSI transport is working correctly to the Plextor 708: Executing 'read disk info' command on Bus 0 Target 0, Lun 0 timeout 240s CDB: 51 00 00 00 00 00 00 00 24 00 cmd finished after 0.000s timeout 240s Got 36 (0x24), expecting 36 (0x24) bytes of data. Received Data: 00 22 00 01 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 23 05 40 00 00 00 00 00 00 00 00 00 00 00 00 >> I can burn the same iso with growisofs. >USB deficiency mentioned above was addressed in dvd+rw-tools in August >2002. Cdrecord knows to deal with the Linux USB bugs twice as long as DVD+RW tools exist. This is definitely not a cdrecord problem! >> Xcdroast otherwise works >Note that there're GUI front-ends to growisofs too... People who used Xcdroast once, mostly don't like to use other GUIs anymore. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: plextor px-708uf: cannot get disk type
>From: Thomas J Magliery PhD <[EMAIL PROTECTED]> >I have a Plextor PX-708UF (USB 2.0) on a Red Hat Linux 9 machine. When >I try to burn an ISO from either xcdroast or the dvdrecord command line, >I get the following: > >Unlocked features: ProDVD Clone >Limited features: >This copy of cdrecord is licensed for: >private/research/educational_non-commercial_use >Using libscg version 'schily-0.8'. >Device type: Removable CD-ROM >Version: 2 >Response Format: 1 >Vendor_info: 'PLEXTOR ' >Identifikation : 'DVDR PX-708A ' >Revision : '1.03' The first Firmware from Plextor that is known to work halfway correctly is 1.04. Please first update the firmware, it is possible since more than a month! >Device seems to be: Generic mmc2 DVD-R/DVD-RW. >Using generic SCSI-3/mmc-3 DVD+R driver (mmc_dvdplusr). >Driver flags : DVD MMC-3 SWABAUDIO BURNFREE >Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R >cdrecord.prodvd: Input/output error. read disk info: scsi sendcmd: no error >CDB: 51 00 00 00 00 00 00 00 24 00 >status: 0x2 (CHECK CONDITION) >Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 >Sense Key: 0x0 No Additional Sense, Segment 0 >Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 >Sense flags: Blk 0 (not valid) >cmd finished after 0.002s timeout 240s >cdrecord.prodvd: Cannot get disk type. >= If this _still_ fails after you upgraded to 1.04, then there are two possible reasons: - A Linux Kernel bug - there are many of them. - An unfriendly second application tries to do simultaneous access. A typical well known application is k3b from KDE. In order to make sure this does not apply, boot into single use mode. and try again. >The media is 4x DVD+R from Memorex. This is not an inherent problem >with the drive or media, since I can burn the same iso with growisofs. If something is caused by buggy software outside the application, then in many cases it may also work just by luck. > Xcdroast otherwise works (I used it to make the iso file), and it >correctly detects a CD-R (48x Memorex) when I tap ATIP-Info and it's in >the drive. I don't have DVD-R to test, but I will do that. As DVD+R does not implement a simulation mode, it is recommended to use a DVD-R or DVD-RW for tests. >Perhaps this is a firmware issue--I see there is a version 1.04 >available for this drive. (I gather the 708A is basically the same >drive.) Can one upgrade Plextor firmware in Linux, or do I have to put >this on a Windows machine to do it? Support for upgrading the firmware for the plextor 708 was added 2.5 months ago. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
i got the solution :blanking last few tracks
hi all , i dint know how to blank last few tracks.i tried with blank=session option for cdrecord.which will delete the last track written.if we run more times it will go on deleting previous sessions.this looks enough for me.(but i just want to know how to delete particular track by using blank=track for cdrecord.)thanx. -manu Note: forwarded message attached. Yahoo! India Mobile: Download the latest polyphonic ringtones. Go to http://in.mobile.yahoo.com--- Begin Message --- hi all i am new to this list. i want to blank a few last written tracks from the CDRW. thir is blank=track option is thir for cdrecord. if i have 5 tracks of data on cd-rewritable, i want to blank last 3 tracks can anybody tell me how can i. iam using Redhatlinux 9 on p4. -manu. Yahoo! India Mobile: Download the latest polyphonic ringtones. Go to http://in.mobile.yahoo.com --- End Message ---
Re: Cdrtools-2.01a25 ready
> - Try to support the half hearted and badly designed /dev/hd* interface
> from Linux-2.6 in a more usable way.
>
> Note: The Bus mapping function inside the kernel for this interface is
> a dummy. For this reason, we need to do the mapping ourself.
> Busnummer is ("/dev/hd*"[7] - 'a') / 2
> Lun is ("/dev/hd*"[7] - 'a') % 2
^^^ Typo?
> Adding SCSI transport to something like /dev/hd*
Pass-through SG_IO (interface is question) is not specific to /dev/hd*.
In other words it's not an "/dev/hd* interface" or an IDE-specific hack,
but a road-map if you wish. Because the idea is to use "tangible" block
device entries with *all* recorders, not only IDE units. Note that SCSI
command-level programming through "tangible" block device not some
Linux-specific novelty, but widely accepted implementation strategy.
> on an OS that includes
> a generic SCSI transport driver is disregarding SCSI protocol
> layering.
It's rather contrary. It's not disregarding SCSI protocol layering, but
affirming it by putting applications to the level they naturally belongs
in. Layers lower than SCSI command block is pure kernel domain. Generic
SCSI should be used with targets which are not controlled by any other
kernel driver. Preferably generic SCSI should not even hook up all the
targets, but only those explicitly pointed out (pretty much the way it's
done in Solaris sgen). A.
hi all how to blank a track
hi all i am new to this list. i want to blank a few last written tracks from the CDRW. thir is blank=track option is thir for cdrecord. if i have 5 tracks of data on cd-rewritable, i want to blank last 3 tracks can anybody tell me how can i. iam using Redhatlinux 9 on p4. -manu. Yahoo! India Mobile: Download the latest polyphonic ringtones. Go to http://in.mobile.yahoo.com
Re: Sony DRU-510A, cannot burn dvd's on Solaris9 x386
> OS: Solaris 9, x386 > cdrecord version: cd-record-prodvd-2.01a12-i386-pc-solaris2.9 > DVD Model: Sony DRU-510A > > When I try to burn a DVD (using DVD-R media this is the results I get ... > > Starting to write CD/DVD at speed 2 in real TAO mode for single session. > CDB: 2A 00 00 00 08 B8 00 00 1F 00 > Sense Bytes: 70 00 05 00 00 00 00 12 00 00 00 00 21 02 00 C0 00 02 > Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0 > cdrecord: It looks like 'driveropts=burnfree' does not work for this drive. > CDB: 00 00 00 00 00 00 > Sense Bytes: 70 00 02 00 00 00 00 12 00 00 00 00 04 08 00 00 00 00 > Sense Code: 0x04 Qual 0x08 (logical unit not ready, long write in progress) As error printout suggests there is a possibility that buffer underrun protection is not effective in the recording mode in question. One can argue if it's firmware deficiency or not, because if you read for example Mt.Fuji drafts, buffer underrun protection is not defined [or is optional] in DVD-R DAO mode. The exact wording is "If a buffer under-run occurs, the logical unit shall stop writing immediately and the logical unit shall start writing of Lead-out." Where "shall" is defined previously in document as "mandatory requirement." This was discussed once, long time ago... Following option is most likely irrelevant, but such behaviour (INVALID ADDRESS FOR WRITE while LONG WRITE IN PROGRESS) was observed under Solaris 8 with USB connected units... You mentioned that you run Solaris 9, but is it external or IDE unit you're talking about? > Could someone help me out here? You can double-check DMA settings and abstain from using your computer during recording (in order to minimize probability of buffer underrun) or you can download dvd+rw-tools at http://fy.chalmers.se/~appro/linux/DVD+RW/. Despite the name and page heading, it works with all kind of DVD media and runs under several OSes including Solaris. A.
Re: Cdrtools-2.01a25 ready
> - Try to support the half hearted and badly designed /dev/hd* interface
> from Linux-2.6 in a more usable way.
>
> Note: The Bus mapping function inside the kernel for this interface is
> a dummy. For this reason, we need to do the mapping ourself.
> Busnummer is ("/dev/hd*"[7] - 'a') / 2
> Lun is ("/dev/hd*"[7] - 'a') % 2
^^^ Typo?
> Adding SCSI transport to something like /dev/hd*
Pass-through SG_IO (interface is question) is not specific to /dev/hd*.
In other words it's not an "/dev/hd* interface" or an IDE-specific hack,
but a road-map if you wish. Because the idea is to use "tangible" block
device entries with *all* recorders, not only IDE units. Note that SCSI
command-level programming through "tangible" block device not some
Linux-specific novelty, but widely accepted implementation strategy.
> on an OS that includes
> a generic SCSI transport driver is disregarding SCSI protocol layering.
It's rather contrary. It's not disregarding SCSI protocol layering, but
affirming it by putting applications to the level they naturally belongs
in. Layers lower than SCSI command block is pure kernel domain. Generic
SCSI should be used with targets which are not controlled by any other
kernel driver. Preferably generic SCSI should not even hook up all the
targets, but only those explicitly pointed out (pretty much the way it's
done in Solaris sgen). A.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: plextor px-708uf: cannot get disk type
> I have a Plextor PX-708UF (USB 2.0) on a Red Hat Linux 9 machine. > > cdrecord.prodvd: Input/output error. read disk info: scsi sendcmd: no error > CDB: 51 00 00 00 00 00 00 00 24 00 ^^ I don't know if following holds true for other USB implementations, but Linux USB is very picky about allocation length. Most notably if you ask for M bytes while only M-N bytes are available for transfer, the transport fails. I don't know what is the current status, but it used to "reset bus" in such situation. Check your logs. In either case the structure returned by CDB in question is variable length and is 32/0x20 bytes upon media load, which must be the cause for the trouble. > I can burn the same iso with growisofs. USB deficiency mentioned above was addressed in dvd+rw-tools in August 2002. > Xcdroast otherwise works Note that there're GUI front-ends to growisofs too... > Perhaps this is a firmware issue-- Hardly. A.
hi all how to blank a track
hi all i am new to this list. i want to blank a few last written tracks from the CDRW. thir is blank=track option is thir for cdrecord. if i have 5 tracks of data on cd-rewritable, i want to blank last 3 tracks can anybody tell me how can i. iam using Redhatlinux 9 on p4. -manu. Yahoo! India Mobile: Download the latest polyphonic ringtones. Go to http://in.mobile.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sony DRU-510A, cannot burn dvd's on Solaris9 x386
> OS: Solaris 9, x386 > cdrecord version: cd-record-prodvd-2.01a12-i386-pc-solaris2.9 > DVD Model: Sony DRU-510A > > When I try to burn a DVD (using DVD-R media this is the results I get ... > > Starting to write CD/DVD at speed 2 in real TAO mode for single session. > CDB: 2A 00 00 00 08 B8 00 00 1F 00 > Sense Bytes: 70 00 05 00 00 00 00 12 00 00 00 00 21 02 00 C0 00 02 > Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0 > cdrecord: It looks like 'driveropts=burnfree' does not work for this drive. > CDB: 00 00 00 00 00 00 > Sense Bytes: 70 00 02 00 00 00 00 12 00 00 00 00 04 08 00 00 00 00 > Sense Code: 0x04 Qual 0x08 (logical unit not ready, long write in progress) As error printout suggests there is a possibility that buffer underrun protection is not effective in the recording mode in question. One can argue if it's firmware deficiency or not, because if you read for example Mt.Fuji drafts, buffer underrun protection is not defined [or is optional] in DVD-R DAO mode. The exact wording is "If a buffer under-run occurs, the logical unit shall stop writing immediately and the logical unit shall start writing of Lead-out." Where "shall" is defined previously in document as "mandatory requirement." This was discussed once, long time ago... Following option is most likely irrelevant, but such behaviour (INVALID ADDRESS FOR WRITE while LONG WRITE IN PROGRESS) was observed under Solaris 8 with USB connected units... You mentioned that you run Solaris 9, but is it external or IDE unit you're talking about? > Could someone help me out here? You can double-check DMA settings and abstain from using your computer during recording (in order to minimize probability of buffer underrun) or you can download dvd+rw-tools at http://fy.chalmers.se/~appro/linux/DVD+RW/. Despite the name and page heading, it works with all kind of DVD media and runs under several OSes including Solaris. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: plextor px-708uf: cannot get disk type
> I have a Plextor PX-708UF (USB 2.0) on a Red Hat Linux 9 machine. > > cdrecord.prodvd: Input/output error. read disk info: scsi sendcmd: no error > CDB: 51 00 00 00 00 00 00 00 24 00 ^^ I don't know if following holds true for other USB implementations, but Linux USB is very picky about allocation length. Most notably if you ask for M bytes while only M-N bytes are available for transfer, the transport fails. I don't know what is the current status, but it used to "reset bus" in such situation. Check your logs. In either case the structure returned by CDB in question is variable length and is 32/0x20 bytes upon media load, which must be the cause for the trouble. > I can burn the same iso with growisofs. USB deficiency mentioned above was addressed in dvd+rw-tools in August 2002. > Xcdroast otherwise works Note that there're GUI front-ends to growisofs too... > Perhaps this is a firmware issue-- Hardly. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
