On Tuesday 11 of May 2004 18:10, dobrev wrote:
Craig Bradney wrote:
On Tue, 2004-05-11 at 13:24, Rene Herman wrote:I have Maxtor 6Y060L0 and is also affected. Now I am with 2.6.5.
Bartlomiej Zolnierkiewicz wrote:At a guess the 80P0 drives will also be affected (80G, 8mb cache), but
Rene, can you send me copies of /proc/ide/hda/identify andSure, attached. Quite sure you wanted hdc though? That's a DVD-ROM.
/proc/ide/hdc/identify?
I still would like to know why these drives don't accept flush cacheNo idea I'm afraid. Seems at least new Maxtor drives are affected. Both
commands (or it is a driver's bug?).
the "120P0" (120G, 8M cache) and "L0" (120G, 2M cache) were reported in
this thread.
as yet I havent tried 2.6.6 on the boxes with them. Tonight if theres
time.
Craig
Please see http://bugme.osdl.org/show_bug.cgi?id=2672
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).
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) ||
Attachment:
attach.tar.gz
Description: Unix tar archive