Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reenable CONFIG_E1000_DELAY #77

Closed
wants to merge 2 commits into from
Closed

Reenable CONFIG_E1000_DELAY #77

wants to merge 2 commits into from

Conversation

shruthi-ravi
Copy link

Commit a555b1a added a delay after long writes on PREEMPT_RT-enabled
kernels, but using the PREEMPT_RT_FULL option, which has since been
replaced by just PREEMPT_RT.
Therefore,

  • update the delay condition to check on PREEMPT_RT instead.
  • readd CONFIG_E1000_DELAY to nati_x86_64_defconfig

AzDO WI: 2114543

@shruthi-ravi
e1000e: Replace PREEMPT_RT_FULL with PREEMPT_RT
db0eb18 
Commit a555b1a added a delay after long writes on PREEMPT_RT-enabled
kernels, but using the PREEMPT_RT_FULL option, which has since been
replaced by just PREEMPT_RT.
Therefore, update the delay condition to check on PREEMPT_RT instead.

Signed-off-by: Shruthi Ravichandran <shruthi.ravichandran@ni.com>
@shruthi-ravi
nati_x86_64_defconfig: enable CONFIG_E1000_DELAY
a9017ce 
CONFIG_E1000_DELAY depended on PREEMPT_RT_FULL, which has since been
replaced by PREEMPT_RT. Now that the Kconfig depends has been fixed
for this config, enable CONFIG_E1000_DELAY.

Signed-off-by: Shruthi Ravichandran <shruthi.ravichandran@ni.com>
@shruthi-ravi shruthi-ravi requested a review from gratian August 30, 2022 16:36
@gratian
Copy link
Contributor

gratian commented Aug 31, 2022

Rebased on top of latest nilrt/master/5.15 to account for PR #75, and submitted as commits:

  • 3425c3b ("nati_x86_64_defconfig: enable CONFIG_E1000_DELAY")
  • 50ffc1c ("e1000e: Replace PREEMPT_RT_FULL with PREEMPT_RT")

@gratian gratian closed this Aug 31, 2022
@amstewart amstewart mentioned this pull request Sep 1, 2022
Merged
mike-petersen-ni pushed a commit to mike-petersen-ni/linux that referenced this pull request Jan 9, 2023
@pberuto @gregkh
stmmac: fix potential division by 0
0abd337 
[ Upstream commit ede5a38 ]

When the MAC is connected to a 10 Mb/s PHY and the PTP clock is derived
from the MAC reference clock (default), the clk_ptp_rate becomes too
small and the calculated sub second increment becomes 0 when computed by
the stmmac_config_sub_second_increment() function within
stmmac_init_tstamp_counter().

Therefore, the subsequent div_u64 in stmmac_init_tstamp_counter()
operation triggers a divide by 0 exception as shown below.

[   95.062067] socfpga-dwmac ff700000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   95.076440] socfpga-dwmac ff700000.ethernet eth0: PHY [stmmac-0:08] driver [NCN26000] (irq=49)
[   95.095964] dwmac1000: Master AXI performs any burst length
[   95.101588] socfpga-dwmac ff700000.ethernet eth0: No Safety Features support found
[   95.109428] Division by zero in kernel.
[   95.113447] CPU: 0 PID: 239 Comm: ifconfig Not tainted 6.1.0-rc7-centurion3-1.0.3.0-01574-gb624218205b7-dirty ni#77
[   95.123686] Hardware name: Altera SOCFPGA
[   95.127695]  unwind_backtrace from show_stack+0x10/0x14
[   95.132938]  show_stack from dump_stack_lvl+0x40/0x4c
[   95.137992]  dump_stack_lvl from Ldiv0+0x8/0x10
[   95.142527]  Ldiv0 from __aeabi_uidivmod+0x8/0x18
[   95.147232]  __aeabi_uidivmod from div_u64_rem+0x1c/0x40
[   95.152552]  div_u64_rem from stmmac_init_tstamp_counter+0xd0/0x164
[   95.158826]  stmmac_init_tstamp_counter from stmmac_hw_setup+0x430/0xf00
[   95.165533]  stmmac_hw_setup from __stmmac_open+0x214/0x2d4
[   95.171117]  __stmmac_open from stmmac_open+0x30/0x44
[   95.176182]  stmmac_open from __dev_open+0x11c/0x134
[   95.181172]  __dev_open from __dev_change_flags+0x168/0x17c
[   95.186750]  __dev_change_flags from dev_change_flags+0x14/0x50
[   95.192662]  dev_change_flags from devinet_ioctl+0x2b4/0x604
[   95.198321]  devinet_ioctl from inet_ioctl+0x1ec/0x214
[   95.203462]  inet_ioctl from sock_ioctl+0x14c/0x3c4
[   95.208354]  sock_ioctl from vfs_ioctl+0x20/0x38
[   95.212984]  vfs_ioctl from sys_ioctl+0x250/0x844
[   95.217691]  sys_ioctl from ret_fast_syscall+0x0/0x4c
[   95.222743] Exception stack(0xd0ee1fa8 to 0xd0ee1ff0)
[   95.227790] 1fa0:                   00574c4f be9aeca4 00000003 00008914 be9aeca4 be9aec50
[   95.235945] 1fc0: 00574c4f be9aeca4 0059f078 00000036 be9aee8c be9aef7a 00000015 00000000
[   95.244096] 1fe0: 005a01f0 be9aec38 004d7484 b6e67d74

Signed-off-by: Piergiorgio Beruto <piergiorgio.beruto@gmail.com>
Fixes: 91a2559 ("net: stmmac: Fix sub-second increment")
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/de4c64ccac9084952c56a06a8171d738604c4770.1670678513.git.piergiorgio.beruto@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
gratian pushed a commit to gratian/linux that referenced this pull request Feb 28, 2024
@gregkh
bpf: Fix a few selftest failures due to llvm18 change
e02851a 
[ Upstream commit b16904f ]

With latest upstream llvm18, the following test cases failed:

  $ ./test_progs -j
  ni#13/2    bpf_cookie/multi_kprobe_link_api:FAIL
  ni#13/3    bpf_cookie/multi_kprobe_attach_api:FAIL
  ni#13      bpf_cookie:FAIL
  ni#77      fentry_fexit:FAIL
  ni#78/1    fentry_test/fentry:FAIL
  ni#78      fentry_test:FAIL
  ni#82/1    fexit_test/fexit:FAIL
  ni#82      fexit_test:FAIL
  ni#112/1   kprobe_multi_test/skel_api:FAIL
  ni#112/2   kprobe_multi_test/link_api_addrs:FAIL
  [...]
  ni#112     kprobe_multi_test:FAIL
  #356/17  test_global_funcs/global_func17:FAIL
  #356     test_global_funcs:FAIL

Further analysis shows llvm upstream patch [1] is responsible for the above
failures. For example, for function bpf_fentry_test7() in net/bpf/test_run.c,
without [1], the asm code is:

  0000000000000400 <bpf_fentry_test7>:
     400: f3 0f 1e fa                   endbr64
     404: e8 00 00 00 00                callq   0x409 <bpf_fentry_test7+0x9>
     409: 48 89 f8                      movq    %rdi, %rax
     40c: c3                            retq
     40d: 0f 1f 00                      nopl    (%rax)

... and with [1], the asm code is:

  0000000000005d20 <bpf_fentry_test7.specialized.1>:
    5d20: e8 00 00 00 00                callq   0x5d25 <bpf_fentry_test7.specialized.1+0x5>
    5d25: c3                            retq

... and <bpf_fentry_test7.specialized.1> is called instead of <bpf_fentry_test7>
and this caused test failures for ni#13/ni#77 etc. except #356.

For test case #356/17, with [1] (progs/test_global_func17.c)), the main prog
looks like:

  0000000000000000 <global_func17>:
       0:       b4 00 00 00 2a 00 00 00 w0 = 0x2a
       1:       95 00 00 00 00 00 00 00 exit

... which passed verification while the test itself expects a verification
failure.

Let us add 'barrier_var' style asm code in both places to prevent function
specialization which caused selftests failure.

  [1] llvm/llvm-project#72903

Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20231127050342.1945270-1-yonghong.song@linux.dev
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@gratian gratian gratian approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@shruthi-ravi @gratian