Re: ide.2.4.1-p3.01112001.patch
On Mon, 15 Jan 2001, Albert Cranford wrote:
> I have a working PA-2007 but use a small hard disk. Can I help.
[...]
> Detected 239.833 MHz processor.
[...]
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[...]
> hda: WDC AC2540F, ATA DISK drive
> hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
> hda: set_drive_speed_status: error=0x04 { DriveStatusError }
> hda: 1056384 sectors (541 MB) w/64KiB Cache, CHS=524/32/63, DMA
I have a FIC PA-2007 (the older one, with a 586A bridge instead of the 586B
of later FIC PA-2007 boards), running at 75MHz FSB (PCI bus runs at 37.5MHz,
so I suppose I should use idebus=37.5 if I were to try 2.4.x), and a Quantum
Fireball lct15 30MB.
It works flawlessly in UDMA mode 2 (although I have to force the drive to
UDMA mode 2 with -X66 before enabling dma, because the bogus beta BIOS I use
sets it to UDMA4 which is not supported by the 586A). Kernel is 2.2.18,
without the 2.4.x ide backport.
The lspci output is exactly the same as yours.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
This sucks! I have had several systems with VIA chipsets and have never had any problems. Currently I am running a SOYO K6-2 system with UDMA 33 and a SOYO K-7 system with both UDMA-33 and UDMA-66 with not problems. How do we know that there is not some related hardware problem, (cable, power supply, etc ) with the systems that reported problems? What percentage of people are running OK VS those that are not? Now everybody with a VIA chipset is going to be punished! My $.02 Steve Vojtech Pavlik wrote: > On Fri, Jan 12, 2001 at 04:09:22PM -0800, Linus Torvalds wrote: > > > On Fri, 12 Jan 2001, Vojtech Pavlik wrote: > > > > > > However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets. > > > That's because all VIA chipsets starting from vt82c586 to vt82c686b > > > (UDMA100), share the same PCI ID. > > > > > > Would you prefer to filter just vt82c586 and vt82c586a as the comment in > > > Alan's code says or simply unconditionally kill autodma on all of VIA > > > chipsets, as Alan's code does? > > > > Right now, for 2.4.1, I'd rather have the patch to just do the same as > > 2.2.x. We can figure it out better when we get a better idea of exactly > > what the bug is, and whether there is some other work-around, and whether > > it is 100% certain that it is just those two controllers (maybe the other > > ones are buggy too, but the 2.2.x tests basically cured their symptoms too > > and peopl ehaven't reported them because they are "fixed"). > > > > Linus > > Ok, here goes the patch. > > Note that with this patch, all VIA users will get IDE transferrates > about 3 MB/sec as opposed to about 20 MB/sec without it (and with > UDMA66). > > This patch disables automatic DMA on all VIA chipsets, including the > ancient 82c561 for 486's, and up to the 686a UDMA66 chipset. > > Also note that enabling the DMA later with hdparm -X66 -d1 or similar > command is not safe, and usually works by pure luck on VIA chipsets. > This however, would need some non-minor changes to the generic code to > fix. > > But perhaps it's still worth ... > > -- > Vojtech Pavlik > SuSE Labs > > > >via-no-autodma.diffName: via-no-autodma.diff > Type: Plain Text (text/plain) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
"David D.W. Downey" <[EMAIL PROTECTED]> writes: > Good! I'm not the only ome getting this error! Mine is also a VT82C686 > though mine is a VT82C686A (352 BGA). This is on an MSI Model 694D Pro > motherboard running dual PIII-733 FC-PGA 133MHz Coppermines. RAM is 4 > 256MB PC133 unbuffered 7ns non mixed-cell DIMMs. I bring up the RAM and > CPU info because this board is also giving me random SIG11 errors even > though all equipment passes lab testing. > > . > > Anyone else out there with troubles with either of these 3 items? I've got two 694D Pro's (the AIR variant) and at the moment I'm not especially happy with them - whether it's Linux, the boards or a combination of both I don't know. Problems so far have been - With disks on the Promise controller I have to disable the M/B sound or Linux (everything from 2.2.14(RH 6.2) up to 2.4.0-ac4) hangs when probing the IDE interfaces. The sound shares the PCI IRO line with the Promise. With no disks on the Promise I can leave the sound enabled - I get the same CRC errors when I move the disks (Maxtor 33073H3's) to the VIA interfaces (ATA/66). - 2.4.0-ac8 gives errors on /dev/md1 (S/W RAID-1 pair) on boot (and then panics as /dev/md1 is the root fs), 2.2.x is happy with the mirror. I'm not sure whether this is a 2.4.0 problem, one introduced by Alan or hardware because I'm lucky to get a kernel compile without the thing OOPSing on me. My set-up is similar to David's except that I have 2x866 PIII FC-PGAs, If I can figure out whether some of the problems are hardware (we have 4 of these boards two were to have Linux, one one of the BSDs and one W2k so we should be able to spot problems that are common to all the OSes) I'll send some better bug reports. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, John Heil wrote: > I then changed to the 80 wire cables and retried with only -d1 again, > and to my surprise, the problems never came back and DMA stayed on. > A while later, I added -X66 and it too worked great. Then lastly came > the re-add of the rest giving current state. Yuck. What UDMA mode does your kernel put the drive in at boot WITHOUT the -X option? -X66 means UDMA 2 (33). -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, John Heil wrote: I then changed to the 80 wire cables and retried with only -d1 again, and to my surprise, the problems never came back and DMA stayed on. A while later, I added -X66 and it too worked great. Then lastly came the re-add of the rest giving current state. Yuck. What UDMA mode does your kernel put the drive in at boot WITHOUT the -X option? -X66 means UDMA 2 (33). -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
"David D.W. Downey" [EMAIL PROTECTED] writes: Good! I'm not the only ome getting this error! Mine is also a VT82C686 though mine is a VT82C686A (352 BGA). This is on an MSI Model 694D Pro motherboard running dual PIII-733 FC-PGA 133MHz Coppermines. RAM is 4 256MB PC133 unbuffered 7ns non mixed-cell DIMMs. I bring up the RAM and CPU info because this board is also giving me random SIG11 errors even though all equipment passes lab testing. . Anyone else out there with troubles with either of these 3 items? I've got two 694D Pro's (the AIR variant) and at the moment I'm not especially happy with them - whether it's Linux, the boards or a combination of both I don't know. Problems so far have been - With disks on the Promise controller I have to disable the M/B sound or Linux (everything from 2.2.14(RH 6.2) up to 2.4.0-ac4) hangs when probing the IDE interfaces. The sound shares the PCI IRO line with the Promise. With no disks on the Promise I can leave the sound enabled - I get the same CRC errors when I move the disks (Maxtor 33073H3's) to the VIA interfaces (ATA/66). - 2.4.0-ac8 gives errors on /dev/md1 (S/W RAID-1 pair) on boot (and then panics as /dev/md1 is the root fs), 2.2.x is happy with the mirror. I'm not sure whether this is a 2.4.0 problem, one introduced by Alan or hardware because I'm lucky to get a kernel compile without the thing OOPSing on me. My set-up is similar to David's except that I have 2x866 PIII FC-PGAs, If I can figure out whether some of the problems are hardware (we have 4 of these boards two were to have Linux, one one of the BSDs and one W2k so we should be able to spot problems that are common to all the OSes) I'll send some better bug reports. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
This sucks! I have had several systems with VIA chipsets and have never had any problems. Currently I am running a SOYO K6-2 system with UDMA 33 and a SOYO K-7 system with both UDMA-33 and UDMA-66 with not problems. How do we know that there is not some related hardware problem, (cable, power supply, etc ) with the systems that reported problems? What percentage of people are running OK VS those that are not? Now everybody with a VIA chipset is going to be punished! My $.02 Steve Vojtech Pavlik wrote: On Fri, Jan 12, 2001 at 04:09:22PM -0800, Linus Torvalds wrote: On Fri, 12 Jan 2001, Vojtech Pavlik wrote: However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets. That's because all VIA chipsets starting from vt82c586 to vt82c686b (UDMA100), share the same PCI ID. Would you prefer to filter just vt82c586 and vt82c586a as the comment in Alan's code says or simply unconditionally kill autodma on all of VIA chipsets, as Alan's code does? Right now, for 2.4.1, I'd rather have the patch to just do the same as 2.2.x. We can figure it out better when we get a better idea of exactly what the bug is, and whether there is some other work-around, and whether it is 100% certain that it is just those two controllers (maybe the other ones are buggy too, but the 2.2.x tests basically cured their symptoms too and peopl ehaven't reported them because they are "fixed"). Linus Ok, here goes the patch. Note that with this patch, all VIA users will get IDE transferrates about 3 MB/sec as opposed to about 20 MB/sec without it (and with UDMA66). This patch disables automatic DMA on all VIA chipsets, including the ancient 82c561 for 486's, and up to the 686a UDMA66 chipset. Also note that enabling the DMA later with hdparm -X66 -d1 or similar command is not safe, and usually works by pure luck on VIA chipsets. This however, would need some non-minor changes to the generic code to fix. But perhaps it's still worth ... -- Vojtech Pavlik SuSE Labs via-no-autodma.diffName: via-no-autodma.diff Type: Plain Text (text/plain) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Mon, 15 Jan 2001, Albert Cranford wrote:
I have a working PA-2007 but use a small hard disk. Can I help.
[...]
Detected 239.833 MHz processor.
[...]
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[...]
hda: WDC AC2540F, ATA DISK drive
hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hda: set_drive_speed_status: error=0x04 { DriveStatusError }
hda: 1056384 sectors (541 MB) w/64KiB Cache, CHS=524/32/63, DMA
I have a FIC PA-2007 (the older one, with a 586A bridge instead of the 586B
of later FIC PA-2007 boards), running at 75MHz FSB (PCI bus runs at 37.5MHz,
so I suppose I should use idebus=37.5 if I were to try 2.4.x), and a Quantum
Fireball lct15 30MB.
It works flawlessly in UDMA mode 2 (although I have to force the drive to
UDMA mode 2 with -X66 before enabling dma, because the bogus beta BIOS I use
sets it to UDMA4 which is not supported by the 586A). Kernel is 2.2.18,
without the 2.4.x ide backport.
The lspci output is exactly the same as yours.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Vojtech Pavlik wrote:
>
> Is the board still available for some testing?
>
I have a working PA-2007 but use a small hard disk. Can I help.
PIRQ redirection, working around broken MP-BIOS.
... PIRQ0 -> IRQ 0
Initializing CPU#0
Detected 239.833 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 478.41 BogoMIPS
Memory: 61920k/65536k available (1197k kernel code, 3228k reserved, 432k data, 244k
init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
CPU: Before vendor init, caps: 008001bf 008005bf , vendor = 2
CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
CPU: After vendor init, caps: 008001bf 008005bf
CPU: After generic, caps: 008001bf 008005bf
CPU: Common caps: 008001bf 008005bf
CPU: AMD-K6tm w/ multimedia extensions stepping 02
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
.SNIP..
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c586a IDE UDMA33 controller on pci0:7.1
ide0: BM-DMA at 0xfff0-0xfff7, BIOS settings: hda:pio, hdb:pio
hda: WDC AC2540F, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hda: set_drive_speed_status: error=0x04 { DriveStatusError }
hda: 1056384 sectors (541 MB) w/64KiB Cache, CHS=524/32/63, DMA
lspci -vv
00:00.0 Host bridge: VIA Technologies, Inc. VT82C595/97 [Apollo VP2/97] (rev 03)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
> > Note that "hdparm -X34 -d1" enables old DMA, not UDMA. (The board was > > advertised as UDMA capable but it isn't AFAIK). Fwiw, -X34 does not fix the lockups for everyone else. Vojtech Pavlik wrote: > Is the board still available for some testing? The board is not in the same country as me (Wales vs. France), but I visit it every few months so there is some chance of me testing it on that timescale. AFAIK there are no computer experts in the area to enable remote access ;-) > It should be able to do UDMA33. It does not look hopeful. Let us look at an old email: From: Jamie Lokier <[EMAIL PROTECTED]> To: Michel Aubry <[EMAIL PROTECTED]> Subject: Re: mozilla+XFree86+Linux-2.1.x => HARD LOCKUP (addition) On Wed, Dec 09, 1998 at 04:30:34PM +0100, Michel Aubry wrote: > Is this to say that your bios has no "select UDMA" or so capability??? > Is your motherboard an old one? (that was not udma compliant). It has "Bus Master DMA" option, but no "UDMA" option. It's an FIC PC-2011, manufactured about August 1997. I always assumed the hardware did UDMA (that's one reason I bought it). > you should edit via82c586.c , uncomment or add a > "#define DISPLAY_VIA_TIMINGS" > and recompile your kernel... Will do, at my next recompile. Would that be with the patch you sent me? > You ought to know that linux kernel via patch requires your bios to be > udma compliant. If not, all you can do safely is run it dma only! Is this strictly true? You've obviously got all the chipset docs, and I doubt anything on the motherboard interferes with IDE timings/state machines. > > [root@tantalophile linux]# hdparm -I /dev/hda > this one is not running udma! I know, I did hdparm -X34 explicitly to avoid lockups. > > [root@tantalophile linux]# hdparm -i /dev/hda > > this one is running udma! And with these settings unchanged, the system locks up from time to time. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sun, Jan 14, 2001 at 08:38:23PM +0100, Jamie Lokier wrote: > > I think its significant that two reports I have are FIC PA-2013 but not all. > > What combination of chips is on the 2013 ? > > Reading through my mail logs, I know a board, either FIC PA-2011 or FIC > PA-2007 (I seem to have changed my mind somewhere in history) with a > 6.4G Quantum Fireball ST, 64MB RAM and an AMD K6-233. The chipset > reports as VIA VP2/97; sorry, I do not have access to get the PCI IDs. PA-2007 is indeed a VP2/97, a very nice board, with vt82c595+vt82c586b. > It locks up with DMA enabled, typically after a few hours, and has done > that since 2.1 kernel days. > > Unfortunately it locks up with Mandrake 7.2 which is not very old (based > on 2.2.17 kernels -- it's not my PC any more but I installed Mandrake on > it recently). > > Kernel option "ide=nodma" fixes this -- no lockups. > > After that "hdparm -X34 -d1" enables DMA and the board remains reliable. > I observed one lockup in several years, while X was starting so it could > have been X. -X34 does not change the results of "hdparm -t". > > Note that "hdparm -X34 -d1" enables old DMA, not UDMA. (The board was > advertised as UDMA capable but it isn't AFAIK). It should be able to do UDMA33. Is the board still available for some testing? -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Alan Cox wrote: > I think its significant that two reports I have are FIC PA-2013 but not all. > What combination of chips is on the 2013 ? Reading through my mail logs, I know a board, either FIC PA-2011 or FIC PA-2007 (I seem to have changed my mind somewhere in history) with a 6.4G Quantum Fireball ST, 64MB RAM and an AMD K6-233. The chipset reports as VIA VP2/97; sorry, I do not have access to get the PCI IDs. It locks up with DMA enabled, typically after a few hours, and has done that since 2.1 kernel days. Unfortunately it locks up with Mandrake 7.2 which is not very old (based on 2.2.17 kernels -- it's not my PC any more but I installed Mandrake on it recently). Kernel option "ide=nodma" fixes this -- no lockups. After that "hdparm -X34 -d1" enables DMA and the board remains reliable. I observed one lockup in several years, while X was starting so it could have been X. -X34 does not change the results of "hdparm -t". Note that "hdparm -X34 -d1" enables old DMA, not UDMA. (The board was advertised as UDMA capable but it isn't AFAIK). enjoy, -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sat, 13 Jan 2001, Linus Torvalds wrote:
> Somebody who can test it needs to send me a patch - I'm NOT going to apply
> patches that haven't been tested and that I cannot test myself.
This patch has worked for me and is obvious enough that I haven't bothered
to rewire my box to put the IBM drive back on the HPT366 - the lid's
actually screwed on for once.
It adds all the IBM Deskstar 75GXP and 40GV drives to the HPT366's UDMA
mode 4 blacklist, forcing them to drop to mode 3, with which myself and
the one other tester who responded were unable to find problems.
IIRC the drives actually used in the testing were the 30GB and 45GB 75GXP
models - IBM-DTLA-3070{30,45}. I've blacklisted the 40GV models too with
this patch, just to be on the safe side. It's a reasonable assumption that
the IDE interfaces on the slower drives share the same compatibility
problems with the HPT366.
(And I've fixed the Pine bug which was stripping trailing whitespace and
making my patches fail to apply too :)
Index: drivers/ide/hpt366.c
===
RCS file: /inst/cvs/linux/drivers/ide/Attic/hpt366.c,v
retrieving revision 1.1.2.7
diff -u -r1.1.2.7 hpt366.c
--- drivers/ide/hpt366.c2001/01/05 11:10:44 1.1.2.7
+++ drivers/ide/hpt366.c2001/01/14 17:15:23
@@ -55,6 +55,15 @@
};
const char *bad_ata66_4[] = {
+ "IBM-DTLA-307075",
+ "IBM-DTLA-307060",
+ "IBM-DTLA-307045",
+ "IBM-DTLA-307030",
+ "IBM-DTLA-307020",
+ "IBM-DTLA-307015",
+ "IBM-DTLA-305040",
+ "IBM-DTLA-305030",
+ "IBM-DTLA-305020",
"WDC AC310200R",
NULL
};
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
I feel it important to note that the distrib in use for all of this is of
my own design. The specs are at www.kixolinux.com.
Why do I feel this is important? Possibly something I've done in the
distrib could be affecting this as well. I remember reading some weeks ago
about the 2.4.0-test## series + SCSI + SMP were having some problems.
The drives are as follows
ide0: BM-DMA at 0xb000-0xb007, BIOS settings: hda:DMA, hdb:DMA
hda: WDC WD153AA, ATA DISK drive
hda: 30064608 sectors (15393 MB) w/2048KiB Cache, CHS=1871/255/63, UDMA(66)
ide0: BM-DMA at 0xb000-0xb007, BIOS settings: hda:DMA, hdb:DMA
hdb: WDC WD300BB-00AUA1, ATA DISK drive
hdb: 58633344 sectors (30020 MB) w/2048KiB Cache, CHS=3649/255/63, UDMA(66)
ide1: BM-DMA at 0xb008-0xb00f, BIOS settings: hdc:DMA, hdd:pio
hdc: SAMSUNG CD-ROM SC-148F, ATAPI CDROM drive
hdc: ATAPI 48X CD-ROM drive, 128kB Cache, DMA
The errors are as follows
hdc: timeout waiting for DMA
hdc: irq timeout: status=0xd0 { Busy }
hdc: DMA disabled
hdc: ATAPI reset complete
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54
end_request: I/O error, dev 16:00 (hdc), sector 929520
hdc: irq timeout: status=0xd0 { Busy }
hdc: ATAPI reset complete
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54
end_request: I/O error, dev 16:00 (hdc), sector 929522
I get the same thing for hda and hdb though not as frequently as with
hdc. (Controller doesn't like switchign between DMA and PIO modes
possibly? ::shrug::)
David D.W. Downey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sat, Jan 13, 2001 at 08:41:00PM -0700, TimO wrote: > > Note that with this patch, all VIA users will get IDE transferrates > > about 3 MB/sec as opposed to about 20 MB/sec without it (and with > > UDMA66). > > > > Also note that enabling the DMA later with hdparm -X66 -d1 or similar > > command is not safe, and usually works by pure luck on VIA chipsets. > > This however, would need some non-minor changes to the generic code to > > fix. > > _ouch_ Will -X66 -d1c1m16 be as stable with this patch as version 2.1e > has been for me?? It has always (auto)set transfer speeds properly and > I have never seen corruption with my 686a -- 'cept when patching from > test11-pre7 to test12-pre1, and I'm pretty sure that was from other > factors. Well, can't tell. For some reason hdparm doesn't tell the VIA driver to update the timings in the chipset when changing modes. The fact that UDMA will start to work after this command is only due to that the VIA chips do have a built in filter for UDMA commands, notice the command sent to the harddrive, and switch the UDMA mode on. However the timings stay as were, as perhaps the BIOS set them up. So it may work or may not. As I said, getting it to work reliably needs changes in the generic code (hdparm should call the correct ioctl, and the ioctl must call the timing routine in the specific chipset code). If the patch I sent to Linus gets applied, I'll probably submit another one that will allow to override the no-dma rule by a kernel command line option, as Alan Cox suggested. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sun, Jan 14, 2001 at 12:40:58AM +0100, Andrzej Krzysztofowicz wrote: > > > 2.4 has code in the pci quirks to disable the register which makes > > > the chip masquerade as a VP3, and forces it to identify itself as > > > an MVP3 part. I'm curious whether this has an interaction here. > > > > This doesn't do anything but change the ID so that Linux drivers are not > > confused anymore. This caused a lot of trouble in 2.2, especially with > > the old VIA IDE driver. > [...] > > Fortunately all these chips use PIIX-compatible extensions to the PCI > > bus, so they are all interchangeable to some degree. > > > > > I'm curious if all of the other boards in Alans bug reports also > > > fall into the stranger category. > > > > It's possible. I have a board (VA-503A), which has a masqueraded 598, > > which identifies itself as 597, and a 686a southbridge. This got the > > 2.2 ide driver completely confused, for example. > > Maybe the VIA IDE chipset support option should depend on PCI quirks now ? No, in 2.4 the VIA IDE driver doesn't use this (northbridge) information anymore. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
> > /dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 {
> > DriveReady SeekComplete Error } hda: dma_intr: error=0x84 {
> > DriveStatusError BadCRC } hda: dma_intr: status=0x51 { DriveReady
> > SeekComplete Error } hda: dma_intr: error=0x84 { DriveStatusError
> > BadCRC } hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> ...
> > 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev
> > 02)
> > 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
> > 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super]
> > (rev 22)
> > 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo]
> > (rev 10)
> > 00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
> > 00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
> > 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
> > ACPI] (rev 30)
Good! I'm not the only ome getting this error! Mine is also a VT82C686
though mine is a VT82C686A (352 BGA). This is on an MSI Model 694D Pro
motherboard running dual PIII-733 FC-PGA 133MHz Coppermines. RAM is 4
256MB PC133 unbuffered 7ns non mixed-cell DIMMs. I bring up the RAM and
CPU info because this board is also giving me random SIG11 errors even
though all equipment passes lab testing.
I was beginning to think the board was flaky until i saw this
posting. Almost exactly matche smy errors. Also, since I'm using the
Promise PDC20265 (rev 2) ATA33/66 + 100 controller on the mobo, I wasn't sure
if my errors were stemming from that. The 2.4.0 kernel driver picks up
the controller fine and it's only under heavy I/O (aka dd if=/dev/hdc
of=/root/testdd.img bs=1024M count=2k ) that it REALLY goes nuts and
drops loses it's lunch all over the floor. Accessing a standard 48X CDROM
in the same manner doesn't kill the kernel but I get quite a few
DriveReady errors like you got. I'm wondering if this is just a flaky
chipset or if this is a Promise controller issue. This is one reason i'm
extremely interested in what controller you have on your board, and if you
are using it.
I also had to remove the USB support totally since it would stream errors
at me about usb devices not accepting new addresses.
Funny thing is, I don't have any USB devices attached to the machine!
Thought address assignments were only when you attached devices.
Anyone else out there with troubles with either of these 3 items?
David D.W. Downey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
/dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 {
DriveReady SeekComplete Error } hda: dma_intr: error=0x84 {
DriveStatusError BadCRC } hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error } hda: dma_intr: error=0x84 { DriveStatusError
BadCRC } hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
...
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev
02)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super]
(rev 22)
00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo]
(rev 10)
00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
ACPI] (rev 30)
Good! I'm not the only ome getting this error! Mine is also a VT82C686
though mine is a VT82C686A (352 BGA). This is on an MSI Model 694D Pro
motherboard running dual PIII-733 FC-PGA 133MHz Coppermines. RAM is 4
256MB PC133 unbuffered 7ns non mixed-cell DIMMs. I bring up the RAM and
CPU info because this board is also giving me random SIG11 errors even
though all equipment passes lab testing.
I was beginning to think the board was flaky until i saw this
posting. Almost exactly matche smy errors. Also, since I'm using the
Promise PDC20265 (rev 2) ATA33/66 + 100 controller on the mobo, I wasn't sure
if my errors were stemming from that. The 2.4.0 kernel driver picks up
the controller fine and it's only under heavy I/O (aka dd if=/dev/hdc
of=/root/testdd.img bs=1024M count=2k ) that it REALLY goes nuts and
drops loses it's lunch all over the floor. Accessing a standard 48X CDROM
in the same manner doesn't kill the kernel but I get quite a few
DriveReady errors like you got. I'm wondering if this is just a flaky
chipset or if this is a Promise controller issue. This is one reason i'm
extremely interested in what controller you have on your board, and if you
are using it.
I also had to remove the USB support totally since it would stream errors
at me about usb devices not accepting new addresses.
Funny thing is, I don't have any USB devices attached to the machine!
Thought address assignments were only when you attached devices.
Anyone else out there with troubles with either of these 3 items?
David D.W. Downey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sun, Jan 14, 2001 at 12:40:58AM +0100, Andrzej Krzysztofowicz wrote: 2.4 has code in the pci quirks to disable the register which makes the chip masquerade as a VP3, and forces it to identify itself as an MVP3 part. I'm curious whether this has an interaction here. This doesn't do anything but change the ID so that Linux drivers are not confused anymore. This caused a lot of trouble in 2.2, especially with the old VIA IDE driver. [...] Fortunately all these chips use PIIX-compatible extensions to the PCI bus, so they are all interchangeable to some degree. I'm curious if all of the other boards in Alans bug reports also fall into the stranger category. It's possible. I have a board (VA-503A), which has a masqueraded 598, which identifies itself as 597, and a 686a southbridge. This got the 2.2 ide driver completely confused, for example. Maybe the VIA IDE chipset support option should depend on PCI quirks now ? No, in 2.4 the VIA IDE driver doesn't use this (northbridge) information anymore. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sat, Jan 13, 2001 at 08:41:00PM -0700, TimO wrote: Note that with this patch, all VIA users will get IDE transferrates about 3 MB/sec as opposed to about 20 MB/sec without it (and with UDMA66). Also note that enabling the DMA later with hdparm -X66 -d1 or similar command is not safe, and usually works by pure luck on VIA chipsets. This however, would need some non-minor changes to the generic code to fix. _ouch_ Will -X66 -d1c1m16 be as stable with this patch as version 2.1e has been for me?? It has always (auto)set transfer speeds properly and I have never seen corruption with my 686a -- 'cept when patching from test11-pre7 to test12-pre1, and I'm pretty sure that was from other factors. Well, can't tell. For some reason hdparm doesn't tell the VIA driver to update the timings in the chipset when changing modes. The fact that UDMA will start to work after this command is only due to that the VIA chips do have a built in filter for UDMA commands, notice the command sent to the harddrive, and switch the UDMA mode on. However the timings stay as were, as perhaps the BIOS set them up. So it may work or may not. As I said, getting it to work reliably needs changes in the generic code (hdparm should call the correct ioctl, and the ioctl must call the timing routine in the specific chipset code). If the patch I sent to Linus gets applied, I'll probably submit another one that will allow to override the no-dma rule by a kernel command line option, as Alan Cox suggested. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
I feel it important to note that the distrib in use for all of this is of
my own design. The specs are at www.kixolinux.com.
Why do I feel this is important? Possibly something I've done in the
distrib could be affecting this as well. I remember reading some weeks ago
about the 2.4.0-test## series + SCSI + SMP were having some problems.
The drives are as follows
ide0: BM-DMA at 0xb000-0xb007, BIOS settings: hda:DMA, hdb:DMA
hda: WDC WD153AA, ATA DISK drive
hda: 30064608 sectors (15393 MB) w/2048KiB Cache, CHS=1871/255/63, UDMA(66)
ide0: BM-DMA at 0xb000-0xb007, BIOS settings: hda:DMA, hdb:DMA
hdb: WDC WD300BB-00AUA1, ATA DISK drive
hdb: 58633344 sectors (30020 MB) w/2048KiB Cache, CHS=3649/255/63, UDMA(66)
ide1: BM-DMA at 0xb008-0xb00f, BIOS settings: hdc:DMA, hdd:pio
hdc: SAMSUNG CD-ROM SC-148F, ATAPI CDROM drive
hdc: ATAPI 48X CD-ROM drive, 128kB Cache, DMA
The errors are as follows
hdc: timeout waiting for DMA
hdc: irq timeout: status=0xd0 { Busy }
hdc: DMA disabled
hdc: ATAPI reset complete
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54
end_request: I/O error, dev 16:00 (hdc), sector 929520
hdc: irq timeout: status=0xd0 { Busy }
hdc: ATAPI reset complete
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54
end_request: I/O error, dev 16:00 (hdc), sector 929522
I get the same thing for hda and hdb though not as frequently as with
hdc. (Controller doesn't like switchign between DMA and PIO modes
possibly? ::shrug::)
David D.W. Downey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sat, 13 Jan 2001, Linus Torvalds wrote:
Somebody who can test it needs to send me a patch - I'm NOT going to apply
patches that haven't been tested and that I cannot test myself.
This patch has worked for me and is obvious enough that I haven't bothered
to rewire my box to put the IBM drive back on the HPT366 - the lid's
actually screwed on for once.
It adds all the IBM Deskstar 75GXP and 40GV drives to the HPT366's UDMA
mode 4 blacklist, forcing them to drop to mode 3, with which myself and
the one other tester who responded were unable to find problems.
IIRC the drives actually used in the testing were the 30GB and 45GB 75GXP
models - IBM-DTLA-3070{30,45}. I've blacklisted the 40GV models too with
this patch, just to be on the safe side. It's a reasonable assumption that
the IDE interfaces on the slower drives share the same compatibility
problems with the HPT366.
(And I've fixed the Pine bug which was stripping trailing whitespace and
making my patches fail to apply too :)
Index: drivers/ide/hpt366.c
===
RCS file: /inst/cvs/linux/drivers/ide/Attic/hpt366.c,v
retrieving revision 1.1.2.7
diff -u -r1.1.2.7 hpt366.c
--- drivers/ide/hpt366.c2001/01/05 11:10:44 1.1.2.7
+++ drivers/ide/hpt366.c2001/01/14 17:15:23
@@ -55,6 +55,15 @@
};
const char *bad_ata66_4[] = {
+ "IBM-DTLA-307075",
+ "IBM-DTLA-307060",
+ "IBM-DTLA-307045",
+ "IBM-DTLA-307030",
+ "IBM-DTLA-307020",
+ "IBM-DTLA-307015",
+ "IBM-DTLA-305040",
+ "IBM-DTLA-305030",
+ "IBM-DTLA-305020",
"WDC AC310200R",
NULL
};
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Alan Cox wrote: I think its significant that two reports I have are FIC PA-2013 but not all. What combination of chips is on the 2013 ? Reading through my mail logs, I know a board, either FIC PA-2011 or FIC PA-2007 (I seem to have changed my mind somewhere in history) with a 6.4G Quantum Fireball ST, 64MB RAM and an AMD K6-233. The chipset reports as VIA VP2/97; sorry, I do not have access to get the PCI IDs. It locks up with DMA enabled, typically after a few hours, and has done that since 2.1 kernel days. Unfortunately it locks up with Mandrake 7.2 which is not very old (based on 2.2.17 kernels -- it's not my PC any more but I installed Mandrake on it recently). Kernel option "ide=nodma" fixes this -- no lockups. After that "hdparm -X34 -d1" enables DMA and the board remains reliable. I observed one lockup in several years, while X was starting so it could have been X. -X34 does not change the results of "hdparm -t". Note that "hdparm -X34 -d1" enables old DMA, not UDMA. (The board was advertised as UDMA capable but it isn't AFAIK). enjoy, -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Note that "hdparm -X34 -d1" enables old DMA, not UDMA. (The board was advertised as UDMA capable but it isn't AFAIK). Fwiw, -X34 does not fix the lockups for everyone else. Vojtech Pavlik wrote: Is the board still available for some testing? The board is not in the same country as me (Wales vs. France), but I visit it every few months so there is some chance of me testing it on that timescale. AFAIK there are no computer experts in the area to enable remote access ;-) It should be able to do UDMA33. It does not look hopeful. Let us look at an old email: From: Jamie Lokier [EMAIL PROTECTED] To: Michel Aubry [EMAIL PROTECTED] Subject: Re: mozilla+XFree86+Linux-2.1.x = HARD LOCKUP (addition) On Wed, Dec 09, 1998 at 04:30:34PM +0100, Michel Aubry wrote: Is this to say that your bios has no "select UDMA" or so capability??? Is your motherboard an old one? (that was not udma compliant). It has "Bus Master DMA" option, but no "UDMA" option. It's an FIC PC-2011, manufactured about August 1997. I always assumed the hardware did UDMA (that's one reason I bought it). you should edit via82c586.c , uncomment or add a "#define DISPLAY_VIA_TIMINGS" and recompile your kernel... Will do, at my next recompile. Would that be with the patch you sent me? You ought to know that linux kernel via patch requires your bios to be udma compliant. If not, all you can do safely is run it dma only! Is this strictly true? You've obviously got all the chipset docs, and I doubt anything on the motherboard interferes with IDE timings/state machines. [root@tantalophile linux]# hdparm -I /dev/hda this one is not running udma! I know, I did hdparm -X34 explicitly to avoid lockups. [root@tantalophile linux]# hdparm -i /dev/hda this one is running udma! And with these settings unchanged, the system locks up from time to time. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Vojtech Pavlik wrote:
Is the board still available for some testing?
I have a working PA-2007 but use a small hard disk. Can I help.
PIRQ redirection, working around broken MP-BIOS.
... PIRQ0 - IRQ 0
Initializing CPU#0
Detected 239.833 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 478.41 BogoMIPS
Memory: 61920k/65536k available (1197k kernel code, 3228k reserved, 432k data, 244k
init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
CPU: Before vendor init, caps: 008001bf 008005bf , vendor = 2
CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
CPU: After vendor init, caps: 008001bf 008005bf
CPU: After generic, caps: 008001bf 008005bf
CPU: Common caps: 008001bf 008005bf
CPU: AMD-K6tm w/ multimedia extensions stepping 02
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
.SNIP..
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c586a IDE UDMA33 controller on pci0:7.1
ide0: BM-DMA at 0xfff0-0xfff7, BIOS settings: hda:pio, hdb:pio
hda: WDC AC2540F, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hda: set_drive_speed_status: error=0x04 { DriveStatusError }
hda: 1056384 sectors (541 MB) w/64KiB Cache, CHS=524/32/63, DMA
lspci -vv
00:00.0 Host bridge: VIA Technologies, Inc. VT82C595/97 [Apollo VP2/97] (rev 03)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR+
Latency: 32 set
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 25)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR-
Latency: 0 set
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) (prog-if
8a [Master SecP PriP])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR-
Latency: 32 set
Region 4: I/O ports at fff0 [size=16]
--
Albert Cranford Deerfield Beach FL USA
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
In-Reply-To: <[EMAIL PROTECTED]>
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Bryan O'Sullivan) wrote:
> /dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 {
> DriveReady SeekComplete Error } hda: dma_intr: error=0x84 {
> DriveStatusError BadCRC } hda: dma_intr: status=0x51 { DriveReady
> SeekComplete Error } hda: dma_intr: error=0x84 { DriveStatusError
> BadCRC } hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
...
> 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev
> 02)
> 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
> 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super]
> (rev 22)
> 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo]
> (rev 10)
> 00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
> 00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
> 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
> ACPI] (rev 30)
It's not an Abit KT7 or similar is it?
I was just helping my dad upgrade a machine based with one of those to 2.4
today and until we turned off Generic PCI bus-master DMA Support and the
VIA82CXXX drivers we kept getting the same messages the second the system
booted up.
It was rather annoying, as I'm not sure if it was because of this or
something else, but we ended up with some minor disk corruption mainly
around /usr/src/linux where I made the mistake of doing a make mrproper
while it was like this. Went back to 2.2 temporarily and it was fine.
Can dig out/try anything on request.
TonyP
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Vojtech Pavlik wrote: > > Ok, here goes the patch. > > Note that with this patch, all VIA users will get IDE transferrates > about 3 MB/sec as opposed to about 20 MB/sec without it (and with > UDMA66). > > This patch disables automatic DMA on all VIA chipsets, including the > ancient 82c561 for 486's, and up to the 686a UDMA66 chipset. > > Also note that enabling the DMA later with hdparm -X66 -d1 or similar > command is not safe, and usually works by pure luck on VIA chipsets. > This however, would need some non-minor changes to the generic code to > fix. > > But perhaps it's still worth ... > > -- > Vojtech Pavlik > SuSE Labs > > _ouch_ Will -X66 -d1c1m16 be as stable with this patch as version 2.1e has been for me?? It has always (auto)set transfer speeds properly and I have never seen corruption with my 686a -- 'cept when patching from test11-pre7 to test12-pre1, and I'm pretty sure that was from other factors. === -- Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
>From kufel!ankry Sun Jan 14 00:30:25 2001 Return-Path: Received: from kufel.UUCP (uucp@localhost) by green.mif.pg.gda.pl (8.9.3/8.9.3) with UUCP id AAA00889 for green.mif.pg.gda.pl!ankry; Sun, 14 Jan 2001 00:30:25 +0100 Received: (from ankry@localhost) by kufel.dom (8.9.3/8.9.3) id WAA01107 for green!ankry; Sat, 13 Jan 2001 22:00:40 +0100 From: Andrzej Krzysztofowicz Message-Id: <[EMAIL PROTECTED]> Subject: Re: ide.2.4.1-p3.01112001.patch To: kufel!green.mif.pg.gda.pl!ankry Date: Sat, 13 Jan 2001 22:00:40 +0100 (CET) In-Reply-To: <[EMAIL PROTECTED]> from "Vojtech Pavlik" at Jan 13, 2001 02:42:36 PM X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [EMAIL PROTECTED] (Vojtech Pavlik) > > 2.4 has code in the pci quirks to disable the register which makes > > the chip masquerade as a VP3, and forces it to identify itself as > > an MVP3 part. I'm curious whether this has an interaction here. > > This doesn't do anything but change the ID so that Linux drivers are not > confused anymore. This caused a lot of trouble in 2.2, especially with > the old VIA IDE driver. [...] > Fortunately all these chips use PIIX-compatible extensions to the PCI > bus, so they are all interchangeable to some degree. > > > I'm curious if all of the other boards in Alans bug reports also > > fall into the stranger category. > > It's possible. I have a board (VA-503A), which has a masqueraded 598, > which identifies itself as 597, and a 686a southbridge. This got the > 2.2 ide driver completely confused, for example. Maybe the VIA IDE chipset support option should depend on PCI quirks now ? -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] tel. (0-58) 347 14 61 Wydz.Fizyki Technicznej i Matematyki Stosowanej Politechniki Gdanskiej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
With vt86c686b (AOpen AK73Pro) I am having a strange problem. When accessing disks old-fashioned way (/dev/hdaN or /dev/hdcN) I do not see corruption, but writing to a RAID-1 made out of them produces corrupted results. Does RAID code access the underlying block device the same way as single partitions are accessed from the userland? My test goes like this: cd / raidstop /dev/md2 # Baseline: single device case seem to work OK # with both 2.1e and 3.11 for dev in a7 c7 do mke2fs /dev/hd$dev mount /dev/hd$dev /mnt tar cf - usr | ( cd /mnt && tar xfp - ) sync umount /mnt mount -o ro /dev/hd$dev /mnt tar cf - usr | ( cd /mnt && tar df - ) # no problem reported from `tar df' umount /mnt done # RAID-1 /dev/md2 is built out of /dev/hda7 and /dev/hdc7 # not quite, but exact `force' switch withheld :-) mkraid /dev/md2 # wait until /proc/mdstat says /dev/md2 is fully reconstructed mke2fs /dev/md2 mount /dev/md2 /mnt tar cf - usr | ( cd /mnt && tar xfp - ) sync umount /mnt mount -o ro /dev/md2 /mnt tar cf - usr | ( cd /mnt && tar df - ) # many errors. umount /mnt raidstop /dev/md2 sync mkdir -p /mnt/1 /mnt/2 mount -o ro /dev/hda7 /mnt/1 mount -o ro /dev/hdc7 /mnt/2 tar cf - usr | ( cd /mnt/1 && tar df - ) # many differences. tar cf - usr | ( cd /mnt/2 && tar df - ) # many differences. umount /dev/hda7 umount /dev/hdc7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
COOL!
This will kill the VIA problem and allow us to clobber the timeout.
I know where and what to do but it is the how with the current mess of the
driver held togather with duct tape and paper clips and a little bit of
spit here and there.
I can not wait for 2.5 to get started to begin with "rm -rf ./drivers/ide"
and start with "mkdir ./drivers/ata" ;-)) Okay not quite that radical but
very close
On Sat, 13 Jan 2001, Alan Cox wrote:
> > if (IDE_PCI_DEVID_EQ(d->devid, DEVID_SIS5513) ||
> > IDE_PCI_DEVID_EQ(d->devid, DEVID_AEC6260) ||
> > IDE_PCI_DEVID_EQ(d->devid, DEVID_PIIX4NX) ||
> > - IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X))
> > + IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X) ||
> > + IDE_PCI_DEVID_EQ(d->devid, DEVID_VIA_IDE) ||
> > + IDE_PCI_DEVID_EQ(d->devid, DEVID_VP_IDE))
> > autodma = 0;
> > if (autodma)
> > hwif->autodma = 1;
>
> How about
>
> && !force_dma)
>
>
> __setup("force_dma") ...
>
> So those who want to play fast can
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
Linux ATA Development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
> if (IDE_PCI_DEVID_EQ(d->devid, DEVID_SIS5513) ||
> IDE_PCI_DEVID_EQ(d->devid, DEVID_AEC6260) ||
> IDE_PCI_DEVID_EQ(d->devid, DEVID_PIIX4NX) ||
> - IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X))
> + IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X) ||
> + IDE_PCI_DEVID_EQ(d->devid, DEVID_VIA_IDE) ||
> + IDE_PCI_DEVID_EQ(d->devid, DEVID_VP_IDE))
> autodma = 0;
> if (autodma)
> hwif->autodma = 1;
How about
&& !force_dma)
__setup("force_dma") ...
So those who want to play fast can
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
David Woodhouse writes: > Please can we also stop HPT366 from attempting UDMA66 on the IBM DTLA > drives, while we're at it? I don't care if it's done by blacklisting the > DTLA drives, as was done by the patch I resent numerous times, or if it's > done the other way round by putting known-compatible drives (include > "FUJITSU MPE3136AT") into a whitelist. But it needs doing. I've been wondering recently why there isn't an option to tell the kernel "even if you've been configured to use dma by default, please don't on this IDE interface". There is an option for tuning the interface up, but nothing to tune down. It strikes me that this might be a good thing to have. Comments? _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On 12 Jan 2001, Linus Torvalds wrote: > In short, let's leave it out of a stable kernel for now, and add > blacklisting of auto-DMA. Alan has a list. We can play around with > trying to _fix_ DMA on the VIA chipsets in 2.5.x (and possibly backport > the thing once it has been sufficiently battletested that people believe > it truly will work). Please can we also stop HPT366 from attempting UDMA66 on the IBM DTLA drives, while we're at it? I don't care if it's done by blacklisting the DTLA drives, as was done by the patch I resent numerous times, or if it's done the other way round by putting known-compatible drives (include "FUJITSU MPE3136AT") into a whitelist. But it needs doing. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sat, 13 Jan 2001, David Woodhouse wrote: > > Please can we also stop HPT366 from attempting UDMA66 on the IBM DTLA > drives, while we're at it? I don't care if it's done by blacklisting the > DTLA drives, as was done by the patch I resent numerous times, or if it's > done the other way round by putting known-compatible drives (include > "FUJITSU MPE3136AT") into a whitelist. But it needs doing. Somebody who can test it needs to send me a patch - I'm NOT going to apply patches that haven't been tested and that I cannot test myself. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Hi!
This is not the case I'm looking for. You have a 686b, a chip that is
not supported in 2.4.0 yet. You can try the via 3.11 driver I posted a
while ago, it adds support for this chip, including UDMA100.
Thanks anyway,
Vojtech
On Sat, Jan 13, 2001 at 09:09:05AM -0800, Bryan O'Sullivan wrote:
> v> I can make one for you, but first I'd like to find out what exactly are
> v> the problem cases.
>
> I have a VT82C686 motherboard. It has one UDMA-100 slot and two
> regular IDE slots. I have an IBM DTTA-371440 (about 18 months old) as
> hda (only fat32 filesystems), and an IBM DTLA-307030 as hde
> (i.e. plugged into the UDMA-100 slot). I've never seen any problems
> with DMA on the newer drive, but if I turn on DMA and do anything with
> the older drive, I get stuff like this:
>
> /dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 { DriveReady
>SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
>
> The driver attempts to reset ide0 a few times, gets more of the above,
> then gives up with an I/O error.
>
> I've been seeing these problems as long as I've been tracking the 2.3
> series, up to and including 2.4.0. I can't boot a 2.2 kernel on this
> machine to compare, as it doesn't recognise hde (which is where Linux
> lives).
>
> Here's the output of lspci under 2.4.0, in case it's useful:
>
> 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
> 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
> 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
> 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
> 00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
> 00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
> 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
> 00:09.0 CardBus bridge: Texas Instruments PCI1225 (rev 01)
> 00:09.1 CardBus bridge: Texas Instruments PCI1225 (rev 01)
> 00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
> 00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 08)
> 00:0b.1 Input device controller: Creative Labs SB Live! (rev 08)
> 00:11.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device
>0d30 (rev 02)
> 01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0150 (rev a3)
>
> If you need any more information, I can dig it out.
>
> http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
v> I can make one for you, but first I'd like to find out what exactly are
v> the problem cases.
I have a VT82C686 motherboard. It has one UDMA-100 slot and two
regular IDE slots. I have an IBM DTTA-371440 (about 18 months old) as
hda (only fat32 filesystems), and an IBM DTLA-307030 as hde
(i.e. plugged into the UDMA-100 slot). I've never seen any problems
with DMA on the newer drive, but if I turn on DMA and do anything with
the older drive, I get stuff like this:
/dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
The driver attempts to reset ide0 a few times, gets more of the above,
then gives up with an I/O error.
I've been seeing these problems as long as I've been tracking the 2.3
series, up to and including 2.4.0. I can't boot a 2.2 kernel on this
machine to compare, as it doesn't recognise hde (which is where Linux
lives).
Here's the output of lspci under 2.4.0, in case it's useful:
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:09.0 CardBus bridge: Texas Instruments PCI1225 (rev 01)
00:09.1 CardBus bridge: Texas Instruments PCI1225 (rev 01)
00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 08)
00:0b.1 Input device controller: Creative Labs SB Live! (rev 08)
00:11.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device
0d30 (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0150 (rev a3)
If you need any more information, I can dig it out.
http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 11:43:23PM +, Alan Cox wrote: > > I'd like to hear about such reports so that I can start debugging (and > > perhaps get me one of those failing boards, they must be quite cheap > > these days). > > This is one of the most precise reports I have > > |The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks. The > |size of hda is 4.3 GB, the size of hdb is 854 MB and the size of hdc is > |1.2 GB. Hdd is an IDE CDROM drive > > I think its significant that two reports I have are FIC PA-2013 but not all. > What combination of chips is on the 2013 ? As far as I know the same as on FIC VA-503+, that is vt82c598 north and vt82c586b south - the MVP3 chipset. I've got the VA-503+ here and it works really well. the 503+ and the 2013 differ only in form factor, one is Baby AT (503+) and the other is ATX. It's vt82c586b, and most probably 3041 silicon - the most bugless VIA southbridge I know of ... Weird. Could the person who reported it test the 2.4.0 kernel? I think the 2.2 drivers had some MVP3 (and 3041 silicon) related bugs. 3041 has some registers layed out differently from all other chips. Btw, this is not the 586 nor 586a, so changing the test to test for just these two probably won't be the right thing to do ... -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sat, Jan 13, 2001 at 02:43:30AM +, [EMAIL PROTECTED] wrote: > > |The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks. The > > |size of hda is 4.3 GB, the size of hdb is 854 MB and the size of hdc is > > |1.2 GB. Hdd is an IDE CDROM drive > > > > I think its significant that two reports I have are FIC PA-2013 but not all. > > What combination of chips is on the 2013 ? > > The FIC PA-2013 is one of the stranger types of MVP3. > (A mixture of 82c597 host bridge and 82c598 PCI bridge). 598 + 586b > As discussed some time ago on this list, there are some of these > boards, which initially seem to be an MVP3, but have the host bridge ID > set to an VP3. (Real reasoning behind this never figured out). Windows driver compatibility, so that VP3 drivers would work on MVP3 as well. > 2.4 has code in the pci quirks to disable the register which makes > the chip masquerade as a VP3, and forces it to identify itself as > an MVP3 part. I'm curious whether this has an interaction here. This doesn't do anything but change the ID so that Linux drivers are not confused anymore. This caused a lot of trouble in 2.2, especially with the old VIA IDE driver. > I have a list of known 'hybrid' boards, and known true (both halves) MVP3 > boards and also a collection of lspci -xxx outputs from a selection of > them. If anyone wants any of this stuff, shout and I'll put it up > for ftp/www. Actually, the definitions of what's a 'true VIA xxx chipset' change over time, as VIA upgrades the southbridges in the specs. You'll now fing that the VPX chipset is 587vpx + 586b, but when released the 587vpx was coupled with the old 586 south. Fortunately all these chips use PIIX-compatible extensions to the PCI bus, so they are all interchangeable to some degree. > I'm curious if all of the other boards in Alans bug reports also > fall into the stranger category. It's possible. I have a board (VA-503A), which has a masqueraded 598, which identifies itself as 597, and a 686a southbridge. This got the 2.2 ide driver completely confused, for example. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 04:09:22PM -0800, Linus Torvalds wrote:
> On Fri, 12 Jan 2001, Vojtech Pavlik wrote:
> >
> > However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets.
> > That's because all VIA chipsets starting from vt82c586 to vt82c686b
> > (UDMA100), share the same PCI ID.
> >
> > Would you prefer to filter just vt82c586 and vt82c586a as the comment in
> > Alan's code says or simply unconditionally kill autodma on all of VIA
> > chipsets, as Alan's code does?
>
> Right now, for 2.4.1, I'd rather have the patch to just do the same as
> 2.2.x. We can figure it out better when we get a better idea of exactly
> what the bug is, and whether there is some other work-around, and whether
> it is 100% certain that it is just those two controllers (maybe the other
> ones are buggy too, but the 2.2.x tests basically cured their symptoms too
> and peopl ehaven't reported them because they are "fixed").
>
> Linus
Ok, here goes the patch.
Note that with this patch, all VIA users will get IDE transferrates
about 3 MB/sec as opposed to about 20 MB/sec without it (and with
UDMA66).
This patch disables automatic DMA on all VIA chipsets, including the
ancient 82c561 for 486's, and up to the 686a UDMA66 chipset.
Also note that enabling the DMA later with hdparm -X66 -d1 or similar
command is not safe, and usually works by pure luck on VIA chipsets.
This however, would need some non-minor changes to the generic code to
fix.
But perhaps it's still worth ...
--
Vojtech Pavlik
SuSE Labs
diff -urN linux-old/drivers/ide/ide-pci.c linux/drivers/ide/ide-pci.c
--- linux-old/drivers/ide/ide-pci.c Wed Jan 3 01:58:45 2001
+++ linux/drivers/ide/ide-pci.c Sat Jan 13 14:54:53 2001
@@ -663,7 +663,9 @@
if (IDE_PCI_DEVID_EQ(d->devid, DEVID_SIS5513) ||
IDE_PCI_DEVID_EQ(d->devid, DEVID_AEC6260) ||
IDE_PCI_DEVID_EQ(d->devid, DEVID_PIIX4NX) ||
- IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X))
+ IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X) ||
+ IDE_PCI_DEVID_EQ(d->devid, DEVID_VIA_IDE) ||
+ IDE_PCI_DEVID_EQ(d->devid, DEVID_VP_IDE))
autodma = 0;
if (autodma)
hwif->autodma = 1;
diff -urN linux-old/drivers/ide/via82cxxx.c linux/drivers/ide/via82cxxx.c
--- linux-old/drivers/ide/via82cxxx.c Tue Nov 7 20:02:24 2000
+++ linux/drivers/ide/via82cxxx.c Sat Jan 13 14:52:26 2001
@@ -602,7 +602,6 @@
#ifdef CONFIG_BLK_DEV_IDEDMA
if (hwif->dma_base) {
hwif->dmaproc = _dmaproc;
- hwif->autodma = 1;
}
#endif /* CONFIG_BLK_DEV_IDEDMA */
}
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 04:52:00PM -0800, Linus Torvalds wrote: > > > On Fri, 12 Jan 2001, John Heil wrote: > > > On Sat, 13 Jan 2001, Alan Cox wrote: > > > > > Date: Sat, 13 Jan 2001 00:25:28 + (GMT) > > > From: Alan Cox <[EMAIL PROTECTED]> > > > To: Linus Torvalds <[EMAIL PROTECTED]> > > > Cc: Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > > > Subject: Re: ide.2.4.1-p3.01112001.patch > > > > > > > what the bug is, and whether there is some other work-around, and whether > > > > it is 100% certain that it is just those two controllers (maybe the other > > > > ones are buggy too, but the 2.2.x tests basically cured their symptoms too > > > > and peopl ehaven't reported them because they are "fixed"). > > > > > > I've not seen reports on the later chips. If they had been buggy and then > > > fixed I'd have expected much unhappy ranting before the change > > > > The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda. > > Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon. > > Careful. It may be that your fix just avoids the corruption because the > other changes make it ok - like the 16-sector multi-count thing maybe > hides a problem that might still exist - it just changes the "normal" > timing so that you won't ever see it in practice any more. > > These kinds of magic interactions is why I'm not at all happy about driver > changes until people really know what it was that caused it, and _know_ > that it's gone. > > Anyway, for you the problem apparently happened even on a 686a, but just > the 586 series. Correct? Yes, but this is a different problem. No corruption was happening here. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Hi!
I think that with 2.4.0 your board will operate just fine at UDMA33. If
you can, please do test that. Best mount your drives read only at first,
but I doubt there will be any problems.
Vojtech
On Fri, Jan 12, 2001 at 08:03:49PM -0700, Tkil wrote:
>
> Alan asked:
> > I think its significant that two reports I have are FIC PA-2013 but
> > not all. What combination of chips is on the 2013 ?
>
> My board here is a FIC PA-2013A (if I recall correctly; the
> motherboard only has "PA-2013" on it, no "A") rev 1.1.
>
> It's worth noting that there is at least another full revision level
> (2.x), and the BIOSes for these different revisions are *not*
> compatible (as I found out to my chagrin ;-).
>
> Also, the FIC PA-513 (maybe 512?) should be a very similar board, only
> wired for an AT power supply where the PA-2013 is an ATX board.
>
> I've never seen the DMA data corruption on this box, but I'd really
> really like to get something better than 3MB/s off my UDMA/66-capable
> drives. I'm pretty sure that (prior to the 2.2.18 squelching of all
> VIA IDE UDMA) that hda and hdc would come up with DMA enabled, at the
> very least. Is there a safe way to test various hdparm settings? I'm
> even willing to buy a scratch disk if that would help...
>
> Looking at the chips, I have:
>
> 1. VIA
>VT82C598MVP
>9828CE Taiwan
>13G003900
>
> 2. VIA
>VT82C586B
>S7-SB
>9826CD Taiwan
>14B013511
>
> It has an Award BIOS with a variety of WinBond support chips (looks
> like at least 4 on-board cache chips, and one near the BIOS EEPROM).
>
> Here's the relevant dmesg bits:
>
> | PCI: PCI BIOS revision 2.10 entry at 0xfb490
> | PCI: Using configuration type 1
> | PCI: Probing PCI hardware
> | PCI: 00:38 [1106/0586]: Work around ISA DMA hangs (00)
> | Activating ISA DMA hang workarounds.
> | Detected PS/2 Mouse Port.
> | Serial driver version 4.27 with no serial options enabled
> | ttyS00 at 0x03f8 (irq = 4) is a 16550A
> | ttyS01 at 0x02f8 (irq = 3) is a 16550A
> | Real Time Clock Driver v1.09
> | VP_IDE: IDE controller on PCI bus 00 dev 39
> | VP_IDE: not 100% native mode: will probe irqs later
> | ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
> | ide0: VIA Bus-Master (U)DMA Timing Config Success
> | ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA
> | ide1: VIA Bus-Master (U)DMA Timing Config Success
> | hda: WDC WD307AA, ATA DISK drive
> | hdc: Maxtor 96147H8, ATA DISK drive
> | ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> | ide1 at 0x170-0x177,0x376 on irq 15
> | hda: WDC WD307AA, 29333MB w/2048kB Cache, CHS=59598/16/63
> | hdc: Maxtor 96147H8, 58623MB w/2048kB Cache, CHS=7473/255/63
> | Floppy drive(s): fd0 is 1.44M
> | FDC 0 is a post-1991 82077
> | Partition check:
> | sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
> | hda: [PTBL] [3739/255/63] hda1
> | hdc: hdc1
> | apm: BIOS version 1.2 Flags 0x07 (Driver version 1.13)
>
> Short version of lspci:
>
> | 00:00.0 Host bridge: VIA Technologies, Inc. VT82C597 [Apollo VP3] (rev 04)
> | 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
> | 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586 ISA [Apollo VP] (rev 41)
> | 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
> | 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 02)
> | 00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
> | 00:08.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 03)
> | 00:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21140
>[FasterNet] (rev 22)
> | 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP [Millennium
>G200 AGP] (rev 01)
>
> I've included "hdparm" and "lspci -vvxxx" output below, omitting
> non-chipset related things (SCSI, Ethernet, and VGA). If it matters,
> this board is running 100MHz FSB with a 450MHz K6-3 CPU and 384MB (3 x
> 128MB DIMMs) of PC-100 SDRAM.
>
> If I can provide any more information, please don't hesitate to ask.
>
> Thanks,
> t.
>
> hdparm output:
>
> | # for i in hda hdc ; do hdparm /dev/$i ; hdparm -i /dev/$i ; done
> |
> | /dev/hda:
> | multcount= 0 (off)
> | I/O support = 0 (default 16-bit)
> | unmaskirq= 0 (off)
> | using_dma= 0 (off)
> | keepsettings = 0 (off)
> | nowerr = 0 (off)
> | readonly = 0 (off)
> | readahead= 8 (on)
> | geometry = 3739/255/63, sectors = 60074784, start = 0
> |
> | /dev/hda:
> |
> | Model=WDC WD307AA, FwRev=05.05B05, SerialNo=WD-WMA11
> | Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
> | RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
> | BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
> | DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=0(slow)
> | CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=60074784
> | tDMA={min:120,rec:120}, DMA modes: mword0 mword1 *mword2
> | IORDY=on/off,
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 11:47:41PM +, Alan Cox wrote: > > However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets. > > That's because all VIA chipsets starting from vt82c586 to vt82c686b > > (UDMA100), share the same PCI ID. > > I have no reports of problems with the later stuff At least the one you sent to me is about 586b. Which is the later stuff. > > Would you prefer to filter just vt82c586 and vt82c586a as the comment in > > Alan's code says or simply unconditionally kill autodma on all of VIA > > chipsets, as Alan's code does? > > I'd take a 2.2 patch to cut down the range too I can make one for you, but first I'd like to find out what exactly are the problem cases. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Hi!
I think that with 2.4.0 your board will operate just fine at UDMA33. If
you can, please do test that. Best mount your drives read only at first,
but I doubt there will be any problems.
Vojtech
On Fri, Jan 12, 2001 at 08:03:49PM -0700, Tkil wrote:
Alan asked:
I think its significant that two reports I have are FIC PA-2013 but
not all. What combination of chips is on the 2013 ?
My board here is a FIC PA-2013A (if I recall correctly; the
motherboard only has "PA-2013" on it, no "A") rev 1.1.
It's worth noting that there is at least another full revision level
(2.x), and the BIOSes for these different revisions are *not*
compatible (as I found out to my chagrin ;-).
Also, the FIC PA-513 (maybe 512?) should be a very similar board, only
wired for an AT power supply where the PA-2013 is an ATX board.
I've never seen the DMA data corruption on this box, but I'd really
really like to get something better than 3MB/s off my UDMA/66-capable
drives. I'm pretty sure that (prior to the 2.2.18 squelching of all
VIA IDE UDMA) that hda and hdc would come up with DMA enabled, at the
very least. Is there a safe way to test various hdparm settings? I'm
even willing to buy a scratch disk if that would help...
Looking at the chips, I have:
1. VIA
VT82C598MVP
9828CE Taiwan
13G003900
2. VIA
VT82C586B
S7-SB
9826CD Taiwan
14B013511
It has an Award BIOS with a variety of WinBond support chips (looks
like at least 4 on-board cache chips, and one near the BIOS EEPROM).
Here's the relevant dmesg bits:
| PCI: PCI BIOS revision 2.10 entry at 0xfb490
| PCI: Using configuration type 1
| PCI: Probing PCI hardware
| PCI: 00:38 [1106/0586]: Work around ISA DMA hangs (00)
| Activating ISA DMA hang workarounds.
| Detected PS/2 Mouse Port.
| Serial driver version 4.27 with no serial options enabled
| ttyS00 at 0x03f8 (irq = 4) is a 16550A
| ttyS01 at 0x02f8 (irq = 3) is a 16550A
| Real Time Clock Driver v1.09
| VP_IDE: IDE controller on PCI bus 00 dev 39
| VP_IDE: not 100% native mode: will probe irqs later
| ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
| ide0: VIA Bus-Master (U)DMA Timing Config Success
| ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA
| ide1: VIA Bus-Master (U)DMA Timing Config Success
| hda: WDC WD307AA, ATA DISK drive
| hdc: Maxtor 96147H8, ATA DISK drive
| ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
| ide1 at 0x170-0x177,0x376 on irq 15
| hda: WDC WD307AA, 29333MB w/2048kB Cache, CHS=59598/16/63
| hdc: Maxtor 96147H8, 58623MB w/2048kB Cache, CHS=7473/255/63
| Floppy drive(s): fd0 is 1.44M
| FDC 0 is a post-1991 82077
| Partition check:
| sda: sda1 sda2 sda3 sda5 sda6 sda7
| hda: [PTBL] [3739/255/63] hda1
| hdc: hdc1
| apm: BIOS version 1.2 Flags 0x07 (Driver version 1.13)
Short version of lspci:
| 00:00.0 Host bridge: VIA Technologies, Inc. VT82C597 [Apollo VP3] (rev 04)
| 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
| 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586 ISA [Apollo VP] (rev 41)
| 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
| 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 02)
| 00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
| 00:08.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 03)
| 00:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21140
[FasterNet] (rev 22)
| 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP [Millennium
G200 AGP] (rev 01)
I've included "hdparm" and "lspci -vvxxx" output below, omitting
non-chipset related things (SCSI, Ethernet, and VGA). If it matters,
this board is running 100MHz FSB with a 450MHz K6-3 CPU and 384MB (3 x
128MB DIMMs) of PC-100 SDRAM.
If I can provide any more information, please don't hesitate to ask.
Thanks,
t.
hdparm output:
| # for i in hda hdc ; do hdparm /dev/$i ; hdparm -i /dev/$i ; done
|
| /dev/hda:
| multcount= 0 (off)
| I/O support = 0 (default 16-bit)
| unmaskirq= 0 (off)
| using_dma= 0 (off)
| keepsettings = 0 (off)
| nowerr = 0 (off)
| readonly = 0 (off)
| readahead= 8 (on)
| geometry = 3739/255/63, sectors = 60074784, start = 0
|
| /dev/hda:
|
| Model=WDC WD307AA, FwRev=05.05B05, SerialNo=WD-WMA11
| Config={ HardSect NotMFM HdSw15uSec SpinMotCtl Fixed DTR5Mbs FmtGapReq }
| RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
| BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
| DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=0(slow)
| CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=60074784
| tDMA={min:120,rec:120}, DMA modes: mword0 mword1 *mword2
| IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4
|
|
| /dev/hdc:
| multcount= 0 (off)
| I/O support = 0 (default
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 04:52:00PM -0800, Linus Torvalds wrote: On Fri, 12 Jan 2001, John Heil wrote: On Sat, 13 Jan 2001, Alan Cox wrote: Date: Sat, 13 Jan 2001 00:25:28 + (GMT) From: Alan Cox [EMAIL PROTECTED] To: Linus Torvalds [EMAIL PROTECTED] Cc: Vojtech Pavlik [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: ide.2.4.1-p3.01112001.patch what the bug is, and whether there is some other work-around, and whether it is 100% certain that it is just those two controllers (maybe the other ones are buggy too, but the 2.2.x tests basically cured their symptoms too and peopl ehaven't reported them because they are "fixed"). I've not seen reports on the later chips. If they had been buggy and then fixed I'd have expected much unhappy ranting before the change The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda. Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon. Careful. It may be that your fix just avoids the corruption because the other changes make it ok - like the 16-sector multi-count thing maybe hides a problem that might still exist - it just changes the "normal" timing so that you won't ever see it in practice any more. These kinds of magic interactions is why I'm not at all happy about driver changes until people really know what it was that caused it, and _know_ that it's gone. Anyway, for you the problem apparently happened even on a 686a, but just the 586 series. Correct? Yes, but this is a different problem. No corruption was happening here. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 11:47:41PM +, Alan Cox wrote: However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets. That's because all VIA chipsets starting from vt82c586 to vt82c686b (UDMA100), share the same PCI ID. I have no reports of problems with the later stuff At least the one you sent to me is about 586b. Which is the later stuff. Would you prefer to filter just vt82c586 and vt82c586a as the comment in Alan's code says or simply unconditionally kill autodma on all of VIA chipsets, as Alan's code does? I'd take a 2.2 patch to cut down the range too I can make one for you, but first I'd like to find out what exactly are the problem cases. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 11:43:23PM +, Alan Cox wrote: I'd like to hear about such reports so that I can start debugging (and perhaps get me one of those failing boards, they must be quite cheap these days). This is one of the most precise reports I have |The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks. The |size of hda is 4.3 GB, the size of hdb is 854 MB and the size of hdc is |1.2 GB. Hdd is an IDE CDROM drive I think its significant that two reports I have are FIC PA-2013 but not all. What combination of chips is on the 2013 ? As far as I know the same as on FIC VA-503+, that is vt82c598 north and vt82c586b south - the MVP3 chipset. I've got the VA-503+ here and it works really well. the 503+ and the 2013 differ only in form factor, one is Baby AT (503+) and the other is ATX. It's vt82c586b, and most probably 3041 silicon - the most bugless VIA southbridge I know of ... Weird. Could the person who reported it test the 2.4.0 kernel? I think the 2.2 drivers had some MVP3 (and 3041 silicon) related bugs. 3041 has some registers layed out differently from all other chips. Btw, this is not the 586 nor 586a, so changing the test to test for just these two probably won't be the right thing to do ... -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sat, Jan 13, 2001 at 02:43:30AM +, [EMAIL PROTECTED] wrote: |The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks. The |size of hda is 4.3 GB, the size of hdb is 854 MB and the size of hdc is |1.2 GB. Hdd is an IDE CDROM drive I think its significant that two reports I have are FIC PA-2013 but not all. What combination of chips is on the 2013 ? The FIC PA-2013 is one of the stranger types of MVP3. (A mixture of 82c597 host bridge and 82c598 PCI bridge). 598 + 586b As discussed some time ago on this list, there are some of these boards, which initially seem to be an MVP3, but have the host bridge ID set to an VP3. (Real reasoning behind this never figured out). Windows driver compatibility, so that VP3 drivers would work on MVP3 as well. 2.4 has code in the pci quirks to disable the register which makes the chip masquerade as a VP3, and forces it to identify itself as an MVP3 part. I'm curious whether this has an interaction here. This doesn't do anything but change the ID so that Linux drivers are not confused anymore. This caused a lot of trouble in 2.2, especially with the old VIA IDE driver. I have a list of known 'hybrid' boards, and known true (both halves) MVP3 boards and also a collection of lspci -xxx outputs from a selection of them. If anyone wants any of this stuff, shout and I'll put it up for ftp/www. Actually, the definitions of what's a 'true VIA xxx chipset' change over time, as VIA upgrades the southbridges in the specs. You'll now fing that the VPX chipset is 587vpx + 586b, but when released the 587vpx was coupled with the old 586 south. Fortunately all these chips use PIIX-compatible extensions to the PCI bus, so they are all interchangeable to some degree. I'm curious if all of the other boards in Alans bug reports also fall into the stranger category. It's possible. I have a board (VA-503A), which has a masqueraded 598, which identifies itself as 597, and a 686a southbridge. This got the 2.2 ide driver completely confused, for example. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 04:09:22PM -0800, Linus Torvalds wrote:
On Fri, 12 Jan 2001, Vojtech Pavlik wrote:
However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets.
That's because all VIA chipsets starting from vt82c586 to vt82c686b
(UDMA100), share the same PCI ID.
Would you prefer to filter just vt82c586 and vt82c586a as the comment in
Alan's code says or simply unconditionally kill autodma on all of VIA
chipsets, as Alan's code does?
Right now, for 2.4.1, I'd rather have the patch to just do the same as
2.2.x. We can figure it out better when we get a better idea of exactly
what the bug is, and whether there is some other work-around, and whether
it is 100% certain that it is just those two controllers (maybe the other
ones are buggy too, but the 2.2.x tests basically cured their symptoms too
and peopl ehaven't reported them because they are "fixed").
Linus
Ok, here goes the patch.
Note that with this patch, all VIA users will get IDE transferrates
about 3 MB/sec as opposed to about 20 MB/sec without it (and with
UDMA66).
This patch disables automatic DMA on all VIA chipsets, including the
ancient 82c561 for 486's, and up to the 686a UDMA66 chipset.
Also note that enabling the DMA later with hdparm -X66 -d1 or similar
command is not safe, and usually works by pure luck on VIA chipsets.
This however, would need some non-minor changes to the generic code to
fix.
But perhaps it's still worth ...
--
Vojtech Pavlik
SuSE Labs
diff -urN linux-old/drivers/ide/ide-pci.c linux/drivers/ide/ide-pci.c
--- linux-old/drivers/ide/ide-pci.c Wed Jan 3 01:58:45 2001
+++ linux/drivers/ide/ide-pci.c Sat Jan 13 14:54:53 2001
@@ -663,7 +663,9 @@
if (IDE_PCI_DEVID_EQ(d-devid, DEVID_SIS5513) ||
IDE_PCI_DEVID_EQ(d-devid, DEVID_AEC6260) ||
IDE_PCI_DEVID_EQ(d-devid, DEVID_PIIX4NX) ||
- IDE_PCI_DEVID_EQ(d-devid, DEVID_HPT34X))
+ IDE_PCI_DEVID_EQ(d-devid, DEVID_HPT34X) ||
+ IDE_PCI_DEVID_EQ(d-devid, DEVID_VIA_IDE) ||
+ IDE_PCI_DEVID_EQ(d-devid, DEVID_VP_IDE))
autodma = 0;
if (autodma)
hwif-autodma = 1;
diff -urN linux-old/drivers/ide/via82cxxx.c linux/drivers/ide/via82cxxx.c
--- linux-old/drivers/ide/via82cxxx.c Tue Nov 7 20:02:24 2000
+++ linux/drivers/ide/via82cxxx.c Sat Jan 13 14:52:26 2001
@@ -602,7 +602,6 @@
#ifdef CONFIG_BLK_DEV_IDEDMA
if (hwif-dma_base) {
hwif-dmaproc = via82cxxx_dmaproc;
- hwif-autodma = 1;
}
#endif /* CONFIG_BLK_DEV_IDEDMA */
}
Re: ide.2.4.1-p3.01112001.patch
v I can make one for you, but first I'd like to find out what exactly are
v the problem cases.
I have a VT82C686 motherboard. It has one UDMA-100 slot and two
regular IDE slots. I have an IBM DTTA-371440 (about 18 months old) as
hda (only fat32 filesystems), and an IBM DTLA-307030 as hde
(i.e. plugged into the UDMA-100 slot). I've never seen any problems
with DMA on the newer drive, but if I turn on DMA and do anything with
the older drive, I get stuff like this:
/dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
The driver attempts to reset ide0 a few times, gets more of the above,
then gives up with an I/O error.
I've been seeing these problems as long as I've been tracking the 2.3
series, up to and including 2.4.0. I can't boot a 2.2 kernel on this
machine to compare, as it doesn't recognise hde (which is where Linux
lives).
Here's the output of lspci under 2.4.0, in case it's useful:
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:09.0 CardBus bridge: Texas Instruments PCI1225 (rev 01)
00:09.1 CardBus bridge: Texas Instruments PCI1225 (rev 01)
00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 08)
00:0b.1 Input device controller: Creative Labs SB Live! (rev 08)
00:11.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device
0d30 (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0150 (rev a3)
If you need any more information, I can dig it out.
b
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Hi!
This is not the case I'm looking for. You have a 686b, a chip that is
not supported in 2.4.0 yet. You can try the via 3.11 driver I posted a
while ago, it adds support for this chip, including UDMA100.
Thanks anyway,
Vojtech
On Sat, Jan 13, 2001 at 09:09:05AM -0800, Bryan O'Sullivan wrote:
v I can make one for you, but first I'd like to find out what exactly are
v the problem cases.
I have a VT82C686 motherboard. It has one UDMA-100 slot and two
regular IDE slots. I have an IBM DTTA-371440 (about 18 months old) as
hda (only fat32 filesystems), and an IBM DTLA-307030 as hde
(i.e. plugged into the UDMA-100 slot). I've never seen any problems
with DMA on the newer drive, but if I turn on DMA and do anything with
the older drive, I get stuff like this:
/dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
The driver attempts to reset ide0 a few times, gets more of the above,
then gives up with an I/O error.
I've been seeing these problems as long as I've been tracking the 2.3
series, up to and including 2.4.0. I can't boot a 2.2 kernel on this
machine to compare, as it doesn't recognise hde (which is where Linux
lives).
Here's the output of lspci under 2.4.0, in case it's useful:
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:09.0 CardBus bridge: Texas Instruments PCI1225 (rev 01)
00:09.1 CardBus bridge: Texas Instruments PCI1225 (rev 01)
00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 08)
00:0b.1 Input device controller: Creative Labs SB Live! (rev 08)
00:11.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device
0d30 (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0150 (rev a3)
If you need any more information, I can dig it out.
b
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On 12 Jan 2001, Linus Torvalds wrote: In short, let's leave it out of a stable kernel for now, and add blacklisting of auto-DMA. Alan has a list. We can play around with trying to _fix_ DMA on the VIA chipsets in 2.5.x (and possibly backport the thing once it has been sufficiently battletested that people believe it truly will work). Please can we also stop HPT366 from attempting UDMA66 on the IBM DTLA drives, while we're at it? I don't care if it's done by blacklisting the DTLA drives, as was done by the patch I resent numerous times, or if it's done the other way round by putting known-compatible drives (include "FUJITSU MPE3136AT") into a whitelist. But it needs doing. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
David Woodhouse writes: Please can we also stop HPT366 from attempting UDMA66 on the IBM DTLA drives, while we're at it? I don't care if it's done by blacklisting the DTLA drives, as was done by the patch I resent numerous times, or if it's done the other way round by putting known-compatible drives (include "FUJITSU MPE3136AT") into a whitelist. But it needs doing. I've been wondering recently why there isn't an option to tell the kernel "even if you've been configured to use dma by default, please don't on this IDE interface". There is an option for tuning the interface up, but nothing to tune down. It strikes me that this might be a good thing to have. Comments? _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
if (IDE_PCI_DEVID_EQ(d-devid, DEVID_SIS5513) ||
IDE_PCI_DEVID_EQ(d-devid, DEVID_AEC6260) ||
IDE_PCI_DEVID_EQ(d-devid, DEVID_PIIX4NX) ||
- IDE_PCI_DEVID_EQ(d-devid, DEVID_HPT34X))
+ IDE_PCI_DEVID_EQ(d-devid, DEVID_HPT34X) ||
+ IDE_PCI_DEVID_EQ(d-devid, DEVID_VIA_IDE) ||
+ IDE_PCI_DEVID_EQ(d-devid, DEVID_VP_IDE))
autodma = 0;
if (autodma)
hwif-autodma = 1;
How about
!force_dma)
__setup("force_dma") ...
So those who want to play fast can
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
COOL!
This will kill the VIA problem and allow us to clobber the timeout.
I know where and what to do but it is the how with the current mess of the
driver held togather with duct tape and paper clips and a little bit of
spit here and there.
I can not wait for 2.5 to get started to begin with "rm -rf ./drivers/ide"
and start with "mkdir ./drivers/ata" ;-)) Okay not quite that radical but
very close
On Sat, 13 Jan 2001, Alan Cox wrote:
if (IDE_PCI_DEVID_EQ(d-devid, DEVID_SIS5513) ||
IDE_PCI_DEVID_EQ(d-devid, DEVID_AEC6260) ||
IDE_PCI_DEVID_EQ(d-devid, DEVID_PIIX4NX) ||
- IDE_PCI_DEVID_EQ(d-devid, DEVID_HPT34X))
+ IDE_PCI_DEVID_EQ(d-devid, DEVID_HPT34X) ||
+ IDE_PCI_DEVID_EQ(d-devid, DEVID_VIA_IDE) ||
+ IDE_PCI_DEVID_EQ(d-devid, DEVID_VP_IDE))
autodma = 0;
if (autodma)
hwif-autodma = 1;
How about
!force_dma)
__setup("force_dma") ...
So those who want to play fast can
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Andre Hedrick
Linux ATA Development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
With vt86c686b (AOpen AK73Pro) I am having a strange problem. When accessing disks old-fashioned way (/dev/hdaN or /dev/hdcN) I do not see corruption, but writing to a RAID-1 made out of them produces corrupted results. Does RAID code access the underlying block device the same way as single partitions are accessed from the userland? My test goes like this: cd / raidstop /dev/md2 # Baseline: single device case seem to work OK # with both 2.1e and 3.11 for dev in a7 c7 do mke2fs /dev/hd$dev mount /dev/hd$dev /mnt tar cf - usr | ( cd /mnt tar xfp - ) sync umount /mnt mount -o ro /dev/hd$dev /mnt tar cf - usr | ( cd /mnt tar df - ) # no problem reported from `tar df' umount /mnt done # RAID-1 /dev/md2 is built out of /dev/hda7 and /dev/hdc7 # not quite, but exact `force' switch withheld :-) mkraid /dev/md2 # wait until /proc/mdstat says /dev/md2 is fully reconstructed mke2fs /dev/md2 mount /dev/md2 /mnt tar cf - usr | ( cd /mnt tar xfp - ) sync umount /mnt mount -o ro /dev/md2 /mnt tar cf - usr | ( cd /mnt tar df - ) # many errors. umount /mnt raidstop /dev/md2 sync mkdir -p /mnt/1 /mnt/2 mount -o ro /dev/hda7 /mnt/1 mount -o ro /dev/hdc7 /mnt/2 tar cf - usr | ( cd /mnt/1 tar df - ) # many differences. tar cf - usr | ( cd /mnt/2 tar df - ) # many differences. umount /dev/hda7 umount /dev/hdc7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
From kufel!ankry Sun Jan 14 00:30:25 2001 Return-Path: kufel!ankry Received: from kufel.UUCP (uucp@localhost) by green.mif.pg.gda.pl (8.9.3/8.9.3) with UUCP id AAA00889 for green.mif.pg.gda.pl!ankry; Sun, 14 Jan 2001 00:30:25 +0100 Received: (from ankry@localhost) by kufel.dom (8.9.3/8.9.3) id WAA01107 for green!ankry; Sat, 13 Jan 2001 22:00:40 +0100 From: Andrzej Krzysztofowicz kufel!ankry Message-Id: [EMAIL PROTECTED] Subject: Re: ide.2.4.1-p3.01112001.patch To: kufel!green.mif.pg.gda.pl!ankry Date: Sat, 13 Jan 2001 22:00:40 +0100 (CET) In-Reply-To: [EMAIL PROTECTED] from "Vojtech Pavlik" at Jan 13, 2001 02:42:36 PM X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [EMAIL PROTECTED] (Vojtech Pavlik) 2.4 has code in the pci quirks to disable the register which makes the chip masquerade as a VP3, and forces it to identify itself as an MVP3 part. I'm curious whether this has an interaction here. This doesn't do anything but change the ID so that Linux drivers are not confused anymore. This caused a lot of trouble in 2.2, especially with the old VIA IDE driver. [...] Fortunately all these chips use PIIX-compatible extensions to the PCI bus, so they are all interchangeable to some degree. I'm curious if all of the other boards in Alans bug reports also fall into the stranger category. It's possible. I have a board (VA-503A), which has a masqueraded 598, which identifies itself as 597, and a 686a southbridge. This got the 2.2 ide driver completely confused, for example. Maybe the VIA IDE chipset support option should depend on PCI quirks now ? -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] tel. (0-58) 347 14 61 Wydz.Fizyki Technicznej i Matematyki Stosowanej Politechniki Gdanskiej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Vojtech Pavlik wrote: Ok, here goes the patch. Note that with this patch, all VIA users will get IDE transferrates about 3 MB/sec as opposed to about 20 MB/sec without it (and with UDMA66). This patch disables automatic DMA on all VIA chipsets, including the ancient 82c561 for 486's, and up to the 686a UDMA66 chipset. Also note that enabling the DMA later with hdparm -X66 -d1 or similar command is not safe, and usually works by pure luck on VIA chipsets. This however, would need some non-minor changes to the generic code to fix. But perhaps it's still worth ... -- Vojtech Pavlik SuSE Labs _ouch_ Will -X66 -d1c1m16 be as stable with this patch as version 2.1e has been for me?? It has always (auto)set transfer speeds properly and I have never seen corruption with my 686a -- 'cept when patching from test11-pre7 to test12-pre1, and I'm pretty sure that was from other factors. === -- Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
In-Reply-To: [EMAIL PROTECTED]
In article [EMAIL PROTECTED], [EMAIL PROTECTED]
(Bryan O'Sullivan) wrote:
/dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 {
DriveReady SeekComplete Error } hda: dma_intr: error=0x84 {
DriveStatusError BadCRC } hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error } hda: dma_intr: error=0x84 { DriveStatusError
BadCRC } hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
...
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev
02)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super]
(rev 22)
00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo]
(rev 10)
00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
ACPI] (rev 30)
It's not an Abit KT7 or similar is it?
I was just helping my dad upgrade a machine based with one of those to 2.4
today and until we turned off Generic PCI bus-master DMA Support and the
VIA82CXXX drivers we kept getting the same messages the second the system
booted up.
It was rather annoying, as I'm not sure if it was because of this or
something else, but we ended up with some minor disk corruption mainly
around /usr/src/linux where I made the mistake of doing a make mrproper
while it was like this. Went back to 2.2 temporarily and it was fine.
Can dig out/try anything on request.
TonyP
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On 12 Jan 2001, Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, > Andre Hedrick <[EMAIL PROTECTED]> wrote: > > > >Well that "experimental patch" is designed to get out of the dreaded > >"DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the > >Intel 440*X Chipset groups. Since it appears that their bug was copied > >but other chipset makers..you see the picture clearly, right? > > No. Oh, then I need to explainbut later. > That experimental patch is _experimental_, and has not been reported by > anybody to fix anything at all. Also, the DMA timeout on PIIX4 seems to > have nothing at all to do with the very silent corruption on VIA. At > least nobody has reported any error messages being produced on the VIA > corruption cases. Yes corruption verses deadlock that can wack superblockhummm Two evils, mame or kill one or leave both active... > In short, let's leave it out of a stable kernel for now, and add > blacklisting of auto-DMA. Alan has a list. We can play around with > trying to _fix_ DMA on the VIA chipsets in 2.5.x (and possibly backport > the thing once it has been sufficiently battletested that people believe > it truly will work). Linus we are talking about blacklisting every PIIX4 that is 440BX/GX/LX/NX in this case and that is a major list. VIA has its own problems and that need special cases attention by one person work on always, thus the poor^H^H^H^H bold sucker^H^H^H^H^H^H guy known as Vojtech Pavlik from SuSE is having to much fun Cheers, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Alan asked:
> I think its significant that two reports I have are FIC PA-2013 but
> not all. What combination of chips is on the 2013 ?
My board here is a FIC PA-2013A (if I recall correctly; the
motherboard only has "PA-2013" on it, no "A") rev 1.1.
It's worth noting that there is at least another full revision level
(2.x), and the BIOSes for these different revisions are *not*
compatible (as I found out to my chagrin ;-).
Also, the FIC PA-513 (maybe 512?) should be a very similar board, only
wired for an AT power supply where the PA-2013 is an ATX board.
I've never seen the DMA data corruption on this box, but I'd really
really like to get something better than 3MB/s off my UDMA/66-capable
drives. I'm pretty sure that (prior to the 2.2.18 squelching of all
VIA IDE UDMA) that hda and hdc would come up with DMA enabled, at the
very least. Is there a safe way to test various hdparm settings? I'm
even willing to buy a scratch disk if that would help...
Looking at the chips, I have:
1. VIA
VT82C598MVP
9828CE Taiwan
13G003900
2. VIA
VT82C586B
S7-SB
9826CD Taiwan
14B013511
It has an Award BIOS with a variety of WinBond support chips (looks
like at least 4 on-board cache chips, and one near the BIOS EEPROM).
Here's the relevant dmesg bits:
| PCI: PCI BIOS revision 2.10 entry at 0xfb490
| PCI: Using configuration type 1
| PCI: Probing PCI hardware
| PCI: 00:38 [1106/0586]: Work around ISA DMA hangs (00)
| Activating ISA DMA hang workarounds.
| Detected PS/2 Mouse Port.
| Serial driver version 4.27 with no serial options enabled
| ttyS00 at 0x03f8 (irq = 4) is a 16550A
| ttyS01 at 0x02f8 (irq = 3) is a 16550A
| Real Time Clock Driver v1.09
| VP_IDE: IDE controller on PCI bus 00 dev 39
| VP_IDE: not 100% native mode: will probe irqs later
| ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
| ide0: VIA Bus-Master (U)DMA Timing Config Success
| ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA
| ide1: VIA Bus-Master (U)DMA Timing Config Success
| hda: WDC WD307AA, ATA DISK drive
| hdc: Maxtor 96147H8, ATA DISK drive
| ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
| ide1 at 0x170-0x177,0x376 on irq 15
| hda: WDC WD307AA, 29333MB w/2048kB Cache, CHS=59598/16/63
| hdc: Maxtor 96147H8, 58623MB w/2048kB Cache, CHS=7473/255/63
| Floppy drive(s): fd0 is 1.44M
| FDC 0 is a post-1991 82077
| Partition check:
| sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
| hda: [PTBL] [3739/255/63] hda1
| hdc: hdc1
| apm: BIOS version 1.2 Flags 0x07 (Driver version 1.13)
Short version of lspci:
| 00:00.0 Host bridge: VIA Technologies, Inc. VT82C597 [Apollo VP3] (rev 04)
| 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
| 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586 ISA [Apollo VP] (rev 41)
| 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
| 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 02)
| 00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
| 00:08.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 03)
| 00:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet]
|(rev 22)
| 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP [Millennium
|G200 AGP] (rev 01)
I've included "hdparm" and "lspci -vvxxx" output below, omitting
non-chipset related things (SCSI, Ethernet, and VGA). If it matters,
this board is running 100MHz FSB with a 450MHz K6-3 CPU and 384MB (3 x
128MB DIMMs) of PC-100 SDRAM.
If I can provide any more information, please don't hesitate to ask.
Thanks,
t.
hdparm output:
| # for i in hda hdc ; do hdparm /dev/$i ; hdparm -i /dev/$i ; done
|
| /dev/hda:
| multcount= 0 (off)
| I/O support = 0 (default 16-bit)
| unmaskirq= 0 (off)
| using_dma= 0 (off)
| keepsettings = 0 (off)
| nowerr = 0 (off)
| readonly = 0 (off)
| readahead= 8 (on)
| geometry = 3739/255/63, sectors = 60074784, start = 0
|
| /dev/hda:
|
| Model=WDC WD307AA, FwRev=05.05B05, SerialNo=WD-WMA11
| Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
| RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
| BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
| DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=0(slow)
| CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=60074784
| tDMA={min:120,rec:120}, DMA modes: mword0 mword1 *mword2
| IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4
|
|
| /dev/hdc:
| multcount= 0 (off)
| I/O support = 0 (default 16-bit)
| unmaskirq= 0 (off)
| using_dma= 0 (off)
| keepsettings = 0 (off)
| nowerr = 0 (off)
| readonly = 0 (off)
| readahead= 8 (on)
| geometry = 7473/255/63, sectors = 120060864, start = 0
|
| /dev/hdc:
|
| Model=Maxtor 96147H8, FwRev=BAC51KJ0, SerialNo=N80CP5KC
| Config={ Fixed }
| RawCHS=16383/16/63, TrkSize=0,
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Alan Cox wrote: > |The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks. The > |size of hda is 4.3 GB, the size of hdb is 854 MB and the size of hdc is > |1.2 GB. Hdd is an IDE CDROM drive > > I think its significant that two reports I have are FIC PA-2013 but not all. > What combination of chips is on the 2013 ? The FIC PA-2013 is one of the stranger types of MVP3. (A mixture of 82c597 host bridge and 82c598 PCI bridge). As discussed some time ago on this list, there are some of these boards, which initially seem to be an MVP3, but have the host bridge ID set to an VP3. (Real reasoning behind this never figured out). 2.4 has code in the pci quirks to disable the register which makes the chip masquerade as a VP3, and forces it to identify itself as an MVP3 part. I'm curious whether this has an interaction here. I have a list of known 'hybrid' boards, and known true (both halves) MVP3 boards and also a collection of lspci -xxx outputs from a selection of them. If anyone wants any of this stuff, shout and I'll put it up for ftp/www. I'm curious if all of the other boards in Alans bug reports also fall into the stranger category. regards, Davej. -- | Dave Jones.http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Linus Torvalds wrote: > > > On Fri, 12 Jan 2001, Andre Hedrick wrote: > > > > It works perfectly and exactly as it is defined to work by the rules. > > Getting the rules correct == 'the concept of "working"'. > > Don't be silly. > > You're entirely ignoring the concept of hardware bugs. Which is one very > likely reason for this whole discussion in the first place. First you get the access correct and assume no bugs, round one. After this is fixed, then you address the "hardware bugs" by execption rules and not the basic premis, the endless round. Regards, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Linus Torvalds wrote: > > > On Fri, 12 Jan 2001, Andre Hedrick wrote: > > > > It works perfectly and exactly as it is defined to work by the rules. > > Getting the rules correct == 'the concept of "working"'. > > Don't be silly. > > You're entirely ignoring the concept of hardware bugs. Which is one very > likely reason for this whole discussion in the first place. > > ANYBODY who does driver development without taking the real world into > account is a dangerous person. Stacks of papers, diagrams and rules are > absolutely WORTHLESS if you can't just understand the fact that > documentation is nothing more than a guide-line. > > Once you realize that documentation should be laughed at, peed upon, put > on fire, and just ridiculed in general, THEN, and only then, have you > reached the level where you can safely read it and try to use it to > actually implement a driver. > > I'm continually amazed and absolutely scared silly by your blind trust in > paperwork, whether it be standards or committees or vendor documentation. Test and Verify! It has been abused on an ATA-Analyzer! It was written while running on an ATA-Analyzer! The real world does not get any more real than on an ATA-Analyzer! Since this was a done by direct access with out the FS/VM mess it is an exact method of operation, it is a perfect data-signal trace. Perfect == fits exactly in the boundaries of the state-diagrams. This is how you write code, LT. Follow the rules, and the verify the rules are correct. If they are not, fix it until it is correct and see what happened in the rules. I have offered to get you signed letters of technical certification by the drive makers, and you have declined. The idea of just banging code to get the desired result regardless of public methods published to insure comman design/correctness is all but silly. What do you think timing tables are for, wallpaper or to line the bottom of a bird cage? Sheesh You have to access a PCI-bus, CPU, AGP and all these other things in the correct event windows, or do you? Regards, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Andre Hedrick wrote: > > It works perfectly and exactly as it is defined to work by the rules. > Getting the rules correct == 'the concept of "working"'. Don't be silly. You're entirely ignoring the concept of hardware bugs. Which is one very likely reason for this whole discussion in the first place. ANYBODY who does driver development without taking the real world into account is a dangerous person. Stacks of papers, diagrams and rules are absolutely WORTHLESS if you can't just understand the fact that documentation is nothing more than a guide-line. Once you realize that documentation should be laughed at, peed upon, put on fire, and just ridiculed in general, THEN, and only then, have you reached the level where you can safely read it and try to use it to actually implement a driver. I'm continually amazed and absolutely scared silly by your blind trust in paperwork, whether it be standards or committees or vendor documentation. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Linus Torvalds wrote: > > > On Fri, 12 Jan 2001, Andre Hedrick wrote: > > > > I told you that I have the new code that is scheduled for 2.5 certified on > > analizers to be technically correct as it relates to the "state diagrams" > > in the standard. > > "Technically correct" and "state diagrams as in the standard" mean less > that nothing to me. > > They have very little to do with the concept of "working", which is all I > really personally care about. Translation: You can do a bit level tracking of data and verify that what went down you get it back across the entire disk. This can be done in a random-pattern that does not over-write (obvious) or from head->tail or tail->head. It works perfectly and exactly as it is defined to work by the rules. Getting the rules correct == 'the concept of "working"'. However that model of IO is not complete yet. :-(( Cheers, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Andre Hedrick wrote: > > I told you that I have the new code that is scheduled for 2.5 certified on > analizers to be technically correct as it relates to the "state diagrams" > in the standard. "Technically correct" and "state diagrams as in the standard" mean less that nothing to me. They have very little to do with the concept of "working", which is all I really personally care about. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, John Heil wrote: > > Yes, initially the 686a was problematic, now with an 80 wire cable its > fine. > > One point of clarification... I started out with a simple hdparm -d1 > which failed 85% of the time. I added the other stuff only to enhance the > -d0 state I was left with. This sounds like a totally different thing than the DMA corruption - this sounds like you just got CRC error messages, and the driver still did the right thing? The 82c586 corruption seems to be silently just writing (and maybe reading) bad data to the disk. The case of CRC errors and recivering from them (or fixing them with a good cable) is different - when the CRC errors are noticed, they cause the command to be re-tried and thus no data corruption should occur. Basically it's the difference between being "silently bad" and "noisily good". Sounds like you are in the "noisily good" category - a category that I don't worry about ;) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Linus Torvalds wrote: > > > On Fri, 12 Jan 2001, John Heil wrote: > > > On Sat, 13 Jan 2001, Alan Cox wrote: > > > > > Date: Sat, 13 Jan 2001 00:25:28 + (GMT) > > > From: Alan Cox <[EMAIL PROTECTED]> > > > To: Linus Torvalds <[EMAIL PROTECTED]> > > > Cc: Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > > > Subject: Re: ide.2.4.1-p3.01112001.patch > > > > > > > what the bug is, and whether there is some other work-around, and whether > > > > it is 100% certain that it is just those two controllers (maybe the other > > > > ones are buggy too, but the 2.2.x tests basically cured their symptoms too > > > > and peopl ehaven't reported them because they are "fixed"). > > > > > > I've not seen reports on the later chips. If they had been buggy and then > > > fixed I'd have expected much unhappy ranting before the change > > > > The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda. ^^ There no chipset calls that allow one to envoke 32-bit data access on the data-taskfile register. This may bite you in the arse! (see below) > > Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon. > > Careful. It may be that your fix just avoids the corruption because the > other changes make it ok - like the 16-sector multi-count thing maybe > hides a problem that might still exist - it just changes the "normal" > timing so that you won't ever see it in practice any more. This is why it is better to do on paper the timings and not create code that is varible based on the "ide-bus-clock" not the "pci-bus-clock". You can only run timings at 33MHz clocking, period. The exceptions are for those that can report from the chipset that a clocking-base other than 33 is detected. I told you that I have the new code that is scheduled for 2.5 certified on analizers to be technically correct as it relates to the "state diagrams" in the standard. > These kinds of magic interactions is why I'm not at all happy about driver > changes until people really know what it was that caused it, and _know_ > that it's gone. Linus I know how the driver is to work and how it behaves in non-multimodes, but I am not sure that even Mark Lord could tells you or me about the true nature of the current multimode with various chipsets. Sheesh some of them are now documenting that special bits must be set to do 32-bit word access on the dataport. Cheers, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Linus Torvalds wrote: > Date: Fri, 12 Jan 2001 16:52:00 -0800 (PST) > From: Linus Torvalds <[EMAIL PROTECTED]> > To: John Heil <[EMAIL PROTECTED]> > Cc: Alan Cox <[EMAIL PROTECTED]>, Vojtech Pavlik <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > Subject: Re: ide.2.4.1-p3.01112001.patch > > > > On Fri, 12 Jan 2001, John Heil wrote: > > > On Sat, 13 Jan 2001, Alan Cox wrote: > > > > > Date: Sat, 13 Jan 2001 00:25:28 + (GMT) > > > From: Alan Cox <[EMAIL PROTECTED]> > > > To: Linus Torvalds <[EMAIL PROTECTED]> > > > Cc: Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > > > Subject: Re: ide.2.4.1-p3.01112001.patch > > > > > > > what the bug is, and whether there is some other work-around, and whether > > > > it is 100% certain that it is just those two controllers (maybe the other > > > > ones are buggy too, but the 2.2.x tests basically cured their symptoms too > > > > and peopl ehaven't reported them because they are "fixed"). > > > > > > I've not seen reports on the later chips. If they had been buggy and then > > > fixed I'd have expected much unhappy ranting before the change > > > > The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda. > > Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon. > > Careful. It may be that your fix just avoids the corruption because the > other changes make it ok - like the 16-sector multi-count thing maybe > hides a problem that might still exist - it just changes the "normal" > timing so that you won't ever see it in practice any more. > > These kinds of magic interactions is why I'm not at all happy about driver > changes until people really know what it was that caused it, and _know_ > that it's gone. > > Anyway, for you the problem apparently happened even on a 686a, but just > the 586 series. Correct? Yes, initially the 686a was problematic, now with an 80 wire cable its fine. One point of clarification... I started out with a simple hdparm -d1 which failed 85% of the time. I added the other stuff only to enhance the -d0 state I was left with. I then changed to the 80 wire cables and retried with only -d1 again, and to my surprise, the problems never came back and DMA stayed on. A while later, I added -X66 and it too worked great. Then lastly came the re-add of the rest giving current state. > > Linus > - John Heil South Coast Software Custom systems software for UNIX and IBM MVS mainframes 1-714-774-6952 [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.sc-software.com - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, John Heil wrote: > On Sat, 13 Jan 2001, Alan Cox wrote: > > > Date: Sat, 13 Jan 2001 00:25:28 + (GMT) > > From: Alan Cox <[EMAIL PROTECTED]> > > To: Linus Torvalds <[EMAIL PROTECTED]> > > Cc: Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > > Subject: Re: ide.2.4.1-p3.01112001.patch > > > > > what the bug is, and whether there is some other work-around, and whether > > > it is 100% certain that it is just those two controllers (maybe the other > > > ones are buggy too, but the 2.2.x tests basically cured their symptoms too > > > and peopl ehaven't reported them because they are "fixed"). > > > > I've not seen reports on the later chips. If they had been buggy and then > > fixed I'd have expected much unhappy ranting before the change > > The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda. > Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon. Careful. It may be that your fix just avoids the corruption because the other changes make it ok - like the 16-sector multi-count thing maybe hides a problem that might still exist - it just changes the "normal" timing so that you won't ever see it in practice any more. These kinds of magic interactions is why I'm not at all happy about driver changes until people really know what it was that caused it, and _know_ that it's gone. Anyway, for you the problem apparently happened even on a 686a, but just the 586 series. Correct? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sat, 13 Jan 2001, Alan Cox wrote: > Date: Sat, 13 Jan 2001 00:25:28 + (GMT) > From: Alan Cox <[EMAIL PROTECTED]> > To: Linus Torvalds <[EMAIL PROTECTED]> > Cc: Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: ide.2.4.1-p3.01112001.patch > > > what the bug is, and whether there is some other work-around, and whether > > it is 100% certain that it is just those two controllers (maybe the other > > ones are buggy too, but the 2.2.x tests basically cured their symptoms too > > and peopl ehaven't reported them because they are "fixed"). > > I've not seen reports on the later chips. If they had been buggy and then > fixed I'd have expected much unhappy ranting before the change The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda. Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon. Interestingly, initially feeding that chip 40 wire cables (w/o the -X66 of course) would result in the crc errors followed by DMA turn off, about 85% of time... Other 15% was fine and DMA worked great. I then switched to the 80 wire cable and DMA became rock solid at which point the -X66 was added. Just thought I'd add some data points :) > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - John Heil South Coast Software Custom systems software for UNIX and IBM MVS mainframes 1-714-774-6952 [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.sc-software.com - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
> what the bug is, and whether there is some other work-around, and whether > it is 100% certain that it is just those two controllers (maybe the other > ones are buggy too, but the 2.2.x tests basically cured their symptoms too > and peopl ehaven't reported them because they are "fixed"). I've not seen reports on the later chips. If they had been buggy and then fixed I'd have expected much unhappy ranting before the change - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Vojtech Pavlik wrote: > > However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets. > That's because all VIA chipsets starting from vt82c586 to vt82c686b > (UDMA100), share the same PCI ID. > > Would you prefer to filter just vt82c586 and vt82c586a as the comment in > Alan's code says or simply unconditionally kill autodma on all of VIA > chipsets, as Alan's code does? Right now, for 2.4.1, I'd rather have the patch to just do the same as 2.2.x. We can figure it out better when we get a better idea of exactly what the bug is, and whether there is some other work-around, and whether it is 100% certain that it is just those two controllers (maybe the other ones are buggy too, but the 2.2.x tests basically cured their symptoms too and peopl ehaven't reported them because they are "fixed"). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
> However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets. > That's because all VIA chipsets starting from vt82c586 to vt82c686b > (UDMA100), share the same PCI ID. I have no reports of problems with the later stuff > Would you prefer to filter just vt82c586 and vt82c586a as the comment in > Alan's code says or simply unconditionally kill autodma on all of VIA > chipsets, as Alan's code does? I'd take a 2.2 patch to cut down the range too - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
> I'd like to hear about such reports so that I can start debugging (and > perhaps get me one of those failing boards, they must be quite cheap > these days). This is one of the most precise reports I have |The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks. The |size of hda is 4.3 GB, the size of hdb is 854 MB and the size of hdc is |1.2 GB. Hdd is an IDE CDROM drive I think its significant that two reports I have are FIC PA-2013 but not all. What combination of chips is on the 2013 ? Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Alan Cox wrote: > > I want to see the code to handle the apparent VIA DMA bug. At this point, > > preferably by just disabling DMA on VIA chipsets or something like that > > (if it has only gotten worse since 2.2.x, I'm not interested in seeing any > > experimental patches for it during early 2.4.x). > > It hasnt gotten worse, its just its a very specific combination and its a > well known problem (vendors dont enable auto dma for ide for this reason) > 2.2.16 just covers the cases I know about (and slightly overdoes it for now) > > > We've already had one major fs corruption due to this, I want that fixed > > _first_. > > I've got other reports too. >... At least some of the reported problems with VIA chipsets are fixed with the VIA IDE driver v3.11 [1]. Are there any problems that still occur with this driver? cu, Adrian [1] http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-02/1291.html -- A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 11:57:37AM -0800, Linus Torvalds wrote: > > I've got a vt82c586 here (bought it just for testing of this problem), > > and I wasn't able to create any corruption using that board and the 2.4 > > drivers. > > The fact that it works on one board doesn't mean that it works on _every_ > board. Of course. That's why I'm calling for bug reports. > This is, in fact, why I will _NOT_ accept anything but a simple auto-dma > disable for this problem for early 2.4.x. I hope that people will continue > to work on and debug this problem, but it's just been around for too long, > and it's obvious enough that it doesn't happen with all hardware that I > doubt there is any other reasonable solution that doesn't require some > _very_ extensive testing to verify. > > I'd love to see people who see these problems and are willing to test out > patches to fix it. But in parallel with that, I definitely want the 2.2.x > "disable auto-DMA" thing for the big public. We can enable it later if > some patch does seem to fix it for good. Sure. However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets. That's because all VIA chipsets starting from vt82c586 to vt82c686b (UDMA100), share the same PCI ID. Would you prefer to filter just vt82c586 and vt82c586a as the comment in Alan's code says or simply unconditionally kill autodma on all of VIA chipsets, as Alan's code does? -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Vojtech Pavlik wrote: > > I've got a vt82c586 here (bought it just for testing of this problem), > and I wasn't able to create any corruption using that board and the 2.4 > drivers. The fact that it works on one board doesn't mean that it works on _every_ board. This is, in fact, why I will _NOT_ accept anything but a simple auto-dma disable for this problem for early 2.4.x. I hope that people will continue to work on and debug this problem, but it's just been around for too long, and it's obvious enough that it doesn't happen with all hardware that I doubt there is any other reasonable solution that doesn't require some _very_ extensive testing to verify. I'd love to see people who see these problems and are willing to test out patches to fix it. But in parallel with that, I definitely want the 2.2.x "disable auto-DMA" thing for the big public. We can enable it later if some patch does seem to fix it for good. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 10:55:22AM -0800, Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, > Andre Hedrick <[EMAIL PROTECTED]> wrote: > > > >Well that "experimental patch" is designed to get out of the dreaded > >"DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the > >Intel 440*X Chipset groups. Since it appears that their bug was copied > >but other chipset makers..you see the picture clearly, right? > > No. > > That experimental patch is _experimental_, and has not been reported by > anybody to fix anything at all. Also, the DMA timeout on PIIX4 seems to > have nothing at all to do with the very silent corruption on VIA. At > least nobody has reported any error messages being produced on the VIA > corruption cases. > > In short, let's leave it out of a stable kernel for now, and add > blacklisting of auto-DMA. Alan has a list. We can play around with > trying to _fix_ DMA on the VIA chipsets in 2.5.x (and possibly backport > the thing once it has been sufficiently battletested that people believe > it truly will work). I've got a vt82c586 here (bought it just for testing of this problem), and I wasn't able to create any corruption using that board and the 2.4 drivers. Does anyone still have any vt82c586 or vt82c586a the 2.4 VIA driver is corrupting data on? I'd like to hear about such reports so that I can start debugging (and perhaps get me one of those failing boards, they must be quite cheap these days). -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
In article <[EMAIL PROTECTED]>, Andre Hedrick <[EMAIL PROTECTED]> wrote: > >Well that "experimental patch" is designed to get out of the dreaded >"DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the >Intel 440*X Chipset groups. Since it appears that their bug was copied >but other chipset makers..you see the picture clearly, right? No. That experimental patch is _experimental_, and has not been reported by anybody to fix anything at all. Also, the DMA timeout on PIIX4 seems to have nothing at all to do with the very silent corruption on VIA. At least nobody has reported any error messages being produced on the VIA corruption cases. In short, let's leave it out of a stable kernel for now, and add blacklisting of auto-DMA. Alan has a list. We can play around with trying to _fix_ DMA on the VIA chipsets in 2.5.x (and possibly backport the thing once it has been sufficiently battletested that people believe it truly will work). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>
>The PCI ids I kill autodma on for 2.2 to cover this are:
>
>/*
> * Don't try and tune a VIA 82C586 or 586A
> */
>if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_IDE))
>{
>autodma_default = 0;
>break;
>}
>if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_OLDIDE))
>{
>autodma_default = 0;
>break;
>}
>
>
>PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_82C586_0
>PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_82C586_1
Can I get a patch, Andre?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Linus Torvalds wrote: > > > On Fri, 12 Jan 2001, Andre Hedrick wrote: > > > > Scratch that patch it has 2 typos that are in amd74xx.c > > > > will do it again.. > > I will scratch your new patch too. > > I want to see the code to handle the apparent VIA DMA bug. At this point, > preferably by just disabling DMA on VIA chipsets or something like that > (if it has only gotten worse since 2.2.x, I'm not interested in seeing any > experimental patches for it during early 2.4.x). Well that "experimental patch" is designed to get out of the dreaded "DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the Intel 440*X Chipset groups. Since it appears that their bug was copied but other chipset makers..you see the picture clearly, right? > We've already had one major fs corruption due to this, I want that fixed > _first_. Well since I do not have VIA boards and Vojtech Pavlik <[EMAIL PROTECTED]> is doing that chipset, take that issue to him. VIA has always been a HACK fro mthe beginning because it was written off the whitepapers that stink. The AMD and HPT366 code were to be in 2.4.0 release, but the early surprize caused most to be off guard. I will pull the TIMEOUT but this is one you have bitched me out before about not fixing or attempting to fix. You can not have it both ways. This is why I made it a compile option and not default. I have one report that it does not helpthus I changed it to a compile option. Yes one report took it from mainstream to option. Cheers, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
> I want to see the code to handle the apparent VIA DMA bug. At this point,
> preferably by just disabling DMA on VIA chipsets or something like that
> (if it has only gotten worse since 2.2.x, I'm not interested in seeing any
> experimental patches for it during early 2.4.x).
It hasnt gotten worse, its just its a very specific combination and its a
well known problem (vendors dont enable auto dma for ide for this reason)
2.2.16 just covers the cases I know about (and slightly overdoes it for now)
> We've already had one major fs corruption due to this, I want that fixed
> _first_.
I've got other reports too.
The PCI ids I kill autodma on for 2.2 to cover this are:
/*
* Don't try and tune a VIA 82C586 or 586A
*/
if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_IDE))
{
autodma_default = 0;
break;
}
if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_OLDIDE))
{
autodma_default = 0;
break;
}
PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_82C586_0
PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_82C586_1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Andre Hedrick wrote: > > Scratch that patch it has 2 typos that are in amd74xx.c > > will do it again.. I will scratch your new patch too. I want to see the code to handle the apparent VIA DMA bug. At this point, preferably by just disabling DMA on VIA chipsets or something like that (if it has only gotten worse since 2.2.x, I'm not interested in seeing any experimental patches for it during early 2.4.x). We've already had one major fs corruption due to this, I want that fixed _first_. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Scratch that patch it has 2 typos that are in amd74xx.c will do it again.. Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 12:44:25AM -0800, Andre Hedrick wrote: > > AMD Update. > HPT366 Update. > > NASTY-ARSE dma-timeout "hack" as a compile option. [snip] ide_dma_timeout_revovery ? s/revovery/recovery/ perhaps? Cheers, --Craig - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Scratch that patch it has 2 typos that are in amd74xx.c will do it again.. Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 12:44:25AM -0800, Andre Hedrick wrote: AMD Update. HPT366 Update. NASTY-ARSE dma-timeout "hack" as a compile option. [snip] ide_dma_timeout_revovery ? s/revovery/recovery/ perhaps? Cheers, --Craig - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Andre Hedrick wrote: Scratch that patch it has 2 typos that are in amd74xx.c will do it again.. I will scratch your new patch too. I want to see the code to handle the apparent VIA DMA bug. At this point, preferably by just disabling DMA on VIA chipsets or something like that (if it has only gotten worse since 2.2.x, I'm not interested in seeing any experimental patches for it during early 2.4.x). We've already had one major fs corruption due to this, I want that fixed _first_. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
I want to see the code to handle the apparent VIA DMA bug. At this point,
preferably by just disabling DMA on VIA chipsets or something like that
(if it has only gotten worse since 2.2.x, I'm not interested in seeing any
experimental patches for it during early 2.4.x).
It hasnt gotten worse, its just its a very specific combination and its a
well known problem (vendors dont enable auto dma for ide for this reason)
2.2.16 just covers the cases I know about (and slightly overdoes it for now)
We've already had one major fs corruption due to this, I want that fixed
_first_.
I've got other reports too.
The PCI ids I kill autodma on for 2.2 to cover this are:
/*
* Don't try and tune a VIA 82C586 or 586A
*/
if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_IDE))
{
autodma_default = 0;
break;
}
if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_OLDIDE))
{
autodma_default = 0;
break;
}
PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_82C586_0
PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_82C586_1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Linus Torvalds wrote: On Fri, 12 Jan 2001, Andre Hedrick wrote: Scratch that patch it has 2 typos that are in amd74xx.c will do it again.. I will scratch your new patch too. I want to see the code to handle the apparent VIA DMA bug. At this point, preferably by just disabling DMA on VIA chipsets or something like that (if it has only gotten worse since 2.2.x, I'm not interested in seeing any experimental patches for it during early 2.4.x). Well that "experimental patch" is designed to get out of the dreaded "DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the Intel 440*X Chipset groups. Since it appears that their bug was copied but other chipset makers..you see the picture clearly, right? We've already had one major fs corruption due to this, I want that fixed _first_. Well since I do not have VIA boards and Vojtech Pavlik [EMAIL PROTECTED] is doing that chipset, take that issue to him. VIA has always been a HACK fro mthe beginning because it was written off the whitepapers that stink. The AMD and HPT366 code were to be in 2.4.0 release, but the early surprize caused most to be off guard. I will pull the TIMEOUT but this is one you have bitched me out before about not fixing or attempting to fix. You can not have it both ways. This is why I made it a compile option and not default. I have one report that it does not helpthus I changed it to a compile option. Yes one report took it from mainstream to option. Cheers, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
In article [EMAIL PROTECTED],
Alan Cox [EMAIL PROTECTED] wrote:
The PCI ids I kill autodma on for 2.2 to cover this are:
/*
* Don't try and tune a VIA 82C586 or 586A
*/
if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_IDE))
{
autodma_default = 0;
break;
}
if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_OLDIDE))
{
autodma_default = 0;
break;
}
PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_82C586_0
PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_82C586_1
Can I get a patch, Andre?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
In article [EMAIL PROTECTED], Andre Hedrick [EMAIL PROTECTED] wrote: Well that "experimental patch" is designed to get out of the dreaded "DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the Intel 440*X Chipset groups. Since it appears that their bug was copied but other chipset makers..you see the picture clearly, right? No. That experimental patch is _experimental_, and has not been reported by anybody to fix anything at all. Also, the DMA timeout on PIIX4 seems to have nothing at all to do with the very silent corruption on VIA. At least nobody has reported any error messages being produced on the VIA corruption cases. In short, let's leave it out of a stable kernel for now, and add blacklisting of auto-DMA. Alan has a list. We can play around with trying to _fix_ DMA on the VIA chipsets in 2.5.x (and possibly backport the thing once it has been sufficiently battletested that people believe it truly will work). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 10:55:22AM -0800, Linus Torvalds wrote: In article [EMAIL PROTECTED], Andre Hedrick [EMAIL PROTECTED] wrote: Well that "experimental patch" is designed to get out of the dreaded "DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the Intel 440*X Chipset groups. Since it appears that their bug was copied but other chipset makers..you see the picture clearly, right? No. That experimental patch is _experimental_, and has not been reported by anybody to fix anything at all. Also, the DMA timeout on PIIX4 seems to have nothing at all to do with the very silent corruption on VIA. At least nobody has reported any error messages being produced on the VIA corruption cases. In short, let's leave it out of a stable kernel for now, and add blacklisting of auto-DMA. Alan has a list. We can play around with trying to _fix_ DMA on the VIA chipsets in 2.5.x (and possibly backport the thing once it has been sufficiently battletested that people believe it truly will work). I've got a vt82c586 here (bought it just for testing of this problem), and I wasn't able to create any corruption using that board and the 2.4 drivers. Does anyone still have any vt82c586 or vt82c586a the 2.4 VIA driver is corrupting data on? I'd like to hear about such reports so that I can start debugging (and perhaps get me one of those failing boards, they must be quite cheap these days). -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Vojtech Pavlik wrote: I've got a vt82c586 here (bought it just for testing of this problem), and I wasn't able to create any corruption using that board and the 2.4 drivers. The fact that it works on one board doesn't mean that it works on _every_ board. This is, in fact, why I will _NOT_ accept anything but a simple auto-dma disable for this problem for early 2.4.x. I hope that people will continue to work on and debug this problem, but it's just been around for too long, and it's obvious enough that it doesn't happen with all hardware that I doubt there is any other reasonable solution that doesn't require some _very_ extensive testing to verify. I'd love to see people who see these problems and are willing to test out patches to fix it. But in parallel with that, I definitely want the 2.2.x "disable auto-DMA" thing for the big public. We can enable it later if some patch does seem to fix it for good. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 11:57:37AM -0800, Linus Torvalds wrote: I've got a vt82c586 here (bought it just for testing of this problem), and I wasn't able to create any corruption using that board and the 2.4 drivers. The fact that it works on one board doesn't mean that it works on _every_ board. Of course. That's why I'm calling for bug reports. This is, in fact, why I will _NOT_ accept anything but a simple auto-dma disable for this problem for early 2.4.x. I hope that people will continue to work on and debug this problem, but it's just been around for too long, and it's obvious enough that it doesn't happen with all hardware that I doubt there is any other reasonable solution that doesn't require some _very_ extensive testing to verify. I'd love to see people who see these problems and are willing to test out patches to fix it. But in parallel with that, I definitely want the 2.2.x "disable auto-DMA" thing for the big public. We can enable it later if some patch does seem to fix it for good. Sure. However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets. That's because all VIA chipsets starting from vt82c586 to vt82c686b (UDMA100), share the same PCI ID. Would you prefer to filter just vt82c586 and vt82c586a as the comment in Alan's code says or simply unconditionally kill autodma on all of VIA chipsets, as Alan's code does? -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Alan Cox wrote: I want to see the code to handle the apparent VIA DMA bug. At this point, preferably by just disabling DMA on VIA chipsets or something like that (if it has only gotten worse since 2.2.x, I'm not interested in seeing any experimental patches for it during early 2.4.x). It hasnt gotten worse, its just its a very specific combination and its a well known problem (vendors dont enable auto dma for ide for this reason) 2.2.16 just covers the cases I know about (and slightly overdoes it for now) We've already had one major fs corruption due to this, I want that fixed _first_. I've got other reports too. ... At least some of the reported problems with VIA chipsets are fixed with the VIA IDE driver v3.11 [1]. Are there any problems that still occur with this driver? cu, Adrian [1] http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-02/1291.html -- A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
I'd like to hear about such reports so that I can start debugging (and perhaps get me one of those failing boards, they must be quite cheap these days). This is one of the most precise reports I have |The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks. The |size of hda is 4.3 GB, the size of hdb is 854 MB and the size of hdc is |1.2 GB. Hdd is an IDE CDROM drive I think its significant that two reports I have are FIC PA-2013 but not all. What combination of chips is on the 2013 ? Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets. That's because all VIA chipsets starting from vt82c586 to vt82c686b (UDMA100), share the same PCI ID. I have no reports of problems with the later stuff Would you prefer to filter just vt82c586 and vt82c586a as the comment in Alan's code says or simply unconditionally kill autodma on all of VIA chipsets, as Alan's code does? I'd take a 2.2 patch to cut down the range too - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001, Vojtech Pavlik wrote: However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets. That's because all VIA chipsets starting from vt82c586 to vt82c686b (UDMA100), share the same PCI ID. Would you prefer to filter just vt82c586 and vt82c586a as the comment in Alan's code says or simply unconditionally kill autodma on all of VIA chipsets, as Alan's code does? Right now, for 2.4.1, I'd rather have the patch to just do the same as 2.2.x. We can figure it out better when we get a better idea of exactly what the bug is, and whether there is some other work-around, and whether it is 100% certain that it is just those two controllers (maybe the other ones are buggy too, but the 2.2.x tests basically cured their symptoms too and peopl ehaven't reported them because they are "fixed"). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
