Bug#681161: [squeeze] General Protection Fault or Invalid Opcode in mm/slub.c:2969
Chris Angelico wrote:
> The first one is an invalid opcode trap. Going from its "cut here":
Can we have a few (10, maybe) lines before that, too? Sorry for the
lack of clarity.
[3147 seconds into the boot]
> ------------[ cut here ]------------
> kernel BUG at /build/buildd-linux-2.6_2.6.32-45-amd64-FcX7RM/linux-2.6-2.6.32/debian/build/source_amd64_none/mm/slub.c:2969!
> invalid opcode: 0000 [#1] SMP Jul 11 10:07:56 archibald
> last sysfs file: /sys/devices/pci0000:00/0000:00:12.0/host2/target2:0:0/2:0:0:0/block/sda/uevent
> CPU 1
> Modules linked in: parport_pc ppdev powernow_k8 cpufreq_userspace lp cpufreq_powersave cpufreq_conservative cpufreq_stats parport sco bridge stp bnep rfcomm l2cap crc16 bluetooth binfmt_misc uinput fuse loop firewire_sbp2 snd_hda_codec_idt radeon ttm drm_kms_helper drm i2c_algo_bit snd_hda_intel snd_hda_codec snd_hwdep arc4 ecb snd_pcm snd_seq joydev snd_timer b43 rng_core snd_seq_device mac80211 psmouse yenta_socket edac_core shpchp serio_raw cfg80211 edac_mce_amd pcspkr dell_laptop rsrc_nonstatic pci_hotplug snd dcdbas i2c_piix4 k8temp evdev i2c_core wmi soundcore rfkill snd_page_alloc video output led_class processor button battery ac ext3 jbd mbcache sg usbhid hid sr_mod cdrom sd_mod crc_t10dif ata_generic ahci ssb firewire_ohci mmc_core tg3 pata_atiixp ohci_hcd pcmcia firewire_core crc_itu_t libphy ehci_hcd libata scsi_mod pcmcia_core usbcore nls_base thermal thermal_sys [last unloaded: scsi_wait_scan]
> Pid: 2164, comm: udisks-daemon Not tainted 2.6.32-5-amd64 #1 Latitude D531
> RIP: 0010:[<ffffffff810e77ef>] [<ffffffff810e77ef>] kfree+0x55/0xcb
> RSP: 0018:ffff88006e5b1a48 EFLAGS: 00010246
> RAX: 0000000000000400 RBX: ffff880037b609f0 RCX: ffffffffa00604c0
> RDX: ffff880037b609c0 RSI: ffff8800019120d0 RDI: ffffea0000000000
> RBP: ffff880000000000 R08: ffffffff8149bd88 R09: ffffffff81479930
> R10: 00007f65236528e7 R11: ffffffff810b5def R12: ffffffffa01a36db
> R13: 0000000000000001 R14: ffff880000000000 R15: ffff8800774246a0
> FS: 00007f4bc17ac7a0(0000) GS:ffff880001900000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00007f6523653764 CR3: 000000006e6d1000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process udisks-daemon (pid: 2164, threadinfo ffff88006e5b0000, task ffff88006e52e9f0)
> Stack:
> ffff880037b609f0 ffff880037b609c0 0000000000000000 ffffffffa01a36db
> <0> 0000000000000296 ffff88006e5b1a98 ffff88006e5b1ef8 ffffffff81067d07
> <0> ffff88006e5b1b88 ffffffff812fc49f ffff8800019101b1 0000000000000000
> Call Trace:
> [<ffffffffa01a36db>] ? sr_media_change+0x253/0x27a [sr_mod]
This is presumably
kfree(sshdr);
in sr_media_change. That's allocated with kzalloc earlier in the same
function and the pointer is not modified after then, so this looks
like memory corruption, due to bad memory, other misbehaving hardware,
or a kernel bug.
In the current configuration, does memtest86+ report the memory to be
ok?
Have there been any other weird symptoms recently, or is this the
first time?
Thanks again.
Jonathan
> [<ffffffff81067d07>] ? hrtimer_cancel+0xc/0x16
> [<ffffffff812fc49f>] ? schedule_hrtimeout_range+0xd5/0x112
> [<ffffffffa0195074>] ? media_changed+0x42/0x74 [cdrom]
> [<ffffffff81112026>] ? check_disk_change+0x22/0x53
> [<ffffffffa0199808>] ? cdrom_open+0x8d2/0x962 [cdrom]
> [<ffffffff810fc2ea>] ? do_sys_poll+0x316/0x391
> [<ffffffff810fcf71>] ? __pollwait+0x0/0xd6
> [<ffffffff810fd047>] ? pollwake+0x0/0x59
> [<ffffffff810fd047>] ? pollwake+0x0/0x59
> [<ffffffff8118fb03>] ? kobject_get+0x12/0x17
> [<ffffffff811845ec>] ? get_disk+0x95/0xb4
> [<ffffffff81223160>] ? kobj_lookup+0x169/0x1a1
> [<ffffffff8118fb03>] ? kobject_get+0x12/0x17
> [<ffffffffa01a3464>] ? sr_block_open+0x86/0x9f [sr_mod]
> [<ffffffff81112d37>] ? __blkdev_get+0xc6/0x342
> [<ffffffff81112fba>] ? blkdev_open+0x0/0x96
> [<ffffffff81113021>] ? blkdev_open+0x67/0x96
> [<ffffffff810ed942>] ? __dentry_open+0x19d/0x2bf
> [<ffffffff810f91a3>] ? do_filp_open+0x4e4/0x94b
> [<ffffffffa0196fce>] ? cdrom_release+0x1ae/0x1fe [cdrom]
> [<ffffffff81097f0e>] ? rcu_start_gp+0x197/0x1c0
> [<ffffffff811021c5>] ? alloc_fd+0x67/0x10c
> [<ffffffff810ed6d3>] ? do_sys_open+0x55/0xfc
> [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b
> Code: 83 c3 08 48 83 3b 00 eb ec 48 83 fd 10 0f 86 89 00 00 00 48 89 ef e8 b9 e8 ff ff 48 89 c7 48 8b 00 84 c0 78 13 66 a9 00 c0 75 04 <0f> 0b eb fe 5b 5d 41 5c e9 8c 54 fd ff 48 8b 4c 24 18 4c 8b 4f
> RIP [<ffffffff810e77ef>] kfree+0x55/0xcb
> RSP <ffff88006e5b1a48>
> ---[ end trace a9174ff557aa957d ]---
[...]
> The stuff after "end trace" is all normal for that box.
Reply to: