]
----- Forwarded message from Chris Knadle <[email protected]> -----
Date: Thu, 6 Mar 2008 23:29:07 -0500
From: Chris Knadle <[email protected]>
Subject: assfail during unmount xfs 2.6.24.3 [from 2.6.24.y git]
To: [email protected]
During the final unmount before reboot there was an assertion failure from XFS leading to the debug output below; I've included what was available on the screendump, which I handwrote + transcribed. [I also have screenshots from a 2.1 MP camera -- they're slightly ugly but usable.] CONFIG_KEXEC was not compiled in, so I was uanble to get a crashdump via SysRq. I'm sending this along in case someone working on the XFS fs can find + fix a bug. I'm not sending the kernel config in this first post just as not to spam everybody with it if it's not needed -- if desired just ask and I'll send it. Source used: 2.6.24.y from git -- 2.6.24.3.
This is on my Desktop box, x86 system -- single P4 CPU @ 2.6 GHz, IDE disk attached to an onboard HighPoint HPT370 controller, and running Debian Sid.
When replying please CC me, as I am not currently subscribed to the list.
Cheers.
-- Chris
Signature · 82 lines
Chris Knadle [email protected] ------------------- Cleaning up ifdown.... Deactivating swap...done. Unmounting local filesystems...done. Assertion failed: atomic_read(&mp->m_active_trans) == 0, file: fs/xfs/xfs_vfsops.c, line: 708 ------------[ cut here ]------------ kernel BUG at fs/xfs/support/debug.c:82! infalid opcode: 0000 [#1] Modules lined in: nvidia(P) xt_multiport iptable_filter ip_tables x_tables ppdev lp ac battery ipv6 ext2 mbcache joydev sidewinder kqemu loop snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 firmware_class snd_ac97_codec ac97_bus snd_util_mem snd_hwdep parport_pc parport snd_pcm_oss snd_pcm snd_page_alloc snd_mixer_oss psmouse rtc snd_deq_dummy pcspkr serio_raw evdev snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device emu10k1_gp gameport snd soundcore button i2c_i801 i2c_core intel_agp iTCO_wdt agpart shpchp pci_hotplug usbhid hid xfs ide_cd cdrom ata_piix ata_generic libata scsi_mod ide_disk floppy uhci_hcd usbcore hpt366 e1000 piix generic ide_core thermal processor fan Pid: 25313, comm: mount Tainted: P (2.6.24.3-686-initrd-crk1 #1) EIP: 0060:[>f8a67a3f>] EFLAGS: 00010292 CPU: 0 EIP is at assfail+0x1b/0x1f [xfs] EAX: 00000061 EBX: f7faa400 ECX: ffffffff EDX: c034bda0 ESI: dfc97000 EDI: f7faa400 EBP: db175e14 ESP: db175dcc DS: 007b ES: 007b FS: 0000 GS: 033 SS: 0068 Process mount (pid: 25313, ti=db174000 task=f7c32560 task.ti=db174000) Stack: f8a6cc60 f8a6c6b0 f8a6a135 000002c4 f8a57e38 f7faa400 f8a57ee7 00000000 dfc97000 f7faa400 db175e14 f8a66ebc 00000001 f8a7fd20 f7fbd400 00000000 00000001 c0162bd2 00000001 f7fbd43c ffffffff f7fbd400 c0174c1b 00000000 Call Trace: [<f8a57e38>] xfs_attr_quiesce+0x46/0x61 [xfs] [<f8a57ee7>] xfs_mntupdate+0x84/0xbb [xfs] [<f8a66ebc>] xfs_fs_remount+0x3d/0x57 [xfs] [<c0162bd2>] do_remount_sb+0xb5/0x101 [xfs] [<c0174c1b>] do_mount+0x5a9/0x65b [<c0148ec9>] __alloc_pages+0x5f/0x360 [<c014430c>] find_lock_page+0x15/0x67 [<c0150dd8>] handle_mm_fault+0x25a/0x52d [<c0148ec9>] __alloc_pages+0x5f/0x360 [<c0173707>] copy_mount_options+0x28/0x113 [<c0168b45>] getname+0x87/0xaf [<c0174d3f>] sys_mount+0x72/0xa4 [<c0103cf2>] sysenter_past_esp+0x5f/0x85 ======================= Code: d7 6b c7 83 c3 08 81 fb c8 02 a8 f8 75 ee 5b c3 83 ec 10 89 4c 24 0c 89 54 24 08 89 44 24 04 c7 04 24 60 cc a6 f8 e8 0d ed 6a c7 <0f> 0b eb fe 56 53 83 ec 0c 89 c6 83 e6 07 9c 5b fa 89 0c 24 89 EIP: [<f8a67a3f>] assfail+0x1b/0x1f [xfs] SS:ESP 0068:db175dcc ---[ end trace 65bd78ca1bf60304 ]--- WARNING: at kernel/exit.c:917 do_exit() Pid: 25313, comm: mount Tainted: P D 2.6.24.3-686-initrd-crk1 #1 [<c0118ceb>] do_exit+0x669/0x7a4 [<c0116767>] printk+0x1b/0x1f [<c010477a>] do_trap+0x0/0xbd [<c0104a56>] do_invalid_op+0x0/0x8a [<f8a67a3f>] assfail+0x1b/0x1f [xfs] [<f8a57e38>] xfs_attr_quiesce+0x46/0x61 [xfs] [<f8a57ee7>] xfs_mntupdate+0x84/0xbb [xfs] [<f8a66ebc>] xfs_fs_remount+0x3d/0x57 [xfs] [<c0162bd2>] do_remount_sb+0xb5/0x101 [<c0174c1b>] do_mount+0x5a9/0x65b [<c0148ec9>] __alloc_pages+0x5f/0x360 [<c014430c>] find_lock_page+0x15/0x67 [<c0150dd8>] handle_mm_fault+0x25a/0x52d [<c0148ec9>] __alloc_pages+0x5f/0x360 [<c0173707>] copy_mount_options+0x28/0x113 [<c0168b45>] getname+0x87/0xaf [<c0174d3f>] sys_mount+0x72/0xa4 [<c0103cf2>] sysenter_past_esp+0x5f/0x85 ======================== /etc/rc6.d/S60umountroot: line17: 25313 Segmentation fault mount $MOUNT_FORCE_OPT -n -o remount,ro -t dummytype dummydev / 2>/dev/null ----- End forwarded message -----
[2.6.27.25] assfail in xfs_attr_quiesce() during umount
Quoted 4 lines
fs/xfs/xfs_vfsops.c, line: 708
kernel BUG atfs/xfs/support/debug.c: 82!
infalid opcode: 0000 [#1]
Modules lined in: nvidia(P)xt_multiportiptable_filterip_tables
x_tables
Quoted 7 lines
Pid: 25313, comm: mount Tainted: P (2.6.24.3-686-initrd-crk1 #1)
EIP: 0060:[>f8a67a3f>] EFLAGS: 00010292 CPU: 0
EAX: 00000061 EBX:f7faa400ECX: ffffffff EDX:c034bda0
ESI:dfc97000EDI:f7faa400EBP:db175e14ESP:db175dcc
DS: 007b ES: 007b FS: 0000 GS: 033 SS: 0068
Process mount (pid: 25313, ti=db174000 task=f7c32560 task.ti=db174000)Stack: f8a6cc60 f8a6c6b0 f8a6a135 000002c4 f8a57e38 f7faa400 f8a57ee7
00000000
Quoted 2 lines
Call Trace: Code: d7 6b c7 83 c3 08 81 fb c8 02 a8 f8 75 ee 5b c3 83 ec 10 89 4c 24
0c 89
Quoted 4 lines
EIP: [<
f8a67a3f>]assfail+0x1b/0x1f[xfs] SS:ESP 0068:db175dccWARNING: at kernel/exit.c:917 do_exit()Pid: 25313, comm: mount Tainted: P D 2.6.24.3-686-initrd-crk1 #1
/etc/rc6.d/S60umountroot: line17: 25313 Segmentation fault mount
Content-Type: text/plain
Organization: GNU's Not Unix!
Date: Tue, 07 Jul 2009 14:42:15 -0400
Message-Id: <[email protected]>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.3
Content-Transfer-Encoding: 7bit
Hi all. I've seen this failure (only once so far, but even one kernel panic is not good!) in my 2.6.27.25 kernel. Output below.
This was seen before, in earlier kernels; see (2.6.23):
http://marc.info/?l=linux-kernel&m=120106649923499&w=2
And also (2.6.24):
http://archives.free.net.ph/message/20080307.104918.4ea41ede.en.html
According to the thread for the former, it was intended to be resolved by "proper per-vfsmount write count in 2.6.25 as part of the per-mount r/o patches" (C.Hellwig)
Did those fixes indeed go into 2.6.25 (or 2.6.27 or below)? Was there something else that needed to be done for XFS to be able take advantage of that enhancement?
And, is the patch posted by DavidC here:
http://marc.info/?l=linux-kernel&m=120106649923499&w=2
still appropriate to work around this issue for 2.5.27.25?
Thanks!
===================================
umount: cannot remount /dev/md110 read-only
Assertion failed: atomic_read(&mp->m_active_trans) == 0, file: /home/psmith/build/linux/fs/xfs/xfs_vfsops.c, line: 105
------------[ cut here ]------------ Kernel BUG at ffffffffa02340ca [verbose debug info unavailable] invalid opcode: 0000 [1] PREEMPT SMP CPU 7 Modules linked in: rng_core dock scsi_mod libata ata_piix zlib_inflate bnx2 libphy tg3 ipmi_msghandler ipmi_si ipmi_devintf bonding sd_mod sg scsi_transport_sas mptbase mptscsih mptsas mptctl md_mod raid1 raid10 raid0 linear dm_mod dm_multipath dm_round_robin jbd ext3 dm_ioband xfs disklog xxds(P) Pid: 8546, comm: umount Tainted: P 2.6.27.25 #1 RIP: 0010:[<ffffffffa02340ca>] [<ffffffffa02340ca>] assfail+0x1a/0x20 [xfs] RSP: 0000:ffff8801a357fd38 EFLAGS: 00010292 RAX: 00000000000000a5 RBX: ffff880462188000 RCX: ffff88046bcebef0 RDX: ffffffff8054dfc8 RSI: 0000000000000096 RDI: 0000000000000001 RBP: ffff8801a357fd60 R08: ffff88046f84db38 R09: 001c90dd7a1c63bb R10: 0000000000000000 R11: 0000000000000001 R12: ffff8801a357fd68 R13: ffff8801a357fdcc R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff88046f819280(0063) knlGS:00000000f7f9c6c0 CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b CR2: 000000004d8800e1 CR3: 0000000322097000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process umount (pid: 8546, threadinfo ffff8801a357e000, task ffff880390a7f1c0) Stack: ffff8801a357fd60 ffffffffa022178e ffff880462188000 ffffffffa023332c ffff88046cbb7000 0000000000000000 0000000000000000 0000000000000001 0000000000000000 7fffffffffffffff 0000000000000000 0000000000000000 Call Trace: [<ffffffffa022178e>] ? xfs_attr_quiesce+0x4e/0x90 [xfs] [<ffffffffa023332c>] ? xfs_fs_remount+0x10c/0x130 [xfs] [<ffffffff802b23d1>] ? do_remount_sb+0x131/0x1d0 [<ffffffff802cac25>] ? do_remount+0x195/0x1b0 [<ffffffff802cd3da>] ? do_mount+0x1ba/0x230 [<ffffffff8028706e>] ? __get_free_pages+0x1e/0x50 [<ffffffff802e8e4f>] ? compat_sys_mount+0x11f/0x260 [<ffffffff8022ade8>] ? ia32_syscall_done+0x0/0x21 Code: c7 96 69 23 a0 e8 57 66 13 e0 48 83 c4 18 c3 66 90 89 d1 48 83 ec 08 48 89 f2 31 c0 48 89 fe 48 c7 c7 a0 9e 23 a0 e8 a5 6e 25 e0 <0f> 0b eb fe 66 90 41 55 41 54 49 89 f4 55 89 fd 53 48 c7 c7 a0 RIP [<ffffffffa02340ca>] assfail+0x1a/0x20 [xfs] RSP <ffff8801a357fd38> Kernel panic - not syncing: Fatal exception
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Re: [2.6.27.25] assfail in xfs_attr_quiesce() during umount
Quoted 7 lines · Paul Smith
According to the thread for the former, it was intended to be resolved by "proper per-vfsmount write count in 2.6.25 as part of the per-mount r/o patches" (C.Hellwig)
Did those fixes indeed go into 2.6.25 (or 2.6.27 or below)? Was there something else that needed to be done for XFS to be able take advantage of that enhancement?
We haven't fixed the VFS issues yet. In some later kernel we just changed the assert to a warn on for now until the issue is sorted out.
Quoted 2 lines
And, is the patch posted by DavidC here:
http://marc.info/?l=linux-kernel&m=120106649923499&w=2
It looks somehwat dangerous for me. For now I would just comment out the assert or change it to a WARN_ON as in the newer kernels.
I've recently started looking at that area in the VFS again and I'll hopefully make progress on a solution that sets MS_RDONLY at the correct time.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Re: [2.6.27.25] assfail in xfs_attr_quiesce() during umount
Quoted 2 lines · Christoph Hellwig
It looks somehwat dangerous for me. For now I would just comment out the assert or change it to a
WARN_ONas in the newer kernels.
Hah! :-). OK, that works for me.
Thanks Christoph.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs