Date: Sat, 5 Sep 1998 10:43:11 -0400 (EDT) From: wpaul@ctr.columbia.edu (Bill Paul) To: Darcy@ok-connect.com (Darcy Buskermolen) Cc: freebsd-net@FreeBSD.ORG Subject: Re: xl0: transmission error: 82 Fatal trap12: Message-ID: <199809051443.KAA07955@advent.ctr.columbia.edu> In-Reply-To: <3.0.32.19980904201648.018c2100@mail.ok-connect.com> from "Darcy Buskermolen" at Sep 4, 98 08:16:49 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Darcy Buskermolen had to walk into mine and say: > I have a 2.2.7-stable which is acting up on me > I recently changed to a 3com 905B which was in a windows box with no errors > and now during heavy network access > the 2.2.7-stable box dies with the followng error: > > xl0: transmission error: 82 > > Fatal trap12: page fault while in kernal mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf019b372 > stack pointer = 0x10:0xf0209f90 > code segment = base 0x0, limit 0xf0209f9c > = DPL 0, pres 1, def32 1 gran 1 > processor eflags = interupt enabled, resume, IOPL = 0 > current process = Idle > interupt mask = net tty > panic: page fault > > The card is running in 10Mb Half duplex mode, and I just CVSUP'd the source > and made a new kernal using the xl dated 1998/09/01 > > Any ideas ? or is this really a bug ? I think it's a bug. I'm including a small patch with this e-mail. To apply it, do the following: - save this e-mail to /tmp/xl.patch - cd /sys/pci - patch < /tmp/xl.patch - compile a new kernel image and reboot This patch is against the 2.2.x driver version but should work on 3.0 too. Let me know if this makes a difference. I think the problem is that the code is blindly assuming that there's always a packet in the transmit queue when a transmission error occurs, but in this case there may not be. That being the case, sc->xl_cdata.xl_tx_head is a NULL pointer, and dereferencing it could be causing the panic. I don't have the manual in front of me, but I think 82 means a transmit FIFO reclaim error (which only happens on the 3c905B). I believe it means that a transmit error occured after part of the transmit FIFO had already been reclaimed. In other words, the packet was already most of the way out the door before the chip noticed an error condition, possibly too many collisions or deferals. Let me know if this patch stops the panic. You may still see the transmission error message. Let me know how frequently the message occurs. If the driver recovers from the error condition properly then I can just hide the printf() under #ifdef DIAGNOSTIC. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "Mulder, toads just fell from the sky!" "I guess their parachutes didn't open." ============================================================================= *** if_xl.c 1998/09/04 15:31:48 1.38 --- if_xl.c 1998/09/05 14:33:25 *************** *** 1884,1890 **** sc->xl_unit, txstat); CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_TX_RESET); xl_wait(sc); ! CSR_WRITE_4(sc, XL_DOWNLIST_PTR, vtophys(sc->xl_cdata.xl_tx_head->xl_ptr)); /* * Remember to set this for the --- 1884,1891 ---- sc->xl_unit, txstat); CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_TX_RESET); xl_wait(sc); ! if (sc->xl_cdata.xl_tx_head != NULL) ! CSR_WRITE_4(sc, XL_DOWNLIST_PTR, vtophys(sc->xl_cdata.xl_tx_head->xl_ptr)); /* * Remember to set this for the To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809051443.KAA07955>