Dear Maintainer, On startup, firewire-ohci crashes If modprobe firewire-core, there are no crash but that doesn't mean it works well, because the /dev/xxxx plugin is not created. [ 14.149170] Call Trace: [ 14.149174] <TASK> [ 14.149177] dump_stack_lvl+0x64/0x80 [ 14.149185] read_phy_reg+0x91/0xa0 [firewire_ohci] [ 14.149196] ohci_enable+0x3a3/0x5b0 [firewire_ohci] [ 14.149204] fw_card_add+0x85/0x110 [firewire_core] [ 14.149232] pci_probe+0x492/0x620 [firewire_ohci] [ 14.149241] local_pci_probe+0x45/0xa0 [ 14.149247] pci_device_probe+0x20a/0x240 [ 14.149251] really_probe+0xd6/0x380 [ 14.149255] ? __pfx___driver_attach+0x10/0x10 [ 14.149258] __driver_probe_device+0x78/0x150 [ 14.149261] driver_probe_device+0x1f/0x90 [ 14.149264] __driver_attach+0xd2/0x1c0 [ 14.149267] bus_for_each_dev+0x88/0xd0 [ 14.149272] bus_add_driver+0x112/0x240 [ 14.149275] driver_register+0x59/0x100 [ 14.149279] ? __pfx_fw_ohci_init+0x10/0x10 [firewire_ohci] [ 14.149285] do_one_initcall+0x5b/0x320 [ 14.149292] do_init_module+0x60/0x270 [ 14.149296] __do_sys_init_module+0x17f/0x1b0 [ 14.149300] do_syscall_64+0x82/0x190 [ 14.149307] ? vfs_read+0x247/0x370 [ 14.149312] ? arch_exit_to_user_mode_prepare.constprop.0+0x16/0xa0 [ 14.149316] ? syscall_exit_to_user_mode+0x37/0x1b0 [ 14.149319] ? do_syscall_64+0x8e/0x190 [ 14.149321] ? __count_memcg_events+0x53/0xf0 [ 14.149325] ? count_memcg_events.constprop.0+0x1a/0x30 [ 14.149328] ? handle_mm_fault+0xae/0x2d0 [ 14.149332] ? do_user_addr_fault+0x379/0x670 [ 14.149335] ? arch_exit_to_user_mode_prepare.constprop.0+0x16/0xa0 [ 14.149339] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 14.149345] RIP: 0033:0x7fd1fbe08d2a [ 14.149349] Code: 48 8b 0d d9 90 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a6 90 0c 00 f7 d8 64 89 01 48 [ 14.149351] RSP: 002b:00007ffcec140b98 EFLAGS: 00000246 ORIG_RAX: 00000000000000af [ 14.149355] RAX: ffffffffffffffda RBX: 00005566438d8eb0 RCX: 00007fd1fbe08d2a [ 14.149357] RDX: 00007fd1fbf3cefd RSI: 000000000002220e RDI: 0000556643a6a3a0 [ 14.149358] RBP: 00007fd1fbf3cefd R08: 0000000000000007 R09: 000055664383ef50 [ 14.149360] R10: 0000000000000005 R11: 0000000000000246 R12: 0000556643a6a3a0 [ 14.149361] R13: 0000000000000000 R14: 00005566438ddc70 R15: 00007ffcec140e00 [ 14.149364] </TASK> [ 14.150242] firewire_ohci 0000:02:00.0: probe with driver firewire_ohci failed with error -16 [ 14.150382] firewire_ohci 0000:02:00.0: removed fw-ohci device
Control: tags -1 + moreinfo boot without loading those, trigger the issue and the attache the *full* kernel log please? Additionally: is that an experienced regression from a previous running kernel? Which one? Can you as well test newer kernel, from the upper suite at least 6.12.63-1 from trixie, but additonally the ones in unstable and experimental so we get a picture on the if newer upstream versions would expose the problem as well. Regards, Salvatore
Le 24/01/2026 à 18:10, Salvatore Bonaccorso a écrit : Hello, I have tried with the 6.19~rc6-1~exp1 kernel from experimental. I get the same bug. I cannot now try from trixie because a lot of dependencies.I'll try later from a live DVD or USB key. ASAP, I'll try also old live Debian to see if it is better. Attached the full dmesg log from journald. Thank you.
All my tests does not work with the same issue and crash from the 3.16 (10 years old!) kernel to the last 6.19-rc. So I think that this device has never work with firewire-ohci. It a pity. It works fine a long time ago with the obsolete raw1394 module. I have seen on the web that I am not alone. My device: The adapter: lspci -v 02:00.0 FireWire (IEEE 1394): Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express] (rev 01) (prog-if 10 [OHCI]) Subsystem: Device 3412:7856 Flags: 66MHz, medium devsel, IRQ 18, IOMMU group 1 Memory at fe604000 (32-bit, non-prefetchable) [size=2K] Memory at fe600000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 3 Kernel modules: firewire_ohci dvgrab -i Error: no camera exists But the Sony DCR-TRV325E is connected on the DV-OUT output.
Hi Rpnpif, reported in Debian (at https://bugs.debian.org/1126090) that firewire_ohci driver has since almost 3.16, an issue with the following device: 02:00.0 FireWire (IEEE 1394): Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express] (rev 01) (prog-if 10 [OHCI]) Subsystem: Device 3412:7856 Flags: 66MHz, medium devsel, IRQ 18, IOMMU group 1 Memory at fe604000 (32-bit, non-prefetchable) [size=2K] Memory at fe600000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 3 Kernel modules: firewire_ohci A log from the affected system follows: The old IEEE 1394 driver stack was removed way back in 2010, so maybe the issue is actually present since then, but looks Rpnpif would be happy to still get it working. Is there anything Rpnpif could provide to you to debug the issue? Regards, Salvatore
Hi, Here some more information about this bug. I replaced the "FireWire (IEEE 1394): Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express] (rev 01)" card with an old cable by "FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0)" card with a new cable. And now there are no crash from the kernel but the camera is not detected. I replaced the new cable with the old cable and now all works fine. I have not explanations about why this. In conclusion, Texas Instruments XIO2213A/B/XIO2221 is incorrectly activated unlike VT6306/7/8 from Via to detect the Sony DCR-TRV325E camera (that is old also). Regards.
Hi,
Thanks for your report[1].
I use so long the similar product with the same combination of bus bridge
chip and 1394 OHCI controller, on AMD processor family 19th model 0x50
(Ryzen 7 5700G, Cezanne), but never face the issue. My output of lspci
is:
```
$ lspci -vnn
...
01:00.0 PCI bridge [0604]: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI Bridge [Cheetah Express] [104c:823e] (rev 01) (prog-if 00 [Normal decode])
Subsystem: Texas Instruments Device [104c:823f]
Flags: bus master, fast devsel, latency 0, IOMMU group 10
Memory at fcd00000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=01, secondary=02, subordinate=02, sec-latency=32
I/O behind bridge: [disabled] [32-bit]
Memory behind bridge: fcc00000-fccfffff [size=1M] [32-bit]
Prefetchable memory behind bridge: [disabled] [64-bit]
Capabilities: <access denied>
02:00.0 FireWire (IEEE 1394) [0c00]: Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express] [104c:823f] (rev 01) (prog-if 10 [OHCI])
Subsystem: Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express] [104c:823f]
Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 121, IOMMU group 10
Memory at fcc04000 (32-bit, non-prefetchable) [size=2K]
Memory at fcc00000 (32-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: firewire_ohci
Kernel modules: firewire_ohci
...
```
According to the value of subsystem field, it is manufactured by Texas
Instruments, while the issued device is from 3412:7856. The vendor ID
0x3412 seems not to be registered in pciids[2]. Fortunately, I can find
the report from Raspberry PI users to use the device[3], and it seems to
work in their Arm64 machine.
I guess that the issue appears in the case to use a certain combination
of hardware. I can remember an unresolved issue that AMD Ryzen machine
generates unexpected system reboot when working with the hardware of
ASM1083 and VT63xx[4], but never cleared.
The above messages are printed by the following line:
$ git show v6.12:drivers/firewire/ohci.c | nl -b a
634 static int read_phy_reg(struct fw_ohci *ohci, int addr)
635 {
636 u32 val;
637 int i;
638
639 reg_write(ohci, OHCI1394_PhyControl, OHCI1394_PhyControl_Read(addr));
640 for (i = 0; i < 3 + 100; i++) {
641 val = reg_read(ohci, OHCI1394_PhyControl);
642 if (!~val)
643 return -ENODEV; /* Card was ejected. */
644
645 if (val & OHCI1394_PhyControl_ReadDone)
646 return OHCI1394_PhyControl_ReadData(val);
647
648 /*
649 * Try a few times without waiting. Sleeping is necessary
650 * only when the link/PHY interface is busy.
651 */
652 if (i >= 3)
653 msleep(1);
654 }
655 ohci_err(ohci, "failed to read phy reg %d\n", addr);
656 dump_stack();
657
658 return -EBUSY;
659 }
It hits 'dump_stack()'. It means that it has no critical effect to your
running machine, just generates annoying dump message, So our situation is
not so critical, in system POV.
The cause is that the value of register does not become to have a 'done'
bit, even if retrying 100 times, after configuring the link layer to read
register in PHY layer.
The most suspicious cause is the hardware fail to provide SCLK signal
even after turning on Link Power Status (LPS). In this case, any access
to the OHCI1394_PhyControl register undefined, according to 1394 OHCI
Specification Release 1.1 (clause 4. Register addressing). Actually the
1394 OHCI driver attempts to detect LPS-on by the following lines:
```
2416 static int ohci_enable(struct fw_card *card,
2417 const __be32 *config_rom, size_t length)
2418 {
...
2442 reg_write(ohci, OHCI1394_HCControlSet,
2443 OHCI1394_HCControl_LPS |
2444 OHCI1394_HCControl_postedWriteEnable);
2445 flush_writes(ohci);
2446
2447 for (lps = 0, i = 0; !lps && i < 3; i++) {
2448 msleep(50);
2449 lps = reg_read(ohci, OHCI1394_HCControlSet) &
2450 OHCI1394_HCControl_LPS;
2451 }
2452
2453 if (!lps) {
2454 ohci_err(ohci, "failed to set Link Power Status\n");
2455 return -EIO;
2456 }
...
```
On the other hand, the arrival of SCLK can not detected by software.
Would I ask you to try inserting msleep() with enough long in the end of
the above lines if you can compile the driver code by yourself?
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1126090
[2] https://pci-ids.ucw.cz/
[3] https://github.com/geerlingguy/raspberry-pi-pcie-devices/issues/297
[4] https://lore.kernel.org/lkml/20231105144852.GA165906@workstation.local/
Regards
Takashi Sakamoto
I wonder if installing the latest firmware might help? Hardware name: MSI MS-7721/A78M-E35 (MS-7721), BIOS V30.3 03/14/2014 According to https://www.msi.com/Motherboard/A78M-E35/support v30.6 (2014-12-23) is available. The descriptions for each revision since v30.6 state they include AGESA updates.