lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C06A246.9030405@s5r6.in-berlin.de>
Date:	Wed, 02 Jun 2010 20:26:14 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	linux1394-devel@...ts.sourceforge.net
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] firewire: core: check for 1394a compliant IRM,	fix inaccessibility
 of Sony camcorder

H.S. wrote:
> H.S. wrote:
>> So, what is verdict?
> 
> Should have been "So, what is the verdict?"

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.

> Anyway, just wanted to give a little additional information, in case
> this is significant. While testing the camcorder on a different Debian
> machine running Unstable and 2.6.32-5-686-bigmem kernel, I did not face
> the face problem I reported earlier. On this new machine, I was able to
> connect the camera and grab a footage using dvgrab. The syslog had this
> in it:
> May 30 19:31:42 blue kernel: [ 5203.926694] firewire_core: skipped bus generations, destroying all nodes
> May 30 19:31:42 blue kernel: [ 5204.424019] firewire_core: rediscovered device fw0
> May 30 19:31:42 blue kernel: [ 5204.516343] firewire_core: created device fw1: GUID 08004601024aca36, S100
> May 30 19:31:42 blue kernel: [ 5204.516346] firewire_core: phy config: card 0, new root=ffc1, gap_count=5
> May 30 19:31:42 blue kernel: [ 5204.525209] firewire_core: skipped bus generations, destroying all nodes
> May 30 19:31:43 blue kernel: [ 5205.024019] firewire_core: rediscovered device fw0
> May 30 19:31:43 blue kernel: [ 5205.116912] firewire_core: rediscovered device fw1

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.
-- 
Stefan Richter
-=====-==-=- -==- ---=-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ