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

[dobrev]

Patrick Wildi wrote:

> 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
>  
I agree, I think config_chipset_for_dma() was never entered before 2.6.6.
Transfer rate was udma2 and there were no problems. Same was with 2.4.
I don't know why OSB4 was concidered not to work in udma.
I have no problems for a long time and I want to use udma2.

>  
>
> > >      
> > >
> > > > 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/