On Tue, 01 Dec 2009 13:23:37 -0000 Milan Bouchet-Valat wrote: > Interesting! Could you simply try the steps I described in my first > comment? We must find out what's going on before reporting this against > HAL. I may well be that liboobs is doing something bad here. Here's the gdb output: $ gdb shares-admin GNU gdb (GDB) 7.0-ubuntu Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/bin/shares-admin...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/shares-admin [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. hal_context_get_initial_devices (config=0x80aec88) at oobs-ifacesconfig.c:194 194 oobs-ifacesconfig.c: No such file or directory. in oobs-ifacesconfig.c (gdb) ba #0 hal_context_get_initial_devices (config=0x80aec88) at oobs-ifacesconfig.c:194 #1 init_hal_context (config=0x80aec88) at oobs-ifacesconfig.c:233 #2 oobs_ifaces_config_init (config=0x80aec88) at oobs-ifacesconfig.c:246 #3 0x0020697f in g_type_create_instance () from /usr/lib/libgobject-2.0.so.0 #4 0x001eb748 in ?? () from /usr/lib/libgobject-2.0.so.0 #5 0x00e8410a in oobs_object_constructor (type=134969616, n_construct_properties=1, construct_params=0x80b7910) at oobs-object.c:210 #6 0x001ecb62 in g_object_newv () from /usr/lib/libgobject-2.0.so.0 #7 0x001ed5f1 in g_object_new_valist () from /usr/lib/libgobject-2.0.so.0 #8 0x001ed70e in g_object_new () from /usr/lib/libgobject-2.0.so.0 #9 0x00e95d0b in oobs_ifaces_config_get () at oobs-ifacesconfig.c:815 #10 0x08052a33 in ?? () #11 0x0020697f in g_type_create_instance () from /usr/lib/libgobject-2.0.so.0 #12 0x001eb748 in ?? () from /usr/lib/libgobject-2.0.so.0 #13 0x08055655 in ?? () #14 0x08052993 in ?? () #15 0x001ecb62 in g_object_newv () from /usr/lib/libgobject-2.0.so.0 #16 0x001ed5f1 in g_object_new_valist () from /usr/lib/libgobject-2.0.so.0 #17 0x001ed70e in g_object_new () from /usr/lib/libgobject-2.0.so.0 #18 0x080521d6 in ?? () #19 0x08052bc6 in ?? () #20 0x00a4ab56 in __libc_start_main (main=0x8052b40, argc=1, ---Type to continue, or q to quit--- ubp_av=0xbffff314, init=0x8056e60, fini=0x8056e50, rtld_fini=0x236d20 <_dl_fini>, stack_end=0xbffff30c) at libc-start.c:220 #21 0x0804e3a1 in ?? () (gdb) q BTW, after restarting udev, Xfce4's "Governor Plugin", which allows to change the CPU governor, exits after printing the message: "Could not find a device able to handle cpufreq control" Don't know if this is related, or relevant... Looks to me like udev doesn't handle being restarted properly, and liboobs crashing in turn. (I tried disabling udev in the first place because it prevents my second harddrive from spinning down. The HD is unmounted and unused, but I had problems with spinning it down. At first it would immediately spin up after spinning down while udev was running. My workaround was a little script that killall'd udev, hdparm -y, then called /etc/init.d/udev.d restart. This "worked" in 9.04, but obviously not in 9.10... Now, after upgrading to 9.10, it's spinning down properly after 3 idle minutes as set in /etc/hdparm.conf, then randomly spins up again after a while, then spins down again 3 minutes later... Judging from web search results, problems with udev preventing disks from spinning down seem to be common. All this is unrelated to liboobs of course.)