Message ID | 20230704121847.GA26576@workstation.local |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp1187204vqx; Tue, 4 Jul 2023 05:35:17 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ68L94QGqikcPNoRpnkLuBEdS9H5wr9z/+NatTR8MYE8S98ESGBFCnKr7aP13ymDyLv0F0R X-Received: by 2002:a17:90a:6e02:b0:261:326d:99e8 with SMTP id b2-20020a17090a6e0200b00261326d99e8mr25128583pjk.2.1688474117589; Tue, 04 Jul 2023 05:35:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688474117; cv=none; d=google.com; s=arc-20160816; b=ZkEy9g4kw5AWSKzYzY9mTRxREHU7uJGLgPUqaLLzX4LVVNPjUhmtoytJ42ETDHCtHh Zl+7vt8dn1BgRT7EcC1jtV2mEkS0N/L0hEK3gVH1QYzSjq8fmeN54tAu3E0X6yrdb9zs Z+wOQcgIA6x/0XNZncNRiInUSdE+fbc1BwhfNjo4iII+lT0YgiwGQd03pg8HaJV1qTq4 ou/OPt1i0ZXpnBJto8VqOby2j571Cwk/T5s+v0H85H2U1LwKRsd8+WfyWEeHsZTudU4H OlnmgZjKPkUjaJBNyWM8KkKR5pyPo7L7OeW3tCSdeL/foARDRFno/DLnCzKr8qi48xVI xgTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version :mail-followup-to:message-id:subject:cc:to:from:date:feedback-id :dkim-signature:dkim-signature; bh=TFejWBSEdCirJhK9+BSCkX03krBBQ5n4YbwiIw1ENxA=; fh=X/K9fo3OhTvDrVVIvfKUfsT76Iel+RlAA2+AG+903tQ=; b=IOXwGbuP7RdIobGz3vCWimAXZLe8cx9EJDCtX6MKE9CYdTQBxDWFxeBhA/aGACntuV kbcE/TvMt+7YJ8ehCjIceKmXgEqAUS2Rx9LcD9HADFgp+B3bs0LC5hXaFfl7V3b/d1i5 IbqVuSkZQzPnx0FzDIB/jp6gYn5x5ISwollVneDso7qe85vZF9mGYswSp9rKHBGqXSO0 gtC3jBgDtHXlV/ksmIiM/G0i0vYa4u4a2SDCR9yl3PdNC5KiA7Gw3R7k00N9ObOCfWi2 Oa1m50tGLaFDiAnph/2syQXSQK/Zrc8pavcVqB2m0x7t3y20zBb3UeD2tvPtZZ92BaiG jLeQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sakamocchi.jp header.s=fm2 header.b=AAlBf6c2; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=MGmIPDWH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v19-20020a634653000000b0055771146c25si10796588pgk.896.2023.07.04.05.35.01; Tue, 04 Jul 2023 05:35:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@sakamocchi.jp header.s=fm2 header.b=AAlBf6c2; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=MGmIPDWH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231449AbjGDMTB (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Tue, 4 Jul 2023 08:19:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37178 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231313AbjGDMS6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 4 Jul 2023 08:18:58 -0400 Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C165810EF for <linux-kernel@vger.kernel.org>; Tue, 4 Jul 2023 05:18:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2594E32009B4; Tue, 4 Jul 2023 08:18:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 04 Jul 2023 08:18:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sakamocchi.jp; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm2; t=1688473132; x=1688559532; bh=TFejWBSEdC irJhK9+BSCkX03krBBQ5n4YbwiIw1ENxA=; b=AAlBf6c2M4sh+7H1YAM1K7PzvH xTOwlbyncXDXjmjWTuW3rISaNThFjbZEVQxTL4wc/53kMtEAjTHPQ9VdeUxnJLOQ GOkEiQWdo4MoWuISx8UZWF+DYR0k+rhC0zQaw5IJEjFE2879PO7teT6CW2ijLyre ebGrYt0NMxijXY5au4UrBgqBoTkF9qbI8ImAxKHWdvxtVT9M28njSOoTIVMUzuZX 1mvOVhc7wzmjxJ/R1MvnebtLUI4hb8UZXVYJhtYavklJYrp6hUMTTAlHPKH5/6pd CHvOq1SUliO5OgW5GN9x9lxtRAKK9iXLvoRNPBs62QvIcW6elcrH1TV+3XrQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1688473132; x=1688559532; bh=TFejWBSEdCirJhK9+BSCkX03krBBQ5n4Ybw iIw1ENxA=; b=MGmIPDWHpPFm16D/CS1d6xbTOWZeVoS5JvFDx4vKjlCGtTrsDyr FCJXt74KaltSreL8faNPG6AkYgNSO2Ub6efn7Sm7+WhDo379/A9LbKqNi3gB9Wh2 E9ybHw40oPjkbJoIlVqmKRAdJzD+yj9AjRSSEFDStBkh5WBE1du96k8Yga/ESrDY lJqssPYJvUo69xMvnfWjnmZZ7UTMVaeuG65qlnwdC30IKke/KlB7G2CaCKO6hTHp 4qdgnB+UFgcdl0+q4WTERDBUkmsC2PZGERcyH7r5k6V8rmoHGnnn00asG/Z7Qanb Q5Xp1EjsSGAhnQdtgL0r8qzORpTwzuFUwHg== X-ME-Sender: <xms:LA6kZISMxGD7b5Y0HJDmPw1IYIkufcCsgP1GtvxmkeIbWicHwtZgJA> <xme:LA6kZFyIlBOMe4iFx1iuQYcg17AGkZzdzldR6rM1Cm82GSxOAXwiURpV0EWWe7hnl 8ZL6mdT3xeYsh5Ifp4> X-ME-Received: <xmr:LA6kZF0P8TxpI2qCCo4J1wANRL2v4La8nnGFcdWpJRCgke6ASHUBTcy-wV_ThEjVZMmnJ-VY4JNZNWlaTZFtqlRjg-NwuTb4sRw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudeggdehtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkgggtugesthdtredttd dtvdenucfhrhhomhepvfgrkhgrshhhihcuufgrkhgrmhhothhouceoohdqthgrkhgrshhh ihesshgrkhgrmhhotggthhhirdhjpheqnecuggftrfgrthhtvghrnhepteefieetfeevge dvgfegffehteeljeekkeelueegfffftdfgtdetteekvedvvdfgnecuffhomhgrihhnpehk vghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehoqdhtrghkrghshhhisehsrghkrghmohgttghhihdrjhhp X-ME-Proxy: <xmx:LA6kZMCEEJug6CoAx2flDy4RHASHs-s8b-PmhpueZVXS0aDQhlrQzw> <xmx:LA6kZBjKkPq4Of5aFeEY_sOjeY9XjSF9_nGkA3oA7kEobutSZcrlwA> <xmx:LA6kZIo4PmT_W5Qa6HvDEM-iJXqUv6E-1eQyLCVQ4OedEv_zXwhP_g> <xmx:LA6kZBLbW7d7fVomH7uwcfsyQ8PlqHEBIlQBlcTaZnz7xLTJza-JkQ> Feedback-ID: ie8e14432:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 4 Jul 2023 08:18:51 -0400 (EDT) Date: Tue, 4 Jul 2023 21:18:47 +0900 From: Takashi Sakamoto <o-takashi@sakamocchi.jp> To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org Subject: [GIT PULL] firewire updates for 6.5-rc1 Message-ID: <20230704121847.GA26576@workstation.local> Mail-Followup-To: Takashi Sakamoto <o-takashi@sakamocchi.jp>, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1770493436341675740?= X-GMAIL-MSGID: =?utf-8?q?1770493436341675740?= |
Series |
[GIT,PULL] firewire updates for 6.5-rc1
|
|
Pull-request
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git tags/firewire-6.5-rc1Message
Takashi Sakamoto
July 4, 2023, 12:18 p.m. UTC
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
Comments
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!
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,
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,
Linux regression tracking (Thorsten Leemhuis)
Sept. 27, 2023, 1:15 p.m. UTC |
#5
Addressed
Unaddressed
[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,
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,
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,
Linux regression tracking (Thorsten Leemhuis)
Jan. 21, 2024, 10:04 a.m. UTC |
#12
Addressed
Unaddressed
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.