crash - should I upload the dump?

[Pierre Abbat]

I was copying something from a webpage to a document in Kate and the computer 
froze, then showed me the console saying that X could not be restarted. I 
killed kdm and logged in again. While all the windows were coming up, the 
computer turned itself off. I rebooted and found a dump numbered 12. Here are 
the tracebacks and some other info:

Version String: DragonFly v3.1.0.114.g7fba7-DEVELOPMENT #4: Sun Feb 5 15:33:37 
EST 2012 p...@darner.ixazon.lan:/usr/obj/usr/src/sys/GENERIC

panic: device_unbusy: called for non-busy device
Trace beginning at frame 0xcc956954
panic(,0,c06daaa4,cc956988,cc971160) at panic+0x19e 0xc0383933 
panic(c06daaa4,0,cc9569ac,c04c79b1,c2e85528) at panic+0x19e 0xc0383933 
device_unbusy(c2e85528,0,cc9712ac,cdd3aee0,cdd3aee0) at device_unbusy+0x1c 
0xc039f82f 
agp_close(cc9569b8,c08a5bf0,cdd3aee0,6,2000) at agp_close+0xb3 0xc04c79b1 
dev_dclose(cdd3aee0,6,2000,ccb9d660,d087f7b8) at dev_dclose+0x4b 0xc0366d17 
devfs_spec_close(cc9569fc,c08b3b78,d08c4be0,d087f7b8,0) at 
devfs_spec_close+0x14d 0xc0545be0 
vop_close(d08c4be0,d087f7b8,6,0,c0c789c0) at vop_close+0x7c 0xc03fb381 
vclean_vxlocked(d087f7b8,8,c0c789c0,c0d0f600,cc956b90) at vclean_vxlocked+0xf2 
0xc03ead71 
vgone_vxlocked(d087f7b8,c0c78a00,a00,cc97127c,cc956ba4) at 
vgone_vxlocked+0x50 0xc03eaf63 
vflush_scan(d08ae660,d087f7b8,cc956b90,c03fa6e4,cc956b50) at vflush_scan+0x98 
0xc03edc8d 
vmntvnodescan(d08ae660,2,0,c03edbf5,cc956b90) at vmntvnodescan+0x1af 
0xc03ede6f 
vflush(d08ae660,0,2,d08ae660,0) at vflush+0x181 0xc03ee0e6 
devfs_vfs_unmount(d08ae660,8,d08ae660,0,d08ae684) at 
devfs_vfs_unmount+0x46 0xc0546fc2 
vfs_unmount(d08ae660,8,14,1000,0) at vfs_unmount+0x68 0xc03fbda1 
dounmount(d08ae660,8,d08ae660,1,cc956c60) at dounmount+0x220 0xc03f6e00 
vfs_umountall_callback(d08ae660,0,4,0,c0c78c78) at vfs_umountall_callback+0x1f 
0xc03e9142 
mountlist_scan(c03e9123,0,6,cc956ca4,c03835d8) at mountlist_scan+0x119 
0xc03ee4fa 
vfs_unmountall(c06af5e0,0,c037c5c4,ccad2498,4000) at vfs_unmountall+0x22 
0xc03e860b 
boot(0,8,cc956d34,c065ebcc,cc956cf0) at boot+0x2d6 0xc03835d8 
sys_reboot(cc956cf0,cc956d00,4,0,0) at sys_reboot+0x3f 0xc0383c73 
syscall2(cc956d40) at syscall2+0x270 0xc065ebcc 
Xint0x80_syscall() at Xint0x80_syscall+0x36 0xc062dc16 

(kgdb) #0  _get_mycpu () at ./machine/thread.h:79
#1  md_dumpsys (di=0xc0c02820) at 
/usr/src/sys/platform/pc32/i386/dump_machdep.c:264
#2  0xc03830e8 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:925
#3  0xc03836fe in boot (howto=) at 
/usr/src/sys/kern/kern_shutdown.c:387
#4  0xc0383967 in panic (fmt=0xc06daaa4 "device_unbusy: called for non-busy 
device") at /usr/src/sys/kern/kern_shutdown.c:831
#5  0xc039f82f in device_unbusy (dev=0xc2e85528) at 
/usr/src/sys/kern/subr_bus.c:1513
#6  0xc04c79b1 in agp_close (ap=0xcc9569b8) at /usr/src/sys/dev/agp/agp.c:800
#7  0xc0366d17 in dev_dclose (dev=0xcdd3aee0, fflag=6, devtype=8192) at 
/usr/src/sys/kern/kern_device.c:168
#8  0xc0545be0 in devfs_spec_close (ap=0xcc9569fc) at 
/usr/src/sys/vfs/devfs/devfs_vnops.c:1081
#9  0xc03fb381 in vop_close (ops=0xd08c4be0, vp=0xd087f7b8, fflag=6) at 
/usr/src/sys/kern/vfs_vopops.c:310
#10 0xc03ead71 in vclean_vxlocked (vp=0xd087f7b8, flags=) at 
/usr/src/sys/kern/vfs_subr.c:1216
#11 0xc03eaf63 in vgone_vxlocked (vp=0xd087f7b8) at 
/usr/src/sys/kern/vfs_subr.c:1424
#12 0xc03edc8d in vflush_scan (mp=0xd08ae660, vp=0xd087f7b8, data=0xcc956b90) 
at /usr/src/sys/kern/vfs_mount.c:1266
#13 0xc03ede6f in vmntvnodescan (mp=0xd08ae660, flags=, 
fastfunc=0, slowfunc=0xc03edbf5 , data=0xcc956b90) at 
/usr/src/sys/kern/vfs_mount.c:1081
#14 0xc03ee0e6 in vflush (mp=0xd08ae660, rootrefs=0, flags=2) at 
/usr/src/sys/kern/vfs_mount.c:1198
#15 0xc0546fc2 in devfs_vfs_unmount (mp=0xd08ae660, mntflags=524288) at 
/usr/src/sys/vfs/devfs/devfs_vfsops.c:145
#16 0xc03fbda1 in vfs_unmount (mp=0xd08ae660, mntflags=524288) at 
/usr/src/sys/kern/vfs_vfsops.c:137
#17 0xc03f6e00 in dounmount (mp=0xd08ae660, flags=524288) at 
/usr/src/sys/kern/vfs_syscalls.c:757
#18 0xc03e9142 in vfs_umountall_callback (mp=0xd08ae660, data=0x0) at 
/usr/src/sys/kern/vfs_subr.c:1801
#19 0xc03ee4fa in mountlist_scan (callback=0xc03e9123 
, data=0x0, how=) at 
/usr/src/sys/kern/vfs_mount.c:905
#20 0xc03e860b in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:1790
#21 0xc03835d8 in boot (howto=) at 
/usr/src/sys/kern/kern_shutdown.c:375
#22 0xc0383c73 in sys_reboot (uap=0xcc956cf0) at 
/usr/src/sys/kern/kern_shutdown.c:202
#23 0xc065ebcc in syscall2 (frame=0xcc956d40) at 
/usr/src/sys/platform/pc32/i386/trap.c:1328
#24 0xc062dc16 in Xint0x80_syscall () at 
/usr/src/sys/platform/pc32/i386/exception.s:878
#25 0x001f in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Pierre
-- 
When a barnacle settles down, its brain disintegrates.
Já não percebe nada, já não percebe nada.

XScreensaver Tricks?

[Chris Turner]

Hello -

Usually I have xscreensaver installed suid so that it can grab password infos -
& it is started from an ~/.xinitrc by my normal user -

I'm in the process of updating packages and this no longer works
(only entering the root password unlocks the screen now)

Log messages for xscreensaver -verbose between the working 5.11 copy
(old box - running 2.10) and the new box (xscreensaver 5.15 / df-2.13)
are roughly identical

Any ideas?

Can probably dig around on this but pinging first in case anyone
has run into the same issue of late & not digging on this gives
me time to dig on GConf stuff from earlier thread

Cheers,

- Chris

ghc linker problem with __thread int errno

[Goetz Isenmann]

Hi!

Since there seems to be some interest in ghc/haskell on #dragonflybsd,
I would like to write down, what my (uneducated) guess is about the main
problem porting ghc to dfly.

On dfly we have "__thread int errno", "#define errno (*__error())", and
"static __inline int *__error(void) { return (&errno); }"

I believe, that ghc generates correct code for this thread local (tls)
access (uses the C comiler), but the ghc linker/load (rts/linker.c)
cannot handle the resulting relocation types:
#define R_386_TLS_IE15  /* Absolute address of GOT for -ve static TLS */
#define R_X86_64_GOTTPOFF 22/* PC relative offset to IE GOT entry */

To get an idea, what the ghc linker should do, I did this:

$ cat >main.c
#include 
int main() {
  return errno;
}
$ gcc -c -O main.c
$ gcc -o main main.o
$ objdump -d main.o

main.o: file format elf32-i386

Disassembly of section .text:

 :
   0:   8d 4c 24 04 lea0x4(%esp),%ecx
   4:   83 e4 f0and$0xfff0,%esp
   7:   ff 71 fcpushl  0xfffc(%ecx)
   a:   55  push   %ebp
   b:   89 e5   mov%esp,%ebp
   d:   51  push   %ecx
   e:   65 a1 00 00 00 00   mov%gs:0x0,%eax
  14:   8b 15 00 00 00 00   mov0x0,%edx
  1a:   8b 04 10mov(%eax,%edx,1),%eax
  1d:   59  pop%ecx
  1e:   c9  leave  
  1f:   8d 61 fclea0xfffc(%ecx),%esp
  22:   c3  ret
$ objdump -d main
...
08048548 :
 8048548:   8d 4c 24 04 lea0x4(%esp),%ecx
 804854c:   83 e4 f0and$0xfff0,%esp
 804854f:   ff 71 fcpushl  0xfffc(%ecx)
 8048552:   55  push   %ebp
 8048553:   89 e5   mov%esp,%ebp
 8048555:   51  push   %ecx
 8048556:   65 a1 00 00 00 00   mov%gs:0x0,%eax
 804855c:   8b 15 6c 96 04 08   mov0x804966c,%edx
---^
 8048562:   8b 04 10mov(%eax,%edx,1),%eax
 8048565:   59  pop%ecx
 8048566:   c9  leave  
 8048567:   8d 61 fclea0xfffc(%ecx),%esp
 804856a:   c3  ret
 804856b:   90  nop
...
$ objdump -h main

main: file format elf32-i386

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
...
 17 .got  0004  0804966c  0804966c  066c  2**2
^^
  CONTENTS, ALLOC, LOAD, DATA
...

The same on x86_64:

$ objdump -d main.o

main.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   48 8b 05 00 00 00 00mov0x0(%rip),%rax# 7 
   7:   64 48 8b 14 25 00 00mov%fs:0x0,%rdx
   e:   00 00 
  10:   8b 04 02mov(%rdx,%rax,1),%eax
  13:   c3  retq   
$ objdump -d main
...
  40060c:   48 8b 05 8d 02 20 00mov0x20028d(%rip),%rax# 
6008a0 <_DYNAMIC+0x170>
---
  400613:   64 48 8b 14 25 00 00mov%fs:0x0,%rdx
--^^
  40061a:   00 00 
  40061c:   8b 04 02mov(%rdx,%rax,1),%eax
  40061f:   c3  retq   
...
$ objdump -h main

main: file format elf64-x86-64

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
...
 18 .got  0008  006008a0  006008a0  08a0  2**3
^^
  CONTENTS, ALLOC, LOAD, DATA
...
$ python2.6 -c 'print hex(0x6008a0 - 0x20028d)'
0x400613


This gives me the idea, that the ghc linker should insert a pointer to
the .got segment on i386 and insert the 32bit offset to the .got
segment on x86_64.

So the next point on my todo list for ghc is, to recompile ghc without
my errno access wrapper, take the .got value from the resulting binary
and recompile ghc again with the linker inserting this value, check
that the .got value hasn't changed, and see what happens.

If this goes well, the next steps would be to (a) find out, how to
calculate the .got value inside the linker, and (b) think about an
experiment, that could show me what has to be done, when there is more
than one tls variable.

Hmm, maybe I should try also from the opposite side: How important is
this "static __inline" on the __error function?
Are there any situations, where one would notice a performance impact?
-- 
Goetz Isenmann
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Michael Heinrichs, 
Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Sitz/Registered Office: Tuebingen
R