SUMMARY: Problems serving Sunos diskless clients from Solaris 2.5 server

From: Michael Assels (mjassels@cs.concordia.ca)
Date: Thu Aug 22 1996 - 10:34:17 CDT


Thanks to the two people from whom I received replies:

Lisa Lopshire <lisa@e-z.net> pointed me at the Solaris FAQ, specifically:

  5.39) Why do I get ``named[]: rt_malloc: memdebug overflow'' errors?

      That's caused by a bug in the Solaris 2.4 named. You need to install
      the appropriate one of the following patches:
          102479-01: SunOS 5.4: memory leak/mismanagement in in.named
          102480-01: SunOS 5.4_x86: memory leak/mismanagement in in.named

Unfortunately, this is Solaris 2.5, and as far as I can tell, this bug is
not present. In any case, I'm pretty sure named isn't involved.

Danny Johnson 0172547 <djohnson@nbserv2.dseg.ti.com> suggested that the
problem might be related to sunview oddities, but the problem occurs with
non-sunview applications too: e.g., xmh and xxgdb.

So, in summary my problem remains unsolved, but thanks for trying.

Michael

--
Michael Assels    Comp. Sci.    Concordia U.    mjassels@cs.concordia.ca
Voice: (514)848-3030  WWW: http://www.cs.concordia.ca/~staffcs/mjassels/
------------------------------------------------------------------------
"O tempura!  O morays!" -- Cicero, after dining on eels fried in batter.

Original question:

I have a Sparc 10 (running Solaris 2.5) serving root filesystems to several Sparcs {2,10,20} running Sunos 4.1.3.

Although many things work, some important things don't. We find that xmh, xxgdb, dbxtool, and others, crash when they try to do normal things with devices. For example:

sunos% trace xmh ... OK until I click on "Quit" in a composition window, then ... open ("/dev/null", 0, 0666) = 4 lseek (4, 0, 2) = 2147483647 <-- 0x7fffffff lseek (4, 0, 1) = 2147483647 brk (0x8004a428) = -1 ENOMEM (Not enough memory) open ("/pkg/X11/lib/X11/XtErrorDB", 0, 017777777) = -1 ENOENT (No such file or directory) write (2, "Error: Cannot perform malloc\n", 29) = Error: Cannot perform malloc 29

sunos% trace dbxtool open ("/dev/win0", 0, 0) = 3 ioctl (3, 0x40086705, 0xf7fff848) = 0 open ("/dev/win1", 0200002, 0) = 4 close (3) = 0 write (2, "window: Base frame not passed pa".., 59) = window: Base frame not passed parent window in environment 59 write (2, "Could not create the tool\n", 26) = Could not create the tool

Of course, none of this happened last week when the server was also running Sunos 4.1.3.

Has anyone else seen this? Is there a known fix (other than putting / on a local disk where it belongs)?



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:08 CDT