Description of problem:
Firewire interface and downloading from a firewire-equipped cable box using test-mpeg2 works on a FC12 i686 LiveCD but not a FC12 x86-64 LiveCD.
I do not know if this is a firewire kernel problem (improper behavior of the 64 bit drivers) or a userspace problem in iec61883 or the 1394 interface libraries.
Version-Release number of selected component (if applicable):
FC12 release LiveCD for x86-64 fails
FC12 release LiveCD for i686 works
Steps to Reproduce:
1. Connect HD-cable box with firewire port to computer & turn on cable box
2. Boot LiveCD.
3. Install libiec61883-utils appropriate for the platform
4. plugctl -n 1 oPCR.n_p2p_connections=1
5. test-mpeg2 -r 1 > test.file
(On x86-64): test.file is created but remains zero-length.
(on i686): test.file is created and expands as long as test-mpeg2 runs. The resulting file generally be played with mplayer
Relevant bits from the hardware description as follows:
CPU: Intel Core 2 Duo 6550
Motherboard chipset: Nvidia 7100
Adaptec USB/Firewire PCI card
lspci -v data for firewire controller:
02:0c.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
Subsystem: Texas Instruments Unknown device 8010
Flags: bus master, medium devsel, latency 64, IRQ 18
Memory at febfd000 (32-bit, non-prefetchable) [size=2K]
Memory at febf8000 (32-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: firewire_ohci
Kernel modules: firewire-ohci
Note that this lspci data was collected using an older version of Fedora. If required, I can rerun lspci on FC12.
I can run additional diagnostics on this if more information is required to narrow down the problem.
How much memory is installed in this machine? If more than 2 GB, try the x86-64 live CD again with "mem=2G" appended as kernel parameter on the boot loader's prompt (if that is possible with the live CD), or with RAM physically removed so that no more than 2 GB remain.
(I am alluding to bug 435550 here which was about TSB43AB22/A.)
Could you test an actual Fedora installation (F12 or Rawhide) with the current Rawhide kernel package? This would be a 2.6.33 pre-release kernel which contains a change that could fix this issue.
On F12, you get the Rawhide kernel with
# yum --enablerepo=rawhide install kernel
(Or at least I think so; I don't have Fedora myself.)
(In reply to comment #1)
> How much memory is installed in this machine? If more than 2 GB, try the
> x86-64 live CD again with "mem=2G" appended as kernel parameter on the boot
> loader's prompt (if that is possible with the live CD), or with RAM physically
> removed so that no more than 2 GB remain.
> (I am alluding to bug 435550 here which was about TSB43AB22/A.)
Stefan - The machine in question does have 4G of memory. The mem=2G option does indeed seem to fix the problem. I'll try to test the updated kernel. I hope that kernel-2.6.33-0.20.rc5.git0.fc13.x86-64 will fit the bill.
One other odd thing that I noticed about this problem - it no longer appears to be completely reproducible with the stock x86 settings. It appears to be dependent on which PCI/PCI-Express cards are installed (and possibly which PCI slot gets used). For instance, the problem occurs when the Firewire card is in PCI slot 4, but not 3. If I add my PCI-Ex graphics card, the problem goes away. I will try to test this more.
(In reply to comment #3)
> It appears to be dependent on which PCI/PCI-Express cards are
> installed (and possibly which PCI slot gets used).
Perhaps the presence or absence of other cards influences the probability of allocations (of firewire-ohci's dualbuffer DMA descriptors) landing above or below the 31 bit address barrier which is problematic for TSB43AB22/A and evidently TSB43AB23 too.
If you have the means to test a kernel-2.6.33*.fc13.x86-64 on a hardware configuration that would get no video or only corrupted video under F12/x86-64, that would be appreciated. (If successful, it would be green light for a fix patch that I have in mind.)
Upstream bug: http://bugzilla.kernel.org/show_bug.cgi?id=13808
Proposed patch: http://lkml.org/lkml/2010/1/26/284
The fix for this is queued for 22.214.171.124 as:
upstream commit 7a481436787cbc932af6c407b317ac603969a242
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '12'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 12's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 12 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.