Bug 18641

Just to confirm that the problem also exists with other HW ( 486/ DE200
), so
it is highly probably that something in the le0 driver, or the
'compatability shims' is broken. (NE2000's work just fine for me, so I
replaced the card).

Pascal

The problem remains under FreeBSD V4.1Release, from the CD ISO
image available from 
ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/ISO-IMAGES/4.1-install.iso
<ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/ISO-IMAGES/4.1-install.iso>
.  (MD5 signature was correct). 

During a minimal configuration build with minimal devices
enabled via 'visual config', a freshly built system is unable
to start, due to non-existent page fault in kernel mode, by
ifconfig. (booting halts on this process).  There are no other
network devices.  The default le0 values (300, 5, D000, 2K) are
used.  The NIC was checked using ezworks, to match the default
values.  
 
Regards, Dewayne.

Comment 3 Sheldon Hearn 2000-08-14 11:25:42 UTC

State Changed
From-To: open->feedback

Dewayne and Pascal, is either of you in a position to provide a 
backtrace of this panic as described in: 

http://www.freebsd.org/handbook/kerneldebug.html

Same symptoms on a 4.0R pentium with different IRQ etc.
Checked with a 3.3R boot floppy and that works fine on this machine.
Kernel crash dump obtained, not yet submitted.

Similar panic also while attempting to install 4.0R (CD with
several remakes of floppy boot disks) to a 486 that ran 3.3R
very well both before and after the failed 4.0 install. (This
was a fresh install each time, not an upgrade.)

Feel free to contact sue@welearn.com.au for kernel trace
if you can offer a teensy bit of help to identify the
required info.

-- 

Regards,
        -*Sue*-

On Sat, 26 Aug 2000 08:00:05 MST, browser wrote:

>  Similar panic also while attempting to install 4.0R (CD with
>  several remakes of floppy boot disks) to a 486 that ran 3.3R
>  very well both before and after the failed 4.0 install. (This
>  was a fresh install each time, not an upgrade.)
>  
>  Feel free to contact sue@welearn.com.au for kernel trace
>  if you can offer a teensy bit of help to identify the
>  required info.

Thanks for the offer.

You'll need to test this using a kernel compiled with debugging support.
There are instructions for providing a backtrace at:

	http://www.freebsd.org/handbook/kerneldebug.html

However, I'm not optimistic about finding someone to look into this for
you.  The le(4) driver doesn't seem to have a maintainer.  Once you have
a backtrace, we'll see whether the author of the driver (Matt Thomas)
can take a look, but I'm not sure that his last known e-mail address is
still valid.

Ciao,
Sheldon.

On Mon, 28 Aug 2000 21:39:12 +1000, Sue Blake wrote:

> #5  0x0 in ?? ()
> (kgdb) 

Oh dear.  I wonder what happened further back. :-)

> If you want more from me, please be very specific. If nobody's
> interested, please record the death of le(4) at 4.0-RELEASE to avoid a
> support burden.

That's actually not a bad idea.  Perhaps ruffling up the release notes
and the errata will jog someone into action. :-)

You and I are in the same boat with this one, by the way.  Neither of us
needs the driver, but both of us think it should be fixed or listed as
unsupported.  For some reason, I never seem to consider the latter as an
acceptable solution. :-)

Ciao,
Sheldon.

Comment 7 Sheldon Hearn 2000-08-30 10:29:20 UTC

State Changed
From-To: feedback->suspended

This will probably remain in the suspended state for some time 
unless someone can supply the maintainer with hardware to test. 

If you have problematic le(4) hardware that you can send the 
maintainer to facilitate testing, please contact: 

Paul Richards <paul@FreeBSD.org> 

Comment 8 Sheldon Hearn 2000-08-30 10:29:20 UTC

Responsible Changed
From-To: freebsd-bugs->paul

Over to the maintainer, in the hopes that someone will 
send him hardware to test the driver on.

To the Maintainer of the le driver,

I am quite happy to pack up one of these devices (DE20x) and pop it into
the post and ship it to you.

Please contact me at <hwc@ficsgrp.com> with snail-address details.

Reg's,

haxxa

-- 

Harry Woodward-Clarke
Support Analyst

S1 Australia		Telephone:   +61 2 9260-2144
Level 8, 131 York St,	Facsimile:   +61 2 9267-9422
Sydney NSW, 2000	E-mail:      Harry.Woodward-Clarke@S1.com
Australia		Web Page:    www.S1.com

[jlemon: you are cc'd because you are the last person who committed
fixes to if_le.c.  cyschow & swear cc'd because they recently had small
thread in -stable about this problem.]

The problem still exists in 4.5:  My NIC:

le0 at port 0x300-0x31f iomem 0xd0000-0xd07ff irq 5 on isa0
le0: DE205-AC ethernet address 08:00:2b:9f:39:d4

dies when an address is ifconfig'd.  The following patch (against
RELEG_4_5_0_RELEASE) works for me; maybe it could be committed?
It has only been tested on the card that I have, but it this email is
being sent via that card so it seems to work...

andrew

Index: if_le.c
===================================================================
RCS file: /usr/local/repos/fbsdcvs/src/sys/i386/isa/if_le.c,v
retrieving revision 1.56.2.3
diff -u -u -r1.56.2.3 if_le.c
--- if_le.c	2001/11/02 17:48:00	1.56.2.3
+++ if_le.c	2002/03/25 14:00:23
@@ -191,7 +191,6 @@
  */
 struct le_softc {
     struct arpcom le_ac;		/* Common Ethernet/ARP Structure */
-    void (*if_init) __P((le_softc_t *));/* Interface init routine */
     void (*if_reset) __P((le_softc_t *));/* Interface reset routine */
     caddr_t le_membase;			/* Starting memory address (virtual) */
     unsigned le_iobase;			/* Starting I/O base address */
@@ -336,19 +335,23 @@
     struct ifnet *ifp = &sc->le_if;
 
     dvp->id_ointr = le_intr;
-    ifp->if_softc = sc;
-    ifp->if_mtu = ETHERMTU;
+
     printf("%s%d: %s ethernet address %6D\n",
 	   ifp->if_name, ifp->if_unit,
 	   sc->le_prodname,
 	   sc->le_ac.ac_enaddr, ":");
 
+    ifp->if_softc = sc;
+    ifp->if_mtu = ETHERMTU;
     ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
+    ifp->if_timer = 0;
     ifp->if_output = ether_output;
     ifp->if_ioctl = le_ioctl;
+    ifp->if_watchdog = 0;
     ifp->if_type = IFT_ETHER;
-    ifp->if_addrlen = 6;
-    ifp->if_hdrlen = 14;
+    ifp->if_addrlen = ETHER_ADDR_LEN;
+    ifp->if_hdrlen = ETHER_HDR_LEN;
+    ifp->if_snd.ifq_maxlen = IFQ_MAXLEN;
 
     ether_ifattach(ifp, ETHER_BPF_SUPPORTED);
 
@@ -446,7 +449,7 @@
                 break;
 
 	case SIOCSIFFLAGS: {
-	    sc->if_init(sc);
+	    sc->le_if.if_init(sc);
 	    break;
 	}
 
@@ -455,7 +458,7 @@
 	    /*
 	     * Update multicast listeners
 	     */
-		sc->if_init(sc);
+		sc->le_if.if_init(sc);
 		error = 0;
 		break;
 
@@ -613,7 +616,7 @@
 #define LEMAC_32K_MODE(mbase)	(((mbase) >= 0x14) && ((mbase) <= 0x1F))
 #define LEMAC_2K_MODE(mbase)	( (mbase) >= 0x40)
 
-static void lemac_init(le_softc_t *sc);
+static void lemac_init(void *xsc);
 static void lemac_start(struct ifnet *ifp);
 static void lemac_reset(le_softc_t *sc);
 static void lemac_intr(le_softc_t *sc);
@@ -688,7 +691,7 @@
     /*
      * Try to reset the unit
      */
-    sc->if_init = lemac_init;
+    sc->le_if.if_init = lemac_init;
     sc->le_if.if_start = lemac_start;
     sc->if_reset = lemac_reset;
     sc->lemac_memmode = 2;
@@ -778,8 +781,9 @@
 
 static void
 lemac_init(
-    le_softc_t *sc)
+    void  *xsc)
 {
+    le_softc_t *sc = (le_softc_t *)xsc;
     int s;
 
     if ((sc->le_flags & IFF_UP) == 0)
@@ -1138,7 +1142,7 @@
 static int  lance_init_ring(le_softc_t *sc, ln_ring_t *rp, lance_ring_t *ri,
 			    unsigned ndescs, unsigned bufoffset,
 			    unsigned descoffset);
-static void lance_init(le_softc_t *sc);
+static void lance_init(void *xsc);
 static void lance_reset(le_softc_t *sc);
 static void lance_intr(le_softc_t *sc);
 static int  lance_rx_intr(le_softc_t *sc);
@@ -1360,7 +1364,7 @@
 	return 0;
 
     sc->if_reset = lance_reset;
-    sc->if_init = lance_init;
+    sc->le_if.if_init = lance_init;
     sc->le_if.if_start = lance_start;
     DEPCA_WRNICSR(sc, DEPCA_NICSR_SHE | DEPCA_NICSR_ENABINTR);
     sc->if_reset(sc);
@@ -1580,8 +1584,9 @@
 
 static void
 lance_init(
-    le_softc_t *sc)
+    void *xsc)
 {
+    le_softc_t *sc = (le_softc_t *)xsc;
     lance_ring_t *ri;
     lance_descinfo_t *di;
     ln_desc_t desc;

I've downloaded and tested the patch on my system (P120 with DEC
Ewrk3, irq 5, io 240, mem d0000, FBSD v4.5) and so far so good, it
seems to be chugging along quite happily now.

Thanks a lot for submitting the patch!

On Mon, 25 Mar 2002 09:09:39 -0500 "Andrew Heybey" <ath@niksun.com> wrote:

> The following patch (against RELEG_4_5_0_RELEASE) works for me; maybe it

> could be committed?  It has only been tested on the card that I have,
but 
> it this email is being sent via that card so it seems to work...
> [patch deleted]

	Thanks!  I tested on my NIC and it is working great!
	The following is my relevant dmesg:

	le0 at port 0x300-0x31f iomem 0xd0000-0xd07ff irq 5 drq 0 on isa0
	le0: DE204-AB ethernet address 08:00:2b:90:02:f0
	le0: driver is using old-style compatability shims

	How can we get this committed?

---
Samuel Chow
cyschow@shaw.ca

Segmentation Fault (core dumped)
This message is displayed using recycled electrons.

Comment 13 Paul Richards 2002-06-06 00:28:37 UTC

State Changed
From-To: suspended->closed

Simplification of above patch applied to -stable. More complete fix
should still be applied to -current before 5.0.

Comment 14 Paul Richards 2002-06-06 00:29:34 UTC

State Changed
From-To: closed->open

A more complete migration to newbus needs to be done before 5.0

Hi!

If you are not satisfied with the path from this PR,
perhaps you'd like to recall much simplier patch from
(now closed) kern/37330:

http://www.freebsd.org/cgi/query-pr.cgi?pr=37330

Eugene Grosbein

Comment 16 Paul Richards 2005-05-16 12:09:37 UTC

State Changed
From-To: open->closed

The le driver has been deprecated and is no longer in the tree.