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

[dobrev <dobrev666@prostak.org>]

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