From owner-freebsd-mobile  Mon Sep 23 09:42:11 1996
Return-Path: owner-mobile
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id JAA05617
          for mobile-outgoing; Mon, 23 Sep 1996 09:42:11 -0700 (PDT)
Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA05543;
          Mon, 23 Sep 1996 09:42:00 -0700 (PDT)
Received: (from imb@localhost)
          by asstdc.scgt.oz.au (8.7.6/BSD4.4) id CAA04350
          Tue, 24 Sep 1996 02:41:20 +1000 (EST)
From: michael butler <imb@scgt.oz.au>
Message-Id: <199609231641.CAA04350@asstdc.scgt.oz.au>
Subject: Re: 3C589b + ep driver
To: nate@mt.sri.com (Nate Williams)
Date: Tue, 24 Sep 1996 02:41:19 +1000 (EST)
Cc: current@freebsd.org, mobile@freebsd.org
In-Reply-To: <199609231609.KAA02696@rocky.mt.sri.com> from "Nate Williams" at Sep 23, 96 10:09:20 am
X-Mailer: ELM [version 2.4 PL24beta]
Content-Type: text
Sender: owner-mobile@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Nate Williams writes:
> FWIW, I'm now starting to see these as well with the if_zp driver under
> -current, and I *NEVER* saw them before in the almost 2 years I ran 2.1
> and 2.1.5.

I tried the zp driver from yesterday's -current and couldn't get it to work
for me (which is odd because I installed using it in July :-()

> This is what also implies that it's not something necessarily specific
> to the drivers, but something that changes which might require all of
> the drivers to be modified.

I'm tempted to think (but without proof since I don't have sufficient
hardware documentation - any, in fact) that the present drivers are timing
sensitive (increasing CPU load causes more frequent failures) and that some
other changes in the kernel have provoked a latent weakness.

Honestly, I can't see anything wrong with it the way it is so "poking" bits
of code to see what has any impact at all is the only way I can approach it.

Tonight, I looked at Guido's "newif_vx" stuff on freefall which, amongst
other things, breaks out the TX_STATUS stuff into a separate function and
has a similar interrupt service restructure to the one I tried. I might try
the "BROKEN_AVAIL" strategy to see if that affects the problem,

	michael