Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Patrick Wildi]

On Wed, 12 May 2004, dobrev wrote:

>
>
> Bartlomiej Zolnierkiewicz wrote:
>
> >On Tuesday 11 of May 2004 18:10, dobrev wrote:
> >
> >
> >>Craig Bradney wrote:
> >>
> >>
> >>>On Tue, 2004-05-11 at 13:24, Rene Herman wrote:
> >>>
> >>>
> >>>>Bartlomiej Zolnierkiewicz wrote:
> >>>>
> >>>>
> >>>>>Rene, can you send me copies of /proc/ide/hda/identify and
> >>>>>/proc/ide/hdc/identify?
> >>>>>
> >>>>>
> >>>>Sure, attached. Quite sure you wanted hdc though? That's a DVD-ROM.
> >>>>
> >>>>
> >>>>
> >>>>>I still would like to know why these drives don't accept flush cache
> >>>>>commands (or it is a driver's bug?).
> >>>>>
> >>>>>
> >>>>No idea I'm afraid. Seems at least new Maxtor drives are affected. Both
> >>>>the "120P0" (120G, 8M cache) and "L0" (120G, 2M cache) were reported in
> >>>>this thread.
> >>>>
> >>>>
> >>>At a guess the 80P0 drives will also be affected (80G, 8mb cache), but
> >>>as yet I havent tried 2.6.6 on the boxes with them. Tonight if theres
> >>>time.
> >>>
> >>>Craig
> >>>
> >>>
> >>I have Maxtor 6Y060L0 and is also affected. Now I am with 2.6.5.
> >>
> >>
> >
> >Please see http://bugme.osdl.org/show_bug.cgi?id=2672
> >
> >
>
> Yes, I know.
>
> >
> >
> >>SvrWks IDE controller also have problems with 2.6.6 because the drive
> >>works in mdma2 mode.
> >>When in 2.6.5 the transfer mode is udma2.
> >>
> >>
> >
> >UDMA2 on OSB4?  Weird.
> >
> >from serverwoks.c:
> >
> >	/* If we are about to put a disk into UDMA mode we screwed up.
> >	   Our code assumes we never _ever_ do this on an OSB4 */
> >
> >	if(dev->device == PCI_DEVICE_ID_SERVERWORKS_OSB4 &&
> >		drive->media == ide_disk && speed >= XFER_UDMA_0)
> >			BUG();
> >
> >I need more data: .config (2.6.5/2.6.6) and full dmesg output (2.6.5/2.6.6).
> >
> >
>
> Yes, it's a OSB4.
> I attached files you need. .config is the same.
> The problem is that when in 2.6.6 hdparm  reports that the drive is much
> slower than 2.6.5
> 2.6.6 => 13 MB/s
> 2.6.5 => 23 MB/s
> When I  remove the code related to serverworks.c (see bellow) in
> patch-2.6.6 transfer is like 2.6.5.

I believe what happens, is that with the old logic UDMA disks on
OSB4 "fell through the cracks" in svwks_config_drive_xfer_rate().
It was basically a noop (unintentionally) and the settings were
left at whatever BIOS set them to.
Looking through some old threads, it looks like UDMA was considered
not safe on an OSB4.

Patrick

> >
> >
> >>Probably because of this (from patch-2.6.6):
> >>diff -Nru a/drivers/ide/pci/serverworks.c b/drivers/ide/pci/serverworks.c
> >>--- a/drivers/ide/pci/serverworks.c     Sun May  9 19:33:36 2004
> >>+++ b/drivers/ide/pci/serverworks.c     Sun May  9 19:33:36 2004
> >>@@ -472,7 +472,9 @@
> >>                                int dma = config_chipset_for_dma(drive);
> >>                                if ((id->field_valid & 2) && !dma)
> >>                                        goto try_dma_modes;
> >>-                       }
> >>+                       } else
> >>+                               /* UDMA disabled by mask, try other DMA
> >>modes */+                               goto try_dma_modes;
> >>                } else if (id->field_valid & 2) {
> >> try_dma_modes:
> >>                        if ((id->dma_mword & hwif->mwdma_mask) ||
> >>
> >>
>
>
>
>
>
-
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/