Date: Sun, 29 Jun 2003 21:07:51 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Mike Makonnen <mtm@identd.net> Cc: threads@freebsd.org Subject: Re: Regression in libthr on ia64 Message-ID: <20030630040751.GA5993@athlon.pn.xcllnt.net> In-Reply-To: <20030630035135.WEWF20810.pop015.verizon.net@kokeb.ambesa.net> References: <20030630030106.GA1345@athlon.pn.xcllnt.net> <20030630035135.WEWF20810.pop015.verizon.net@kokeb.ambesa.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 29, 2003 at 11:51:34PM -0400, Mike Makonnen wrote:
> On Sun, 29 Jun 2003 20:01:06 -0700
> Marcel Moolenaar <marcel@xcllnt.net> 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:
This GDB was configured as "i386-undermydesk-freebsd"...
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc0237f0e
stack pointer = 0x10:0xd2235a90
frame pointer = 0x10:0xd2235a9c
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 548 (gnome-terminal)
trap number = 12
panic: page fault
syncing disks, buffers remaining... 2227 2227 2226 2226 2226 2226 2226 2226 2226 2226 2226 2226 2226 2226 2226 2226 2226 2226 2226 2226 2226 2226
giving up on 1240 buffers
Uptime: 4h22m59s
Dumping 255 MB
ata0: resetting devices ..
done
[CTRL-C to abort] 16 32 48 64 80[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 96 112 128 144 160 176 192 208 224 240
---
Reading symbols from /usr/obj/nfs/freebsd/5.x/src/sys/ATHLON/modules/nfs/freebsd/5.x/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for /usr/obj/nfs/freebsd/5.x/src/sys/ATHLON/modules/nfs/freebsd/5.x/src/sys/modules/linux/linux.ko.debug
#0 doadump () at /nfs/freebsd/5.x/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(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...
> There was a window of opportunity (several hours) yesterday where the interface
> to sigtimedwait was changed but libthr was not.
I kept close track of that. The library I used is guaranteed the
latest. Rebuilt today, with no new commits. Kernel has been built
after the signal changes, with no significant commits not included.
> Also, is it possible to narrow down the time frame during which it broke?
I'll try. I'm not sure I have the time. I first have to tie a couple
of loose ends...
--
Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030630040751.GA5993>