From: David Runge <hidden> Date: 2021-01-23 12:10:14
Hi!
I package linux-rt and linux-rt-lts for Arch Linux.
Due to time constraints over the past months I did not have the time to
test all of my own hardware setups with the recent realtime kernels.
Unfortunately firewire-ohci is unable to initialize my firewire
controller [1] (a PCIe card [2]) both on 5.4.91-rt50 and on 5.10.8-rt24: No
device nodes (i.e. /dev/fw0) are created and therefore no connected devices can
be initialized either.
The controller is initialized properly on our other stock kernels on
Arch Linux though (e.g. linux/ linux-hardened/ linux-lts) and I usually keep
the config files for linux-rt[3] and linux-rt-lts[4] as close as possible to
that of our respective core linux packages linux[5] and linux-lts[6].
Looking at the kernel logs, this is what the initialization usually looks like
on our stock kernels (with `firewire_ohci debug=8` and duplicate lines
truncated for brevity):
I have a laptop using an ExpressCard34 that provides Firewire800 [7], with the
same Texas Instruments chip which initializes properly (i.e. /dev/fw0 is
created, subsequently connected devices are initialized and are usable) on the
realtime kernels:
At this point in time I'm uncertain whether this is a general problem
with the kernel module on the realtime kernels or a problem with the
kernel module on the realtime kernels with my PCIe controller specifically.
That it works using the ExpressCard34 based controller on my laptop makes it
extra odd (but I guess the underlying driver is handling this
differently due to the PCI bridge?).
Any pointers to solving this issue would be greatly appreciated, as not being
able to use firewire audio interfaces on a realtime kernel in a workstation
context is bad for pro-audio people on Linux in general (and me in particular
;-) ).
Best,
David
[1]
From: Ahmed S. Darwish <hidden> Date: 2021-01-28 06:29:25
On Sat, Jan 23, 2021 at 12:59:29PM +0100, David Runge wrote:
...
Unfortunately firewire-ohci is unable to initialize my firewire
controller [1] (a PCIe card [2]) both on 5.4.91-rt50 and on 5.10.8-rt24: No
device nodes (i.e. /dev/fw0) are created and therefore no connected devices can
be initialized either.
...
At this point in time I'm uncertain whether this is a general problem
with the kernel module on the realtime kernels or a problem with the
kernel module on the realtime kernels with my PCIe controller specifically.
That it works using the ExpressCard34 based controller on my laptop makes it
extra odd (but I guess the underlying driver is handling this
differently due to the PCI bridge?).
Can you please send the full kernel log, with boot parameter
"firewire_ohci.debug=-1", for mainline v5.4.91 vs. v5.4.91-rt50?
Please also make sure to use the exact same defconfig for both, except
with CONFIG_PREEMPT_RT=y for the -rt kenrel of course.
This will help in comparing apples to apples, as you were posting the
results of different base kernels (vs. the -rt versions), and different
defconfigs (vs. -rt) within such kernels.
Good luck,
P.S. Since this maybe is a timing issue, and ohci bus reset handling
occurs at SCHED_OTHER workqueu context, were you by any chance running
unreasonably-intensive realtime workloads by the time the driver was
loaded?
Thanks,
--
Ahmed S. Darwish
From: David Runge <hidden> Date: 2021-01-28 21:42:41
On 2021-01-28 07:28:35 (+0100), Ahmed S. Darwish wrote:
On Sat, Jan 23, 2021 at 12:59:29PM +0100, David Runge wrote:
...
Can you please send the full kernel log, with boot parameter
"firewire_ohci.debug=-1", for mainline v5.4.91 vs. v5.4.91-rt50?
This will help in comparing apples to apples, as you were posting the
results of different base kernels (vs. the -rt versions), and different
defconfigs (vs. -rt) within such kernels.
The configuration for the 5.4.91 stock kernel has not been updated since
the 5.4.83, which is maybe a bit misleading.
Generally I enable anything that I can in the config for the realtime
kernel. However, some settings of course get switched off, as they are
not compatible.
The diff above is for a custom version I just made, just to make sure
and clear things out.
Good luck,
Thanks, seems it's needed!
P.S. Since this maybe is a timing issue, and ohci bus reset handling
occurs at SCHED_OTHER workqueu context, were you by any chance running
unreasonably-intensive realtime workloads by the time the driver was
loaded?
Not that I am aware of. The driver neither initializes the device during
boot nor when later reloading.
There are no intense services running. The system is fairly
multi-purpose, so most things are started on demand.
Thanks!
David
--
https://sleepmap.de
I don't see anything wrong. There is small difference in timing and then
the RT version does not do a thing while !RT keeps reseting…
Could you try non-RT with the
threadirqs
option?
Sebastian
From: David Runge <hidden> Date: 2021-01-30 11:46:51
On 2021-01-29 18:04:14 (+0100), Sebastian Andrzej Siewior wrote:
I don't see anything wrong. There is small difference in timing and
then the RT version does not do a thing while !RT keeps reseting…
Could you try non-RT with the
threadirqs
option?
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2021-02-01 08:35:37
+ firewire maintainer
On 2021-01-30 12:46:04 [+0100], David Runge wrote:
On 2021-01-29 18:04:14 (+0100), Sebastian Andrzej Siewior wrote:
quoted
I don't see anything wrong. There is small difference in timing and
then the RT version does not do a thing while !RT keeps reseting…
Could you try non-RT with the
threadirqs
option?
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2021-02-05 11:30:58
On 2021-02-01 09:34:41 [+0100], To David Runge wrote:
+ firewire maintainer
On 2021-01-30 12:46:04 [+0100], David Runge wrote:
quoted
On 2021-01-29 18:04:14 (+0100), Sebastian Andrzej Siewior wrote:
quoted
I don't see anything wrong. There is small difference in timing and
then the RT version does not do a thing while !RT keeps reseting…
Could you try non-RT with the
threadirqs
option?
From: David Runge <hidden> Date: 2021-02-06 03:09:57
On 2021-02-05 12:26:38 (+0100), Sebastian Andrzej Siewior wrote:
On 2021-02-01 09:34:41 [+0100], To David Runge wrote:
quoted
+ firewire maintainer
On 2021-01-30 12:46:04 [+0100], David Runge wrote:
quoted
On 2021-01-29 18:04:14 (+0100), Sebastian Andrzej Siewior wrote:
quoted
I don't see anything wrong. There is small difference in timing and
then the RT version does not do a thing while !RT keeps reseting…
Could you try non-RT with the
threadirqs
option?
Could be specific to the chip or the ohci driver. Either way, the problem
are the threaded interrupts.
David, could you please try a v5.10 kernel with threadirqs? I've been
just told that it works there on a ppc64 box.
I have now tried with our vanilla 5.10.13 kernel, as I have issues
getting 5.10.12-rt26 to boot at all on my machine (will try to
investigate that tomorrow).
On 5.10.13 with threadirqs the controller is indeed initialized again
(/dev/fw0 appears).
However, no connected device is detected (i.e. /dev/fw1 does not
appear).
Here are the kernel logs with "firewire-ohci debug=-1":
https://pkgbuild.com/~dvzrv/bugs/2021/01/linux-5.10.13.arch1_threadirqs-kernel.log
Thanks for the follow-up!
Best,
David
--
https://sleepmap.de
From: David Runge <hidden> Date: 2021-02-07 09:59:30
On 2021-02-06 00:22:12 (+0100), David Runge wrote:
On 2021-02-05 12:26:38 (+0100), Sebastian Andrzej Siewior wrote:
quoted
On 2021-02-01 09:34:41 [+0100], To David Runge wrote:
quoted
+ firewire maintainer
On 2021-01-30 12:46:04 [+0100], David Runge wrote:
quoted
On 2021-01-29 18:04:14 (+0100), Sebastian Andrzej Siewior wrote:
quoted
I don't see anything wrong. There is small difference in timing and
then the RT version does not do a thing while !RT keeps reseting…
Could you try non-RT with the
threadirqs
option?
Could be specific to the chip or the ohci driver. Either way, the problem
are the threaded interrupts.
David, could you please try a v5.10 kernel with threadirqs? I've been
just told that it works there on a ppc64 box.
I have now tried with our vanilla 5.10.13 kernel, as I have issues
getting 5.10.12-rt26 to boot at all on my machine (will try to
investigate that tomorrow).
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2021-02-18 08:41:41
On 2021-02-14 20:16:02 [+0100], David Runge wrote:
The current config can be found on the AUR [1].
So this did make a difference. John concluded that it might be related
to the RESET quirk your hardware is having and his does not.
Could you try the patch below? Everything related to canceling tasklets
is broken so it is nothing logterm. It is just to figure out if your
hardware initializes further than it does right now.
------->8-------
Subject: [PATCH] firewire: threaded interrupts
Canceling tasklets is broken.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/firewire/ohci.c | 103 ++++++++++++++++++++++++++++------------
1 file changed, 73 insertions(+), 30 deletions(-)
From: David Runge <hidden> Date: 2021-03-10 18:16:30
On 2021-03-08 15:12:10 (+0100), Sebastian Andrzej Siewior wrote:
On 2021-02-18 10:27:51 [+0100], To David Runge wrote:
quoted
On 2021-02-18 09:38:49 [+0100], To David Runge wrote:
quoted
On 2021-02-14 20:16:02 [+0100], David Runge wrote:
quoted
The current config can be found on the AUR [1].
So this did make a difference.
made _no_ difference. Sorry for the confusion.
David, did you had a chance to test the patch?
Hey Sebastian,
sorry for the long delay! I got busy with other packaging/
infrastructure things and nearly forgot about this one.
I have now tested with 5.11.2-rt9 with and without your proposed patch.
Without the patch [1], the behavior is as before, only the parent device
node of the controller (/dev/fw0) is created, but the attached audio
interface is not recognized.
With the patch applied [2], things get a little more exciting, as now
both the parent and the child node are created (so both /dev/fw0 and
/dev/fw1 show up).
However, starting jackd on the interface leads to a zombification of the
jackd process and the process never exits:
From: David Runge <hidden> Date: 2021-09-07 23:25:05
Hi all,
As a follow-up to the previous conversation, I have now also tried
5.14.1-rt19 (packaged as 5.14.1.19.realtime1) in the hopes that ALSA
driver improvements for my Fireface800 will allow me to use pipewire
going forward.
Unfortunately, firewire-ohci and/or firewire-core are still freezing
upon trying to make use of the connected device which is connected with
the card using the chip in question (see title).
Upon first boot the /dev/fw0 and /dev/fw1 nodes did not show up
initially [1] (log without using -1 debug parameter), which is why I
switched the device off and on again.
Afterwards the device nodes were created, so I attempted to use aplay -l
to check whether the device was detected. The command hung forever (also
starting jackd) and I had to reboot eventually. Using alsamixer I was
able to select the Fireface800 device from the list of devices though.
Upon 2nd boot I used the -1 debug parameter for firewire-ohci [2].
The device nodes were created automatically, but neither aplay -l nor
alsamixer showed the audio interface. The attempt to switch the device
off and on again and afterwards to remove the firewire-ohci module lead
to another freeze and a successive reboot.
If I can provide further information, please let me know!
I hope I can try the vanilla 5.14.1 kernel tomorrow to see how it
behaves in regards to firewire-ohci (judging from the past it will
probably work though).
Best,
David
P.S.: I have added Kristian Hoegsberg in CC, who is mentioned as the
author of firewire-ohci and firewire-core.
[1] https://pkgbuild.com/~dvzrv/bugs/2021/09/linux-5.14.1.19.realtime1-kernel.log
[2] https://pkgbuild.com/~dvzrv/bugs/2021/09/linux-5.14.1.19.realtime1-restart_device_kernel.log
--
https://sleepmap.de
Hi,
On Wed, Sep 08, 2021 at 01:17:02AM +0200, David Runge wrote:
Upon first boot the /dev/fw0 and /dev/fw1 nodes did not show up
initially [1] (log without using -1 debug parameter), which is why I
switched the device off and on again.
Afterwards the device nodes were created, so I attempted to use aplay -l
to check whether the device was detected. The command hung forever (also
starting jackd) and I had to reboot eventually. Using alsamixer I was
able to select the Fireface800 device from the list of devices though.
Upon 2nd boot I used the -1 debug parameter for firewire-ohci [2].
The device nodes were created automatically, but neither aplay -l nor
alsamixer showed the audio interface. The attempt to switch the device
off and on again and afterwards to remove the firewire-ohci module lead
to another freeze and a successive reboot.
If I can provide further information, please let me know!
I hope I can try the vanilla 5.14.1 kernel tomorrow to see how it
behaves in regards to firewire-ohci (judging from the past it will
probably work though).
Best,
David
P.S.: I have added Kristian Hoegsberg in CC, who is mentioned as the
author of firewire-ohci and firewire-core.
[1] https://pkgbuild.com/~dvzrv/bugs/2021/09/linux-5.14.1.19.realtime1-kernel.log
[2] https://pkgbuild.com/~dvzrv/bugs/2021/09/linux-5.14.1.19.realtime1-restart_device_kernel.log
According to the log, the task of 'pipewire-media-:2554' is blocked during
122 seconds by call of 'wait_for_completion()' in code of
'fw_run_transaction()'. This is odd in two points of transaction service
programmed in Linux FireWire subsystem:
1. The process context should be awakened by softIRQ context, which should
be scheduled by hwIRQ context for hardware interrupt of OHCI 1394
controller.
2. Even if the softIRQ context is not invoked, the process context
should be awakened by wheel timer context, which is scheduled to finish
the transaction several jiffies later (originally prepared for the case
of split-transaction). In the case, the result of transaction is
'RCODE_CANCELLED'.
The call graph is below:
1 in the process context:
I guess we have issue in the softIRQ context or timer wheel context
instead of hwIRQ context, if the OHCI 1394 controller you use has
no quirk (I suggest you to give information about the controller).
I'd like you to check it. The firewire-ohci module has 'debug' parameter.
``
$ modinfo firewire-ohci
...
parm: debug:Verbose logging (default = 0, AT/AR events = 1, self-IDs = 2, IRQs = 4, busReset events = 8, or a combination, or all = -1) (int)
``
When the parameter has value '5' (= 1 | 4), we can see information per
transaction, like:
The first line: in hwIRQ context for request subaction
The second line: in softIRQ context scheduled by the above.
The third line: in hwIRQ context for response subaction
The fourth line: in softIRQ context scheduled by the above.
If we have any issue in invocation of softIRQ, we would often see
missing swIRQ logs (and it might be the most concern to RT Linux
developers).
If you need instruction to configure module parameters, 'man modprobe.d'
may be a good help.
Thanks
Takashi Sakamoto
From: David Runge <hidden> Date: 2021-09-08 17:30:21
Hi Takashi,
thanks for the prompt and detailed response!
Unfortunately I lack the knowledge about the driver and its inner
workings to be able to provide a patch for this issue myself.
If anyone reading this who is able to suggest a fix, I'd be happy to
test it!
On 2021-09-08 11:17:18 (+0900), Takashi Sakamoto wrote:
I guess we have issue in the softIRQ context or timer wheel context
instead of hwIRQ context, if the OHCI 1394 controller you use has
no quirk (I suggest you to give information about the controller).
I'd like you to check it. The firewire-ohci module has 'debug' parameter.
``
$ modinfo firewire-ohci
...
parm: debug:Verbose logging (default = 0, AT/AR events = 1, self-IDs = 2, IRQs = 4, busReset events = 8, or a combination, or all = -1) (int)
``
I am using '-1' (all) in the 2nd link in my previous mail. It appears to
not show a different output in the kernel logs from when I set it to '5'
though. There seems to be something wrong...
I'm adding the options in a .conf file below /etc/modprobe.d/, e.g.:
On Wed, Sep 08, 2021 at 07:30:14PM +0200, David Runge wrote:
I am using '-1' (all) in the 2nd link in my previous mail. It appears to
not show a different output in the kernel logs from when I set it to '5'
though. There seems to be something wrong...
I'm adding the options in a .conf file below /etc/modprobe.d/, e.g.:
Before printing 'created device fw1', Linux FireWire subsystem already
initiates asynchronous transactions to retrieve content of configuration
ROM located in 0x'ffff'f000'0400 of node address space. If you can see
no transaction record but see the print, it means to fail configuration
of the parameter of firewire-ohci module.
I think your system uses initramfs. Any node for storage function in
IEEE 1394 bus is available as initial boot disk, thus it's reasonable
that the designer of your initramfs puts firewire-ohci/firewire-core
modules into it. In the case, we can not configure module by
'/etc/modprobe.d/*' since the modules are already loaded before mounting
root file system.
I think the design of initramfs differs depending on distribution, thus
you need to find instruction for the way to configure module parameter
by yourself.
Instead, I suggest you to configure the module via sysfs after booting,
like:
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2021-09-10 11:55:45
On 2021-09-08 11:17:18 [+0900], Takashi Sakamoto wrote:
Hi,
Hi,
According to the log, the task of 'pipewire-media-:2554' is blocked during
122 seconds by call of 'wait_for_completion()' in code of
'fw_run_transaction()'. This is odd in two points of transaction service
programmed in Linux FireWire subsystem:
1. The process context should be awakened by softIRQ context, which should
be scheduled by hwIRQ context for hardware interrupt of OHCI 1394
controller.
2. Even if the softIRQ context is not invoked, the process context
should be awakened by wheel timer context, which is scheduled to finish
the transaction several jiffies later (originally prepared for the case
of split-transaction). In the case, the result of transaction is
'RCODE_CANCELLED'.
Side note: David is using PREEMPT_RT and his problem can be reduced to
plain vanilla with `threadirqs' boot option. Back in February I sent him
a patch [0] which inlines the tasklet job as I assumed it is not good
reset the IRQ-event in the tasklet/workqueue. It seemed to improve the
situtation as it recognized the device attached to the bus but ended
then in the same timeout behaviour as now.
[0] https://https://lkml.kernel.org/r/.kernel.org/all/20210218083849.iitcrhdgv2oajfhv@linutronix.de/
Hi,
On Fri, Sep 10, 2021 at 01:55:41PM +0200, Sebastian Andrzej Siewior wrote:
On 2021-09-08 11:17:18 [+0900], Takashi Sakamoto wrote:
quoted
Hi,
Hi,
quoted
According to the log, the task of 'pipewire-media-:2554' is blocked during
122 seconds by call of 'wait_for_completion()' in code of
'fw_run_transaction()'. This is odd in two points of transaction service
programmed in Linux FireWire subsystem:
1. The process context should be awakened by softIRQ context, which should
be scheduled by hwIRQ context for hardware interrupt of OHCI 1394
controller.
2. Even if the softIRQ context is not invoked, the process context
should be awakened by wheel timer context, which is scheduled to finish
the transaction several jiffies later (originally prepared for the case
of split-transaction). In the case, the result of transaction is
'RCODE_CANCELLED'.
Side note: David is using PREEMPT_RT and his problem can be reduced to
plain vanilla with `threadirqs' boot option. Back in February I sent him
a patch [0] which inlines the tasklet job as I assumed it is not good
reset the IRQ-event in the tasklet/workqueue. It seemed to improve the
situtation as it recognized the device attached to the bus but ended
then in the same timeout behaviour as now.
[0] https://https://lkml.kernel.org/r/.kernel.org/all/20210218083849.iitcrhdgv2oajfhv@linutronix.de/
Thanks for the side note, and I apologize to follow the thread partially,
not entire.
Furthermore, I'd like to correct my misunderstanding about the 2nd point
since the timer wheel context is scheduled only when the peer of
transaction transfer ack_pending for the request subaction. Without the
hwIRQ context, the task is blocked ever anyway.
Regards
Takashi Sakamoto
From: David Runge <hidden> Date: 2021-09-12 18:45:00
On 2021-09-09 09:46:06 (+0900), Takashi Sakamoto wrote:
On Wed, Sep 08, 2021 at 07:30:14PM +0200, David Runge wrote:
quoted
I am using '-1' (all) in the 2nd link in my previous mail. It appears to
not show a different output in the kernel logs from when I set it to '5'
though. There seems to be something wrong...
I'm adding the options in a .conf file below /etc/modprobe.d/, e.g.:
Before printing 'created device fw1', Linux FireWire subsystem already
initiates asynchronous transactions to retrieve content of configuration
ROM located in 0x'ffff'f000'0400 of node address space. If you can see
no transaction record but see the print, it means to fail configuration
of the parameter of firewire-ohci module.
I think your system uses initramfs. Any node for storage function in
IEEE 1394 bus is available as initial boot disk, thus it's reasonable
that the designer of your initramfs puts firewire-ohci/firewire-core
modules into it. In the case, we can not configure module by
'/etc/modprobe.d/*' since the modules are already loaded before mounting
root file system.
I think the design of initramfs differs depending on distribution, thus
you need to find instruction for the way to configure module parameter
by yourself.
Instead, I suggest you to configure the module via sysfs after booting,
like:
I have played around with adding the configuration and the module
explicitly to the initramfs (we're using mkinitcpio on Arch Linux).
However, this did not change anything in the output provided by
journalctl [1].
A boot with the vanilla 5.14.2 (no threadirqs) and debug=-1 set for
firewire-ohci logs everything successfully [2].
My assumption is that the debug parameter is either not considered or
the module hangs far before there's any further output when on linux-rt.
Unrelated sidenote: I am currently booted into vanilla 5.14.2 (no
threadirqs) and the device works well using pipewire and the ALSA driver
snd-fireface.
Good job to everyone involved! I'm very happy about the results! \o/
Best,
David
[1] https://pkgbuild.com/~dvzrv/bugs/2021/09/linux-5.14.1.19.realtime1-firewire-ohci-debug--1-initramfs-kernel.log
[2] https://pkgbuild.com/~dvzrv/bugs/2021/09/linux-5.14.2.arch1-firewire-ohci-debug--1-initramfs-kernel.log
--
https://sleepmap.de
From: David Runge <hidden> Date: 2021-09-12 18:53:54
On 2021-09-11 18:46:57 (+0900), Takashi Sakamoto wrote:
Hi,
On Fri, Sep 10, 2021 at 01:55:41PM +0200, Sebastian Andrzej Siewior wrote:
quoted
On 2021-09-08 11:17:18 [+0900], Takashi Sakamoto wrote:
quoted
Hi,
Hi,
quoted
According to the log, the task of 'pipewire-media-:2554' is blocked during
122 seconds by call of 'wait_for_completion()' in code of
'fw_run_transaction()'. This is odd in two points of transaction service
programmed in Linux FireWire subsystem:
1. The process context should be awakened by softIRQ context, which should
be scheduled by hwIRQ context for hardware interrupt of OHCI 1394
controller.
2. Even if the softIRQ context is not invoked, the process context
should be awakened by wheel timer context, which is scheduled to finish
the transaction several jiffies later (originally prepared for the case
of split-transaction). In the case, the result of transaction is
'RCODE_CANCELLED'.
Side note: David is using PREEMPT_RT and his problem can be reduced to
plain vanilla with `threadirqs' boot option. Back in February I sent him
a patch [0] which inlines the tasklet job as I assumed it is not good
reset the IRQ-event in the tasklet/workqueue. It seemed to improve the
situtation as it recognized the device attached to the bus but ended
then in the same timeout behaviour as now.
[0] https://https://lkml.kernel.org/r/.kernel.org/all/20210218083849.iitcrhdgv2oajfhv@linutronix.de/
Thanks for the side note, and I apologize to follow the thread partially,
not entire.
Furthermore, I'd like to correct my misunderstanding about the 2nd point
since the timer wheel context is scheduled only when the peer of
transaction transfer ack_pending for the request subaction. Without the
hwIRQ context, the task is blocked ever anyway.
Thanks at any rate to look into this! It is much appreciated!
Is there anything further I can try to debug this using threadirqs? It
would be really amazing to be able to use this device on PREEMPT_RT
again (especially given that now the ALSA driver has improved so
drastically). :)
Best,
David
--
https://sleepmap.de
Thanks at any rate to look into this! It is much appreciated!
Is there anything further I can try to debug this using threadirqs? It
would be really amazing to be able to use this device on PREEMPT_RT
again (especially given that now the ALSA driver has improved so
drastically). :)
Best,
David
Hi,
since a processor and BIOS update I ran into the same problems as David.
* former processor alt: AMD Ryzen 2 0600X 6-Core
* new processor neu: AMD Ryzen 7 3700X 8-Core Processor
* kernel (Ubuntu): 5.4.0-91-lowlatency #102-Ubuntu SMP PREEMPT Fri Nov 5
18:18:39 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
* chipset: AMD B450
* firewire card:
05: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: bus master, 66MHz, medium devsel, latency 32, IRQ 36
Memory at fc204000 (32-bit, non-prefetchable) [size=2K]
Memory at fc200000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 3
Kernel modules: firewire_ohci
I did not change the kernel version - it worked before upgrading the
processor and BIOS with the same kernel!
Now jack or alternatively "ffado-test Discover" immediately get
zombified when I try to start them.
In addition to Davids findings a can add the following:
Under some weird circumstances I got the card to work (once immediately
after loading BIOS to defaults and three times after an unsuccessful try
to downgrade the BIOS).
Appended are two dmesg outputs one in which the card is initialized
correctly [1], one in which the card did not work [2].
Another finding was, that after the driver was trying some time to read
the config ROM, it gave up and, did a bus reset and everything was fine [3].
I just have build the kernel modules with some mor debugging output. So
if there's something I should try, just give me intructions ;-)
Holger
[1]
https://cloud.dehnhardt.org/s/Z7jwqT9y3x6JgbE
[2]
https://cloud.dehnhardt.org/s/GAm2MjSqdbYDcod
[3]
[Mo Jan 3 18:41:53 2022] firewire_ohci 0000:05:00.0: added OHCI v1.10
device as card 0, 8 IR + 8 IT contexts, quirks 0x2
[Mo Jan 3 18:41:53 2022] firewire_core 0000:05:00.0: created device fw0:
GUID 7856341278563412, S800
[Mo Jan 3 18:41:53 2022] firewire_core 0000:05:00.0: phy config: new
root=ffc1, gap_count=5
[Mo Jan 3 18:45:59 2022] Workqueue: firewire fw_device_workfn
[firewire_core]
[Mo Jan 3 18:45:59 2022] fw_run_transaction+0xdc/0x110 [firewire_core]
[Mo Jan 3 18:45:59 2022] ? fw_core_handle_bus_reset+0x440/0x440
[firewire_core]
[Mo Jan 3 18:45:59 2022] ? close_transaction+0x110/0x110 [firewire_core]
[Mo Jan 3 18:45:59 2022] ? transmit_phy_packet_callback+0x20/0x20
[firewire_core]
[Mo Jan 3 18:45:59 2022] read_rom+0x5e/0xa0 [firewire_core]
[Mo Jan 3 18:45:59 2022] read_config_rom+0x8b/0x3d0 [firewire_core]
[Mo Jan 3 18:45:59 2022] fw_device_init+0x35/0x320 [firewire_core]
[Mo Jan 3 18:45:59 2022] fw_device_workfn+0x12/0x20 [firewire_core]
[snip...]
[Mo Jan 3 19:04:25 2022] Workqueue: firewire fw_device_workfn
[firewire_core]
[Mo Jan 3 19:04:25 2022] fw_run_transaction+0xdc/0x110 [firewire_core]
[Mo Jan 3 19:04:25 2022] ? fw_core_handle_bus_reset+0x440/0x440
[firewire_core]
[Mo Jan 3 19:04:25 2022] ? close_transaction+0x110/0x110 [firewire_core]
[Mo Jan 3 19:04:25 2022] ? transmit_phy_packet_callback+0x20/0x20
[firewire_core]
[Mo Jan 3 19:04:25 2022] read_rom+0x5e/0xa0 [firewire_core]
[Mo Jan 3 19:04:25 2022] read_config_rom+0x8b/0x3d0 [firewire_core]
[Mo Jan 3 19:04:25 2022] fw_device_init+0x35/0x320 [firewire_core]
[Mo Jan 3 19:04:25 2022] fw_device_workfn+0x12/0x20 [firewire_core]
[Mo Jan 3 21:03:50 2022] firewire_core 0000:05:00.0: giving up on node
ffc0: reading config rom failed: bus reset
[Mo Jan 3 21:03:51 2022] firewire_core 0000:05:00.0: rediscovered device fw0
[Mo Jan 3 21:03:56 2022] firewire_core 0000:05:00.0: rediscovered device fw0
[Mo Jan 3 21:03:56 2022] firewire_core 0000:05:00.0: phy config: new
root=ffc1, gap_count=5
[Mo Jan 3 21:04:01 2022] firewire_core 0000:05:00.0: created device fw1:
GUID 000ff20400001d98, S400