Greg KH wrote: > On Fri, Nov 17, 2006 at 04:24:27PM +0100, Stefan Richter wrote: >> I wrote: >>> Either the FireWire host's device->klist_children was overwritten before >>> the call to device_for_each_child >> or *during* the run of device_for_each_child, which first successfully >> called nodemgr_remove_ne for node [0-00:1023] but then stumbled over the >> false node [20754571-38:0455]. >> >>> (perhaps nodemgr didn't hold a reference which it should have), or/and >>> all of this is an issue with the ongoing migration away from class_device. > > I don't have any firewire class_device migration patches in -mm right > now.
Yes, I looked through the driver core related patches in -mm but wasn't sure if there was a change to generic code which could affect ieee1394/nodemgr. > I do have one sitting here if you wish to play around with it, but it > needs some more infrastructure patches that I have not really tested all > that well yet. (Is this infrastructure something which other subsystems will require anyway? If not, maybe the ieee1394 subsystem's sysfs interface could be cut to size instead.) > Either way, I don't think this is caused by any new class_device > patches, but I'm very willing to be proven wrong :) Good, I just wanted to hear your opinion before drilling further down. Seems there is an older bug in nodemgr. But whatever it is, the reporter reproduced it _only_ in -mm, with either of 2.6.19-rc-mm's and 2.6.19-rc's ieee1394 code. Time for me to let -mm loose on my PC. Thanks, -- Stefan Richter -=====-=-==- =-== =--=- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
