FreeBSD V3.3 system guttered for V4.0 installation. System previously working, there were no changes or variations to the hardware. Other slice uses Win95. When using ifconfig to configure network, system crashes. e.g. ifconfig le0 inet 10.0.0.1 netmask 255.255.255.0 This can be induced using standalone or muliuser mode. Crash screen details: Fatal trap 12: page fault while in kernel mode Fault virtual address: 0x0 Fault code: Supervisor read, page not present Instruction pointer: 0x8:0x0 Stack pointer 0x10: 0xcccced7c Frame pointer: 0x10: 0Xcccced90 Code segment = base rx0, limit 0xfffff, type 0x1b - DPL0, pres 1 def32 1, gran 1 Processor flag=interrupt enabled, resume, IOPL-0 Current process = 179 (ifconfig) Inerrupt mask = net tty Trap number = 12 Panic: page fault --- Possibly relevant facts: 1. NIC Settings: irq 10, iomem 0xD0000, port 300 2. The NIC requires eprom settings, buffer size is 64K, which its been since 2.2.5 3. Unfamiliar kernel messages during boot: le: drier is using old-style compatability shims le0 XXX: driver didn't set ifq_maxlen 4. A crash also results when installing fresh from CD and configuring the network. 5. These problems were also experienced from the ISO image via a web copy. (Though I suspected a fouled CD burner.) 6. System is a Pentium III with 256Mb memory. Fix: The le driver has been deprecated and is no longer in the tree. How-To-Repeat: Install fresh system, do not configure network interface Boot system Login to root account ifconfig le0 inet 10.0.0.1 netmask 255.255.255.0 <crashes>
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.
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.
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>
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.
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.
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
State Changed From-To: open->closed The le driver has been deprecated and is no longer in the tree.