envbvs@epb2.lbl.gov (Brian V. Smith) (05/24/89)
We are crashing on our Microvax II with a DEQNA with the panic message "qe: chained packet". Any idea on what this means? It usuallly happens when "rlogin"ing or "ftp"ing to a remote host. _____________________________________ Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory We don't need no signatures!
grr@cbmvax.UUCP (George Robbins) (05/25/89)
In article <2717@helios.ee.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes: > We are crashing on our Microvax II with a DEQNA with the panic message > "qe: chained packet". > > Any idea on what this means? It usuallly happens when "rlogin"ing > or "ftp"ing to a remote host. It means that the deqna driver has received a packet > 2K bytes long. Normal ethernet packets are limited to ~1500 bytes, but many systems will generate longer packets if left to their own ends. If you have a Sun on your net, you should be able to use the etherfind/tcpdump utilities to get some handle on this. I've heard that sun NFS will use big packets, but there are parameters in fstab to control this. I don't see right off why you would have problems with rlogin/telnet type protocols though. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jack@cwi.nl (Jack Jansen) (05/26/89)
In article <2717@helios.ee.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes: >We are crashing on our Microvax II with a DEQNA with the panic message >"qe: chained packet". > Well, you could at least have told us which OS you run, and which version........ Anyway, the problem is probably that there are packets coming in that are longer than one receive buffer (and, thus, get chained into the next buffer) and your software can't handle this. Depending on your OS, you might be able to extend the size of the recieve buffers. Another (hacky) solution is to set the 'mtu' of all systems on the net to a value lower than your uVax-II buffer size. -- -- Een volk dat voor tirannen zwicht | Oral: Jack Jansen zal meer dan lijf en goed verliezen | Internet: jack@cwi.nl dan dooft het licht | Uucp: mcvax!jack
envbvs@epb2.lbl.gov (Brian V. Smith) (05/27/89)
In article <8147@boring.cwi.nl>, jack@cwi.nl (Jack Jansen) writes: > In article <2717@helios.ee.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes: > >We are crashing on our Microvax II with a DEQNA with the panic message > >"qe: chained packet". > > > Well, you could at least have told us which OS you run, and which > version........ > Sorry. Ultrix 2.0-1. BUT, in three years since it has been running it has not ever given that error. > Anyway, the problem is probably that there are packets coming in > that are longer than one receive buffer (and, thus, get chained into > the next buffer) and your software can't handle this. Depending on > your OS, you might be able to extend the size of the recieve buffers. > I suspect that some other host is sending large packets that is making our machine panic. Do you know how to extend the size of the receive buffers on Ultrix 2.x or Ultrix 3.0 (which we will be installing anyway)? > Another (hacky) solution is to set the 'mtu' of all systems on > the net to a value lower than your uVax-II buffer size. You're not serious! There are several hundered machines on the LBL net. _____________________________________ Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory We don't need no signatures!
grr@cbmvax.UUCP (George Robbins) (05/29/89)
In article <2734@helios.ee.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes: > In article <8147@boring.cwi.nl>, jack@cwi.nl (Jack Jansen) writes: > > In article <2717@helios.ee.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes: > > >We are crashing on our Microvax II with a DEQNA with the panic message > > >"qe: chained packet". > > > Anyway, the problem is probably that there are packets coming in > > that are longer than one receive buffer (and, thus, get chained into > > the next buffer) and your software can't handle this. Depending on > > your OS, you might be able to extend the size of the recieve buffers. > I suspect that some other host is sending large packets that is making > our machine panic. Do you know how to extend the size of the receive > buffers on Ultrix 2.x or Ultrix 3.0 (which we will be installing anyway)? This is not so easy. The DEQNA seems to be an attempt by DEC to emulate a DELNI using a Fujitsu ethernet controller chip instead of a LANCE. It has a grand total of 8K onboard memory, which doesn't allow from very many normal packets, let alone mega packets. It's fairly easy to patch the driver to ignore the error condition instead of panic'ing, however, I suspect the result would be to hang the interface if you simply noop'ed out the panic(). Making it do the "right" thing or even toss the "bad" packet(s) would be non-trivial. > > Another (hacky) solution is to set the 'mtu' of all systems on > > the net to a value lower than your uVax-II buffer size. > > You're not serious! There are several hundered machines on the LBL net. In which case hoepfully you have a competent network administrator/wizard? If so take the problem to him. It's probably only one or two bad guys and might be correctable. You might want to take the problem up with DEC software support. While you'll get little sympathy for the oversize packets, you should be able to make a very reasonable case that typical network problems should *never* cause a panic. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
guy@auspex.auspex.com (Guy Harris) (05/31/89)
>I've heard that sun NFS will use big packets, but there are parameters >in fstab to control this. Sun's RPC/NFS implementation will use big *UDP* packets - the size of these is controlled by parameters in "fstab" - but by the time it gets to the link layer IP should have busted them up into properly-sized fragments if necessary. The BSD IP code, which is used in SunOS and, presumably, Ultrix (and probably 99 44/100% of the UNIX TCP/UDP/IP implementations out there, as well as a lot of *non*-UNIX implementations), will do this. If a machine puts out Ethergrams longer than 1500 bytes, it's being *very* antisocial, except maybe if it's talking to other consenting adults. If you're using Internet-family protocols (TCP/UDP/IP/etc.), it's basically the responsibility of IP to ensure that your machine is not being antisocial.