Bug#637199: oops when disconnecting an external hdd still mounted
Stanislav Maslovski wrote:
> Strange, I remember seeing this request and also checking that the bug
> was reprodicible without loaded virtualbox modules. Did I just forget to
> to write a reply?...
>
> Unfortunately, now I do not have any 32 bit installation of squeeze
> available for testing, and that laptop on which the bug was found and
> reported is several thousands kilometers away from my current location.
>
> I have just tested 2.6.32 from squeeze on a 64 bit installation of
> wheezy and the bug was not reproducible on this system.
Thanks for the update. For reference, here's the relevant log
snippet:
| [ 154.195805] usb 2-4: USB disconnect, address 4
| [ 163.641193] BUG: unable to handle kernel paging request at 00def000
| [ 163.641205] IP: [<c1140c27>] __percpu_counter_add+0x21/0x6d
| [ 163.641221] *pde = 00000000
| [ 163.641227] Oops: 0000 [#1] SMP
| [ 163.641234] last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/present
| [ 163.641242] Modules linked in: ext3 jbd usb_storage acpi_cpufreq cpufreq_stats cpufreq_userspace cpufreq_conservative cpufreq_powersave ipx p8023 parport_pc ppdev lp parport autofs4 vboxnetadp vboxnetflt vboxdrv binfmt_misc fuse dm_crypt dm_mod cls_fw sch_sfq sch_prio tun tcp_westwood iptable_raw ipt_LOG xt_limit xt_state iptable_filter ipt_MASQUERADE ipt_NETMAP iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 xt_length xt_tcpudp xt_dscp xt_MARK xt_owner iptable_mangle ip_tables x_tables coretemp firewire_sbp2 loop snd_hda_codec_idt usbhid hid arc4 btusb bluetooth ecb snd_hda_intel snd_hda_codec b43 rng_core snd_hwdep mac80211 snd_pcm snd_seq uvcvideo snd_timer snd_seq_device sg videodev sr_mod v4l1_compat snd cfg80211 sdhci_pci cdrom ssb joydev ata_generic sdhci firewire_ohci soundcore uhci_hcd pcmcia mmc_core firewire_core pcmcia_core snd_page_alloc ehci_hcd i2c_i801 dell_laptop crc_itu_t ata_piix tg3 psmouse led_class video ricoh_mmc rfkill i2c_core usbcore nl
| s_base button ac battery libphy processor serio_raw output wmi evdev dcdbas ext4 mbcache jbd2 crc16 sd_mod crc_t10dif ahci libata scsi_mod thermal thermal_sys uvesafb cn
| [ 163.641470]
| [ 163.641478] Pid: 3315, comm: umount Not tainted (2.6.32-5-686 #1) Vostro 1400
| [ 163.641485] EIP: 0060:[<c1140c27>] EFLAGS: 00010006 CPU: 1
| [ 163.641493] EIP is at __percpu_counter_add+0x21/0x6d
| [ 163.641498] EAX: 00000001 EBX: f66534cc ECX: 00000000 EDX: 00000001
| [ 163.641505] ESI: f6823528 EDI: 00def000 EBP: 00000010 ESP: f6503efc
| [ 163.641510] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
| [ 163.641518] Process umount (pid: 3315, ti=f6502000 task=f6fbeec0 task.ti=f6502000)
| [ 163.641522] Stack:
| [ 163.641526] f66534cc f6fbeec0 f6823528 00000000 f4dbc780 c108d515 00000010 00000000
| [ 163.641540] <0> c1a747c0 c10cded2 ed1be400 f6f6f600 f6f6fc00 f84b4363 f6f6fc00 f84ba5b0
| [ 163.641555] <0> f84bde0c f4dbc780 c10b4e64 f6823400 00000003 c10b4efe f6f6fc00 c10e3732
| [ 163.641571] Call Trace:
| [ 163.641584] [<c108d515>] ? account_page_dirtied+0x2f/0x4b
| [ 163.641595] [<c10cded2>] ? __set_page_dirty+0x44/0x82
| [ 163.641611] [<f84b4363>] ? ext3_put_super+0x69/0x1b6 [ext3]
| [ 163.641622] [<c10b4e64>] ? generic_shutdown_super+0x46/0xc6
| [ 163.641632] [<c10b4efe>] ? kill_block_super+0x1a/0x2c
| [ 163.641641] [<c10e3732>] ? vfs_quota_off+0x0/0xd
| [ 163.641650] [<c10b549b>] ? deactivate_super+0x4a/0x5f
| [ 163.641660] [<c10c5487>] ? sys_umount+0x2a5/0x2cb
| [ 163.641669] [<c10c54b8>] ? sys_oldumount+0xb/0xe
| [ 163.641680] [<c10030fb>] ? sysenter_do_call+0x12/0x28
| [ 163.641685] Code: ce 12 00 31 d2 89 d0 5b 5e c3 55 57 56 53 83 ec 04 89 04 24 8b 1c 24 64 a1 54 39 41 c1 8b 6c 24 18 8b 7b 14 03 3c 85 30 7d 3b c1 <8b> 07 89 c3 89 c6 c1 fe 1f 89 e8 01 d3 11 ce 99 39 d6 7f 15 7c
| [ 163.641769] EIP: [<c1140c27>] __percpu_counter_add+0x21/0x6d SS:ESP 0068:f6503efc
| [ 163.641781] CR2: 0000000000def000
Not sure what would have triggered this. I'd like it to be fixed by
v2.6.32.42~84 ("block: add proper state guards to __elv_next_request")
or some nearby fix applied in 2.6.32-36, but the symptoms don't match
so well.
Anyway, if you are able to reproduce this again (by using 2.6.32-35
from snapshot.debian.org, or if you get access to the relevant
machine again), that would be very useful.
Ciao,
Jonathan
Reply to: