kern/94196: [dc] if_dc panics on bad hardware

[John Hood]

>Number:         94196
>Category:       kern
>Synopsis:       [dc] if_dc panics on bad hardware
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 07 22:50:02 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     john hood
>Release:        FreeBSD 6.0-RELEASE i386
>Organization:
Sandstorm Enterprises
>Environment:

Software: FreeBSD (Sandstorm internal machine) 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 root at x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386

Hardware: Intel D845EPT2 motherboard in a 2U box with a 3-slot riser card;
the riser card has little paddleboards to pick off slot-geographic
signals on 2 other motherboard slots (the motherboard is not designed
for a riser card).  A Netgear FA310TX ethercard and an Intel
82559-family card are installed on the riser.  One of the little
paddle boards is not fully seated...

Software:  6.0-RELEASE install CD

>Description:

Kernel panics during boot when probing a misfunctioning Netgear
FA310TX card.

>How-To-Repeat:

By examination, mostly.  Unfortunately, the the problem went away when
the paddleboard was reseated.

Reproduce above hardware configuration, such that a card probed by the
dc driver responds to PCI config-space reads/writes, but fails to
operate normally when the driver tries to reset it.  Boot 6.0 install
CD, observe panic.  Boot 5.3 install CD, observe dc printing a
message, failing to attach, and the system otherwise continuing
normally.  Examine stack trace of debug kernel, note that the kernel
has paniced with a null-pointer dereference under
  if_printf(sc->dc_ifp, "reset never completed!\n");
in dc_reset(), from dc_attach().

Alternately, one could alter dc_reset() so that it always calls
if_printf() and boot the resulting kernel on any system with a
dc-driven card.

Sorry about the lack of a concrete report.  If you have trouble
understanding/reproducing the problem, I can generate a proper report
with stack trace, but it should be fairly obvious on examination.

>Fix:

Make sure your hardware works...

Looks like the bug was introduced with 1.163, where if_printf() was
substituted for printf().  dc_attach() does not set sc->dc_ifp until
after dc_reset() is called.  Things need to be rearranged so dc_reset
doesn't have this dependency or sc->dc_ifp is set before it's called.

I haven't looked. but it's been suggested that this may be a problem
in other drivers, if similar changes have been made.  The original
author (jhb) should review this problem.

>Release-Note:
>Audit-Trail:
>Unformatted: