You are not logged in.

#1 2009-11-30 09:27:02

chpln
Member
From: Australia
Registered: 2009-09-17
Posts: 361

makechrootpkg with aufs: kernel panic

I've now experienced three separate kernel panics during running makechrootpkg, and I'm strongly suspecting aufs is the reason behind this.

I followed the guide in the wiki for setting up a chroot for building packages (http://wiki.archlinux.org/index.php/Dev … ean_Chroot), and everything seems to work as usual.  Generally, I can successfully complete a build in a x86_64 chroot without issues.  However I occassionally (I guess 10-20% of builds) trigger a kernel panic.  The log for the crash follows.

/var/log/messages.log:

Nov 30 19:08:04 gnawty kernel: Modules linked in: aufs exportfs ipv6 hdaps tp_smapi thinkpad_ec ext2 btusb bluetooth usbhid hid snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq arc4 snd_seq_device ecb i915 joydev iwl3945 iwlcore mac80211 snd_hda_codec_analog pcmcia snd_pcm_oss snd_mixer_oss rtc_cmos rtc_core drm rtc_lib cfg80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc irtty_sir sir_dev nsc_ircc i2c_algo_bit irda crc_ccitt yenta_socket rsrc_nonstatic pcmcia_core thinkpad_acpi rfkill led_class nvram uhci_hcd iTCO_wdt psmouse iTCO_vendor_support thermal battery video ehci_hcd button ac processor i2c_i801 i2c_core e1000e usbcore output sg serio_raw evdev intel_agp ext3 jbd mbcache sd_mod sr_mod cdrom pata_acpi ata_generic ahci ata_piix libata scsi_mod
Nov 30 19:08:04 gnawty kernel: Pid: 6661, comm: pacman Not tainted 2.6.31-ARCH #1 6371A14
Nov 30 19:08:04 gnawty kernel: RIP: 0010:[<ffffffff81119fad>]  [<ffffffff81119fad>] __kmalloc+0x9d/0x280
Nov 30 19:08:04 gnawty kernel: RSP: 0018:ffff88003b3af968  EFLAGS: 00010006
Nov 30 19:08:04 gnawty kernel: RAX: 0000000000000000 RBX: 6c7265702e68772e RCX: ffffffffa05b4b54
Nov 30 19:08:04 gnawty kernel: RDX: 0000000000000000 RSI: 0000000000000050 RDI: 0000000000000006
Nov 30 19:08:04 gnawty kernel: RBP: ffffffff814b6ab0 R08: ffff8800016a5100 R09: 0000000000000040
Nov 30 19:08:04 gnawty kernel: R10: 0000000008080808 R11: 000000005d4a02a1 R12: 0000000000000050
Nov 30 19:08:04 gnawty kernel: R13: 0000000000000022 R14: 0000000000000206 R15: 0000000000000050
Nov 30 19:08:04 gnawty kernel: FS:  00007effec2da700(0000) GS:ffff880001695000(0000) knlGS:0000000000000000
Nov 30 19:08:04 gnawty kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 30 19:08:04 gnawty kernel: CR2: 00007fa8a37d9870 CR3: 000000003b3ac000 CR4: 00000000000006f0
Nov 30 19:08:04 gnawty kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Nov 30 19:08:04 gnawty kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Nov 30 19:08:04 gnawty kernel: Process pacman (pid: 6661, threadinfo ffff88003b3ae000, task ffff88007e57ea00)
Nov 30 19:08:04 gnawty kernel: 00000000e32e92eb ffffffffa00cd2e4 ffff88003b3af9ec 000000005f4e3f05
Nov 30 19:08:04 gnawty kernel: <0> ffff8800381d5480 0000000000000007 ffff88003b365058 ffff88003b365872
Nov 30 19:08:04 gnawty kernel: <0> 000000000002dbb3 ffff88003b365872 0000000000000008 ffffffffa05b4b54
Nov 30 19:08:04 gnawty kernel: [<ffffffffa00cd2e4>] ? ext3_htree_store_dirent+0x104/0x140 [ext3]
Nov 30 19:08:04 gnawty kernel: [<ffffffffa05b4b54>] ? au_nhash_append_wh+0x64/0x130 [aufs]
Nov 30 19:08:04 gnawty kernel: [<ffffffffa05b42cb>] ? test_empty_cb+0x13b/0x150 [aufs]
Nov 30 19:08:04 gnawty kernel: [<ffffffffa05b4190>] ? test_empty_cb+0x0/0x150 [aufs]
Nov 30 19:08:04 gnawty kernel: [<ffffffffa00ccac0>] ? call_filldir+0x80/0x100 [ext3]
Nov 30 19:08:04 gnawty kernel: [<ffffffffa00cd0ca>] ? ext3_readdir+0x58a/0x6a0 [ext3]
Nov 30 19:08:04 gnawty kernel: [<ffffffffa05b4190>] ? test_empty_cb+0x0/0x150 [aufs]
Nov 30 19:08:04 gnawty kernel: [<ffffffff81385212>] ? thread_return+0x4e/0x71c
Nov 30 19:08:04 gnawty kernel: [<ffffffff811192b5>] ? kmem_cache_alloc+0x175/0x190
Nov 30 19:08:04 gnawty kernel: [<ffffffff81387068>] ? __mutex_lock_killable_slowpath+0x268/0x410
Nov 30 19:08:04 gnawty kernel: [<ffffffffa05b4190>] ? test_empty_cb+0x0/0x150 [aufs]
Nov 30 19:08:04 gnawty kernel: [<ffffffff81132909>] ? vfs_readdir+0xd9/0x100
Nov 30 19:08:04 gnawty kernel: [<ffffffffa05b0ac6>] ? au_h_open+0x1a6/0x2a0 [aufs]
Nov 30 19:08:04 gnawty kernel: [<ffffffffa05a6936>] ? vfsub_readdir+0x26/0x60 [aufs]
Nov 30 19:08:04 gnawty kernel: [<ffffffffa05b3f9a>] ? do_test_empty+0xea/0x100 [aufs]
Nov 30 19:08:04 gnawty kernel: [<ffffffffa05b412b>] ? au_test_empty+0x17b/0x190 [aufs]
Nov 30 19:08:04 gnawty kernel: [<ffffffff813881c2>] ? __down_write_nested+0xd2/0xe0
Nov 30 19:08:04 gnawty kernel: [<ffffffff813881c2>] ? __down_write_nested+0xd2/0xe0
Nov 30 19:08:04 gnawty kernel: [<ffffffffa05bae6b>] ? aufs_rmdir+0x8b/0x420 [aufs]
Nov 30 19:08:04 gnawty kernel: [<ffffffffa05b7e30>] ? aufs_permission+0x2d0/0x3b0 [aufs]
Nov 30 19:08:04 gnawty kernel: [<ffffffff811ecbb2>] ? __up_read+0x32/0xe0
Nov 30 19:08:04 gnawty kernel: [<ffffffff81135b44>] ? shrink_dcache_parent+0x144/0x1b0
Nov 30 19:08:04 gnawty kernel: [<ffffffff81386838>] ? __mutex_lock_slowpath+0x258/0x360
Nov 30 19:08:04 gnawty kernel: [<ffffffff8112c6cc>] ? vfs_rmdir+0x12c/0x170
Nov 30 19:08:04 gnawty kernel: [<ffffffff8112eff1>] ? do_rmdir+0x131/0x150
Nov 30 19:08:04 gnawty kernel: [<ffffffff8111cd77>] ? filp_close+0x67/0xb0
Nov 30 19:08:04 gnawty kernel: [<ffffffff8111ce84>] ? sys_close+0xc4/0x130
Nov 30 19:08:04 gnawty kernel: [<ffffffff8100c382>] ? system_call_fastpath+0x16/0x1b
Nov 30 19:08:04 gnawty kernel: RSP <ffff88003b3af968>
Nov 30 19:08:04 gnawty kernel: ---[ end trace 3f6aacf19f3a06fb ]---

As suspected, aufs is implicated.

$ pacman -Qi aufs2
Name           : aufs2
Version        : 2.6.31_20090910-1
[...]
$ uname -rsm
Linux 2.6.31-ARCH x86_64

I intend to file a bug report regarding this, but I suspect there are quite a few packagers using this setup that have had no issues.  So I am looking to collect some more information from anyone using aufs (can reproduce crash?, architecture, etc.).

Until this is solved, I'll be looking to setup another chroot for building.  Any recommendations on alternative tools to help with this?

EDIT:
This seems to be fixed in kernel26-2.6.32-1 and aufs2-2.6.32_20091203-1.

Update:
Just experienced another aufs-related kernel-panic.  Though they seem much less frequent.

Last edited by chpln (2009-12-21 22:16:23)

Offline

Board footer

Powered by FluxBB