Something broke :-( Re: fwcontrol update

[Dieter]

> > I notice that it doesn't print every generation.
> > I notice that the node_id changes.
>
>
> This alarms me quite a bit.  I didn't think there was anyway for the 
> generation to change
> without the log message being spit out.  Interesting.

It also skips on dmesg, so it isn't a console problem:

fwohci1: node_id=0xc000ffc0, gen=86, CYCLEMASTER mode
firewire1: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
firewire1: bus manager 0 (me)
got BUSRST packet!?
got BUSRST packet!?
got BUSRST packet!?
fwohci1: BUS reset
fwohci1: node_id=0xc000ffc1, gen=108, CYCLEMASTER mode
firewire1: 2 nodes, maxhop <= 1, cable IRM = 1 (me)
firewire1: bus manager 0 
fwohci1: BUS reset
fwohci1: node_id=0xc000ffc0, gen=112, CYCLEMASTER mode
fwohci1: invalid SID len = 0	<-----------------------<<< didn't notice this line before
fwohci1: BUS reset						only occurs twice in dmesg
fwohci1: node_id=0xc000ffc1, gen=130, CYCLEMASTER mode
firewire1: 2 nodes, maxhop <= 1, cable IRM = 1 (me)
firewire1: bus manager 1 (me)
fwohci1: BUS reset
fwohci1: node_id=0xc000ffc0, gen=135, CYCLEMASTER mode
firewire1: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
firewire1: bus manager 0 (me)
got BUSRST packet!?
got BUSRST packet!?
fwohci1: BUS reset
fwohci1: node_id=0xc000ffc1, gen=154, CYCLEMASTER mode

Does "got BUSRST packet!?" mean that the camera is sending out
bus reset commands?  That doesn't seem right.  BTW, shouldn't that
line have a prefix telling where it comes from (e.g. fwohci1:
or firewire1:) ?

BTW there is just the FreeBSD box and the camera, no other nodes
on the firewire bus.

> I have been suspicious of a race condition for some time in the firewire 
> stack, I see it across multiple
> devices(sbp, sbp_targ) and now fwcontrol is acting weird.  Very interesting.

> Yes.  Try the attached patch.  Let me know.

I don't see a patch.

Note that fwcontrol is not running when the spew happens.
I press play on the camcorder, and the spewing starts.
I press stop and the spewing stops.

My only theories are that fwcontrol set something that
survives a reboot, or that the fw controller chip isn't
getting completely reset and properly initialized.  I'm
leaning towards the chip being the more likely explaination.