[PATCH] dgrs.c: kmalloc release on failure

[PATCH] dgrs.c: kmalloc release on failure

[Arnaldo Carvalho de Melo]

Hi,

	Please consider applying, comments in the patch.

- Arnaldo

--- linux-2.4.0-ac6/drivers/net/dgrs.c	Tue Dec 19 11:25:40 2000
+++ linux-2.4.0-ac6.acme/drivers/net/dgrs.c	Thu Jan 11 11:05:05 2001
@@ -71,6 +71,13 @@
  *	  into the kernel.
  *	- Better handling of multicast addresses.
  *
+ *	Fixes:
+ *	Arnaldo Carvalho de Melo <acme@conectiva.com.br> - 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

IDE DMA problems on 2.4.0 with vt82c686a driver

[James Brents]

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
James@nistix.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] dgrs.c: kmalloc release on failure

[Arnaldo Carvalho de Melo]

Hi,

	Please consider applying.

- Arnaldo

--- linux-2.4.0-ac6/drivers/net/hp100.c	Tue Dec 19 11:25:41 2000
+++ linux-2.4.0-ac6.acme/drivers/net/hp100.c	Thu Jan 11 11:52:34 2001
@@ -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 <acme@conectiva.com.br>
+**   - 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: IDE DMA problems on 2.4.0 with vt82c686a driver

[dep]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: IDE DMA problems on 2.4.0 with vt82c686a driver

[Mark Hahn]

> Since this looks like either a chipset, drive, or driver problem, I am 

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

> occasionally (not often/constant, but sometimes) get CRC errors:
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

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

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

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

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

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: IDE DMA problems on 2.4.0 with vt82c686a driver

[Alan Cox]

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

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: IDE DMA problems on 2.4.0 with vt82c686a driver

[Doug McNaught]

James Brents <James@nistix.com> writes:

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

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: IDE DMA problems on 2.4.0 with vt82c686a driver

[John O'Donnell]

Alan Cox wrote:

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

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: johnod@voicefx.com     |
| 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: IDE DMA problems on 2.4.0 with vt82c686a driver

[Andre Hedrick]

On Thu, 11 Jan 2001, Alan Cox wrote:

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

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!

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

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

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

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.

> 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

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

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

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: IDE DMA problems on 2.4.0 with vt82c686a driver

[Vojtech Pavlik]

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

On Thu, Jan 11, 2001 at 09:38:26AM -0500, dep wrote:
> 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 majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: IDE DMA problems on 2.4.0 with vt82c686a driver

[Vojtech Pavlik]

On Thu, Jan 11, 2001 at 09:41:55AM -0500, Mark Hahn wrote:
> > Since this looks like either a chipset, drive, or driver problem, I am 
> 
> 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.)

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.

> > occasionally (not often/constant, but sometimes) get CRC errors:
> > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> 
> nothing wrong here.  occasional crc retries cause no performance impact.

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.

> > 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. 
> 
> great, since without the 80c cable, udma > 33 is illegal.

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

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

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.

> and definitely by overclocking (PCI other than 33 MHz).
> 
> > 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?
> 
> 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.)

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/