What this message means ?
instead
hdc=ide-scsi
what should I put in options of boot kernel ?
please cc me with a quick reply.
for google the archives
thanks,
--
S?rgio M.B.
for the google archives :
I work with Linux more than 10 years and this messages are a great
sheet ! I can't understand a thing of the fuck is going in the mind of
the author.
"Use ide-cd and give dev=/dev/hdX as device"
cracks me up , Can someone translate this to English ?
reading man fstab-sync we get
--add=UDI
Add an entry to the /etc/fstab file by giving a HAL Unique Device
Identifier
no fucking example of the fuck is one UDI !
here is my /var/log/message after a reboot the cdwriter still no
working.
A fucking example could be a great help !
Feb 15 01:41:44 bastov su(pam_unix)[5370]: session opened for user root by sergio(uid=500)
Feb 15 01:55:51 bastov kernel: SCSI subsystem initialized
Feb 15 01:55:51 bastov kernel: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device
Feb 15 01:55:51 bastov kernel: scsi0 : SCSI host adapter emulation for IDE ATAPI devices
Feb 15 01:55:51 bastov kernel: Vendor: HP Model: CD-Writer+ 8200 Rev: 1.0f
Feb 15 01:55:51 bastov kernel: Type: CD-ROM ANSI SCSI revision: 02
Feb 15 01:55:51 bastov hald[4294]: Timed out waiting for hotplug event 701. Rebasing to 705
Feb 15 01:55:51 bastov scsi.agent[5621]: cdrom at /devices/pci0000:00/0000:00:1f.1/ide1/1.0/host0/target0:0:0/0:0:0:0
Feb 15 01:55:51 bastov kernel: ide-scsi: Warning this device driver is only intended for specialist devices.
Feb 15 01:55:51 bastov kernel: ide-scsi: Do not use for cd burning, use /dev/hdX directly instead.
Feb 15 01:55:51 bastov kernel: sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
Feb 15 01:55:51 bastov kernel: ide-scsi: unsup command: dev hdc: flags = REQ_CMD REQ_STARTED
Feb 15 01:55:51 bastov kernel: sector 0, nr/cnr 1/1
Feb 15 01:55:51 bastov kernel: bio c06558c0, biotail c06558c0, buffer c601f000, data 00000000, len 0
Feb 15 01:55:51 bastov kernel: end_request: I/O error, dev hdc, sector 0
Feb 15 01:55:51 bastov kernel: FAT: unable to read boot sector
Feb 15 01:55:51 bastov kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Feb 15 01:55:51 bastov kernel: printing eip:
Feb 15 01:55:51 bastov kernel: c01d5fac
Feb 15 01:55:51 bastov kernel: *pde = 00000000
Feb 15 01:55:51 bastov kernel: Oops: 0000 [#1]
Feb 15 01:55:51 bastov kernel: Modules linked in: sr_mod ide_scsi scsi_mod md5 ipv6 parport_pc lp parport autofs4sunrpc pcmcia yenta_socket pcmcia_core microcode vfat fat dm_mod video button battery ac uhci_hcd hw_random i2c_i801 i2c_core snd_ens1371 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer sndsoundcore snd_page_alloc gameport 3c59x floppy ext3 jbd
Feb 15 01:55:51 bastov kernel: CPU: 0
Feb 15 01:55:51 bastov kernel: EIP: 0060:[<c01d5fac>] Not tainted VLI
Feb 15 01:55:51 bastov kernel: EFLAGS: 00210286 (2.6.10-1.760_FC3)
Feb 15 01:55:51 bastov kernel: EIP is at get_kobj_path_length+0x10/0x25
Feb 15 01:55:51 bastov kernel: eax: 00000000 ebx: 00000001 ecx: ffffffff edx: d3dd5490
Feb 15 01:55:51 bastov kernel: esi: 00000000 edi: 00000000 ebp: d3dd5490 esp: c0e74e44
Feb 15 01:55:51 bastov kernel: ds: 007b es: 007b ss: 0068
Feb 15 01:55:51 bastov kernel: Process mount (pid: 5559, threadinfo=c0e74000 task=ca144e50)
Feb 15 01:55:51 bastov kernel: Stack: 000000d0 00000005 c01d6016 00000005 d2419400 00000000 00000005 d499fec0
Feb 15 01:55:51 bastov kernel: c01d6716 fffffff4 d2419400 d2a7c2c0 d499fec0 d499fec0 c01d67c1 000000d0
Feb 15 01:55:51 bastov kernel: c01689ed d2419440 d2419400 c01670b5 fffffffb fffffffb d2a7c2c0 c01689b0
Feb 15 01:55:51 bastov kernel: Call Trace:
Feb 15 01:55:51 bastov kernel: [<c01d6016>] kobject_get_path+0xe/0x4a
Feb 15 01:55:51 bastov kernel: [<c01d6716>] do_kobject_uevent+0x19/0xba
Feb 15 01:55:51 bastov kernel: [<c01d67c1>] kobject_uevent+0xa/0xc
Feb 15 01:55:51 bastov kernel: [<c01689ed>] kill_block_super+0x16/0x30
Feb 15 01:55:51 bastov kernel: [<c01670b5>] deactivate_super+0xc8/0xdd
Feb 15 01:55:51 bastov kernel: [<c01689b0>] get_sb_bdev+0xf1/0x118
Feb 15 01:55:51 bastov kernel: [<c01c178c>] selinux_sb_copy_data+0x33/0x159
Feb 15 01:55:51 bastov kernel: [<d499e851>] vfat_get_sb+0xe/0x11 [vfat]
Feb 15 01:55:51 bastov kernel: [<d499e80d>] vfat_fill_super+0x0/0x36 [vfat]
Feb 15 01:55:51 bastov kernel: [<c0168b72>] do_kern_mount+0x8a/0x13a
Feb 15 01:55:51 bastov kernel: [<c0180cc4>] do_new_mount+0x61/0x90
Feb 15 01:55:51 bastov kernel: [<c0181677>] do_mount+0x178/0x190
Feb 15 01:55:51 bastov kernel: [<c0143394>] __alloc_pages+0xac/0x28e
Feb 15 01:55:51 bastov kernel: [<c0181a96>] sys_mount+0x6a/0xbd
Feb 15 01:55:51 bastov kernel: [<c0103443>] syscall_call+0x7/0xb
Feb 15 01:55:51 bastov kernel: Code: 75 14 89 d8 e8 9a ff ff ff 85 c0 89 c6 74 07 89 d8 e8 4e c9 fc ff 5b 89 f0 5e c3 57 89 c2 53 bb 01 00 00 00 8b 3a 31 c0 83 c9 ff <f2> ae f7 d1 49 8b 52 24 8d 5c 0b 01 85 d2 75 e9 89 d8 5b 5fc3
Feb 15 01:55:56 bastov fstab-sync[5755]: added mount point /media/cdrecorder for /dev/scd0
On Tue, 2005-02-15 at 00:20 +0000, Sergio Monteiro Basto wrote:
> What this message means ?
>
> instead
> hdc=ide-scsi
> what should I put in options of boot kernel ?
>
>
> please cc me with a quick reply.
> for google the archives
>
> thanks,
--
S?rgio M.B.
Sergio Monteiro Basto wrote:
> for the google archives :
>
> I work with Linux more than 10 years and this messages are a great
> sheet ! I can't understand a thing of the fuck is going in the mind of
> the author.
>
> "Use ide-cd and give dev=/dev/hdX as device"
> cracks me up , Can someone translate this to English ?
I'll try.
It means: don't use the ide-scsi driver. Support for it is
lagging (not well-maintained) because it's really not needed for
burning CDs. Just use the ide-cd driver (module) and
specify the CD burner device as /dev/hdX.
Example with cdrecord:
deprecated:
cdrecord -dev=1,0,0 -data backup.iso
modern :)
cdrecord -dev=/dev/hdc -data backup.iso
Do you know how to _not_ use ide-scsi? Don't load the module
if you have it built as a module, or don't build it into the
kernel boot image. Mostly don't try to open /dev/sdX, just use
/dev/hdX instead.
Hope you feel better soon.
> reading man fstab-sync we get
>
> --add=UDI
> Add an entry to the /etc/fstab file by giving a HAL Unique Device
> Identifier
>
> no fucking example of the fuck is one UDI !
>
> here is my /var/log/message after a reboot the cdwriter still no
> working.
> A fucking example could be a great help !
>
> Feb 15 01:41:44 bastov su(pam_unix)[5370]: session opened for user root by sergio(uid=500)
> Feb 15 01:55:51 bastov kernel: SCSI subsystem initialized
> Feb 15 01:55:51 bastov kernel: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device
> Feb 15 01:55:51 bastov kernel: scsi0 : SCSI host adapter emulation for IDE ATAPI devices
> Feb 15 01:55:51 bastov kernel: Vendor: HP Model: CD-Writer+ 8200 Rev: 1.0f
> Feb 15 01:55:51 bastov kernel: Type: CD-ROM ANSI SCSI revision: 02
> Feb 15 01:55:51 bastov hald[4294]: Timed out waiting for hotplug event 701. Rebasing to 705
> Feb 15 01:55:51 bastov scsi.agent[5621]: cdrom at /devices/pci0000:00/0000:00:1f.1/ide1/1.0/host0/target0:0:0/0:0:0:0
> Feb 15 01:55:51 bastov kernel: ide-scsi: Warning this device driver is only intended for specialist devices.
> Feb 15 01:55:51 bastov kernel: ide-scsi: Do not use for cd burning, use /dev/hdX directly instead.
> Feb 15 01:55:51 bastov kernel: sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
> Feb 15 01:55:51 bastov kernel: ide-scsi: unsup command: dev hdc: flags = REQ_CMD REQ_STARTED
> Feb 15 01:55:51 bastov kernel: sector 0, nr/cnr 1/1
> Feb 15 01:55:51 bastov kernel: bio c06558c0, biotail c06558c0, buffer c601f000, data 00000000, len 0
> Feb 15 01:55:51 bastov kernel: end_request: I/O error, dev hdc, sector 0
> Feb 15 01:55:51 bastov kernel: FAT: unable to read boot sector
> Feb 15 01:55:51 bastov kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
> Feb 15 01:55:51 bastov kernel: printing eip:
> Feb 15 01:55:51 bastov kernel: c01d5fac
> Feb 15 01:55:51 bastov kernel: *pde = 00000000
> Feb 15 01:55:51 bastov kernel: Oops: 0000 [#1]
> Feb 15 01:55:51 bastov kernel: Modules linked in: sr_mod ide_scsi scsi_mod md5 ipv6 parport_pc lp parport autofs4sunrpc pcmcia yenta_socket pcmcia_core microcode vfat fat dm_mod video button battery ac uhci_hcd hw_random i2c_i801 i2c_core snd_ens1371 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer sndsoundcore snd_page_alloc gameport 3c59x floppy ext3 jbd
> Feb 15 01:55:51 bastov kernel: CPU: 0
> Feb 15 01:55:51 bastov kernel: EIP: 0060:[<c01d5fac>] Not tainted VLI
> Feb 15 01:55:51 bastov kernel: EFLAGS: 00210286 (2.6.10-1.760_FC3)
> Feb 15 01:55:51 bastov kernel: EIP is at get_kobj_path_length+0x10/0x25
> Feb 15 01:55:51 bastov kernel: eax: 00000000 ebx: 00000001 ecx: ffffffff edx: d3dd5490
> Feb 15 01:55:51 bastov kernel: esi: 00000000 edi: 00000000 ebp: d3dd5490 esp: c0e74e44
> Feb 15 01:55:51 bastov kernel: ds: 007b es: 007b ss: 0068
> Feb 15 01:55:51 bastov kernel: Process mount (pid: 5559, threadinfo=c0e74000 task=ca144e50)
> Feb 15 01:55:51 bastov kernel: Stack: 000000d0 00000005 c01d6016 00000005 d2419400 00000000 00000005 d499fec0
> Feb 15 01:55:51 bastov kernel: c01d6716 fffffff4 d2419400 d2a7c2c0 d499fec0 d499fec0 c01d67c1 000000d0
> Feb 15 01:55:51 bastov kernel: c01689ed d2419440 d2419400 c01670b5 fffffffb fffffffb d2a7c2c0 c01689b0
> Feb 15 01:55:51 bastov kernel: Call Trace:
> Feb 15 01:55:51 bastov kernel: [<c01d6016>] kobject_get_path+0xe/0x4a
> Feb 15 01:55:51 bastov kernel: [<c01d6716>] do_kobject_uevent+0x19/0xba
> Feb 15 01:55:51 bastov kernel: [<c01d67c1>] kobject_uevent+0xa/0xc
> Feb 15 01:55:51 bastov kernel: [<c01689ed>] kill_block_super+0x16/0x30
> Feb 15 01:55:51 bastov kernel: [<c01670b5>] deactivate_super+0xc8/0xdd
> Feb 15 01:55:51 bastov kernel: [<c01689b0>] get_sb_bdev+0xf1/0x118
> Feb 15 01:55:51 bastov kernel: [<c01c178c>] selinux_sb_copy_data+0x33/0x159
> Feb 15 01:55:51 bastov kernel: [<d499e851>] vfat_get_sb+0xe/0x11 [vfat]
> Feb 15 01:55:51 bastov kernel: [<d499e80d>] vfat_fill_super+0x0/0x36 [vfat]
> Feb 15 01:55:51 bastov kernel: [<c0168b72>] do_kern_mount+0x8a/0x13a
> Feb 15 01:55:51 bastov kernel: [<c0180cc4>] do_new_mount+0x61/0x90
> Feb 15 01:55:51 bastov kernel: [<c0181677>] do_mount+0x178/0x190
> Feb 15 01:55:51 bastov kernel: [<c0143394>] __alloc_pages+0xac/0x28e
> Feb 15 01:55:51 bastov kernel: [<c0181a96>] sys_mount+0x6a/0xbd
> Feb 15 01:55:51 bastov kernel: [<c0103443>] syscall_call+0x7/0xb
> Feb 15 01:55:51 bastov kernel: Code: 75 14 89 d8 e8 9a ff ff ff 85 c0 89 c6 74 07 89 d8 e8 4e c9 fc ff 5b 89 f0 5e c3 57 89 c2 53 bb 01 00 00 00 8b 3a 31 c0 83 c9 ff <f2> ae f7 d1 49 8b 52 24 8d 5c 0b 01 85 d2 75 e9 89 d8 5b 5fc3
> Feb 15 01:55:56 bastov fstab-sync[5755]: added mount point /media/cdrecorder for /dev/scd0
>
>
>
>
>
>
> On Tue, 2005-02-15 at 00:20 +0000, Sergio Monteiro Basto wrote:
>
>>What this message means ?
>>
>>instead
>>hdc=ide-scsi
>>what should I put in options of boot kernel ?
>>
>>
>>please cc me with a quick reply.
>>for google the archives
--
~Randy
Hi, don't feel much better but thanks a lot!
in conclusion ?
1- hdc=ide-scsi, now should be hdc=ide-cd for general cd-writer, because
cdrecorder don't need scsi emulation anymore.
2- as hdc already is ide-cd by default, therefore is not necessary to
write it and what should be made is erase the line hdc=ide-scsi.
Correct ?
On Mon, 2005-02-14 at 18:25 -0800, Randy.Dunlap wrote:
> Sergio Monteiro Basto wrote:
> > "Use ide-cd and give dev=/dev/hdX as device"
> > cracks me up , Can someone translate this to English ?
>
> I'll try.
> It means: don't use the ide-scsi driver. Support for it is
> lagging (not well-maintained) because it's really not needed for
> burning CDs. Just use the ide-cd driver (module) and
> specify the CD burner device as /dev/hdX.
>
> Example with cdrecord:
> deprecated:
> cdrecord -dev=1,0,0 -data backup.iso
> modern :)
> cdrecord -dev=/dev/hdc -data backup.iso
>
> Do you know how to _not_ use ide-scsi? Don't load the module
> if you have it built as a module, or don't build it into the
> kernel boot image. Mostly don't try to open /dev/sdX, just use
> /dev/hdX instead.
>
> Hope you feel better soon.
>
--
S?rgio M.B.
Sergio Monteiro Basto wrote:
> Hi, don't feel much better but thanks a lot!
>
> in conclusion ?
> 1- hdc=ide-scsi, now should be hdc=ide-cd for general cd-writer, because
> cdrecorder don't need scsi emulation anymore.
At least partially correct: don't use "hdc=ide-scsi".
However, I don't use "hdc=ide-cd" and I can burn CDs,
so that's not needed AFAIK.
> 2- as hdc already is ide-cd by default, therefore is not necessary to
> write it and what should be made is erase the line hdc=ide-scsi.
>
> Correct ?
Ah, yes, we seem to agree on that.
HTH.
~Randy
> On Mon, 2005-02-14 at 18:25 -0800, Randy.Dunlap wrote:
>
>>Sergio Monteiro Basto wrote:
>>
>>>"Use ide-cd and give dev=/dev/hdX as device"
>>>cracks me up , Can someone translate this to English ?
>>
>>I'll try.
>>It means: don't use the ide-scsi driver. Support for it is
>>lagging (not well-maintained) because it's really not needed for
>>burning CDs. Just use the ide-cd driver (module) and
>>specify the CD burner device as /dev/hdX.
>>
>>Example with cdrecord:
>>deprecated:
>>cdrecord -dev=1,0,0 -data backup.iso
>>modern :)
>>cdrecord -dev=/dev/hdc -data backup.iso
>>
>>Do you know how to _not_ use ide-scsi? Don't load the module
>>if you have it built as a module, or don't build it into the
>>kernel boot image. Mostly don't try to open /dev/sdX, just use
>>/dev/hdX instead.
>>
>>Hope you feel better soon.
On Maw, 2005-02-15 at 02:25, Randy.Dunlap wrote:
> It means: don't use the ide-scsi driver. Support for it is
> lagging (not well-maintained) because it's really not needed for
> burning CDs. Just use the ide-cd driver (module) and
> specify the CD burner device as /dev/hdX.
This information is unfortunately *WRONG*. The base 2.6 ide-cd driver is
vastly inferior to ide-scsi. The ide-scsi layer knows about proper error
reporting, end of media and other things that ide-cd does not.
The -ac ide-cd knows some of the stuff that ide-cd needs to and works
with various drive/disk combinations the base code doesn't but ide-scsi
still handles CD's better.
Alan
Alan Cox wrote:
> On Maw, 2005-02-15 at 02:25, Randy.Dunlap wrote:
>
>>It means: don't use the ide-scsi driver. Support for it is
>>lagging (not well-maintained) because it's really not needed for
>>burning CDs. Just use the ide-cd driver (module) and
>>specify the CD burner device as /dev/hdX.
>
>
> This information is unfortunately *WRONG*. The base 2.6 ide-cd driver is
> vastly inferior to ide-scsi. The ide-scsi layer knows about proper error
> reporting, end of media and other things that ide-cd does not.
>
> The -ac ide-cd knows some of the stuff that ide-cd needs to and works
> with various drive/disk combinations the base code doesn't but ide-scsi
> still handles CD's better.
>
> Alan
Thanks for the corrections, Alan.
--
~Randy
Hi Alan,
On Feb 15 at 05:02:35, Alan Cox wrote:
> > burning CDs. Just use the ide-cd driver (module) and
> > specify the CD burner device as /dev/hdX.
>
> This information is unfortunately *WRONG*. The base 2.6 ide-cd driver is
> vastly inferior to ide-scsi. The ide-scsi layer knows about proper error
> reporting, end of media and other things that ide-cd does not.
>
> The -ac ide-cd knows some of the stuff that ide-cd needs to and works
> with various drive/disk combinations the base code doesn't but ide-scsi
> still handles CD's better.
Is going to be merged soon to the mainline 2.6 kernel? I guess this
bad error handling from ide-cd has something to do with recent messages
about kernel hanging with bad dvd media.
--
David Gómez Jabber ID: [email protected]
On Tue, Feb 15, 2005 at 05:02:35PM +0000, Alan Cox wrote:
> On Maw, 2005-02-15 at 02:25, Randy.Dunlap wrote:
> > It means: don't use the ide-scsi driver. Support for it is
> > lagging (not well-maintained) because it's really not needed for
> > burning CDs. Just use the ide-cd driver (module) and
> > specify the CD burner device as /dev/hdX.
>
> This information is unfortunately *WRONG*. The base 2.6 ide-cd driver is
> vastly inferior to ide-scsi. The ide-scsi layer knows about proper error
> reporting, end of media and other things that ide-cd does not.
>
> The -ac ide-cd knows some of the stuff that ide-cd needs to and works
> with various drive/disk combinations the base code doesn't but ide-scsi
> still handles CD's better.
>
> Alan
I can confirm that. Creating a correct iso image from a CD is a
major pain w/o ide-scsi. Depending on what one has done before the iso
image is missing some data at the end most of the time.
(paired with lots of kernel error messages)
Testing was done here using Joerg Schilling's sdd:
sdd ivsize=`isosize /dev/cdxxx` if=/dev/cdxxx of=/dev/null \
bs=<several block sizes from 2048 up tried,does not matter>
and most of the time it results in bad iso images....
Gretings
Karl
--
Karl Kiniger mailto:[email protected]
GE Medical Systems Kretztechnik GmbH & Co OHG
Tiefenbach 15 Tel: (++43) 7682-3800-710
A-4871 Zipf Austria Fax: (++43) 7682-3800-47
On Tue, 2005-02-15 at 14:48, Kiniger, Karl (GE Healthcare) wrote:
> I can confirm that. Creating a correct iso image from a CD is a
> major pain w/o ide-scsi. Depending on what one has done before the iso
> image is missing some data at the end most of the time.
> (paired with lots of kernel error messages)
>
> Testing was done here using Joerg Schilling's sdd:
>
> sdd ivsize=`isosize /dev/cdxxx` if=/dev/cdxxx of=/dev/null \
> bs=<several block sizes from 2048 up tried,does not matter>
>
> and most of the time it results in bad iso images....
Karl,
what about catting out that device? I.E.,
'cat /dev/cdxxx > some.iso'
*instead* of using 'dd' (or variants) against it? I've always had good
results using 'cat' and CDs, avoiding 'dd' and CDs whenever the
opportunity presents itself.
regards,
-fd
On Tue, Feb 15, 2005 at 08:48:13PM +0100, Kiniger, Karl (GE Healthcare) wrote:
> I can confirm that. Creating a correct iso image from a CD is a
> major pain w/o ide-scsi. Depending on what one has done before the iso
> image is missing some data at the end most of the time.
> (paired with lots of kernel error messages)
>
> Testing was done here using Joerg Schilling's sdd:
>
> sdd ivsize=`isosize /dev/cdxxx` if=/dev/cdxxx of=/dev/null \
> bs=<several block sizes from 2048 up tried,does not matter>
>
> and most of the time it results in bad iso images....
I have only ever used his readcd program for doing such things. It has
been so long I can't even remember if it was using ide-scsi or ide-cd.
For burning I use ide-cd with cdrecord and growisofs, and so far it has
worked great. Flashing firmware on the plextor still requires ide-scsi
though.
Lennart Sorensen
Well the problem for the common users is the haldeamon doesn't recognize
automatically /dev/scd0 and /etc/fstab don't have any entry about it.
So with hdc=scsi, how I read cds on hdc ?
thanks,
Note: I am using last updates of FC3, after upgrade from FC1.
On Tue, 2005-02-15 at 17:02 +0000, Alan Cox wrote:
> On Maw, 2005-02-15 at 02:25, Randy.Dunlap wrote:
> > It means: don't use the ide-scsi driver. Support for it is
> > lagging (not well-maintained) because it's really not needed for
> > burning CDs. Just use the ide-cd driver (module) and
> > specify the CD burner device as /dev/hdX.
>
> This information is unfortunately *WRONG*. The base 2.6 ide-cd driver is
> vastly inferior to ide-scsi. The ide-scsi layer knows about proper error
> reporting, end of media and other things that ide-cd does not.
>
> The -ac ide-cd knows some of the stuff that ide-cd needs to and works
> with various drive/disk combinations the base code doesn't but ide-scsi
> still handles CD's better.
>
> Alan
>
--
S?rgio M.B.
On Tue, 15 Feb 2005 20:48:13 +0100, "Kiniger, Karl (GE Healthcare)" said:
> I can confirm that. Creating a correct iso image from a CD is a
> major pain w/o ide-scsi. Depending on what one has done before the iso
> image is missing some data at the end most of the time.
> (paired with lots of kernel error messages)
>
> Testing was done here using Joerg Schilling's sdd:
>
> sdd ivsize=`isosize /dev/cdxxx` if=/dev/cdxxx of=/dev/null \
> bs=<several block sizes from 2048 up tried,does not matter>
>
> and most of the time it results in bad iso images....
Have you tested the ISO on some *OTHER* hardware? The impression I got
was that the cd was *burned* right by ide-cd, but when *read back*, it
bollixed things up at the end of the CD.....
On Maw, 2005-02-15 at 17:48, David Gómez wrote:
> Is going to be merged soon to the mainline 2.6 kernel? I guess this
> bad error handling from ide-cd has something to do with recent messages
> about kernel hanging with bad dvd media.
Up to the maintainer. I've been very busy on thesis stuff but I'll try
and split it out for 2.6.12pre if Bartlomiej wants the changes.
As to the DVD media hang - I think that is unrelated. The ide-cd fixes
deal with end of media error handling primarily and better reporting of
sense data. That affects multisession discs, readahead and some other
oddments rather than any hang cases
Alan
On Tue, Feb 15, 2005 at 03:03:02PM -0500, kernel wrote:
> On Tue, 2005-02-15 at 14:48, Kiniger, Karl (GE Healthcare) wrote:
> > I can confirm that. Creating a correct iso image from a CD is a
> > major pain w/o ide-scsi. Depending on what one has done before the iso
> > image is missing some data at the end most of the time.
> > (paired with lots of kernel error messages)
> >
> > Testing was done here using Joerg Schilling's sdd:
> >
> > sdd ivsize=`isosize /dev/cdxxx` if=/dev/cdxxx of=/dev/null \
> > bs=<several block sizes from 2048 up tried,does not matter>
> >
> > and most of the time it results in bad iso images....
>
> Karl,
>
> what about catting out that device? I.E.,
>
> 'cat /dev/cdxxx > some.iso'
>
> *instead* of using 'dd' (or variants) against it? I've always had good
> results using 'cat' and CDs, avoiding 'dd' and CDs whenever the
> opportunity presents itself.
I dont think this is relevant. cat will probably use stdio which will
do blocking similar to dd (perhaps 4 kB).
Interestingly reading the files off the mounted CD works fine.
Karl
>
> regards,
>
>
> -fd
>
>
--
Karl Kiniger mailto:[email protected]
GE Medical Systems Kretztechnik GmbH & Co OHG
Tiefenbach 15 Tel: (++43) 7682-3800-710
A-4871 Zipf Austria Fax: (++43) 7682-3800-47
On Tue, Feb 15, 2005 at 03:15:14PM -0500, [email protected] wrote:
> On Tue, Feb 15, 2005 at 08:48:13PM +0100, Kiniger, Karl (GE Healthcare) wrote:
> > I can confirm that. Creating a correct iso image from a CD is a
> > major pain w/o ide-scsi. Depending on what one has done before the iso
> > image is missing some data at the end most of the time.
> > (paired with lots of kernel error messages)
> >
> > Testing was done here using Joerg Schilling's sdd:
> >
> > sdd ivsize=`isosize /dev/cdxxx` if=/dev/cdxxx of=/dev/null \
> > bs=<several block sizes from 2048 up tried,does not matter>
> >
> > and most of the time it results in bad iso images....
>
> I have only ever used his readcd program for doing such things. It has
> been so long I can't even remember if it was using ide-scsi or ide-cd.
>
> For burning I use ide-cd with cdrecord and growisofs, and so far it has
> worked great. Flashing firmware on the plextor still requires ide-scsi
> though.
Burning has not been the problem here, just reading. At least
`isosize /dev/cdxxx` bytes have to be readable and I am always
burning with additional pad sectors at the end and even 32kb
were not always enough to get all files contents......
Karl
>
> Lennart Sorensen
--
Karl Kiniger mailto:[email protected]
GE Medical Systems Kretztechnik GmbH & Co OHG
Tiefenbach 15 Tel: (++43) 7682-3800-710
A-4871 Zipf Austria Fax: (++43) 7682-3800-47
On Tue, 2005-02-15 at 18:16, Kiniger wrote:
> >
> > what about catting out that device? I.E.,
> >
> > 'cat /dev/cdxxx > some.iso'
> >
> > *instead* of using 'dd' (or variants) against it? I've always had good
> > results using 'cat' and CDs, avoiding 'dd' and CDs whenever the
> > opportunity presents itself.
>
> I dont think this is relevant. cat will probably use stdio which will
> do blocking similar to dd (perhaps 4 kB).
>
But it *is* a quick try (rule out), though. Take 5 minutes if you can
and try it. Easy to rule. If it fails, it fails. But *if* not, you
don't waste any more time. I only mention it because it's worked for me
in the past where dd (and variants) has (have) not.
-fd
On Tue, Feb 15, 2005 at 10:25:28PM +0100, [email protected] wrote:
>
> On Tue, 15 Feb 2005 20:48:13 +0100, "Kiniger, Karl (GE Healthcare)" said:
>
> > I can confirm that. Creating a correct iso image from a CD is a
> > major pain w/o ide-scsi. Depending on what one has done before the iso
> > image is missing some data at the end most of the time.
> > (paired with lots of kernel error messages)
> >
> > Testing was done here using Joerg Schilling's sdd:
> >
> > sdd ivsize=`isosize /dev/cdxxx` if=/dev/cdxxx of=/dev/null \
> > bs=<several block sizes from 2048 up tried,does not matter>
> >
> > and most of the time it results in bad iso images....
>
> Have you tested the ISO on some *OTHER* hardware? The impression I got
> was that the cd was *burned* right by ide-cd, but when *read back*, it
> bollixed things up at the end of the CD.....
Using ide-scsi is enough to get all the data till the real end of the CD.
Just to be sure I also generated an image with Nero and it was fine as well.
(all using the same drive(s)).
Karl
--
Karl Kiniger mailto:[email protected]
GE Medical Systems Kretztechnik GmbH & Co OHG
Tiefenbach 15 Tel: (++43) 7682-3800-710
A-4871 Zipf Austria Fax: (++43) 7682-3800-47
On Wed, 16 Feb 2005 10:42:21 +0100, "Kiniger, Karl (GE Healthcare)" said:
> > Have you tested the ISO on some *OTHER* hardware? The impression I got
> > was that the cd was *burned* right by ide-cd, but when *read back*, it
> > bollixed things up at the end of the CD.....
>
> Using ide-scsi is enough to get all the data till the real end of the CD.
OK, so the problem is that ide-cd is able to *burn* the CD just fine, but it
suffers lossage when ide-cd tries to read it back...
Alan - are the sense-byte patches for ide-cd in a shape to push either upstream
or to -mm?
On Mer, 2005-02-16 at 17:36, [email protected] wrote:
> OK, so the problem is that ide-cd is able to *burn* the CD just fine, but it
> suffers lossage when ide-cd tries to read it back...
>
> Alan - are the sense-byte patches for ide-cd in a shape to push either upstream
> or to -mm?
I think so. They don't solve all reported problems but they do help with
some drives we found problematic in Red Hat internal testing.
with hdc=scsi haldeamon doesn't recognize cdwriter.
but with hdc=ide-scsi (was the original from kernel 2.4) haldaamon
reconize my cdwriter !
So this message of this subject just make me wast my time and lose my
patience. ( because I forgot to enable haldaemon before to try
understand the message )
Still don't understand if I should or not change to ide-cd on my FC3, if
not please remove the message, if yes rewrite it please .
thanks for your precious time.
On Tue, 2005-02-15 at 20:36 +0000, Sergio Monteiro Basto wrote:
> Well the problem for the common users is the haldeamon doesn't recognize
> automatically /dev/scd0 and /etc/fstab don't have any entry about it.
>
> So with hdc=scsi, how I read cds on hdc ?
>
> thanks,
>
> Note: I am using last updates of FC3, after upgrade from FC1.
>
>
> On Tue, 2005-02-15 at 17:02 +0000, Alan Cox wrote:
> > On Maw, 2005-02-15 at 02:25, Randy.Dunlap wrote:
> > > It means: don't use the ide-scsi driver. Support for it is
> > > lagging (not well-maintained) because it's really not needed for
> > > burning CDs. Just use the ide-cd driver (module) and
> > > specify the CD burner device as /dev/hdX.
> >
> > This information is unfortunately *WRONG*. The base 2.6 ide-cd driver is
> > vastly inferior to ide-scsi. The ide-scsi layer knows about proper error
> > reporting, end of media and other things that ide-cd does not.
> >
> > The -ac ide-cd knows some of the stuff that ide-cd needs to and works
> > with various drive/disk combinations the base code doesn't but ide-scsi
> > still handles CD's better.
> >
> > Alan
> >
--
S?rgio M.B.
[email protected] wrote:
> On Wed, 16 Feb 2005 10:42:21 +0100, "Kiniger, Karl (GE Healthcare)" said:
>
>
>>> Have you tested the ISO on some *OTHER* hardware? The impression I got
>>> was that the cd was *burned* right by ide-cd, but when *read back*, it
>>> bollixed things up at the end of the CD.....
>>
>>Using ide-scsi is enough to get all the data till the real end of the CD.
>
>
> OK, so the problem is that ide-cd is able to *burn* the CD just fine, but it
> suffers lossage when ide-cd tries to read it back...
>
> Alan - are the sense-byte patches for ide-cd in a shape to push either upstream
> or to -mm?
The last time I looked at this, the issue was that the user software did
a large read and the ide-cd didn't properly return a small data block
with no error, but rather returned an error with no data. If you get the
size of the ISO image, you can read that with any program which doesn't
try to read MORE than that.
I don't consider this correct behaviour, but at least I know how to get
by it for iso-9660 CDs. For other formats which don't allow
determination of data set size except by the contents of the data, this
works poorly.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
kernel wrote:
> On Tue, 2005-02-15 at 14:48, Kiniger, Karl (GE Healthcare) wrote:
>
>>I can confirm that. Creating a correct iso image from a CD is a
>>major pain w/o ide-scsi. Depending on what one has done before the iso
>>image is missing some data at the end most of the time.
>>(paired with lots of kernel error messages)
>>
>>Testing was done here using Joerg Schilling's sdd:
>>
>>sdd ivsize=`isosize /dev/cdxxx` if=/dev/cdxxx of=/dev/null \
>> bs=<several block sizes from 2048 up tried,does not matter>
>>
>>and most of the time it results in bad iso images....
Use isoinfo to get the size in 2k sectors, then
dd if=/dev/cdrom bs=2k count={size} of=my_file
to pull the image. As noted elsewhere this doesn't work if the image
isn't iso-9660.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Sergio Monteiro Basto wrote:
> with hdc=scsi haldeamon doesn't recognize cdwriter.
> but with hdc=ide-scsi (was the original from kernel 2.4) haldaamon
> reconize my cdwriter !
>
> So this message of this subject just make me wast my time and lose my
> patience. ( because I forgot to enable haldaemon before to try
> understand the message )
> Still don't understand if I should or not change to ide-cd on my FC3, if
> not please remove the message, if yes rewrite it please .
Since ide-scsi seems needed to do firmware upgrades and multi-session
CDs as user, like Mark Twain I believe the reports of death are greatly
exaggerated.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Thu, Feb 17, 2005 at 05:58:05PM -0500, Bill Davidsen wrote:
> [email protected] wrote:
> >On Wed, 16 Feb 2005 10:42:21 +0100, "Kiniger, Karl (GE Healthcare)" said:
> >
> >
> >>> Have you tested the ISO on some *OTHER* hardware? The impression I got
> >>> was that the cd was *burned* right by ide-cd, but when *read back*, it
> >>> bollixed things up at the end of the CD.....
> >>
> >>Using ide-scsi is enough to get all the data till the real end of the CD.
> >
> >
> >OK, so the problem is that ide-cd is able to *burn* the CD just fine, but
> >it
> >suffers lossage when ide-cd tries to read it back...
> >
> >Alan - are the sense-byte patches for ide-cd in a shape to push either
> >upstream
> >or to -mm?
>
> The last time I looked at this, the issue was that the user software did
> a large read and the ide-cd didn't properly return a small data block
> with no error, but rather returned an error with no data. If you get the
> size of the ISO image, you can read that with any program which doesn't
> try to read MORE than that.
Not entirely true (at least for me). I actually tried to read the
last iso9660 data sector with a small C program (reading 2 kb) and
it failed to read the sector. Using ide-scsi I was able to read it.....
sdd (from Joerg Schilling) should not try to read more than ivsize
bytes (InputVolumeSize) if that argument is given - I did not
verify with strace though.
Karl
--
Karl Kiniger mailto:[email protected]
GE Medical Systems Kretztechnik GmbH & Co OHG
Tiefenbach 15 Tel: (++43) 7682-3800-710
A-4871 Zipf Austria Fax: (++43) 7682-3800-47
Kiniger, Karl (GE Healthcare) wrote:
> On Thu, Feb 17, 2005 at 05:58:05PM -0500, Bill Davidsen wrote:
>
>>[email protected] wrote:
>>
>>>On Wed, 16 Feb 2005 10:42:21 +0100, "Kiniger, Karl (GE Healthcare)" said:
>>>
>>>
>>>
>>>>> Have you tested the ISO on some *OTHER* hardware? The impression I got
>>>>> was that the cd was *burned* right by ide-cd, but when *read back*, it
>>>>> bollixed things up at the end of the CD.....
>>>>
>>>>Using ide-scsi is enough to get all the data till the real end of the CD.
>>>
>>>
>>>OK, so the problem is that ide-cd is able to *burn* the CD just fine, but
>>>it
>>>suffers lossage when ide-cd tries to read it back...
>>>
>>>Alan - are the sense-byte patches for ide-cd in a shape to push either
>>>upstream
>>>or to -mm?
>>
>>The last time I looked at this, the issue was that the user software did
>>a large read and the ide-cd didn't properly return a small data block
>>with no error, but rather returned an error with no data. If you get the
>>size of the ISO image, you can read that with any program which doesn't
>>try to read MORE than that.
>
>
> Not entirely true (at least for me). I actually tried to read the
> last iso9660 data sector with a small C program (reading 2 kb) and
> it failed to read the sector. Using ide-scsi I was able to read it.....
>
> sdd (from Joerg Schilling) should not try to read more than ivsize
> bytes (InputVolumeSize) if that argument is given - I did not
> verify with strace though.
I'll try to build a truth table for this, I'm now working with some
non-iso data sets, so I'm a bit more interested. I would expect read()
to only try to read one sector, so I'll just do a quick and dirty to get
the size from the command line, seek and read.
I haven't had a problem using dd to date, as long as I know how long the
data set was, but I'll try to have results tonight.
Thanks for your additional info on this.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
I regularly burn tarballs to a CD without useing a filesystem and as long
as I use the -pad option when burning I've had no problems reading them
(the -pad was nessasary even when I was useing ide-scsi)
David Lang
On Fri, 18 Feb
2005, Bill Davidsen wrote:
> Date: Fri, 18 Feb 2005 15:23:44 -0500
> From: Bill Davidsen <[email protected]>
> To: [email protected]
> Newsgroups: mail.linux-kernel
> Subject: Re: ide-scsi is deprecated for cd burning! Use ide-cd and give
> dev=/dev/hdXas device
>
> Kiniger, Karl (GE Healthcare) wrote:
>> On Thu, Feb 17, 2005 at 05:58:05PM -0500, Bill Davidsen wrote:
>>
>>> [email protected] wrote:
>>>
>>>> On Wed, 16 Feb 2005 10:42:21 +0100, "Kiniger, Karl (GE Healthcare)"
>>>> said:
>>>>
>>>>
>>>>
>>>>>> Have you tested the ISO on some *OTHER* hardware? The impression
>>>>>> I got
>>>>>> was that the cd was *burned* right by ide-cd, but when *read
>>>>>> back*, it
>>>>>> bollixed things up at the end of the CD.....
>>>>>
>>>>> Using ide-scsi is enough to get all the data till the real end of
>>>>> the CD.
>>>>
>>>>
>>>> OK, so the problem is that ide-cd is able to *burn* the CD just fine,
>>>> but it
>>>> suffers lossage when ide-cd tries to read it back...
>>>>
>>>> Alan - are the sense-byte patches for ide-cd in a shape to push either
>>>> upstream
>>>> or to -mm?
>>>
>>> The last time I looked at this, the issue was that the user software did
>>> a large read and the ide-cd didn't properly return a small data block
>>> with no error, but rather returned an error with no data. If you get the
>>> size of the ISO image, you can read that with any program which doesn't
>>> try to read MORE than that.
>>
>>
>> Not entirely true (at least for me). I actually tried to read the last
>> iso9660 data sector with a small C program (reading 2 kb) and
>> it failed to read the sector. Using ide-scsi I was able to read it.....
>>
>> sdd (from Joerg Schilling) should not try to read more than ivsize
>> bytes (InputVolumeSize) if that argument is given - I did not
>> verify with strace though.
>
> I'll try to build a truth table for this, I'm now working with some non-iso
> data sets, so I'm a bit more interested. I would expect read() to only try to
> read one sector, so I'll just do a quick and dirty to get the size from the
> command line, seek and read.
>
> I haven't had a problem using dd to date, as long as I know how long the data
> set was, but I'll try to have results tonight.
>
> Thanks for your additional info on this.
>
> --
> -bill davidsen ([email protected])
> "The secret to procrastination is to put things off until the
> last possible moment - but no longer" -me
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
On Fri, 18 Feb 2005 15:23:44 EST, Bill Davidsen said:
> I'll try to build a truth table for this, I'm now working with some
> non-iso data sets, so I'm a bit more interested. I would expect read()
> to only try to read one sector, so I'll just do a quick and dirty to get
> the size from the command line, seek and read.
>
> I haven't had a problem using dd to date, as long as I know how long the
> data set was, but I'll try to have results tonight.
The problem is that often you don't know exactly how long the data set is
(think "backup burned to CD/RW") - there's a *lot* of code that does stuff
like
while (actual=read(fd,buffer,65536) > 0) {
...
}
with the realistic expectation that the last read might return less than 64k,
in which case 'actual' will tell us how much was read. Instead, we just get
an error on the read.
Note that 'dd' does this - that's why you get messages like '12343+1 blocks read'.
We *really* want to get to a point where 'dd' will work *without* having to
tell it a 'bs=' and 'count=' to get the size right....
Well , In other computer with one fresh Core 3 installation, try set a
prodvd.key on xcdroast, Fedora Core 3, doesn't had set hdc=ide-scsi , so
I think that the recorder of dvds has worked in mode hdc=ide-cd, and
stopped to function and to read any type of cd or dvd.
So is it possible that ide-cd had, damage my dvdrecorder ?
Well dvdrecorder doesn't had work very well all the time, even in
Windows, and stops after one firmware upgrade but I hadn't much luck.
Happily it is in the warranty.
--------------------------------------------------------------------------
On Thu, 2005-02-17 at 02:27 +0000, Sergio Monteiro Basto wrote:
with hdc=scsi haldeamon doesn't recognize cdwriter.
but with hdc=ide-scsi (was the original from kernel 2.4) haldaamon
reconize my cdwriter !
So this message of this subject just make me wast my time and lose my
patience. ( because I forgot to enable haldaemon before to try
understand the message )
Still don't understand if I should or not change to ide-cd on my FC3, if
not please remove the message, if yes rewrite it please .
thanks for your precious time.
On Tue, 2005-02-15 at 20:36 +0000, Sergio Monteiro Basto wrote:
> Well the problem for the common users is the haldeamon doesn't recognize
> automatically /dev/scd0 and /etc/fstab don't have any entry about it.
>
> So with hdc=scsi, how I read cds on hdc ?
>
> thanks,
>
> Note: I am using last updates of FC3, after upgrade from FC1.
>
>
> On Tue, 2005-02-15 at 17:02 +0000, Alan Cox wrote:
> > On Maw, 2005-02-15 at 02:25, Randy.Dunlap wrote:
> > > It means: don't use the ide-scsi driver. Support for it is
> > > lagging (not well-maintained) because it's really not needed for
> > > burning CDs. Just use the ide-cd driver (module) and
> > > specify the CD burner device as /dev/hdX.
> >
> > This information is unfortunately *WRONG*. The base 2.6 ide-cd driver is
> > vastly inferior to ide-scsi. The ide-scsi layer knows about proper error
> > reporting, end of media and other things that ide-cd does not.
> >
> > The -ac ide-cd knows some of the stuff that ide-cd needs to and works
> > with various drive/disk combinations the base code doesn't but ide-scsi
> > still handles CD's better.
> >
> > Alan
> >
--
S?rgio M.B.
On Gwe, 2005-02-18 at 10:31, Kiniger, Karl (GE Healthcare) wrote:
> Not entirely true (at least for me). I actually tried to read the
> last iso9660 data sector with a small C program (reading 2 kb) and
> it failed to read the sector. Using ide-scsi I was able to read it.....
Thats the bug that should now be fixed by the ide changes I did so that
ide-cd has the knowledge ide-scsi has for partial completions of I/O
Hi,
On Mon, 21 Feb 2005 15:00:28 +0000, Alan Cox <[email protected]> wrote:
> On Gwe, 2005-02-18 at 10:31, Kiniger, Karl (GE Healthcare) wrote:
> > Not entirely true (at least for me). I actually tried to read the
> > last iso9660 data sector with a small C program (reading 2 kb) and
> > it failed to read the sector. Using ide-scsi I was able to read it.....
>
> Thats the bug that should now be fixed by the ide changes I did so that
> ide-cd has the knowledge ide-scsi has for partial completions of I/O
I haven't looked closely but I've noticed that these fixes are accessing rq->bio
directly which is a layering violation. Could you de-bio and submit them?
[ AFAIR they are already splitted out in RHEL4 ]
Speaking about ide-scsi, it will be undeprecated after I fix the locking.
Rationale is that ide-scsi is _much_ simpler than ide-{cd,tape}.
[ although it doesn't support all the hardware that ide-{cd,tape} do ]
Bartlomiej
On Llu, 2005-02-21 at 15:25, Bartlomiej Zolnierkiewicz wrote:
> I haven't looked closely but I've noticed that these fixes are accessing rq->bio
> directly which is a layering violation. Could you de-bio and submit them?
> [ AFAIR they are already splitted out in RHEL4 ]
Not in the near future.
> Speaking about ide-scsi, it will be undeprecated after I fix the locking.
> Rationale is that ide-scsi is _much_ simpler than ide-{cd,tape}.
> [ although it doesn't support all the hardware that ide-{cd,tape} do ]
And vice versa with ide-cd - not always for reasons I understand either.
On Mon, 21 Feb 2005, Bartlomiej Zolnierkiewicz wrote:
> Speaking about ide-scsi, it will be undeprecated after I fix the locking.
> Rationale is that ide-scsi is _much_ simpler than ide-{cd,tape}.
> [ although it doesn't support all the hardware that ide-{cd,tape} do ]
Good to read that. I've always wondered why Linux went backwards when all
other systems added atapicam (FreeBSD) and similar, now I can stop
wondering.
--
Matthias Andree
[email protected] wrote:
> On Fri, 18 Feb 2005 15:23:44 EST, Bill Davidsen said:
>
>
>>I'll try to build a truth table for this, I'm now working with some
>>non-iso data sets, so I'm a bit more interested. I would expect read()
>>to only try to read one sector, so I'll just do a quick and dirty to get
>>the size from the command line, seek and read.
>>
>>I haven't had a problem using dd to date, as long as I know how long the
>>data set was, but I'll try to have results tonight.
>
>
> The problem is that often you don't know exactly how long the data set is
> (think "backup burned to CD/RW") - there's a *lot* of code that does stuff
> like
>
> while (actual=read(fd,buffer,65536) > 0) {
> ...
> }
>
> with the realistic expectation that the last read might return less than 64k,
> in which case 'actual' will tell us how much was read. Instead, we just get
> an error on the read.
>
> Note that 'dd' does this - that's why you get messages like '12343+1 blocks read'.
> We *really* want to get to a point where 'dd' will work *without* having to
> tell it a 'bs=' and 'count=' to get the size right....
I think I already had a pretty good grasp on that, in my previous post
on this I noted: "The last time I looked at this, the issue was that the
user software did a large read and the ide-cd didn't properly return a
small data block with no error, but rather returned an error with no
data. If you get the size of the ISO image, you can read that with any
program which doesn't try to read MORE than that."
It sounds as if (a) the problem with ide-cd is going to get fixed, and
(b) ide-scsi may not remain depreciated. A win-win if I ever saw one.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
David Lang wrote:
> I regularly burn tarballs to a CD without useing a filesystem and as
> long as I use the -pad option when burning I've had no problems reading
> them (the -pad was nessasary even when I was useing ide-scsi)
That matches my experience, at least as far as the "no problem" part, I
never tried without -pad because it just seemed as if cdrecord would
have a better idea of what the drive wanted than I do.
I have burned tarballs, as well as cpio (I like the checking with -Hcrc
and not overwriting newer versions of a file), and more recently I have
been burning encrypted filesystem images onto DVDs directly, and that
works as well.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> On Mon, 21 Feb 2005 15:00:28 +0000, Alan Cox <[email protected]> wrote:
>
>>On Gwe, 2005-02-18 at 10:31, Kiniger, Karl (GE Healthcare) wrote:
>>
>>>Not entirely true (at least for me). I actually tried to read the
>>>last iso9660 data sector with a small C program (reading 2 kb) and
>>>it failed to read the sector. Using ide-scsi I was able to read it.....
>>
>>Thats the bug that should now be fixed by the ide changes I did so that
>>ide-cd has the knowledge ide-scsi has for partial completions of I/O
>
>
> I haven't looked closely but I've noticed that these fixes are accessing rq->bio
> directly which is a layering violation. Could you de-bio and submit them?
> [ AFAIR they are already splitted out in RHEL4 ]
>
> Speaking about ide-scsi, it will be undeprecated after I fix the locking.
> Rationale is that ide-scsi is _much_ simpler than ide-{cd,tape}.
> [ although it doesn't support all the hardware that ide-{cd,tape} do ]
Some time ago I offered the opinion that this was the correct way to go.
Linux presents real SCSI, PPA, USB, and firewire as SCSI, and with
ide-scsi all ATAPI devices are covered as well.
I have not tried ide-floppy in some time, but my two machines which do
ZIP drive media exchange both use the ide-scsi interface and 2.4 kernel
to talk to the devices. They are unlikely to get or need an update, but
I did try ide-floppy at one time and had some poorly-remembered
"learning experience" doing so.
Thanks for your work on this!
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Mon, Feb 21, 2005 at 03:00:28PM +0000, Alan Cox wrote:
> On Gwe, 2005-02-18 at 10:31, Kiniger, Karl (GE Healthcare) wrote:
> > Not entirely true (at least for me). I actually tried to read the
> > last iso9660 data sector with a small C program (reading 2 kb) and
> > it failed to read the sector. Using ide-scsi I was able to read it.....
>
> Thats the bug that should now be fixed by the ide changes I did so that
> ide-cd has the knowledge ide-scsi has for partial completions of I/O
Thanks Alan,
hopefully these changes will go into the fedora core3 kernel soon.
Greetings
Karl
--
Karl Kiniger mailto:[email protected]
GE Medical Systems Kretztechnik GmbH & Co OHG
Tiefenbach 15 Tel: (++43) 7682-3800-710
A-4871 Zipf Austria Fax: (++43) 7682-3800-47
On Sat, Feb 19, 2005 at 01:23:10AM +0100, [email protected] wrote:
>
> On Fri, 18 Feb 2005 15:23:44 EST, Bill Davidsen said:
>
> > I'll try to build a truth table for this, I'm now working with some
> > non-iso data sets, so I'm a bit more interested. I would expect read()
> > to only try to read one sector, so I'll just do a quick and dirty to get
> > the size from the command line, seek and read.
> >
> > I haven't had a problem using dd to date, as long as I know how long the
> > data set was, but I'll try to have results tonight.
>
> The problem is that often you don't know exactly how long the data set is
> (think "backup burned to CD/RW") - there's a *lot* of code that does stuff
> like
>
> while (actual=read(fd,buffer,65536) > 0) {
> ...
> }
>
> with the realistic expectation that the last read might return less than
> 64k,
> in which case 'actual' will tell us how much was read. Instead, we just get
> an error on the read.
>
> Note that 'dd' does this - that's why you get messages like '12343+1 blocks
> read'.
> We *really* want to get to a point where 'dd' will work *without* having to
> tell it a 'bs=' and 'count=' to get the size right....
> )
my point was that even specifying the exact byte count was not sufficient.
e.g
strace sdd if=/dev/zero bs=32k of=/dev/null ivsize=41234 gives:
......
munmap(0x46a000, 4096) = 0
_llseek(3, 0, [0], SEEK_SET) = 0
_llseek(4, 0, [0], SEEK_SET) = 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = 32768
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = 32768
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8466) = 8466
write(2, "sdd: Done with input volume # 1."..., 33sdd: Done with input volume # 1.
) = 33
write(2, "Do you want to continue with inp"..., 53Do you want to continue with input volume # 2 (y/n): ) = 53
that is, it requests exactly ivsize bytes (for iso cd's this can be got from isosize).
even this was not good enough....
Karl
--
Karl Kiniger mailto:[email protected]
GE Medical Systems Kretztechnik GmbH & Co OHG
Tiefenbach 15 Tel: (++43) 7682-3800-710
A-4871 Zipf Austria Fax: (++43) 7682-3800-47