Bug in new version of subsystem

[Manfred W. <e95...@st...>]

Hello!

After updating to the new (cvs-)version of the subsystem (before I used
ieee1394-2.2.14-20000206.gz) I observed the following very interesting
phenomenon:

If my computer was attached to a 1394-network during bootup (ie. when
the driver was loaded) and I run testlibraw (from the current libraw1394
0.6 of course), it tells me that:

<output of testlibraw>
successfully got handle
current generation number: 1
1 card(s) found
  nodes on bus:  0, card name: pcilynx
using first card found: 0 nodes on bus, local ID is 3

doing transactions with custom tag handler

using standard tag handler and synchronous calls

testing FCP monitoring on local node
got fcp command from node 3 of 8 bytes: 01 23 45 67 89 ab cd ef
got fcp response from node 3 of 8 bytes: 01 23 45 67 89 ab cd ef

polling for leftover messages
</output of testlibraw>

Obviously no node is found. But there must be at least one node (the
local node).
gscanbus crashes with a core dump (which probably is a bug of gscanbus
which might not be able to handle 0 nodes correctly).

Then I pulled the 1394 plug and afterwards it seemed to be ok, one node
was detected (the same happens if the plug was already pulled during
bootup):

<output of testlibraw>
successfully got handle
current generation number: 2
1 card(s) found
  nodes on bus:  1, card name: pcilynx
using first card found: 1 nodes on bus, local ID is 0

doing transactions with custom tag handler
trying to send read request to node 0... completed with 0x00100000,
value
0xfe060000

using standard tag handler and synchronous calls
trying to read from node 0... completed with 0x00100000, value
0x77050000

testing FCP monitoring on local node
got fcp command from node 0 of 8 bytes: 01 23 45 67 89 ab cd ef
got fcp response from node 0 of 8 bytes: 01 23 45 67 89 ab cd ef

polling for leftover messages
</output of testlibraw>

gscanbus does not core dump any more, but it says that it cannot read
the topology map (this is probably because it is not yet adopted to the
changed endianess policy).

Afterwards I again plugged in the 1394-cable, and now the network is
detected:

<output of testlibraw>
successfully got handle
current generation number: 3
1 card(s) found
  nodes on bus:  9, card name: pcilynx
using first card found: 9 nodes on bus, local ID is 3

doing transactions with custom tag handler
trying to send read request to node 0... completed with 0x00020000,
value
0x799b
96c6
trying to send read request to node 1... failed with error -1102
trying to send read request to node 2... completed with 0x00020000,
value
0xa632
a2c6
trying to send read request to node 3... completed with 0x00100000,
value
0x7205
0000
trying to send read request to node 4... completed with 0x00020000,
value
0x3e23
bfc6
trying to send read request to node 5... failed with error -1102
trying to send read request to node 6... completed with 0x00020000,
value
0xe4b3
76c6
trying to send read request to node 7... failed with error -1102
trying to send read request to node 8... failed with error -1102

using standard tag handler and synchronous calls
trying to read from node 0... completed with 0x00020000, value
0x11b8acc6
trying to read from node 1... failed with error -1102
trying to read from node 2... completed with 0x00020000, value
0xf31ab8c6
trying to read from node 3... completed with 0x00100000, value
0xb00a0000
trying to read from node 4... completed with 0x00020000, value
0x82f4d4c6
trying to read from node 5... failed with error -1102
trying to read from node 6... completed with 0x00020000, value
0xd1828cc6
trying to read from node 7... failed with error -1102
trying to read from node 8... failed with error -1102

testing FCP monitoring on local node
got fcp command from node 3 of 8 bytes: 01 23 45 67 89 ab cd ef
got fcp response from node 3 of 8 bytes: 01 23 45 67 89 ab cd ef

polling for leftover messages
</output of testlibraw>

It took me quite a lot of time to find out, that in order to work with
the new driver, I have to pull the plug and then to re-plug-in. I hope,
you will find the bug.

Manfred Weihs

PS: I can report another bug which I observed yesterday before updating,
so it is a bug of the version from feb 6th, and I do not know if it
still exists in the current version.
If I plugged in the cabel, which a 1394-network hang on, and the
X-server (Xfree86 3.6, kde 1.1.2) was running (and visible), then
sometimes my pc hang up (completely, I was not even able to ping it).
But it did not happen always, so I could not reproduce it. But it never
happened when a text console was active, and booting while attached to
the 1394-network also worked, it only hang up, when I plugged in.