* ice: General protection fault in ptp_clock_index @ 2025-07-24 20:25 Frederick Lawler 2025-07-28 16:18 ` Jesse Brandeburg 0 siblings, 1 reply; 4+ messages in thread From: Frederick Lawler @ 2025-07-24 20:25 UTC (permalink / raw) To: Tony Nguyen, Przemek Kitszel Cc: netdev, linux-kernel, AndrewLunn, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, kernel-team, jbrandeburg Hi, On Linux 6.12.39, we appear to hit a race reading ethtool while the device is removed. We have automation to remove unused interfaces during early boot process, and when systemd is restarting the network afterwards, we get a page fault and get into a boot-crash-loop state. We're currently renaming the interface to something like unused0 to circumvent the issue. I was able to reproduce with the following snippet: $ watch -n0.1 /sbin/ethtool -T ext0 $ echo -n "1" | sudo tee /sys/class/net/ext0/device/remove ice 0000:41:00.0: Removed PTP clock ... Oops: general protection fault, probably for non-canonical address 0xae09e2b3b0c665f1: 0000 [#1] PREEMPT SMP NOPTI Tainted: [O]=OOT_MODULE Hardware name: Lenovo HR355M-V3-G12/HR355M_V3_HPM, BIOS HR355M_V3.G.031 02/17/2025 RIP: 0010:ptp_clock_index (drivers/ptp/ptp_clock.c:476 (discriminator 1)) Code: 38 1b 4e 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 <8b> 87 94 03 00 00 e9 07 1b 4e 00 66 66 2e 0f 1f 84 00 00 00 00 00 All code ======== 0: 38 1b cmp %bl,(%rbx) 2: 4e 00 66 66 rex.WRX add %r12b,0x66(%rsi) 6: 2e 0f 1f 84 00 00 00 cs nopl 0x0(%rax,%rax,1) d: 00 00 f: 66 90 xchg %ax,%ax 11: 90 nop 12: 90 nop 13: 90 nop 14: 90 nop 15: 90 nop 16: 90 nop 17: 90 nop 18: 90 nop 19: 90 nop 1a: 90 nop 1b: 90 nop 1c: 90 nop 1d: 90 nop 1e: 90 nop 1f: 90 nop 20: 90 nop 21: f3 0f 1e fa endbr64 25: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 2a:* 8b 87 94 03 00 00 mov 0x394(%rdi),%eax <-- trapping instruction 30: e9 07 1b 4e 00 jmp 0x4e1b3c 35: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1) 3c: 00 00 00 00 Code starting with the faulting instruction =========================================== 0: 8b 87 94 03 00 00 mov 0x394(%rdi),%eax 6: e9 07 1b 4e 00 jmp 0x4e1b12 b: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1) 12: 00 00 00 00 RSP: 0018:ffffb5664f657c88 EFLAGS: 00010282 RAX: ffff9f4854c201a0 RBX: ffffb5664f657d34 RCX: ffffffffc1c6a5c0 RDX: 555485607aaada55 RSI: ffffb5664f657d34 RDI: ae09e2b3b0c6625d RBP: ffffb5664f657df0 R08: 0000000000000000 R09: ffff9f3124c570a8 R10: ffffb5664f657cc0 R11: 0000000000000001 R12: ffffffffafab4680 R13: 00007ffc828fdbb0 R14: ffff9f3124c57000 R15: ffffb5664f657d80 FS: 00007ff5abba1340(0000) GS:ffff9f402f600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff5ac03f0c0 CR3: 0000000a8768e006 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> ice_get_ts_info (drivers/net/ethernet/intel/ice/ice_ethtool.c:3776 (discriminator 1)) ice __ethtool_get_ts_info (net/ethtool/common.c:713) __ethtool_get_ts_info (net/ethtool/common.c:713) dev_ethtool (net/ethtool/ioctl.c:2651 net/ethtool/ioctl.c:3312 net/ethtool/ioctl.c:3390) ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:182) ? trace_call_bpf (kernel/trace/bpf_trace.c:151 (discriminator 38)) ? security_file_ioctl (security/security.c:2909) ? trace_call_bpf (kernel/trace/bpf_trace.c:151 (discriminator 38)) ? __x64_sys_ioctl (fs/ioctl.c:893) ? kprobe_ftrace_handler (arch/x86/kernel/kprobes/ftrace.c:45 (discriminator 1)) ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:182) dev_ioctl (net/core/dev_ioctl.c:720) sock_ioctl (net/socket.c:1242 net/socket.c:1346) __x64_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:907 fs/ioctl.c:893 fs/ioctl.c:893) osnoise_arch_unregister (??:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7ff5abe13d1b Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00 All code ======== 0: 00 48 89 add %cl,-0x77(%rax) 3: 44 24 18 rex.R and $0x18,%al 6: 31 c0 xor %eax,%eax 8: 48 8d 44 24 60 lea 0x60(%rsp),%rax d: c7 04 24 10 00 00 00 movl $0x10,(%rsp) 14: 48 89 44 24 08 mov %rax,0x8(%rsp) 19: 48 8d 44 24 20 lea 0x20(%rsp),%rax 1e: 48 89 44 24 10 mov %rax,0x10(%rsp) 23: b8 10 00 00 00 mov $0x10,%eax 28: 0f 05 syscall 2a:* 89 c2 mov %eax,%edx <-- trapping instruction 2c: 3d 00 f0 ff ff cmp $0xfffff000,%eax 31: 77 1c ja 0x4f 33: 48 8b 44 24 18 mov 0x18(%rsp),%rax 38: 64 fs 39: 48 rex.W 3a: 2b .byte 0x2b 3b: 04 25 add $0x25,%al 3d: 28 00 sub %al,(%rax) ... Code starting with the faulting instruction =========================================== 0: 89 c2 mov %eax,%edx 2: 3d 00 f0 ff ff cmp $0xfffff000,%eax 7: 77 1c ja 0x25 9: 48 8b 44 24 18 mov 0x18(%rsp),%rax e: 64 fs f: 48 rex.W 10: 2b .byte 0x2b 11: 04 25 add $0x25,%al 13: 28 00 sub %al,(%rax) ... RSP: 002b:00007ffc828fdb20 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000056370e675800 RCX: 00007ff5abe13d1b RDX: 00007ffc828fdb80 RSI: 0000000000008946 RDI: 0000000000000005 RBP: 000056370e6757e0 R08: 00007ff5abee8c60 R09: 0000000000000000 R10: 00007ff5abd2f310 R11: 0000000000000246 R12: 00007ffc828fdd80 R13: 0000000000000005 R14: 00007ffc828fdb80 R15: 00007ffc828fff1a </TASK> ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ice: General protection fault in ptp_clock_index 2025-07-24 20:25 ice: General protection fault in ptp_clock_index Frederick Lawler @ 2025-07-28 16:18 ` Jesse Brandeburg 2025-07-31 11:01 ` [Intel-wired-lan] " Nitka, Grzegorz 0 siblings, 1 reply; 4+ messages in thread From: Jesse Brandeburg @ 2025-07-28 16:18 UTC (permalink / raw) To: Frederick Lawler, Tony Nguyen, Przemek Kitszel Cc: netdev, linux-kernel, AndrewLunn, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, kernel-team, intel-wired-lan +IWL Hi Intel team, anyone have an idea on this? Looks like maybe removal of device 0 that had originally registered PTP clock isn't handled well? On 7/24/25 1:25 PM, Frederick Lawler wrote: > Hi, > > On Linux 6.12.39, we appear to hit a race reading ethtool while the > device is removed. > > We have automation to remove unused interfaces during early boot > process, and when systemd is restarting the network afterwards, we > get a page fault and get into a boot-crash-loop state. We're currently > renaming the interface to something like unused0 to circumvent the > issue. > > I was able to reproduce with the following snippet: > > $ watch -n0.1 /sbin/ethtool -T ext0 > $ echo -n "1" | sudo tee /sys/class/net/ext0/device/remove > > ice 0000:41:00.0: Removed PTP clock > > ... > > Oops: general protection fault, probably for non-canonical address 0xae09e2b3b0c665f1: 0000 [#1] PREEMPT SMP NOPTI > Tainted: [O]=OOT_MODULE > Hardware name: Lenovo HR355M-V3-G12/HR355M_V3_HPM, BIOS HR355M_V3.G.031 02/17/2025 > RIP: 0010:ptp_clock_index (drivers/ptp/ptp_clock.c:476 (discriminator 1)) > Code: 38 1b 4e 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 <8b> 87 94 03 00 00 e9 07 1b 4e 00 66 66 2e 0f 1f 84 00 00 00 00 00 > All code > ======== > 0: 38 1b cmp %bl,(%rbx) > 2: 4e 00 66 66 rex.WRX add %r12b,0x66(%rsi) > 6: 2e 0f 1f 84 00 00 00 cs nopl 0x0(%rax,%rax,1) > d: 00 00 > f: 66 90 xchg %ax,%ax > 11: 90 nop > 12: 90 nop > 13: 90 nop > 14: 90 nop > 15: 90 nop > 16: 90 nop > 17: 90 nop > 18: 90 nop > 19: 90 nop > 1a: 90 nop > 1b: 90 nop > 1c: 90 nop > 1d: 90 nop > 1e: 90 nop > 1f: 90 nop > 20: 90 nop > 21: f3 0f 1e fa endbr64 > 25: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) > 2a:* 8b 87 94 03 00 00 mov 0x394(%rdi),%eax <-- trapping instruction > 30: e9 07 1b 4e 00 jmp 0x4e1b3c > 35: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1) > 3c: 00 00 00 00 > > Code starting with the faulting instruction > =========================================== > 0: 8b 87 94 03 00 00 mov 0x394(%rdi),%eax > 6: e9 07 1b 4e 00 jmp 0x4e1b12 > b: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1) > 12: 00 00 00 00 > RSP: 0018:ffffb5664f657c88 EFLAGS: 00010282 > RAX: ffff9f4854c201a0 RBX: ffffb5664f657d34 RCX: ffffffffc1c6a5c0 > RDX: 555485607aaada55 RSI: ffffb5664f657d34 RDI: ae09e2b3b0c6625d > RBP: ffffb5664f657df0 R08: 0000000000000000 R09: ffff9f3124c570a8 > R10: ffffb5664f657cc0 R11: 0000000000000001 R12: ffffffffafab4680 > R13: 00007ffc828fdbb0 R14: ffff9f3124c57000 R15: ffffb5664f657d80 > FS: 00007ff5abba1340(0000) GS:ffff9f402f600000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007ff5ac03f0c0 CR3: 0000000a8768e006 CR4: 0000000000770ef0 > PKRU: 55555554 > Call Trace: > <TASK> > ice_get_ts_info (drivers/net/ethernet/intel/ice/ice_ethtool.c:3776 (discriminator 1)) ice > __ethtool_get_ts_info (net/ethtool/common.c:713) > __ethtool_get_ts_info (net/ethtool/common.c:713) > dev_ethtool (net/ethtool/ioctl.c:2651 net/ethtool/ioctl.c:3312 net/ethtool/ioctl.c:3390) > ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:182) > ? trace_call_bpf (kernel/trace/bpf_trace.c:151 (discriminator 38)) > ? security_file_ioctl (security/security.c:2909) > ? trace_call_bpf (kernel/trace/bpf_trace.c:151 (discriminator 38)) > ? __x64_sys_ioctl (fs/ioctl.c:893) > ? kprobe_ftrace_handler (arch/x86/kernel/kprobes/ftrace.c:45 (discriminator 1)) > ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:182) > dev_ioctl (net/core/dev_ioctl.c:720) > sock_ioctl (net/socket.c:1242 net/socket.c:1346) > __x64_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:907 fs/ioctl.c:893 fs/ioctl.c:893) > osnoise_arch_unregister (??:?) > entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) > RIP: 0033:0x7ff5abe13d1b > Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00 > All code > ======== > 0: 00 48 89 add %cl,-0x77(%rax) > 3: 44 24 18 rex.R and $0x18,%al > 6: 31 c0 xor %eax,%eax > 8: 48 8d 44 24 60 lea 0x60(%rsp),%rax > d: c7 04 24 10 00 00 00 movl $0x10,(%rsp) > 14: 48 89 44 24 08 mov %rax,0x8(%rsp) > 19: 48 8d 44 24 20 lea 0x20(%rsp),%rax > 1e: 48 89 44 24 10 mov %rax,0x10(%rsp) > 23: b8 10 00 00 00 mov $0x10,%eax > 28: 0f 05 syscall > 2a:* 89 c2 mov %eax,%edx <-- trapping instruction > 2c: 3d 00 f0 ff ff cmp $0xfffff000,%eax > 31: 77 1c ja 0x4f > 33: 48 8b 44 24 18 mov 0x18(%rsp),%rax > 38: 64 fs > 39: 48 rex.W > 3a: 2b .byte 0x2b > 3b: 04 25 add $0x25,%al > 3d: 28 00 sub %al,(%rax) > ... > > Code starting with the faulting instruction > =========================================== > 0: 89 c2 mov %eax,%edx > 2: 3d 00 f0 ff ff cmp $0xfffff000,%eax > 7: 77 1c ja 0x25 > 9: 48 8b 44 24 18 mov 0x18(%rsp),%rax > e: 64 fs > f: 48 rex.W > 10: 2b .byte 0x2b > 11: 04 25 add $0x25,%al > 13: 28 00 sub %al,(%rax) > ... > RSP: 002b:00007ffc828fdb20 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > RAX: ffffffffffffffda RBX: 000056370e675800 RCX: 00007ff5abe13d1b > RDX: 00007ffc828fdb80 RSI: 0000000000008946 RDI: 0000000000000005 > RBP: 000056370e6757e0 R08: 00007ff5abee8c60 R09: 0000000000000000 > R10: 00007ff5abd2f310 R11: 0000000000000246 R12: 00007ffc828fdd80 > R13: 0000000000000005 R14: 00007ffc828fdb80 R15: 00007ffc828fff1a > </TASK> > ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [Intel-wired-lan] ice: General protection fault in ptp_clock_index 2025-07-28 16:18 ` Jesse Brandeburg @ 2025-07-31 11:01 ` Nitka, Grzegorz 2025-10-20 22:02 ` Jesse Brandeburg 0 siblings, 1 reply; 4+ messages in thread From: Nitka, Grzegorz @ 2025-07-31 11:01 UTC (permalink / raw) To: Brandeburg, Jesse, Frederick Lawler, Nguyen, Anthony L, Kitszel, Przemyslaw Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, AndrewLunn, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, kernel-team@cloudflare.com, intel-wired-lan@lists.osuosl.org > -----Original Message----- > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of > Jesse Brandeburg > Sent: Monday, July 28, 2025 6:19 PM > To: Frederick Lawler <fred@cloudflare.com>; Nguyen, Anthony L > <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw > <przemyslaw.kitszel@intel.com> > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; AndrewLunn > <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric > Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; > Paolo Abeni <pabeni@redhat.com>; kernel-team@cloudflare.com; intel- > wired-lan@lists.osuosl.org > Subject: Re: [Intel-wired-lan] ice: General protection fault in ptp_clock_index > > +IWL > > Hi Intel team, anyone have an idea on this? Looks like maybe removal of > device 0 that had originally registered PTP clock isn't handled well? > Hi All, Thank you for your message. We're looking into this. Yes, at first sight it seems to be a race condition hit while removing PF which is PTP owner (and responsible for removing PTP clock). Kind regards Grzegorz > On 7/24/25 1:25 PM, Frederick Lawler wrote: > > Hi, > > > > On Linux 6.12.39, we appear to hit a race reading ethtool while the > > device is removed. > > > > We have automation to remove unused interfaces during early boot > > process, and when systemd is restarting the network afterwards, we > > get a page fault and get into a boot-crash-loop state. We're currently > > renaming the interface to something like unused0 to circumvent the > > issue. > > > > I was able to reproduce with the following snippet: > > > > $ watch -n0.1 /sbin/ethtool -T ext0 > > $ echo -n "1" | sudo tee /sys/class/net/ext0/device/remove > > > > ice 0000:41:00.0: Removed PTP clock > > > > ... > > > > Oops: general protection fault, probably for non-canonical address > 0xae09e2b3b0c665f1: 0000 [#1] PREEMPT SMP NOPTI > > Tainted: [O]=OOT_MODULE > > Hardware name: Lenovo HR355M-V3-G12/HR355M_V3_HPM, BIOS > HR355M_V3.G.031 02/17/2025 > > RIP: 0010:ptp_clock_index (drivers/ptp/ptp_clock.c:476 (discriminator 1)) > > Code: 38 1b 4e 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 90 90 90 90 90 90 90 > 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 <8b> 87 94 03 00 00 e9 07 1b > 4e 00 66 66 2e 0f 1f 84 00 00 00 00 00 > > All code > > ======== > > 0: 38 1b cmp %bl,(%rbx) > > 2: 4e 00 66 66 rex.WRX add %r12b,0x66(%rsi) > > 6: 2e 0f 1f 84 00 00 00 cs nopl 0x0(%rax,%rax,1) > > d: 00 00 > > f: 66 90 xchg %ax,%ax > > 11: 90 nop > > 12: 90 nop > > 13: 90 nop > > 14: 90 nop > > 15: 90 nop > > 16: 90 nop > > 17: 90 nop > > 18: 90 nop > > 19: 90 nop > > 1a: 90 nop > > 1b: 90 nop > > 1c: 90 nop > > 1d: 90 nop > > 1e: 90 nop > > 1f: 90 nop > > 20: 90 nop > > 21: f3 0f 1e fa endbr64 > > 25: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) > > 2a:* 8b 87 94 03 00 00 mov 0x394(%rdi),%eax <-- > trapping instruction > > 30: e9 07 1b 4e 00 jmp 0x4e1b3c > > 35: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1) > > 3c: 00 00 00 00 > > > > Code starting with the faulting instruction > > =========================================== > > 0: 8b 87 94 03 00 00 mov 0x394(%rdi),%eax > > 6: e9 07 1b 4e 00 jmp 0x4e1b12 > > b: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1) > > 12: 00 00 00 00 > > RSP: 0018:ffffb5664f657c88 EFLAGS: 00010282 > > RAX: ffff9f4854c201a0 RBX: ffffb5664f657d34 RCX: ffffffffc1c6a5c0 > > RDX: 555485607aaada55 RSI: ffffb5664f657d34 RDI: ae09e2b3b0c6625d > > RBP: ffffb5664f657df0 R08: 0000000000000000 R09: ffff9f3124c570a8 > > R10: ffffb5664f657cc0 R11: 0000000000000001 R12: ffffffffafab4680 > > R13: 00007ffc828fdbb0 R14: ffff9f3124c57000 R15: ffffb5664f657d80 > > FS: 00007ff5abba1340(0000) GS:ffff9f402f600000(0000) > knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: 00007ff5ac03f0c0 CR3: 0000000a8768e006 CR4: 0000000000770ef0 > > PKRU: 55555554 > > Call Trace: > > <TASK> > > ice_get_ts_info (drivers/net/ethernet/intel/ice/ice_ethtool.c:3776 > (discriminator 1)) ice > > __ethtool_get_ts_info (net/ethtool/common.c:713) > > __ethtool_get_ts_info (net/ethtool/common.c:713) > > dev_ethtool (net/ethtool/ioctl.c:2651 net/ethtool/ioctl.c:3312 > net/ethtool/ioctl.c:3390) > > ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:182) > > ? trace_call_bpf (kernel/trace/bpf_trace.c:151 (discriminator 38)) > > ? security_file_ioctl (security/security.c:2909) > > ? trace_call_bpf (kernel/trace/bpf_trace.c:151 (discriminator 38)) > > ? __x64_sys_ioctl (fs/ioctl.c:893) > > ? kprobe_ftrace_handler (arch/x86/kernel/kprobes/ftrace.c:45 > (discriminator 1)) > > ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:182) > > dev_ioctl (net/core/dev_ioctl.c:720) > > sock_ioctl (net/socket.c:1242 net/socket.c:1346) > > __x64_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:907 fs/ioctl.c:893 fs/ioctl.c:893) > > osnoise_arch_unregister (??:?) > > entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) > > RIP: 0033:0x7ff5abe13d1b > > Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 > 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c > 48 8b 44 24 18 64 48 2b 04 25 28 00 00 > > All code > > ======== > > 0: 00 48 89 add %cl,-0x77(%rax) > > 3: 44 24 18 rex.R and $0x18,%al > > 6: 31 c0 xor %eax,%eax > > 8: 48 8d 44 24 60 lea 0x60(%rsp),%rax > > d: c7 04 24 10 00 00 00 movl $0x10,(%rsp) > > 14: 48 89 44 24 08 mov %rax,0x8(%rsp) > > 19: 48 8d 44 24 20 lea 0x20(%rsp),%rax > > 1e: 48 89 44 24 10 mov %rax,0x10(%rsp) > > 23: b8 10 00 00 00 mov $0x10,%eax > > 28: 0f 05 syscall > > 2a:* 89 c2 mov %eax,%edx <-- trapping > instruction > > 2c: 3d 00 f0 ff ff cmp $0xfffff000,%eax > > 31: 77 1c ja 0x4f > > 33: 48 8b 44 24 18 mov 0x18(%rsp),%rax > > 38: 64 fs > > 39: 48 rex.W > > 3a: 2b .byte 0x2b > > 3b: 04 25 add $0x25,%al > > 3d: 28 00 sub %al,(%rax) > > ... > > > > Code starting with the faulting instruction > > =========================================== > > 0: 89 c2 mov %eax,%edx > > 2: 3d 00 f0 ff ff cmp $0xfffff000,%eax > > 7: 77 1c ja 0x25 > > 9: 48 8b 44 24 18 mov 0x18(%rsp),%rax > > e: 64 fs > > f: 48 rex.W > > 10: 2b .byte 0x2b > > 11: 04 25 add $0x25,%al > > 13: 28 00 sub %al,(%rax) > > ... > > RSP: 002b:00007ffc828fdb20 EFLAGS: 00000246 ORIG_RAX: > 0000000000000010 > > RAX: ffffffffffffffda RBX: 000056370e675800 RCX: 00007ff5abe13d1b > > RDX: 00007ffc828fdb80 RSI: 0000000000008946 RDI: 0000000000000005 > > RBP: 000056370e6757e0 R08: 00007ff5abee8c60 R09: 0000000000000000 > > R10: 00007ff5abd2f310 R11: 0000000000000246 R12: 00007ffc828fdd80 > > R13: 0000000000000005 R14: 00007ffc828fdb80 R15: 00007ffc828fff1a > > </TASK> > > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Intel-wired-lan] ice: General protection fault in ptp_clock_index 2025-07-31 11:01 ` [Intel-wired-lan] " Nitka, Grzegorz @ 2025-10-20 22:02 ` Jesse Brandeburg 0 siblings, 0 replies; 4+ messages in thread From: Jesse Brandeburg @ 2025-10-20 22:02 UTC (permalink / raw) To: Nitka, Grzegorz, Frederick Lawler, Nguyen, Anthony L, Kitszel, Przemyslaw Cc: netdev@vger.kernel.org, AndrewLunn, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, kernel-team@cloudflare.com, intel-wired-lan@lists.osuosl.org On 7/31/25 4:01 AM, Nitka, Grzegorz wrote: >> Hi Intel team, anyone have an idea on this? Looks like maybe removal of >> device 0 that had originally registered PTP clock isn't handled well? >> > > Hi All, > > Thank you for your message. We're looking into this. > Yes, at first sight it seems to be a race condition hit while removing PF which is PTP > owner (and responsible for removing PTP clock). Hi Intel team, any progress on this issue? BR, Jesse ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-10-20 22:02 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-07-24 20:25 ice: General protection fault in ptp_clock_index Frederick Lawler 2025-07-28 16:18 ` Jesse Brandeburg 2025-07-31 11:01 ` [Intel-wired-lan] " Nitka, Grzegorz 2025-10-20 22:02 ` Jesse Brandeburg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox