In article <199604300304.WAA09735@fezzik.endicor.com>,
 <tsarna@endicor.com> wrote:
> 
> >Number:         2358
> >Category:       port-i386
> >Synopsis:       Recent changes to if_ep made my 3C590 stop working
> >Confidential:   no
> >Severity:       serious
> >Priority:       high
> >Responsible:    gnats-admin (GNATS administrator)
> >State:          open
> >Class:          sw-bug
> >Submitter-Id:   net
> >Arrival-Date:   Tue Apr 30 01:35:02 1996
> >Last-Modified:
> >Originator:     Ty Sarna
> >Organization:
> Endicor Technologies, Inc., San Antonio, Texas
> >Release:        NetBSD-current supped 4/29 and several earlier sups
> >Environment:

Something additional I just noticed: I built GENERICOTHER, and it works. 
I started trimming stuff from it, to see if there was some particular
difference betweeen my config and it that caused the problem, and I
found no pattern.  I removed a few unrelated things (386 and 586 cpu
support, MATH_EMULATE) and it continued to work.  I removed a few more
(LFS, QUOTA, COMPAT_{09,10,LINUX,SVR4,FREEBSD,IBSC4}) and it stopped
working.  I'm guessing it's a stray pointer problem, and that it merely
works or doesn't work depending on where things are in the kernel based
on how much stuff is compiled in. None of the above changes should
affect the driver in any way.

What's even more interesting is that I noticed that st0 is not detected
by my latest non-working kernel. I went back and booted a bunch of
previous versions, and the ones where the 3C590 works detect st0, and
the ones that don't, don't!

st0 is a Wangtek 5150ES if it matters (but I doubt it does). So the
question is, is the st or scsi code trashing the ep driver, or vice
versa? Or are they both symptoms of something else? Since st0 is
detected before ep0 on the working kernels, I'm guessing it's maybe
something related to the scsi or st code.