IDE DMA problems on 2.4.0 with vt82c686a driver

Hello,
Since this looks like either a chipset, drive, or driver problem, I am submitting this.
I have recently started using DMA mode on my harddisk. However, I occasionally (not often/constant, but sometimes) get CRC errors:
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

After reading some archives in linux-kernel, I tried changing some options. Then I changed out the 40 pin, 80 wire cable with a new one. The errors still occasionally happened, so I then checked out the included floppy disk with the drive and used the utilities and saw that it was set for a maximum capability of ATA/100, so i changed it to ATA/66, but no change in results. I've since changed it back to ATA/100 capabilities. Running without DMA mode never gives any errors what so ever. Running with DMA mode gives me over 30 more MB/sec, so I would really like to use it...

My main concern that I havnt beem able to find an answer for on any archives or documentation, Can this cause file system corruption in any way?

The hardware is a VP_IDE: VIA vt82c686a IDE UDMA66 (VIA KT133 chipset on an Abit KT7 board) The drive is a Western Digital Caviare 7200rpm 40gig hard drive.
I have support for my chipset compiled in as well

Kernel: 2.4.0

[root@Earth root]$ hdparm -i /dev/hda

/dev/hda:

Model=WDC WD400BB-00AUA1, FwRev=18.20D18, SerialNo=WD-WMA6R2018028 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq } RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=78165360 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5

[root@Earth root]# hdparm -I /dev/hda

/dev/hda:

Model=DW CDW04B0-B00UA1A , FwRev=812.D081,
SerialNo=DWW-AMR6028120
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq } RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=78165360 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}

[root@Earth root]# hdparm /dev/hda

/dev/hda:

 multcount    =  0 (off)
 I/O support  =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)

geometry = 4865/255/63, sectors = 78165360, start = 0

PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5

VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1

    ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio

ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=38166/64/32, UDMA(66)

If any other information is needed, I will be more than happy to supply it. Any help/information will be greatly appreciated. Thank you.

--
James Brents
[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/

On Thursday 11 January 2001 08:33 am, James Brents wrote:

| Since this looks like either a chipset, drive, or driver problem, I
| am submitting this.
| I have recently started using DMA mode on my harddisk. However, I
| occasionally (not often/constant, but sometimes) get CRC errors:
| hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
| hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

welcome to the club. if you are given an answer off-list to this, i'd love a copy, because i've had the same issue for six months now. some have said that it's crosstalk in the cable -- in which case, all three of the 80-conductor cables i've tried are insufficiently shielded and we're in need of premium 80-conductor cables. and i found this in the november 200 linux journal, page 82, last paragraph, in an article on the ultimate linux box written by don marti:

"earlier this year, kernel hacker andre hedrick, the maintainer of linux's ide driver, tracked a user's problem to the fact that western digital drives don't do error checking correctly. he posted to linux-kernel, 'wdc drives blow off the crc check of udma . . . . this is bad and stupid.' western digital fired back on their web site with, 'if there's a problem using these drives in linux the problem most likely lies with the software driver and not the hard drive itself.' i'm going to believe the kernel hacker over the hardware vendor and stay away from western digital drives for awhile."

this suggests a.) that we need to gently pressure the w.d. people to come up with a fix or provide the specs necessary to fashion one -- the latter being preferable -- and b.) that we need to figure out some sort of hack that does -- what? in my experience, these error messages actually signify nothing, but they're using up cycles. can they be safely supressed? beats me. but they sold a hell of a lot of these things.

though i've noticed that the problem seems to be limited to those of us who have via chipset motherboards, suggesting that it is limited to that chipset, that chipset is ubiquitous, or via chipset motherboard owners are generally the complaining type. no idea which applies there, either.

dep
--
bipartisanship: an illogical construct not unlike the idea that
if half the people like red and half the people like blue, the 
country's favorite color is purple.
-
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/

Or there are a lot of them. 90% of scsi bug reports I get are adaptec 29xx driver. Thats not because the adaptec 29xx is the most sucky driver 8)

Firstly there are numerous reasons for CRC errors. At ATA100 even the track length and the capacitance of the connectors becomes an issue. It is quite possibly a driver issue. It could even be that specific combination of drives and ide controller is right on the edge of the spec limits and just slightly dipping over. It might be the odd power spike.

Providing the code is working sanely the odd CRC error shouldnt be a problem and should be causing a command retry. The CRC checking used in ATA is very robust so unlike scsi parity errors which couldnt be ignored ATA ones on occassion are probably fine

ATA100 is another testimony to the fact that pigs can be made to fly given sufficient thrust (to borrow an RFC)

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/

I acquired a VIA Mobo (ASUS CUV4X) for home and it is workin pretty damn spiffy with Linux - Even better with 2.4.0 with regards to IDE!!! Once a month I boot WinDOS to play a game I can't play in Linux, THEN my troubles begin!!!
parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:4.1 etc... etc... etc...
yadda yadda yadda ....

Alan,
My father repaired F-4 Phantoms in Vietnam. He said the F-4 Phantom was proof that if you put enough power behind a brick, it would fly!!! Your comment remonded me of that - just had to share :-)

<SomeLamer> what's the difference between chattr and chmod?
<SomeGuru> SomeLamer: man chattr > 1; man chmod > 2; diff -u 1 2 | less
	-- Seen on #linux on irc
=== Never ask a geek why, just nod your head and slowly back away.===
+==============================+====================================+
| John O'Donnell (Sr. Systems Engineer, Net Admin, Webmaster, etc.) |
| Voice FX Corporation (a subsidiary of Student Advantage)          |
| One Plymouth Meeting         |     E-Mail: [email protected]     |
| Suite 610                    |           www.voicefx.com          |
| Plymouth Meeting, PA 19462   |         www.campusdirect.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/

Sheesh, when you can reprogram the chipset identity so that you can make it appear to be mimic older chipsets that have current support, well you get the headache!

It is not so much the chipset of the drivers, it is the jokers making mainboards. At the last meeting in Irvine there were issues about PCB lane designs and chipset that cause problems in crosstalk or create bad timing skews. The problem is so wide spread in the industry that T13 is looking at drafting a possible design annex for defined how to test and create good hardware. (I do not need the noise, I know this is what we should be doing and not screwing up/down hardware) ;-)

The 2.4.0 kernels now have the very first created in the software industry of ATA an auto-dma-crc transfer rate recovery callback. Thus if you get only the 0x84/0x51 errors and there are no other problems and you chipset code is full-featured to have a hwif->speedproc callback, it will auto set the transfer-rate down until the iCRC errors stop.

(off to mark calender, a positive comment about ATA)

But the price to pay is SCSI noise in ATA devices, or was that pig lips flapping in the breeze...?

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/

Hi,

Please consider applying, comments in the patch.

- Arnaldo

@@ -71,6 +71,13 @@
  *	  into the kernel.
  *	- Better handling of multicast addresses.
  *
+ *	Fixes:
+ *	Arnaldo Carvalho de Melo <[email protected]> - 11/01/2001
+ *	- fix dgrs_found_device wrt checking kmalloc return and
+ *	rollbacking the partial steps of the whole process when
+ *	one of the devices can't be allocated. Fix SET_MODULE_OWNER
+ *	on the loop to use devN instead of repeated calls to dev.
+ *
  */
 
 static char *version = "$Id: dgrs.c,v 1.13 2000/06/06 04:07:00 rick Exp $";

@@ -190,7 +197,7 @@
 /*
  *	Chain of device structures
  */
-static struct net_device *dgrs_root_dev = NULL;
+static struct net_device *dgrs_root_dev;
 
 /*
  *	Private per-board data structure (dev->priv)

@@ -1247,13 +1254,17 @@
 )
 {
 	DGRS_PRIV	*priv;
-	struct net_device *dev;
+	struct net_device *dev, *aux;
 
 	/* Allocate and fill new device structure. */
 	int dev_size = sizeof(struct net_device) + sizeof(DGRS_PRIV);
-	int i;
+	int i, ret;
 
 	dev = (struct net_device *) kmalloc(dev_size, GFP_KERNEL);
+
+	if (!dev)
+		return -ENOMEM;
+
 	memset(dev, 0, dev_size);
 	dev->priv = ((void *)dev) + sizeof(struct net_device);
 	priv = (DGRS_PRIV *)dev->priv;

@@ -1272,11 +1283,12 @@
 	dev->init = dgrs_probe1;
 	SET_MODULE_OWNER(dev);
 	ether_setup(dev);
-	priv->next_dev = dgrs_root_dev;
-	dgrs_root_dev = dev;
 	if (register_netdev(dev) != 0)
 		return -EIO;
 
+	priv->next_dev = dgrs_root_dev;
+	dgrs_root_dev = dev;
+
 	if ( !dgrs_nicmode )
 		return (0);	/* Switch mode, we are done */
 

@@ -1293,6 +1305,9 @@
 			/* Allocate new dev and priv structures */
 		devN = (struct net_device *) kmalloc(dev_size, GFP_KERNEL);
 			/* Make it an exact copy of dev[0]... */
+		ret = -ENOMEM;
+		if (!devN) 
+			goto fail;
 		memcpy(devN, dev, dev_size);
 		devN->priv = ((void *)devN) + sizeof(struct net_device);
 		privN = (DGRS_PRIV *)devN->priv;

@@ -1303,17 +1318,29 @@
 		devN->irq = 0;
 			/* ... and base MAC address off address of 1st port */
 		devN->dev_addr[5] += i;
-		privN->chan = i+1;
-		priv->devtbl[i] = devN;
 		devN->init = dgrs_initclone;
-		SET_MODULE_OWNER(dev);
+		SET_MODULE_OWNER(devN);
 		ether_setup(devN);
+		ret = -EIO;
+		if (register_netdev(devN)) {
+			kfree(devN);
+			goto fail;
+		}
+		privN->chan = i+1;
+		priv->devtbl[i] = devN;
 		privN->next_dev = dgrs_root_dev;
 		dgrs_root_dev = devN;
-		if (register_netdev(devN) != 0)
-			return -EIO;
 	}
-	return (0);
+	return 0;
+fail:	aux = priv->next_dev;
+	while (dgrs_root_dev != aux) {
+		struct net_device *d = dgrs_root_dev;
+		
+		dgrs_root_dev = ((DGRS_PRIV *)d->priv)->next_dev;
+		unregister_netdev(d);
+		kfree(d);
+	}
+	return ret;
 }
 
 /*

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

Hi,

Please consider applying.

- Arnaldo

@@ -45,6 +45,8 @@
 **   along with this program; if not, write to the Free Software
 **   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 **
+** 1.57b -> 1.57c - Arnaldo Carvalho de Melo <[email protected]>
+**   - release resources on failure in init_module
 **
 ** 1.57 -> 1.57b - Jean II
 **   - fix spinlocks, SMP is now working !

@@ -3024,7 +3026,25 @@
 MODULE_PARM(hp100_name, "1-5c" __MODULE_STRING(IFNAMSIZ));
 
 /* List of devices */
-static struct net_device *hp100_devlist[5] = { NULL, NULL, NULL, NULL, NULL };
+static struct net_device *hp100_devlist[5];
+
+static void release_dev(int i)
+{
+	struct net_device *d = hp100_devlist[i];
+	struct hp100_private *p = (struct hp100_private *)d->priv;
+
+	unregister_netdev(d);
+	release_region(d->base_addr, HP100_REGION_SIZE);
+
+	if (p->mode == 1) /* busmaster */
+		kfree(p->page_vaddr); 
+	if (p->mem_ptr_virt)
+		iounmap(p->mem_ptr_virt);
+	kfree(d->priv);
+	d->priv = NULL;
+	kfree(d);
+	hp100_devlist[i] = NULL;
+}
 
 /*
  * Note: if you have more than five 100vg cards in your pc, feel free to

@@ -3051,6 +3071,8 @@
     {
       /* Create device and set basics args */
       hp100_devlist[i] = kmalloc(sizeof(struct net_device), GFP_KERNEL);
+      if (!hp100_devlist[i])
+	goto fail;
       memset(hp100_devlist[i], 0x00, sizeof(struct net_device));
 #if LINUX_VERSION_CODE >= 0x020362	/* 2.3.99-pre7 */
       memcpy(hp100_devlist[i]->name, hp100_name[i], IFNAMSIZ);	/* Copy name */

@@ -3073,6 +3095,13 @@
     }			/* Loop over all devices */
 
   return cards > 0 ? 0 : -ENODEV;
+ fail:
+  while (cards && --i)
+	  if (hp100_devlist[i]) {
+		release_dev(i);
+		--cards;
+	  }
+  return -ENOMEM;
 }
 
 void cleanup_module( void )

@@ -3082,18 +3111,7 @@
   /* TODO: Check if all skb's are released/freed. */
   for(i = 0; i < 5; i++)
     if(hp100_devlist[i] != (struct net_device *) NULL)
-      {
-	unregister_netdev( hp100_devlist[i] );
-	release_region( hp100_devlist[i]->base_addr, HP100_REGION_SIZE );
-	if( ((struct hp100_private *)hp100_devlist[i]->priv)->mode==1 ) /* busmaster */
-	  kfree( ((struct hp100_private *)hp100_devlist[i]->priv)->page_vaddr ); 
-	if ( ((struct hp100_private *)hp100_devlist[i]->priv) -> mem_ptr_virt )
-	  iounmap( ((struct hp100_private *)hp100_devlist[i]->priv) -> mem_ptr_virt );
-	kfree( hp100_devlist[i]->priv );
-	hp100_devlist[i]->priv = NULL;
-	kfree(hp100_devlist[i]);
-	hp100_devlist[i] = (struct net_device *) NULL;
-      }
+	    release_dev(i);
 }
 
 #endif		/* MODULE */

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

no: the only entities involved with udma crc's are the drive, the controller (and the cable). the kernel is not involved in any way (except to configure udma, of course.)

nothing wrong here. occasional crc retries cause no performance impact.

great, since without the 80c cable, udma > 33 is illegal. is it safe to assume your cable is also 18" or less, with both ends plugged in (no stub)? you might be able to minimize CRC retries by changing where the cable runs. it's also conceivable that CRC errors would be caused by marginal power, bad trace layout on the motherboard, and definitely by overclocking (PCI other than 33 MHz).

abosolutely not. udma checksums each transfer. when checksums don't match, the *hardware* retries the transfer (and incidentally reports the event, which Linux obligingly passes on to you.)

regards, mark hahn.

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

You might try testing with a different drive if you can get hold of one--if that works OK, that'll narrow it down to either a drive or drive-chipset interaction. The above error message could very well mean that you're starting to lose the drive, so keep backups!

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

Hi!

I'm the current maintainer of the VIA driver. I'm pretty sure the version in 2.4.0 programs the chips correctly for harddrives at various speeds, even leaving some margins where it shouldn't need to.

I think there is not any problem with Western Digital drives, I've got many reports of them working OK with different chipsets, including those made by VIA.

However, I'm getting many many problem reports on Abit KT7's. It might be that this is a very popular board, but nevertheless, I think at least its earlier revisions had trouble with UDMA transfers.

At least on one of these boards a drive did work correctly, without CRC errors on the secondary interface, and gave constant errors on the primary. All other known problem causes were eliminated.

I think it's Abit this time who's to blame.

-----

Anyway, you can try disabling VIA support in kernel, and if BIOS sets up things correctly, you should be able to use UDMA as well. If it works then, it would mean that my driver is a problem. I'd like to hear in either case.

Vojtech

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/

Well, that's the part where it is really easy to cause crc errors. But I believe I got that right in the driver. Tested successfully on many VIA chipsets.

Also it should be noted that they don't cause any corruption (*). The worst thing they can do is disabling DMA if they happen many times in a short period of time.

(*) - UDMA modes only. CRC errors are a big problem in PIO and
MWDMA/SWDMA modes.

... note that he says 40pin, 80wire. That's the correct UDMA66 cable, it has just 40 pins.

Bad trace on the motherboard is what I suspect on KT7's. It could be designed a little longer or shorter than the others and a marginal clock skew can cause the crc errors. Or the trace can lead too close to some source of e/m noise.

The software retries the transfer, the hardware just aborts. But it's safe, anyways.

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/