Re: No SCSI burning problem (was: Bug in "ide-pci.c")
On Sat, Oct 07, 2000 at 11:16:30AM -0700, Andre Hedrick wrote: > On Sat, 7 Oct 2000, Jeff V. Merkey wrote: > > > append "hdd=ide-scsi" > > append "hdd=scsi" is better. Care to explain why? -- /| Ragnar Højland Freedom - Linux - OpenGL Fingerprint 94C4B \ o.O| 2F0D27DE025BE2302C =(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822 U chaos and madness await thee at its end." hkp://keys.pgp.com Handle via comment channels only. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in ide-pci.c)
On Sat, Oct 07, 2000 at 11:16:30AM -0700, Andre Hedrick wrote: On Sat, 7 Oct 2000, Jeff V. Merkey wrote: append "hdd=ide-scsi" append "hdd=scsi" is better. Care to explain why? -- /| Ragnar Højland Freedom - Linux - OpenGL Fingerprint 94C4B \ o.O| 2F0D27DE025BE2302C =(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822 U chaos and madness await thee at its end." hkp://keys.pgp.com Handle via comment channels only. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in "ide-pci.c")
Oct 7 18:48:01 manos PAM_pwdb[727]: (login) session opened for user root by
LOGIN(uid=0)
Oct 7 18:48:08 manos kernel: scsi1 : SCSI host adapter emulation for IDE ATAPI
devices
Oct 7 18:48:08 manos kernel: scsi : 2 hosts.
Oct 7 18:49:32 manos PAM_pwdb[728]: (login) session opened for user root by
LOGIN(uid=0)
Oct 7 19:04:34 manos modprobe: modprobe: Can't locate module block-major-11
Oct 7 19:04:34 manos modprobe: modprobe: Can't locate module block-major-11
Oct 7 19:04:41 manos kernel: hdd: packet command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:04:41 manos kernel: hdd: packet command error: error=0x54
Oct 7 19:04:41 manos kernel: ATAPI device hdd:
Oct 7 19:04:41 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:04:41 manos kernel: Invalid field in command packet -- (asc=0x24,
ascq=0x00)
Oct 7 19:04:41 manos kernel: The failed "Read TOC" packet command was:
Oct 7 19:04:41 manos kernel: "43 02 00 00 00 00 00 00 04 00 00 00 "
Oct 7 19:04:41 manos kernel: hdd: command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:04:41 manos kernel: hdd: command error: error=0x54
Oct 7 19:04:41 manos kernel: end_request: I/O error, dev 16:40 (hdd), sector 2
Oct 7 19:04:41 manos kernel: ATAPI device hdd:
Oct 7 19:04:41 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:04:41 manos kernel: Logical block address out of range -- (asc=0x21,
ascq=0x00)
Oct 7 19:04:41 manos kernel: hdd: packet command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:04:41 manos kernel: hdd: packet command error: error=0x54
Oct 7 19:04:41 manos kernel: ATAPI device hdd:
Oct 7 19:04:41 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:04:41 manos kernel: Invalid field in command packet -- (asc=0x24,
ascq=0x00)
Oct 7 19:04:41 manos kernel: The failed "Read TOC" packet command was:
Oct 7 19:04:41 manos kernel: "43 02 00 00 00 00 00 00 04 00 00 00 "
Oct 7 19:04:41 manos kernel: hdd: command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:04:41 manos kernel: hdd: command error: error=0x54
Oct 7 19:04:41 manos kernel: end_request: I/O error, dev 16:40 (hdd), sector 2
Oct 7 19:04:41 manos kernel: ATAPI device hdd:
Oct 7 19:04:41 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:04:41 manos kernel: Logical block address out of range -- (asc=0x21,
ascq=0x00)
Oct 7 19:04:41 manos kernel: hdd: packet command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:04:41 manos kernel: hdd: packet command error: error=0x54
Oct 7 19:04:41 manos kernel: ATAPI device hdd:
Oct 7 19:04:41 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:04:41 manos kernel: Invalid field in command packet -- (asc=0x24,
ascq=0x00)
Oct 7 19:04:41 manos kernel: The failed "Read TOC" packet command was:
Oct 7 19:04:41 manos kernel: "43 02 00 00 00 00 00 00 04 00 00 00 "
Oct 7 19:04:41 manos kernel: hdd: command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:04:41 manos kernel: hdd: command error: error=0x54
Oct 7 19:04:41 manos kernel: end_request: I/O error, dev 16:40 (hdd), sector 0
Oct 7 19:04:41 manos kernel: FAT bread failed
Oct 7 19:04:41 manos kernel: ATAPI device hdd:
Oct 7 19:04:41 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:04:41 manos kernel: Logical block address out of range -- (asc=0x21,
ascq=0x00)
Oct 7 19:05:01 manos kernel: hdd: packet command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:05:01 manos kernel: hdd: packet command error: error=0x54
Oct 7 19:05:01 manos kernel: ATAPI device hdd:
Oct 7 19:05:01 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:05:01 manos kernel: Invalid field in command packet -- (asc=0x24,
ascq=0x00)
Oct 7 19:05:01 manos kernel: The failed "Read TOC" packet command was:
Oct 7 19:05:01 manos kernel: "43 02 00 00 00 00 00 00 04 00 00 00 "
Oct 7 19:05:01 manos kernel: hdd: packet command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:05:01 manos kernel: hdd: packet command error: error=0x54
Oct 7 19:05:01 manos kernel: ATAPI device hdd:
Oct 7 19:05:01 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:05:01 manos kernel: Invalid field in command packet -- (asc=0x24,
ascq=0x00)
Oct 7 19:05:01 manos kernel: The failed "Read TOC" packet command was:
Oct 7 19:05:01 manos kernel: "43 02 00 00 00 00 00 00 04 00 00 00 "
Oct 7 19:05:01 manos kernel: hdd: command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:05:01 manos kernel: hdd: command error: error=0x54
Oct 7 19:05:01 manos kernel: end_request: I/O error, dev 16:40 (hdd), sector 64
Oct 7 19:05:01 manos kernel: ATAPI device hdd:
Oct 7 19:05:01 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:05:01 manos kernel:
Re: Bug in "ide-pci.c"
On Fri, 6 Oct 2000, Andre Hedrick wrote:
> void go_take_a_dump (float load)
> {
> if (pull_down_pants() && purge_bowles() && wipe_anus() && pull_up_pants())
> flush(load);
> else
> wear(load);
> }
But here you make another classic mistake. Consider the case where
purge_bowels() fails (-EWOULDBLOCK?).
In that case, you don't actually execute the subsequent two procedure
calls, which I'm sure we all agree is a suboptimal state of affairs.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in "ide-pci.c")
On Sat, Oct 07, 2000 at 11:16:30AM -0700, Andre Hedrick wrote: > On Sat, 7 Oct 2000, Jeff V. Merkey wrote: > > > append "hdd=ide-scsi" Am I doing this wrong? It seems to work. :-) Jeff > > append "hdd=scsi" is better. > > Andre Hedrick > The Linux ATA/IDE guy > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in "ide-pci.c")
On Sat, 7 Oct 2000, Jeff V. Merkey wrote: > append "hdd=ide-scsi" append "hdd=scsi" is better. Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in "ide-pci.c")
On Sat, Oct 07, 2000 at 10:03:34AM +0200, Jens Axboe wrote: > On Sat, Oct 07 2000, Dax Kelson wrote: > > > BTW, how did your testing of the speed=4 problem with ide-scsi turn > > > out. We are still seeing the speed=2 problem on 2.4.0-pre9. I cannot > > > get the drive to burn clean unless the speed setting is cranked down to > > > speed=2. > > > > > > Jeff > > > > I just burned Red Hat 7.0 disk1 iso image at on a SCSI 4x burner without > > any problems. I have an IDE Plextor 12x burner at work, Monday I'll try a > > burn under 2.4.0-test9. > > [snip] > > I regurlarly burn CD-R with ide-scsi on 2.4, and I've not noticed any > problems (this is on two different atapi writers). This could be an > ide-scsi bug on some models. The folks who are seeing corruption, could > they try and narrow it down? Is it random data getting written, or > data from other locations? I think it's related to the drive type in some way. What we are seeing is the CD burner hang on the first write to track 0. Once it starts burning, it seems to work fine, and we have even got some clean burns at speed=4, however, when it's set this way, we occasionally see cdrecord hang when it attempts to write the first track of a CD. It ruins the CD in the burner, BTW when this happens. I also see an I/O error message from the ide-scsi driver about a timeout and data error (but I did not write it down -- sorry). I will burn some more CD's today, and will try to get more info. Config is: in lilo.conf: append "hdd=ide-scsi" and the CDROM device is mapped to: /dev/scd0 and I load the ide-scsi module: insmod ide-scsi and: cdrecord -scanbus. Then we use the system to burn CD's all day. Jeff > > -- > * Jens Axboe <[EMAIL PROTECTED]> > * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in "ide-pci.c")
> Something like this?
Close but now there is no select.
--- /opt/kernel/linux-2.4.0-test9/drivers/scsi/ide-scsi.c Sat Sep 23
01:04:46 2000
+++ drivers/scsi/ide-scsi.c Sat Oct 7 10:52:13 2000
@@ -435,7 +435,6 @@
+ SELECT_DRIVE(HWIF(drive), drive);
if (IDE_CONTROL_REG)
OUT_BYTE (drive->ctl,IDE_CONTROL_REG);
OUT_BYTE (dma_ok,IDE_FEATURE_REG);
OUT_BYTE (bcount >> 8,IDE_BCOUNTH_REG);
OUT_BYTE (bcount & 0xff,IDE_BCOUNTL_REG);
- OUT_BYTE (drive->select.all,IDE_SELECT_REG);
if (dma_ok) {
set_bit (PC_DMA_IN_PROGRESS, >flags);
It is a macro issue and ordering task-registers.
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in "ide-pci.c")
On Sat, Oct 07 2000, Andre Hedrick wrote:
> > I regurlarly burn CD-R with ide-scsi on 2.4, and I've not noticed any
> > problems (this is on two different atapi writers). This could be an
> > ide-scsi bug on some models. The folks who are seeing corruption, could
> > they try and narrow it down? Is it random data getting written, or
> > data from other locations?
>
> If it is ide-scsi then it is device select bug that is know but never made
> it in the kernel. I have the fix.
>
> Plextor is one on the list that fails without it.
Something like this?
--
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
--- /opt/kernel/linux-2.4.0-test9/drivers/scsi/ide-scsi.c Sat Sep 23 01:04:46
2000
+++ drivers/scsi/ide-scsi.c Sat Oct 7 10:52:13 2000
@@ -435,7 +435,6 @@
OUT_BYTE (dma_ok,IDE_FEATURE_REG);
OUT_BYTE (bcount >> 8,IDE_BCOUNTH_REG);
OUT_BYTE (bcount & 0xff,IDE_BCOUNTL_REG);
- OUT_BYTE (drive->select.all,IDE_SELECT_REG);
if (dma_ok) {
set_bit (PC_DMA_IN_PROGRESS, >flags);
Re: No SCSI burning problem (was: Bug in "ide-pci.c")
On Sat, 7 Oct 2000, Jens Axboe wrote: > I regurlarly burn CD-R with ide-scsi on 2.4, and I've not noticed any > problems (this is on two different atapi writers). This could be an > ide-scsi bug on some models. The folks who are seeing corruption, could > they try and narrow it down? Is it random data getting written, or > data from other locations? If it is ide-scsi then it is device select bug that is know but never made it in the kernel. I have the fix. Plextor is one on the list that fails without it. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in "ide-pci.c")
On Sat, Oct 07 2000, Dax Kelson wrote: > > BTW, how did your testing of the speed=4 problem with ide-scsi turn > > out. We are still seeing the speed=2 problem on 2.4.0-pre9. I cannot > > get the drive to burn clean unless the speed setting is cranked down to > > speed=2. > > > > Jeff > > I just burned Red Hat 7.0 disk1 iso image at on a SCSI 4x burner without > any problems. I have an IDE Plextor 12x burner at work, Monday I'll try a > burn under 2.4.0-test9. [snip] I regurlarly burn CD-R with ide-scsi on 2.4, and I've not noticed any problems (this is on two different atapi writers). This could be an ide-scsi bug on some models. The folks who are seeing corruption, could they try and narrow it down? Is it random data getting written, or data from other locations? -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
No SCSI burning problem (was: Bug in "ide-pci.c")
Jeff V. Merkey said once upon a time (Fri, 6 Oct 2000): > > Andre, > > BTW, how did your testing of the speed=4 problem with ide-scsi turn > out. We are still seeing the speed=2 problem on 2.4.0-pre9. I cannot > get the drive to burn clean unless the speed setting is cranked down to > speed=2. > > Jeff I just burned Red Hat 7.0 disk1 iso image at on a SCSI 4x burner without any problems. I have an IDE Plextor 12x burner at work, Monday I'll try a burn under 2.4.0-test9. distro: Red Hat 7.0 kernel: 2.4.0-test9-pre8 Cdrecord 1.9 True SCSI Yamaha 4x burner (scsi0) found at PCI 0/16/0 (scsi0:0:4:0) Synchronous at 8.0 Mbyte/sec, offset 15. Vendor: YAMAHAModel: CRW4416S Rev: 1.0j Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr1 at scsi0, channel 0, id 4, lun 0 Uniform CD-ROM driver Revision: 3.11 sr1: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray [root@localhost burn]# md5sum redhat-7.0-disc1.iso 626b7d18033e320c27c8cd58cc37a288 redhat-7.0-disc1.iso [did a 4x burn] [root@localhost dkelson]# md5sum /dev/scd1 626b7d18033e320c27c8cd58cc37a288 /dev/scd1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
No SCSI burning problem (was: Bug in ide-pci.c)
Jeff V. Merkey said once upon a time (Fri, 6 Oct 2000): Andre, BTW, how did your testing of the speed=4 problem with ide-scsi turn out. We are still seeing the speed=2 problem on 2.4.0-pre9. I cannot get the drive to burn clean unless the speed setting is cranked down to speed=2. Jeff I just burned Red Hat 7.0 disk1 iso image at on a SCSI 4x burner without any problems. I have an IDE Plextor 12x burner at work, Monday I'll try a burn under 2.4.0-test9. distro: Red Hat 7.0 kernel: 2.4.0-test9-pre8 Cdrecord 1.9 True SCSI Yamaha 4x burner (scsi0) Adaptec AHA-2940UW Pro Ultra SCSI host adapter found at PCI 0/16/0 (scsi0:0:4:0) Synchronous at 8.0 Mbyte/sec, offset 15. Vendor: YAMAHAModel: CRW4416S Rev: 1.0j Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr1 at scsi0, channel 0, id 4, lun 0 Uniform CD-ROM driver Revision: 3.11 sr1: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray [root@localhost burn]# md5sum redhat-7.0-disc1.iso 626b7d18033e320c27c8cd58cc37a288 redhat-7.0-disc1.iso [did a 4x burn] [root@localhost dkelson]# md5sum /dev/scd1 626b7d18033e320c27c8cd58cc37a288 /dev/scd1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in ide-pci.c)
On Sat, Oct 07 2000, Dax Kelson wrote: BTW, how did your testing of the speed=4 problem with ide-scsi turn out. We are still seeing the speed=2 problem on 2.4.0-pre9. I cannot get the drive to burn clean unless the speed setting is cranked down to speed=2. Jeff I just burned Red Hat 7.0 disk1 iso image at on a SCSI 4x burner without any problems. I have an IDE Plextor 12x burner at work, Monday I'll try a burn under 2.4.0-test9. [snip] I regurlarly burn CD-R with ide-scsi on 2.4, and I've not noticed any problems (this is on two different atapi writers). This could be an ide-scsi bug on some models. The folks who are seeing corruption, could they try and narrow it down? Is it random data getting written, or data from other locations? -- * Jens Axboe [EMAIL PROTECTED] * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in ide-pci.c)
On Sat, 7 Oct 2000, Jens Axboe wrote: I regurlarly burn CD-R with ide-scsi on 2.4, and I've not noticed any problems (this is on two different atapi writers). This could be an ide-scsi bug on some models. The folks who are seeing corruption, could they try and narrow it down? Is it random data getting written, or data from other locations? If it is ide-scsi then it is device select bug that is know but never made it in the kernel. I have the fix. Plextor is one on the list that fails without it. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in ide-pci.c)
On Sat, Oct 07 2000, Andre Hedrick wrote:
I regurlarly burn CD-R with ide-scsi on 2.4, and I've not noticed any
problems (this is on two different atapi writers). This could be an
ide-scsi bug on some models. The folks who are seeing corruption, could
they try and narrow it down? Is it random data getting written, or
data from other locations?
If it is ide-scsi then it is device select bug that is know but never made
it in the kernel. I have the fix.
Plextor is one on the list that fails without it.
Something like this?
--
* Jens Axboe [EMAIL PROTECTED]
* SuSE Labs
--- /opt/kernel/linux-2.4.0-test9/drivers/scsi/ide-scsi.c Sat Sep 23 01:04:46
2000
+++ drivers/scsi/ide-scsi.c Sat Oct 7 10:52:13 2000
@@ -435,7 +435,6 @@
OUT_BYTE (dma_ok,IDE_FEATURE_REG);
OUT_BYTE (bcount 8,IDE_BCOUNTH_REG);
OUT_BYTE (bcount 0xff,IDE_BCOUNTL_REG);
- OUT_BYTE (drive-select.all,IDE_SELECT_REG);
if (dma_ok) {
set_bit (PC_DMA_IN_PROGRESS, pc-flags);
Re: No SCSI burning problem (was: Bug in ide-pci.c)
Something like this?
Close but now there is no select.
--- /opt/kernel/linux-2.4.0-test9/drivers/scsi/ide-scsi.c Sat Sep 23
01:04:46 2000
+++ drivers/scsi/ide-scsi.c Sat Oct 7 10:52:13 2000
@@ -435,7 +435,6 @@
+ SELECT_DRIVE(HWIF(drive), drive);
if (IDE_CONTROL_REG)
OUT_BYTE (drive-ctl,IDE_CONTROL_REG);
OUT_BYTE (dma_ok,IDE_FEATURE_REG);
OUT_BYTE (bcount 8,IDE_BCOUNTH_REG);
OUT_BYTE (bcount 0xff,IDE_BCOUNTL_REG);
- OUT_BYTE (drive-select.all,IDE_SELECT_REG);
if (dma_ok) {
set_bit (PC_DMA_IN_PROGRESS, pc-flags);
It is a macro issue and ordering task-registers.
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in ide-pci.c)
On Sat, Oct 07, 2000 at 10:03:34AM +0200, Jens Axboe wrote: On Sat, Oct 07 2000, Dax Kelson wrote: BTW, how did your testing of the speed=4 problem with ide-scsi turn out. We are still seeing the speed=2 problem on 2.4.0-pre9. I cannot get the drive to burn clean unless the speed setting is cranked down to speed=2. Jeff I just burned Red Hat 7.0 disk1 iso image at on a SCSI 4x burner without any problems. I have an IDE Plextor 12x burner at work, Monday I'll try a burn under 2.4.0-test9. [snip] I regurlarly burn CD-R with ide-scsi on 2.4, and I've not noticed any problems (this is on two different atapi writers). This could be an ide-scsi bug on some models. The folks who are seeing corruption, could they try and narrow it down? Is it random data getting written, or data from other locations? I think it's related to the drive type in some way. What we are seeing is the CD burner hang on the first write to track 0. Once it starts burning, it seems to work fine, and we have even got some clean burns at speed=4, however, when it's set this way, we occasionally see cdrecord hang when it attempts to write the first track of a CD. It ruins the CD in the burner, BTW when this happens. I also see an I/O error message from the ide-scsi driver about a timeout and data error (but I did not write it down -- sorry). I will burn some more CD's today, and will try to get more info. Config is: in lilo.conf: append "hdd=ide-scsi" and the CDROM device is mapped to: /dev/scd0 and I load the ide-scsi module: insmod ide-scsi and: cdrecord -scanbus. Then we use the system to burn CD's all day. Jeff -- * Jens Axboe [EMAIL PROTECTED] * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in ide-pci.c)
On Sat, 7 Oct 2000, Jeff V. Merkey wrote: append "hdd=ide-scsi" append "hdd=scsi" is better. Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in ide-pci.c)
On Sat, Oct 07, 2000 at 11:16:30AM -0700, Andre Hedrick wrote: On Sat, 7 Oct 2000, Jeff V. Merkey wrote: append "hdd=ide-scsi" Am I doing this wrong? It seems to work. :-) Jeff append "hdd=scsi" is better. Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in ide-pci.c
On Fri, 6 Oct 2000, Andre Hedrick wrote:
void go_take_a_dump (float load)
{
if (pull_down_pants() purge_bowles() wipe_anus() pull_up_pants())
flush(load);
else
wear(load);
}
But here you make another classic mistake. Consider the case where
purge_bowels() fails (-EWOULDBLOCK?).
In that case, you don't actually execute the subsequent two procedure
calls, which I'm sure we all agree is a suboptimal state of affairs.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: No SCSI burning problem (was: Bug in ide-pci.c)
Oct 7 18:48:01 manos PAM_pwdb[727]: (login) session opened for user root by
LOGIN(uid=0)
Oct 7 18:48:08 manos kernel: scsi1 : SCSI host adapter emulation for IDE ATAPI
devices
Oct 7 18:48:08 manos kernel: scsi : 2 hosts.
Oct 7 18:49:32 manos PAM_pwdb[728]: (login) session opened for user root by
LOGIN(uid=0)
Oct 7 19:04:34 manos modprobe: modprobe: Can't locate module block-major-11
Oct 7 19:04:34 manos modprobe: modprobe: Can't locate module block-major-11
Oct 7 19:04:41 manos kernel: hdd: packet command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:04:41 manos kernel: hdd: packet command error: error=0x54
Oct 7 19:04:41 manos kernel: ATAPI device hdd:
Oct 7 19:04:41 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:04:41 manos kernel: Invalid field in command packet -- (asc=0x24,
ascq=0x00)
Oct 7 19:04:41 manos kernel: The failed "Read TOC" packet command was:
Oct 7 19:04:41 manos kernel: "43 02 00 00 00 00 00 00 04 00 00 00 "
Oct 7 19:04:41 manos kernel: hdd: command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:04:41 manos kernel: hdd: command error: error=0x54
Oct 7 19:04:41 manos kernel: end_request: I/O error, dev 16:40 (hdd), sector 2
Oct 7 19:04:41 manos kernel: ATAPI device hdd:
Oct 7 19:04:41 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:04:41 manos kernel: Logical block address out of range -- (asc=0x21,
ascq=0x00)
Oct 7 19:04:41 manos kernel: hdd: packet command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:04:41 manos kernel: hdd: packet command error: error=0x54
Oct 7 19:04:41 manos kernel: ATAPI device hdd:
Oct 7 19:04:41 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:04:41 manos kernel: Invalid field in command packet -- (asc=0x24,
ascq=0x00)
Oct 7 19:04:41 manos kernel: The failed "Read TOC" packet command was:
Oct 7 19:04:41 manos kernel: "43 02 00 00 00 00 00 00 04 00 00 00 "
Oct 7 19:04:41 manos kernel: hdd: command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:04:41 manos kernel: hdd: command error: error=0x54
Oct 7 19:04:41 manos kernel: end_request: I/O error, dev 16:40 (hdd), sector 2
Oct 7 19:04:41 manos kernel: ATAPI device hdd:
Oct 7 19:04:41 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:04:41 manos kernel: Logical block address out of range -- (asc=0x21,
ascq=0x00)
Oct 7 19:04:41 manos kernel: hdd: packet command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:04:41 manos kernel: hdd: packet command error: error=0x54
Oct 7 19:04:41 manos kernel: ATAPI device hdd:
Oct 7 19:04:41 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:04:41 manos kernel: Invalid field in command packet -- (asc=0x24,
ascq=0x00)
Oct 7 19:04:41 manos kernel: The failed "Read TOC" packet command was:
Oct 7 19:04:41 manos kernel: "43 02 00 00 00 00 00 00 04 00 00 00 "
Oct 7 19:04:41 manos kernel: hdd: command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:04:41 manos kernel: hdd: command error: error=0x54
Oct 7 19:04:41 manos kernel: end_request: I/O error, dev 16:40 (hdd), sector 0
Oct 7 19:04:41 manos kernel: FAT bread failed
Oct 7 19:04:41 manos kernel: ATAPI device hdd:
Oct 7 19:04:41 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:04:41 manos kernel: Logical block address out of range -- (asc=0x21,
ascq=0x00)
Oct 7 19:05:01 manos kernel: hdd: packet command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:05:01 manos kernel: hdd: packet command error: error=0x54
Oct 7 19:05:01 manos kernel: ATAPI device hdd:
Oct 7 19:05:01 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:05:01 manos kernel: Invalid field in command packet -- (asc=0x24,
ascq=0x00)
Oct 7 19:05:01 manos kernel: The failed "Read TOC" packet command was:
Oct 7 19:05:01 manos kernel: "43 02 00 00 00 00 00 00 04 00 00 00 "
Oct 7 19:05:01 manos kernel: hdd: packet command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:05:01 manos kernel: hdd: packet command error: error=0x54
Oct 7 19:05:01 manos kernel: ATAPI device hdd:
Oct 7 19:05:01 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:05:01 manos kernel: Invalid field in command packet -- (asc=0x24,
ascq=0x00)
Oct 7 19:05:01 manos kernel: The failed "Read TOC" packet command was:
Oct 7 19:05:01 manos kernel: "43 02 00 00 00 00 00 00 04 00 00 00 "
Oct 7 19:05:01 manos kernel: hdd: command error: status=0x51 { DriveReady
SeekComplete Error }
Oct 7 19:05:01 manos kernel: hdd: command error: error=0x54
Oct 7 19:05:01 manos kernel: end_request: I/O error, dev 16:40 (hdd), sector 64
Oct 7 19:05:01 manos kernel: ATAPI device hdd:
Oct 7 19:05:01 manos kernel: Error: Illegal request -- (Sense key=0x05)
Oct 7 19:05:01 manos kernel:
Re: Bug in "ide-pci.c"
Andre, (Thanks for calling my bluff) && (I was wrong). Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in "ide-pci.c"
Sean Estabrooks wrote: > > Hi Andre, > > The if() logic must then rely on implementation specific compiler > details and not have any optimizations which break this code. While it may > "WORK" it isn't particularly reliable code. > > Sean Nope, the logical ops are sequence points required by standard to lazy evaluate left to right. For ||, that means they operate in order till they find a true. Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in "ide-pci.c"
On Fri, 6 Oct 2000, Sean Estabrooks wrote:
> Hi Andre,
>
> The if() logic must then rely on implementation specific compiler
> details and not have any optimizations which break this code. While it may
> "WORK" it isn't particularly reliable code.
If that is the case and it is proven then there is more code than mine
that will fail. Also if the compiler is allowed in optimizations to break
specific test order, then it is a bad compiler.
Order of operation is critical in writing code.
In my world of ATA, you dork the order of a command and you get crap on
your drive. So since there is not crap on the drive in general, I am
accounting for stupid programmer errors in the past, I call your bluff.
If you issue the command register first the the rest of the register will
execute on the next command register. This is doing thing bass-ackwards.
void go_take_a_dump (float load)
{
if (pull_down_pants() && purge_bowles() && wipe_anus() && pull_up_pants())
flush(load);
else
wear(load);
}
You do this out of order and this is more descriptive.
Now if you are complaining about logical operators in the test and how
these get optimized then you point is noted.
Since I was an astronomer and +/- one AU (93,000,000 miles) is critical,
feel free to check the rules for order. Then you can call my bluff.
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
FYI, I have a new baby-girl and thus the diaper-humor!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in "ide-pci.c"
Hi Andre, The if() logic must then rely on implementation specific compiler details and not have any optimizations which break this code. While it may "WORK" it isn't particularly reliable code. Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in "ide-pci.c"
Andre,
BTW, how did your testing of the speed=4 problem with ide-scsi turn
out. We are still seeing the speed=2 problem on 2.4.0-pre9. I cannot
get the drive to burn clean unless the speed setting is cranked down to
speed=2.
Jeff
Andre Hedrick wrote:
>
> On Fri, 6 Oct 2000, Sean Estabrooks wrote:
>
> > ide-pci.c bug:
> >
> > ide_setup_pci_baseregs() may inappropriately report device as not capable of full
>native PCI:
> >
> > // BUGGY LINE:
> > if (pci_read_config_byte(dev, PCI_CLASS_PROG, ) || (progif & 5) != 5) {
> > // = TWO CONDITIONS USING PROGIF
> >if ((progif & 0xa) != 0xa) {
> > printk("%s: device not capable of full native PCI mode\n", name);
> > return 1;
> >}
> >
> > ...
> >
> > In the first line of code above there is no guarantee that the first condition
>will be executed
> > before the second. As progif is set to 0 before this block of code, the second
>test will always
> > be true if it is executed prior to the first.
>
> if () are serial in test.
>
> >
> >
> >
>
> Andre Hedrick
> The Linux ATA/IDE guy
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in "ide-pci.c"
On Fri, 6 Oct 2000, Sean Estabrooks wrote:
> ide-pci.c bug:
>
> ide_setup_pci_baseregs() may inappropriately report device as not capable of full
>native PCI:
>
> // BUGGY LINE:
> if (pci_read_config_byte(dev, PCI_CLASS_PROG, ) || (progif & 5) != 5) {
> // = TWO CONDITIONS USING PROGIF
>if ((progif & 0xa) != 0xa) {
> printk("%s: device not capable of full native PCI mode\n", name);
> return 1;
>}
>
> ...
>
> In the first line of code above there is no guarantee that the first condition
>will be executed
> before the second. As progif is set to 0 before this block of code, the second test
>will always
> be true if it is executed prior to the first.
if () are serial in test.
>
>
>
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Bug in "ide-pci.c"
ide-pci.c bug:
ide_setup_pci_baseregs() may inappropriately
report device as not capable of full native PCI:
// BUGGY LINE:
if (pci_read_config_byte(dev,
PCI_CLASS_PROG, ) || (progif & 5) != 5)
{// = TWO CONDITIONS USING PROGIF
if ((progif &
0xa) != 0xa) { printk("%s:
device not capable of full native PCI mode\n",
name); return
1; }
...
In the first line of code above there is no
guarantee that the first condition will be executed
before the second. As progif is set to 0 before this block of code,
the second test will always
be true if it is executed prior to the first.
Re: Bug in ide-pci.c
On Fri, 6 Oct 2000, Sean Estabrooks wrote:
ide-pci.c bug:
ide_setup_pci_baseregs() may inappropriately report device as not capable of full
native PCI:
// BUGGY LINE:
if (pci_read_config_byte(dev, PCI_CLASS_PROG, progif) || (progif 5) != 5) {
// = TWO CONDITIONS USING PROGIF
if ((progif 0xa) != 0xa) {
printk("%s: device not capable of full native PCI mode\n", name);
return 1;
}
...
In the first line of code above there is no guarantee that the first condition
will be executed
before the second. As progif is set to 0 before this block of code, the second test
will always
be true if it is executed prior to the first.
if () are serial in test.
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in ide-pci.c
Andre,
BTW, how did your testing of the speed=4 problem with ide-scsi turn
out. We are still seeing the speed=2 problem on 2.4.0-pre9. I cannot
get the drive to burn clean unless the speed setting is cranked down to
speed=2.
Jeff
Andre Hedrick wrote:
On Fri, 6 Oct 2000, Sean Estabrooks wrote:
ide-pci.c bug:
ide_setup_pci_baseregs() may inappropriately report device as not capable of full
native PCI:
// BUGGY LINE:
if (pci_read_config_byte(dev, PCI_CLASS_PROG, progif) || (progif 5) != 5) {
// = TWO CONDITIONS USING PROGIF
if ((progif 0xa) != 0xa) {
printk("%s: device not capable of full native PCI mode\n", name);
return 1;
}
...
In the first line of code above there is no guarantee that the first condition
will be executed
before the second. As progif is set to 0 before this block of code, the second
test will always
be true if it is executed prior to the first.
if () are serial in test.
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in ide-pci.c
Hi Andre, The if() logic must then rely on implementation specific compiler details and not have any optimizations which break this code. While it may "WORK" it isn't particularly reliable code. Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in ide-pci.c
On Fri, 6 Oct 2000, Sean Estabrooks wrote:
Hi Andre,
The if() logic must then rely on implementation specific compiler
details and not have any optimizations which break this code. While it may
"WORK" it isn't particularly reliable code.
If that is the case and it is proven then there is more code than mine
that will fail. Also if the compiler is allowed in optimizations to break
specific test order, then it is a bad compiler.
Order of operation is critical in writing code.
In my world of ATA, you dork the order of a command and you get crap on
your drive. So since there is not crap on the drive in general, I am
accounting for stupid programmer errors in the past, I call your bluff.
If you issue the command register first the the rest of the register will
execute on the next command register. This is doing thing bass-ackwards.
void go_take_a_dump (float load)
{
if (pull_down_pants() purge_bowles() wipe_anus() pull_up_pants())
flush(load);
else
wear(load);
}
You do this out of order and this is more descriptive.
Now if you are complaining about logical operators in the test and how
these get optimized then you point is noted.
Since I was an astronomer and +/- one AU (93,000,000 miles) is critical,
feel free to check the rules for order. Then you can call my bluff.
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
FYI, I have a new baby-girl and thus the diaper-humor!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in ide-pci.c
Sean Estabrooks wrote: Hi Andre, The if() logic must then rely on implementation specific compiler details and not have any optimizations which break this code. While it may "WORK" it isn't particularly reliable code. Sean Nope, the logical ops are sequence points required by standard to lazy evaluate left to right. For ||, that means they operate in order till they find a true. Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in ide-pci.c
Andre, (Thanks for calling my bluff) (I was wrong). Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
