https://bugzilla.kernel.org/show_bug.cgi?id=27492
Dave Chinner <david@xxxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |david@xxxxxxxxxxxxx
--- Comment #3 from Dave Chinner <david@xxxxxxxxxxxxx> 2011-02-01 00:58:15 ---
(In reply to comment #0)
> Created an attachment (id=45012)
--> (https://bugzilla.kernel.org/attachment.cgi?id=45012) [details]
> 2.6.37 kernel config
>
> This bug happens on >= kernels since 2.6.34 on Gentoo 32 bit sytems:
> http://bugs.gentoo.org/show_bug.cgi?id=351938
> I had many XFS chrashes on my Lenovo T61 Notebook with lvm under xfs (32 bit
> system (Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz, sata) and also under
> virtual kvm guests describet in the above gentoo bug. The systems chrashed
> also
> with vmalloc=256M very often. Kernel's <=2.6.32 works fine.
>
> Now I fetch the actual version 2.6.37 from kernel.org compile and boot my
> Gentoo kvm guest. I start an high load compilation with emerge and make -j 10
> and distcc to a 64bit crosscompiler system. after compiling 15 packages I got
> the following:
>
> xfs_buf_get: failed to map pages
> vmap allocation for size 1048576 failed: use vmalloc=<size> to increase size.
.....
> cat /proc/meminfo | fgrep -i vmalloc
> VmallocTotal: 122880 kB
> VmallocUsed: 14088 kB
> VmallocChunk: 81420 kB
This is probably caused by buildup of unflushed vmap ranges that have been
released but not yet freed. That's more of a VM problem, not an XFS problem,
though I think I can work around it in XFS by forcing a flush of all the ranges
not yet freed when an vm_map_pages() call fails. Need to read a little more
code first, though.
> xfs_buf_get: failed to map pages
> vmap allocation for size 1048576 failed: use vmalloc=<size> to increase size.
> xfs_buf_get: failed to map pages
> vmap allocation for size 1048576 failed: use vmalloc=<size> to increase size.
> xfs_buf_get: failed to map pages
> BUG: unable to handle kernel NULL pointer dereference at 00000008
> IP: [<f9187b72>] xfs_da_do_buf+0x4c8/0x61f [xfs]
> *pde = 00000000
> Oops: 0000 [#1] SMP
> last sysfs file: /sys/devices/virtio-pci/virtio1/net/eth0/broadcast
> Modules linked in: ipv6 nfsd rtc_cmos tpm_tis rtc_core tpm tpm_bios rtc_lib
> i2c_piix4 virtio_net i6300esb i2c_core virtio_balloon processor pcspkr floppy
> thermal_sys button tg3 libphy e1000 fuse xfs exportfs nfs auth_rpcgss nfs_acl
> lockd sunrpc jfs raid10 dm_snapshot dm_crypt dm_mirror dm_region_hash dm_log
> dm_mod scsi_wait_scan sl811_hcd usbhid ohci_hcd ssb uhci_hcd usb_storage
> ehci_hcd usbcore aic94xx libsas lpfc qla2xxx megaraid_sas megaraid_mbox
> megaraid_mm megaraid aacraid sx8 DAC960 cciss 3w_9xxx 3w_xxxx mptsas
> scsi_transport_sas mptfc scsi_transport_fc scsi_tgt mptspi mptscsih mptbase
> atp870u dc395x qla1280 imm parport dmx3191d sym53c8xx qlogicfas408 gdth
> advansys initio BusLogic arcmsr aic7xxx aic79xx scsi_transport_spi sg pdc_adma
> sata_inic162x sata_mv ata_piix ahci libahci sata_qstor sata_vsc sata_uli
> sata_sis sata_sx4 sata_nv sata_via sata_svw sata_sil24 sata_sil sata_promise
> pata_pcmcia pcmcia pcmcia_core
>
> Pid: 425, comm: i686-pc-linux-g Not tainted 2.6.37 #1 /Bochs
> EIP: 0060:[<f9187b72>] EFLAGS: 00210246 CPU: 1
> EIP is at xfs_da_do_buf+0x4c8/0x61f [xfs]
> EAX: 00000001 EBX: f5947800 ECX: 00000008 EDX: c5631d64
> ESI: 00000000 EDI: 00000000 EBP: c5631d74 ESP: c5631d0c
> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> Process i686-pc-linux-g (pid: 425, ti=c5630000 task=c5248960 task.ti=c5630000)
> Stack:
> 007adb5f 00000000 c5631dc0 c55870dc f4c26220 00000000 00000001 00000000
> 00000000 ffffffff c55870c0 00000000 00000000 c5631d48 c011d903 c5631d5c
> c0414e4e c5631d5c 00200286 eb74ebe0 c5631d6c 00000001 00000000 c5631d9c
> Call Trace:
> [<c011d903>] ? default_spin_lock_flags+0x8/0xd
> [<c0414e4e>] ? _raw_spin_lock_irqsave+0x20/0x28
> [<f9187d25>] ? xfs_da_read_buf+0x18/0x1d [xfs]
> [<f918af47>] ? xfs_dir2_block_lookup_int+0x34/0x178 [xfs]
> [<f918af47>] ? xfs_dir2_block_lookup_int+0x34/0x178 [xfs]
> [<f919fe7c>] ? xfs_log_release_iclog+0x11/0x3a [xfs]
> [<f918b3a0>] ? xfs_dir2_block_removename+0x3d/0x18a [xfs]
> [<f9179022>] ? xfs_bmap_last_offset+0xe4/0xfa [xfs]
> [<f9189c6b>] ? xfs_dir2_isblock+0x18/0x62 [xfs]
> [<f918a213>] ? xfs_dir_removename+0xb4/0xe6 [xfs]
> [<f91ad30a>] ? xfs_remove+0x1d9/0x306 [xfs]
> [<f91b6d1a>] ? xfs_vn_unlink+0x30/0x62 [xfs]
> [<c01bfdd2>] ? vfs_unlink+0x5f/0xbc
> [<c01c1c3b>] ? do_unlinkat+0x94/0xfe
> [<c01a8e06>] ? do_munmap+0x217/0x231
> [<c01c1cb5>] ? sys_unlink+0x10/0x12
> [<c0102858>] ? sysenter_do_call+0x12/0x28
That shouldn't happen, though.
Can you post the output of 'xfs_info <mntpt>', as that might tell us why you're
putting so much load on the vmap subsystem.
Also, can you post the output of:
$ echo 'l *(xfs_da_do_buf+0x4c8)' > gdb /path/to/vmlinux
On the kernel that produced this oops? I'd like to know where in
xfs_da_do_buf() it actually crashed. If you've got a different kernel and
crash, then modify "xfs_da_do_buf+0x4c8" to match the address reported for the
oops.
Cheers,
Dave.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
|