Re: regression: ide-floppy doesn't work with IOMEGA IDE ZIP drive

Re: regression: ide-floppy doesn't work with IOMEGA IDE ZIP drive

[Stanislav Brabec]

Albert Lee wrote:
> Tejun Heo wrote:

> > Hmmm... weird.  Your drive bears the same model name as Stanislav's.  I
> > don't think the low level driver is causing the difference.  They both
> > use the standard libata HSM implementation.  Any ideas?  Stanislav, can
> > you try to connect that zip drive to another IDE controller?

> Maybe it's also worth a try to replace the medium, cable or even the
> drive itself to rule out the possibility of hardware problem.

I'll try it. I cannot replace the drive, I don't have any spare one, but
my colleague has. He will try it on his machine. So let's wait for
result.

Looking at the syslog in Novell bug 232086 in detail, following line may
indicate hardware failure:
usb 5-1: string descriptor 0 read error: -22

My drive is a slave on bus, where master is a modern Seagate ST3160812A.

On my system I see two regressions:
- One between year 2002 kernels and SuSE Linux 10.0:
  Delay with "packet command initiated yet DRQ isn't asserted" before
  first read access, then the read will succeed.
  I did not yet reproduce this regression just now on my hardware.
- Second between SuSE 10.1 and 10.2:
  Delay with "packet command initiated yet DRQ isn't asserted" before
  any attempt to access, then it will fail.
  This regression is reproducible just now on my hardware, but still may
  be caused by hardware problems raised by a slightly different
  initialization order.

Tejun Heo wrote:
> [libata]
> And, as the device requires custom high level driver, libata fails
> miserably.  Would it be worth to try support these devices?  Or are
> they just too outdated to put the effort in?

As far as I remember, it was working without any special driver with
ide-scsi.

-- 
Best Regards,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec@suse.cz
Lihovarska 1060/12                            tel: +420 284 028 966
190 00 Praha 9                                fax: +420 284 028 951
Czech Republic                                http://www.suse.cz/

Re: regression: ide-floppy doesn't work with IOMEGA IDE ZIP drive

[Tejun Heo]

Stanislav Brabec wrote:
> Looking at the syslog in Novell bug 232086 in detail, following line may
> indicate hardware failure:
> usb 5-1: string descriptor 0 read error: -22

I don't think usb 5-1 is related to ide-floppy problem.

> My drive is a slave on bus, where master is a modern Seagate ST3160812A.
> 
> On my system I see two regressions:
> - One between year 2002 kernels and SuSE Linux 10.0:
>   Delay with "packet command initiated yet DRQ isn't asserted" before
>   first read access, then the read will succeed.
>   I did not yet reproduce this regression just now on my hardware.
> - Second between SuSE 10.1 and 10.2:
>   Delay with "packet command initiated yet DRQ isn't asserted" before
>   any attempt to access, then it will fail.
>   This regression is reproducible just now on my hardware, but still may
>   be caused by hardware problems raised by a slightly different
>   initialization order.

I see.

> Tejun Heo wrote:
>> [libata]
>> And, as the device requires custom high level driver, libata fails
>> miserably.  Would it be worth to try support these devices?  Or are
>> they just too outdated to put the effort in?
> 
> As far as I remember, it was working without any special driver with
> ide-scsi.

If that's the case, libata should work too as long as the HSM problem is
fixed.

-- 
tejun

Re: regression: ide-floppy doesn't work with IOMEGA IDE ZIP drive

[Mark Lord]

Tejun wrote:
> If that's the case, libata should work too as long as the HSM problem is
> fixed.

Really?  I didn't notice when libata gained ATAPI-disk support.

Are you *sure* about that??

Cool.

Re: regression: ide-floppy doesn't work with IOMEGA IDE ZIP drive

[Tejun Heo]

Mark Lord wrote:
> Tejun wrote:
>> If that's the case, libata should work too as long as the HSM problem is
>> fixed.
> 
> Really?  I didn't notice when libata gained ATAPI-disk support.
> 
> Are you *sure* about that??

Not sure sure but almost sure.  :-)  What ide-scsi does is borrowing
SCSI mid and high level drivers while using ide as SCSI low level
driver.  To SCSI, libata and ide-scsi aren't very different except that
libata also exports SBC device to it.  So, if SCSI could handle ATAPI
disk via ide-scsi, I don't think there is any reason it can't with libata.

Thanks.

-- 
tejun

IOMEGA IDE ZIP (ATAPI) drive

[Mark Lord]

Tejun Heo wrote:
> Mark Lord wrote:
>> Really?  I didn't notice when libata gained ATAPI-disk support.
>>
>> Are you *sure* about that??
> 
> Not sure sure but almost sure.  :-)  What ide-scsi does is borrowing
> SCSI mid and high level drivers while using ide as SCSI low level
> driver.  To SCSI, libata and ide-scsi aren't very different except that
> libata also exports SBC device to it.  So, if SCSI could handle ATAPI
> disk via ide-scsi, I don't think there is any reason it can't with libata.

Okay, I dusted off one of my old (actually, I believe *the oldest*)
Zip100 drives in the collection, and tried it out here with both
2.6.20 and 2.6.21-rc3-git9.   It works mostly fine with each.

A couple of minor issues, though.

(1) When ejecting a disk, either with the "eject /dev/sdc" command
or using the front-panel soft-eject button on the drive,
I get the following in syslog from libata:

sdc: Spinning up disk...<3>ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
         res 00/00:03:00:00:20/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
ata4: soft resetting port
ATA: abnormal status 0x7F on port 0x00010177
ATA: abnormal status 0x7F on port 0x00010177
ata4.00: configured for PIO2
ata4: EH complete


(2) The above log says PIO2, but the IDENTIFY data for this drive,
which I had to patch the kernel to get (ATAPI ATA_16 support),
indicates max PIO0 for this unit.  I suppose maybe the chipset
doesn't go that low, but no big deal since IORDY handshakes it anyway.

Chipset is VIA, PCI ID 1106:0571, Rev.6.


Tejun, if you want one for your testbed, then email me shipping
info (again) and I'll send you this exact unit, with one disc.

Here's the IDENTIFY data, for anyone else here who collects antiques:

/dev/sdc:
80a0 0000 0000 0000 0000 0000 0000 0000
0000 0000 2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 0000 0000 0000 3233
2e44 2020 2020 494f 4d45 4741 2020 5a49
5020 3130 3020 2020 2020 2020 4154 4150
4920 2020 2020 2020 2020 2020 2020 0000
0000 0e00 0000 0000 0000 0002 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 01f4 01f4 0000 0000 0000
0000 0006 0009 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0101
2863 2920 436f 7079 7269 6768 7420 494f
4d45 4741 2031 3939 3720 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000

Cheers

Re: IOMEGA IDE ZIP (ATAPI) drive

[Albert Lee]

Mark Lord wrote:
> Tejun Heo wrote:
> 
>> Mark Lord wrote:
>>
>>> Really?  I didn't notice when libata gained ATAPI-disk support.
>>>
>>> Are you *sure* about that??
>>
>>
>> Not sure sure but almost sure.  :-)  What ide-scsi does is borrowing
>> SCSI mid and high level drivers while using ide as SCSI low level
>> driver.  To SCSI, libata and ide-scsi aren't very different except that
>> libata also exports SBC device to it.  So, if SCSI could handle ATAPI
>> disk via ide-scsi, I don't think there is any reason it can't with
>> libata.
> 
> 
> Okay, I dusted off one of my old (actually, I believe *the oldest*)
> Zip100 drives in the collection, and tried it out here with both
> 2.6.20 and 2.6.21-rc3-git9.   It works mostly fine with each.
> 
> A couple of minor issues, though.
> 
> (1) When ejecting a disk, either with the "eject /dev/sdc" command
> or using the front-panel soft-eject button on the drive,
> I get the following in syslog from libata:
> 
> sdc: Spinning up disk...<3>ata4.00: exception Emask 0x0 SAct 0x0 SErr
> 0x0 action 0x2
>         res 00/00:03:00:00:20/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
> ata4: soft resetting port
> ATA: abnormal status 0x7F on port 0x00010177
> ATA: abnormal status 0x7F on port 0x00010177
> ata4.00: configured for PIO2
> ata4: EH complete

The device status of 0x00 looks strange.
Could you please apply the attached debugging patch for 
clue about what caused the HSM violation, thanks.

> 
> 
> (2) The above log says PIO2, but the IDENTIFY data for this drive,
> which I had to patch the kernel to get (ATAPI ATA_16 support),
> indicates max PIO0 for this unit.  I suppose maybe the chipset
> doesn't go that low, but no big deal since IORDY handshakes it anyway.
> 

I saw this strange behavior, too.
The Promise BIOS identified my zip 100 drive as "PIO 0" during boot,
but libata identified it as "PIO2":

ata4.00: ATAPI, max PIO2, CDB intr
ata4.00: configured for PIO2

--
albert

--- linux-2.6.20.3/drivers/ata/libata-core.c	2007-03-15 12:13:12.000000000 +0800
+++ linux-2.6.20.3-mod/drivers/ata/libata-core.c	2007-03-15 12:13:55.000000000 +0800
@@ -4371,8 +4371,9 @@ int ata_hsm_move(struct ata_port *ap, st
 	WARN_ON(in_wq != ata_hsm_ok_in_wq(ap, qc));
 
 fsm_start:
-	DPRINTK("ata%u: protocol %d task_state %d (dev_stat 0x%X)\n",
-		ap->id, qc->tf.protocol, ap->hsm_task_state, status);
+	if (is_atapi_taskfile(&qc->tf))
+		printk(KERN_ERR "ata%u: protocol %d task_state %d (dev_stat 0x%X)\n",
+		       ap->id, qc->tf.protocol, ap->hsm_task_state, status);
 
 	switch (ap->hsm_task_state) {
 	case HSM_ST_FIRST:
@@ -5091,8 +5092,9 @@ inline unsigned int ata_host_intr (struc
 	struct ata_eh_info *ehi = &ap->eh_info;
 	u8 status, host_stat = 0;
 
-	VPRINTK("ata%u: protocol %d task_state %d\n",
-		ap->id, qc->tf.protocol, ap->hsm_task_state);
+	if (is_atapi_taskfile(&qc->tf))
+		printk(KERN_ERR "ata%u: protocol %d task_state %d\n",
+		       ap->id, qc->tf.protocol, ap->hsm_task_state);
 
 	/* Check whether we are expecting interrupt in this state */
 	switch (ap->hsm_task_state) {

Re: IOMEGA IDE ZIP (ATAPI) drive

[Mark Lord]

Albert Lee wrote:
> Mark Lord wrote:
>..
>> (1) When ejecting a disk, either with the "eject /dev/sdc" command
>> or using the front-panel soft-eject button on the drive,
>> I get the following in syslog from libata:
>>
>> sdc: Spinning up disk...<3>ata4.00: exception Emask 0x0 SAct 0x0 SErr
>> 0x0 action 0x2
>>         res 00/00:03:00:00:20/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
>> ata4: soft resetting port
>> ATA: abnormal status 0x7F on port 0x00010177
>> ATA: abnormal status 0x7F on port 0x00010177
>> ata4.00: configured for PIO2
>> ata4: EH complete
> 
> The device status of 0x00 looks strange.

Not to me.  The device likely generated an unsolicitied interrupt,
and status==0x00 is correct for a few seconds here:  the drive is
not busy with a command, not in an error state, and not ready
for a new command since it is busy ejecting a disc.

> Could you please apply the attached debugging patch for 
> clue about what caused the HSM violation, thanks.

I'll unpack the drive and hook it up again.

Cheers

Re: IOMEGA IDE ZIP (ATAPI) drive

[Mark Lord]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

Albert Lee wrote:
> Could you please apply the attached debugging patch for 
> clue about what caused the HSM violation, thanks.

I had to edit the patch to get it to apply on 2.6.21-rc3-git9,
but here (attached) is the output from syslog.

zip_insert.txt :: response to inserting a disc into the drive.
zip_button.txt :: response to pressing the eject button.
zip_eject.txt  :: response to using "eject /dev/sdc".

Enjoy!


[-- Attachment #2: zip_button.txt --]
[-- Type: text/plain, Size: 421 bytes --]

11:08:57: sdc: Spinning up disk...<3>ata port 1: protocol 6 task_state 4
11:08:57:          res 00/00:03:00:00:20/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
11:08:57: ata4: soft resetting port
11:08:57: ATA: abnormal status 0x7F on port 0x00010177
11:08:57: ATA: abnormal status 0x7F on port 0x00010177
11:08:58: ata4.00: configured for PIO2
11:08:58: ata4: EH complete
11:08:58: .<3>ata port 1: protocol 6 task_state 4

[-- Attachment #3: zip_eject.txt --]
[-- Type: text/plain, Size: 494 bytes --]

11:09:55: sdc: Spinning up disk...<3>ata port 1: protocol 6 task_state 4
11:09:55:          res 00/00:03:00:00:20/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
11:09:55: ata4: soft resetting port
11:09:55: ATA: abnormal status 0x7F on port 0x00010177
11:09:55: ATA: abnormal status 0x7F on port 0x00010177
11:09:56: ata4.00: configured for PIO2
11:09:56: ata4: EH complete
11:09:56: sdc: Spinning up disk...<3>ata port 1: protocol 6 task_state 4
11:09:57: .<3>ata port 1: protocol 6 task_state 4

[-- Attachment #4: zip_insert.txt --]
[-- Type: text/plain, Size: 1454 bytes --]

11:07:19: sdc: Spinning up disk...<3>ata port 1: protocol 6 task_state 4
11:07:19:          res 00/00:03:00:00:20/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
11:07:19: ata4: soft resetting port
11:07:19: ATA: abnormal status 0x7F on port 0x00010177
11:07:19: ATA: abnormal status 0x7F on port 0x00010177
11:07:19: ata4.00: configured for PIO2
11:07:19: ata4: EH complete
11:07:20: sdc: Spinning up disk...<3>ata port 1: protocol 6 task_state 4
11:07:20:          res 00/00:03:00:00:20/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
11:07:20: ata4: soft resetting port
11:07:20: ATA: abnormal status 0x7F on port 0x00010177
11:07:20: ATA: abnormal status 0x7F on port 0x00010177
11:07:21: .<6>ata4.00: configured for PIO2
11:07:21: ata4: EH complete
11:07:21: ready
11:07:21: SCSI device sdc: 196608 512-byte hdwr sectors (101 MB)
11:07:21: sdc: Write Protect is off
11:07:21: sdc: cache data unavailable
11:07:21: SCSI device sdc: 196608 512-byte hdwr sectors (101 MB)
11:07:21: sdc: Write Protect is off
11:07:21: sdc: cache data unavailable
11:07:21:  sdc:<3>ata port 1: protocol 5 task_state 4
11:07:21:  sdc4
11:07:22: .<3>ata port 1: protocol 6 task_state 4
11:07:22: ready
11:07:22: SCSI device sdc: 196608 512-byte hdwr sectors (101 MB)
11:07:22: sdc: Write Protect is off
11:07:22: sdc: cache data unavailable
11:07:22: SCSI device sdc: 196608 512-byte hdwr sectors (101 MB)
11:07:22: sdc: Write Protect is off
11:07:22: sdc: cache data unavailable

Re: IOMEGA IDE ZIP (ATAPI) drive

[Albert Lee]

Mark Lord wrote:
> Albert Lee wrote:
> 
>> Could you please apply the attached debugging patch for clue about
>> what caused the HSM violation, thanks.
> 
> 
> I had to edit the patch to get it to apply on 2.6.21-rc3-git9,
> but here (attached) is the output from syslog.
> 
> zip_insert.txt :: response to inserting a disc into the drive.
> zip_button.txt :: response to pressing the eject button.
> zip_eject.txt  :: response to using "eject /dev/sdc".
> 
> Enjoy!
> 
> 
> ------------------------------------------------------------------------
> 
> 11:08:57: sdc: Spinning up disk...<3>ata port 1: protocol 6 task_state 4
> 11:08:57:          res 00/00:03:00:00:20/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
> 11:08:57: ata4: soft resetting port
> 11:08:57: ATA: abnormal status 0x7F on port 0x00010177
> 11:08:57: ATA: abnormal status 0x7F on port 0x00010177
> 11:08:58: ata4.00: configured for PIO2
> 11:08:58: ata4: EH complete

Thanks for this good clue.

<3>ata port 1: protocol 6 task_state 4
11:08:57:          res 00/00:03:00:00:20/00:00:00:00:00/a0 Emask 0x2 (HSM violation)

>From the trace, the zip 100 drive clears BSY and raises irq to tell libata
when it is ready to transfer the CDB. However, the DRQ is not set yet. The status
0x00 causes libata HSM violation.

Maybe we can wait a moment and give the slow ATAPI devices some time to set DRQ.
Could you please try if the attached patch works, thanks.
--
albert

--- linux-2.6.20.3/drivers/ata/libata-core.c	2007-03-15 18:03:27.000000000 +0800
+++ linux-2.6.20.3-mod2/drivers/ata/libata-core.c	2007-03-17 01:12:53.000000000 +0800
@@ -4384,6 +4384,19 @@ fsm_start:
 		 */
 		poll_next = (qc->tf.flags & ATA_TFLAG_POLLING);
 
+		/* wait for some slow ATAPI devices to set DRQ */
+		if (unlikely((status & ATA_DRQ) == 0) &&
+		    is_atapi_taskfile(&qc->tf)) {
+			int max = 100;
+
+			do {
+				udelay(10);
+				status = ata_chk_status(ap);
+				max--;
+				ata_port_printk(ap, KERN_ERR, "wait for DRQ %d\n", 100-max);	
+			} while (((status & ATA_DRQ) == 0) && (max > 0));
+		}
+
 		/* check device status */
 		if (unlikely((status & ATA_DRQ) == 0)) {
 			/* handle BSY=0, DRQ=0 as error */

Re: IOMEGA IDE ZIP (ATAPI) drive

[Mark Lord]

Albert Lee wrote:
>..
> Maybe we can wait a moment and give the slow ATAPI devices some time to set DRQ.
> Could you please try if the attached patch works, thanks.
> --
> albert
> 
> --- linux-2.6.20.3/drivers/ata/libata-core.c	2007-03-15 18:03:27.000000000 +0800
> +++ linux-2.6.20.3-mod2/drivers/ata/libata-core.c	2007-03-17 01:12:53.000000000 +0800
> @@ -4384,6 +4384,19 @@ fsm_start:
>  		 */
>  		poll_next = (qc->tf.flags & ATA_TFLAG_POLLING);
>  
> +		/* wait for some slow ATAPI devices to set DRQ */
> +		if (unlikely((status & ATA_DRQ) == 0) &&
> +		    is_atapi_taskfile(&qc->tf)) {
> +			int max = 100;
> +
> +			do {
> +				udelay(10);
> +				status = ata_chk_status(ap);
> +				max--;
> +				ata_port_printk(ap, KERN_ERR, "wait for DRQ %d\n", 100-max);	
> +			} while (((status & ATA_DRQ) == 0) && (max > 0));
> +		}
> +
>  		/* check device status */
>  		if (unlikely((status & ATA_DRQ) == 0)) {
>  			/* handle BSY=0, DRQ=0 as error */
> 

I patched the above in, and it was NEVER hit.

-ml

Re: IOMEGA IDE ZIP (ATAPI) drive

[Albert Lee]

Mark Lord wrote:
> Albert Lee wrote:
> 
>> ..
>> Maybe we can wait a moment and give the slow ATAPI devices some time
>> to set DRQ.
>> Could you please try if the attached patch works, thanks.
>> -- 
>> albert
>>
>> --- linux-2.6.20.3/drivers/ata/libata-core.c    2007-03-15
>> 18:03:27.000000000 +0800
>> +++ linux-2.6.20.3-mod2/drivers/ata/libata-core.c    2007-03-17
>> 01:12:53.000000000 +0800
>> @@ -4384,6 +4384,19 @@ fsm_start:
>>           */
>>          poll_next = (qc->tf.flags & ATA_TFLAG_POLLING);
>>  
>> +        /* wait for some slow ATAPI devices to set DRQ */
>> +        if (unlikely((status & ATA_DRQ) == 0) &&
>> +            is_atapi_taskfile(&qc->tf)) {
>> +            int max = 100;
>> +
>> +            do {
>> +                udelay(10);
>> +                status = ata_chk_status(ap);
>> +                max--;
>> +                ata_port_printk(ap, KERN_ERR, "wait for DRQ %d\n",
>> 100-max);   
>> +            } while (((status & ATA_DRQ) == 0) && (max > 0));
>> +        }
>> +
>>          /* check device status */
>>          if (unlikely((status & ATA_DRQ) == 0)) {
>>              /* handle BSY=0, DRQ=0 as error */
>>
> 
> I patched the above in, and it was NEVER hit.

Do you mean no "wait for DRQ" messages at all?
Is the HSM violation still seen?

--
albert

Re: IOMEGA IDE ZIP (ATAPI) drive

[Mark Lord]

Albert Lee wrote:
> Mark Lord wrote:
>..
>> I patched the above in, and it was NEVER hit.
> 
> Do you mean no "wait for DRQ" messages at all?
> Is the HSM violation still seen?

The code you sent me to patch in was never hit.
The "wait for DRQ" message therefore never gets output.
The exact same set of HSM violation messages still appear.

Of course this makes perfect sense -- the HSM messages
are not being generated in response to any command,
but rather in response to ejecting a disk -- which I think
causes the drive to generate an unsolicited event.

Cheers

Re: IOMEGA IDE ZIP (ATAPI) drive

[Albert Lee]

Mark Lord wrote:
> Albert Lee wrote:
> 
>> Mark Lord wrote:
>> ..
>>
>>> I patched the above in, and it was NEVER hit.
>>
>>
>> Do you mean no "wait for DRQ" messages at all?
>> Is the HSM violation still seen?
> 
> 
> The code you sent me to patch in was never hit.
> The "wait for DRQ" message therefore never gets output.
> The exact same set of HSM violation messages still appear.
> 
> Of course this makes perfect sense -- the HSM messages
> are not being generated in response to any command,
> but rather in response to ejecting a disk -- which I think
> causes the drive to generate an unsolicited event.
> 

Hi Mark,

Could you please apply the attached debug patch (against 2.6.21-rc4).
(BTW, the zip 100 must be connected to ata4.)
Hopefully we could have more clue about the HSM violation.

--
thanks,

albert


diff -Nrup linux-2.6.21-rc4/drivers/ata/libata-core.c linux-2.6.21-rc4-mod/drivers/ata/libata-core.c
--- linux-2.6.21-rc4/drivers/ata/libata-core.c	2007-03-16 08:20:01.000000000 +0800
+++ linux-2.6.21-rc4-mod/drivers/ata/libata-core.c	2007-03-20 18:04:15.000000000 +0800
@@ -4350,8 +4350,9 @@ int ata_hsm_move(struct ata_port *ap, st
 	WARN_ON(in_wq != ata_hsm_ok_in_wq(ap, qc));
 
 fsm_start:
-	DPRINTK("ata%u: protocol %d task_state %d (dev_stat 0x%X)\n",
-		ap->print_id, qc->tf.protocol, ap->hsm_task_state, status);
+	if (ap->print_id == 4)
+		printk(KERN_ERR "ata%u: protocol %d task_state %d (dev_stat 0x%X)\n",
+		       ap->print_id, qc->tf.protocol, ap->hsm_task_state, status);
 
 	switch (ap->hsm_task_state) {
 	case HSM_ST_FIRST:
@@ -5071,8 +5072,14 @@ inline unsigned int ata_host_intr (struc
 	struct ata_eh_info *ehi = &ap->eh_info;
 	u8 status, host_stat = 0;
 
-	VPRINTK("ata%u: protocol %d task_state %d\n",
-		ap->print_id, qc->tf.protocol, ap->hsm_task_state);
+	if (ap->print_id == 4) {
+		printk(KERN_ERR "ata%u: protocol %d task_state %d\n",
+		       ap->print_id, qc->tf.protocol, ap->hsm_task_state);
+
+		host_stat = ap->ops->bmdma_status(ap);
+		printk(KERN_ERR "ata%u: host_stat 0x%X\n", ap->print_id, host_stat);
+	}
+
 
 	/* Check whether we are expecting interrupt in this state */
 	switch (ap->hsm_task_state) {
@@ -5118,11 +5125,17 @@ inline unsigned int ata_host_intr (struc
 
 	/* check altstatus */
 	status = ata_altstatus(ap);
+	if (ap->print_id == 4)
+		printk(KERN_ERR "ata%u: dev_altstatus 0x%X\n",
+		       ap->print_id, status);
 	if (status & ATA_BUSY)
 		goto idle_irq;
 
 	/* check main status, clearing INTRQ */
 	status = ata_chk_status(ap);
+	if (ap->print_id == 4)
+		printk(KERN_ERR "ata%u: dev_status 0x%X\n",
+		       ap->print_id, status);
 	if (unlikely(status & ATA_BUSY))
 		goto idle_irq;
 
diff -Nrup linux-2.6.21-rc4/drivers/ata/libata-scsi.c linux-2.6.21-rc4-mod/drivers/ata/libata-scsi.c
--- linux-2.6.21-rc4/drivers/ata/libata-scsi.c	2007-03-16 08:20:01.000000000 +0800
+++ linux-2.6.21-rc4-mod/drivers/ata/libata-scsi.c	2007-03-20 18:05:38.000000000 +0800
@@ -2773,17 +2773,17 @@ static inline ata_xlat_func_t ata_get_xl
 static inline void ata_scsi_dump_cdb(struct ata_port *ap,
 				     struct scsi_cmnd *cmd)
 {
-#ifdef ATA_DEBUG
 	struct scsi_device *scsidev = cmd->device;
 	u8 *scsicmd = cmd->cmnd;
 
-	DPRINTK("CDB (%u:%d,%d,%d) %02x %02x %02x %02x %02x %02x %02x %02x %02x\n",
-		ap->print_id,
-		scsidev->channel, scsidev->id, scsidev->lun,
-		scsicmd[0], scsicmd[1], scsicmd[2], scsicmd[3],
-		scsicmd[4], scsicmd[5], scsicmd[6], scsicmd[7],
-		scsicmd[8]);
-#endif
+	if (ap->print_id == 4) {
+		printk(KERN_ERR "CDB (%u:%d,%d,%d) %02x %02x %02x %02x %02x %02x %02x %02x %02x\n",
+		       ap->print_id,
+		       scsidev->channel, scsidev->id, scsidev->lun,
+		       scsicmd[0], scsicmd[1], scsicmd[2], scsicmd[3],
+		       scsicmd[4], scsicmd[5], scsicmd[6], scsicmd[7],
+		       scsicmd[8]);
+	}
 }
 
 static inline int __ata_scsi_queuecmd(struct scsi_cmnd *scmd,

Re: regression: ide-floppy doesn't work with IOMEGA IDE ZIP drive

[Jeff Garzik]

Mark Lord wrote:
> Tejun wrote:
>> If that's the case, libata should work too as long as the HSM problem is
>> fixed.
> 
> Really?  I didn't notice when libata gained ATAPI-disk support.

ATAPI just passes through to SCSI.  There is no limitation on the 
peripheral device types supported, except in the SCSI midlayer itself.

Some rare ATAPI devices are even pure SCSI bridges, allowing you to hook 
up any SCSI-2 device to the bridge, and in turn, to any ATA/ATAPI 
controller.

	Jeff

Re: regression: ide-floppy doesn't work with IOMEGA IDE ZIP drive

[Bartlomiej Zolnierkiewicz]

On Wednesday 14 March 2007, Stanislav Brabec wrote:
> Albert Lee wrote:
> > Tejun Heo wrote:
> 
> > > Hmmm... weird.  Your drive bears the same model name as Stanislav's.  I
> > > don't think the low level driver is causing the difference.  They both
> > > use the standard libata HSM implementation.  Any ideas?  Stanislav, can
> > > you try to connect that zip drive to another IDE controller?
> 
> > Maybe it's also worth a try to replace the medium, cable or even the
> > drive itself to rule out the possibility of hardware problem.
> 
> I'll try it. I cannot replace the drive, I don't have any spare one, but
> my colleague has. He will try it on his machine. So let's wait for
> result.
> 
> Looking at the syslog in Novell bug 232086 in detail, following line may
> indicate hardware failure:
> usb 5-1: string descriptor 0 read error: -22
> 
> My drive is a slave on bus, where master is a modern Seagate ST3160812A.
> 
> On my system I see two regressions:
> - One between year 2002 kernels and SuSE Linux 10.0:
>   Delay with "packet command initiated yet DRQ isn't asserted" before
>   first read access, then the read will succeed.
>   I did not yet reproduce this regression just now on my hardware.
> - Second between SuSE 10.1 and 10.2:
>   Delay with "packet command initiated yet DRQ isn't asserted" before
>   any attempt to access, then it will fail.
>   This regression is reproducible just now on my hardware, but still may
>   be caused by hardware problems raised by a slightly different
>   initialization order.

It is reproduceable, SuSE 10.1 kernel is "good" and SuSE 10.2 is "bad".
So even if this is caused by some hardware problems or different
initialization order git-bisect on 2.6.16-2.6.20 should tell us what
change caused the problem.

PS Tejun, I praise efforts to make ATA floppy drives work with libata
but this is IMO a _future_ work (won't help et all for existing
systems/distributions) and we need to have ide-floppy fixed _now_.

Bart

> Tejun Heo wrote:
> > [libata]
> > And, as the device requires custom high level driver, libata fails
> > miserably.  Would it be worth to try support these devices?  Or are
> > they just too outdated to put the effort in?
> 
> As far as I remember, it was working without any special driver with
> ide-scsi.
> 
> -- 
> Best Regards,
> 
> Stanislav Brabec
> software developer
> ---------------------------------------------------------------------
> SUSE LINUX, s. r. o.                          e-mail: sbrabec@suse.cz
> Lihovarska 1060/12                            tel: +420 284 028 966
> 190 00 Praha 9                                fax: +420 284 028 951
> Czech Republic                                http://www.suse.cz/

Re: regression: ide-floppy doesn't work with IOMEGA IDE ZIP drive

[Tejun Heo]

Bartlomiej Zolnierkiewicz wrote:
>> My drive is a slave on bus, where master is a modern Seagate ST3160812A.
>>
>> On my system I see two regressions:
>> - One between year 2002 kernels and SuSE Linux 10.0:
>>   Delay with "packet command initiated yet DRQ isn't asserted" before
>>   first read access, then the read will succeed.
>>   I did not yet reproduce this regression just now on my hardware.
>> - Second between SuSE 10.1 and 10.2:
>>   Delay with "packet command initiated yet DRQ isn't asserted" before
>>   any attempt to access, then it will fail.
>>   This regression is reproducible just now on my hardware, but still may
>>   be caused by hardware problems raised by a slightly different
>>   initialization order.
> 
> It is reproduceable, SuSE 10.1 kernel is "good" and SuSE 10.2 is "bad".
> So even if this is caused by some hardware problems or different
> initialization order git-bisect on 2.6.16-2.6.20 should tell us what
> change caused the problem.
> 
> PS Tejun, I praise efforts to make ATA floppy drives work with libata
> but this is IMO a _future_ work (won't help et all for existing
> systems/distributions) and we need to have ide-floppy fixed _now_.

Yeap, agreed but I think getting more info on the libata HSM violation
can help diagnosing ide problem too.  Anyways, Stanislav, can you bisect
as Bartlomiej requested?

-- 
tejun

Re: regression: ide-floppy doesn't work with IOMEGA IDE ZIP drive

[Mark Lord]

Tejun Heo wrote:
> 
> Yeap, agreed but I think getting more info on the libata HSM violation
> can help diagnosing ide problem too.  Anyways, Stanislav, can you bisect
> as Bartlomiej requested?
> 

Tejun, do you have a Zip100 (ATAPI) drive to play with there?

Cheers

Re: regression: ide-floppy doesn't work with IOMEGA IDE ZIP drive

[Tejun Heo]

Mark Lord wrote:
> Tejun Heo wrote:
>>
>> Yeap, agreed but I think getting more info on the libata HSM violation
>> can help diagnosing ide problem too.  Anyways, Stanislav, can you bisect
>> as Bartlomiej requested?
>>
> 
> Tejun, do you have a Zip100 (ATAPI) drive to play with there?

Nope.  Do you happen to have a spare one?

-- 
tejun

Re: regression: ide-floppy doesn't work with IOMEGA IDE ZIP drive

[Stanislav Brabec]

Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 14 March 2007, Stanislav Brabec wrote:
> > Albert Lee wrote:
> > > Tejun Heo wrote:
> > 
> > > > Hmmm... weird.  Your drive bears the same model name as Stanislav's.  I
> > > > don't think the low level driver is causing the difference.  They both
> > > > use the standard libata HSM implementation.  Any ideas?  Stanislav, can
> > > > you try to connect that zip drive to another IDE controller?
> > 
> > > Maybe it's also worth a try to replace the medium, cable or even the
> > > drive itself to rule out the possibility of hardware problem.
> > 
> > I'll try it. I cannot replace the drive, I don't have any spare one, but
> > my colleague has. He will try it on his machine. So let's wait for
> > result.
> > 
> > Looking at the syslog in Novell bug 232086 in detail, following line may
> > indicate hardware failure:
> > usb 5-1: string descriptor 0 read error: -22
> > 
> > My drive is a slave on bus, where master is a modern Seagate ST3160812A.
> > 
> > On my system I see two regressions:

> 
> It is reproduceable, SuSE 10.1 kernel is "good" and SuSE 10.2 is "bad".
> So even if this is caused by some hardware problems or different
> initialization order git-bisect on 2.6.16-2.6.20 should tell us what
> change caused the problem.

After more kernels testing I am inclined to suspect broken hardware.

2.4.20 (SuSE 8.1) and newer kernels  exhibits this "DRQ isn't asserted"
error. The latest kernel working without any problem is five years old
2.4.18 (SuSE 8.0).

In some older systems the delay was "hidden" somewhere in the boot
process, now userspace processes repeatedly scan all media, which makes
delay permanent.

-- 
Best Regards,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec@suse.cz
Lihovarska 1060/12                            tel: +420 284 028 966
190 00 Praha 9                                fax: +420 284 028 951
Czech Republic                                http://www.suse.cz/

Re: regression: ide-floppy doesn't work with IOMEGA IDE ZIP drive

[Albert Lee]

Stanislav Brabec wrote:
> Bartlomiej Zolnierkiewicz wrote:
> 
>>On Wednesday 14 March 2007, Stanislav Brabec wrote:
>>
>>>Albert Lee wrote:
>>>
>>>>Tejun Heo wrote:
>>>
>>>>>Hmmm... weird.  Your drive bears the same model name as Stanislav's.  I
>>>>>don't think the low level driver is causing the difference.  They both
>>>>>use the standard libata HSM implementation.  Any ideas?  Stanislav, can
>>>>>you try to connect that zip drive to another IDE controller?
>>>
>>>>Maybe it's also worth a try to replace the medium, cable or even the
>>>>drive itself to rule out the possibility of hardware problem.
>>>
>>>I'll try it. I cannot replace the drive, I don't have any spare one, but
>>>my colleague has. He will try it on his machine. So let's wait for
>>>result.
>>>
>>>Looking at the syslog in Novell bug 232086 in detail, following line may
>>>indicate hardware failure:
>>>usb 5-1: string descriptor 0 read error: -22
>>>
>>>My drive is a slave on bus, where master is a modern Seagate ST3160812A.
>>>
>>>On my system I see two regressions:
> 
> 
>>It is reproduceable, SuSE 10.1 kernel is "good" and SuSE 10.2 is "bad".
>>So even if this is caused by some hardware problems or different
>>initialization order git-bisect on 2.6.16-2.6.20 should tell us what
>>change caused the problem.
> 
> 
> After more kernels testing I am inclined to suspect broken hardware.
> 
> 2.4.20 (SuSE 8.1) and newer kernels  exhibits this "DRQ isn't asserted"
> error. The latest kernel working without any problem is five years old
> 2.4.18 (SuSE 8.0).
> 
> In some older systems the delay was "hidden" somewhere in the boot
> process, now userspace processes repeatedly scan all media, which makes
> delay permanent.
> 

Hi Stanislav,

Could you apply the attached HSM debug patch and post the dmesg, thanks.
(Hopefully we can get some clue from the HSM trace.)

--
albert

--- linux-2.6.20.3/drivers/ata/libata-core.c	2007-03-15 12:13:12.000000000 +0800
+++ linux-2.6.20.3-mod/drivers/ata/libata-core.c	2007-03-15 12:13:55.000000000 +0800
@@ -4371,8 +4371,9 @@ int ata_hsm_move(struct ata_port *ap, st
 	WARN_ON(in_wq != ata_hsm_ok_in_wq(ap, qc));
 
 fsm_start:
-	DPRINTK("ata%u: protocol %d task_state %d (dev_stat 0x%X)\n",
-		ap->id, qc->tf.protocol, ap->hsm_task_state, status);
+	if (is_atapi_taskfile(&qc->tf))
+		printk(KERN_ERR "ata%u: protocol %d task_state %d (dev_stat 0x%X)\n",
+		       ap->id, qc->tf.protocol, ap->hsm_task_state, status);
 
 	switch (ap->hsm_task_state) {
 	case HSM_ST_FIRST:
@@ -5091,8 +5092,9 @@ inline unsigned int ata_host_intr (struc
 	struct ata_eh_info *ehi = &ap->eh_info;
 	u8 status, host_stat = 0;
 
-	VPRINTK("ata%u: protocol %d task_state %d\n",
-		ap->id, qc->tf.protocol, ap->hsm_task_state);
+	if (is_atapi_taskfile(&qc->tf))
+		printk(KERN_ERR "ata%u: protocol %d task_state %d\n",
+		       ap->id, qc->tf.protocol, ap->hsm_task_state);
 
 	/* Check whether we are expecting interrupt in this state */
 	switch (ap->hsm_task_state) {

Re: regression: ide-floppy doesn't work with IOMEGA IDE ZIP drive

[Bartlomiej Zolnierkiewicz]

On Wednesday 14 March 2007, Stanislav Brabec wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 14 March 2007, Stanislav Brabec wrote:
> > > Albert Lee wrote:
> > > > Tejun Heo wrote:
> > > 
> > > > > Hmmm... weird.  Your drive bears the same model name as Stanislav's.  I
> > > > > don't think the low level driver is causing the difference.  They both
> > > > > use the standard libata HSM implementation.  Any ideas?  Stanislav, can
> > > > > you try to connect that zip drive to another IDE controller?
> > > 
> > > > Maybe it's also worth a try to replace the medium, cable or even the
> > > > drive itself to rule out the possibility of hardware problem.
> > > 
> > > I'll try it. I cannot replace the drive, I don't have any spare one, but
> > > my colleague has. He will try it on his machine. So let's wait for
> > > result.
> > > 
> > > Looking at the syslog in Novell bug 232086 in detail, following line may
> > > indicate hardware failure:
> > > usb 5-1: string descriptor 0 read error: -22
> > > 
> > > My drive is a slave on bus, where master is a modern Seagate ST3160812A.
> > > 
> > > On my system I see two regressions:
> 
> > 
> > It is reproduceable, SuSE 10.1 kernel is "good" and SuSE 10.2 is "bad".
> > So even if this is caused by some hardware problems or different
> > initialization order git-bisect on 2.6.16-2.6.20 should tell us what
> > change caused the problem.
> 
> After more kernels testing I am inclined to suspect broken hardware.
> 
> 2.4.20 (SuSE 8.1) and newer kernels  exhibits this "DRQ isn't asserted"
> error. The latest kernel working without any problem is five years old
> 2.4.18 (SuSE 8.0).
> 
> In some older systems the delay was "hidden" somewhere in the boot
> process, now userspace processes repeatedly scan all media, which makes
> delay permanent.

I'm lost, weren't you saying that there are two problems actually:

* "DRQ isn't asserted" one which has always been there (but ide-floppy works)

* the 2.6.16->2.6.20 (SuSE 10.1->10.2) regression (ide-floppy doesn't work)

?

Bart