From: H.S. on
H.S. wrote:
>
> I will report back how it goes as soon as I am able to do the experiments.
>


Well, good news. The patch seems to be worked as you designed.

Compiled the kernel with your patch, rebooted the machine and plugged in
the camcorder to the firewire port. This is what the log said:
May 31 11:06:47 red kernel: [ 924.228439] firewire_ohci: isochronous
cycle inconsistent
May 31 11:06:48 red kernel: [ 924.821383] firewire_core: created device
fw1: GUID 08004601024aca36, S100
May 31 11:06:48 red kernel: [ 924.821396] firewire_core: phy config:
card 0, new root=ffc1, gap_count=5
May 31 11:06:48 red kernel: [ 924.833768] firewire_core: IRM is not
1394a compliant, making local node (ffc0) root.
May 31 11:06:48 red kernel: [ 924.833777] firewire_core: phy config:
card 0, new root=ffc0, gap_count=5


And that is all it said ever after I captured a footage of some seconds.
I used the following command:
$> dvgrab -a -f raw -t video-

Then I switched off the camera, and still there were no messages in the log.

So, what is verdict?

Meanwhile, I will continue using this kernel.

Thanks.

--

Please reply to this list only. I read this list on its corresponding
newsgroup on gmane.org. Replies sent to my email address are just
filtered to a folder in my mailbox and get periodically deleted without
ever having been read.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H.S. on
On 02/06/10 02:26 PM, Stefan Richter wrote:
>
> I committed the patch to linux1394-2.6.git now, exposed it in the
> linux-next branch, and will send a pull request sometime next week.
>
> I marked the commit to be back-merged into the stable kernel branches
> (2.6.32.y and newer). Distributors will pick it up from there at their
> leisure, or earlier if they get a distro bug report that points them to
> the commit.
>
> Thanks for testing the patched kernel.

Great! I am glad I was able to help.

>
> I suppose either the local node became root node (node with highest node
> ID) and thus the camcorder stopped doing bus management things, or the
> camcorder chose the optimum gap count 5 for some reason and thus the
> Linux node saw no reason to do its bus management routine. If you are
> very curious, you can look at node IDs and gap counts and more with the
> FireWire inspection utility gscanbus.


Okay. Thanks again for the explanations.

Warm regards.

--

Please reply to this list only. I read this list on its corresponding
newsgroup on gmane.org. Replies sent to my email address are just
filtered to a folder in my mailbox and get periodically deleted without
ever having been read.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/