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: Logical
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, &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, 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")
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/
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) || (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) || (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) || (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.