Date: Mon, 26 Oct 1998 10:44:05 -0500 From: Dave Chapeskie <dchapes@borderware.com> To: Drew Baxter <netmonger@genesis.ispace.com> Cc: hackers@FreeBSD.ORG Subject: Re: XL0 Message-ID: <98Oct26.110114est.115594@gateway.borderware.com> In-Reply-To: <4.1.0.67.19981022124020.00ad2100@genesis.ispace.com>; from Drew Baxter on Thu, Oct 22, 1998 at 12:43:17PM -0400 References: <4.1.0.67.19981022124020.00ad2100@genesis.ispace.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 22, 1998 at 12:43:17PM -0400, Drew Baxter wrote: > Got my dmesg output for the day.. (this is probably my 2nd day of using my > XL card instead of a EP0'd 3c509), and i see this.. Anyone able to shed > some light on it? It runs fine otherwise, not sure if this is killing > performance when we have this happen or not. > > > xl0: transmission error: 82 [repeats] > > --- > Drew "Droobie" Baxter > Network Admin/Professional Computer Nerd(TM) > OneEX: The OneNetwork Exchange 207-942-0275 > http://www.droo.orland.me.us > My Latest Kernel: FreeBSD 3.0-CURRENT (ONEEX) #14: Mon Oct 19 22:36:58 EDT 1998 I had the exact same thing and this is the response I got from the author of the xl0 driver: > > a) What does transmission error 82 mean? > > The 2 part in this case indicates the error which, according to the > manual is: > > #define XL_TXSTATUS_RECLAIM 0x02 /* 3c905B only */ > > The manual says that this error happens because "the packet experienced > a collision after the front of the packet had been reclaimed to the > FIFO free space." In other words, the chip had sent the packet and had > already erased part of it from its internal FIFO RAM when it detected > a collision. The driver detects this error and, if the packet is still > in the driver's outbound queue, it will attempt to retransmit it. If > it isn't in the queue, the driver just acknowledges the TX error interrupt > and continues. I don't think there should be any traffic interruptions. > > The 80 part means the transmission is complete: > > #define XL_TXSTATUS_COMPLETE 0x80 > > > b) Is it something I should be concerned about? > > Not really. If the error message annoys you, you can hide it under an > #ifdef DIAGNOSTIC/#endif pair. The driver recovers from the condition > correctly, so it's really just an informational message. (There was a > bug in older versions of the driver where the error handler failed to > check if there really was a packet in the outbound queue and could panic > when it tried to dereference the NULL queue head pointer, but I fixed > that.) > > > c) Is it a potential problem with my cabling or hub? > > Mmm... possibly. I would expect to see this on a busy shared ethernet > with lots of collisions, but there might be other causes. In my test > environment I use an ethernet switch and don't ever see these errors. > > -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 > ============================================================================= > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" > ============================================================================= Hope this helps. -- Dave Chapeskie <dchapes@borderware.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98Oct26.110114est.115594>