Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 Feb 2000 22:05:25 -0700
From:      "Justin T. Gibbs" <gibbs@FreeBSD.org>
To:        tkuehn@websurf.pcom.de (Torsten Kuehn)
Cc:        freebsd-bugs@FreeBSD.ORG, ken@plutotech.com, wilko@FreeBSD.ORG
Subject:   Re: ahb Bug still not resolved in 3.2-release (ref. kern/12495) 
Message-ID:  <200002130505.WAA02124@caspian.plutotech.com>
In-Reply-To: Your message of "Sat, 12 Feb 2000 22:26:31 GMT." <000212222503224400@mail1.pcom.de> 

next in thread | previous in thread | raw e-mail | index | archive | help
There are several things that the FreeBSD driver does that the Linux
driver does not.

1) We will issue tagged commands.
2) We tell the firmware to only update the status block on error.
3) We tell the firmware to not auto-retry on BUSY status.  The CAM
   peripheral driver will retry if it wishes.
4) We don't suppress underrun errors.  Since we tell the firmware to
   only update the status block on errors, this is the only way to
   get a valid residual.
5) We don't have the controller check that data flows in the proper
   direction.  The code is there, but it is currently commented out
   for some reason.  I don't remember doing this myself.

It may be that any or all of the above are features of the firmware
that were never exercised by other drivers and so are buggy.

Do you have a system where you can generate kernels?  Perhaps you can
change the driver to behave just like the Linux one and then enable
the use of the above features one by one until an error occurs?  That
is, hoping that by mimicking the Linux driver the errors go away. 8-)

--
Justin




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002130505.WAA02124>