| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20260205123722.GA303762@workstation.local>
Date: Thu, 5 Feb 2026 21:37:22 +0900
From: Takashi Sakamoto <o-takashi@...amocchi.jp>
To: Salvatore Bonaccorso <carnil@...ian.org>
Cc: rpnpif <rpnpif@...b.eu>, 1126090@...s.debian.org,
linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: Bug#1126090: Firewire-ohci module crashes: firewire_ohci
0000:02:00.0: failed to read phy reg 2
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:
Thanks for your report[1].
> 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: Device [3412:7856]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> IOMMU group: 1
> Region 1: Memory at fe700000 (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: fe600000-fe6fffff [size=1M] [32-bit]
> Prefetchable memory behind bridge: [disabled] [64-bit]
> Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
> BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> 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: Device [3412:7856]
> Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Interrupt: pin A routed to IRQ 18
> IOMMU group: 1
> Region 0: Memory at fe604000 (32-bit, non-prefetchable) [size=2K]
> Region 1: Memory at fe600000 (32-bit, non-prefetchable) [size=16K]
> Capabilities: <access denied>
> Kernel modules: firewire_ohci
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.
> [ 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.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
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
Powered by blists - more mailing lists