[systemd-devel] vmware-datarecovery+systemd.automount+EVC = crash

[Reindl Harald]

i spent from 6 PM until now to find out why after hardware
upgrade Fedora 17 VM's are crashing on vSpere5 cluster while
make snapshot / suspend filesystem for VMware-Datarecovery

* EVC Intel® "Westmere" Generation (Xeon® 32nm Core™ i7)
* UUID=....  /boot  ext4  defaults,comment=systemd.automount,noauto  0 1
* open-vm-tools-9.2.2.893683
* vSphere5 build 821926
* Fedora 17 x86_64 with any 3.6.8 to 3.6.10 Kernel (i guess others too)
* /boot was a ext2 without journal mounted as ext4, other FS native ext4

with EVC "Xeon 45 nm Core2" on the same host no problem
without systemd.automount also no problem, even with 32nm i7 EVC
with manual snapshots no problem in any case

this happens really only in this combination on both hosts
one with dual socket E5-2640, one with dual socket E5640

below the stacktrace, may somebody have fun to debug this, i am done
after a whole night finding the workaround not use systemd.automount
in this environment killing the joy of new hardware......

------------[ cut here ]------------
WARNING: at fs/ext4/super.c:339 ext4_journal_start_sb+0x11e/0x130()
Hardware name: VMware Virtual Platform
Modules linked in: binfmt_misc cls_u32 sch_htb xt_hl xt_LOG xt_limit xt_recent nf_conntrack_ipv4 nf_defrag_ipv4
xt_state nf_conntrack xt_iprange xt_multiport vmw_balloon crc32c_intel ghash_clmulni_intel vmxnet3 vmw_pvscsi
Pid: 606, comm: master Not tainted 3.6.10-2.fc17.x86_64 #1
Call Trace:
 [<ffffffff8105c8ef>] warn_slowpath_common+0x7f/0xc0
 [<ffffffff81216296>] ? ext4_dirty_inode+0x26/0x60
 [<ffffffff8105c94a>] warn_slowpath_null+0x1a/0x20
 [<ffffffff8123152e>] ext4_journal_start_sb+0x11e/0x130
 [<ffffffff81216296>] ext4_dirty_inode+0x26/0x60
 [<ffffffff811b85df>] __mark_inode_dirty+0x3f/0x200
 [<ffffffff811a97a1>] update_time+0x81/0xc0
 [<ffffffff811ade40>] ? __mnt_want_write+0x40/0x60
 [<ffffffff811a9878>] file_update_time+0x98/0xf0
 [<ffffffff811997b0>] pipe_write+0x420/0x540
 [<ffffffff8118f9e7>] do_sync_write+0xa7/0xe0
 [<ffffffff8119026c>] vfs_write+0xac/0x180
 [<ffffffff8119059a>] sys_write+0x4a/0x90
 [<ffffffff816270e9>] system_call_fastpath+0x16/0x1b
---[ end trace 4af44fba571309d1 ]---
------------[ cut here ]------------
WARNING: at fs/ext4/super.c:339 ext4_journal_start_sb+0x11e/0x130()
Hardware name: VMware Virtual Platform
Modules linked in: binfmt_misc cls_u32 sch_htb xt_hl xt_LOG xt_limit xt_recent nf_conntrack_ipv4 nf_defrag_ipv4
xt_state nf_conntrack xt_iprange xt_multiport vmw_balloon crc32c_intel ghash_clmulni_intel vmxnet3 vmw_pvscsi
Pid: 606, comm: master Tainted: G        W    3.6.10-2.fc17.x86_64 #1
Call Trace:
 [<ffffffff8105c8ef>] warn_slowpath_common+0x7f/0xc0
 [<ffffffff81216296>] ? ext4_dirty_inode+0x26/0x60
 [<ffffffff8105c94a>] warn_slowpath_null+0x1a/0x20
 [<ffffffff8123152e>] ext4_journal_start_sb+0x11e/0x130
 [<ffffffff81216296>] ext4_dirty_inode+0x26/0x60
 [<ffffffff811b85df>] __mark_inode_dirty+0x3f/0x200
 [<ffffffff811a97a1>] update_time+0x81/0xc0
 [<ffffffff811ade40>] ? __mnt_want_write+0x40/0x60
 [<ffffffff811a9878>] file_update_time+0x98/0xf0
 [<ffffffff811997b0>] pipe_write+0x420/0x540
 [<ffffffff8118f9e7>] do_sync_write+0xa7/0xe0
 [<ffffffff8119026c>] vfs_write+0xac/0x180
 [<ffffffff8119059a>] sys_write+0x4a/0x90
 [<ffffffff816270e9>] system_call_fastpath+0x16/0x1b
---[ end trace 4af44fba571309d2 ]--

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20121214/569c3d19/attachment.pgp>