linux1394-user

Re: VT6306/7/8 shows up 33 times in lspci but have two ports

[Stefan R. <st...@s5...>]

On Jul 18 Alan Evans wrote to linux1394-user:
> I have never paid much attention to firewire support but now I am
> building a media player and plan to scrape video via firewire so I
> have to pay attention!
> 
> Anyway, my motherboard has 2 onboard firewire ports (one on ATX rear
> panel and 1 header which is unconnected) but lspci shows the device 33
> times!  What gives?

lspci should show only one VT6307 device.  The two physical ports are both
attached to a single link layer controller device i.e. FireWire-to-PCI
bridge device.

I have never heard of such a problem before.  It is not a FireWire problem
but a PCI problem.  Hence I Cc'd linux-pci.

VT6307 is a PCI device and is surely located behind a PCIe-to-PCI bridge.
Perhaps that bridge doesn't work right.

Alan, could you please reply-to-all with the output of "dmesg" attached,
beginning at the boot of the system?

Maybe a BIOS update can fix it?

> Secondly I am seeing a bunch of "Failed to reset ohci card" messages
> that coincide with the extra devices.
> 
> ...snip...
> [   37.619910] firewire_ohci 0000:04:12.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> [   38.618540] firewire_ohci: Failed to reset ohci card.
> [   38.618607] firewire_ohci 0000:04:12.0: PCI INT A disabled
> [   38.618615] firewire_ohci: probe of 0000:04:12.0 failed with error -16
> ...snip...

Well, if the kernel driver core binds firewire-ohci to devices that don't
actually exist, there are bound to be initialization failures.

> lspci
> ...snip...
> 03:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0)
> 04:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0)
> 04:01.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0)
> 04:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0)
> ...omitted for brevity...
> 04:1e.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0)
> 04:1f.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0)
> ...snip...
> 
> Any thoughts?
> 
> Regards,
> -Alan

I suppose the one VT6307 at bus 03 is for real, and the 32 ones on bus 04
are ghosts.
-- 
Stefan Richter
-=====-==-== -=== =--=-
http://arcgraph.de/sr/

VT6306/7/8 shows up 33 times in lspci but have two ports

[Alan E. <ala...@gm...>]

I have never paid much attention to firewire support but now I am
building a media player and plan to scrape video via firewire so I
have to pay attention!

Anyway, my motherboard has 2 onboard firewire ports (one on ATX rear
panel and 1 header which is unconnected) but lspci shows the device 33
times!  What gives?

Secondly I am seeing a bunch of "Failed to reset ohci card" messages
that coincide with the extra devices.

...snip...
[   37.619910] firewire_ohci 0000:04:12.0: PCI INT A -> GSI 17 (level,
low) -> IRQ 17
[   38.618540] firewire_ohci: Failed to reset ohci card.
[   38.618607] firewire_ohci 0000:04:12.0: PCI INT A disabled
[   38.618615] firewire_ohci: probe of 0000:04:12.0 failed with error -16
...snip...

lspci
...snip...
03:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire
II(M)] IEEE 1394 OHCI Controller (rev c0)
04:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire
II(M)] IEEE 1394 OHCI Controller (rev c0)
04:01.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire
II(M)] IEEE 1394 OHCI Controller (rev c0)
04:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire
II(M)] IEEE 1394 OHCI Controller (rev c0)
...omitted for brevity...
04:1e.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire
II(M)] IEEE 1394 OHCI Controller (rev c0)
04:1f.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire
II(M)] IEEE 1394 OHCI Controller (rev c0)
...snip...

Any thoughts?

Regards,
-Alan

Changes to the FireWire kernel drivers in Linux 3.0

[Stefan R. <st...@s5...>]

Hi all,

Linux 3.0-rc7 has been released on Monday.  Among the following
more visible changes to the IEEE 1394 kernel drivers, it contains a few
fixes and some optimizations regarding CPU utilization.

firewire-ohci:
  - Probing of the FireWire part on Pinnacle MovieBoard is disabled for
    now because it used to lock up the kernel.  Perhaps we can come up
    with a proper fix longer term, perhaps not.

firewire-sbp2:
  - Management of storage devices (connect, reconnect, disconnect) is now
    performed in parallel if there are two or more devices present.

snd-isight:
  - New ALSA driver for the microphones in Apple iSight FireWire webcams.
    It exposes front and rear microphone as a sound card with two PCM
    capture channels.  This supersedes an older out-of-the-mainline driver
    with the same function, called lisight, which depended on the removed
    ieee1394 driver stack.
-- 
Stefan Richter
-=====-==-== -=== -==-=
http://arcgraph.de/sr/

Re: pciehp udev remove, 12 seconds to settle

[Stefan R. <st...@s5...>]

Yesterday I put a PCIe-to-ExpressCard slot adapter into my PC and am using
it with a XIO2200 based ExpressCard now.  However, I haven't figured out
yet how to make pciehp do anything.  Tried a few pciehp module parameters
but never got it to recognize card insertion or removal.  So for now I'm
using that card like a fixed PCIe card, provided that it was present at
boot.

At one time I got at least the following at card insertion (pciehp
present but not giving a rat's ass):

Jul 10 13:24:01 stein kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Jul 10 13:24:01 stein kernel: pciehp: PCI Express Hot Plug Controller Driver version: 0.4
Jul 10 13:24:16 stein kernel: irq 9: nobody cared (try booting with the "irqpoll" option)
Jul 10 13:24:16 stein kernel: Pid: 0, comm: kworker/0:1 Not tainted 3.0.0-rc6 #14
Jul 10 13:24:16 stein kernel: Call Trace:
Jul 10 13:24:16 stein kernel: <IRQ>  [<ffffffff8106cfd0>] __report_bad_irq+0x35/0xc1
Jul 10 13:24:16 stein kernel: [<ffffffff8106d1b1>] note_interrupt+0x155/0x1ce
Jul 10 13:24:16 stein kernel: [<ffffffff8106b7bb>] handle_irq_event_percpu+0x107/0x124
Jul 10 13:24:16 stein kernel: [<ffffffff8106b814>] handle_irq_event+0x3c/0x5c
Jul 10 13:24:16 stein kernel: [<ffffffff8134f7d9>] ? _raw_spin_lock+0x3e/0x45
Jul 10 13:24:16 stein kernel: [<ffffffff8106d7f2>] ? handle_fasteoi_irq+0x19/0xa2
Jul 10 13:24:16 stein kernel: [<ffffffff8106d855>] handle_fasteoi_irq+0x7c/0xa2
Jul 10 13:24:16 stein kernel: [<ffffffff810037c3>] handle_irq+0x1f/0x28
Jul 10 13:24:16 stein kernel: [<ffffffff81056c1a>] ? tick_broadcast_oneshot_control+0x5e/0x109
Jul 10 13:24:16 stein kernel: [<ffffffff810030a7>] do_IRQ+0x48/0xae
Jul 10 13:24:16 stein kernel: [<ffffffff813502d3>] common_interrupt+0x13/0x13
Jul 10 13:24:16 stein kernel: <EOI>  [<ffffffff81350384>] ? retint_restore_args+0xe/0xe
Jul 10 13:24:16 stein kernel: [<ffffffff81056c1a>] ? tick_broadcast_oneshot_control+0x5e/0x109
Jul 10 13:24:16 stein kernel: [<ffffffff81008a90>] ? default_idle+0x33/0x57
Jul 10 13:24:16 stein kernel: [<ffffffff81008a8e>] ? default_idle+0x31/0x57
Jul 10 13:24:16 stein kernel: [<ffffffff81008bfc>] amd_e400_idle+0xca/0xf1
Jul 10 13:24:16 stein kernel: [<ffffffff81001464>] cpu_idle+0x5c/0xa7
Jul 10 13:24:16 stein kernel: [<ffffffff813495a7>] start_secondary+0x1ad/0x1b2
Jul 10 13:24:16 stein kernel: handlers:
Jul 10 13:24:16 stein kernel: [<ffffffff8116c8d0>] acpi_irq
Jul 10 13:24:16 stein kernel: Disabling IRQ #9

Haven't tried booting with irqpoll option yet.

From a fresh boot with card inserted and not yet removed:
$ grep " 9:" /proc/interrupts
  9:          0          0          0          0   IO-APIC-fasteoi   acpi

# cd /sys/bus/pci_express/devices/
# ls ../drivers/pciehp/
bind  uevent  unbind
# for x in *; do echo $x; echo $x > ../drivers/pciehp/bind; done
0000:00:02.0:pcie08
-su: echo: write error: No such device
0000:00:04.0:pcie08
-su: echo: write error: No such device
0000:00:05.0:pcie08
-su: echo: write error: No such device
0000:00:06.0:pcie08
-su: echo: write error: No such device
0000:02:00.0:pcie18
-su: echo: write error: No such device
0000:03:01.0:pcie28
-su: echo: write error: No such device
0000:03:02.0:pcie28
-su: echo: write error: No such device
0000:03:03.0:pcie28
-su: echo: write error: No such device
0000:03:04.0:pcie28

This is with any of the three types of pciehp_detect_mode and without or
with pciehp_force=1.  None of the messages in pciehp_core.c::pciehp_probe
are ever logged.  Its' just always only
Jul 10 14:15:41 stein kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Jul 10 14:15:41 stein kernel: pciehp: PCI Express Hot Plug Controller Driver version: 0.4

$ lspci -tv
-[0000:00]-+-00.0  Advanced Micro Devices [AMD] RS780 Host Bridge
           +-01.0-[01]--+-05.0  ATI Technologies Inc Radeon HD 3200 Graphics
           |            \-05.1  ATI Technologies Inc RS780 Azalia controller
           +-02.0-[02-07]----00.0-[03-07]--+-01.0-[04]----00.0  Agere Systems FW643 PCI Express1394b Controller (PHY/Link)
           |                               +-02.0-[05]----00.0  Agere Systems FW643 PCI Express1394b Controller (PHY/Link)
           |                               +-03.0-[06]--
           |                               \-04.0-[07]--
           +-04.0-[08-09]----00.0-[09]----00.0  Texas Instruments XIO2200(A) IEEE-1394a-2000 Controller (PHY/Link)
           +-05.0-[0a]----00.0  JMicron Technology Corp. IEEE 1394 Host Controller
           +-06.0-[0b]----00.0  Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller
           +-11.0  ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode]
           +-12.0  ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
           +-12.1  ATI Technologies Inc SB700 USB OHCI1 Controller
           +-12.2  ATI Technologies Inc SB700/SB800 USB EHCI Controller
           +-13.0  ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
           +-13.1  ATI Technologies Inc SB700 USB OHCI1 Controller
           +-13.2  ATI Technologies Inc SB700/SB800 USB EHCI Controller
           +-14.0  ATI Technologies Inc SBx00 SMBus Controller
           +-14.1  ATI Technologies Inc SB700/SB800 IDE Controller
           +-14.2  ATI Technologies Inc SBx00 Azalia (Intel HDA)
           +-14.3  ATI Technologies Inc SB700/SB800 LPC host controller
           +-14.4-[0c-10]--+-06.0  Ricoh Co Ltd RL5c475
           |               +-07.0  Pinnacle Systems Inc. AV/DV Studio Capture Card
           |               \-07.1  Pinnacle Systems Inc. Device 0015
           +-14.5  ATI Technologies Inc SB700/SB800 USB OHCI2 Controller
           +-18.0  Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration
           +-18.1  Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map
           +-18.2  Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller
           +-18.3  Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control
           \-18.4  Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control

acpiphp on the other hand does not seem to be applicable to my setup; it
refuses to load with -ENODEV.
-- 
Stefan Richter
-=====-==-== -=== -=-=-
http://arcgraph.de/sr/

Re: mythtv firewire_tester

[Stefan R. <st...@s5...>]

On Jul 03 Carl Karsten wrote:
> On Sun, Jul 3, 2011 at 12:32 PM, Stefan Richter
> <st...@s5...> wrote:
> > Indeed, this tests IEC 61883-1 connection management with an MPEG2-TS
> > streaming capable device, e.g. TV set top box or H-DV camcorder.
> 
> camcorder sounds useful once I get the rest of the stack in order.

I guess it can be easily modified to test DV reception too, if you prefer
a cheap DV camcorder over an expensive HDV camcorder as a test dongle. :-)
-- 
Stefan Richter
-=====-==-== -=== ---==
http://arcgraph.de/sr/

Re: mythtv firewire_tester

[Carl K. <ca...@pe...>]

On Sun, Jul 3, 2011 at 12:32 PM, Stefan Richter
<st...@s5...> wrote:
> On Jul 03 Carl Karsten wrote:
>> http://www.mythtv.org/wiki/Firewire_tester
>>
>> How useful would that be for testing controllers?   My guess is it
>> isn't appropriate;  looks like it depends on a set top device that I
>> don't have.
>
> Indeed, this tests IEC 61883-1 connection management with an MPEG2-TS
> streaming capable device, e.g. TV set top box or H-DV camcorder.


camcorder sounds useful once I get the rest of the stack in order.


-- 
Carl K

Re: pciehp udev remove, 12 seconds to settle

[Carl K. <ca...@pe...>]

On Sun, Jul 3, 2011 at 12:28 PM, Stefan Richter
<st...@s5...> wrote:
> On Jul 03 Carl Karsten wrote:
>> The only thing I am doing here is booting the box, inserting the card,
>> waiting a few seconds for all events to fire, removing the card.  No
>> -net or testing.
>
> Then something in firewire-core is likely to spend much of the latter 10
> seconds doing something useless.  Though at the moment I don't see how it
> would do so; all of the subdevice tear-down seems to be either immediate
> or at worst with much smaller delays than those 10 s (from looking at the
> code, and from what I can tell with my CardBus cards).
>
> The first circa 2 seconds are spent before the firewire subsystem is
> entered, hence outside my area of knowledge (and also not being observed
> with my outmoded CardBus system here).
>
>> I'll be happy to test patches.
>>
>> Any chance you can package the patched kernel for ubuntu oneiric?   I
>> have built kernels in the past, but that was back in the 90's running
>> slackware.
>
> Well, neither the prospect of me going into the .deb building business nor
> of you getting yourself an unbootable system sounds convenient for the
> short term.  Let's defer it for an occasion at which something more
> substantial than a 0.5 ms shutdown speedup is to be tested.

I have no problem borking my box - I pxe boot, get a menu, select
"install oneiric" (or maveric, natty and a few others)  hit enter and
wander off.  come back in 30 min and I have a fresh install.

I'll give this a go

https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel

-- 
Carl K

Re: mythtv firewire_tester

[Stefan R. <st...@s5...>]

On Jul 03 Carl Karsten wrote:
> http://www.mythtv.org/wiki/Firewire_tester
> 
> How useful would that be for testing controllers?   My guess is it
> isn't appropriate;  looks like it depends on a set top device that I
> don't have.

Indeed, this tests IEC 61883-1 connection management with an MPEG2-TS
streaming capable device, e.g. TV set top box or H-DV camcorder.
-- 
Stefan Richter
-=====-==-== -=== ---==
http://arcgraph.de/sr/

Re: pciehp udev remove, 12 seconds to settle

[Stefan R. <st...@s5...>]

On Jul 03 Carl Karsten wrote:
> The only thing I am doing here is booting the box, inserting the card,
> waiting a few seconds for all events to fire, removing the card.  No
> -net or testing.

Then something in firewire-core is likely to spend much of the latter 10
seconds doing something useless.  Though at the moment I don't see how it
would do so; all of the subdevice tear-down seems to be either immediate
or at worst with much smaller delays than those 10 s (from looking at the
code, and from what I can tell with my CardBus cards).

The first circa 2 seconds are spent before the firewire subsystem is
entered, hence outside my area of knowledge (and also not being observed
with my outmoded CardBus system here).

> I'll be happy to test patches.
> 
> Any chance you can package the patched kernel for ubuntu oneiric?   I
> have built kernels in the past, but that was back in the 90's running
> slackware.

Well, neither the prospect of me going into the .deb building business nor
of you getting yourself an unbootable system sounds convenient for the
short term.  Let's defer it for an occasion at which something more
substantial than a 0.5 ms shutdown speedup is to be tested.
-- 
Stefan Richter
-=====-==-== -=== ---==
http://arcgraph.de/sr/

mythtv firewire_tester

[Carl K. <ca...@pe...>]

http://www.mythtv.org/wiki/Firewire_tester

How useful would that be for testing controllers?   My guess is it
isn't appropriate;  looks like it depends on a set top device that I
don't have.


-- 
Carl K

Re: pciehp udev remove, 12 seconds to settle

[Carl K. <ca...@pe...>]

On Sun, Jul 3, 2011 at 9:59 AM, Stefan Richter
<st...@s5...> wrote:
> On Jul 02 Carl Karsten wrote:
>> when I remove a firewire card from the EC slot, syslog shows:
>>
>> [22225.626360] pciehp 0000:00:1c.2:pcie04: Card not present on Slot(2)
>> [22227.630061] firewire_ohci: failed to write phy reg
>> [22237.690127] firewire_ohci 0000:04:00.0: PCI INT A disabled
>> [22237.690137] firewire_ohci: Removed fw-ohci device.
>>
>> udev events fire at 22227 and 22237.  I am wondering why nothing fires
>> at the first one.
>
> I suppose the uevent at 22227 is from the pci subsystem, and at 22237 from
> the firewire subsystem.  Or is it vice versa?
>
> Uevents aside; I don't know what the first circa 2 seconds since
> 22225.626360 are spent with.
>
> 22227.630061 minus 100 ms is the point at which the pci subsystem calls
> firewire-ohci's removal routine pci_remove(), which in turn calls into
> firewire-core's card shutdown routine fw_core_remove_card().
> This one first spends the mentioned 100 ms in an attempt to switch off the
> "link active" bit of the controller that is to be shut down.  I have a
> patch which gets rid of this useless attempt in case of ejected CardBus
> cards:  http://marc.info/?l=linux1394-devel&m=130876954807280
> Supposedly, this patch also covers ejected ExpressCard cards.  If you are
> inclined to, you could apply this patch and see whether it removes the
> final "failed to write phy reg" message also with ExpressCard cards that
> are being ejected.
>
> Next, the bulk of the time between "failed to write phy reg" and
> "0000:04:00.0: PCI INT A disabled" is spent by firewire-core waiting for
> all places at higher levels of the firewire subsystem to drop all
> references to the card.  As far as I can tell, firewire-core itself is
> doing so rather quickly.  Other drivers like firewire-sbp2 etc. may take
> considerably more time because they need to interact with other higher
> levels.  But you don't have such other drivers in the picture --- except
> firewire-net perhaps if that one is still part of your testing regime.
>
> More notably, userspace users of firewire devices via the
> linux/firewire-cdev.h interface need to close their device files too
> before firewire-core's fw_core_remove_card() proceeds.
>
> This most time consuming aspect of fw_core_remove_card() can and should be
> modified to let card shutdown go on even while there are still references
> to the card held.  Basically, the fw_card structure deallocation needs to
> be moved from firewire-ohci into firewire-core.
>
> As the last time-consuming step after fw_core_remove_card() returned to
> firewire-ohci's pci_remove(), firewire-ohci attempts to perform a software
> reset of the controller.  This again needlessly takes 500 ms if the card
> was already removed.  I shall send a patch shortly which skips this delay,
> similar to the aforementioned patch.


The only thing I am doing here is booting the box, inserting the card,
waiting a few seconds for all events to fire, removing the card.  No
-net or testing.

I'll be happy to test patches.

Any chance you can package the patched kernel for ubuntu oneiric?   I
have built kernels in the past, but that was back in the 90's running
slackware.  I tried a year ago or so, may have been successful, but
remember a bit of floundering.   I would rather our time be spent
debugging firewire things than debugging my kernel building.   But if
it isn't easy for you, I'll be happy to give it a go.

-- 
Carl K

Re: pciehp udev remove, 12 seconds to settle

[Stefan R. <st...@s5...>]

On Jul 02 Carl Karsten wrote:
> when I remove a firewire card from the EC slot, syslog shows:
> 
> [22225.626360] pciehp 0000:00:1c.2:pcie04: Card not present on Slot(2)
> [22227.630061] firewire_ohci: failed to write phy reg
> [22237.690127] firewire_ohci 0000:04:00.0: PCI INT A disabled
> [22237.690137] firewire_ohci: Removed fw-ohci device.
> 
> udev events fire at 22227 and 22237.  I am wondering why nothing fires
> at the first one.

I suppose the uevent at 22227 is from the pci subsystem, and at 22237 from
the firewire subsystem.  Or is it vice versa?

Uevents aside; I don't know what the first circa 2 seconds since
22225.626360 are spent with.

22227.630061 minus 100 ms is the point at which the pci subsystem calls
firewire-ohci's removal routine pci_remove(), which in turn calls into
firewire-core's card shutdown routine fw_core_remove_card().
This one first spends the mentioned 100 ms in an attempt to switch off the
"link active" bit of the controller that is to be shut down.  I have a
patch which gets rid of this useless attempt in case of ejected CardBus
cards:  http://marc.info/?l=linux1394-devel&m=130876954807280
Supposedly, this patch also covers ejected ExpressCard cards.  If you are
inclined to, you could apply this patch and see whether it removes the
final "failed to write phy reg" message also with ExpressCard cards that
are being ejected.

Next, the bulk of the time between "failed to write phy reg" and
"0000:04:00.0: PCI INT A disabled" is spent by firewire-core waiting for
all places at higher levels of the firewire subsystem to drop all
references to the card.  As far as I can tell, firewire-core itself is
doing so rather quickly.  Other drivers like firewire-sbp2 etc. may take
considerably more time because they need to interact with other higher
levels.  But you don't have such other drivers in the picture --- except
firewire-net perhaps if that one is still part of your testing regime.

More notably, userspace users of firewire devices via the
linux/firewire-cdev.h interface need to close their device files too
before firewire-core's fw_core_remove_card() proceeds.

This most time consuming aspect of fw_core_remove_card() can and should be
modified to let card shutdown go on even while there are still references
to the card held.  Basically, the fw_card structure deallocation needs to
be moved from firewire-ohci into firewire-core.

As the last time-consuming step after fw_core_remove_card() returned to
firewire-ohci's pci_remove(), firewire-ohci attempts to perform a software
reset of the controller.  This again needlessly takes 500 ms if the card
was already removed.  I shall send a patch shortly which skips this delay,
similar to the aforementioned patch.
-- 
Stefan Richter
-=====-==-== -=== ---==
http://arcgraph.de/sr/

pciehp udev remove, 12 seconds to settle

[Carl K. <ca...@pe...>]

I got no replies on pci or hotplug.  hoping someone here can stupe to
this level :)


Laptop: Hewlett-Packard F.0C HP EliteBook 8530w (the one where pciehp
works, no need for acpiphp)

when I remove a firewire card from the EC slot, syslog shows:

[22225.626360] pciehp 0000:00:1c.2:pcie04: Card not present on Slot(2)
[22227.630061] firewire_ohci: failed to write phy reg
[22237.690127] firewire_ohci 0000:04:00.0: PCI INT A disabled
[22237.690137] firewire_ohci: Removed fw-ohci device.

udev events fire at 22227 and 22237.  I am wondering why nothing fires
at the first one.

Given the last event takes 12 seconds, and I am not sure what happens
if I insert a card during that time, I want to hear beeps when I
should not insert a card, so I would like a udev rule with

 RUN="/usr/bin/screen -S pci_beep -d -m  /bin/bash -c 'for x in
{1..12}; do  /usr/bin/sox -n -d synth .05 sin 700 gain -16; /bin/sleep
.9; done'"

I would do it on the firewire remove event, but that also fires when
firewire devices are removed (like camera) and I am not smart enough
to keep track of when I should ignore the warning beeps.

--
Carl K



--
Carl K



-- 
Carl K

1/2 connected weirdness

[Carl K. <ca...@pe...>]

testing a laptop/EC card loop with
https://gitorious.org/cfk_misc/fwdiag/blobs/master/fw_test.sh
 which is conceptually

ls /dev/fw*
async-test receive A & async-test send B
ls /dev/fw*
async-test receive B & async-test send A

Ran that a few times for 10 min or so.  Then ran it over night.

first direction for over 5 hours with no errors.
ls /dev/fw* showed all 4 nodes
async-test send A failed due to missing device.
Which is correct, but only 1 of the 2 fw nodes evaporated:

juser@xps:~$ ls /dev/fw*
/dev/fw0  /dev/fw1  /dev/fw2

Which shouldn't be possible.

Plus running async-test shouldn't cause nodes to evaporate.

I'll leave the box as is in case someone wants me to look at it in its
current state.

02:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
0c:00.0 FireWire (IEEE 1394): Agere Systems FW643 PCI Express1394b
Controller (PHY/Link) (rev 06)

juser@xps:~$ ls /dev/fw*
/dev/fw0  /dev/fw1  /dev/fw2


[ 4096.269555] composite sync not supported
[ 4096.390717] composite sync not supported
[ 4096.575731] composite sync not supported
[ 4096.713120] composite sync not supported
[ 4096.866169] composite sync not supported
[ 4107.614426] composite sync not supported
[ 4119.295491] composite sync not supported
[ 4274.969796] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 4274.970375] acpiphp: Slot [1] registered
[ 4289.380358] pci 0000:0c:00.0: [11c1:5901] type 0 class 0x000c00
[ 4289.380406] pci 0000:0c:00.0: reg 10: [mem 0x00000000-0x00000fff 64bit]
[ 4289.380543] pci 0000:0c:00.0: supports D1 D2
[ 4289.380550] pci 0000:0c:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 4289.380561] pci 0000:0c:00.0: PME# disabled
[ 4289.380874] pci 0000:0c:00.0: BAR 0: assigned [mem
0xdfc00000-0xdfc00fff 64bit]
[ 4289.380894] pci 0000:0c:00.0: BAR 0: set to [mem
0xdfc00000-0xdfc00fff 64bit] (PCI address [0xdfc00000-0xdfc00fff])
[ 4289.380941] pci 0000:0c:00.0: no hotplug settings from platform
[ 4289.381129] firewire_ohci 0000:0c:00.0: enabling device (0000 -> 0002)
[ 4289.381146] firewire_ohci 0000:0c:00.0: PCI INT A -> GSI 17 (level,
low) -> IRQ 17
[ 4289.381161] firewire_ohci 0000:0c:00.0: setting latency timer to 64
[ 4289.436151] firewire_ohci: Added fw-ohci device 0000:0c:00.0, OHCI
v1.10, 8 IR + 8 IT contexts, quirks 0x10
[ 4289.936430] firewire_core: created device fw1: GUID 0108000000005e74, S800
[ 4312.844067] firewire_ohci: failed to write phy reg
[ 4316.848110] firewire_ohci 0000:0c:00.0: PCI INT A disabled
[ 4316.848120] firewire_ohci: Removed fw-ohci device.
[ 4326.476256] pci 0000:0c:00.0: [11c1:5901] type 0 class 0x000c00
[ 4326.476303] pci 0000:0c:00.0: reg 10: [mem 0x00000000-0x00000fff 64bit]
[ 4326.476440] pci 0000:0c:00.0: supports D1 D2
[ 4326.476447] pci 0000:0c:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 4326.476459] pci 0000:0c:00.0: PME# disabled
[ 4326.476710] pci 0000:0c:00.0: BAR 0: assigned [mem
0xdfc00000-0xdfc00fff 64bit]
[ 4326.476731] pci 0000:0c:00.0: BAR 0: set to [mem
0xdfc00000-0xdfc00fff 64bit] (PCI address [0xdfc00000-0xdfc00fff])
[ 4326.476776] pci 0000:0c:00.0: no hotplug settings from platform
[ 4326.476967] firewire_ohci 0000:0c:00.0: enabling device (0000 -> 0002)
[ 4326.476984] firewire_ohci 0000:0c:00.0: PCI INT A -> GSI 17 (level,
low) -> IRQ 17
[ 4326.476999] firewire_ohci 0000:0c:00.0: setting latency timer to 64
[ 4326.532119] firewire_ohci: Added fw-ohci device 0000:0c:00.0, OHCI
v1.10, 8 IR + 8 IT contexts, quirks 0x10
[ 4327.032400] firewire_core: created device fw1: GUID 0108000000005e74, S800
[ 4355.368904] firewire_ohci: isochronous cycle inconsistent
[ 4355.369435] firewire_core: phy config: card 2, new root=ffc1, gap_count=5
[ 4380.913115] firewire_core: created device fw2: GUID
434fc00038594521, S400, 5 config ROM retries
[ 4382.936805] firewire_core: created device fw3: GUID
0108000000005e74, S400, 9 config ROM retries
[ 4993.104835] composite sync not supported
[ 5704.116045] usb 4-2: new low speed USB device number 2 using uhci_hcd
[ 5704.645037] input: HID 04b3:3107 as
/devices/pci0000:00/0000:00:1d.2/usb4/4-2/4-2:1.0/input/input8
[ 5704.645555] generic-usb 0003:04B3:3107.0001: input,hidraw0: USB HID
v1.00 Mouse [HID 04b3:3107] on usb-0000:00:1d.2-2/input0
[ 5704.649572] usbcore: registered new interface driver usbhid
[ 5704.649579] usbhid: USB HID core driver
[ 6316.176048] composite sync not supported
[23227.287363] firewire_core: phy config: card 2, new root=ffc1, gap_count=5
[23235.304185] firewire_core: giving up on refresh of device fw3

copy/paste of the fw_test.sh run:

+ screen -S foo -X screen async-test send 434fc00038594521
+ read

+ screen -S foo -p 0 -X kill
+ sleep 1
+ screen -S foo -p 1 -X kill
+ '[' '!' ']'
+ ./fw_test.sh 1
+ ls /dev/fw0 /dev/fw1 /dev/fw2 /dev/fw3
/dev/fw0  /dev/fw1  /dev/fw2  /dev/fw3
+ '[' 1 = 1 ']'
++ cut -c 3- /sys/bus/firewire/devices/fw1/guid
+ GUID=0108000000005e74
+ screen -S foo -d -m async-test receive 0108000000005e74
+ sleep 2
+ xterm -e screen -r foo
+ screen -S foo -X split -v
+ screen -S foo -X focus
+ screen -S foo -X screen async-test send 0108000000005e74
+ read

juser@xps:~$ cat /sys/bus/firewire/devices/fw?/guid
0x434fc00038594521
0x0108000000005e74
0x434fc00038594521


-- 
Carl K

Re: Boot from firewire drive with no BIOS support

[Harald K. <hk...@gm...>]

On 06/18/2011 05:10 PM, Stefan Richter wrote:
> On Jun 17 Ken Stailey wrote:
>>
>> Can you name a working implementation of (basically) /boot on USB and
>> root fs on Firewire?  I'd love to know which one works.
> [...]
>
> But it should actually be possible to do this waiting for the root
> filesystem even with a kernel without initrd, by means of the kernel
> parameter "rootwait".
> http://lxr.linux.no/#linux+v2.6.39/Documentation/kernel-parameters.txt#L2241
>

I did this long time ago (when I did all kind of fun things with 
Firewire, like using it as a  shared disk for 2 small computers, resp. 
cluster nodes).

It's was simple as Stefan describes: kernel self-compiled (Gentoo back 
then), with sbp2 driver and rootwait some seconds until the sbp2 disk 
was recognized as sdb (sda was the local disk where I booted from).
No issues with UUID as the number of sdX disks was very limited and the 
order was strictly /dev/sda for the one I boot off, and /dev/sdb for the 
only other disk, which was the Firewire one.

Harald

Re: Boot from firewire drive with no BIOS support

[Stefan R. <st...@s5...>]

On Jun 17 Ken Stailey wrote:
> --- On Fri, 6/17/11, Stefan Richter <st...@s5...> wrote:
> 
> > The second requirement is not exactly trivial but not an insurmountable
> > obstacle either.  I think there have been a few different strategies
> > implemented that solve this particular problem
> > (generally, not just for root-fs-on-FireWire).
> 
> Can you name a working implementation of (basically) /boot on USB and
> root fs on Firewire?  I'd love to know which one works.

No, I don't know of particular distributions or user solutions which
address that.

If you use an initrd, you can do virtually anything in there.  Like
waiting for the kernel uevent that is associated with registration of the
block device that hold your desired root partition.

I never use initrds myself, hence am out of touch with the toolchain to
build initrd images and can't help you with that.

But it should actually be possible to do this waiting for the root
filesystem even with a kernel without initrd, by means of the kernel
parameter "rootwait".
http://lxr.linux.no/#linux+v2.6.39/Documentation/kernel-parameters.txt#L2241

By the way, there is another problem, again a generic one rather than
FireWire specific:  Ho to specify the root filesystem or its device in the
first place.  After all, asynchronous device registration = random order
of device registration leads to random device names.  Hence, it is better
to specify the root file system or its partition by a persistent unique
ID.  If you use an initrd, you can in fact specify the root filesystem by
filesystem UUID.  If you do not use an initrd, you can partition the
FireWire disk with GPT and specify the partition UUID on the kernel
command line:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b5af921ec02333e943efb59aca4f56b78fc0e100

Another possible solution to the naming problem is to make sure that
firewire-sbp2 is the only SCSI host driver that is present at boot time
(i.e. no SATA host driver, USB storage driver, etc. statically linked into
the kernel nor provided as module in the initrd), and that only a single
FireWire disk is connected during boot.  Then you know that your root
filesystem resides on /dev/sda or on one of the partitions of /dev/sda.
-- 
Stefan Richter
-=====-==-== -==- =--=-
http://arcgraph.de/sr/

Re: Boot from firewire drive with no BIOS support

[Ken S. <kst...@ya...>]

--- On Fri, 6/17/11, Stefan Richter <st...@s5...> wrote:

> The second requirement is not exactly trivial but not an insurmountable
> obstacle either.  I think there have been a few different strategies
> implemented that solve this particular problem
> (generally, not just for root-fs-on-FireWire).

Can you name a working implementation of (basically) /boot on USB and root fs on Firewire?  I'd love to know which one works.

Re: Boot from firewire drive with no BIOS support

[Stefan R. <st...@s5...>]

On Jun 17 Ken Stailey wrote:
> I thought it would be easy to boot from a CD or USB key and switch so that the kernel
> on the Firewire drive would load, instead I find many tools that fail trying to do that.

You can purchase an Apple PC --- their firmware contains a stack of OHCI
1394, IEEE 1394, SBP-2, SCSI, RBC drivers which is able to use a FireWire
disk as boot medium.

Or you need to take an open source boot loader and add your own stack of
mentioned drivers to it and do what you described --- i.e. have this boot
loader on a CD or USB key but the Linux kernel on the FireWire disk (and
the root filesystem on the FireWire disk too, certainly).

Or, to finally turn this posting more towards realism, you can put
  - a usual boot loader,
  - the Linux kernel image,
  - if desired an initrd image
onto the CD or USB key and only the final root filesystem onto the
FireWire disk.

Either the kernel image or the initrd image
  - needs to contain firewire-ohci, firewire-sbp2, and their
    dependencies of course (PCI/ FireWire/ SCSI cores),
  - needs to be able to deal with the asynchronous nature of FireWire
    device discovery.  In other words, needs to wait for the disk/
    partition registration event before the root filesystem can be
    mounted.
The first requirement is trivial.  The second requirement is not exactly
trivial but not an insurmountable obstacle either.  I think there have been
a few different strategies implemented that solve this particular problem
(generally, not just for root-fs-on-FireWire).

There is a fourth option:  Put boot loader, kernel, and root filesystem
onto an USB key and only /home and some other directories (if
desired, /usr even) onto the FireWire disk.  I.e. mount / from USB
and /home etc. from FireWire.
-- 
Stefan Richter
-=====-==-== -==- =---=
http://arcgraph.de/sr/

Boot from firewire drive with no BIOS support

[Ken S. <kst...@ya...>]

Hi,

I have a FreeAgent GoFlex external drive with the Firewire (IEEE 1394b) module. It has ports for USB 2 and Firewire 800. The host has a Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller card in it. There are no other hard drives as I have pulled the cables out of the internal SATA drives so it's just a CD-ROM drive, some USB ports and and the Firewire drive.

I can plug in the drive via USB 2 and it boots with no problems at all.

I can plug in the drive via Firewire 800 and it will not boot as the BIOS doesn't speak Firewire.

I can boot from Ubuntu 11.10 server CD into rescue mode and mount the Firewire as chroot but I'm running off an old kernel on the CD-ROM and Upstart is all funny that way too.

In that mode "lspci -nvv" reports:

04:00.0 PCI bridge [0604]: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI Bridge [104c:823e] (rev 01) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Memory at fe9ff000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=04, secondary=05, subordinate=05, sec-latency=64
        Memory behind bridge: fea00000-feafffff
        Capabilities: [50] Power Management version 3
        Capabilities: [60] MSI: Enable- Count=1/16 Maskable- 64bit+
        Capabilities: [80] Subsystem: Device [3412:7856]
        Capabilities: [90] Express PCI/PCI-X Bridge, MSI 00
        Capabilities: [100] Advanced Error Reporting

05:00.0 FireWire (IEEE 1394) [0c00]: Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [104c:823f] (rev 01) (prog-if 10 [OHCI])
        Subsystem: Device [3412:7856]
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
        Memory at feaff800 (32-bit, non-prefetchable) [size=2K]
        Memory at feaf8000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [44] Power Management version 3
        Kernel driver in use: firewire_ohci

I thought it would be easy to boot from a CD or USB key and switch so that the kernel on the Firewire drive would load, instead I find many tools that fail trying to do that.

Searching the ieee1394.wiki.kernel.org and using google to search the "linux1394-user" archive hasn't turned up anything useful about this yet.  

Any suggestions?

Thanks,
Ken

Re: test script

[Carl K. <ca...@pe...>]

On Sun, Jun 5, 2011 at 9:16 PM, Carl Karsten <ca...@pe...> wrote:
> On Sun, Jun 5, 2011 at 3:20 PM, Carl Karsten <ca...@pe...> wrote:
>> On Sun, Jun 5, 2011 at 3:12 PM, Stefan Richter
>> <st...@s5...> wrote:
>>> On Jun 05 Carl Karsten wrote:
>>>> https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c
>>>>
>>>> root@chris:~# ./async-test receive
>>>> /dev/fw0: Success
>>>> ioctl allocate: Invalid argument
>>> [...]
>>>> Does this have a side effect?
>>>> 252            ret = ioctl(fd, FW_CDEV_IOC_GET_INFO, &info);
>>>
>>> Yes, it does, but at the moment I don't see which one would cause this
>>> failure.
>>>
>>> Try to combine the latter FW_CDEV_IOC_GET_INFO call at the end of
>>> main() into the call in the for loop.
>>>
>>> Some documentation is available in /usr/include/linux/firewire-cdev.h.
>>
>> ack - rushed to the email so you wouldn't spend any time...
>>
>> fixed:
>>
>> your        int i, fd, ret;
>> the local fd stole the value from the global.
>> looks like it is working now.
>>
>
> https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c
>
> root@chris:~# ./async-test send 5566778811223344
> /dev/fw0: Success
> 5566778811223344
> 00016c00006754fe 65473 65473 0
> /dev/fw1: Success
> 5566778811223344
> 5566778811223344 65472 65473 0
>
> root@pc9e:~# ./async-test receive 5566778811223344
> /dev/fw0: Success
> 5566778811223344
> 5566778811223344 65472 65472 1
> 10629120 packets, 22.76 MB/s  unexpected packet: 0xa2356d
> 84545536 packets, 22.73 MB/s
>
> I like it.  Thanks.
>
> dvgrab has 3 ways of finding a source:
> 1. default iterate and grab the first one found
> 2. -card num FireWire card num.
> 3. -guid hex
>
> I think I'll try implementing those in async-test.
> Any advice?  I'll put back /dev support too.
>

My goal of a quick way to test is coming along.  This runs both sides
of the test and lets me see the output of both sides.

Problem: xterm.  really?  I need X?!  Yeah, I couldn't figure out how
to do this with just term.  If someone can get screen to behave, or
something similar so I can see both send and receive processes, that
would be great.

https://gitorious.org/cfk_misc/fwdiag/blobs/master/fw_test.sh


#!/bin/bash -xe

if [ $1 ]; then
  GUID=$1
else
  GUID=$(cut -c 3- /sys/bus/firewire/devices/fw0/guid)
fi

screen -S foo -d -m async-test receive $GUID

xterm -e screen -r foo &
sleep 1

screen -S foo -X split -v
screen -S foo -X focus

screen -S foo -X screen async-test send $GUID



-- 
Carl K

Re: testing - was: firewire-net 2 ports

[Carl K. <ca...@pe...>]

On Sun, Jun 5, 2011 at 3:20 PM, Carl Karsten <ca...@pe...> wrote:
> On Sun, Jun 5, 2011 at 3:12 PM, Stefan Richter
> <st...@s5...> wrote:
>> On Jun 05 Carl Karsten wrote:
>>> https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c
>>>
>>> root@chris:~# ./async-test receive
>>> /dev/fw0: Success
>>> ioctl allocate: Invalid argument
>> [...]
>>> Does this have a side effect?
>>> 252            ret = ioctl(fd, FW_CDEV_IOC_GET_INFO, &info);
>>
>> Yes, it does, but at the moment I don't see which one would cause this
>> failure.
>>
>> Try to combine the latter FW_CDEV_IOC_GET_INFO call at the end of
>> main() into the call in the for loop.
>>
>> Some documentation is available in /usr/include/linux/firewire-cdev.h.
>
> ack - rushed to the email so you wouldn't spend any time...
>
> fixed:
>
> your        int i, fd, ret;
> the local fd stole the value from the global.
> looks like it is working now.
>

https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c

root@chris:~# ./async-test send 5566778811223344
/dev/fw0: Success
5566778811223344
00016c00006754fe 65473 65473 0
/dev/fw1: Success
5566778811223344
5566778811223344 65472 65473 0

root@pc9e:~# ./async-test receive 5566778811223344
/dev/fw0: Success
5566778811223344
5566778811223344 65472 65472 1
10629120 packets, 22.76 MB/s  unexpected packet: 0xa2356d
84545536 packets, 22.73 MB/s

I like it.  Thanks.

dvgrab has 3 ways of finding a source:
1. default iterate and grab the first one found
2. -card num FireWire card num.
3. -guid hex

I think I'll try implementing those in async-test.
Any advice?  I'll put back /dev support too.



-- 
Carl K

Re: testing - was: firewire-net 2 ports

[Carl K. <ca...@pe...>]

On Sun, Jun 5, 2011 at 3:12 PM, Stefan Richter
<st...@s5...> wrote:
> On Jun 05 Carl Karsten wrote:
>> https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c
>>
>> root@chris:~# ./async-test receive
>> /dev/fw0: Success
>> ioctl allocate: Invalid argument
> [...]
>> Does this have a side effect?
>> 252            ret = ioctl(fd, FW_CDEV_IOC_GET_INFO, &info);
>
> Yes, it does, but at the moment I don't see which one would cause this
> failure.
>
> Try to combine the latter FW_CDEV_IOC_GET_INFO call at the end of
> main() into the call in the for loop.
>
> Some documentation is available in /usr/include/linux/firewire-cdev.h.

ack - rushed to the email so you wouldn't spend any time...

fixed:

your        int i, fd, ret;
the local fd stole the value from the global.
looks like it is working now.


-- 
Carl K

Re: testing - was: firewire-net 2 ports

[Stefan R. <st...@s5...>]

On Jun 05 Carl Karsten wrote:
> https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c
> 
> root@chris:~# ./async-test receive
> /dev/fw0: Success
> ioctl allocate: Invalid argument
[...]
> Does this have a side effect?
> 252            ret = ioctl(fd, FW_CDEV_IOC_GET_INFO, &info);

Yes, it does, but at the moment I don't see which one would cause this
failure.

Try to combine the latter FW_CDEV_IOC_GET_INFO call at the end of
main() into the call in the for loop.

Some documentation is available in /usr/include/linux/firewire-cdev.h.
-- 
Stefan Richter
-=====-==-== -==- --=-=
http://arcgraph.de/sr/

Re: testing - was: firewire-net 2 ports

[Carl K. <ca...@pe...>]

On Tue, May 31, 2011 at 2:46 AM, Stefan Richter
<st...@s5...> wrote:
>
>        __u64 guid = 0x1111112222222222ull; /* <-- insert GUID of your lab card */
>        int receiver = 1;  /* <-- set receiver = 0 in the sender */
>
>        __u32 rom[5];
>        struct fw_cdev_event_bus_reset reset;
>        struct fw_cdev_get_info info = {
>                .rom            = (unsigned long)rom,
>                .rom_length     = sizeof(rom),
>                .bus_reset      = (unsigned long)&reset,
>        };
>        char name[] = "/dev/fw??";
>        int i, fd, ret;
>
>        for (i = 0; i < 99; i++) {
>                sprintf(name, "/dev/fw%d", i);
>
>                fd = open(name, O_RDWR);
>                if (fd < 0)
>                        continue;
>
>                ret = ioctl(fd, FW_CDEV_IOC_GET_INFO, &info);
>                if (ret >= 0 &&
>                    ((__u64)rom[3] << 32 | rom[4]) == guid &&
>                    (reset.node_id == reset.local_node_id) == (receiver == 1))
>                        break;
>
>                close(fd);
>                fd = -1;
>        }
>
>        if (fd < 0) {
>                fprint(stderr, "Device not found.\n")
>                exit(1);
>        }
>
>        /* Proceed to use fd. */
>

https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c

root@chris:~# ./async-test receive
/dev/fw0: Success
ioctl allocate: Invalid argument

old code:
269     // fd = open(argv[2], O_RDWR);

new:
248            fd = open(name, O_RDWR);


Does this have a side effect?
252            ret = ioctl(fd, FW_CDEV_IOC_GET_INFO, &info);



-- 
Carl K

Re: async-test

[Carl K. <ca...@pe...>]

On Sun, Jun 5, 2011 at 10:38 AM, Stefan Richter
<st...@s5...> wrote:
> On Jun 05 Carl Karsten wrote:
>> On Sun, Jun 5, 2011 at 9:48 AM, Stefan Richter
>> <st...@s5...> wrote:
>> > On Jun 05 Stefan Richter wrote:
>> >> I understood that you are meant to first connect both cards
>> >> with a FireWire cable, then start the listener on the /dev/fw* of the local
>> >> node of card A, then run the talker on the /dev/fw* of the remote node of
>> >> card B.
>> >
>> > Correction:  Both "..of card A"
>> >
>> >> Instead or in parallel, you can start the listener on the /dev/fw* of the
>> >> local node of card B, then run the talker on the /dev/fw* of the remote
>> >> node of card A.
>> >
>> > or both "...of card B" respectively.  %-|
>>
>> Are you suggesting running 2 listeners on the same box?
>
> Well, card A and card B may be on the same box or on different boxes; the
> principle stays the same.  You can run one talker--listener pair, or two
> talker--listener pairs which work in opposite directions (or with certain
> modifications to the tool any number of pairs).
>
>
> Test direction 1:
>
> Listener on the local node A and talker to remote node A create traffic
> in which node A is responder and and node B is requester.  This tests
> asynchronous request transmission and response reception on node B, and
> request reception and response transmission on node A.
>
> On the bus, the traffic is
>        B -> req  -> A
>        B <- ack  <- A
>        B <- resp <- A
>        B -> ack  -> A
>
> (This is for split transactions; write transactions can also be performed
> as unified transactions if directed to an address range in which the
> hardware supports them.  These unified transactions consist only of the
> first two of the shown four packets.  Broadcast write transactions consist
> only of the first one of the four packets.  Read and lock transactions are
> always split transactions with all four packets, if successful.  Different
> transactions can overlap each other in time.)
>
> If cards A and B sit in the same PC, run the listener and talker on this
> PC of course. :-)  The listener needs to access the local node
> A's /dev/fw*, and the talker needs to access the remote node A's /dev/fw*.
>
> If cards A and B sit in two different PCs, run the listener on the PC
> which contains card A (accessing the local node A's /dev/fw*) and the
> talker on the PC which contains card B (accessing the remote node
> A's /dev/fw*).
>
> Regardless whether it's one or two PCs, start the listener before the
> talker.  Otherwise the talker gets RCODE_ADDRESS_ERROR.
>
>
> Test direction 2:
>
> Same as above, but swap "A" and "B" everywhere.
>
>
> Test direction 1 and 2 concurrently:
>
> The two tests running at the same time.  There is no dependency or
> conflict between the two test directions, just more complete coverage if
> you try both directions.  Asynchronous transmission DMA and asynchronous
> reception DMA work a bit differently.  Also, having several DMA units busy
> at the same time is certainly desirable if the goal is to spot buggy cards.
>
> And then there are isochronous transmission and reception... :-)

got it.

Was running 1 send/receive test for a while (20+ min) with no errors.
brought up a 2nd pair going in the other direction.  Now I get errors
on both sides, about 1 every min or so.

One side has nothing new in dmesg, the other side:

juser@pc9e:~$ syslog-summary <( dmesg | cut -d \] -f 2- )

    4234  firewire_ohci: isochronous cycle too long
      38  irq_handler: 2 callbacks suppressed
      58  irq_handler: 1 callbacks suppressed
      22  irq_handler: 3 callbacks suppressed
      10  irq_handler: 5 callbacks suppressed
      18  irq_handler: 4 callbacks suppressed
       3  irq_handler: 6 callbacks suppressed
       1  irq_handler: 9 callbacks suppressed


root@chris:~# async-test receive /dev/fw0
892928 packets, 15.97 MB/s  duplicate packet: 0xda2b4
1863680 packets, 16.11 MB/s  duplicate packet: 0x1c7e2e
2236416 packets, 16.11 MB/s  duplicate packet: 0x222dd5
2547712 packets, 16.12 MB/s  duplicate packet: 0x26ebd5
3252224 packets, 16.12 MB/s  duplicate packet: 0x31ac4d
7122944 packets, 16.11 MB/s  duplicate packet: 0x6cb4bf
7315456 packets, 16.11 MB/s  duplicate packet: 0x6fa03e
7806976 packets, 16.10 MB/s  duplicate packet: 0x772f02
9003008 packets, 16.13 MB/s  duplicate packet: 0x896d44
9084928 packets, 16.13 MB/s  duplicate packet: 0x8aaed4
9986048 packets, 16.11 MB/s  duplicate packet: 0x986def
9998336 packets, 16.00 MB/s  duplicate packet: 0x9896bc
10248192 packets, 16.11 MB/s  duplicate packet: 0x9c6862
10399744 packets, 16.11 MB/s  duplicate packet: 0x9eb2f7
10842112 packets, 16.12 MB/s  duplicate packet: 0xa575ba
12500992 packets, 16.11 MB/s  duplicate packet: 0xbeccae
12886016 packets, 16.09 MB/s  duplicate packet: 0xc4accb
12951552 packets, 16.10 MB/s  duplicate packet: 0xc5ac6d
13123584 packets, 16.10 MB/s  duplicate packet: 0xc84a9e
13258752 packets, 16.12 MB/s  duplicate packet: 0xca5ab8
13307904 packets, 16.16 MB/s  duplicate packet: 0xcb1d05
13377536 packets, 16.10 MB/s  duplicate packet: 0xcc2967
13660160 packets, 16.12 MB/s  duplicate packet: 0xd07af7
13701120 packets, 16.11 MB/s  duplicate packet: 0xd1102b
14139392 packets, 16.25 MB/s  duplicate packet: 0xd7bfb8
14893056 packets, 16.10 MB/s  duplicate packet: 0xe34863
16211968 packets, 16.12 MB/s  duplicate packet: 0xf76b57
16232448 packets, 16.09 MB/s  duplicate packet: 0xf7bc5c
16785408 packets, 15.98 MB/s  duplicate packet: 0x1002b58
17281024 packets, 16.05 MB/s  duplicate packet: 0x107bcb7
17944576 packets, 16.13 MB/s  duplicate packet: 0x111d683
18714624 packets, 16.10 MB/s  duplicate packet: 0x11d98fe
18767872 packets, 16.12 MB/s  duplicate packet: 0x11e6bab
19267584 packets, 16.11 MB/s  duplicate packet: 0x1260e94
21299200 packets, 16.11 MB/s  duplicate packet: 0x1450051
21303296 packets, 16.13 MB/s  duplicate packet: 0x14511e4
21917696 packets, 15.98 MB/s  duplicate packet: 0x14e7659
22081536 packets, 16.01 MB/s  duplicate packet: 0x150fb7b
22360064 packets, 16.11 MB/s  duplicate packet: 0x155386c
22687744 packets, 16.12 MB/s  duplicate packet: 0x15a3506
25178112 packets, 16.11 MB/s  duplicate packet: 0x18037da
27078656 packets, 16.09 MB/s  duplicate packet: 0x19d3484
27643904 packets, 16.13 MB/s  duplicate packet: 0x1a5d57e
28164096 packets, 16.11 MB/s  duplicate packet: 0x1adc28e
28704768 packets, 16.13 MB/s  duplicate packet: 0x1b6035e
 duplicate packet: 0x1b605da
29773824 packets, 16.17 MB/s  duplicate packet: 0x1c650a4
 duplicate packet: 0x1c65263
29999104 packets, 16.09 MB/s  duplicate packet: 0x1c9cdbf
30015488 packets, 16.10 MB/s  duplicate packet: 0x1ca00eb
30232576 packets, 16.10 MB/s  duplicate packet: 0x1cd5360
30773248 packets, 16.13 MB/s  duplicate packet: 0x1d5932f
30961664 packets, 16.12 MB/s  duplicate packet: 0x1d871b8
31719424 packets, 16.10 MB/s  duplicate packet: 0x1e40f41
33296384 packets, 16.12 MB/s  duplicate packet: 0x1fc1425
35790848 packets, 16.11 MB/s  duplicate packet: 0x2222316
36085760 packets, 16.11 MB/s  duplicate packet: 0x226a475
36683776 packets, 15.83 MB/s  duplicate packet: 0x22fcb00
36835328 packets, 16.14 MB/s  duplicate packet: 0x2321470
36847616 packets, 16.22 MB/s  duplicate packet: 0x2324537
37482496 packets, 16.28 MB/s  duplicate packet: 0x23bfa4e
37507072 packets, 16.11 MB/s  duplicate packet: 0x23c595c
37601280 packets, 16.11 MB/s  duplicate packet: 0x23dcd40
37793792 packets, 16.12 MB/s  duplicate packet: 0x240b039
37900288 packets, 16.10 MB/s  duplicate packet: 0x2425535
38305792 packets, 16.13 MB/s  duplicate packet: 0x2488d79
38555648 packets, 16.10 MB/s  duplicate packet: 0x24c548e
38576128 packets, 16.07 MB/s  duplicate packet: 0x24ca0c0
39796736 packets, 15.97 MB/s  duplicate packet: 0x25f462a
 duplicate packet: 0x25f467b
40960000 packets, 16.12 MB/s  duplicate packet: 0x271067b
41263104 packets, 16.12 MB/s  duplicate packet: 0x275a288
41607168 packets, 16.10 MB/s  duplicate packet: 0x27aeaf5
42450944 packets, 16.37 MB/s  duplicate packet: 0x287c12e
43114496 packets, 16.10 MB/s  duplicate packet: 0x291e62d
44318720 packets, 16.12 MB/s  duplicate packet: 0x2a44ca3
45092864 packets, 16.07 MB/s  duplicate packet: 0x2b01b76
45535232 packets, 16.09 MB/s  duplicate packet: 0x2b6da35
45920256 packets, 16.10 MB/s  duplicate packet: 0x2bcbbc8
46284800 packets, 16.10 MB/s  duplicate packet: 0x2c2463e
47247360 packets, 15.98 MB/s  duplicate packet: 0x2d0f5ff
48074752 packets, 16.11 MB/s  duplicate packet: 0x2dd9930
48832512 packets, 16.08 MB/s  duplicate packet: 0x2e92080
49229824 packets, 16.12 MB/s  duplicate packet: 0x2ef34e5
49393664 packets, 16.12 MB/s  duplicate packet: 0x2f1bc3f
49397760 packets, 16.14 MB/s  duplicate packet: 0x2f1c9b8
49688576 packets, 16.13 MB/s  duplicate packet: 0x2f63211
50188288 packets, 16.10 MB/s  duplicate packet: 0x2fdd55d
50565120 packets, 16.12 MB/s  duplicate packet: 0x3039619
50720768 packets, 15.98 MB/s  duplicate packet: 0x305fe36
50724864 packets, 16.33 MB/s  duplicate packet: 0x3060006
 duplicate packet: 0x306001d
 duplicate packet: 0x3060089
50794496 packets, 16.11 MB/s  duplicate packet: 0x307176e
52944896 packets, 16.11 MB/s  duplicate packet: 0x327e62b
53485568 packets, 16.13 MB/s  duplicate packet: 0x3302089
53972992 packets, 16.12 MB/s  duplicate packet: 0x3379561
54784000 packets, 16.12 MB/s  duplicate packet: 0x343f55b
55717888 packets, 16.13 MB/s  duplicate packet: 0x3523a19
55996416 packets, 16.10 MB/s  duplicate packet: 0x356711b
56373248 packets, 16.11 MB/s  duplicate packet: 0x35c3957
56459264 packets, 16.11 MB/s  duplicate packet: 0x35d8b4c
56516608 packets, 16.13 MB/s  duplicate packet: 0x35e69b4
56909824 packets, 16.09 MB/s  duplicate packet: 0x364642d
57720832 packets, 16.10 MB/s  duplicate packet: 0x370ca36
58695680 packets, 16.12 MB/s  duplicate packet: 0x37fa0e6
59412480 packets, 16.11 MB/s  duplicate packet: 0x38a911b
59641856 packets, 16.12 MB/s  duplicate packet: 0x38e19b6
62181376 packets, 16.10 MB/s  duplicate packet: 0x3b4cfbf
62722048 packets, 16.08 MB/s  duplicate packet: 0x3bd1877
62808064 packets, 16.13 MB/s  duplicate packet: 0x3be6043
63438848 packets, 16.11 MB/s  duplicate packet: 0x3c80dd5
64294912 packets, 16.03 MB/s  duplicate packet: 0x3d51e6e
65327104 packets, 16.11 MB/s  duplicate packet: 0x3e4df1c
66297856 packets, 16.15 MB/s  duplicate packet: 0x3f3a2d5
66445312 packets, 16.11 MB/s  duplicate packet: 0x3f5ef24
67108864 packets, 15.98 MB/s  duplicate packet: 0x4000a86
67305472 packets, 16.12 MB/s  duplicate packet: 0x4030ade
71143424 packets, 16.10 MB/s  duplicate packet: 0x43d9e63
72200192 packets, 16.11 MB/s  duplicate packet: 0x44db842
72241152 packets, 16.04 MB/s  duplicate packet: 0x44e592c
72544256 packets, 16.11 MB/s  duplicate packet: 0x452f7b4
73723904 packets, 16.11 MB/s  duplicate packet: 0x464f012
74682368 packets, 16.11 MB/s


pc9e:
(what's on term.  screen cut is not doing what I want)
307245056 packets, 14.41 MB/s  duplicate packet: 0x12503b29
307597312 packets, 14.40 MB/s  duplicate packet: 0x12559916
309927936 packets, 14.42 MB/s  duplicate packet: 0x12792afa
310001664 packets, 14.39 MB/s  duplicate packet: 0x127a4f8e
312451072 packets, 14.34 MB/s  duplicate packet: 0x129fa9b8
313802752 packets, 14.08 MB/s  duplicate packet: 0x12b44b9a
318390272 packets, 14.07 MB/s  duplicate packet: 0x12fa4e73
318578688 packets, 14.42 MB/s  duplicate packet: 0x12fd2787
320360448 packets, 14.58 MB/s  duplicate packet: 0x131851f8
324489216 packets, 14.38 MB/s  duplicate packet: 0x135751cd
 duplicate packet: 0x135751db
327847936 packets, 14.41 MB/s  duplicate packet: 0x138a93cd
328171520 packets, 14.40 MB/s  duplicate packet: 0x138f8421
331878400 packets, 14.40 MB/s  duplicate packet: 0x13c81f32
331972608 packets, 14.37 MB/s  duplicate packet: 0x13c98100
332316672 packets, 14.39 MB/s
334905344 packets, 14.41 MB/s  duplicate packet: 0x13f646da
335200256 packets, 14.41 MB/s  duplicate packet: 0x13facbe8
336822272 packets, 14.41 MB/s  duplicate packet: 0x14138844
338022400 packets, 14.39 MB/s


I think printing time stamps and deltas would be handy.

-- 
Carl K