Bug 622567 - kernel warning when ripping out wd passport drive
kernel warning when ripping out wd passport drive
Status: CLOSED DUPLICATE of bug 679930
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Don Zickus
Red Hat Kernel QE team
: RHELNAK
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-09 14:59 EDT by Ray Strode [halfline]
Modified: 2011-03-16 13:21 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-16 13:21:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ray Strode [halfline] 2010-08-09 14:59:28 EDT
I have WD Passport drive I use for virt machines and random testing.

Without thinking, I ripped the drive out of the usb port before unmounting it.

Shortly after abrt popped up a "kernel oops" bubble.

The trace it found is:

WARNING: at fs/buffer.c:1159 mark_buffer_dirty+0x82/0xa0() (Not tainted)
Hardware name: Latitude D630                   
Modules linked in: fuse(U) ebtable_nat(U) ebtables(U) ipt_MASQUERADE(U) iptable_nat(U) nf_nat(U) bridge(U) stp(U) llc(U) sunrpc(U) xt_physdev(U) ip6t_REJECT(U) nf_conntrack_ipv6(U) ip6table_filter(U) ip6_tables(U) be2iscsi(U) bnx2i(U) cnic(U) uio(U) cxgb3i(U) cxgb3(U) mdio(U) ib_iser(U) rdma_cm(U) ib_cm(U) iw_cm(U) ib_sa(U) ib_mad(U) ib_core(U) ib_addr(U) ipv6(U) iscsi_tcp(U) libiscsi_tcp(U) libiscsi(U) scsi_transport_iscsi(U) ext2(U) dm_mirror(U) dm_region_hash(U) dm_log(U) sha256_generic(U) cryptd(U) aes_x86_64(U) aes_generic(U) cbc(U) dm_crypt(U) ses(U) enclosure(U) vhost_net(U) macvtap(U) macvlan(U) tun(U) kvm_intel(U) kvm(U) uinput(U) wmi(U) dell_laptop(U) dcdbas(U) sg(U) i2c_i801(U) iTCO_wdt(U) iTCO_vendor_support(U) tg3(U) arc4(U) ecb(U) iwl3945(U) iwlcore(U) mac80211(U) cfg80211(U) rfkill(U) snd_hda_codec_idt(U) snd_hda_intel(U) snd_hda_codec(U) snd_hwdep(U) snd_seq(U) snd_seq_device(U) snd_pcm(U) snd_timer(U) snd(U) soundcore(U) snd_page_alloc(U) ext4(U) mbcache(U) jbd2(U)
sd_mod(U) crc_t10dif(U) sr_mod(U) cdrom(U) firewire_ohci(U) firewire_core(U) crc_itu_t(U) yenta_socket(U) rsrc_nonstatic(U) ahci(U) pata_acpi(U) ata_generic(U) ata_piix(U) usb_storage(U) i915(U) drm_kms_helper(U) drm(U) i2c_algo_bit(U) i2c_core(U) video(U) output(U) dm_mod(U) [last unloaded: microcode]
Pid: 29, comm: khubd Not tainted 2.6.32-37.el6.x86_64 #1
Call Trace:
[<ffffffff8106a703>] warn_slowpath_common+0x83/0xc0
[<ffffffff8106a754>] warn_slowpath_null+0x14/0x20
[<ffffffff81198692>] mark_buffer_dirty+0x82/0xa0
[<ffffffffa043b853>] ext2_sync_fs+0x43/0xb0 [ext2]
[<ffffffff81195ac3>] __sync_filesystem+0x53/0x90
[<ffffffff81195cfb>] sync_filesystem+0x4b/0x70
[<ffffffff8119f7ee>] fsync_bdev+0x2e/0x70
[<ffffffff8124455e>] invalidate_partition+0x2e/0x50
[<ffffffff811d6ccf>] del_gendisk+0x3f/0x150
[<ffffffff8132cb67>] ? put_device+0x17/0x20
[<ffffffffa013c93a>] sd_remove+0x5a/0xa0 [sd_mod]
[<ffffffff8133135f>] __device_release_driver+0x6f/0xe0
[<ffffffff813314cd>] device_release_driver+0x2d/0x40
[<ffffffff81330363>] bus_remove_device+0xa3/0x100
[<ffffffff8132df17>] device_del+0x127/0x1d0
[<ffffffff81351b15>] __scsi_remove_device+0xc5/0xd0
[<ffffffff8134decc>] scsi_forget_host+0x5c/0x80
[<ffffffff81345ed7>] scsi_remove_host+0x67/0x120
[<ffffffffa007e38b>] quiesce_and_remove_host+0x6b/0xc0 [usb_storage]
[<ffffffffa007e4c2>] usb_stor_disconnect+0x22/0x40 [usb_storage]
[<ffffffff8138ce5d>] usb_unbind_interface+0x6d/0x170
[<ffffffff8133135f>] __device_release_driver+0x6f/0xe0
[<ffffffff813314cd>] device_release_driver+0x2d/0x40
[<ffffffff81330363>] bus_remove_device+0xa3/0x100
[<ffffffff8132df17>] device_del+0x127/0x1d0
[<ffffffff8138913d>] usb_disable_device+0xbd/0x210
[<ffffffff81095a5e>] ? down+0x2e/0x50
[<ffffffff81381344>] usb_disconnect+0xe4/0x200
[<ffffffff813828c3>] hub_thread+0x6f3/0x17f0
[<ffffffff81060b91>] ? dequeue_entity+0x1a1/0x1e0
[<ffffffff81090a50>] ? autoremove_wake_function+0x0/0x40
[<ffffffff813821d0>] ? hub_thread+0x0/0x17f0
[<ffffffff810906e6>] kthread+0x96/0xa0
[<ffffffff810141ca>] child_rip+0xa/0x20
[<ffffffff81090650>] ? kthread+0x0/0xa0
[<ffffffff810141c0>] ? child_rip+0x0/0x20

Although, something is a little strange, since
uname -r says 2.6.32-54.el6.x86_64 and the trace above says 2.6.32-37.el6.x86_64
Comment 2 RHEL Product and Program Management 2010-08-09 16:18:39 EDT
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 3 RHEL Product and Program Management 2010-08-18 17:28:56 EDT
Thank you for your bug report. This issue was evaluated for inclusion
in the current release of Red Hat Enterprise Linux. Unfortunately, we
are unable to address this request in the current release. Because we
are in the final stage of Red Hat Enterprise Linux 6 development, only
significant, release-blocking issues involving serious regressions and
data corruption can be considered.

If you believe this issue meets the release blocking criteria as
defined and communicated to you by your Red Hat Support representative,
please ask your representative to file this issue as a blocker for the
current release. Otherwise, ask that it be evaluated for inclusion in
the next minor release of Red Hat Enterprise Linux.
Comment 4 Don Zickus 2010-11-09 16:38:57 EST
Eric,

Is this WARN_ON_ONCE harmful?  It seems like the usb drive disappeared with dirty buffers and the OS doesn't know what to do with it hence the warning?

Cheers,
Don
Comment 5 Eric Sandeen 2011-03-16 13:21:26 EDT
sorry for missing the question .  :(  I don't think it's particularly harmful to the system, though possibly not so great for the -filesystem-



This should be fixed upstream now, with 7bf0dc9b0ca9e9b6524b1f70e0898c7f11eb10be

in 2.6.33 ... and fixed for RHEL6 (on ext3) by bug #591466, open for RHEL6 (for ext2) in bug #679930

Ray, I'll probably dup this to that one, and you can retest once it's fixed?  If it turns out to be a different issue we can reopen this.

Thanks,
-Eric

*** This bug has been marked as a duplicate of bug 679930 ***

Note You need to log in before you can comment on or make changes to this bug.