From owner-freebsd-threads@FreeBSD.ORG Sun Jun 29 21:45:30 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DB0637B428 for ; Sun, 29 Jun 2003 21:45:30 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C82E44027 for ; Sun, 29 Jun 2003 21:45:27 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5U4jQAI010388; Mon, 30 Jun 2003 00:45:26 -0400 (EDT) Date: Mon, 30 Jun 2003 00:45:26 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030630040751.GA5993@athlon.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Regression in libthr on ia64 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2003 04:45:30 -0000 On Sun, 29 Jun 2003, Marcel Moolenaar wrote: > On Sun, Jun 29, 2003 at 11:51:34PM -0400, Mike Makonnen wrote: > > On Sun, 29 Jun 2003 20:01:06 -0700 > > Marcel Moolenaar wrote: > > > > > It doesn't matter if I compile with -DWITH_SLEEP or not. > > > > > > Is this a known issue? Is there some work in progress still? > > > > > > > 2nd question first: yes, there is still more work to be done, but committed bits > > should be self-contained and not break anything. > > Ok. > > > Did you update both your kernel and libthr together? when? > > Yes, yesterday. I manually updated both libkse and libthr after some > new commits (without seeing any related kernel commits). I'm rebuilding > the kernel just to be sure. > > i386 has the same problem and libkse causes a nice coredump: I assume not with your test program; t.c works just fine with libkse for me. > (kgdb) bt > #0 doadump () at /nfs/freebsd/5.x/src/sys/kern/kern_shutdown.c:240 > #1 0xc023149d in boot (howto=256) > at /nfs/freebsd/5.x/src/sys/kern/kern_shutdown.c:372 > #2 0xc0231859 in panic () at /nfs/freebsd/5.x/src/sys/kern/kern_shutdown.c:550 > #3 0xc037a012 in trap_fatal (frame=0xd2235a50, eva=0) > at /nfs/freebsd/5.x/src/sys/i386/i386/trap.c:836 > #4 0xc03795d3 in trap (frame= > {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1033618160, tf_esi = -1033632128, tf_ebp = -769434980, tf_isp = -769435012, tf_ebx = -1030172480, tf_edx = 0, tf_ecx = -1031741888, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1071415538, tf_cs = 8, tf_eflags = 66118, tf_esp = -1058233696, tf_ss = 0}) > at /nfs/freebsd/5.x/src/sys/i386/i386/trap.c:256 > #5 0xc036a0b8 in calltrap () at {standard input}:96 > #6 0xc0239aff in mi_switch () > at /nfs/freebsd/5.x/src/sys/kern/kern_synch.c:524 > #7 0xc020bcf4 in cv_switch_catch (td=0xc2643d10) > at /nfs/freebsd/5.x/src/sys/kern/kern_condvar.c:123 > #8 0xc020b409 in cv_timedwait_sig (cvp=0x0, mp=0xc0428680, timo=0) > at /nfs/freebsd/5.x/src/sys/kern/kern_condvar.c:433 > #9 0xc0259647 in poll (td=0xc2643d10, uap=0xd2235d10) > at /nfs/freebsd/5.x/src/sys/kern/sys_generic.c:1027 > #10 0xc037a33a in syscall (frame= > {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 681148880, tf_esi = 0, tf_ebp = 134852520, tf_isp = -769434252, tf_ebx = 681149764, tf_edx = 12, tf_ecx = 12, tf_eax = 209, tf_trapno = 22, tf_err = 2, tf_eip = 683943555, tf_cs = 31, tf_eflags = 514, tf_esp = 134852428, tf_ss = 47}) > at /nfs/freebsd/5.x/src/sys/i386/i386/trap.c:1023 > #11 0xc036a10d in Xint0x80_syscall () at {standard input}:138 > ---Can't read userspace from dump, or kernel process--- > > Notice frame #8... Hmm, something sure seems to be borken in the kernel. I haven't seen this yet, but I'm using kde not gnome. -- Dan Eischen