From: Justin M. S. <str...@cl...> - 2007-11-05 00:40:00
|
On Mon, 5 Nov 2007, Jonathan Woithe wrote: >>> Without a sniffer it's difficult to prove that this is what is happening >>> because the cycle-start packets are async packets. However, it would be >>> helpful if you could fire up gscanbus, select the MOTU interface and see if >>> "IRM-capable" is mentioned anywhere in the device's capabilities. >> >> gscanbus output follows. I don't see any mention of IRM anywhere. > > It's there under "SelfID Info": > >> IRM Capable: No Reading too quickly and a lack of caffeine will do that to me sometimes :) > 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 ----------- Physical ID: 1 Link active: Yes Gap Count: 63 PHY Speed: S400 PHY Delay: <=144ns IRM Capable: Yes Power Class: None Port 0: Connected to child node Port 1: Not connected Init. reset: No CSR ROM Info ------------ GUID: 0x324FC000273A1161 Node Capabilities: 0x000083C0 Vendor ID: 0x00324FC0 Unit Spec ID: 0x00000000 Unit SW Version: 0x00000000 Model ID: 0x00000000 Nr. Textual Leafes: 1 Vendor: Unknown Textual Leafes: Linux - ohci1394 AV/C Subunits ------------- N/A > > 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) > 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. > All this aside, I wonder how the MOTU manages to put streaming data onto the > bus without an IRM present on the bus. Maybe it just "does it anyway". > >>> 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 :) >>> 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). 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 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? jms |