From owner-freebsd-hackers Thu Apr 20 19:19:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 9193537B57B for ; Thu, 20 Apr 2000 19:19:46 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id WAA01645 for ; Thu, 20 Apr 2000 22:19:38 -0400 (EDT) Message-Id: <200004210219.WAA01645@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: spontaneous reboots in 4.0-STABLE (gotcha) Date: Thu, 20 Apr 2000 22:19:37 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, I posted some panic messages awhile ago that appeared to go largely unnoticed. I just got it again (this time while running in X) and I was able to capture them via serial console. I will separate this message into 'fact', 'observation', and 'speculation': Fact: 1) This was the same panic as before (when just running on console). 2) Panic is as follows: > panic: clist reservation botch > mp_lock = 00000001; cpuid = 0; lapic.id = 01000000 > Debugger("panic") > panic: clist reservation botch > mp_lock = 00000003; cpuid = 0; lapic.id = 01000000 > boot() called on cpu#0 > Uptime: 12h14m52s > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > cpu_reset called on cpu#0 > cpu_reset: stopping other CPUs 3) This was running a -STABLE as of today 4) This is a SMP machine with SMP Kernel (2 CPUs) 5) Machine is USB, with USB console keyboard, USB mouse 6) attempting to 'control-alt-escape' into the debugger will sometimes hard-lock the system in the debugger mode. 7: running vinum on 1 SCSI and 2 IDE drives Observations: 1) Appears much more likely if the system bus is busy 2) break to debugger hard-locking the system becomes more likely (to a 100% probability) the longer the system runs. (this is measured in minutes, if I were to try to enter it now, 25minutes after boot, it would lock) Speculations: 1) It appears to be a race condition of some sort in the USB code, perhaps not setting the correct SPL level before branching to the tty routines (for atkbdc it appears automagically set for you, with no such magic for USB that I can find) If anyone needs additional information (configuration hasn't changed since the earlier message), please ask. -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message