Re: ohci1394 oops bisected [was Re: 2.6.19-rc5-mm2 (Oops in class_device_remove_attrs during nodemgr_remove_host)]

[Greg KH <greg@kroah.com>]

On Sun, Nov 19, 2006 at 10:01:06PM +0100, Stefan Richter wrote:
> Andrew Morton wrote:
> > On Sun, 19 Nov 2006 18:13:45 +0100
> > Stefan Richter <stefanr@s5r6.in-berlin.de> 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.)

Yes, I can trigger this quite easily here now.

>  - 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.

I'll hold off on submitting the network change to mainline until I fix
this problem, so it might be a while...

thanks for narrowing it down for me.

greg k-h