Andrew Morton wrote: > On Sun, 19 Nov 2006 18:13:45 +0100 > Stefan Richter <[EMAIL PROTECTED]> wrote: >> Looks very much like eth1394's sysfs interface is getting >> in the way. And since it is entirely handled by the ieee1394 core, it >> means ieee1394 needs the class_dev to dev treatment. I think it's OK if >> we just wait for Greg to finish his preliminary patch. Until then, >> CONFIG_IEEE1394_ETH1394=n should avoid the oops. (Or Andrew marks >> eth1394 broken or removes gregkh-driver-network-device.patch...) > > Do we know what's actually wrong, and what needs to be done about it?
I for one don't know what's needed precisely. But at the moment I actually don't want to spend any more time on this because: - It happens only if ohci1394 is unloaded while eth1394 is loaded. (That's not an unusual condition though.) - It happens only in -mm, and only because -mm contains the work-in- progress patches for class_device -> device transition. I expect it to go away automatically once Greg is done with the transition. It seems Greg is the one to do it :-), at least I'm not available right now to lend a hand. There are older ieee1394 bugs in mainline with bigger practical impact for me to work on. If there are still issues once ieee1394 was converted away from class_device, I'm OK with revisiting it. (Besides, if anybody wants to become eth1394 maintainer, please step up. MAINTAINERS currently lists eth1394 as in "Odd fixes" mode.) -- 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/
