From owner-freebsd-stable Wed Aug 29 21:57:43 2001 Delivered-To: freebsd-stable@freebsd.org Received: from guru.mired.org (okc-94-248-46.mmcable.com [24.94.248.46]) by hub.freebsd.org (Postfix) with SMTP id 08FE337B405 for ; Wed, 29 Aug 2001 21:57:33 -0700 (PDT) (envelope-from mwm@mired.org) Received: (qmail 5930 invoked by uid 100); 30 Aug 2001 04:57:06 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15245.51106.120852.616240@guru.mired.org> Date: Wed, 29 Aug 2001 23:57:06 -0500 To: Alex Varju Cc: Subject: Re: Freezes in 4.4RC on SMP Kernel and gkrellm In-Reply-To: <20010829155138.F60349-100000@snapple.webct.com> References: <15245.28607.676147.717891@guru.mired.org> <20010829155138.F60349-100000@snapple.webct.com> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alex Varju types: > Considering that you've seen problems with this, it seems worth mentioning > that I also have gkrellm running all the time. I have the following > monitors enabled: Clock, CPU, Disk (composite), Network (xl0), Mailcheck, > and Uptime. Turns out that gkrellm can be *very* hazardous to your system. I've got a situation where the system panics every time I start gkrellm. I believe this is a bug in gkrellm, not in the system. What I did was enable smb in the kernel, to see if gkrellm behaved differently using smb rather than isa for io. I've got two smb devices in the system: smbus0: on intsmb0 smb0: on smbus0 and smbus1: on bti2c0 smb1: on smbus1 gkrellm opens the first one with no problem. It finds the second one, and the system panics. The relevant part of the traceback seems to be: #6 0xc027e05f in trap (frame={tf_fs = -1072300008, tf_es = -1056047088, tf_ds = 16777232, tf_edi = 0, tf_esi = -1059648000, tf_ebp = -863265464, tf_isp = -863265484, tf_ebx = -1063046432, tf_edx = -1071663704, tf_ecx = -1059648000, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1072240230, tf_cs = 8, tf_eflags = 66118, tf_esp = -863265440, tf_ss = -1072362873}) at ../../i386/i386/trap.c:458 #7 0xc016e99a in device_set_softc (dev=0x0, softc=0xc0a332e0) at ../../kern/subr_bus.c:986 #8 0xc0150a87 in iicbus_request_bus (bus=0x0, dev=0xc0d70e00, how=0) at ../../dev/iicbus/iiconf.c:108 #9 0xc01fb5e6 in bti2c_smb_callback (dev=0xc0d70e00, index=1, data=0xcc8b9dc4) at ../../dev/bktr/bktr_i2c.c:248 From looking over gkrellm's code, it assumes that any smb device it finds is the one it knows about - and proceeds to try and extract data from it. This seems like a bad idea - at least in this case. gkrellm also has the problem that it initializes every monitor it knows about, even if that one isn't being displayed. Without the smb devices, it uses /dev/io, and that's left open so that gkrellm can lower it's privileges after opening the file. This means bugs in other modules could stroke /dev/io in some strange way - and I believe that's the root cause of the freezes I'm seeing. I've installed gkrellm WITHOUT_SENSOR=yes - which sgid instead of suid - and enabled all the things that I had on when the system was freezing before, except the sensors. If anyone is interested in the smb panics, I've still got all the relevant files if you need them, or information from them. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message