From owner-freebsd-current Thu Feb 22 5:45:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id D9D6F37B401; Thu, 22 Feb 2001 05:45:47 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f1MDh5l88535; Thu, 22 Feb 2001 05:43:05 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 22 Feb 2001 05:45:00 -0800 (PST) From: John Baldwin To: Dag-Erling Smorgrav Subject: Re: A possible bug in the interrupt thread preemption code [Was: Cc: current@FreeBSD.org, "Alexander N. Kabaev" , Maxim Sobolev Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Feb-01 Dag-Erling Smorgrav wrote: > John Baldwin writes: >> On 22-Feb-01 Maxim Sobolev wrote: >> > Dag-Erling Smorgrav wrote: >> > >> >> Maxim Sobolev writes: >> >> > It's not an ata specific problem, but rather a problem of all ISA >> >> > devices (I have an ISA based ata controller). >> >> >> >> I don't think it has anything to do with ISA. I've had similar >> >> problems on a PCI-only system (actually, PCI+EISA motherboard with no >> >> EISA cards) with no ATA devices (disks, CD-ROM and streamer are all >> >> SCSI). >> >> >> >> Considering that backing out rev 1.14 of ithread.c eliminates the >> >> panics, and that that revision is supposed to enable interrupt thread >> >> preemption, and that the crashed kernels show signs of stack smashing, >> >> I'd say the cause is probably a bug in the preemption code. >> > >> > Update: the bug is still here, as of -current from 22 Feb. Hovewer, this >> > time >> > it even doesn't let to boot into single-user with following panic message: >> > kernel trap 12 with interrupts disabled >> > panic: mutex sched lock recursed at ../../kern/kern_synch.c:872 >> >> Errrr. That would be something that is leaking sched_lock. Hmm... > > I have another sched_lock-related problem which showed up over the > weekend. Starting StarOffice 5.2 invariably triggers the following > panic: > > root@aes /var/crash# gdb -k > sGNU gdb 4.18 > Copyright 1998 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-unknown-freebsd". > (kgdb) source ~des/kgdb > (kgdb) kernel 0 > IdlePTD 3526656 > initial pcb at 2cb980 > panicstr: from debugger > panic messages: > --- > panic: mutex sched lock not owned at ../../posix4/ksched.c:215 Easy enough. It seems I missed adding sched_lock around a need_resched(). I'll fix in a second.. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message