Date: Wed, 29 Aug 2001 23:57:06 -0500 From: Mike Meyer <mwm@mired.org> To: Alex Varju <varju@webct.com> Cc: <stable@freebsd.org> Subject: Re: Freezes in 4.4RC on SMP Kernel and gkrellm Message-ID: <15245.51106.120852.616240@guru.mired.org> In-Reply-To: <20010829155138.F60349-100000@snapple.webct.com> References: <15245.28607.676147.717891@guru.mired.org> <20010829155138.F60349-100000@snapple.webct.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Alex Varju <varju@webct.com> 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: <System Management Bus> on intsmb0
smb0: <SMBus general purpose I/O> on smbus0
and
smbus1: <System Management Bus> on bti2c0
smb1: <SMBus general purpose I/O> 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.
<mike
--
Mike Meyer <mwm@mired.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15245.51106.120852.616240>