Hi Linus,
Please pull firewire updates for v6.5-rc1.
The following changes since commit 44c026a73be8038f03dbdeef028b642880cf1511:
Linux 6.4-rc3 (2023-05-21 14:05:48 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git tags/firewire-6.5-rc1
for you to fetch changes up to 3ff256751a2853e1ffaa36958ff933ccc98c6cb5:
firewire: net: fix use after free in fwnet_finish_incoming_packet() (2023-06-24 14:03:46 +0900)
----------------------------------------------------------------
firewire updates for 6.5-rc1
The updates consist of three parts; UAPI update, OHCI driver update, and
several bug fixes.
Firstly, the 1394 OHCI specification defines method to retrieve hardware
time stamps for asynchronous communication, which was previously
unavailable in user space. This change adds new events to the UAPI,
allowing applications to retrieve the time when asynchronous packet are
received and sent. The new events are tested in the breeding edge of
libhinawa and look to work well. The new version of libhinawa will be
released after current merge window is closed.
* https://git.kernel.org/pub/scm/libs/ieee1394/libhinawa.git/
Secondly, the FireWire stack includes a PCM device driver for 1394 OHCI
hardware, This change modernizes the driver by managed resource (devres)
framework.
Lastly, the rest of change is bug fixes for firewire-net and firewire-core.
----------------------------------------------------------------
Takashi Sakamoto (24):
firewire: add KUnit test to check layout of UAPI structures
firewire: cdev: add new version of ABI to notify time stamp at request/response subaction of transaction
firewire: cdev: add new event to notify request subaction with time stamp
firewire: cdev: implement new event to notify request subaction with time stamp
firewire: core: use union for callback of transaction completion
firewire: core: implement variations to send request and wait for response with time stamp
firewire: cdev: code refactoring to operate event of response
firewire: cdev: add new event to notify response subaction with time stamp
firewire: cdev: implement new event to notify response subaction with time stamp
firewire: cdev: code refactoring to dispatch event for phy packet
firewire: cdev: add new event to notify phy packet with time stamp
firewire: cdev: implement new event relevant to phy packet with time stamp
firewire: fix build failure due to missing module license
firewire: fix warnings to generate UAPI documentation
firewire: ohci: use devres for memory object of ohci structure
firewire: ohci: use devres for PCI-related resources
firewire: ohci: use devres for MMIO region mapping
firewire: ohci: use devres for misc DMA buffer
firewire: ohci: use devres for requested IRQ
firewire: ohci: use devres for list of isochronous contexts
firewire: ohci: use devres for IT, IR, AT/receive, and AT/request contexts
firewire: ohci: use devres for content of configuration ROM
firewire: ohci: release buffer for AR req/resp contexts when managed resource is released
firewire: core: obsolete usage of GFP_ATOMIC at building node tree
Zhang Shurong (1):
firewire: net: fix use after free in fwnet_finish_incoming_packet()
drivers/firewire/.kunitconfig | 4 +
drivers/firewire/Kconfig | 16 +++
drivers/firewire/Makefile | 3 +
drivers/firewire/core-cdev.c | 252 +++++++++++++++++++++++++++---------
drivers/firewire/core-device.c | 2 +-
drivers/firewire/core-topology.c | 2 +-
drivers/firewire/core-transaction.c | 93 +++++++++----
drivers/firewire/core.h | 7 +
drivers/firewire/net.c | 6 +-
drivers/firewire/ohci.c | 191 +++++++++++----------------
drivers/firewire/uapi-test.c | 89 +++++++++++++
include/linux/firewire.h | 82 +++++++++++-
include/uapi/linux/firewire-cdev.h | 178 +++++++++++++++++++++----
13 files changed, 694 insertions(+), 231 deletions(-)
create mode 100644 drivers/firewire/.kunitconfig
create mode 100644 drivers/firewire/uapi-test.c
The pull request you sent on Tue, 4 Jul 2023 21:18:47 +0900:
> git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git tags/firewire-6.5-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/406fb9eb198a05fa61c31ec8a6e667c8440749c8
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
Hi,
On 04. 07. 23, 14:18, Takashi Sakamoto wrote:
> Please pull firewire updates for v6.5-rc1.
>
> The following changes since commit 44c026a73be8038f03dbdeef028b642880cf1511:
>
> Linux 6.4-rc3 (2023-05-21 14:05:48 -0700)
Likely some of the below commits causes an instant reboot during boot as
was reported in:
https://bugzilla.suse.com/show_bug.cgi?id=1215436
6.4.* was fine, 6.5.4 or 6.6-rc1 fails.
module_blacklist=firewire_ohci fixes the issue on 6.5.4.
Any ideas what can cause this? I fail to see an issue in the commits...
FWIW I see "obsolete usage of GFP_ATOMIC" was reverted in 6.5.5 and
6.6-rc2, I asked the reporter to test those.
> Takashi Sakamoto (24):
> firewire: add KUnit test to check layout of UAPI structures
> firewire: cdev: add new version of ABI to notify time stamp at request/response subaction of transaction
> firewire: cdev: add new event to notify request subaction with time stamp
> firewire: cdev: implement new event to notify request subaction with time stamp
> firewire: core: use union for callback of transaction completion
> firewire: core: implement variations to send request and wait for response with time stamp
> firewire: cdev: code refactoring to operate event of response
> firewire: cdev: add new event to notify response subaction with time stamp
> firewire: cdev: implement new event to notify response subaction with time stamp
> firewire: cdev: code refactoring to dispatch event for phy packet
> firewire: cdev: add new event to notify phy packet with time stamp
> firewire: cdev: implement new event relevant to phy packet with time stamp
> firewire: fix build failure due to missing module license
> firewire: fix warnings to generate UAPI documentation
> firewire: ohci: use devres for memory object of ohci structure
> firewire: ohci: use devres for PCI-related resources
> firewire: ohci: use devres for MMIO region mapping
> firewire: ohci: use devres for misc DMA buffer
> firewire: ohci: use devres for requested IRQ
> firewire: ohci: use devres for list of isochronous contexts
> firewire: ohci: use devres for IT, IR, AT/receive, and AT/request contexts
> firewire: ohci: use devres for content of configuration ROM
> firewire: ohci: release buffer for AR req/resp contexts when managed resource is released
> firewire: core: obsolete usage of GFP_ATOMIC at building node tree
>
> Zhang Shurong (1):
> firewire: net: fix use after free in fwnet_finish_incoming_packet()
thanks,
--
js
suse labs
Hi,
Thanks for your report, and I apologize to trouble you and your
reporter.
On Tue, Sep 26, 2023 at 11:11:23AM +0200, Jiri Slaby wrote:
> Hi,
>
> On 04. 07. 23, 14:18, Takashi Sakamoto wrote:
> > Please pull firewire updates for v6.5-rc1.
> >
> > The following changes since commit 44c026a73be8038f03dbdeef028b642880cf1511:
> >
> > Linux 6.4-rc3 (2023-05-21 14:05:48 -0700)
>
> Likely some of the below commits causes an instant reboot during boot as was
> reported in:
> https://bugzilla.suse.com/show_bug.cgi?id=1215436
>
> 6.4.* was fine, 6.5.4 or 6.6-rc1 fails.
>
> module_blacklist=firewire_ohci fixes the issue on 6.5.4.
>
> Any ideas what can cause this? I fail to see an issue in the commits...
In my opinion, the series of patches to optimize 1394 OHCI driver to
devicves managed resources would bring the issue in the environmennt,
therefore:
> FWIW I see "obsolete usage of GFP_ATOMIC" was reverted in 6.5.5 and 6.6-rc2,
> I asked the reporter to test those.
>
> > Takashi Sakamoto (24):
> > firewire: add KUnit test to check layout of UAPI structures
> > firewire: cdev: add new version of ABI to notify time stamp at request/response subaction of transaction
> > firewire: cdev: add new event to notify request subaction with time stamp
> > firewire: cdev: implement new event to notify request subaction with time stamp
> > firewire: core: use union for callback of transaction completion
> > firewire: core: implement variations to send request and wait for response with time stamp
> > firewire: cdev: code refactoring to operate event of response
> > firewire: cdev: add new event to notify response subaction with time stamp
> > firewire: cdev: implement new event to notify response subaction with time stamp
> > firewire: cdev: code refactoring to dispatch event for phy packet
> > firewire: cdev: add new event to notify phy packet with time stamp
> > firewire: cdev: implement new event relevant to phy packet with time stamp
> > firewire: fix build failure due to missing module license
> > firewire: fix warnings to generate UAPI documentation
here
> > firewire: ohci: use devres for memory object of ohci structure
> > firewire: ohci: use devres for PCI-related resources
> > firewire: ohci: use devres for MMIO region mapping
> > firewire: ohci: use devres for misc DMA buffer
> > firewire: ohci: use devres for requested IRQ
> > firewire: ohci: use devres for list of isochronous contexts
> > firewire: ohci: use devres for IT, IR, AT/receive, and AT/request contexts
> > firewire: ohci: use devres for content of configuration ROM
> > firewire: ohci: release buffer for AR req/resp contexts when managed resource is released
to here.
> > firewire: core: obsolete usage of GFP_ATOMIC at building node tree
> >
> > Zhang Shurong (1):
> > firewire: net: fix use after free in fwnet_finish_incoming_packet()
>
> thanks,
> --
> js
> suse labs
Although, usage of device managed resource is itself preferable, thus I
would like you to help me to fix the issue. I test these patches in v6.2
kernel by module backporting and I have no issue in my environment. For
example, with 'acpi=noirq':
```
kernel: firewire_ohci 0000:0b:00.0: enabling device (0000 -> 0002)
kernel: firewire_ohci 0000:0b:00.0: using bridge 0000:03:00.2 INT D to get INT A
kernel: firewire_ohci 0000:0b:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x2
kernel: firewire_core 0000:0b:00.0: created device fw0: GUID 080028510100014a, S800
```
But in the reporter's environment:
```
kernel: firewire_ohci 0000:22:00.0: enabling device (0080 -> 0083)
kernel: firewire_ohci 0000:22:00.0: can't find IRQ for PCI INT A; please try using pci=biosirq
kernel: genirq: Flags mismatch irq 0. 00000080 (firewire_ohci) vs. 00015a00 (timer)
kernel: firewire_ohci 0000:22:00.0: failed to allocate interrupt 0
kernel: firewire_ohci: probe of 0000:22:00.0 failed with error -16
kernel: firewire_ohci 0000:22:00.0: removed fw-ohci device
```
For my information, would you please ask your reporter to tell what kind
of 1394 OHCI hardware to use? Once the Linux system booted, you can
retrieve information about it by lspci(8). My hardware includes
PCIe-to-PCI bridge as well as PCI-to-1394-bus bridge (1394 OHCI) and I
would like to check the reporter uses the similar hardware or not.
For example, in the market, we have direct PCIe-to-1394-bus bridge. It
appears that the reporter would uses the kind of hardware. If so, I
install the similar hardware in my system and check the patchset. Else,
I'll investigate the other causes; e.g. installing openSUSE Tumbleweed
to regenerate the issue.
Thanks
Takashi Sakamoto
Hi,
On 26. 09. 23, 16:09, Takashi Sakamoto wrote:
> But in the reporter's environment:
>
> ```
> kernel: firewire_ohci 0000:22:00.0: enabling device (0080 -> 0083)
> kernel: firewire_ohci 0000:22:00.0: can't find IRQ for PCI INT A; please try using pci=biosirq
> kernel: genirq: Flags mismatch irq 0. 00000080 (firewire_ohci) vs. 00015a00 (timer)
> kernel: firewire_ohci 0000:22:00.0: failed to allocate interrupt 0
> kernel: firewire_ohci: probe of 0000:22:00.0 failed with error -16
> kernel: firewire_ohci 0000:22:00.0: removed fw-ohci device
Ah, that's why the system boots with acpi=noirq. It simply won't allow
the ohci driver to bind the device due to apparently wrong IRQ
configuration in the PCI device.
You can ignore this error, IMO. ACPI tables have the IRQs setup right
and those should be used (ie. acpi=noirq was used only for testing).
Let's chase the real problem (follow the bug).
thanks,
--
js
suse labs
[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.
See link in footer if these mails annoy you.]
On 26.09.23 11:11, Jiri Slaby wrote:
>
> On 04. 07. 23, 14:18, Takashi Sakamoto wrote:
>> Please pull firewire updates for v6.5-rc1.
>>
>> The following changes since commit
>> 44c026a73be8038f03dbdeef028b642880cf1511:
>>
>> Linux 6.4-rc3 (2023-05-21 14:05:48 -0700)
>
> Likely some of the below commits causes an instant reboot during boot as
> was reported in:
> https://bugzilla.suse.com/show_bug.cgi?id=1215436
>
> 6.4.* was fine, 6.5.4 or 6.6-rc1 fails.
>
> module_blacklist=firewire_ohci fixes the issue on 6.5.4.
>
> Any ideas what can cause this? I fail to see an issue in the commits...
> [...]
Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:
#regzbot ^introduced v6.4..v6.5.3
https://bugzilla.suse.com/show_bug.cgi?id=1215436
#regzbot title firewire: instant reboot during boot
#regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.
Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (the parent of this mail). See page linked in footer for
details.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.
Hi Jiri,
Just now I installed openSUSE Tumbleweed, however I found no issue on my 1394 OHCI
hardware. I would like to ask your current opinion for the issue?
~> uname -r
6.5.4-1-default
~> cat /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20230929"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20230929"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20230929"
BUG_REPORT_URL="https://bugzilla.opensuse.org"
SUPPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed"
LOGO="distributor-logo-Tumbleweed"
->sudo lspci -v
...
01:00.0 PCI bridge: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI Bridge [Cheetah Express] (rev 01) (prog-if 00 [Normal decode])
Subsystem: Device 3412:7856
Flags: bus master, fast devsel, latency 0, IOMMU group 8
Memory at fce00000 (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: fcd00000-fcdfffff [size=1M] [32-bit]
Prefetchable memory behind bridge: [disabled] [64-bit]
Capabilities: [50] Power Management version 3
Capabilities: [60] MSI: Enable- Count=1/16 Maskable- 64bit+
Capabilities: [80] Subsystem: Device 3412:7856
Capabilities: [90] Express PCI-Express to PCI/PCI-X Bridge, MSI 00
Capabilities: [100] Advanced Error Reporting
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: bus master, 66MHz, medium devsel, latency 32, IRQ 39, IOMMU group 8
Memory at fcd04000 (32-bit, non-prefetchable) [size=2K]
Memory at fcd00000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 3
Kernel driver in use: firewire_ohci
Kernel modules: firewire_ohci
...
$ udevadm info -e
...
P: /devices/pci0000:00/0000:00:01.1/0000:01:00.0
M: 0000:01:00.0
R: 0
U: pci
E: DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0
E: SUBSYSTEM=pci
E: PCI_CLASS=60400
E: PCI_ID=104C:823E
E: PCI_SUBSYS_ID=3412:7856
E: PCI_SLOT_NAME=0000:01:00.0
E: MODALIAS=pci:v0000104Cd0000823Esv00003412sd00007856bc06sc04i00
E: USEC_INITIALIZED=11023840
E: ID_PCI_CLASS_FROM_DATABASE=Bridge
E: ID_PCI_SUBCLASS_FROM_DATABASE=PCI bridge
E: ID_PCI_INTERFACE_FROM_DATABASE=Normal decode
E: ID_VENDOR_FROM_DATABASE=Texas Instruments
E: ID_MODEL_FROM_DATABASE=XIO2213A/B/XIO2221 PCI Express to PCI Bridge [Cheetah Express]
E: ID_PATH=pci-0000:01:00.0
E: ID_PATH_TAG=pci-0000_01_00_0
P: /devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0
M: 0000:02:00.0
R: 0
U: pci
V: firewire_ohci
E: DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0
E: SUBSYSTEM=pci
E: DRIVER=firewire_ohci
E: PCI_CLASS=C0010
E: PCI_ID=104C:823F
E: PCI_SUBSYS_ID=3412:7856
E: PCI_SLOT_NAME=0000:02:00.0
E: MODALIAS=pci:v0000104Cd0000823Fsv00003412sd00007856bc0Csc00i10
E: USEC_INITIALIZED=11023930
E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=FireWire (IEEE 1394)
E: ID_PCI_INTERFACE_FROM_DATABASE=OHCI
E: ID_VENDOR_FROM_DATABASE=Texas Instruments
E: ID_MODEL_FROM_DATABASE=XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express]
E: ID_PATH=pci-0000:02:00.0
E: ID_PATH_TAG=pci-0000_02_00_0
P: /devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/fw0
M: fw0
R: 0
U: firewire
D: c 244:0
N: fw0
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/fw0
E: SUBSYSTEM=firewire
E: DEVNAME=/dev/fw0
E: MAJOR=244
E: MINOR=0
...
When I plugged in my sound device (Tascam Fireone) and load ALSA OXFW driver, it works as expected. It means that both 1394 Asynchronous/Isochronous communications are established as expected.
Regards
Takashi Sakamoto
On 01. 10. 23, 7:15, Takashi Sakamoto wrote:
> Just now I installed openSUSE Tumbleweed, however I found no issue on my 1394 OHCI
> hardware. I would like to ask your current opinion for the issue?
Hi,
let's wait for the result of bisection. ATM, the cause appears to be one of:
147e9d3af34a firewire: cdev: code refactoring to operate event of response
39ce342c3a4b firewire: core: implement variations to send request and
wait for response with time stamp
dcadfd7f7c74 firewire: core: use union for callback of transaction
completion
I don't see the problem in them immediately. Do you?
My current bet is the last one. But why the heck the machine resets
immediately?
thanks,
--
js
suse labs
Hi Jiri,
As long as seeing your recent conversation with your reporter, it looks
to be an issue specific to the reporter's 1394 OHCI hardware. I suspect
a quirk specific to it related to accessing to CYCLE_TIME register in
early time after powering on. It is the reason that I can regenerate the
issue in my set of hardware.
Would I ask you to request the reporter to inform the detail of
hardware? If possible, let the reporter open PC box and take some picture
of the hardware so that we can identify the ICs on the hardware?
Via pci.ids, we can see both 'ASM1083/1085' and 'VT6306/7/8' are used,
while I need to identify the IC to purchase an alternative so that I can
regenerate the issue.
Thanks
Takashi Sakamoto
On 04. 10. 23, 2:24, Takashi Sakamoto wrote:
> Hi Jiri,
>
> As long as seeing your recent conversation with your reporter, it looks
> to be an issue specific to the reporter's 1394 OHCI hardware. I suspect
> a quirk specific to it related to accessing to CYCLE_TIME register in
> early time after powering on. It is the reason that I can regenerate the
> issue in my set of hardware.
>
> Would I ask you to request the reporter to inform the detail of
> hardware? If possible, let the reporter open PC box and take some picture
> of the hardware so that we can identify the ICs on the hardware?
>
> Via pci.ids, we can see both 'ASM1083/1085' and 'VT6306/7/8' are used,
> while I need to identify the IC to purchase an alternative so that I can
> regenerate the issue.
Hi,
I asked him in the bug. Feel free to jump in -- no need to be afraid of
asking him directly.
I also asked him to test my last idea (I'm out of them ATM). I let
get_cycle_time() to early return 0.
From my previous attempt, it's funny that few initial calls to
get_cycle_time() succeeded. Only then it reboots. I have no idea why...
Do you have a suggestion for a patch to test your idea above (quirk to
avoid CYCLE_TIME reads early)?
thanks,
--
js
suse labs
Hi Jiri,
I purchased 1394 OHCI hardware quite similar to the issued hardware
(VIA VT6307 + Asmedia ASM1083), then experienced that it causes the
issue in AMD chipset, but it does not in Intel chipset.
I use below machines:
* AMD Ryzen 5 2400G in Gigabyte AX370-Gaming 5 rev.1.0 (Bios version F51h) [1]
* Intel Core i3-2120T in Intel DH77DF (Bios version 0112) [2]
As long as seeing filed issues, the reporters use AMD chipset.
AMD Ryzen 5 3400G, MSI B450-A Pro: https://bugzilla.suse.com/show_bug.cgi?id=1215436
AMD Ryzen 7 3700X, MSI X570-A Pro: https://bugzilla.redhat.com/show_bug.cgi?id=2240973
Furthermore, I experienced that:
* guest machine can cause host reboot in Ryzen machine even if the 1394
OHCI hardware is passed-through to the guest by vfio-pci (and
firewire-ohci is loaded in the guest machine side)
* execution of lspci(8) in the host can cause the reboot when the hardware
is associated to vfio-pci (thus firewire-ohci is not loaded in the case).
This issue is in Ubuntu 23.04 (v6.2 kernel).
At present, I suspect either or both iommu function and kernel
implementation.
For further investigation, I would like you to give some instructions
about the way to use OpenSUSE distribution. I want to boot the distribution
in 'low graphics mode' which debian/ubuntu distribution has. In the mode,
I expect to boot it without loading amdgpu module which depends on iommuv2
module.
Anyway, I would like you to check reporters' chipset when the similar
issues are reported. If they encounter the issue still in Intel chipset,
please inform it to me, since it could deny my current presumption.
[1] https://www.gigabyte.com/Motherboard/GA-AX370-Gaming-5-rev-10#kf
[2] https://www.intel.com/content/www/us/en/products/sku/59503/intel-desktop-board-dh77df/specifications.html
Thanks
Takashi Sakamoto
Hi,
On 16. 10. 23, 17:56, Takashi Sakamoto wrote:
> For further investigation, I would like you to give some instructions
> about the way to use OpenSUSE distribution. I want to boot the distribution
> in 'low graphics mode' which debian/ubuntu distribution has. In the mode,
> I expect to boot it without loading amdgpu module which depends on iommuv2
> module.
I think it translates to "nomodeset" kernel commandline option.
Or you can pass the hard module_blacklist=amdgpu or =iommu_v2 to the kernel.
> Anyway, I would like you to check reporters' chipset when the similar
> issues are reported. If they encounter the issue still in Intel chipset,
> please inform it to me, since it could deny my current presumption.
The reported appears to have an AMD 400 Series Chipset. So no intel.
thanks,
--
js
suse labs
On 27.09.23 15:15, Linux regression tracking #adding (Thorsten Leemhuis)
wrote:
> On 26.09.23 11:11, Jiri Slaby wrote:
>>
>> On 04. 07. 23, 14:18, Takashi Sakamoto wrote:
>>> Please pull firewire updates for v6.5-rc1.
>>>
>>> The following changes since commit
>>> 44c026a73be8038f03dbdeef028b642880cf1511:
>>>
>>> Linux 6.4-rc3 (2023-05-21 14:05:48 -0700)
>>
>> Likely some of the below commits causes an instant reboot during boot as
>> was reported in:
>> https://bugzilla.suse.com/show_bug.cgi?id=1215436
>>
>> 6.4.* was fine, 6.5.4 or 6.6-rc1 fails.
>>
>> module_blacklist=firewire_ohci fixes the issue on 6.5.4.
>>
>> Any ideas what can cause this? I fail to see an issue in the commits...
>> [...]
>
>
> Thanks for the report. To be sure the issue doesn't fall through the
> cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
> tracking bot:
>
> #regzbot ^introduced v6.4..v6.5.3
> https://bugzilla.suse.com/show_bug.cgi?id=1215436
> #regzbot title firewire: instant reboot during boot
> #regzbot ignore-activity
#regzbot fix: ac9184fbb8478dab4a0724b279f94956b69be827
#regzbot ignore-activity
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.