Messages in this thread | | | Date | Wed, 23 Apr 2003 16:24:53 -0400 | From | Ben Collins <> | Subject | Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ] |
| |
> Is this better or not than the -pre7 version ? Honestly I don't know, > there were problems with the old one too (however the old version > reacted to plug/unplug mount/umount events by freezing hard the > laptop, while the new one just oopses, so this is an improvement > from some point of view...)
This is the same oops I get except that for me I see it as a left over scsi device even after sbp2 is unloaded (unload sbp2 and check /proc/partitions). I haven't been able to figure out how to get the scsi subsystem to remove devices in this condition:
scsi_register_module(MODULE_SCSI_HA, &sbp2_template);
scsi_host = scsi_register(&sbp2_template, 0);
// (some devices get detected)
// removal of host scsi_unregister(scsi_host);
// Removal of sbp2 module to unregister template scsi_unregister_module(MODULE_SCSI_HA, &sbp2_template);
In actuality, doing scsi_unregister(scsi_host), in my eyes should also deallocate the devices associated with that scsi_host. That doesn't happen. It seems to me that the logic is that I should not call scsi_unregister(scsi_host), since it gets called for the scsi_unregister_module() of the template. However, that allows a scsi_host leak for situations where ieee1394 controllers are getting plugged/unplugged. It will continue to leak until sbp2 is unloaded.
I'm not sure if the leak is more optimal than the oops...maybe it is. I'll revisit this in the next week.
-- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |