Date: Tue, 16 Apr 2002 18:05:17 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: msch@snafu.de Cc: freebsd-current@freebsd.org Subject: Re: ATA errors on recent -current Message-ID: <3CBCCA4D.AFD57D@mindspring.com> References: <E16xPom-0004cD-00@clever.eusc.inter.net>
next in thread | previous in thread | raw e-mail | index | archive | help
msch@snafu.de wrote:
> > As I said: it could be drive settings unrelated to the code
> > itself being correct. I've given three suggestions to verify
> > this, one way or the other:
> >
> > 1) Control the drive DMA speed down
>
> I *did* test with UDMA66 instead of UDMA100 and it was even worse...
> With UDMA100, the system switched back to PIO4 - with UDMA66 there was a system
> freeze after the second (well known) error message... :-(
>
> But I admit, this test was done some days ago, I'll try it again this evening
> (approx. 19:00 UTC)...
Was this with the atacontrol, or was it with the manufacturer
supplied utility, ibmatarw.exe or ibmata66.exe?
> > 2) Pretend the maximum tagged command queue depth is
> > smaller than it is
>
> How to?
Modify the source code and compile a new kernel. The code has
changed, but, ~line 180 of /sys/dev/ata/ata-disk.c:
/* use tagged queueing if allowed and supported */
if (ata_tags && ad_tagsupported(adp)) {
adp->num_tags = AD_PARAM->queuelen;
adp->flags |= AD_F_TAG_ENABLED;
adp->controller->flags |= ATA_QUEUED;
Change:
adp->num_tags = AD_PARAM->queuelen;
to:
adp->num_tags = AD_PARAM->queuelen / 2;
Or just set it to some known value less than the number supported
by your drive, as indicated by the proble message.
Note that there might have been changes to the ad_tagsupported(adp)
function, in the same file. If so, it may be showing a false
positive for your drive. Here is the old code:
static int
ad_tagsupported(struct ad_softc *adp)
{
const char *drives[] = {"IBM-DPTA", "IBM-DTLA", NULL};
int i = 0;
switch (adp->controller->chiptype) {
case 0x4d33105a: /* Promises before TX2 doesn't work with tagged queuing */
case 0x4d38105a:
case 0x0d30105a:
case 0x4d30105a:
return 0;
}
/* check that drive does DMA, has tags enabled, and is one we know works */
if (adp->controller->mode[ATA_DEV(adp->unit)] >= ATA_DMA &&
AD_PARAM->support.queued && AD_PARAM->enabled.queued) {
while (drives[i] != NULL) {
if (!strncmp(AD_PARAM->model, drives[i], strlen(drives[i])))
return 1;
i++;
}
/*
* check IBM's new obscure way of naming drives
* we want "IC" (IBM CORP) and "AT" or "AV" (ATA interface)
* but doesn't care about the other info (size, capacity etc)
*/
if (!strncmp(AD_PARAM->model, "IC", 2) &&
(!strncmp(AD_PARAM->model + 8, "AT", 2) ||
!strncmp(AD_PARAM->model + 8, "AV", 2)))
return 1;
}
return 0;
}
> > 3) Toggle the write caching on the drive
>
> OK - I'm running all my disks without write cache, but I'll check this too.
Turning write caching off makes the drive work harder, as well as
making it more reliable (just like real life: the more reliable,
the harder it works 8-)). Write caching avoids some additional
work that might otherwise slow the drive electronics.
> > Until you try all three of these and report back, you can't say
> > that the problem is Soren's.
>
> This is a real misunderstanding! I thought I stated clearly enough that I
> don't want to blame Soren for this obviously highly complex issue!
> Shit happens - the only ensurance against that is to stay in bed (alone! :-)
No problem. I just wanted it made clear. The circumstances were a
"before it didn't happen/after it does happen", so it loked like
there was blame being tossed.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CBCCA4D.AFD57D>