cpw%sneezy@lanl.gov (C. Philip Wood) (08/17/87)
On August 5, our milnet host/gateway which is configured like: Name Mtu Ipkts Ierrs Opkts Oerrs Collis imp0 1006 522915 0 255326 0 4 il0 1500 92210 0 98523 0 17 de0 1500 768926 0 583036 0 464 hsd0 25960 40696 0 37261 0 2 hsp0 1006 563601 0 299209 0 0 lo0 1536 0 0 0 0 0 was doing fine except for the 'de0' which when asked to send a packet would return the ENOBUFS error. The ifqueue for this device was full. It stayed in this state, while the other devices continued to function. We had to reboot the system to continue doing business. Its as if there was no mechanism to wakeup and attempt to drain the queue once it filled up. Any ideas on why this happened, and what to do about it? -Phil Wood (cpw@lanl.gov)
chris@mimsy.UUCP (Chris Torek) (08/18/87)
In article <8821@brl-adm.ARPA> cpw%sneezy@lanl.gov (C. Philip Wood) writes: >... doing fine except for the 'de0' which when asked to send a packet >would return the ENOBUFS error. The ifqueue for this device was full. >It stayed in this state, while the other devices continued to function. I have seen this too, though only on a Vax 8600. I now suspect a hardware problem, possibly like the carry chain timing problem in 785s, in the Unibus/DW780/SBIA/Abus logic chain dealing with interrupts, as this 8600 also loses interrupts on its UDA50s (it has two at present; both lose interrupts under heavy massbuss and ethernet interrupt load). The same DEUNA and one other one have been working well on two Vax 8250s (for all of four days on one, and about 2 weeks on the other). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris