dietrich@cernvax.UUCP (dietrich wiegandt) (11/10/89)
After we installed Ultrix3.1 on our VAX 8530 plus several patches concerning LAT terminal connections and DECNET, we got at least one crash per day: panic: m_free has bad m_cltype The sequence of calls according to the dump is _Xnetintr(...) ... _latintr() ... _process_vc_run(...) ... _m_freem(...)... _panic(...)... I have the suspicion that the problem is related to dial-in modems for uucp traffic being connected via a portselector (GANDALF) to DEC Terminal servers for connection to the 8530. When I disabled uucp login for about a day, crashing stopped. We have reverted to the 3.0 kernel for the time being and have not seen these crashes any more, however, we are now again suffering from the tape problems of Release 3.0. A tape with several dumps has been sent to our local DEC support, but we have not got any fix so far. Has anybody had a similar experience? Any ideas? Your help will be much appreciated. Dietrich Wiegandt
grr@cbmvax.UUCP (George Robbins) (11/11/89)
In article <1134@cernvax.UUCP> dietrich@cernvax.UUCP (dietrich wiegandt) writes: > After we installed Ultrix3.1 on our VAX 8530 plus several patches > concerning LAT terminal connections and DECNET, we got at least one crash > per day: > > panic: m_free has bad m_cltype > > The sequence of calls according to the dump is > > _Xnetintr(...) ... > _latintr() ... > _process_vc_run(...) ... > _m_freem(...)... > _panic(...)... If these are the same patches that CSC got from Ultrix engineering when I report LAT problems with 3.1, one of them is very bogus. If you do the following in adb: bucket+20<$mbuf You will probably find the this free mbuf chain is corrupted and/or contains duplicated entries or loops back on itself. Very ugly... > A tape with several dumps has been sent to our local DEC support, but we > have not got any fix so far. > > Has anybody had a similar experience? Any ideas? > Your help will be much appreciated. Make a big stink and see if you can actually get DEC to fix the problem. You will have to generate and SPR and push thru your local service organization that this problem results in system crashes and there is no work around, etc... I was making progress on these problems until DEC and I reached an impasse over a red herring over a 785 memory controller not up to current ECO status, and I haven't had the time lately to be sufficiently nasty to get more action out of them... -- 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)