All, We still have a ZFS-triggerable panic. The conditions under which the panic happens are "simple": 1. Create a mount-point /dos, and mount a MS-DOS file system there. 2. Create directory /dos/zfs 3. Make /boot/zfs a symlink to /dos/zfs 4. create or import a pool, like "zpool import tank" ZFS will create/update the zpool cache (/boot/zfs/zpool.cache) and when done exits the zfskern/solthread thread, at which time the panic happens: panic: mutex Giant owned at /tank/usr/src/sys/kern/kern_thread.c:357 cpuid = 0 KDB: enter: panic [thread pid 8 tid 100147 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe1f3f0,gp ;; db> show alllocks Process 8 (zfskern) thread 0xe000000010df4a20 (100147) exclusive sleep mutex process lock (process lock) r = 0 (0xe000000010407660) locked _at_ /tank/usr/src/sys/kern/kern_kthread.c:326 exclusive sleep mutex Giant (Giant) r = 1 (0xe0000000048f8da8) locked _at_ /tank/usr/src/sys/kern/vfs_lookup.c:755 It looks to me that this is a bug in vfs_lookup.c, but I'm not savvy enough to know this for sure or fix it fast myself. Help is welcome, because this particular bug hits ia64 hard: /boot is a symlink to /efi/boot, where /efi is a msdosfs mount point. FYI, -- Marcel Moolenaar xcllnt_at_mac.comReceived on Wed Dec 30 2009 - 20:56:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:59 UTC