PS,
please also supply the output of "grep . /sys/bus/firewire/devices/fw*/*"
from when the FireWire device is attached but idle and undisturbed.

What hardware do you use?  (FireWire controller according to lspci -nn, if
known make and model of the controller, whether it is PCI, PCIe, CardBus,
ExpressCard; and of course make and model of the attached FireWire device)

How do you supply power to the FireWire device?  (By its own PSU, or by
bus power; if the latter, does the FireWire controller have a direct
connection to the PC's PSU?)

Do you mean by watching video that you are getting the video from the
FireWire device, or is this simply video from a harddisk and the FireWire
device is not even used while the problems happen?

(In reply to comment #1)
> PS,
> please also supply the output of "grep . /sys/bus/firewire/devices/fw*/*"
> from when the FireWire device is attached but idle and undisturbed.

I just now attached the output.

(In reply to comment #2)
> What hardware do you use?  (FireWire controller according to lspci -nn, if
> known make and model of the controller, whether it is PCI, PCIe, CardBus,
> ExpressCard; and of course make and model of the attached FireWire device)
> 
> How do you supply power to the FireWire device?  (By its own PSU, or by
> bus power; if the latter, does the FireWire controller have a direct
> connection to the PC's PSU?)
> 
> Do you mean by watching video that you are getting the video from the
> FireWire device, or is this simply video from a harddisk and the FireWire
> device is not even used while the problems happen?

lspci:
00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] RS780 Host Bridge [1022:9600]
00:01.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (int gfx) [1022:9602]
00:05.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 1) [1022:9605]
00:06.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 2) [1022:9606]
00:11.0 SATA controller [0106]: ATI Technologies Inc SB700/SB800 SATA Controller [IDE mode] [1002:4390]
00:12.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397]
00:12.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398]
00:12.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396]
00:13.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397]
00:13.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398]
00:13.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396]
00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller [1002:4385] (rev 3a)
00:14.1 IDE interface [0101]: ATI Technologies Inc SB700/SB800 IDE Controller [1002:439c]
00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383]
00:14.3 ISA bridge [0601]: ATI Technologies Inc SB700/SB800 LPC host controller [1002:439d]
00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge [1002:4384]
00:14.5 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI2 Controller [1002:4399]
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101]
00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102]
00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103]
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon HD 3200 Graphics [1002:9610]
01:05.1 Audio device [0403]: ATI Technologies Inc RS780 Azalia controller [1002:960f]
02:00.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge [10b5:8111] (rev 21)
03:00.0 FireWire (IEEE 1394) [0c00]: NEC Corporation uPD72874 IEEE1394 OHCI 1.1 3-port PHY-Link Ctrlr [1033:00f2] (rev 01)
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 02)
05:05.0 Multimedia video controller [0400]: Internext Compression Inc iTVC15 MPEG-2 Encoder [4444:0803] (rev 01)
05:06.0 Network controller [0280]: RaLink RT2500 802.11g Cardbus/mini-PCI [1814:0201] (rev 01)
05:07.0 Multimedia video controller [0400]: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05)
05:07.1 Multimedia controller [0480]: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] [14f1:8801] (rev 05)
05:07.2 Multimedia controller [0480]: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] [14f1:8802] (rev 05)
05:07.4 Multimedia controller [0480]: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [IR Port] [14f1:8804] (rev 05)

The firewire card is PCI, but not sure of make/model separate from the lspci output.  It uses the motherboard's/PC's power.  The firewire is device is a cable box: Scientific Atlanta 4240 HDC.  When I say "watching video", it is only using the hard disks...the videos are already recorded.  There are no active recordings happening at the time either.

Thanks,
Brian

Created attachment 43842 [details]
proc of firewire devices

The power issue has me thinking.  The firewire worked a year ago.  I just got back to using it this year.  But I have added a hard drive in between.  And I guess playing video may use enough power to make something underperform.  I will look further into the power issue.

> The firewire card is PCI, but not sure of make/model separate from the lspci
> output.  It uses the motherboard's/PC's power.  The firewire is device is a
> cable box: Scientific Atlanta 4240 HDC.

The 12V power rail of PCI slots is too weak to use it as FireWire bus power
source.  However, the Scientific Atlanta 4240 HDC is apparently
self-powered and should thus not be affected by insufficient FireWire bus
power.  So, the PCI bus just needs to power the FireWire controller card
itself which should be well within the power budget.

But maybe your graphics card draws more power with recent drivers
(perhaps decoding tasks that were previously performed by the CPU are now
offloaded onto the GPU) and stresses the mainboard's power rails even more
than PCI devices like your NEC controller can tolerate.

I forgot:  /sys/bus/firewire/devices/fw1/config_rom would be good to see.
(It's a binary file, just attach it as-is.)

Created attachment 44222 [details]
fw1

Yes, the firewire device is self-powered.  However, I removed a hard drive just to make sure I am not drawing too much power.

'powertop' does should that the ivtv module is consistently using power even though that tuner is not recording.  That is part of V4L, so that could also explain the idea of increased power usage from the newer V4L.

I took out a hard drive and I am still having the same problem though.  The config_rom is attached as requested.

Created attachment 44472 [details]
fw1 - parsed config ROM

> Created an attachment (id=44222)
>  --> (https://bugzilla.kernel.org/attachment.cgi?id=44222)
> fw1

Thanks.  I attach a clear-text representation of it for reference.

> Yes, the firewire device is self-powered.  However, I removed a hard
> drive just to make sure I am not drawing too much power.

It's not only an issue to stay within a global budget, but also an issue of not stressing specific rails too much.  Does your graphics card have an own power connection to the PSU?  Is it a value PSU or high-quality PSU?  (I.e. what might be the margin between power rating on the sticker and actual performance?)  Value mainboard or HQ mainboard?  (There is also the potential issue of aging of power electronics components.)

> 'powertop' does should that the ivtv module is consistently using power even
> though that tuner is not recording.  That is part of V4L, so that could also
> explain the idea of increased power usage from the newer V4L.

A valid comment, although powertop only watches CPU utilization and has of course no knowledge about power draw of any of the other components of the system.

> I took out a hard drive and I am still having the same problem though.

Peak power draw of HDDs is when they spin up.

> The config_rom is attached as requested.

Thanks.  This device flags itself as Cycle Master capable, 1394a-2000 Isochronous Resource Manager capable, and even Bus Manager capable.  The former two properties rule out that there could be an issue with firewire-core attempting to wrestle the root node position from the set top box.  (I wanted to see this because in the past we had issues with 1394-1995 Isochronous Resource Manager implementations in camcorder firmwares, and these issues looked deceptively similar to hardware faults or were even coupled with silicon bugs in the camcorder.)  IOW this reinforces the likelihood that an electrical problem is the cause, rather than a FireWire driver or firmware problem.

(In reply to comment #8)
> 
> It's not only an issue to stay within a global budget, but also an issue of
> not
> stressing specific rails too much.  Does your graphics card have an own power
> connection to the PSU?  Is it a value PSU or high-quality PSU?  (I.e. what
> might be the margin between power rating on the sticker and actual
> performance?)  Value mainboard or HQ mainboard?  (There is also the potential
> issue of aging of power electronics components.)

I am using the mainboard's built-in graphics.  I bought it about 2-3 years ago.  It has the built-in ATI 3200HD with HDMI out.

> A valid comment, although powertop only watches CPU utilization and has of
> course no knowledge about power draw of any of the other components of the
> system.

I figured that was the case

> Peak power draw of HDDs is when they spin up.

I had btrfs striping between 2 hard drives.  I would imagine that reading a video file while watching video would cause both disks to spin using more power than before when a video sat on a single drive.  I am now back to one drive for the video.

> Thanks.  This device flags itself as Cycle Master capable, 1394a-2000
> Isochronous Resource Manager capable, and even Bus Manager capable.  The
> former
> two properties rule out that there could be an issue with firewire-core
> attempting to wrestle the root node position from the set top box.  (I wanted
> to see this because in the past we had issues with 1394-1995 Isochronous
> Resource Manager implementations in camcorder firmwares, and these issues
> looked deceptively similar to hardware faults or were even coupled with
> silicon
> bugs in the camcorder.)  IOW this reinforces the likelihood that an
> electrical
> problem is the cause, rather than a FireWire driver or firmware problem.

I will continue to go the power route as it seems to be the logical cause.  I can tell you that when I start playing video and I run 'plugreport', the GUID changes slightly (same last 4 characters).  However, the STB is still there.  Then 2 seconds later the GUID changes again and STB is gone.

I hooked up a bigger power supply and tried it out.  I am getting the same results.  After starting the playback of video, here are the first 3 calls to 'plugreport':


root@mythserver:~# plugreport
Host Adapter 0
==============

Node 0 GUID 0x00004c01000043fa
------------------------------
libiec61883 error: error reading oMPR
libiec61883 error: error reading iMPR

Node 1 GUID 0x00223a10d6ac0000
------------------------------
oMPR n_plugs=1, data_rate=2, bcast_channel=63
oPCR[0] online=1, bcast_connection=0, n_p2p_connections=0
        channel=0, data_rate=0, overhead_id=0, payload=146
iMPR n_plugs=0, data_rate=2

root@mythserver:~# plugreport
Host Adapter 0
==============

Node 0 GUID 0x00004c01000043fa
------------------------------
libiec61883 error: error reading oMPR
libiec61883 error: error reading iMPR

Node 1 GUID 0x00223a1000223a10
------------------------------
oMPR n_plugs=1, data_rate=2, bcast_channel=63
oPCR[0] online=1, bcast_connection=0, n_p2p_connections=0
        channel=0, data_rate=0, overhead_id=0, payload=146
iMPR n_plugs=0, data_rate=2

root@mythserver:~# plugreport
Host Adapter 0
==============

Node 0 GUID 0x00004c01000043fa
------------------------------
libiec61883 error: error reading oMPR
libiec61883 error: error reading iMPR

Node 1 GUID 0xfa430000000043fa
------------------------------
libiec61883 error: error reading oMPR
libiec61883 error: error reading iMPR


You can see how the GUID changes, but it is still being probed appropriately.  Then the device just drops.

I went out a bought a $10 PCI firewire card to replace the PCIe firewire card.  Everything works perfect now.  I think there was a hardware issue with the firewire card (and it might have been caused by a lack of power).  Thanks to those who helped and all linux developers.

hardware issue

> I am using the mainboard's built-in graphics.

Hmm, onboard graphics shouldn't bee too power hungry.  But who knows, after all it might cut into the power budget of other PCI(e) slots nevertheless.  Or it was not actually about power draw but about noise (EMI) on one/some of the board's slots.

> Node 1 GUID 0x00223a10d6ac0000
[plug register access succeeds]
> Node 1 GUID 0x00223a1000223a10
[plug register access succeeds]
> Node 1 GUID 0xfa430000000043fa
[plug register access fails]

plugreport's function which fetches the GUID does not check whether th etransaction was actually successful.  It simply takes for granted whatever is left in its (uninitialized stack-allocated) transfer buffer.  Its plug register accesses have failure checks though.  I.e. the GUID did most certainly not change, rather the contact between controller and device started to become unreliable.

> I went out a bought a $10 PCI firewire card to replace the PCIe firewire
> card. Everything works perfect now.

Good. I'm glad you got it fixed at little cost.