From owner-freebsd-ia64 Fri Apr 13 16:22:16 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 0454F37B43E; Fri, 13 Apr 2001 16:22:12 -0700 (PDT) (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 f3DNM3G85108; Fri, 13 Apr 2001 16:22:03 -0700 (PDT) (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 Date: Fri, 13 Apr 2001 16:21:34 -0700 (PDT) From: John Baldwin To: dfr@FreeBSD.org Subject: Need some help w/ia64 :) Cc: ia64@FreeBSD.org Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At the moment ia64 kernels on -current panic in the pmap code. I'd like to get a backtrace in ddb, but I can't seem to be able to send input to the console. I was curious if that worked at all or is known to be broken. I also recall Dough saying that ski engaged in some Linux stupidness with respect to the tty's that he had to work around. Unfortunately, I can't seem to find an e-mail with the actual workaround in it, so I'd appreciate any pointers people have. Also, I've noticed that once I start the kernel going, ski is basically unresponsive after the kernel panics. None of the windows update if I move them around, no mouse events, etc. Also, if anyone knows how to fix this panic (dmesg below) that would be great as well. :) dmesg: loading /sys/compile/TEST/kernel... starting kernel... Memory descriptor count: 1 MD 0: type 7 pa 0x200000 cnt 0x4000 Descriptor 0 contains kernel Loading chunk before kernel: 0x200 / 0x500 Loading chunk after kernel: 0xa78 / 0x4200 Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. mtx_init: 0xe000000000a49518 (sleep mutex) zone subsystem LOCK (sleep mutex) All locks list r = 0 at ../../kern/subr_witness.c:346 UNLOCK (sleep mutex) All locks list r = 0 at ../../kern/subr_witness.c:352 mtx_init: 0xe000000000a3f228 (sleep mutex) vm object_list LOCK (sleep mutex) All locks list r = 0 at ../../kern/subr_witness.c:346 UNLOCK (sleep mutex) All locks list r = 0 at ../../kern/subr_witness.c:352 mtx_init: 0xe000000000a3f3d0 (sleep mutex) zone LOCK (sleep mutex) All locks list r = 0 at ../../kern/subr_witness.c:346 UNLOCK (sleep mutex) All locks list r = 0 at ../../kern/subr_witness.c:352 LOCK (sleep mutex) zone subsystem r = 0 at ../../vm/vm_zone.c:248 UNLOCK (sleep mutex) zone subsystem r = 0 at ../../vm/vm_zone.c:250 mtx_init: 0xe000000000a398a8 (sleep mutex) zone LOCK (sleep mutex) All locks list r = 0 at ../../kern/subr_witness.c:346 UNLOCK (sleep mutex) All locks list r = 0 at ../../kern/subr_witness.c:352 LOCK (sleep mutex) zone subsystem r = 0 at ../../vm/vm_zone.c:248 UNLOCK (sleep mutex) zone subsystem r = 0 at ../../vm/vm_zone.c:250 mtx_init: 0xe000000000a39728 (sleep mutex) zone LOCK (sleep mutex) All locks list r = 0 at ../../kern/subr_witness.c:346 UNLOCK (sleep mutex) All locks list r = 0 at ../../kern/subr_witness.c:352 LOCK (sleep mutex) zone subsystem r = 0 at ../../vm/vm_zone.c:248 UNLOCK (sleep mutex) zone subsystem r = 0 at ../../vm/vm_zone.c:250 mtx_init: 0xe000000000a397e8 (sleep mutex) zone LOCK (sleep mutex) All locks list r = 0 at ../../kern/subr_witness.c:346 UNLOCK (sleep mutex) All locks list r = 0 at ../../kern/subr_witness.c:352 LOCK (sleep mutex) zone subsystem r = 0 at ../../vm/vm_zone.c:248 UNLOCK (sleep mutex) zone subsystem r = 0 at ../../vm/vm_zone.c:250 LOCK (sleep mutex) zone r = 0 at ../../vm/vm_zone.c:366 UNLOCK (sleep mutex) zone r = 0 at ../../vm/vm_zone.c:385 mtx_init: 0xe000000000a05858 (sleep mutex) lockmgr LOCK (sleep mutex) All locks list r = 0 at ../../kern/subr_witness.c:346 UNLOCK (sleep mutex) All locks list r = 0 at ../../kern/subr_witness.c:352 LOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:239 UNLOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:475 LOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:239 UNLOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:475 _mtx_lock_sleep: 0xe000000000a77720 recursing LOCK (sleep mutex) Giant r = 1 at ../../vm/vm_kern.c:156 LOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:239 UNLOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:475 LOCK (sleep mutex) zone r = 0 at ../../vm/vm_zone.c:366 UNLOCK (sleep mutex) zone r = 0 at ../../vm/vm_zone.c:385 LOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:239 UNLOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:475 LOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:239 UNLOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:475 LOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:239 UNLOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:475 LOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:239 LOCK (sleep mutex) process lock r = 0 at ../../kern/kern_lock.c:263 UNLOCK (sleep mutex) process lock r = 0 at ../../kern/kern_lock.c:268 UNLOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:475 LOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:239 UNLOCK (sleep mutex) lockmgr r = 0 at ../../kern/kern_lock.c:475 pmap_invalidate_page: pmap = 0xe000000000a542b0, cur = 0 panic: invalidating TLB for non-current pmap panic fatal kernel trap: trap vector = 0xb (Break Instruction) cr.iip = 0xe000000000931a10 cr.ipsr = 0x1010080a2010 cr.isr = 0x0 cr.ifa = 0xe000000000931a10 cr.iim = 0x80100 curproc = 0xe000000000a567c0 pid = 0, comm = Stopped at db> e0 -- 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-ia64" in the body of the message From owner-freebsd-ia64 Fri Apr 13 16:46:45 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id A2A1E37B43F; Fri, 13 Apr 2001 16:46:41 -0700 (PDT) (envelope-from john@baldwin.cx) 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 f3DNkWG85662; Fri, 13 Apr 2001 16:46:33 -0700 (PDT) (envelope-from john@baldwin.cx) 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: Fri, 13 Apr 2001 16:46:03 -0700 (PDT) From: John Baldwin To: John Baldwin Subject: RE: Need some help w/ia64 :) Cc: ia64@FreeBSD.ORG, dfr@FreeBSD.ORG Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 13-Apr-01 John Baldwin wrote: > At the moment ia64 kernels on -current panic in the pmap code. I'd like to > get > a backtrace in ddb, but I can't seem to be able to send input to the console. > I was curious if that worked at all or is known to be broken. I also recall > Dough saying that ski engaged in some Linux stupidness with respect to the > tty's that he had to work around. Unfortunately, I can't seem to find an > e-mail with the actual workaround in it, so I'd appreciate any pointers > people > have. Also, I've noticed that once I start the kernel going, ski is > basically > unresponsive after the kernel panics. None of the windows update if I move > them around, no mouse events, etc. Also, if anyone knows how to fix this > panic > (dmesg below) that would be great as well. :) Well, I've managed to do enough quirky things to kick the console into a usable mode, but trying to do a 'trace' gives a SSC breakpoint. At this point I checked the code to discover: void db_stack_trace_cmd(db_expr_t addr, boolean_t have_addr, db_expr_t count, char *m odif) { } Hmm, guess that still needs to be implemented. :-P -- 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-ia64" in the body of the message From owner-freebsd-ia64 Sat Apr 14 3:55:24 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by hub.freebsd.org (Postfix) with ESMTP id 4C21A37B449; Sat, 14 Apr 2001 03:55:20 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 14oNi3-000Omh-0V; Sat, 14 Apr 2001 11:55:19 +0100 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f3EAs3765348; Sat, 14 Apr 2001 11:54:03 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sat, 14 Apr 2001 11:54:03 +0100 (BST) From: Doug Rabson To: John Baldwin Cc: , Subject: Re: Need some help w/ia64 :) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 13 Apr 2001, John Baldwin wrote: > At the moment ia64 kernels on -current panic in the pmap code. I'd like to get > a backtrace in ddb, but I can't seem to be able to send input to the console. > I was curious if that worked at all or is known to be broken. I also recall > Dough saying that ski engaged in some Linux stupidness with respect to the > tty's that he had to work around. Unfortunately, I can't seem to find an > e-mail with the actual workaround in it, so I'd appreciate any pointers people > have. Also, I've noticed that once I start the kernel going, ski is basically > unresponsive after the kernel panics. None of the windows update if I move > them around, no mouse events, etc. Also, if anyone knows how to fix this panic > (dmesg below) that would be great as well. :) Somehow, ski manages to set VMIN and VTIME on the consoly pty to 255 which stops its console input polling from working. A workaround is to figure out which pty its using with 'stty -a < /dev/ttypX' and when you find it, fix it by 'stty min 0 time 0 < /dev/ttypX'. Unfortunately, I never got around to implementing backtraces with DDB. In general for modern versions of gcc, we will need to parse the unwind records to figure this out. For the toolchain we have now though, gcc always uses a predictable set of registers to store rp and ar.pfs. One could use this to implement a simple backtrace without too much work. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message