On Thu, Mar 22, 2012 at 2:05 AM, 于爱华 <crystal_yu@xxxxxxxxx> wrote: > Sometimes, when I use rmmod to remove the module of pm8001, I will got problems as follows: > > WARNING: at fs/sysfs/inode.c:323 sysfs_hash_and_remove+0xa4/0xb0() > Hardware name: X7DB8 > sysfs: can not remove 'device', no directory > Modules linked in: raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx ses enclosure spcv(O-) libsas scsi_transport_sas ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables tun autofs4 sunrpc p4_clockmod freq_table speedstep_lib bridge stp llc ipv6 dm_mirror dm_region_hash dm_log virtio_net virtio virtio_ring kvm_intel kvm microcode pcspkr i2c_i801 sg iTCO_wdt iTCO_vendor_support i5000_edac edac_core i5k_amb ioatdma dca e1000e shpchp ext4 mbcache jbd2 floppy sd_mod crc_t10dif pata_acpi ata_generic ata_piix radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core dm_mod [last unloaded: mperf] > Pid: 2835, comm: kworker/u:0 Tainted: G W O 3.3.0-rc3+ #2 > Call Trace: > [<ffffffff8104c38f>] warn_slowpath_common+0x7f/0xc0 > [<ffffffff8104c486>] warn_slowpath_fmt+0x46/0x50 > [<ffffffff811d5e04>] sysfs_hash_and_remove+0xa4/0xb0 > [<ffffffff811d8ad6>] sysfs_remove_link+0x26/0x30 > [<ffffffffa00192c6>] enclosure_remove_links+0x56/0x80 [enclosure] > [<ffffffff811d805b>] ? remove_dir+0x3b/0x50 > [<ffffffffa001940f>] enclosure_component_release+0x2f/0x50 [enclosure] > [<ffffffff8132c827>] device_release+0x27/0xa0 Hmm, why are we removing links in the release routine, shouldn't they have been removed before the device was deleted... like what happens in enclosure_remove_device()? This looks like enclosure_remove_links() should be moved from enclosure_component_release() to enclosure_unregister(). Thoughts? -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
