Hi!
Between commits 7ddb58cb0eca and d2f38a3c6507, the kernel stops
loading on my devices.
On the kernel log I see such a trace:
[ 5.868358] primary-ws kernel: Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 5.868360] primary-ws kernel: CPU: 23 PID: 305 Comm: kworker/23:2
Tainted: G W --------- ---
5.17.0-0.rc0.20220113git455e73a07f6e.64.fc36.x86_64 #1
[ 5.868363] primary-ws kernel: Hardware name: System manufacturer
System Product Name/ROG STRIX X570-I GAMING, BIOS 4021 08/09/2021
[ 5.868365] primary-ws kernel: Workqueue: events_long
ucsi_init_work [typec_ucsi]
[ 5.868370] primary-ws kernel: RIP: 0010:typec_port_match+0x44/0x80 [typec]
[ 5.868377] primary-ws kernel: Code: 06 48 8b 98 00 05 00 00 48 89
df 48 83 eb 10 e8 b2 53 3b f3 84 c0 b8 00 00 00 00 48 0f 44 d8 4c 39
eb 74 0a 8b 85 70 fd ff ff <39> 03 74 09 5b 31 c0 5d 41 5c 41 5d c3 49
8b 3c 24 49 8d 74 24 08
[ 5.868379] primary-ws kernel: RSP: 0018:ffffbf704494bd60 EFLAGS: 00010207
[ 5.868381] primary-ws kernel: RAX: 0000000000000000 RBX:
0000000000000000 RCX: 0000000000000000
[ 5.868382] primary-ws kernel: RDX: 0000000000000001 RSI:
ffffbf704494bdb8 RDI: 0000000000000000
[ 5.868384] primary-ws kernel: RBP: ffff9a23c2bbf290 R08:
0000000000000001 R09: 0000000000000001
[ 5.868385] primary-ws kernel: R10: 0000000000000001 R11:
0000000000000000 R12: ffffbf704494bdb8
[ 5.868386] primary-ws kernel: R13: ffff9a23c2bbf000 R14:
ffff9a23c1b99008 R15: ffff9a23c1b01820
[ 5.868388] primary-ws kernel: FS: 0000000000000000(0000)
GS:ffff9a32a8600000(0000) knlGS:0000000000000000
[ 5.868389] primary-ws kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 5.868391] primary-ws kernel: CR2: 0000000000000000 CR3:
000000017c482000 CR4: 0000000000350ee0
[ 5.868393] primary-ws kernel: Call Trace:
[ 5.868394] primary-ws kernel: <TASK>
[ 5.868396] primary-ws kernel: ? typec_port_compare+0x10/0x10 [typec]
[ 5.868401] primary-ws kernel: bus_for_each_dev+0x67/0x90
[ 5.868406] primary-ws kernel: typec_link_ports+0x32/0x50 [typec]
[ 5.868411] primary-ws kernel: typec_register_port+0x1e6/0x2e0 [typec]
[ 5.868416] primary-ws kernel: ucsi_init_work+0x463/0x840 [typec_ucsi]
[ 5.868420] primary-ws kernel: process_one_work+0x2bb/0x600
[ 5.868426] primary-ws kernel: worker_thread+0x55/0x3b0
[ 5.868429] primary-ws kernel: ? process_one_work+0x600/0x600
[ 5.868431] primary-ws kernel: kthread+0x17c/0x1a0
[ 5.868433] primary-ws kernel: ? set_kthread_struct+0x40/0x40
[ 5.868436] primary-ws kernel: ret_from_fork+0x22/0x30
[ 5.868441] primary-ws kernel: </TASK>
[ 5.868442] primary-ws kernel: Modules linked in: crct10dif_pclmul
crc32_pclmul crc32c_intel ucsi_ccg drm_ttm_helper ghash_clmulni_intel
typec_ucsi ttm ccp sp5100_tco typec igb iommu_v2 gpu_sched nvme
nvme_core dca wmi ipmi_devintf ipmi_msghandler fuse
[ 5.868455] primary-ws kernel: CR2: 0000000000000000
[ 5.868457] primary-ws kernel: ---[ end trace c5a60084d820dc9c ]---
[ 5.868459] primary-ws kernel: RIP: 0010:typec_port_match+0x44/0x80 [typec]
[ 5.868463] primary-ws kernel: Code: 06 48 8b 98 00 05 00 00 48 89
df 48 83 eb 10 e8 b2 53 3b f3 84 c0 b8 00 00 00 00 48 0f 44 d8 4c 39
eb 74 0a 8b 85 70 fd ff ff <39> 03 74 09 5b 31 c0 5d 41 5c 41 5d c3 49
8b 3c 24 49 8d 74 24 08
[ 5.868465] primary-ws kernel: RSP: 0018:ffffbf704494bd60 EFLAGS: 00010207
[ 5.868467] primary-ws kernel: RAX: 0000000000000000 RBX:
0000000000000000 RCX: 0000000000000000
[ 5.868468] primary-ws kernel: RDX: 0000000000000001 RSI:
ffffbf704494bdb8 RDI: 0000000000000000
[ 5.868469] primary-ws kernel: RBP: ffff9a23c2bbf290 R08:
0000000000000001 R09: 0000000000000001
[ 5.868470] primary-ws kernel: R10: 0000000000000001 R11:
0000000000000000 R12: ffffbf704494bdb8
[ 5.868471] primary-ws kernel: R13: ffff9a23c2bbf000 R14:
ffff9a23c1b99008 R15: ffff9a23c1b01820
[ 5.868473] primary-ws kernel: FS: 0000000000000000(0000)
GS:ffff9a32a8600000(0000) knlGS:0000000000000000
[ 5.868475] primary-ws kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 5.868476] primary-ws kernel: CR2: 0000000000000000 CR3:
000000017c482000 CR4: 0000000000350ee0
I also bisect kernel and found first bad commit:
$ git bisect log
git bisect start
# good: [daadb3bd0e8d3e317e36bc2c1542e86c528665e5] Merge tag
'locking_core_for_v5.17_rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good daadb3bd0e8d3e317e36bc2c1542e86c528665e5
# bad: [455e73a07f6e288b0061dfcf4fcf54fa9fe06458] Merge tag
'clk-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
git bisect bad 455e73a07f6e288b0061dfcf4fcf54fa9fe06458
# good: [342465f5337f7bd5b8bd3b6f939ac12b620cbb43] Merge tag
'tty-5.17-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect good 342465f5337f7bd5b8bd3b6f939ac12b620cbb43
# bad: [362f533a2a1098fe95020cb59340023e9b11d062] Merge tag
'cxl-for-5.17' of
git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl
git bisect bad 362f533a2a1098fe95020cb59340023e9b11d062
# bad: [6020c204be997e3f5129839ff9c801800fb4336e] Merge tag
'folio-5.17' of git://git.infradead.org/users/willy/pagecache
git bisect bad 6020c204be997e3f5129839ff9c801800fb4336e
# bad: [e681a9d2050cdcaf24adeabc9f1aea6cff94be22] Merge 5.16-rc8 into usb-next
git bisect bad e681a9d2050cdcaf24adeabc9f1aea6cff94be22
# good: [a5b5b45fce2bed5560159095b4777afb18590740] dt-bindings: usb:
dwc3-xilinx: Convert USB DWC3 bindings
git bisect good a5b5b45fce2bed5560159095b4777afb18590740
# good: [cf081d009c447647c6b36aced535ca427dbebe72] usb: musb: Set the
DT node on the child device
git bisect good cf081d009c447647c6b36aced535ca427dbebe72
# good: [78e17d69999521b52b9db9656e9b9b397f59f228] usb: cdns3: Use
platform_get_irq_byname() to get the interrupt
git bisect good 78e17d69999521b52b9db9656e9b9b397f59f228
# good: [13068b7472f9720f807fe72b9bf3f76b9fd6d6ab] acpi: Export acpi_bus_type
git bisect good 13068b7472f9720f807fe72b9bf3f76b9fd6d6ab
# bad: [730b49aac426e1e8016d3c2dd6b407e500423821] usb: typec:
port-mapper: Convert to the component framework
git bisect bad 730b49aac426e1e8016d3c2dd6b407e500423821
# good: [8c67d06f3fd9639c44d8147483fb1c132d71388f] usb: Link the ports
to the connectors they are attached to
git bisect good 8c67d06f3fd9639c44d8147483fb1c132d71388f
# first bad commit: [730b49aac426e1e8016d3c2dd6b407e500423821] usb:
typec: port-mapper: Convert to the component framework
$ git bisect good
730b49aac426e1e8016d3c2dd6b407e500423821 is the first bad commit
commit 730b49aac426e1e8016d3c2dd6b407e500423821
Author: Heikki Krogerus <[email protected]>
Date: Thu Dec 23 11:24:22 2021 +0300
usb: typec: port-mapper: Convert to the component framework
Instead of trying to keep track of the connections to the
USB Type-C connectors separately, letting the component
framework take care of that.
From now on every USB Type-C connector will register itself
as "aggregate" - component master - and anything that can be
connected to it inside the system can then simply register
itself as a generic component.
The matching of the components and the connector shall rely
on ACPI _PLD initially. Before registering itself as the
aggregate, the connector will find all other ACPI devices
that have matching _PLD crc hash with it (matching value in
the pld_crc member of struct acpi_device), and add a
component match entry for each one of them. Because only
ACPI is supported for now, the driver shall only be build
when ACPI is supported.
This removes the need for the custom API that the driver
exposed. The components and the connector can therefore
exist completely independently of each other. The order in
which they are registered, as well as are they modules or
not, is now irrelevant.
Acked-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Heikki Krogerus <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
drivers/usb/typec/Makefile | 3 +-
drivers/usb/typec/class.c | 2 -
drivers/usb/typec/class.h | 10 +-
drivers/usb/typec/port-mapper.c | 279 ++++++----------------------------------
include/linux/usb/typec.h | 12 --
5 files changed, 46 insertions(+), 260 deletions(-)
Full kernel log is here: https://pastebin.com/byYtHyxZ
--
Best Regards,
Mike Gavrilov.
Hi Mikhail,
On Mon, Jan 17, 2022 at 05:49:19AM +0500, Mikhail Gavrilov wrote:
> Hi!
> Between commits 7ddb58cb0eca and d2f38a3c6507, the kernel stops
> loading on my devices.
> On the kernel log I see such a trace:
> [ 5.868358] primary-ws kernel: Oops: 0000 [#1] PREEMPT SMP NOPTI
> [ 5.868360] primary-ws kernel: CPU: 23 PID: 305 Comm: kworker/23:2
> Tainted: G W --------- ---
> 5.17.0-0.rc0.20220113git455e73a07f6e.64.fc36.x86_64 #1
> [ 5.868363] primary-ws kernel: Hardware name: System manufacturer
> System Product Name/ROG STRIX X570-I GAMING, BIOS 4021 08/09/2021
> [ 5.868365] primary-ws kernel: Workqueue: events_long
> ucsi_init_work [typec_ucsi]
> [ 5.868370] primary-ws kernel: RIP: 0010:typec_port_match+0x44/0x80 [typec]
> [ 5.868377] primary-ws kernel: Code: 06 48 8b 98 00 05 00 00 48 89
> df 48 83 eb 10 e8 b2 53 3b f3 84 c0 b8 00 00 00 00 48 0f 44 d8 4c 39
> eb 74 0a 8b 85 70 fd ff ff <39> 03 74 09 5b 31 c0 5d 41 5c 41 5d c3 49
> 8b 3c 24 49 8d 74 24 08
> [ 5.868379] primary-ws kernel: RSP: 0018:ffffbf704494bd60 EFLAGS: 00010207
> [ 5.868381] primary-ws kernel: RAX: 0000000000000000 RBX:
> 0000000000000000 RCX: 0000000000000000
> [ 5.868382] primary-ws kernel: RDX: 0000000000000001 RSI:
> ffffbf704494bdb8 RDI: 0000000000000000
> [ 5.868384] primary-ws kernel: RBP: ffff9a23c2bbf290 R08:
> 0000000000000001 R09: 0000000000000001
> [ 5.868385] primary-ws kernel: R10: 0000000000000001 R11:
> 0000000000000000 R12: ffffbf704494bdb8
> [ 5.868386] primary-ws kernel: R13: ffff9a23c2bbf000 R14:
> ffff9a23c1b99008 R15: ffff9a23c1b01820
> [ 5.868388] primary-ws kernel: FS: 0000000000000000(0000)
> GS:ffff9a32a8600000(0000) knlGS:0000000000000000
> [ 5.868389] primary-ws kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
> 0000000080050033
> [ 5.868391] primary-ws kernel: CR2: 0000000000000000 CR3:
> 000000017c482000 CR4: 0000000000350ee0
> [ 5.868393] primary-ws kernel: Call Trace:
> [ 5.868394] primary-ws kernel: <TASK>
> [ 5.868396] primary-ws kernel: ? typec_port_compare+0x10/0x10 [typec]
> [ 5.868401] primary-ws kernel: bus_for_each_dev+0x67/0x90
> [ 5.868406] primary-ws kernel: typec_link_ports+0x32/0x50 [typec]
> [ 5.868411] primary-ws kernel: typec_register_port+0x1e6/0x2e0 [typec]
> [ 5.868416] primary-ws kernel: ucsi_init_work+0x463/0x840 [typec_ucsi]
> [ 5.868420] primary-ws kernel: process_one_work+0x2bb/0x600
> [ 5.868426] primary-ws kernel: worker_thread+0x55/0x3b0
> [ 5.868429] primary-ws kernel: ? process_one_work+0x600/0x600
> [ 5.868431] primary-ws kernel: kthread+0x17c/0x1a0
> [ 5.868433] primary-ws kernel: ? set_kthread_struct+0x40/0x40
> [ 5.868436] primary-ws kernel: ret_from_fork+0x22/0x30
> [ 5.868441] primary-ws kernel: </TASK>
> [ 5.868442] primary-ws kernel: Modules linked in: crct10dif_pclmul
> crc32_pclmul crc32c_intel ucsi_ccg drm_ttm_helper ghash_clmulni_intel
> typec_ucsi ttm ccp sp5100_tco typec igb iommu_v2 gpu_sched nvme
> nvme_core dca wmi ipmi_devintf ipmi_msghandler fuse
> [ 5.868455] primary-ws kernel: CR2: 0000000000000000
> [ 5.868457] primary-ws kernel: ---[ end trace c5a60084d820dc9c ]---
> [ 5.868459] primary-ws kernel: RIP: 0010:typec_port_match+0x44/0x80 [typec]
> [ 5.868463] primary-ws kernel: Code: 06 48 8b 98 00 05 00 00 48 89
> df 48 83 eb 10 e8 b2 53 3b f3 84 c0 b8 00 00 00 00 48 0f 44 d8 4c 39
> eb 74 0a 8b 85 70 fd ff ff <39> 03 74 09 5b 31 c0 5d 41 5c 41 5d c3 49
> 8b 3c 24 49 8d 74 24 08
> [ 5.868465] primary-ws kernel: RSP: 0018:ffffbf704494bd60 EFLAGS: 00010207
> [ 5.868467] primary-ws kernel: RAX: 0000000000000000 RBX:
> 0000000000000000 RCX: 0000000000000000
> [ 5.868468] primary-ws kernel: RDX: 0000000000000001 RSI:
> ffffbf704494bdb8 RDI: 0000000000000000
> [ 5.868469] primary-ws kernel: RBP: ffff9a23c2bbf290 R08:
> 0000000000000001 R09: 0000000000000001
> [ 5.868470] primary-ws kernel: R10: 0000000000000001 R11:
> 0000000000000000 R12: ffffbf704494bdb8
> [ 5.868471] primary-ws kernel: R13: ffff9a23c2bbf000 R14:
> ffff9a23c1b99008 R15: ffff9a23c1b01820
> [ 5.868473] primary-ws kernel: FS: 0000000000000000(0000)
> GS:ffff9a32a8600000(0000) knlGS:0000000000000000
> [ 5.868475] primary-ws kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
> 0000000080050033
> [ 5.868476] primary-ws kernel: CR2: 0000000000000000 CR3:
> 000000017c482000 CR4: 0000000000350ee0
>
> I also bisect kernel and found first bad commit:
>
> $ git bisect log
> git bisect start
> # good: [daadb3bd0e8d3e317e36bc2c1542e86c528665e5] Merge tag
> 'locking_core_for_v5.17_rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> git bisect good daadb3bd0e8d3e317e36bc2c1542e86c528665e5
> # bad: [455e73a07f6e288b0061dfcf4fcf54fa9fe06458] Merge tag
> 'clk-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
> git bisect bad 455e73a07f6e288b0061dfcf4fcf54fa9fe06458
> # good: [342465f5337f7bd5b8bd3b6f939ac12b620cbb43] Merge tag
> 'tty-5.17-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
> git bisect good 342465f5337f7bd5b8bd3b6f939ac12b620cbb43
> # bad: [362f533a2a1098fe95020cb59340023e9b11d062] Merge tag
> 'cxl-for-5.17' of
> git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl
> git bisect bad 362f533a2a1098fe95020cb59340023e9b11d062
> # bad: [6020c204be997e3f5129839ff9c801800fb4336e] Merge tag
> 'folio-5.17' of git://git.infradead.org/users/willy/pagecache
> git bisect bad 6020c204be997e3f5129839ff9c801800fb4336e
> # bad: [e681a9d2050cdcaf24adeabc9f1aea6cff94be22] Merge 5.16-rc8 into usb-next
> git bisect bad e681a9d2050cdcaf24adeabc9f1aea6cff94be22
> # good: [a5b5b45fce2bed5560159095b4777afb18590740] dt-bindings: usb:
> dwc3-xilinx: Convert USB DWC3 bindings
> git bisect good a5b5b45fce2bed5560159095b4777afb18590740
> # good: [cf081d009c447647c6b36aced535ca427dbebe72] usb: musb: Set the
> DT node on the child device
> git bisect good cf081d009c447647c6b36aced535ca427dbebe72
> # good: [78e17d69999521b52b9db9656e9b9b397f59f228] usb: cdns3: Use
> platform_get_irq_byname() to get the interrupt
> git bisect good 78e17d69999521b52b9db9656e9b9b397f59f228
> # good: [13068b7472f9720f807fe72b9bf3f76b9fd6d6ab] acpi: Export acpi_bus_type
> git bisect good 13068b7472f9720f807fe72b9bf3f76b9fd6d6ab
> # bad: [730b49aac426e1e8016d3c2dd6b407e500423821] usb: typec:
> port-mapper: Convert to the component framework
> git bisect bad 730b49aac426e1e8016d3c2dd6b407e500423821
> # good: [8c67d06f3fd9639c44d8147483fb1c132d71388f] usb: Link the ports
> to the connectors they are attached to
> git bisect good 8c67d06f3fd9639c44d8147483fb1c132d71388f
> # first bad commit: [730b49aac426e1e8016d3c2dd6b407e500423821] usb:
> typec: port-mapper: Convert to the component framework
>
> $ git bisect good
> 730b49aac426e1e8016d3c2dd6b407e500423821 is the first bad commit
> commit 730b49aac426e1e8016d3c2dd6b407e500423821
> Author: Heikki Krogerus <[email protected]>
> Date: Thu Dec 23 11:24:22 2021 +0300
>
> usb: typec: port-mapper: Convert to the component framework
>
> Instead of trying to keep track of the connections to the
> USB Type-C connectors separately, letting the component
> framework take care of that.
>
> From now on every USB Type-C connector will register itself
> as "aggregate" - component master - and anything that can be
> connected to it inside the system can then simply register
> itself as a generic component.
>
> The matching of the components and the connector shall rely
> on ACPI _PLD initially. Before registering itself as the
> aggregate, the connector will find all other ACPI devices
> that have matching _PLD crc hash with it (matching value in
> the pld_crc member of struct acpi_device), and add a
> component match entry for each one of them. Because only
> ACPI is supported for now, the driver shall only be build
> when ACPI is supported.
>
> This removes the need for the custom API that the driver
> exposed. The components and the connector can therefore
> exist completely independently of each other. The order in
> which they are registered, as well as are they modules or
> not, is now irrelevant.
>
> Acked-by: Rafael J. Wysocki <[email protected]>
> Signed-off-by: Heikki Krogerus <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> drivers/usb/typec/Makefile | 3 +-
> drivers/usb/typec/class.c | 2 -
> drivers/usb/typec/class.h | 10 +-
> drivers/usb/typec/port-mapper.c | 279 ++++++----------------------------------
> include/linux/usb/typec.h | 12 --
> 5 files changed, 46 insertions(+), 260 deletions(-)
>
> Full kernel log is here: https://pastebin.com/byYtHyxZ
Thank you for bisecting the problem.
The code assumes currently that every USB Type-C port has an ACPI
device node defined for it in the ACPI tables, but it looks like we
can't make that assumption. Could you send me the acpidump?
I'm attaching a test patch where I check the Type-C port ACPI nodes.
Let me know it that fixes the problem.
thanks,
--
heikki
On Mon, 17 Jan 2022 at 13:58, Heikki Krogerus
<[email protected]> wrote:
>
> Hi Mikhail,
>
> Thank you for bisecting the problem.
>
> The code assumes currently that every USB Type-C port has an ACPI
> device node defined for it in the ACPI tables, but it looks like we
> can't make that assumption. Could you send me the acpidump?
>
> I'm attaching a test patch where I check the Type-C port ACPI nodes.
> Let me know it that fixes the problem.
>
Hi Heikki,
Unfonitaly I can't test patch because it applicable to actual code base.
$ cat 0001-usb-typec-Test-fix.patch | git apply -v
Checking patch drivers/usb/typec/port-mapper.c...
error: while searching for:
{?
struct each_port_arg arg = { .port = con, .match = NULL };?
?
bus_for_each_dev(&acpi_bus_type, NULL, &arg, typec_port_match);?
?
/*?
error: patch failed: drivers/usb/typec/port-mapper.c:56
error: drivers/usb/typec/port-mapper.c: patch does not apply
I attached acpidump files from my workstation and laptop.
--
Best Regards,
Mike Gavrilov.
On Mon, Jan 17, 2022 at 03:46:44PM +0500, Mikhail Gavrilov wrote:
> On Mon, 17 Jan 2022 at 13:58, Heikki Krogerus
> <[email protected]> wrote:
> >
> > Hi Mikhail,
> >
> > Thank you for bisecting the problem.
> >
> > The code assumes currently that every USB Type-C port has an ACPI
> > device node defined for it in the ACPI tables, but it looks like we
> > can't make that assumption. Could you send me the acpidump?
> >
> > I'm attaching a test patch where I check the Type-C port ACPI nodes.
> > Let me know it that fixes the problem.
> >
>
> Hi Heikki,
> Unfonitaly I can't test patch because it applicable to actual code base.
>
> $ cat 0001-usb-typec-Test-fix.patch | git apply -v
> Checking patch drivers/usb/typec/port-mapper.c...
> error: while searching for:
> {?
> struct each_port_arg arg = { .port = con, .match = NULL };?
> ?
> bus_for_each_dev(&acpi_bus_type, NULL, &arg, typec_port_match);?
> ?
> /*?
>
> error: patch failed: drivers/usb/typec/port-mapper.c:56
> error: drivers/usb/typec/port-mapper.c: patch does not apply
I don't know which tree you are working on top of, but the patch
applies just fine on top of Linus' latest master branch:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> I attached acpidump files from my workstation and laptop.
Thanks. I can see UCSI in your laptop dump, but not in the workstation
dump. The laptop has the device nodes also for the ports as expected.
Which machine is failing?
Br,
--
heikki
On Mon, 17 Jan 2022 at 16:19, Heikki Krogerus
<[email protected]> wrote:
> I don't know which tree you are working on top of, but the patch
> applies just fine on top of Linus' latest master branch:
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
Same here.
$ git remote -v
origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
(fetch)
origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
(push)
$ git show
commit 0c947b893d69231a9add855939da7c66237ab44f (HEAD -> master,
origin/master, origin/HEAD)
Merge: a6097180d884 9bbf8662a27b
Author: Linus Torvalds <[email protected]>
Date: Mon Jan 17 09:53:21 2022 +0200
Merge tag '5.17-rc-part1-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6
Pull cifs updates from Steve French:
- multichannel patches mostly related to improving reconnect behavior
- minor cleanup patches
* tag '5.17-rc-part1-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
cifs: fix FILE_BOTH_DIRECTORY_INFO definition
cifs: move superblock magic defitions to magic.h
cifs: Fix smb311_update_preauth_hash() kernel-doc comment
cifs: avoid race during socket reconnect between send and recv
cifs: maintain a state machine for tcp/smb/tcon sessions
cifs: fix hang on cifs_get_next_mid()
cifs: take cifs_tcp_ses_lock for status checks
cifs: reconnect only the connection and not smb session where possible
cifs: add WARN_ON for when chan_count goes below minimum
cifs: adjust DebugData to use chans_need_reconnect for conn status
cifs: use the chans_need_reconnect bitmap for reconnect status
cifs: track individual channel status using chans_need_reconnect
cifs: remove redundant assignment to pointer p
$ cat 0001-usb-typec-Test-fix.patch | git apply
error: patch failed: drivers/usb/typec/port-mapper.c:56
error: drivers/usb/typec/port-mapper.c: patch does not apply
> Thanks. I can see UCSI in your laptop dump, but not in the workstation
> dump. The laptop has the device nodes also for the ports as expected.
>
> Which machine is failing?
Both.
--
Best Regards,
Mike Gavrilov.
On Mon, Jan 17, 2022 at 04:52:02PM +0500, Mikhail Gavrilov wrote:
> On Mon, 17 Jan 2022 at 16:19, Heikki Krogerus
> <[email protected]> wrote:
>
> > I don't know which tree you are working on top of, but the patch
> > applies just fine on top of Linus' latest master branch:
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> >
>
> Same here.
>
> $ git remote -v
> origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> (fetch)
> origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> (push)
>
> $ git show
> commit 0c947b893d69231a9add855939da7c66237ab44f (HEAD -> master,
> origin/master, origin/HEAD)
> Merge: a6097180d884 9bbf8662a27b
> Author: Linus Torvalds <[email protected]>
> Date: Mon Jan 17 09:53:21 2022 +0200
>
> Merge tag '5.17-rc-part1-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6
>
> Pull cifs updates from Steve French:
>
> - multichannel patches mostly related to improving reconnect behavior
>
> - minor cleanup patches
>
> * tag '5.17-rc-part1-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
> cifs: fix FILE_BOTH_DIRECTORY_INFO definition
> cifs: move superblock magic defitions to magic.h
> cifs: Fix smb311_update_preauth_hash() kernel-doc comment
> cifs: avoid race during socket reconnect between send and recv
> cifs: maintain a state machine for tcp/smb/tcon sessions
> cifs: fix hang on cifs_get_next_mid()
> cifs: take cifs_tcp_ses_lock for status checks
> cifs: reconnect only the connection and not smb session where possible
> cifs: add WARN_ON for when chan_count goes below minimum
> cifs: adjust DebugData to use chans_need_reconnect for conn status
> cifs: use the chans_need_reconnect bitmap for reconnect status
> cifs: track individual channel status using chans_need_reconnect
> cifs: remove redundant assignment to pointer p
>
> $ cat 0001-usb-typec-Test-fix.patch | git apply
> error: patch failed: drivers/usb/typec/port-mapper.c:56
> error: drivers/usb/typec/port-mapper.c: patch does not apply
Have you modified the file, or something else that you have not
committed yet?
% git status
Checkout the file, and then try to apply the patch:
% git checkout drivers/usb/typec/port-mapper.c
% git apply -v 0001-usb-typec-Test-fix.patch
thanks,
--
heikki
On Mon, 17 Jan 2022 at 17:21, Heikki Krogerus
<[email protected]> wrote:
>
> Have you modified the file, or something else that you have not
> committed yet?
>
> % git status
>
> Checkout the file, and then try to apply the patch:
>
> % git checkout drivers/usb/typec/port-mapper.c
> % git apply -v 0001-usb-typec-Test-fix.patch
>
I understood why the patch was not applied. The "Window line endings"
in the attached file were.
$ dos2unix 0001-usb-typec-Test-fix.patch
dos2unix: converting file 0001-usb-typec-Test-fix.patch to Unix format...
$ git apply -v 0001-usb-typec-Test-fix.patch
Checking patch drivers/usb/typec/port-mapper.c...
Applied patch drivers/usb/typec/port-mapper.c cleanly.
Unfortunately the attached patch didn't fix the issue.
BUG: kernel NULL pointer dereference, address: 0000000000000008
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 10 PID: 459 Comm: kworker/10:2 Not tainted
5.16.0-patched-455e73a07f6e+ #26
Hardware name: ASUSTeK COMPUTER INC. ROG Strix G513QY_G513QY/G513QY,
BIOS G513QY.316 11/29/2021
Workqueue: events_long ucsi_init_work [typec_ucsi]
RIP: 0010:component_master_add_with_match+0x14/0x110
Code: 72 d7 48 89 ef 5b 5d e9 1a 5c 9f ff 66 2e 0f 1f 84 00 00 00 00
00 0f 1f 44 00 00 41 55 49 89 fd 41 54 49 89 f4 55 53 48 89 d3 <48> 8b
72 08 48 3b 32 74 10 48 89 d7 e8 4b fd ff ff 85 c0 0f 85 bb
RSP: 0018:ffffba4581837d90 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffffc04f58d0 RDI: ffff9c5afe43a808
RBP: ffff9c5a81076358 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: ffffffffc04f58d0
R13: ffff9c5afe43a808 R14: ffff9c5afe43a808 R15: ffff9c5a832c4010
FS: 0000000000000000(0000) GS:ffff9c5d88a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 00000002e5028000 CR4: 0000000000750ee0
PKRU: 55555554
Call Trace:
<TASK>
typec_link_ports+0x5d/0x70 [typec]
typec_register_port+0x1e6/0x2e0 [typec]
ucsi_init_work+0x463/0x840 [typec_ucsi]
process_one_work+0x2bb/0x600
worker_thread+0x55/0x3b0
? process_one_work+0x600/0x600
kthread+0x17c/0x1a0
? set_kthread_struct+0x40/0x40
ret_from_fork+0x22/0x30
</TASK>
Modules linked in: hid_multitouch crct10dif_pclmul hid_asus
crc32_pclmul crc32c_intel asus_wmi sparse_keymap nvme
ghash_clmulni_intel platform_profile drm_ttm_helper ttm serio_raw
rfkill nvme_core ccp ucsi_acpi sp5100_tco r8169 iommu_v2 typec_ucsi i
i2c_hid ipmi_devintf ipmi_msghandler fuse
CR2: 0000000000000008
---[ end trace 464b80635f62ac4e ]---
RIP: 0010:component_master_add_with_match+0x14/0x110
Code: 72 d7 48 89 ef 5b 5d e9 1a 5c 9f ff 66 2e 0f 1f 84 00 00 00 00
00 0f 1f 44 00 00 41 55 49 89 fd 41 54 49 89 f4 55 53 48 89 d3 <48> 8b
72 08 48 3b 32 74 10 48 89 d7 e8 4b fd ff ff 85 c0 0f 85 bb
RSP: 0018:ffffba4581837d90 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffffc04f58d0 RDI: ffff9c5afe43a808
RBP: ffff9c5a81076358 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: ffffffffc04f58d0
R13: ffff9c5afe43a808 R14: ffff9c5afe43a808 R15: ffff9c5a832c4010
FS: 0000000000000000(0000) GS:ffff9c5d88a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 00000002e5028000 CR4: 0000000000750ee0
PKRU: 55555554
--
Best Regards,
Mike Gavrilov.
Hi Mikhail,
On Tue, Jan 18, 2022 at 04:26:27PM +0500, Mikhail Gavrilov wrote:
> On Mon, 17 Jan 2022 at 17:21, Heikki Krogerus
> <[email protected]> wrote:
> >
> > Have you modified the file, or something else that you have not
> > committed yet?
> >
> > % git status
> >
> > Checkout the file, and then try to apply the patch:
> >
> > % git checkout drivers/usb/typec/port-mapper.c
> > % git apply -v 0001-usb-typec-Test-fix.patch
> >
>
> I understood why the patch was not applied. The "Window line endings"
> in the attached file were.
>
> $ dos2unix 0001-usb-typec-Test-fix.patch
> dos2unix: converting file 0001-usb-typec-Test-fix.patch to Unix format...
> $ git apply -v 0001-usb-typec-Test-fix.patch
> Checking patch drivers/usb/typec/port-mapper.c...
> Applied patch drivers/usb/typec/port-mapper.c cleanly.
Oh, I'm sorry. Something corrupted the patch, which is a bit alarming,
but good that you managed to test it in any case.
> Unfortunately the attached patch didn't fix the issue.
>
> BUG: kernel NULL pointer dereference, address: 0000000000000008
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> PGD 0 P4D 0
> Oops: 0000 [#1] PREEMPT SMP NOPTI
> CPU: 10 PID: 459 Comm: kworker/10:2 Not tainted
> 5.16.0-patched-455e73a07f6e+ #26
> Hardware name: ASUSTeK COMPUTER INC. ROG Strix G513QY_G513QY/G513QY,
> BIOS G513QY.316 11/29/2021
> Workqueue: events_long ucsi_init_work [typec_ucsi]
> RIP: 0010:component_master_add_with_match+0x14/0x110
> Code: 72 d7 48 89 ef 5b 5d e9 1a 5c 9f ff 66 2e 0f 1f 84 00 00 00 00
> 00 0f 1f 44 00 00 41 55 49 89 fd 41 54 49 89 f4 55 53 48 89 d3 <48> 8b
> 72 08 48 3b 32 74 10 48 89 d7 e8 4b fd ff ff 85 c0 0f 85 bb
> RSP: 0018:ffffba4581837d90 EFLAGS: 00010282
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffffffffc04f58d0 RDI: ffff9c5afe43a808
> RBP: ffff9c5a81076358 R08: 0000000000000001 R09: 0000000000000001
> R10: 0000000000000001 R11: 0000000000000000 R12: ffffffffc04f58d0
> R13: ffff9c5afe43a808 R14: ffff9c5afe43a808 R15: ffff9c5a832c4010
> FS: 0000000000000000(0000) GS:ffff9c5d88a00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000008 CR3: 00000002e5028000 CR4: 0000000000750ee0
> PKRU: 55555554
> Call Trace:
> <TASK>
> typec_link_ports+0x5d/0x70 [typec]
> typec_register_port+0x1e6/0x2e0 [typec]
> ucsi_init_work+0x463/0x840 [typec_ucsi]
> process_one_work+0x2bb/0x600
> worker_thread+0x55/0x3b0
> ? process_one_work+0x600/0x600
> kthread+0x17c/0x1a0
> ? set_kthread_struct+0x40/0x40
> ret_from_fork+0x22/0x30
> </TASK>
This is not the same issue, this is another bug :-(. The original
issue does seem to be fixed.
I can reproduce this one by simply not creating the component list in
the code. That function - component_master_add_with_match() - can't
handle situation where the list is empty. I'll prepare the fix.
Thanks,
--
heikki
On Tue, Jan 18, 2022 at 03:12:10PM +0200, Heikki Krogerus wrote:
> Hi Mikhail,
>
> On Tue, Jan 18, 2022 at 04:26:27PM +0500, Mikhail Gavrilov wrote:
> > On Mon, 17 Jan 2022 at 17:21, Heikki Krogerus
> > <[email protected]> wrote:
> > >
> > > Have you modified the file, or something else that you have not
> > > committed yet?
> > >
> > > % git status
> > >
> > > Checkout the file, and then try to apply the patch:
> > >
> > > % git checkout drivers/usb/typec/port-mapper.c
> > > % git apply -v 0001-usb-typec-Test-fix.patch
> > >
> >
> > I understood why the patch was not applied. The "Window line endings"
> > in the attached file were.
> >
> > $ dos2unix 0001-usb-typec-Test-fix.patch
> > dos2unix: converting file 0001-usb-typec-Test-fix.patch to Unix format...
> > $ git apply -v 0001-usb-typec-Test-fix.patch
> > Checking patch drivers/usb/typec/port-mapper.c...
> > Applied patch drivers/usb/typec/port-mapper.c cleanly.
>
> Oh, I'm sorry. Something corrupted the patch, which is a bit alarming,
> but good that you managed to test it in any case.
>
> > Unfortunately the attached patch didn't fix the issue.
> >
> > BUG: kernel NULL pointer dereference, address: 0000000000000008
> > #PF: supervisor read access in kernel mode
> > #PF: error_code(0x0000) - not-present page
> > PGD 0 P4D 0
> > Oops: 0000 [#1] PREEMPT SMP NOPTI
> > CPU: 10 PID: 459 Comm: kworker/10:2 Not tainted
> > 5.16.0-patched-455e73a07f6e+ #26
> > Hardware name: ASUSTeK COMPUTER INC. ROG Strix G513QY_G513QY/G513QY,
> > BIOS G513QY.316 11/29/2021
> > Workqueue: events_long ucsi_init_work [typec_ucsi]
> > RIP: 0010:component_master_add_with_match+0x14/0x110
> > Code: 72 d7 48 89 ef 5b 5d e9 1a 5c 9f ff 66 2e 0f 1f 84 00 00 00 00
> > 00 0f 1f 44 00 00 41 55 49 89 fd 41 54 49 89 f4 55 53 48 89 d3 <48> 8b
> > 72 08 48 3b 32 74 10 48 89 d7 e8 4b fd ff ff 85 c0 0f 85 bb
> > RSP: 0018:ffffba4581837d90 EFLAGS: 00010282
> > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> > RDX: 0000000000000000 RSI: ffffffffc04f58d0 RDI: ffff9c5afe43a808
> > RBP: ffff9c5a81076358 R08: 0000000000000001 R09: 0000000000000001
> > R10: 0000000000000001 R11: 0000000000000000 R12: ffffffffc04f58d0
> > R13: ffff9c5afe43a808 R14: ffff9c5afe43a808 R15: ffff9c5a832c4010
> > FS: 0000000000000000(0000) GS:ffff9c5d88a00000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 0000000000000008 CR3: 00000002e5028000 CR4: 0000000000750ee0
> > PKRU: 55555554
> > Call Trace:
> > <TASK>
> > typec_link_ports+0x5d/0x70 [typec]
> > typec_register_port+0x1e6/0x2e0 [typec]
> > ucsi_init_work+0x463/0x840 [typec_ucsi]
> > process_one_work+0x2bb/0x600
> > worker_thread+0x55/0x3b0
> > ? process_one_work+0x600/0x600
> > kthread+0x17c/0x1a0
> > ? set_kthread_struct+0x40/0x40
> > ret_from_fork+0x22/0x30
> > </TASK>
>
> This is not the same issue, this is another bug :-(. The original
> issue does seem to be fixed.
>
> I can reproduce this one by simply not creating the component list in
> the code. That function - component_master_add_with_match() - can't
> handle situation where the list is empty. I'll prepare the fix.
I'm again attaching the proposed fix, just to see if it also gets
corrupted. Can you test does it fix this issue?
You need to apply it on top of the previous one.
thanks,
--
heikki
On Tue, 18 Jan 2022 at 18:33, Heikki Krogerus
<[email protected]> wrote:
>
> I'm again attaching the proposed fix, just to see if it also gets
> corrupted. Can you test does it fix this issue?
> You need to apply it on top of the previous one.
>
Finally it was fixed with the latest addition to the initial patch.
Thanks.
--
Best Regards,
Mike Gavrilov.
On Thu, Jan 20, 2022 at 3:27 AM Heikki Krogerus
<[email protected]> wrote:
> On Tue, Jan 18, 2022 at 03:12:10PM +0200, Heikki Krogerus wrote:
> > I can reproduce this one by simply not creating the component list in
> > the code. That function - component_master_add_with_match() - can't
> > handle situation where the list is empty. I'll prepare the fix.
>
> I'm again attaching the proposed fix, just to see if it also gets
> corrupted. Can you test does it fix this issue?
> You need to apply it on top of the previous one.
We've been hitting the null pointer crash from
component_master_add_with_match() regression as well on the hikey960
board.
The patch you attached resolves the issue. It would be great to see it
merged upstream soon!
Tested-by: John Stultz <[email protected]>
thanks
-john
Tested-by: Len Brown <len.brown@intelcom>
The typec_link_ports crash goes away w/ the 2nd patch.
https://bugzilla.kernel.org/show_bug.cgi?id=215529
On Fri, Jan 21, 2022 at 4:33 PM John Stultz <[email protected]> wrote:
>
> On Thu, Jan 20, 2022 at 3:27 AM Heikki Krogerus
> <[email protected]> wrote:
> > On Tue, Jan 18, 2022 at 03:12:10PM +0200, Heikki Krogerus wrote:
> > > I can reproduce this one by simply not creating the component list in
> > > the code. That function - component_master_add_with_match() - can't
> > > handle situation where the list is empty. I'll prepare the fix.
> >
> > I'm again attaching the proposed fix, just to see if it also gets
> > corrupted. Can you test does it fix this issue?
> > You need to apply it on top of the previous one.
>
> We've been hitting the null pointer crash from
> component_master_add_with_match() regression as well on the hikey960
> board.
>
> The patch you attached resolves the issue. It would be great to see it
> merged upstream soon!
>
> Tested-by: John Stultz <[email protected]>
>
> thanks
> -john
--
Len Brown, Intel Open Source Technology Center
On Mon, Jan 24, 2022 at 06:00:24PM -0500, Len Brown wrote:
> Tested-by: Len Brown <len.brown@intelcom>
>
> The typec_link_ports crash goes away w/ the 2nd patch.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=215529
That patch was already sent out:
https://lore.kernel.org/linux-usb/[email protected]/
thanks,
> On Fri, Jan 21, 2022 at 4:33 PM John Stultz <[email protected]> wrote:
> >
> > On Thu, Jan 20, 2022 at 3:27 AM Heikki Krogerus
> > <[email protected]> wrote:
> > > On Tue, Jan 18, 2022 at 03:12:10PM +0200, Heikki Krogerus wrote:
> > > > I can reproduce this one by simply not creating the component list in
> > > > the code. That function - component_master_add_with_match() - can't
> > > > handle situation where the list is empty. I'll prepare the fix.
> > >
> > > I'm again attaching the proposed fix, just to see if it also gets
> > > corrupted. Can you test does it fix this issue?
> > > You need to apply it on top of the previous one.
> >
> > We've been hitting the null pointer crash from
> > component_master_add_with_match() regression as well on the hikey960
> > board.
> >
> > The patch you attached resolves the issue. It would be great to see it
> > merged upstream soon!
> >
> > Tested-by: John Stultz <[email protected]>
> >
> > thanks
> > -john
>
> --
> Len Brown, Intel Open Source Technology Center
--
heikki