Regression in libthr on ia64

[Marcel Moolenaar]

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 at 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 at xcllnt.net