Subject: Re: kern/25659
To: None <bouyer@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org>
From: John Refling <refling@stanfordalumni.org>
List: netbsd-bugs
Date: 06/17/2005 08:01:03
The following reply was made to PR kern/25659; it has been noted by GNATS.

From: John Refling <refling@stanfordalumni.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>,
	<refling@stanfordalumni.org>, <smb@research.att.com>,
	<gnats-bugs@NetBSD.org>
Cc: <kern-bug-people@NetBSD.org>, <gnats-admin@NetBSD.org>,
	<netbsd-bugs@NetBSD.org>
Subject: Re: kern/25659
Date: Fri, 17 Jun 2005 01:00:03 -0700

 Alright, I have experimented with some of the patches
 in the log for this PR, and have found the following:
 
 The first submission which was to patch ver 1.172 did
 not patch cleanly (I'm running 2.0, version 1.172.2.7)
 but with a tiny bit of work (the "int bcnt"; was inserted
 a few lines off), compiled, and solved the problem attaching
 the disk drive to wd1.
 
 The second submission which was to patch 1.172.2.7
 also did not apply cleanly, (the "delay(1000000);" and
 the following line were swapped), which when changed,
 compiled, and also solved the disk problem.
 
 The third submission which was to patch 1.172.2.7, which
 gave compiler warnings about uninitialized variables (st0,
 st1 on line 495), and after making it compile (st1 =3D 0,
 etc.), it did NOT solve the problem.
 
 The forth submission was for 3.0 which I don't have
 checked out, so can't test it, yet.
 
 I looked at the 2nd patch, and it seemed to be just
 many delays(), so I was curious to see if there was one
 delay that made all the difference, and in my case, there
 was!
 
 The only statement that mattered was the "delay(1000000);"
 
 I'm testing this with three old disk drives:
 
 IBM DADA-24860 4860 MB (1998)  needs delay(200000) or greater
 Toshiba MK-2428 500 MB (1994?) needs delay(450000) or greater
 Apple DVAA-2810 733 MB (1995)  needs delay(380000) or greater
 
 The above shows the range of delays needed from my
 tests.  I suppose a very old drive might need a larger
 delay.  I can test that sometime, when I find one.
 
 Is this really an issue with the wdc.c controller, or
 is it possibly slow pcmcia hardware/driver between the
 wdc controller and the system?
 
 Also, what's going to happen when an old cd-rom is
 attached?  Aren't they slower than disk drives?
 
 Finally, at least on my system, this is not a spin-up
 issue --- the drives are always spinning!  It might be
 a delay after reset, or something.  One of the drives
 consistently powers off, then on about 6 times during
 the probing.  It also powers off then on at any access.
 So these drives apparently have strange reactions to
 things!
 
 
 ------ Original Message ------
 Received: 03:03 AM PDT, 06/11/2005
 From: Manuel Bouyer <bouyer@antioche.eu.org>
 To: refling@stanfordalumni.org, smb@research.att.com, gnats-bugs@NetBSD.o=
 rgCc:
 kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.or=
 g
 Subject: Re: kern/25659
 
 On Fri, Jun 10, 2005 at 08:12:02AM +0000, John Refling wrote:
 >    I have a pcmcia ide controller and drive
 >  package called "Data Disaster Recovery System
 >  for Notebooks" by ei, an Agate' company.  This
 >  had the same symptom of never seeing the disk,
 >  until I applied the first patch above, and all
 >  worked well!
 >  =
 
 >     This is in NetBSD/i386 ver 2.02.
 
 Hi,
 can you try the attached patches instead (one for 2.0, one for 3.0/curren=
 t) ?
 This should do the same thing as the patch in the PR, without busy-waitin=
 g.
 
 -- =
 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 
 
 ____________________________________________________________________
    =