Re: DriveReady SeekComplete Error

[Jens Axboe]

On Fri, Jun 04 2004, Bartlomiej Zolnierkiewicz wrote:
> On Friday 04 of June 2004 13:56, Jens Axboe wrote:
> > On Fri, Jun 04 2004, Bartlomiej Zolnierkiewicz wrote:
> > > On Friday 04 of June 2004 12:22, Jens Axboe wrote:
> > > > damnit, don't trim the cc list!
> > > >
> > > > On Fri, Jun 04 2004, mattia wrote:
> > > > > I have the following error (kernel 2.6.6):
> > > > >
> > > > > Jun  4 08:05:43 blink kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> > > > > Jun  4 08:05:43 blink kernel: hdc: Maxtor 6Y160P0, ATA DISK drive
> > > > > Jun  4 08:05:43 blink kernel: hdd: Maxtor 6Y120L0, ATA DISK drive
> > > > > Jun  4 08:05:43 blink kernel: ide1 at 0x170-0x177,0x376 on irq 15
> > > > > Jun  4 08:05:43 blink kernel: hda: max request size: 128KiB
> > > > > Jun  4 08:05:43 blink kernel: hda: 78177792 sectors (40027 MB)
> > > > > w/1819KiB Cache, CHS=65535/16/63, UDMA(100)
> > > > > Jun  4 08:05:43 blink kernel:  hda: hda1 hda2 hda3
> > > > > Jun  4 08:05:43 blink kernel: hdc: max request size: 1024KiB
> > > > > Jun  4 08:05:43 blink kernel: hdc: 320173056 sectors (163928 MB)
> > > > > w/7936KiB Cache, CHS=19929/255/63, UDMA(100)
> > > > > Jun  4 08:05:43 blink kernel:  hdc: hdc1
> > > > > Jun  4 08:05:43 blink kernel: hdd: max request size: 128KiB
> > > > > Jun  4 08:05:43 blink kernel: hdd: 240121728 sectors (122942 MB)
> > > > > w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
> > > > > Jun  4 08:05:43 blink kernel:  hdd: hdd1 hdd2 hdd3
> > > > > Jun  4 08:05:43 blink kernel: hdd: task_no_data_intr: status=0x51 {
> > > > > DriveReady SeekComplete Error }
> > > > > Jun  4 08:05:43 blink kernel: hdd: task_no_data_intr: error=0x04 {
> > > > > DriveStatusError }
> > > > > Jun  4 08:05:43 blink kernel: hdd: Write Cache FAILED Flushing!
> > > > >
> > > > >
> > > > > I found somewhere that's something wrong with that maxtor drive.
> > > > > However, everything works fine.
> > > >
> > > > There's nothing wrong with the drive technically, it's just odd (lba48
> > > > without FLUSH_CACHE_EXT). It's really a linux ide bug that's fixed in
> > > > newer kernels. 2.6.7 will fix your problem.
> > >
> > > Wrong.
> > >
> > > Bug is a combination of a very minor firmware quirk
> > > and lack of strict checking in Linux IDE driver.
> > >
> > > FLUSH_CACHE_EXT bit is set but it is not supported
> > > (but it is not a problem because LBA48 is not supported also).
> >
> > Ah my bad, I didn't realize this bit was actually set correctly (you
> > mean (cfs_enable_2 & 0x2400) == 0x2400 is actually true?).
> 
> Yes but only on unaffected drives. ;-)
> 
> 0x2000 is FLUSH_CACHE_EXT support
> 0x0400 is LBA48 support
> 
> Affected drives have 0x2000 set incorrectly so we have to check also 0x0400.
> (== 0x2400 is needed because & 0x2400 is true if & 0x2000 OR if & 0x0400).
> 
> Everything is explained in the patch changelog:
> 
> | - many Maxtor disks incorrectly claim CACHE FLUSH EXT command support,
> |   fix it by checking both CACHE FLUSH EXT command and LBA48 support
> |   (thanks to Eric D. Mudama for help in fixing this)
> 
> and in the patch itself:
> 
> +/* some Maxtor disks have bit 13 defined incorrectly so check bit 10 too */
> +#define ide_id_has_flush_cache_ext(id)	\
> +	(((id)->cfs_enable_2 & 0x2400) == 0x2400)

Ok, so I didn't miss anything. Was just wondering because of your
comment on -mm2.

> > > It is fixed in 2.6.7-rc1 but your IDE barrier patch has this problem
> > > (just reminding you that it is still not fixed in 2.6.7-rc2-mm2).
> >
> > So where's the bug? I don't see it...
> 
> ide_fill_flush_cmd()
> 
> +	if (drive->id->cfs_enable_2 & 0x2400)
> +		rq->buffer[0] = WIN_FLUSH_CACHE_EXT;

Just checked a fresh copy of 2.6.7-rc2-mm2, and it has it correctly:

static void ide_fill_flush_cmd(ide_drive_t *drive, struct request *rq)
{
        char *buf = rq->cmd;

        /*
         * reuse cdb space for ata command
         */
        memset(buf, 0, sizeof(rq->cmd));

        rq->flags |= REQ_DRIVE_TASK | REQ_STARTED;
        rq->buffer = buf;
        rq->buffer[0] = WIN_FLUSH_CACHE;

        if (ide_id_has_flush_cache_ext(drive->id))
                rq->buffer[0] = WIN_FLUSH_CACHE_EXT;
}

So that's why I didn't follow what you meant, there should be no problem
here. You are reading disk-barrier-ide.patch, barrier-update.patch is
applied on top of that.

So we are back to step 1, why is his drive complaining. I'm guessing it
doesn't have write back caching enabled and aborts the flush on those
grounds - Ed, what is the output of hdparm -i on your booted system?

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/