From: Jonathan W. <jw...@ph...> - 2007-11-05 01:04:42
|
Hi Justin > > It's there under "SelfID Info": > > > >> IRM Capable: No > : > > This is *really* interesting, because the 828/Traveler interfaces are > > definitely IRM capable and behave accordingly. I think I'll try to run > > gscanbus on my Traveler tonight and compare the results to make sure it's > > not gscanbus getting confused here. > > > > Could you run gscanbus again and this time report the properties associated > > with the firewire device in your PC? > > SelfID Info > : > IRM Capable: Yes That's even more interesting given what Francois just observed with his 828MkII and gscanbus. Why would it correctly identify the IRM capability in the host controller but not on a remote node? > Node Capabilities: 0x000083C0 I'll decode these from the 8pre at some point and see how they compare to the SelfID info. The SelfID info is what is used during bus negotiation but it is still interesting to see what the node capability flags are. > > Could you also try > > > > cat /sys/bus/ieee1394/devices/fw-host0/host_id/bus_options > > > > and sent the output to me? > > streiner@reverb ~ $ cat /sys/bus/ieee1394/devices/fw-host0/host_id/bus_options > IRMC(1) CMC(1) ISC(1) BMC(0) PMC(0) GEN(3) LSPD(2) MAX_REC(2048) MAX_ROM(2) > CYC_CLK_ACC(100) IRMC(1) is at least consistent with the gcanbus output for the host interface. > > If the 8pre is not IRM capable then some other node must take on the IRM > > responsibility. In this case it should be the PC interface since it's the > > only other thing on the bus. However, off-hand I'm not sure what the > > current state of the Linux kernel firewire IRM code is. > > According to gscanbus, it looks like the host side is taking IRM > responsibility. That is what I would expect to happen if the 8pre isn't advertising itself as IRMC. If this were happening then it's possible that a bug in the Linux firewire IRM code may be preventing correct IRM operation - I don't know the current state of that code. It also doesn't explain why things appear to work for Francois even though his interface also reports no IRMC in the SelfID block. Nor does it explain why gscanbus correctly identifies IRMC on some nodes and not on others. At this point my money would be on the card, especially given what Francois has seen on google. > >>> What firewire card are you using for these tests again? > >> > >> This is the built-in Firewire 400 port on my Dell Latitude D820 laptop. > >> lspci doesn't have much to say about it... > >> > >> 03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Unknown device 00f7 (rev 02) > > > > Hmm, O2 Micro Inc. I don't know anything about these cards. Does anyone > > else have experience or anedotes about this chipset? > > From what Francois said in his last post, not many good things have been > said about O2's firewire chipset. Anytime the comparison is made to VIA > motherboards, for audio work, that's never good :) So it seems, yes. > >>> I'm also at a loss to explain how the 8pre's iso output is turned off when > >>> the write to the iso control register is flagged as failing. > > > This is most interesting - the dumpiso output you sent appears to contain > > data from the MOTU. This means that iso streaming of the 8pre is not > > controlled in the same way as for other interfaces. Furthermore I can't > > work out how the MOTU knows when to stop streaming. Without those two lines > > in the code motutest will exit without writing anything to the interface so > > the interface has no way of knowing that there's nothing left listening to > > the iso broadcasts any more. > > > > Maybe the streaming occurs whenever the device is in "interface mode". > > Ok, let's test this idea, could you do the following. > > > > 1) Have a newly rebooted machine ready. > > Done. > > > 2) Run dumpiso to see if there's any traffic coming from the MOTU. Stop > > dumpiso once this has been determined. > > There doesn't appear to be anything coming from the 8pre. > > > 3) Run the modified motutest (the one without the 0x0b00 register writes). > > Done. > > > 4) Run dumpiso once motutest has exitted and see if any traffic is flowing > > from the MOTU now. > > > > I hope that there's no iso traffic at step 2 but there is some at step 4. > > This would indicate that streaming is enabled by the device going into > > "interface" mode. > > Your hunch appears to be correct. dumpiso is quiet before motutest runs, > but there is steady output after running and exiting the modified > motutest (the one with the 0x0b00 register writes commented out). Excellent - another mystery solved: the 8pre starts streaming when it drops into interface mode (which in turn seems to happen when a write is made to the sample control register) and keeps going until the interface exits interface mode. This brings up another question (which may have been covered before - I've had a busy few weeks): when this interface is running under windoze, does it move to interface mode immediately after you plug it in? > dumpiso outputs (bzip'd) are available here: > > http://www.cluebyfour.org/downloads/20071104/dumpiso-20071104-before-motutest.log.bz2 > http://www.cluebyfour.org/downloads/20071104/dumpiso-20071104-after-motutest.log.bz2 Got them - thanks. > I'm not entirely sure what the traffic is in the second dumpiso output - > but I'm curious. What are you using to convert the output into a human > readable format? "hexdump -C" and my knowledge of the MOTU packet format. In short, the iso packet's data size is encoded in network byte order in the most significant 16 bits of the first quadlet of the packet's header. For the 8pre this will be 0x0208 in the mode you're currently running in. Thus the start of each packet in dumpiso's output will be the bytes 0x08 0x02 as seen in hexdump output (remember it's in network byte order so the MSB will appear first in the file). A straight search for "08 02" will therefore find the start of each packet (and any data which happens to also include this sequence). Put another way, dumpiso's output contains MOTU data in the context of these tests if the "08 02" pattern is seen at the start of a packet (and a few other minor conditions are met). Note that the first 32 bytes of dumpiso's output are a dumpiso header. See dumpiso(5) manpage for details. Regards jonathan |