Re: NOHZ tick-stop error: local softirq work is pending, handler #08!!! on Dell XPS 13 9360
[Added URLs for files.] Am 21.08.24 um 10:20 schrieb Paul Menzel: Dear Anna-Maria, Thank you very much for the support. I was finally able to collect the data you asked for. Am 09.04.24 um 09:57 schrieb Anna-Maria Behnsen: Paul Menzel writes: […] Am 08.04.24 um 12:10 schrieb Anna-Maria Behnsen: Paul Menzel writes: On Dell XPS 13 9360/0596KF, BIOS 2.21.0 06/02/2022, with Linux 6.9- rc2+ built from commit b1e6ec0a0fd0 (Merge tag 'docs-6.9-fixes' of git://git.lwn.net/linux) the external USB-C adapter Dell DA300 stopped working (only the Ethernet port was used). Linux logged: thanks for the report. Can you please provide a trace beside the dmesg output? The following trace events should be enabled (via kernel command line): trace_event=timer:*,timer_migration:*,sched:sched_switch,sched:sched_wakeup,sched:sched_process_hang,irq:softirq_entry,irq:softirq_raise,irq:softirq_exit Unfortunately I haven’t been able to reproduce it until now. Should it happen again, I am going to try your suggestion. Thanks for letting me know. I wanted to configure that in the running system, but wasn’t able to set all of these at once with `set_event`: echo 'timer:*,timer_migration:*,sched:sched_switch,sched:sched_wakeup,sched:sched_process_hang,irq:softirq_entry,irq:softirq_raise,irq:softirq_exit' | sudo tee /sys/kernel/tracing/set_event For some reason setting them individually also did *not* work: for e in timer:* timer_migration:* sched:sched_switch sched:sched_wakeup sched:sched_process_hang irq:softirq_entry irq:softirq_raise irq:softirq_exit'; do echo "$e" | sudo tee -a /sys/kernel/tracing/set_event; done I then used echo 1 | sudo tee /sys/kernel/tracing/events/timer/enable echo 1 | sudo tee /sys/kernel/tracing/events/timer_migration/enable echo 1 | sudo tee /sys/kernel/tracing/events/sched/sched_switch/enable echo 1 | sudo tee /sys/kernel/tracing/events/sched/sched_wakeup/enable echo 1 | sudo tee /sys/kernel/tracing/events/sched/sched_process_hang/enable echo 1 | sudo tee /sys/kernel/tracing/events/irq/softirq_entry/enable echo 1 | sudo tee /sys/kernel/tracing/events/irq/softirq_raise/enable echo 1 | sudo tee /sys/kernel/tracing/events/irq/softirq_exit/enable and also had to increase the buffer to bridge the gap between the event and me noticing it: echo 96000 | sudo tee /sys/kernel/tracing/buffer_size_kb Then, with Linux v6.11-rc4-11-g521b1e7f4cf0b, I was able to get the trace for the event below: [ 7542.706299] NOHZ tick-stop error: local softirq work is pending, handler #08!!! $ sudo cat /sys/kernel/tracing/trace […] MediaPD~der #28-14000 [000] d..1. 7542.703768: hrtimer_cancel: hrtimer=8d2c9f3f MediaPD~der #28-14000 [000] . 7542.703810: hrtimer_init: hrtimer=c6f259e7 clockid=CLOCK_MONOTONIC mode=ABS MediaPD~der #28-14000 [000] d..1. 7542.703812: hrtimer_start: hrtimer=c6f259e7 function=hrtimer_wakeup expires=7602581538204 softexpires=7602581488204 mode=ABS MediaPD~der #28-14000 [000] d..2. 7542.703821: sched_switch: prev_comm=MediaPD~der #28 prev_pid=14000 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120 -0 [000] dN.2. 7542.703931: sched_wakeup: comm=ImageBridgeChld pid=6041 prio=120 target_cpu=000 -0 [000] d..2. 7542.703937: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=ImageBridgeChld next_pid=6041 next_prio=120 ImageBridgeChld-6041 [000] d..2. 7542.704041: sched_switch: prev_comm=ImageBridgeChld prev_pid=6041 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120 -0 [000] dN.2. 7542.704174: sched_wakeup: comm=Renderer pid=4113 prio=120 target_cpu=000 -0 [000] d..2. 7542.704179: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=Renderer next_pid=4113 next_prio=120 Renderer-4113 [000] d..2. 7542.704245: sched_switch: prev_comm=Renderer prev_pid=4113 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120 -0 [000] dNh2. 7542.704260: sched_wakeup: comm=IPC I/O Child pid=6029 prio=120 target_cpu=000 -0 [000] d..2. 7542.704267: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=IPC I/O Child next_pid=6029 next_prio=120 IPC I/O Child-6029 [000] d..2. 7542.704340: sched_switch: prev_comm=IPC I/O Child prev_pid=6029 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120 -0 [000] dN.2. 7542.704786: sched_wakeup: comm=Compositor pid=4123 prio=120 target_cpu=000 -0 [000] d..2. 7542.704791: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=Compositor next_pid=4123 next_prio=120
Re: NOHZ tick-stop error: local softirq work is pending, handler #08!!! on Dell XPS 13 9360
Dear Anna-Maria, Thank you very much for the support. I was finally able to collect the data you asked for. Am 09.04.24 um 09:57 schrieb Anna-Maria Behnsen: Paul Menzel writes: […] Am 08.04.24 um 12:10 schrieb Anna-Maria Behnsen: Paul Menzel writes: On Dell XPS 13 9360/0596KF, BIOS 2.21.0 06/02/2022, with Linux 6.9-rc2+ built from commit b1e6ec0a0fd0 (Merge tag 'docs-6.9-fixes' of git://git.lwn.net/linux) the external USB-C adapter Dell DA300 stopped working (only the Ethernet port was used). Linux logged: thanks for the report. Can you please provide a trace beside the dmesg output? The following trace events should be enabled (via kernel command line): trace_event=timer:*,timer_migration:*,sched:sched_switch,sched:sched_wakeup,sched:sched_process_hang,irq:softirq_entry,irq:softirq_raise,irq:softirq_exit Unfortunately I haven’t been able to reproduce it until now. Should it happen again, I am going to try your suggestion. Thanks for letting me know. I wanted to configure that in the running system, but wasn’t able to set all of these at once with `set_event`: echo 'timer:*,timer_migration:*,sched:sched_switch,sched:sched_wakeup,sched:sched_process_hang,irq:softirq_entry,irq:softirq_raise,irq:softirq_exit' | sudo tee /sys/kernel/tracing/set_event For some reason setting them individually also did *not* work: for e in timer:* timer_migration:* sched:sched_switch sched:sched_wakeup sched:sched_process_hang irq:softirq_entry irq:softirq_raise irq:softirq_exit'; do echo "$e" | sudo tee -a /sys/kernel/tracing/set_event; done I then used echo 1 | sudo tee /sys/kernel/tracing/events/timer/enable echo 1 | sudo tee /sys/kernel/tracing/events/timer_migration/enable echo 1 | sudo tee /sys/kernel/tracing/events/sched/sched_switch/enable echo 1 | sudo tee /sys/kernel/tracing/events/sched/sched_wakeup/enable echo 1 | sudo tee /sys/kernel/tracing/events/sched/sched_process_hang/enable echo 1 | sudo tee /sys/kernel/tracing/events/irq/softirq_entry/enable echo 1 | sudo tee /sys/kernel/tracing/events/irq/softirq_raise/enable echo 1 | sudo tee /sys/kernel/tracing/events/irq/softirq_exit/enable and also had to increase the buffer to bridge the gap between the event and me noticing it: echo 96000 | sudo tee /sys/kernel/tracing/buffer_size_kb Then, with Linux v6.11-rc4-11-g521b1e7f4cf0b, I was able to get the trace for the event below: [ 7542.706299] NOHZ tick-stop error: local softirq work is pending, handler #08!!! $ sudo cat /sys/kernel/tracing/trace […] MediaPD~der #28-14000 [000] d..1. 7542.703768: hrtimer_cancel: hrtimer=8d2c9f3f MediaPD~der #28-14000 [000] . 7542.703810: hrtimer_init: hrtimer=c6f259e7 clockid=CLOCK_MONOTONIC mode=ABS MediaPD~der #28-14000 [000] d..1. 7542.703812: hrtimer_start: hrtimer=c6f259e7 function=hrtimer_wakeup expires=7602581538204 softexpires=7602581488204 mode=ABS MediaPD~der #28-14000 [000] d..2. 7542.703821: sched_switch: prev_comm=MediaPD~der #28 prev_pid=14000 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120 -0 [000] dN.2. 7542.703931: sched_wakeup: comm=ImageBridgeChld pid=6041 prio=120 target_cpu=000 -0 [000] d..2. 7542.703937: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=ImageBridgeChld next_pid=6041 next_prio=120 ImageBridgeChld-6041[000] d..2. 7542.704041: sched_switch: prev_comm=ImageBridgeChld prev_pid=6041 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120 -0 [000] dN.2. 7542.704174: sched_wakeup: comm=Renderer pid=4113 prio=120 target_cpu=000 -0 [000] d..2. 7542.704179: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=Renderer next_pid=4113 next_prio=120 Renderer-4113[000] d..2. 7542.704245: sched_switch: prev_comm=Renderer prev_pid=4113 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120 -0 [000] dNh2. 7542.704260: sched_wakeup: comm=IPC I/O Child pid=6029 prio=120 target_cpu=000 -0 [000] d..2. 7542.704267: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=IPC I/O Child next_pid=6029 next_prio=120 IPC I/O Child-6029[000] d..2. 7542.704340: sched_switch: prev_comm=IPC I/O Child prev_pid=6029 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120 -0 [000] dN.2. 7542.704786: sched_wakeup: comm=Compositor pid=4123 prio=120 target_cpu=000 -0 [000] d..2. 7542.704791: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=Compositor next_pid=4123 next_prio=120 Compositor-4123[000] d..2. 7542.704944: sched_switch: prev_comm=Compositor prev_pid=4123 pre
Re: [PATCH] iommu/amd: Fix extended features logging
Dear Alexander, Am 10.04.21 um 23:11 schrieb Alexander Monakov: print_iommu_info prints the EFR register and then the decoded list of features on a separate line: pci :00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade): PPR X2APIC NX GT IA GA PC GA_vAPIC The second line is emitted via 'pr_cont', which causes it to have a different ('warn') loglevel compared to the previous line ('info'). Commit 9a295ff0ffc9 attempted to rectify this by removing the newline from the pci_info format string, but this doesn't work, as pci_info calls implicitly append a newline anyway. Hmm, did I really screw that up during my testing? I am sorry about that. I tried to wrap my head around, where the newline is implicitly appended, and only found the definitions below. include/linux/pci.h:#define pci_info(pdev, fmt, arg...) dev_info(&(pdev)->dev, fmt, ##arg) include/linux/dev_printk.h:#define dev_info(dev, fmt, ...) \ include/linux/dev_printk.h: _dev_info(dev, dev_fmt(fmt), ##__VA_ARGS__) include/linux/dev_printk.h:__printf(2, 3) __cold include/linux/dev_printk.h:void _dev_info(const struct device *dev, const char *fmt, ...); include/linux/compiler_attributes.h:#define __printf(a, b) __attribute__((__format__(printf, a, b))) Restore the newline, and call pr_info with empty format string to set the loglevel for subsequent pr_cont calls. The same solution is used in EFI and uvesafb drivers. Thank you for fixing this. Fixes: 9a295ff0ffc9 ("iommu/amd: Print extended features in one line to fix divergent log levels") Signed-off-by: Alexander Monakov Cc: Paul Menzel Cc: Joerg Roedel Cc: Suravee Suthikulpanit Cc: io...@lists.linux-foundation.org --- drivers/iommu/amd/init.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c index 596d0c413473..a25e241eff1c 100644 --- a/drivers/iommu/amd/init.c +++ b/drivers/iommu/amd/init.c @@ -1929,8 +1929,11 @@ static void print_iommu_info(void) pci_info(pdev, "Found IOMMU cap 0x%hx\n", iommu->cap_ptr); if (iommu->cap & (1 << IOMMU_CAP_EFR)) { - pci_info(pdev, "Extended features (%#llx):", + pci_info(pdev, "Extended features (%#llx):\n", iommu->features); + + pr_info(""); + for (i = 0; i < ARRAY_SIZE(feat_str); ++i) { if (iommu_feature(iommu, (1ULL << i))) pr_cont(" %s", feat_str[i]); In the discussion *smpboot: CPU numbers printed as warning* [1] John wrote: It is supported to provide loglevels for CONT messages. The loglevel is then only used if the append fails: pr_cont(KERN_INFO "message part"); I don't know if we want to go down that path. But it is supported. Kind regards, Paul [1]: https://lkml.org/lkml/2021/2/16/191
Re: OT: Processor recommendation for RAID6
Dear Roger, Thank you for your response. Am 02.04.21 um 16:45 schrieb Roger Heflin: On Fri, Apr 2, 2021 at 4:13 AM Paul Menzel wrote: Are these values a good benchmark for comparing processors? After two years, yes they are. I created 16 10 GB files in `/dev/shm`, set them up as loop devices, and created a RAID6. For resync speed it makes difference. 2 x AMD EPYC 7601 32-Core Processor:34671K/sec 2 x Intel Xeon Gold 6248 CPU @ 2.50GHz: 87533K/sec So, the current state of affairs seems to be, that AVX512 instructions do help for software RAIDs, if you want fast rebuild/resync times. Getting, for example, a four core/eight thread Intel Xeon Gold 5222 might be useful. Now, the question remains, if AMD processors could make it up with higher performance, or better optimized code, or if AVX512 instructions are a must, […] PS: Here are the commands on the AMD EPYC system: ``` $ for i in $(seq 1 16); do truncate -s 10G /dev/shm/vdisk$i.img; done $ for i in /dev/shm/v*.img; do sudo losetup --find --show $i; done […] $ sudo mdadm --create /dev/md1 --level=6 --raid-devices=16 /dev/loop{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15} mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. $ more /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid6] [raid5] [raid4] [multipath] md1 : active raid6 loop15[15] loop14[14] loop13[13] loop12[12] loop11[11] loop10[10] loop9[9] loop8[8] loop7[7] loop6[6] loop5[5] loop4[4] loop3[3] loop2[2] loop1[1] loop0[0] 146671616 blocks super 1.2 level 6, 512k chunk, algorithm 2 [16/16] [] [>] resync = 3.9% (416880/10476544) finish=5.6min speed=29777K/sec unused devices: $ more /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid6] [raid5] [raid4] [multipath] md1 : active raid6 loop15[15] loop14[14] loop13[13] loop12[12] loop11[11] loop10[10] loop9[9] loop8[8] loop7[7] loop6[6] loop5[5] loop4[4] loop3[3] loop2[2] loop1[1] loop0[0] 146671616 blocks super 1.2 level 6, 512k chunk, algorithm 2 [16/16] [] [>] resync = 4.1% (439872/10476544) finish=5.3min speed=31419K/sec $ sudo mdadm -S /dev/md1 mdadm: stopped /dev/md1 $ sudo losetup -D $ sudo rm /dev/shm/vdisk*.img I think you are testing something else. Your speeds are way below what the raw processor can do. You are probably testing memory speed/numa arch differences between the 2. On the intel arch there are 2 numa nodes total with 4 channels, so the system has 8 usable channels of bandwidth, but a allocation on a single numa node will only have 4 channels usable (ddr4-2933) On the epyc there are 8 numa nodes with 2 channels each (ddr4-2666), so any single memory allocation will have only 2 channels available and if the accesses are across the numa bus will be slower. So 4*2933/2*2666 = 2.20 * 34671 = 76286 (fairly close to your results). How the allocation for memory works depends a lot on how much ram you actually have per numa node and how much for the whole machine. But any single block for any single device should be on a single numa node almost all of the time. You might want to drop the cache before the test, run numactl --hardware to see how much memory is free per numa node, then rerun the test and at the of the test before the stop run numactl --hardware again to see how it was spread across numa nodes. Even if it spreads it across multiple numa nodes that may well mean that on the epyc case you are running with several numa nodes were the main raid processes are running against remote numa nodes, and because intel only has 2 then there is a decent chance that it is only running on 1 most of the time (so no remote memory). I have also seen in benchmarks I have run on 2P and 4P intel machines that interleaved on a 2P single thread job is faster than running on a single numa nodes memory (with the process pinned to a single cpu on one of the numa nodes, memory interleaved over both), but on a 4P/4numa node machine interleaving slows it down significantly. And in the default case any single write/read of a block is likely only on a single numa node so that specific read/write is constrained by a single numa node bandwidth giving an advantage to fewer faster/bigger numa nodes and less remote memory. Outside of rebooting and forcing the entire machine to interleave I am not sure how to get shm to interleave. It might be a good enough test to just force the epyc to interleave and see if the benchmark result changes in any way. If the result does change repeat on the intel. Overall for the most part the raid would not be able to use very many cpu anyway, so a bigger machine with more numa nodes may slow down the overall rate. Thank you for the analysis. If I am going to have time, I am going to try your suggestions. In the meantime I won’t test in `/dev/shm`. Our servers with 256+ GB RAM are only two socket systems with a lot of cores/threads,
Re: [regression 5.4.97 → 5.10.24]: raid6 avx2x4 speed drops from 18429 MB/s to 6155 MB/s
Dear Borislav, Am 02.04.21 um 16:05 schrieb Borislav Petkov: On Fri, Apr 02, 2021 at 10:33:51AM +0200, Paul Menzel wrote: On an two socket AMD EPYC 7601, we noticed a decrease in raid6 avx2x4 speed shown at the beginning of the boot. 5.4.955.10.24 -- raid6: avx2x4 gen() 18429 MB/s 6155 MB/s raid6: avx2x4 xor()6644 MB/s 4274 MB/s raid6: avx2x2 gen() 17894 MB/s18744 MB/s raid6: avx2x2 xor() 11642 MB/s11950 MB/s raid6: avx2x1 gen() 13992 MB/s17112 MB/s raid6: avx2x1 xor() 10855 MB/s11143 MB/s Looks like those two might help: 49200d17d27d x86/fpu/64: Don't FNINIT in kernel_fpu_begin() e45122893a98 x86/fpu: Add kernel_fpu_begin_mask() to selectively initialize state I booted Linux 5.12-rc6, containing these commits, on a Dell OptiPlex 5055 with AMD Ryzen 5 PRO 1500 Quad-Core Processor, and the regression is still present for `avx2x4 xor()`: 5.4.95 5.10.24 -- raid6: avx2x4 gen()23964 MB/s 24540 MB/s raid6: avx2x4 xor()13101 MB/s8354 MB/s raid6: avx2x2 gen()22746 MB/s 26972 MB/s raid6: avx2x2 xor()14917 MB/s 16463 MB/s raid6: avx2x1 gen()17519 MB/s 24394 MB/s raid6: avx2x1 xor()14091 MB/s 15330 MB/s raid6: sse2x4 gen()16867 MB/s 16136 MB/s raid6: sse2x4 xor() 9667 MB/s8176 MB/s raid6: sse2x2 gen()14996 MB/s 18234 MB/s raid6: sse2x2 xor()10765 MB/s 10455 MB/s raid6: sse2x1 gen() 7667 MB/s 13769 MB/s raid6: sse2x1 xor() 7818 MB/s7741 MB/s What system are you using, and what results do you get with 5.4 and 5.12-rc6? Kind regards, Paul
Re: OT: Processor recommendation for RAID6
Dear Linux folks, Am 08.04.19 um 18:34 schrieb Paul Menzel: On 04/08/19 12:33, Paul Menzel wrote: Can you share your experiences, which processors you choose for your RAID6 systems? I am particularly interested in Intel alternatives? Are AMD EPYC processors good alternatives for file servers? What about ARM and POWER? We currently use the HBA Adaptec Smart Storage PQI 12G SAS/PCIe 3 (rev 01), Dell systems and rotating disks. For example, Dell PowerEdge R730 with 40x E5-2687W v3 @ 3.10GHz, 192 GB of memory, Linux 4.14.87 and XFS file system. (The processor looks too powerful for the system. At least the processor usage is at most at one or two thread.) ``` [0.394710] raid6: sse2x1 gen() 11441 MB/s [0.416710] raid6: sse2x1 xor() 8099 MB/s [0.438713] raid6: sse2x2 gen() 13359 MB/s [0.460710] raid6: sse2x2 xor() 8910 MB/s [0.482712] raid6: sse2x4 gen() 16128 MB/s [0.504710] raid6: sse2x4 xor() 10009 MB/s [0.526710] raid6: avx2x1 gen() 22242 MB/s [0.548709] raid6: avx2x1 xor() 15406 MB/s [0.570710] raid6: avx2x2 gen() 25699 MB/s [0.592710] raid6: avx2x2 xor() 16521 MB/s [0.614709] raid6: avx2x4 gen() 29847 MB/s [0.636710] raid6: avx2x4 xor() 18617 MB/s [0.642001] raid6: using algorithm avx2x4 gen() 29847 MB/s [0.648000] raid6: xor() 18617 MB/s, rmw enabled [0.654001] raid6: using avx2x2 recovery algorithm ``` […] Maybe some more data. AVX512 from Intel processors really seems to make a difference in the Linux tests. But also ### Intel Xeon W-2145 (3.7 GHz) with Linux 4.19.19 ``` $ dmesg | grep -e raid6 -e smpboot [0.118880] smpboot: Allowing 16 CPUs, 0 hotplug CPUs [0.379291] smpboot: CPU0: Intel(R) Xeon(R) W-2145 CPU @ 3.70GHz (family: 0x6, model: 0x55, stepping: 0x4) [0.398245] smpboot: Max logical packages: 1 [0.398618] smpboot: Total of 16 processors activated (118400.00 BogoMIPS) [0.426597] raid6: sse2x1 gen() 13144 MB/s [0.443601] raid6: sse2x1 xor() 9962 MB/s [0.460602] raid6: sse2x2 gen() 16863 MB/s [0.477606] raid6: sse2x2 xor() 11425 MB/s [0.494609] raid6: sse2x4 gen() 19089 MB/s [0.511613] raid6: sse2x4 xor() 11988 MB/s [0.528614] raid6: avx2x1 gen() 26285 MB/s [0.545617] raid6: avx2x1 xor() 19335 MB/s [0.562620] raid6: avx2x2 gen() 33953 MB/s [0.579624] raid6: avx2x2 xor() 21255 MB/s [0.596627] raid6: avx2x4 gen() 38492 MB/s [0.613629] raid6: avx2x4 xor() 19722 MB/s [0.630633] raid6: avx512x1 gen() 37621 MB/s [0.647636] raid6: avx512x1 xor() 21017 MB/s [0.664639] raid6: avx512x2 gen() 46859 MB/s [0.681642] raid6: avx512x2 xor() 26173 MB/s [0.698645] raid6: avx512x4 gen() 54210 MB/s [0.715648] raid6: avx512x4 xor() 28041 MB/s [0.716019] raid6: using algorithm avx512x4 gen() 54210 MB/s [0.716244] raid6: xor() 28041 MB/s, rmw enabled [0.716648] raid6: using avx512x2 recovery algorithm ``` ### AMD EPYC Linux 4.19.19 (up to 2.6 GHz according to `lscpu`) ``` $ dmesg | grep -e raid6 -e smpboot [0.00] smpboot: Allowing 128 CPUs, 0 hotplug CPUs [0.122478] smpboot: CPU0: AMD EPYC 7601 32-Core Processor (family: 0x17, model: 0x1, stepping: 0x2) [0.364480] smpboot: Max logical packages: 2 [0.366489] smpboot: Total of 128 processors activated (561529.72 BogoMIPS) [0.503630] raid6: sse2x1 gen() 6136 MB/s [0.524630] raid6: sse2x1 xor() 5931 MB/s [0.545627] raid6: sse2x2 gen() 12941 MB/s [0.566628] raid6: sse2x2 xor() 8173 MB/s [0.587629] raid6: sse2x4 gen() 13089 MB/s [0.608627] raid6: sse2x4 xor() 7318 MB/s [0.629627] raid6: avx2x1 gen() 15164 MB/s [0.650626] raid6: avx2x1 xor() 10990 MB/s [0.671627] raid6: avx2x2 gen() 20316 MB/s [0.692625] raid6: avx2x2 xor() 11886 MB/s [0.713625] raid6: avx2x4 gen() 20726 MB/s [0.734628] raid6: avx2x4 xor() 10095 MB/s [0.739479] raid6: using algorithm avx2x4 gen() 20726 MB/s [0.745479] raid6: xor() 10095 MB/s, rmw enabled [0.750479] raid6: using avx2x2 recovery algorithm ``` Are these values a good benchmark for comparing processors? After two years, yes they are. I created 16 10 GB files in `/dev/shm`, set them up as loop devices, and created a RAID6. For resync speed it makes difference. 2 x AMD EPYC 7601 32-Core Processor:34671K/sec 2 x Intel Xeon Gold 6248 CPU @ 2.50GHz: 87533K/sec So, the current state of affairs seems to be, that AVX512 instructions do help for software RAIDs, if you want fast rebuild/resync times. Getting, for example, a four core/eight thread Intel Xeon Gold 5222 might be useful. Now, the question remains, if AMD processors could make it up with higher performance, or better optimized code, or if AVX512 instructions are a must, […] Kind regards, Paul PS: Here are the commands on the AMD EPYC system: ``` $ for i in $(seq 1 16); do truncate -s 10G /dev/shm/vdisk$i.img; done
[regression 5.4.97 → 5.10.24]: raid6 avx2x4 speed drops from 18429 MB/s to 6155 MB/s
Dear Linux folks, On an two socket AMD EPYC 7601, we noticed a decrease in raid6 avx2x4 speed shown at the beginning of the boot. 5.4.955.10.24 -- raid6: avx2x4 gen() 18429 MB/s 6155 MB/s raid6: avx2x4 xor()6644 MB/s 4274 MB/s raid6: avx2x2 gen() 17894 MB/s18744 MB/s raid6: avx2x2 xor() 11642 MB/s11950 MB/s raid6: avx2x1 gen() 13992 MB/s17112 MB/s raid6: avx2x1 xor() 10855 MB/s11143 MB/s We are able to reproduce this with different models: Supermicro AS-2023US-TR4/H11DSU-iN and Dell PowerEdge R7425 (with different microcode versions). Can you reproduce this on your systems? Bisecting is going to be hard, so the systems are in production and also take a while to boot. (Maybe kexec would help here.) Kind regards, Paul PS: Some more information: ``` [0.00] Linux version 5.4.97.mx64.368 (r...@theinternet.molgen.mpg.de) (gcc version 7.5.0 (GCC )) #1 SMP Wed Feb 10 18:22:50 CET 2021 […] [0.00] DMI: Supermicro AS -2023US-TR4/H11DSU-iN, BIOS 1.1 02/07/2018 […] [0.630603] raid6: avx2x4 gen() 18429 MB/s [0.651607] raid6: avx2x4 xor() 6644 MB/s [0.672605] raid6: avx2x2 gen() 17894 MB/s [0.693603] raid6: avx2x2 xor() 11642 MB/s [0.714605] raid6: avx2x1 gen() 13992 MB/s [0.735604] raid6: avx2x1 xor() 10855 MB/s [0.756607] raid6: sse2x4 gen() 12246 MB/s [0.777605] raid6: sse2x4 xor() 5724 MB/s [0.798605] raid6: sse2x2 gen() 10945 MB/s [0.819603] raid6: sse2x2 xor() 8097 MB/s [0.840606] raid6: sse2x1 gen() 5941 MB/s [0.861606] raid6: sse2x1 xor() 5894 MB/s [0.866565] raid6: using algorithm avx2x4 gen() 18429 MB/s [0.871567] raid6: xor() 6644 MB/s, rmw enabled [0.877566] raid6: using avx2x2 recovery algorithm […] ``` ``` [0.00] Linux version 5.10.24.mx64.375 (r...@theinternet.molgen.mpg.de) (gcc (GCC) 7.5.0, GNU ld (GNU Binutils) 2.32) #1 SMP Fri Mar 19 12:29:21 CET 2021 […] [0.00] DMI: Supermicro AS -2023US-TR4/H11DSU-iN, BIOS 1.1 02/07/2018 […] [0.655382] raid6: avx2x4 gen() 6155 MB/s [0.676382] raid6: avx2x4 xor() 4274 MB/s [0.697380] raid6: avx2x2 gen() 18744 MB/s [0.718380] raid6: avx2x2 xor() 11950 MB/s [0.739380] raid6: avx2x1 gen() 17112 MB/s [0.760380] raid6: avx2x1 xor() 11143 MB/s [0.781381] raid6: sse2x4 gen() 11062 MB/s [0.802380] raid6: sse2x4 xor() 5180 MB/s [0.823380] raid6: sse2x2 gen() 12467 MB/s [0.844380] raid6: sse2x2 xor() 7672 MB/s [0.865381] raid6: sse2x1 gen() 9733 MB/s [0.886380] raid6: sse2x1 xor() 5717 MB/s [0.890674] raid6: using algorithm avx2x2 gen() 18744 MB/s [0.895673] raid6: xor() 11950 MB/s, rmw enabled [0.901673] raid6: using avx2x2 recovery algorithm ``` ``` $ lscpu Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 48 bits physical, 48 bits virtual CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 2 Core(s) per socket: 32 Socket(s): 2 NUMA node(s):8 Vendor ID: AuthenticAMD CPU family: 23 Model: 1 Model name: AMD EPYC 7601 32-Core Processor Stepping:2 Frequency boost: enabled CPU MHz: 3100.798 CPU max MHz: 2200. CPU min MHz: 1200. BogoMIPS:4399.53 Virtualization: AMD-V L1d cache: 2 MiB L1i cache: 4 MiB L2 cache:32 MiB L3 cache:128 MiB NUMA node0 CPU(s): 0-7,64-71 NUMA node1 CPU(s): 8-15,72-79 NUMA node2 CPU(s): 16-23,80-87 NUMA node3 CPU(s): 24-31,88-95 NUMA node4 CPU(s): 32-39,96-103 NUMA node5 CPU(s): 40-47,104-111 NUMA node6 CPU(s): 48-55,112-119 NUMA node7 CPU(s): 56-63,120-127 Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2:Mitigation; Full AMD retpoline, IBPB conditional, STIBP disabled, RSB filling Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat ps
Re: Marvell: hw perfevents: unable to count PMU IRQs
Dear Robin, Thank you for the quick reply. Am 26.03.21 um 13:29 schrieb Robin Murphy: On 2021-03-25 21:39, Paul Menzel wrote: On the Marvell Prestera switch, Linux 5.10.4 prints the error (with an additional info level message) below. [ 0.00] Linux version 5.10.4 (robimarko@onlbuilder9) (aarch64-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516, GNU ld (GNU Binutils for Debian) 2.28) #1 SMP PREEMPT Thu Mar 11 10:22:09 UTC 2021 […] [ 1.996658] hw perfevents: unable to count PMU IRQs [ 2.001825] hw perfevents: /ap806/config-space@f000/pmu: failed to register PMU devices! […] Please find the output of `dmesg` attached. How can the IRQs be counted? Well, that message simply means we got an error back from platform_irq_count(), which in turn implies that platform_get_irq_optional() failed. Most likely we got -EPROBE_DEFER back from of_irq_get() because the relevant interrupt controller wasn't ready by that point - especially since that's the o9nly error code that platform_irq_cont() will actually pass. It looks like that should end up getting propagated all the way out appropriately, so the PMU driver should defer and be able to probe OK once the mvebu-pic driver has turned up to provide its IRQ. We could of course do a better job of not shouting error messages for a non-fatal condition Yes, that would be great. As for why the PMU doesn't eventually show up, my best guess would be either an issue with the mvebu-pic driver itself probing, and/or perhaps something in fw_devlink going awry - inspecting sysfs should shed a bit more light on those. I just noticed, I missed [3.298670] hw perfevents: enabled with armv8_cortex_a72 PMU driver, 7 counters available a good second. So the interrupt controller indeed seems to take longer to be ready. I guess, I’d need to boot with `initcall_debug` to find out the callers of the PMU functions. Kind regards, Paul
Marvell: hw perfevents: unable to count PMU IRQs
Dear Linux folks, On the Marvell Prestera switch, Linux 5.10.4 prints the error (with an additional info level message) below. [0.00] Linux version 5.10.4 (robimarko@onlbuilder9) (aarch64-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516, GNU ld (GNU Binutils for Debian) 2.28) #1 SMP PREEMPT Thu Mar 11 10:22:09 UTC 2021 […] [1.996658] hw perfevents: unable to count PMU IRQs [2.001825] hw perfevents: /ap806/config-space@f000/pmu: failed to register PMU devices! ``` # lscpu Architecture: aarch64 Byte Order:Little Endian CPU(s):4 On-line CPU(s) list: 0-3 Thread(s) per core:1 Core(s) per socket:4 Socket(s): 1 NUMA node(s): 1 Model: 1 BogoMIPS: 50.00 L1d cache: 32K L1i cache: 48K L2 cache: 512K NUMA node0 CPU(s): 0-3 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid # cat /proc/cpuinfo processor : 0 BogoMIPS: 50.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part: 0xd08 CPU revision: 1 […] ``` Please find the output of `dmesg` attached. How can the IRQs be counted? Kind regards, Paul [0.00] Booting Linux on physical CPU 0x00 [0x410fd081] [0.00] Linux version 5.10.4 (robimarko@onlbuilder9) (aarch64-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516, GNU ld (GNU Binutils for Debian) 2.28) #1 SMP PREEMPT Thu Mar 11 10:22:09 UTC 2021 [0.00] Machine model: delta,tn48m [0.00] earlycon: uart8250 at MMIO32 0xf0512000 (options '') [0.00] printk: bootconsole [uart8250] enabled [0.00] efi: UEFI not found. [0.00] [Firmware Bug]: Kernel image misaligned at boot, please fix your bootloader! [0.00] cma: Reserved 32 MiB at 0xbe00 [0.00] NUMA: No NUMA configuration found [0.00] NUMA: Faking a node at [mem 0x-0x00023fff] [0.00] NUMA: NODE_DATA [mem 0x23efdb100-0x23efdcfff] [0.00] Zone ranges: [0.00] DMA [mem 0x-0x3fff] [0.00] DMA32[mem 0x4000-0x] [0.00] Normal [mem 0x0001-0x00023fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x03ff] [0.00] node 0: [mem 0x0420-0xbfff] [0.00] node 0: [mem 0x0001-0x00023fff] [0.00] Initmem setup node 0 [mem 0x-0x00023fff] [0.00] On node 0 totalpages: 2096640 [0.00] DMA zone: 4096 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 261632 pages, LIFO batch:63 [0.00] DMA32 zone: 8192 pages used for memmap [0.00] DMA32 zone: 524288 pages, LIFO batch:63 [0.00] Normal zone: 20480 pages used for memmap [0.00] Normal zone: 1310720 pages, LIFO batch:63 [0.00] psci: probing for conduit method from DT. [0.00] psci: PSCIv1.1 detected in firmware. [0.00] psci: Using standard PSCI v0.2 function IDs [0.00] psci: Trusted OS resident on physical CPU 0x0 [0.00] psci: SMC Calling Convention v1.1 [0.00] percpu: Embedded 32 pages/cpu s94104 r8192 d28776 u131072 [0.00] pcpu-alloc: s94104 r8192 d28776 u131072 alloc=32*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Detected PIPT I-cache on CPU0 [0.00] CPU features: detected: EL2 vector hardening [0.00] CPU features: kernel page table isolation forced ON by KASLR [0.00] CPU features: detected: Kernel page table isolation (KPTI) [0.00] CPU features: detected: Spectre-v2 [0.00] CPU features: detected: ARM errata 1165522, 1319367, or 1530923 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 2063872 [0.00] Policy zone: Normal [0.00] Kernel command line: console=ttyS0,115200 earlycon=uart8250,mmio32,0xf0512000 onl_platform=arm64-delta-tn48m-poe-r0 [0.00] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear) [0.00] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] software IO TLB: mapped [mem 0x3bfff000-0x3000] (64MB) [0.00] Memory: 8071364K/8386560K available (18112K kernel code, 4006K rwdata, 9464K rodata, 9536K init, 539K bss, 282428K reserved, 32768K cma-reserved) [0.00] ftrace: allocating 60579 entries in 237 pages [0.00] ftrace: allocated 237 pages with 6 groups [0.00] rcu: Preemptible hierarchical RCU implementation. [0.00]
Re: [PATCH] ACPI: scan: Turn off unused power resources during initialization
Dear Rafael, Am 17.03.21 um 17:49 schrieb Rafael J. Wysocki: From: Rafael J. Wysocki It is reported that on certain platforms unused ACPI power resources that have not been explicitly turned off prevent the platform from reaching the lowest power state in suspend-to-idle which leads to excessive power draw. For this reason, turn all of the unused ACPI power resources off at the end of the initial namespace scan for devices in analogy with resume from suspend-to-RAM. Reported-by: David Box Thank you for the patch. Could you please add more details to the commit message, saying what device this was on, and if there were some error/warning messages pointing to the problem? Kind regards, Paul Signed-off-by: Rafael J. Wysocki --- drivers/acpi/internal.h |1 + drivers/acpi/scan.c |2 ++ drivers/acpi/sleep.h|1 - 3 files changed, 3 insertions(+), 1 deletion(-) Index: linux-pm/drivers/acpi/internal.h === --- linux-pm.orig/drivers/acpi/internal.h +++ linux-pm/drivers/acpi/internal.h @@ -139,6 +139,7 @@ int acpi_device_sleep_wake(struct acpi_d int acpi_power_get_inferred_state(struct acpi_device *device, int *state); int acpi_power_on_resources(struct acpi_device *device, int state); int acpi_power_transition(struct acpi_device *device, int state); +void acpi_turn_off_unused_power_resources(void); /* -- Device Power Management Index: linux-pm/drivers/acpi/scan.c === --- linux-pm.orig/drivers/acpi/scan.c +++ linux-pm/drivers/acpi/scan.c @@ -2360,6 +2360,8 @@ int __init acpi_scan_init(void) } } + acpi_turn_off_unused_power_resources(); + acpi_scan_initialized = true; out: Index: linux-pm/drivers/acpi/sleep.h === --- linux-pm.orig/drivers/acpi/sleep.h +++ linux-pm/drivers/acpi/sleep.h @@ -8,7 +8,6 @@ extern struct list_head acpi_wakeup_devi extern struct mutex acpi_device_lock; extern void acpi_resume_power_resources(void); -extern void acpi_turn_off_unused_power_resources(void); static inline acpi_status acpi_set_waking_vector(u32 wakeup_address) {
Re: [EXTERNAL] Re: [PATCH] kexec: Add kexec reboot string
Dear Joe, Thank you for replying. Am 11.03.21 um 19:14 schrieb Joe LeVeque: Is this all your looking for? If not, please let me know. Signed-off-by: Joe LeVeque It’d be great if you answered Baoquan He’s question, how it’s actually used in SONiC. (I just sent the patch upstream to reduce the out-of-tree patches in SONiC.) Kind regards, Paul
Email from the future (was: [PATCH v2 RESEND 2/2] ARM: dts: Add board-specific compatible string to npcm750-evb devicetree)
Dear Tomer, Please note, your email date was around 11 minutes in the future. As it looks like you are using Google Mail, I am quite surprised by this. Kind regards, Paul
Re: [Intel-wired-lan] [PATCH RESEND][next] ice: Fix fall-through warnings for Clang
Dear Gustavo, Thank you for working on that. Am 05.03.21 um 09:52 schrieb Gustavo A. R. Silva: In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of just letting the code fall through to the next case. It would be nice to have a short summary of the discrepancy between GCC and clang, and it was decided to go with the “clang decision”, and not have clang adapt to GCC. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva --- drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c index 02b12736ea80..207f6ee3a7f6 100644 --- a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c @@ -143,6 +143,7 @@ ice_rx_csum(struct ice_ring *ring, struct sk_buff *skb, case ICE_RX_PTYPE_INNER_PROT_UDP: case ICE_RX_PTYPE_INNER_PROT_SCTP: skb->ip_summed = CHECKSUM_UNNECESSARY; + break; default: break; } Kind regards, Paul
[PATCH] kexec: Add kexec reboot string
From: Joe LeVeque The purpose is to notify the kernel module for fast reboot. Upstream a patch from the SONiC network operating system [1]. [1]: https://github.com/Azure/sonic-linux-kernel/pull/46 Signed-off-by: Paul Menzel --- kernel/kexec_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c index a0b6780740c8..f04d04d1b855 100644 --- a/kernel/kexec_core.c +++ b/kernel/kexec_core.c @@ -1165,7 +1165,7 @@ int kernel_kexec(void) #endif { kexec_in_progress = true; - kernel_restart_prepare(NULL); + kernel_restart_prepare("kexec reboot"); migrate_to_reboot_cpu(); /* -- 2.30.1
Re: [PATCH] iommu/amd: Fix event counter availability check
[cc: +suravee, +jörg] Dear Alex, dear Shuah, dear Suravee, dear Jörg, Am 03.06.20 um 08:54 schrieb Alexander Monakov: On Tue, 2 Jun 2020, Shuah Khan wrote: I changed the logic to read config to get max banks and counters before checking if counters are writable and tried writing to all. The result is the same and all of them aren't writable. However, when disable the writable check and assume they are, I can run [snip] This is similar to what I did. I also noticed that counters can be successfully used with perf if the initial check is ignored. I was considering sending a patch to remove the check and adjust the event counting logic to use counters as read-only, but after a bit more investigation I've noticed how late pci_enable_device is done, and came up with this patch. It's a path of less resistance: I'd expect maintainers to be more averse to removing the check rather than fixing it so it works as intended (even though I think the check should not be there in the first place). However: The ability to modify the counters is needed only for sampling the events (getting an interrupt when a counter overflows). There's no code to do that for these AMD IOMMU counters. A solution I would prefer is to not write to those counters at all. It would simplify or even remove a bunch of code. I can submit a corresponding patch if there's general agreement this path is ok. What do you think? I like this idea. Suravee, Jörg, what do you think? Commit 6778ff5b21b (iommu/amd: Fix performance counter initialization) delays the boot up to 100 ms, which is over 20 % on fast systems, and also just a workaround, and does not seem to work always. The delay is also not mentioned in the commit message. Kind regards, Paul [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6778ff5b21bd8e78c8bd547fd66437cf2657fd9b
Re: [PATCH] iommu/amd: Fix event counter availability check
Dear Suravee, Thank you for your reply. Am 22.02.21 um 18:59 schrieb Suravee Suthikulpanit: This fix has been accepted in the upstream recently. https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git/commit/?h=x86/amd Indeed. Linux pulled also pulled this [1]. Could you please give this a try? Yes, I did give it a try, but, unfortunately, the problem is unfixed. I commented on the Linux Bugzilla bug report #201753 [1]. Kind regards, Paul PS: It’d be great if you didn’t top post, and used interleaved style for responses. [1]: https://bugzilla.kernel.org/show_bug.cgi?id=201753 "AMD-Vi: Unable to write to IOMMU perf counter"
Re: [PATCH] iommu/amd: Fix event counter availability check
Dear Suravee, Am 17.09.20 um 19:55 schrieb Alexander Monakov: On Tue, 16 Jun 2020, Suravee Suthikulpanit wrote: Instead of blindly moving the code around to a spot that would just work, I am trying to understand what might be required here. In this case, the init_device_table_dma()should not be needed. I suspect it's the IOMMU invalidate all command that's also needed here. I'm also checking with the HW and BIOS team. Meanwhile, could you please give the following change a try: Hello. Can you give any update please? […] Sorry for late reply. I have a reproducer and working with the HW team to understand the issue. I should be able to provide update with solution by the end of this week. Hello, hope you are doing well. Has this investigation found anything? I am wondering the same. It’d be great to have this fixed in the upstream Linux kernel. Kind regards, Paul
Re: [PATCH] iommu/amd: Fix event counter availability check
Dear Alexander, Am 01.06.20 um 04:48 schrieb Paul Menzel: […] Am 31.05.20 um 09:22 schrieb Alexander Monakov: Adding Shuah Khan to Cc: I've noticed you've seen this issue on Ryzen 2400GE; can you have a look at the patch? Would be nice to know if it fixes the problem for you too. On Fri, 29 May 2020, Alexander Monakov wrote: The driver performs an extra check if the IOMMU's capabilities advertise presence of performance counters: it verifies that counters are writable by writing a hard-coded value to a counter and testing that reading that counter gives back the same value. Unfortunately it does so quite early, even before pci_enable_device is called for the IOMMU, i.e. when accessing its MMIO space is not guaranteed to work. On Ryzen 4500U CPU, this actually breaks the test: the driver assumes the counters are not writable, and disables the functionality. Moving init_iommu_perf_ctr just after iommu_flush_all_caches resolves the issue. This is the earliest point in amd_iommu_init_pci where the call succeeds on my laptop. Signed-off-by: Alexander Monakov Cc: Joerg Roedel Cc: Suravee Suthikulpanit Cc: io...@lists.linux-foundation.org --- PS. I'm seeing another hiccup with IOMMU probing on my system: pci :00:00.2: can't derive routing for PCI INT A pci :00:00.2: PCI INT A: not connected Hopefully I can figure it out, but I'd appreciate hints. I guess it’s a firmware bug, but I contacted the linux-pci folks [1]. Unfortunately, it’s still present in Linux 5.11. drivers/iommu/amd_iommu_init.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c index 5b81fd16f5fa..1b7ec6b6a282 100644 --- a/drivers/iommu/amd_iommu_init.c +++ b/drivers/iommu/amd_iommu_init.c @@ -1788,8 +1788,6 @@ static int __init iommu_init_pci(struct amd_iommu *iommu) if (iommu->cap & (1UL << IOMMU_CAP_NPCACHE)) amd_iommu_np_cache = true; - init_iommu_perf_ctr(iommu); - if (is_rd890_iommu(iommu->dev)) { int i, j; @@ -1891,8 +1889,10 @@ static int __init amd_iommu_init_pci(void) init_device_table_dma(); - for_each_iommu(iommu) + for_each_iommu(iommu) { iommu_flush_all_caches(iommu); + init_iommu_perf_ctr(iommu); + } if (!ret) print_iommu_info(); base-commit: 75caf310d16cc5e2f851c048cd597f5437013368 Thank you very much for fixing this issue, which is almost two years old for me. Tested-by: Paul Menzel MSI MSI MS-7A37/B350M MORTAR with AMD Ryzen 3 2200G Link: https://lore.kernel.org/linux-iommu/20180727102710.ga6...@8bytes.org/ Just a small note, that I am applying your patch, but it looks like there is still some timing issue. At least today, I noticed it during one boot with Linux 5.11. (Before I never noticed it again in the several years, but I am not always paying attention and do not save the logs.) Kind regards, Paul [1]: https://lore.kernel.org/linux-pci/8579bd14-e369-1141-917b-204d20cff...@molgen.mpg.de/
Re: [PATCH] ARM: dts: nuvoton: Fix flash layout
Dear Anton, Thank you for your patch. Am 18.02.21 um 13:25 schrieb gmo...@google.com: From: "Anton D. Kachalov" This change satisfy OpenBMC requirements for flash layout. Can you please list these requirements in the commit message? Maybe, also add OpenBMC to the commit message summary. Signed-off-by: Anton D. Kachalov --- arch/arm/boot/dts/nuvoton-npcm750-evb.dts | 28 +++ 1 file changed, 8 insertions(+), 20 deletions(-) […] Kind regards, Paul
Re: smpboot: CPU numbers printed as warning
Dear Borislav, dear Petr, Am 16.02.21 um 11:14 schrieb Borislav Petkov: On Tue, Feb 16, 2021 at 10:49:04AM +0100, Petr Mladek wrote: Also you should add '\n' into the previous string to make the behavior clear. It will always be printed on a new line when pr_info() is used. This was made to use pr_cont() on purpose so that the output is compact, for example: [4.088605] x86: Booting SMP configuration: [4.089511] node #0, CPUs: #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21 #22 #23 #24 #25 #26 #27 #28 #29 #30 #31 #32 #33 #34 #35 #36 #37 #38 #39 #40 #41 #42 #43 #44 #45 #46 #47 #48 #49 #50 #51 #52 #53 #54 #55 #56 #57 #58 #59 #60 #61 #62 #63 [4.188510] node #1, CPUs:#64 #65 #66 #67 #68 #69 #70 #71 #72 #73 #74 #75 #76 #77 #78 #79 #80 #81 #82 #83 #84 #85 #86 #87 #88 #89 #90 #91 #92 #93 #94 #95 #96 #97 #98 #99 #100 #101 #102 #103 #104 #105 #106 #107 #108 #109 #110 #111 #112 #113 #114 #115 #116 #117 #118 #119 #120 #121 #122 #123 #124 #125 #126 #127 [4.307511] node #0, CPUs: #128 #129 #130 #131 #132 #133 #134 #135 #136 #137 #138 #139 #140 #141 #142 #143 #144 #145 #146 #147 #148 #149 #150 #151 #152 #153 #154 #155 #156 #157 #158 #159 #160 #161 #162 #163 #164 #165 #166 #167 #168 #169 #170 #171 #172 #173 #174 #175 #176 #177 #178 #179 #180 #181 #182 #183 #184 #185 #186 #187 #188 #189 #190 #191 [4.416511] node #1, CPUs: #192 #193 #194 #195 #196 #197 #198 #199 #200 #201 #202 #203 #204 #205 #206 #207 #208 #209 #210 #211 #212 #213 #214 #215 #216 #217 #218 #219 #220 #221 #222 #223 #224 #225 #226 #227 #228 #229 #230 #231 #232 #233 #234 #235 #236 #237 #238 #239 #240 #241 #242 #243 #244 #245 #246 #247 #248 #249 #250 #251 #252 #253 #254 #255 [4.531683] smp: Brought up 2 nodes, 256 CPUs [4.534510] smpboot: Max logical packages: 2 [4.535527] smpboot: Total of 256 processors activated (1147449.34 BogoMIPS) Yes, the intention is clear, but it’s not working perfectly in all situations. Any ideas, how to improve that? After reading John’s response, I’d go with `pr_cont(KERN_INFO "message part");`. By the way, what are these CPU numbers useful for? Isn’t smp: Brought up 2 nodes, 256 CPUs enough information, and nothing else needed for the majority of users? Kind regards, Paul
Re: smpboot: CPU numbers printed as warning
Dear Petr, Thank you for the quick reply. Am 16.02.21 um 10:49 schrieb Petr Mladek: On Mon 2021-02-15 20:22:34, Paul Menzel wrote: Using Linux 5.10.13 (and before), looking at the Linux kernel warnings, the CPU numbers show up. For example with 12 cpus/threads: ``` $ sudo dmesg --level=warn [0.216103] #2 [0.220105] #3 [0.224103] #4 [0.228104] #5 [0.232110] #6 [0.236101] #7 [0.240102] #8 [0.244102] #9 [0.248100] #10 [0.252098] #11 ``` Is this the exact output from sudo dmesg --level=warn? Yes, it is. It is strange that each CPU number is printed on its own line. Should it be put on one line, if `dmesg --level=warn` is executed, even with other messages in between? Anyway, it might be affected by the new lockless ringbuffer. The original code decided whether to connect the lines only by "current" task pointer. The lockless ring buffer takes into account also CPU number. Well, it has never been reliable. For example, I see here: <6>[0.238262][T1] smp: Bringing up secondary CPUs ... <6>[0.239340][T1] x86: Booting SMP configuration: <6>[0.239794][T1] node #0, CPUs: #1 <6>[0.113946][T0] kvm-clock: cpu 1, msr 6ba01041, secondary cpu clock <6>[0.113946][T0] smpboot: CPU 1 Converting physical 0 to logical die 1 <6>[0.246056][ T16] kvm-guest: stealtime: cpu 1, msr 17f9f2080 <4>[0.246679][T1] #2 <6>[0.113946][T0] kvm-clock: cpu 2, msr 6ba01081, secondary cpu clock <6>[0.113946][T0] smpboot: CPU 2 Converting physical 0 to logical die 2 <6>[0.250023][ T21] kvm-guest: stealtime: cpu 2, msr 17fbf2080 <4>[0.250648][T1] #3 <6>[0.113946][T0] kvm-clock: cpu 3, msr 6ba010c1, secondary cpu clock <6>[0.113946][T0] smpboot: CPU 3 Converting physical 0 to logical die 3 <6>[0.254026][ T26] kvm-guest: stealtime: cpu 3, msr 17fdf2080 <6>[0.254568][T1] smp: Brought up 1 node, 4 CPUs <6>[0.254597][T1] smpboot: Max logical packages: 4 <6>[0.255097][T1] smpboot: Total of 4 processors activated (16896.11 BogoMIPS) There are another messages printed in between that obviously break pr_cont(). Yes, that is what I meant. If I am not mistaken, this is from `announce_cpu()` in `arch/x86/kernel/smpboot.c`, and the `pr_cont()` in their “forgets” the log level it belongs to, maybe because of SMP and other messages are printed in between. ``` if (system_state < SYSTEM_RUNNING) { if (node != current_node) { if (current_node > (-1)) pr_cont("\n"); current_node = node; printk(KERN_INFO " node %*s#%d, CPUs: ", node_width - num_digits(node), " ", node); } /* Add padding for the BSP */ if (cpu == 1) pr_cont("%*s", width + 1, " "); pr_cont("%*s#%d", width - num_digits(cpu), " ", cpu); } else pr_info("Booting Node %d Processor %d APIC 0x%x\n", node, cpu, apicid); ``` Would using `pr_info()` instead be an acceptable fix? Makes sense to me. Also you should add '\n' into the previous string to make the behavior clear. It will always be printed on a new line when pr_info() is used. I am going to reply to Borislav’s response. Kind regards, Paul
smpboot: CPU numbers printed as warning
Dear Linux folks, Using Linux 5.10.13 (and before), looking at the Linux kernel warnings, the CPU numbers show up. For example with 12 cpus/threads: ``` $ sudo dmesg --level=warn [0.216103] #2 [0.220105] #3 [0.224103] #4 [0.228104] #5 [0.232110] #6 [0.236101] #7 [0.240102] #8 [0.244102] #9 [0.248100] #10 [0.252098] #11 ``` If I am not mistaken, this is from `announce_cpu()` in `arch/x86/kernel/smpboot.c`, and the `pr_cont()` in their “forgets” the log level it belongs to, maybe because of SMP and other messages are printed in between. ``` if (system_state < SYSTEM_RUNNING) { if (node != current_node) { if (current_node > (-1)) pr_cont("\n"); current_node = node; printk(KERN_INFO " node %*s#%d, CPUs: ", node_width - num_digits(node), " ", node); } /* Add padding for the BSP */ if (cpu == 1) pr_cont("%*s", width + 1, " "); pr_cont("%*s#%d", width - num_digits(cpu), " ", cpu); } else pr_info("Booting Node %d Processor %d APIC 0x%x\n", node, cpu, apicid); ``` Would using `pr_info()` instead be an acceptable fix? Kind regards, Paul
acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
Dear Linux folks, All the way up to QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-5) and Linux 5.10.13, Linux logs the warning below: acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge. One way to reproduce it: qemu-system-x86_64 -enable-kvm -m 2G -hda /dev/shm/debian.img -kernel /boot/vmlinuz-5.10.0-3-amd64 -initrd /boot/initrd.img-5.10.0-3-amd64 -append root="/dev/sda1 console=ttyS0,115200" -serial stdio Please find more details and the full log in the Bugzilla issue #211765 [1]. Kind regards, Paul [1]: https://bugzilla.kernel.org/show_bug.cgi?id=211765 "[Bug 211765] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge."
Re: [PATCH 2/2] ethernet: igb: e1000_phy: Check for ops.force_speed_duplex existence
Dear Jakub, dear Greg, Am 05.01.21 um 18:25 schrieb Greg KH: On Tue, Jan 05, 2021 at 06:16:59PM +0100, Paul Menzel wrote: Am 03.11.20 um 19:39 schrieb Jakub Kicinski: On Tue, 3 Nov 2020 08:35:09 +0100 Paul Menzel wrote: According to *Developer's Certificate of Origin 1.1* [3], it’s my understanding, that it is *not* required. The items (a), (b), and (c) are connected by an *or*. (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or Ack, but then you need to put yourself as the author, because it's you certifying that the code falls under (b). At least that's my understanding. Greg, can you please clarify, if it’s fine, if I upstream a patch authored by somebody else and distributed under the GPLv2? I put them as the author and signed it off. You can't add someone else's signed-off-by, but you can add your own and keep them as the author, has happened lots of time in the past. Or, you can make the From: line be from you if the original author doesn't want their name/email in the changelog, we've done that as well, both are fine. Greg, thank you for the clarification. Jakub, with that out of the way, can you please take patch 2/2? Kind regards, Paul
Re: [PATCH 2/2] ethernet: igb: e1000_phy: Check for ops.force_speed_duplex existence
Dear Jakub, dear Greg, Am 03.11.20 um 19:39 schrieb Jakub Kicinski: On Tue, 3 Nov 2020 08:35:09 +0100 Paul Menzel wrote: According to *Developer's Certificate of Origin 1.1* [3], it’s my understanding, that it is *not* required. The items (a), (b), and (c) are connected by an *or*. (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or Ack, but then you need to put yourself as the author, because it's you certifying that the code falls under (b). At least that's my understanding. Greg, can you please clarify, if it’s fine, if I upstream a patch authored by somebody else and distributed under the GPLv2? I put them as the author and signed it off. (In this case the change, adding an if condition, is also trivial.) Kind regards, Paul
Re: [Intel-wired-lan] [PATCH] net: ixgbe: Fix memleak in ixgbe_configure_clsu32
Dear Dinghao, Am 03.01.21 um 09:08 schrieb Dinghao Liu: When ixgbe_fdir_write_perfect_filter_82599() fails, input allocated by kzalloc() has not been freed, which leads to memleak. Nice find. Thank you for your patches. Out of curiosity, do you use an analysis tool to find these issues? Signed-off-by: Dinghao Liu --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c index 393d1c2cd853..e9c2d28efc81 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c @@ -9582,8 +9582,10 @@ static int ixgbe_configure_clsu32(struct ixgbe_adapter *adapter, ixgbe_atr_compute_perfect_hash_82599(&input->filter, mask); err = ixgbe_fdir_write_perfect_filter_82599(hw, &input->filter, input->sw_idx, queue); - if (!err) - ixgbe_update_ethtool_fdir_entry(adapter, input, input->sw_idx); + if (err) + goto err_out_w_lock; + + ixgbe_update_ethtool_fdir_entry(adapter, input, input->sw_idx); spin_unlock(&adapter->fdir_perfect_lock); if ((uhtid != 0x800) && (adapter->jump_tables[uhtid])) Reviewed-by: Paul Menzel I wonder, in the non-error case, how `input` and `jump` are freed. Old code: if (!err) ixgbe_update_ethtool_fdir_entry(adapter, input, input->sw_idx); spin_unlock(&adapter->fdir_perfect_lock); if ((uhtid != 0x800) && (adapter->jump_tables[uhtid])) set_bit(loc - 1, (adapter->jump_tables[uhtid])->child_loc_map); kfree(mask); return err; Should these two lines be replaced with `goto err_out`? (Though the name is confusing then, as it’s the non-error case.) err_out_w_lock: spin_unlock(&adapter->fdir_perfect_lock); err_out: kfree(mask); free_input: kfree(input); free_jump: kfree(jump); return err; } Kind regards, Paul
Re: [Intel-wired-lan] [PATCH] PCI: add Intel i210 quirk
Dear Michael, Thank you for the patch. Maybe the summary could be more specific: > PCI: Fix Intel i210 by avoiding overlapping of BARs Am 30.12.20 um 18:28 schrieb Michael Walle: The Intel i210 doesn't work if the Expansion ROM BAR overlaps with another BAR. Networking won't work at all and once a packet is sent the netdev watchdog will bite: [ 89.059374] [ cut here ] [ 89.064019] NETDEV WATCHDOG: enP2p1s0 (igb): transmit queue 0 timed out [ 89.070681] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:443 dev_watchdog+0x3a8/0x3b0 [ 89.078989] Modules linked in: [ 89.082053] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW 5.11.0-rc1-00020-gc16f033804b #289 [ 89.091574] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT) [ 89.099870] pstate: 6005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 89.105900] pc : dev_watchdog+0x3a8/0x3b0 [ 89.109923] lr : dev_watchdog+0x3a8/0x3b0 [ 89.113945] sp : 80001000bd50 [ 89.117268] x29: 80001000bd50 x28: 0008 [ 89.122602] x27: 0004 x26: 0140 [ 89.127935] x25: 002001c6c000 x24: 002001c2b940 [ 89.133267] x23: 8000118c7000 x22: 002001c6c39c [ 89.138600] x21: 002001c6bfb8 x20: 002001c6c3b8 [ 89.143932] x19: x18: 0010 [ 89.149264] x17: x16: [ 89.154596] x15: x14: 0720072007200720 [ 89.159928] x13: 0720072007740775 x12: 80001195b980 [ 89.165260] x11: 0003 x10: 800011943940 [ 89.170592] x9 : 800010100d44 x8 : 00017fe8 [ 89.175924] x7 : c000efff x6 : 0001 [ 89.181255] x5 : x4 : [ 89.186587] x3 : x2 : 8000118eb908 [ 89.191919] x1 : 84d8200845006900 x0 : [ 89.197251] Call trace: [ 89.199701] dev_watchdog+0x3a8/0x3b0 [ 89.203374] call_timer_fn+0x38/0x208 [ 89.207049] run_timer_softirq+0x290/0x540 [ 89.211158] __do_softirq+0x138/0x404 [ 89.214831] irq_exit+0xe8/0xf8 [ 89.217981] __handle_domain_irq+0x70/0xc8 [ 89.222091] gic_handle_irq+0xc8/0x2b0 [ 89.225850] el1_irq+0xb8/0x180 [ 89.228999] arch_cpu_idle+0x18/0x40 [ 89.232587] default_idle_call+0x70/0x214 [ 89.236610] do_idle+0x21c/0x290 [ 89.239848] cpu_startup_entry+0x2c/0x70 [ 89.243783] secondary_start_kernel+0x1a0/0x1f0 [ 89.248332] ---[ end trace 1687af62576397bc ]--- [ 89.253350] igb 0002:01:00.0 enP2p1s0: Reset adapter Before this fixup the Expansion ROM BAR will overlap with BAR3: # lspci -ns 2:1:0 -xx 0002:01:00.0 0200: 8086:1533 (rev 03) 00: 86 80 33 15 06 04 10 00 03 00 00 02 08 00 00 00 10: 00 00 00 40 00 00 00 00 00 00 00 00 00 00 20 40 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 03 00 30: 00 00 20 40 40 00 00 00 00 00 00 00 22 01 00 00 Add a quirk which will update the Expansion ROM BAR for Intel i210s even if the ROM is disabled. This was tested on an ARM64 board (kontron sl28). As this seems also related to the boot loader, please mention the name and version too. Maybe also add the output with the quirk applied? Signed-off-by: Michael Walle --- drivers/pci/quirks.c | 34 ++ 1 file changed, 34 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 653660e3ba9e..59c204ef5df7 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -5612,3 +5612,37 @@ static void apex_pci_fixup_class(struct pci_dev *pdev) } DECLARE_PCI_FIXUP_CLASS_HEADER(0x1ac1, 0x089a, PCI_CLASS_NOT_DEFINED, 8, apex_pci_fixup_class); + +/* + * Some devices doesn't work if the Expansion ROM has the same base address as don’t + * one of the other BARs although it is disabled. + * This might happen if the bootloader/BIOS enumerate the BARs in a different enumerates? + * way than linux. If the Expansion ROM is disabled, linux deliberately skip skip*s* + * writing the ROM BAR if the BAR is not enabled because of some broken + * devices, see pci_std_update_resource(). Thus, the ROM BAR of the device will + * still contain the value assigned by the booloader, which might be the same + * value as one of the other BARs then. + * + * As a workaround, update the Expansion ROM BAR even if the Expansion ROM is + * disabled. + */ +static void pci_fixup_rewrite_rom_bar(struct pci_dev *dev) +{ + struct resource *res = &dev->resource[PCI_ROM_RESOURCE]; + struct pci_bus_region region; + u32 rom_addr; + + pci_read_config_dword(dev, dev->rom_base_reg, &rom_addr); + + if (rom_addr & PCI_ROM_ADDRESS_ENABLE) + return; + + pcibios_resource_to_bus(dev->bus, ®ion, res); + rom_addr &= ~PCI_ROM_ADDRESS_MASK; + rom_addr |= region.start; + pci_write_config_dword(dev, dev->rom_base_reg, rom_addr); +} Can some debug message be added, that the quirk
120 s delay during boot with smaller initrd
Dear Linux folks, Using an initrd created by tiny-initramfs [1], the boot stalls for two minutes *after* the initrd has run and systemd has already started. An F2FS root partition is used. ``` [0.00] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28 [0.00] Linux version 5.9.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-1) 10.2.1 20201207, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.9.15-1 (2020-12-17) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.9.0-5-amd64 root=/dev/sda2 ro quiet noisapnp cryptomgr.notests random.trust_cpu=on tsc=unstable debug log_buf_len=2M initcall_debug […] [0.650168] Trying to unpack rootfs image as initramfs... [0.661343] Freeing initrd memory: 1024K […] [6.033044] systemd[1]: systemd 247.2-3 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified) […] [9.372134] fuse: init (API version 7.31) [9.396990] calling pkcs8_key_init+0x0/0x1000 [pkcs8_key_parser] @ 114 [9.413956] Asymmetric key parser 'pkcs8' registered [9.421378] initcall pkcs8_key_init+0x0/0x1000 [pkcs8_key_parser] returned 0 after 15912 usecs [9.433989] initcall fuse_init+0x0/0x142 [fuse] returned 0 after 28206 usecs [9.443229] calling drm_core_init+0x0/0x1000 [drm] @ 110 [9.480740] initcall drm_core_init+0x0/0x1000 [drm] returned 0 after 2 usecs [ 12.057456] random: crng init done [ 12.060811] random: 7 urandom warning(s) missed due to ratelimiting [ 135.871988] perf: interrupt took too long (2509 > 2500), lowering kernel.perf_event_max_sample_rate to 79500 [ 140.286157] audit: type=1400 audit(1609064788.012:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=142 comm="apparmor_parser" [ 140.315152] audit: type=1400 audit(1609064788.012:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=142 comm="apparmor_parser" [ 140.348623] audit: type=1400 audit(1609064788.072:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=155 comm="apparmor_parser" [ 140.382744] audit: type=1400 audit(1609064788.072:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=155 comm="apparmor_parser" [ 140.408791] audit: type=1400 audit(1609064788.072:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=155 comm="apparmor_parser" [ 140.439860] audit: type=1400 audit(1609064788.072:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/cups/backend/cups-pdf" pid=141 comm="apparmor_parser" [ 140.481521] calling acpi_cpufreq_init+0x0/0x1000 [acpi_cpufreq] @ 154 […] ``` The userspace log during that time could be: ``` Dez 27 11:24:17 sitopanaki systemd[1]: Finished Coldplug All udev Devices. Dez 27 11:24:17 sitopanaki systemd[1]: systemd-udev-trigger.service: Control group is empty. Dez 27 11:24:17 sitopanaki systemd[1]: sysinit.target: starting held back, waiting for: systemd-hwdb-update.service Dez 27 11:26:02 sitopanaki systemd[1]: systemd-journald.service: Got notification message from PID 113 (WATCHDOG=1) Dez 27 11:26:27 sitopanaki systemd-fsck[119]: Info: Fix the reported corruption. Dez 27 11:26:27 sitopanaki systemd-fsck[119]: Info: Mounted device! Dez 27 11:26:27 sitopanaki systemd-fsck[119]: Info: Check FS only due to RO ``` As it does not happen with the initrd created by initramfs-tools, but the initrd was successfully run, I am quite confused. Could it be F2FS related? Please find the full logs of both starts attached to bug #210917 [2]. Kind regards, Paul [1]: https://github.com/chris-se/tiny-initramfs/ [2]: https://bugzilla.kernel.org/show_bug.cgi?id=210917
Re: Pass modules to Linux kernel without initrd
Dear Enrico, Am 08.12.20 um 10:38 schrieb Enrico Weigelt, metux IT consult: On 08.12.20 10:24, Paul Menzel wrote: Similar to passing firmware and microcode update files to Linux or building these into the Linux kernel image, would it be possible to append the required modules to the Linux kernel image, and Linux would load these? Indeed, yes it does. Just set the corresponding CONFIG_ symbols to 'y' instead of 'm'. If you don't need to dynamically load any modules (already have everything you need compiled-in), you can completely disable module support via disabling CONFIG_MODULES. […] Thank you. I know this and do it myself. But, the requirement is to use the distribution Linux kernel (package). I am sorry for being unclear. Kind regards, Paul
Pass modules to Linux kernel without initrd
Dear Linux folks, Trying to reduce the boot time of standard distributions, I would like to get rid of the initrd. The initrd is for mounting the root file system and on most end user systems with standard distributions that means loading the bus driver for the drive and the file system driver. Everyone could build their own Linux kernel and build the drivers into the Linux kernel, but most users enjoy using the distribution Linux kernel, which build the drivers as modules to support a lot of systems. (I think Fedora builds the default file system driver (of the installer) into the Linux kernel.) A custom minimal initrd init script only loading the modules would also work, but as libkmod depends on libcrypto, which as a shared library is already three megabytes in size. Building libkmod statically would mean for distributions, that you need hooks to rebuild libkmod each time OpenSSL is updated (to get the changes). Similar to passing firmware and microcode update files to Linux or building these into the Linux kernel image, would it be possible to append the required modules to the Linux kernel image, and Linux would load these? Probably you are going to say, that is not how it works, but maybe I am lucky and you know a solution, or could point me to the right direction how such a think could be implemented. Kind regards, Paul
pci 0000:00:07.0: DPC: RP PIO log size 0 is invalid
[Bringing the issue up on the list in case the Linux Bugzilla is not monitored/used.] Dear Linux folks, On Intel Tiger Lake Dell laptop, Linux logs the error below [1]. [0.507307] pci :00:07.0: DPC: RP PIO log size 0 is invalid [0.508835] pci :00:07.2: DPC: RP PIO log size 0 is invalid $ lspci -nn -s 00:07 00:07.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP Thunderbolt PCI Express Root Port #0 [8086:9a23] (rev 01) 00:07.2 PCI bridge [0604]: Intel Corporation Tiger Lake-LP Thunderbolt PCI Express Root Port #2 [8086:9a27] (rev 01) Commit 2700561817 (PCI/DPC: Cache DPC capabilities in pci_init_capabilities()) [1] probably introduced it in Linux 5.7. What does this error actually mean? pdev->dpc_rp_log_size = (cap & PCI_EXP_DPC_RP_PIO_LOG_SIZE) >> 8; if (pdev->dpc_rp_log_size < 4 || pdev->dpc_rp_log_size > 9) { pci_err(pdev, "RP PIO log size %u is invalid\n", pdev->dpc_rp_log_size); pdev->dpc_rp_log_size = 0; } (I guess `cap & PCI_EXP_DPC_RP_PIO_LOG_SIZE` is zero too?) Is it a firmware issue or a hardware issue? Kind regards, Paul [1]: https://bugzilla.kernel.org/show_bug.cgi?id=209943 "pci :00:07.0: DPC: RP PIO log size 0 is invalid" [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=27005618178ef9e9bf9c42fd91101771c92e9308
Re: [SPECIFICATION RFC] The firmware and bootloader log specification
Dear Wim, dear Daniel, First, thank you for including all parties in the discussion. Am 04.12.20 um 13:52 schrieb Wim Vervoorn: I agree with you. Using an existing standard is better than inventing a new one in this case. I think using the coreboot logging is a good idea as there is indeed a lot of support already available and it is lightweight and simple. In my opinion coreboot’s format is lacking, that it does not record the timestamp, and the log level is not stored as metadata, but (in coreboot) only used to decide if to print the message or not. I agree with you, that an existing standard should be used, and in my opinion it’s Linux message format. That is most widely supported, and existing tools could then also work with pre-Linux messages. Sean Hudson from Mentor Graphics presented that idea at Embedded Linux Conference Europe 2016 [1]. No idea, if anything came out of that effort. (Unfortunately, I couldn’t find an email. Does somebody have contacts at Mentor to find out, how to reach him?) Kind regards, Paul [1]: http://events17.linuxfoundation.org/sites/events/files/slides/2016-10-12%20-%20ELCE%20-%20Shared%20Logging%20-%20Part%20Deux.pdf
Re: [RFC PATCH] iwlwifi: yoyo: don't print failure if debug firmware is missing
[Sorry, I did not know where and how to import the thread, and only got the first message from Patchwork.] Dear Linux folks, Am 25.06.20 um 18:52 schrieb Wolfram Sang: Missing this firmware is not fatal, my wifi card still works. Even more, I couldn't find any documentation what it is or where to get it. So, I don't think the users should be notified if it is missing. If you browse the net, you see the message is present is in quite some logs. Better remove it. Signed-off-by: Wolfram Sang --- This is only build tested because I wanted to get your opinions first. I couldn't find any explanation about yoyo, so I am entering unknown territory here. […] Despite commit 3f4600de8c93 (iwlwifi: yoyo: don't print failure if debug firmware is missing) being in Linux since version 5.9-rc1, I am still seeing this with Debian’s Linux 5.9.9. Kind regards, Paul
What to do with `BERT: Error records from previous boot`?
Dear Linux folks, On the Intel Tiger Lake Dell XPS 13 9310 Linux 5.9.9 from Debian sid/unstable logged the messages below. Please find the whole log in the Linux bug tracker [1]. ``` kernel: BERT: Error records from previous boot: kernel: [Hardware Error]: event severity: fatal kernel: [Hardware Error]: Error 0, type: fatal kernel: [Hardware Error]: section_type: Firmware Error Record Reference kernel: [Hardware Error]: Firmware Error Record Type: SOC Firmware Error Record Type2 kernel: [Hardware Error]: Revision: 2 kernel: [Hardware Error]: Record Identifier: 8f87f311-c998-4d9e-a0c4-6065518c4f6d kernel: [Hardware Error]: : 0100a306 0280 ca5824d3 03ab .$X. […] ``` How can I decode that error to understand what happened? Kind regards, Paul [1]: https://bugzilla.kernel.org/show_bug.cgi?id=210347
Re: [Intel-wired-lan] [PATCH] e1000e: Assign DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME to speed up s2ram
Dear Chen, Thank you for the patch. Am 24.11.20 um 16:32 schrieb Chen Yu: The NIC is put in runtime suspend status when there is no wire connected. As a result, it is safe to keep this NIC in runtime suspended during s2ram because the system does not rely on the NIC plug event nor WOL to wake up the system. Unlike the s2idle, s2ram does not need to manipulate S0ix settings during suspend. what happens, when I plug in a cable, when the suspend is in ACPI S3 state? I guess it’s ignored? This patch assigns DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME to the e1000e driver so that the s2ram could skip the .suspend_late(), .suspend_noirq() and .resume_noirq() .resume_early() when possible. Also skip .suspend() and .resume() if dev_pm_skip_suspend() and dev_pm_skip_resume() return true, so as to speed up the s2ram. What is sped up? Suspend or resume? Please also document, what system you tested this on, and what the numbers before and after are. If there is a bug report, please note it too. Signed-off-by: Chen Yu --- drivers/base/power/main.c | 2 ++ drivers/net/ethernet/intel/e1000e/netdev.c | 14 +- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index c7ac49042cee..9cd8abba8612 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -580,6 +580,7 @@ bool dev_pm_skip_resume(struct device *dev) return !dev->power.must_resume; } +EXPORT_SYMBOL_GPL(dev_pm_skip_resume); /** * device_resume_noirq - Execute a "noirq resume" callback for given device. @@ -2010,3 +2011,4 @@ bool dev_pm_skip_suspend(struct device *dev) return dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) && pm_runtime_status_suspended(dev); } +EXPORT_SYMBOL_GPL(dev_pm_skip_suspend); diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index b30f00891c03..d79fddabc553 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -6965,6 +6965,14 @@ static __maybe_unused int e1000e_pm_suspend(struct device *dev) struct e1000_hw *hw = &adapter->hw; int rc; + /* Runtime suspended means that there is no wired connection Maybe explicitly use *cable* in here to avoid confusion? +* and it has nothing to do with WOL that, we don't need to Move the comma before *that*? +* adjust the WOL settings. So it is safe to put NIC in +* runtime suspend while doing system suspend. I understood, that the NIC is already in runtime suspend? Could you please clarify the comment? +*/ + if (dev_pm_skip_suspend(dev)) + return 0; + e1000e_flush_lpic(pdev); e1000e_pm_freeze(dev); @@ -6989,6 +6997,9 @@ static __maybe_unused int e1000e_pm_resume(struct device *dev) struct e1000_hw *hw = &adapter->hw; int rc; + if (dev_pm_skip_resume(dev)) + return 0; + /* Introduce S0ix implementation */ if (hw->mac.type >= e1000_pch_cnp && !e1000e_check_me(hw->adapter->pdev->device)) @@ -7665,7 +7676,8 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent) e1000_print_device_info(adapter); - dev_pm_set_driver_flags(&pdev->dev, DPM_FLAG_NO_DIRECT_COMPLETE); + dev_pm_set_driver_flags(&pdev->dev, DPM_FLAG_NO_DIRECT_COMPLETE | + DPM_FLAG_SMART_SUSPEND | DPM_FLAG_MAY_SKIP_RESUME); if (pci_dev_run_wake(pdev) && hw->mac.type < e1000_pch_cnp) pm_runtime_put_noidle(&pdev->dev); Kind regards, Paul
[PATCH] ixgbe: Support external GBE SerDes PHY BCM54616s
From: Jostar Yang The Broadcom PHY is used in switches, so add the ID, and hook it up. This upstreams the Linux kernel patch from the network operating system SONiC from Februar 2020 [1]. [1]: https://github.com/Azure/sonic-linux-kernel/pull/122 Signed-off-by: Jostar Yang Signed-off-by: Guohan Lu Signed-off-by: Paul Menzel --- drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 3 +++ drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1 + 2 files changed, 4 insertions(+) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c index fc389eecdd2b..cb685e917b0c 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c @@ -380,6 +380,9 @@ static enum ixgbe_phy_type ixgbe_get_phy_type_from_id(u32 phy_id) case X557_PHY_ID2: phy_type = ixgbe_phy_x550em_ext_t; break; + case BCM54616S_E_PHY_ID: + phy_type = ixgbe_phy_ext_1g_t; + break; default: phy_type = ixgbe_phy_unknown; break; diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h index 2be1c4c72435..4c317b0dbfd4 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h @@ -1407,6 +1407,7 @@ struct ixgbe_nvm_version { #define QT2022_PHY_ID0x0043A400 #define ATH_PHY_ID 0x03429050 #define AQ_FW_REV0x20 +#define BCM54616S_E_PHY_ID 0x03625D10 /* Special PHY Init Routine */ #define IXGBE_PHY_INIT_OFFSET_NL 0x002B -- 2.29.2
Re: [PATCH 1/3] md: improve variable names in md_flush_request()
Dear Pankaj, Thank you for the cleanups. Am 11.11.20 um 06:16 schrieb Pankaj Gupta: From: Pankaj Gupta This patch improves readability by using better variable names in flush request coalescing logic. Please do not indent the commit message. Signed-off-by: Pankaj Gupta --- drivers/md/md.c | 8 drivers/md/md.h | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index 98bac4f304ae..167c80f98533 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -639,7 +639,7 @@ static void md_submit_flush_data(struct work_struct *ws) * could wait for this and below md_handle_request could wait for those * bios because of suspend check */ - mddev->last_flush = mddev->start_flush; + mddev->prev_flush_start = mddev->start_flush; mddev->flush_bio = NULL; wake_up(&mddev->sb_wait); @@ -660,13 +660,13 @@ static void md_submit_flush_data(struct work_struct *ws) */ bool md_flush_request(struct mddev *mddev, struct bio *bio) { - ktime_t start = ktime_get_boottime(); + ktime_t req_start = ktime_get_boottime(); spin_lock_irq(&mddev->lock); wait_event_lock_irq(mddev->sb_wait, !mddev->flush_bio || - ktime_after(mddev->last_flush, start), + ktime_after(mddev->prev_flush_start, req_start), mddev->lock); - if (!ktime_after(mddev->last_flush, start)) { + if (!ktime_after(mddev->prev_flush_start, req_start)) { WARN_ON(mddev->flush_bio); mddev->flush_bio = bio; bio = NULL; diff --git a/drivers/md/md.h b/drivers/md/md.h index ccfb69868c2e..2292c847f9dd 100644 --- a/drivers/md/md.h +++ b/drivers/md/md.h @@ -495,9 +495,9 @@ struct mddev { */ struct bio *flush_bio; atomic_t flush_pending; - ktime_t start_flush, last_flush; /* last_flush is when the last completed - * flush was started. - */ + ktime_t start_flush, prev_flush_start; /* prev_flush_start is when the previous completed + * flush was started. + */ With the new variable name, the comment could even be removed. ;-) struct work_struct flush_work; struct work_struct event_work; /* used by dm to report failure event */ mempool_t *serial_info_pool; Reviewed-by: Paul Menzel Kind regards, Paul
Re: jitterentropy: `jent_mod_init()` takes 17 ms
Dear Stephan, Thank you for the quick reply. Am 10.11.20 um 10:25 schrieb Stephan Mueller: Am Montag, 9. November 2020, 20:31:02 CET schrieb Paul Menzel: By mistake I built `XFRM_ESP` into the Linux kernel, resulting in CONFIG_CRYPTO_SEQIV=y CONFIG_CRYPTO_ECHAINIV=y and also the Jitterentropy RNG to be built in. CRYPTO_JITTERENTROPY=y So, on the Asus F2A85-M PRO starting Linux 4.10-rc3 with `initcall_debug`, the init method is run unconditionally, and it takes 17.5 ms, which is over ten percent of the overall 900 ms the Linux Hm, 17.5 / 900 = 2%, or am I missing something? Indeed, that is embarrassing. My bad. kernel needs until loading the init process. [0.300544] calling jent_mod_init+0x0/0x2c @ 1 [0.318438] initcall jent_mod_init+0x0/0x2c returned 0 after 17471 usecs Looking at the output of systemd-bootchart, it looks like, that this indeed delayed the boot a little, as the other init methods seem to be ordered after it. I am now building it as a module, but am wondering if the time can be reduced to below ten milliseconds. What you see is the test whether the Jitter RNG has a proper noise source. The function jent_entropy_init() is the cause of the operation. It performs 1024 times a test to validate the appropriateness of the noise source. You can adjust that with the TESTLOOPCOUNT in this function. But I am not sure adjusting is a wise course of action. Out of curiosity, why 1024 and not, for example, 128 or 2048? Is there some statistics behind it? Kind regards, Paul
jitterentropy: `jent_mod_init()` takes 17 ms
Dear Linux folks, By mistake I built `XFRM_ESP` into the Linux kernel, resulting in CONFIG_CRYPTO_SEQIV=y CONFIG_CRYPTO_ECHAINIV=y and also the Jitterentropy RNG to be built in. CRYPTO_JITTERENTROPY=y So, on the Asus F2A85-M PRO starting Linux 4.10-rc3 with `initcall_debug`, the init method is run unconditionally, and it takes 17.5 ms, which is over ten percent of the overall 900 ms the Linux kernel needs until loading the init process. [0.300544] calling jent_mod_init+0x0/0x2c @ 1 [0.318438] initcall jent_mod_init+0x0/0x2c returned 0 after 17471 usecs Looking at the output of systemd-bootchart, it looks like, that this indeed delayed the boot a little, as the other init methods seem to be ordered after it. I am now building it as a module, but am wondering if the time can be reduced to below ten milliseconds. Kind regards, Paul
Re: Linux 5.9: smartpqi: controller is offline: status code 0x6100c
Dear Don, Am 17.10.20 um 00:31 schrieb don.br...@microchip.com: The 6100C lockup is the result of the controller running out of commands to process new incoming requests from the driver. We are actively looking into this issue. Unfortunately, there has not been any further reply by the Microsemi support, and the driver 1.2.14-016 does not built against Linux 5.9 or master. Were you able to reproduce the issue? What is the timeline to getting this fixed? Linux 5.10 is going to be a long-term support release, so it would be great to have the problems fixed as soon as possible. Kind regards, Paul
[PATCH] netfilter: nf_nat: Support fullcone NAT
From: Kiran Kella Changes done in the kernel to ensure 3-tuple uniqueness of the conntrack entries for the fullcone nat functionality. * Hashlist is maintained for the 3-tuple unique keys (Protocol/Source IP/Port) for all the conntrack entries. * When NAT table rules are created with the fullcone option, the SNAT/POSTROUTING stage ensures the ports from the pool are picked up in such a way that the 3-tuple is uniquely assigned. * In the DNAT/POSTROUTING stage, the fullcone behavior is ensured by checking and reusing the 3-tuple for the Source IP/Port in the original direction. * When the pool is exhausted of the 3-tuple assignments, the packets are dropped, else, they will be going out of the router they being 5-tuple unique (which is not intended). * Passing fullcone option using iptables is part of another PR (in sonic-buildimage repo). The kernel changes mentioned above are done to counter the challenges explained in the section *3.4.2.1 Handling NAT model mismatch between the ASIC and the Kernel* in the NAT HLD [1]. [1]: https://github.com/kirankella/SONiC/blob/nat_doc_changes/doc/nat/nat_design_spec.md [Add to SONiC in https://github.com/Azure/sonic-linux-kernel/pull/100] Signed-off-by: Kiran Kella [forward port to Linux v4.19, https://github.com/Azure/sonic-linux-kernel/pull/147] Signed-off-by: Akhilesh Samineni Signed-off-by: Paul Menzel --- Dear Linux folks, This is taken from switch network operating system (NOS) SONiCâs Linux repository, where the support was added in September 2019 [1], and forwarded ported to Linux 4.19 by Akhilesh in June 2020 [2]. I am sending it upstream as a request for comments, before effort is put into forward porting it to Linux master. Kind regards, Paul [1]: https://github.com/Azure/sonic-linux-kernel/pull/100 [2]: https://github.com/Azure/sonic-linux-kernel/pull/147 include/net/netfilter/nf_conntrack.h | 3 + include/net/netfilter/nf_nat.h | 6 + include/net/netfilter/nf_nat_l4proto.h | 12 +- include/uapi/linux/netfilter/nf_nat.h| 1 + net/ipv4/netfilter/nf_nat_proto_gre.c| 8 +- net/ipv4/netfilter/nf_nat_proto_icmp.c | 6 +- net/ipv6/netfilter/nf_nat_proto_icmpv6.c | 5 +- net/netfilter/nf_nat_core.c | 173 --- net/netfilter/nf_nat_proto_common.c | 32 +++-- net/netfilter/nf_nat_proto_dccp.c| 6 +- net/netfilter/nf_nat_proto_sctp.c| 6 +- net/netfilter/nf_nat_proto_tcp.c | 6 +- net/netfilter/nf_nat_proto_udp.c | 12 +- net/netfilter/nf_nat_proto_unknown.c | 4 +- 14 files changed, 220 insertions(+), 60 deletions(-) diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h index f45141bdbb83..64b9293a31f6 100644 --- a/include/net/netfilter/nf_conntrack.h +++ b/include/net/netfilter/nf_conntrack.h @@ -84,6 +84,9 @@ struct nf_conn { #if IS_ENABLED(CONFIG_NF_NAT) struct hlist_node nat_bysource; #endif +/* To optionally ensure 3-tuple uniqueness on the translated source */ +struct hlist_node nat_by_manip_src; + /* all members below initialized via memset */ u8 __nfct_init_offset[0]; diff --git a/include/net/netfilter/nf_nat.h b/include/net/netfilter/nf_nat.h index a17eb2f8d40e..7c3cc3c7b35f 100644 --- a/include/net/netfilter/nf_nat.h +++ b/include/net/netfilter/nf_nat.h @@ -51,6 +51,12 @@ struct nf_conn_nat *nf_ct_nat_ext_add(struct nf_conn *ct); int nf_nat_used_tuple(const struct nf_conntrack_tuple *tuple, const struct nf_conn *ignored_conntrack); +/* Is this 3-tuple already taken? (not by us)*/ +int +nf_nat_used_3_tuple(const struct nf_conntrack_tuple *tuple, + const struct nf_conn *ignored_conntrack, + enum nf_nat_manip_type maniptype); + static inline struct nf_conn_nat *nfct_nat(const struct nf_conn *ct) { #if defined(CONFIG_NF_NAT) || defined(CONFIG_NF_NAT_MODULE) diff --git a/include/net/netfilter/nf_nat_l4proto.h b/include/net/netfilter/nf_nat_l4proto.h index b4d6b29bca62..fbcbb9ad9e4b 100644 --- a/include/net/netfilter/nf_nat_l4proto.h +++ b/include/net/netfilter/nf_nat_l4proto.h @@ -32,7 +32,7 @@ struct nf_nat_l4proto { * possible. Per-protocol part of tuple is initialized to the * incoming packet. */ - void (*unique_tuple)(const struct nf_nat_l3proto *l3proto, + int (*unique_tuple)(const struct nf_nat_l3proto *l3proto, struct nf_conntrack_tuple *tuple, const struct nf_nat_range2 *range, enum nf_nat_manip_type maniptype, @@ -70,11 +70,11 @@ bool nf_nat_l4proto_in_range(const struct nf_conntrack_tuple *tuple, const union nf_conntrack_man_proto *min, const union nf_conntrack_man_proto *max); -void nf_nat_l4proto_unique_tuple(const struct
[PATCH] kexec: Add kexec reboot string
From: Joe LeVeque The purpose is to notify the kernel module for fast reboot. Upstream a patch from the SONiC network operating system [1]. [1]: https://github.com/Azure/sonic-linux-kernel/pull/46 Signed-off-by: Paul Menzel --- kernel/kexec_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c index 8798a8183974..9aaa6ce48cdf 100644 --- a/kernel/kexec_core.c +++ b/kernel/kexec_core.c @@ -1167,7 +1167,7 @@ int kernel_kexec(void) #endif { kexec_in_progress = true; - kernel_restart_prepare(NULL); + kernel_restart_prepare("kexec reboot"); migrate_to_reboot_cpu(); /* -- 2.29.2
Re: [PATCH 2/2] ethernet: igb: e1000_phy: Check for ops.force_speed_duplex existence
Dear Jakub, Am 03.11.20 um 01:19 schrieb Jakub Kicinski: On Tue, 3 Nov 2020 00:13:07 +0100 Paul Menzel wrote: From: Jeffrey Townsend The ops field might no be defined, so add a check. This change should be first, otherwise AFAIU if someone builds the kernel in between the commits (e.g. for bisection) it will crash. Patch `[PATCH 1/2] ethernet: igb: Support PHY BCM5461S` has phy->ops.force_speed_duplex = igb_phy_force_speed_duplex_82580; so the ordering does not matter. I do not know, if Jeffrey can comment, but probably the check was just adding during development. Maybe an assert should be added instead? The patch is taken from Open Network Linux (ONL), and it was added there as part of the patch packages/base/any/kernels/3.16+deb8/patches/driver-support-intel-igb-bcm5461X-phy.patch in ONL commit f32316c63c (Support the BCM54616 and BCM5461S.) [1]. Part of this commit was already upstreamed in Linux commit eeb0149660 (igb: support BCM54616 PHY) in 2017. I applied the forward-ported packages/base/any/kernels/5.4-lts/patches/0002-driver-support-intel-igb-bcm5461S-phy.patch added in ONL commit 5ace6bcdb3 (Add 5.4 LTS kernel build.) [2]. [1]: https://github.com/opencomputeproject/OpenNetworkLinux/commit/f32316c63ce3a64de125b7429115c6d45e942bd1 [2]: https://github.com/opencomputeproject/OpenNetworkLinux/commit/5ace6bcdb37cb8065dcd1d4404b3dcb6424f6331 No need to put this in every commit message. We preserve the cover letter in tree as a merge commit message, so explaining things once in the cover letter is sufficient. I remember, but still find it confusing. If I look at a commit with `git show …`, I normally do not think of also looking at a possible cover letter as not many subsystems/projects do it, and I assume a commit is self-contained. Could you share your development process Cc: Jeffrey Townsend Jefferey will need to provide a sign-off as the author. According to *Developer's Certificate of Origin 1.1* [3], it’s my understanding, that it is *not* required. The items (a), (b), and (c) are connected by an *or*. (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or Cc: John W Linville Signed-off-by: Paul Menzel Kind regards, Paul [3]: https://www.kernel.org/doc/html/v5.9/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
Re: [PATCH 1/2] ethernet: igb: Support PHY BCM5461S
Dear Linux folks, Am 03.11.20 um 00:13 schrieb Paul Menzel: From: Jeffrey Townsend The BCM5461S PHY is used in switches. The patch is taken from Open Network Linux, and it was added there as patch packages/base/any/kernels/3.16+deb8/patches/driver-support-intel-igb-bcm5461X-phy.patch in ONL commit f32316c63c (Support the BCM54616 and BCM5461S.) [1]. Part of this commit was already upstreamed in Linux commit eeb0149660 (igb: support BCM54616 PHY) in 2017. I applied the forward-ported packages/base/any/kernels/5.4-lts/patches/0002-driver-support-intel-igb-bcm5461S-phy.patch added in ONL commit 5ace6bcdb3 (Add 5.4 LTS kernel build.) [2]. [1]: https://github.com/opencomputeproject/OpenNetworkLinux/commit/f32316c63ce3a64de125b7429115c6d45e942bd1 [2]: https://github.com/opencomputeproject/OpenNetworkLinux/commit/5ace6bcdb37cb8065dcd1d4404b3dcb6424f6331 Cc: Jeffrey Townsend Cc: John W Linville Signed-off-by: Paul Menzel --- drivers/net/ethernet/intel/igb/e1000_82575.c | 23 +- .../net/ethernet/intel/igb/e1000_defines.h| 1 + drivers/net/ethernet/intel/igb/e1000_hw.h | 1 + drivers/net/ethernet/intel/igb/e1000_phy.c| 77 +++ drivers/net/ethernet/intel/igb/e1000_phy.h| 2 + drivers/net/ethernet/intel/igb/igb_main.c | 8 ++ 6 files changed, 111 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.c b/drivers/net/ethernet/intel/igb/e1000_82575.c index 50863fd87d53..83c14ae689b1 100644 --- a/drivers/net/ethernet/intel/igb/e1000_82575.c +++ b/drivers/net/ethernet/intel/igb/e1000_82575.c @@ -308,6 +308,12 @@ static s32 igb_init_phy_params_82575(struct e1000_hw *hw) phy->ops.set_d3_lplu_state = igb_set_d3_lplu_state_82580; phy->ops.force_speed_duplex = igb_phy_force_speed_duplex_m88; break; + case BCM5461S_PHY_ID: + phy->type= e1000_phy_bcm5461s; Do not align the = with the one on the line below. + phy->ops.check_polarity = NULL; + phy->ops.get_cable_length = NULL; + phy->ops.force_speed_duplex = igb_phy_force_speed_duplex_82580; + break; case BCM54616_E_PHY_ID: phy->type = e1000_phy_bcm54616; break; @@ -866,6 +872,16 @@ static s32 igb_get_phy_id_82575(struct e1000_hw *hw) goto out; } ret_val = igb_get_phy_id(hw); + if (ret_val && hw->mac.type == e1000_i354) { + /* we do a special check for bcm5461s phy by setting +* the phy->addr to 5 and doing the phy check again. This +* call will succeed and retrieve a valid phy id if we have +* the bcm5461s phy +*/ + phy->addr = 5; + phy->type = e1000_phy_bcm5461s; + ret_val = igb_get_phy_id(hw); + } goto out; } @@ -1253,6 +1269,9 @@ static s32 igb_get_cfg_done_82575(struct e1000_hw *hw) (hw->phy.type == e1000_phy_igp_3)) igb_phy_init_script_igp3(hw); + if (hw->phy.type == e1000_phy_bcm5461s) + igb_phy_init_script_5461s(hw); + return 0; } @@ -1582,6 +1601,7 @@ static s32 igb_setup_copper_link_82575(struct e1000_hw *hw) case e1000_i350: case e1000_i210: case e1000_i211: + case e1000_i354: Any idea, why e1000_i350 is at the top? phpm_reg = rd32(E1000_82580_PHY_POWER_MGMT); phpm_reg &= ~E1000_82580_PM_GO_LINKD; wr32(E1000_82580_PHY_POWER_MGMT, phpm_reg); @@ -1627,7 +1647,8 @@ static s32 igb_setup_copper_link_82575(struct e1000_hw *hw) ret_val = igb_copper_link_setup_82580(hw); break; case e1000_phy_bcm54616: - ret_val = 0; + break; + case e1000_phy_bcm5461s: break; John, any idea, why you did not upstream the `ret_val = 0` line? default: ret_val = -E1000_ERR_PHY; diff --git a/drivers/net/ethernet/intel/igb/e1000_defines.h b/drivers/net/ethernet/intel/igb/e1000_defines.h index d2e2c50ce257..0561ef6cb29c 100644 --- a/drivers/net/ethernet/intel/igb/e1000_defines.h +++ b/drivers/net/ethernet/intel/igb/e1000_defines.h @@ -886,6 +886,7 @@ #define M88E1543_E_PHY_ID0x01410EA0 #define M88E1512_E_PHY_ID0x01410DD0 #define BCM54616_E_PHY_ID0x03625D10 +#define BCM5461S_PHY_ID 0x002060C0 Should this be `BCM5461S_E_PHY_ID` for consistency? I have no idea, what `_E` means? /* M88E1000 Specific Registers */ #define M88E1000_PHY_SPEC_CTRL 0x10 /* PHY Specific Control Register */ diff --git a/drivers/net/ethernet/intel/igb/e1000_hw.h b/drivers/net/ethernet/intel/igb
[PATCH 1/2] ethernet: igb: Support PHY BCM5461S
From: Jeffrey Townsend The BCM5461S PHY is used in switches. The patch is taken from Open Network Linux, and it was added there as patch packages/base/any/kernels/3.16+deb8/patches/driver-support-intel-igb-bcm5461X-phy.patch in ONL commit f32316c63c (Support the BCM54616 and BCM5461S.) [1]. Part of this commit was already upstreamed in Linux commit eeb0149660 (igb: support BCM54616 PHY) in 2017. I applied the forward-ported packages/base/any/kernels/5.4-lts/patches/0002-driver-support-intel-igb-bcm5461S-phy.patch added in ONL commit 5ace6bcdb3 (Add 5.4 LTS kernel build.) [2]. [1]: https://github.com/opencomputeproject/OpenNetworkLinux/commit/f32316c63ce3a64de125b7429115c6d45e942bd1 [2]: https://github.com/opencomputeproject/OpenNetworkLinux/commit/5ace6bcdb37cb8065dcd1d4404b3dcb6424f6331 Cc: Jeffrey Townsend Cc: John W Linville Signed-off-by: Paul Menzel --- drivers/net/ethernet/intel/igb/e1000_82575.c | 23 +- .../net/ethernet/intel/igb/e1000_defines.h| 1 + drivers/net/ethernet/intel/igb/e1000_hw.h | 1 + drivers/net/ethernet/intel/igb/e1000_phy.c| 77 +++ drivers/net/ethernet/intel/igb/e1000_phy.h| 2 + drivers/net/ethernet/intel/igb/igb_main.c | 8 ++ 6 files changed, 111 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.c b/drivers/net/ethernet/intel/igb/e1000_82575.c index 50863fd87d53..83c14ae689b1 100644 --- a/drivers/net/ethernet/intel/igb/e1000_82575.c +++ b/drivers/net/ethernet/intel/igb/e1000_82575.c @@ -308,6 +308,12 @@ static s32 igb_init_phy_params_82575(struct e1000_hw *hw) phy->ops.set_d3_lplu_state = igb_set_d3_lplu_state_82580; phy->ops.force_speed_duplex = igb_phy_force_speed_duplex_m88; break; + case BCM5461S_PHY_ID: + phy->type = e1000_phy_bcm5461s; + phy->ops.check_polarity = NULL; + phy->ops.get_cable_length = NULL; + phy->ops.force_speed_duplex = igb_phy_force_speed_duplex_82580; + break; case BCM54616_E_PHY_ID: phy->type = e1000_phy_bcm54616; break; @@ -866,6 +872,16 @@ static s32 igb_get_phy_id_82575(struct e1000_hw *hw) goto out; } ret_val = igb_get_phy_id(hw); + if (ret_val && hw->mac.type == e1000_i354) { + /* we do a special check for bcm5461s phy by setting +* the phy->addr to 5 and doing the phy check again. This +* call will succeed and retrieve a valid phy id if we have +* the bcm5461s phy +*/ + phy->addr = 5; + phy->type = e1000_phy_bcm5461s; + ret_val = igb_get_phy_id(hw); + } goto out; } @@ -1253,6 +1269,9 @@ static s32 igb_get_cfg_done_82575(struct e1000_hw *hw) (hw->phy.type == e1000_phy_igp_3)) igb_phy_init_script_igp3(hw); + if (hw->phy.type == e1000_phy_bcm5461s) + igb_phy_init_script_5461s(hw); + return 0; } @@ -1582,6 +1601,7 @@ static s32 igb_setup_copper_link_82575(struct e1000_hw *hw) case e1000_i350: case e1000_i210: case e1000_i211: + case e1000_i354: phpm_reg = rd32(E1000_82580_PHY_POWER_MGMT); phpm_reg &= ~E1000_82580_PM_GO_LINKD; wr32(E1000_82580_PHY_POWER_MGMT, phpm_reg); @@ -1627,7 +1647,8 @@ static s32 igb_setup_copper_link_82575(struct e1000_hw *hw) ret_val = igb_copper_link_setup_82580(hw); break; case e1000_phy_bcm54616: - ret_val = 0; + break; + case e1000_phy_bcm5461s: break; default: ret_val = -E1000_ERR_PHY; diff --git a/drivers/net/ethernet/intel/igb/e1000_defines.h b/drivers/net/ethernet/intel/igb/e1000_defines.h index d2e2c50ce257..0561ef6cb29c 100644 --- a/drivers/net/ethernet/intel/igb/e1000_defines.h +++ b/drivers/net/ethernet/intel/igb/e1000_defines.h @@ -886,6 +886,7 @@ #define M88E1543_E_PHY_ID0x01410EA0 #define M88E1512_E_PHY_ID0x01410DD0 #define BCM54616_E_PHY_ID0x03625D10 +#define BCM5461S_PHY_ID 0x002060C0 /* M88E1000 Specific Registers */ #define M88E1000_PHY_SPEC_CTRL 0x10 /* PHY Specific Control Register */ diff --git a/drivers/net/ethernet/intel/igb/e1000_hw.h b/drivers/net/ethernet/intel/igb/e1000_hw.h index 5d87957b2627..a660675d6218 100644 --- a/drivers/net/ethernet/intel/igb/e1000_hw.h +++ b/drivers/net/ethernet/intel/igb/e1000_hw.h @@ -110,6 +110,7 @@ enum e1000_phy_type { e1000_phy_82580, e1000_phy_i210, e1000_phy_bcm54616, + e1000_phy_bcm5461s, }; enum e1000_bus_type { diff --git a/dr
[PATCH 2/2] ethernet: igb: e1000_phy: Check for ops.force_speed_duplex existence
From: Jeffrey Townsend The ops field might no be defined, so add a check. The patch is taken from Open Network Linux (ONL), and it was added there as part of the patch packages/base/any/kernels/3.16+deb8/patches/driver-support-intel-igb-bcm5461X-phy.patch in ONL commit f32316c63c (Support the BCM54616 and BCM5461S.) [1]. Part of this commit was already upstreamed in Linux commit eeb0149660 (igb: support BCM54616 PHY) in 2017. I applied the forward-ported packages/base/any/kernels/5.4-lts/patches/0002-driver-support-intel-igb-bcm5461S-phy.patch added in ONL commit 5ace6bcdb3 (Add 5.4 LTS kernel build.) [2]. [1]: https://github.com/opencomputeproject/OpenNetworkLinux/commit/f32316c63ce3a64de125b7429115c6d45e942bd1 [2]: https://github.com/opencomputeproject/OpenNetworkLinux/commit/5ace6bcdb37cb8065dcd1d4404b3dcb6424f6331 Cc: Jeffrey Townsend Cc: John W Linville Signed-off-by: Paul Menzel --- drivers/net/ethernet/intel/igb/e1000_phy.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/intel/igb/e1000_phy.c b/drivers/net/ethernet/intel/igb/e1000_phy.c index 4e0b4ba09a00..4151e55a6d2a 100644 --- a/drivers/net/ethernet/intel/igb/e1000_phy.c +++ b/drivers/net/ethernet/intel/igb/e1000_phy.c @@ -1107,11 +1107,13 @@ s32 igb_setup_copper_link(struct e1000_hw *hw) /* PHY will be set to 10H, 10F, 100H or 100F * depending on user settings. */ - hw_dbg("Forcing Speed and Duplex\n"); - ret_val = hw->phy.ops.force_speed_duplex(hw); - if (ret_val) { - hw_dbg("Error Forcing Speed and Duplex\n"); - goto out; + if (hw->phy.ops.force_speed_duplex) { + hw_dbg("Forcing Speed and Duplex\n"); + ret_val = hw->phy.ops.force_speed_duplex(hw); + if (ret_val) { + hw_dbg("Error Forcing Speed and Duplex\n"); + goto out; + } } } -- 2.29.1
[PATCH 0/2] Upstream ONL patch for PHY BCM5461S
Dear Linux folks, Looking a little bit at Open Network Linux, they carry some Linux patches, but have not upstreamed them yet. This upstreams support for the PHY BCM5461S. It’d be great, if you could help review it. Kind regards, Paul Jeffrey Townsend (2): ethernet: igb: Support PHY BCM5461S ethernet: igb: e1000_phy: Check for ops.force_speed_duplex existence drivers/net/ethernet/intel/igb/e1000_82575.c | 23 - .../net/ethernet/intel/igb/e1000_defines.h| 1 + drivers/net/ethernet/intel/igb/e1000_hw.h | 1 + drivers/net/ethernet/intel/igb/e1000_phy.c| 89 +-- drivers/net/ethernet/intel/igb/e1000_phy.h| 2 + drivers/net/ethernet/intel/igb/igb_main.c | 8 ++ 6 files changed, 118 insertions(+), 6 deletions(-) -- 2.29.1
Re: [PATCH v2 1/2] init/Kconfig: Fix CPU number in LOG_CPU_MAX_BUF_SHIFT description
Dear Petr, Am 11.08.20 um 11:29 schrieb Paul Menzel: Currently, LOG_BUF_SHIFT defaults to 17, which is 2 ^ 17 bytes = 128 KB, and LOG_CPU_MAX_BUF_SHIFT defaults to 12, which is 2 ^ 12 bytes = 4 KB. Half of 128 KB is 64 KB, so more than 16 CPUs are required for the value to be used, as then the sum of contributions is greater than 64 KB for the first time. My guess is, that the description was written with the configuration values used in the SUSE in mind. Fixes: 23b2899f7f ("printk: allow increasing the ring buffer depending on the number of CPUs") Cc: Luis R. Rodriguez Cc: linux-kernel@vger.kernel.org Reviewed-by: Petr Mladek Signed-off-by: Paul Menzel --- v2: Add Reviewed-by tag init/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/Kconfig b/init/Kconfig index d6a0b31b13dc..9dc607e3806f 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -718,7 +718,7 @@ config LOG_CPU_MAX_BUF_SHIFT with more CPUs. Therefore this value is used only when the sum of contributions is greater than the half of the default kernel ring buffer as defined by LOG_BUF_SHIFT. The default values are set - so that more than 64 CPUs are needed to trigger the allocation. + so that more than 16 CPUs are needed to trigger the allocation. Also this option is ignored when "log_buf_len" kernel parameter is used as it forces an exact (power of two) size of the ring buffer. Could you please apply this trivial patch from the two patches already, so I do not have to resend it? Kind regards, Paul
Re: [PATCH v2 2/2] init/Kconfig: Increase default log buffer size from 128 KB to 512 KB
Dear Petr, Am 11.08.20 um 12:53 schrieb Petr Mladek: On Tue 2020-08-11 11:29:24, Paul Menzel wrote: Commit f17a32e97e (let LOG_BUF_SHIFT default to 17) from 2008 was the last time, the the default log buffer size bump was increased. Machines have evolved, and on current hardware, enough memory is present, and some devices have over 200 PCI devices, like a two socket Skylake-E server, resulting a lot of lines. Therefore, increase the default from 128 KB to 512 KB. Anyone, with limited memory, can still lower it. --- a/init/Kconfig +++ b/init/Kconfig @@ -681,9 +681,9 @@ config IKHEADERS kheaders.ko is built which can be loaded on-demand to get access to headers. config LOG_BUF_SHIFT - int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" + int "Kernel log buffer size (17 => 128KB, 19 => 512KB)" range 12 25 - default 17 + default 19 depends on PRINTK help Select the minimal kernel log buffer size as a power of 2. Honestly, I do not have experience with changing the defaults. People hacking small devices might complain. Well, this can be solved by increasing the default only when BASE_FULL is set. I am personally fine with increasing the default when BASE_FULL is set. The amount of messages is growing over time because of increasing complexity of both the hardware and software. Fortunately also the amount of available memory is growing. Well, this should get discussed in wider audience. Adding some people into CC. JFYI, it started with report of lost messages, see https://lore.kernel.org/lkml/264bfbae-122d-9c41-59ea-6413f91bd...@molgen.mpg.de/ As there was no objection, is it possible to apply the two patches, and maybe even get them into Linux 5.10? Kind regards, Paul
Intel PMC driver on Broadwell system to gather C-State statistics
Dear Linux folks, The Intel Broadwell-U laptop Dell Latitude E7250 (BIOS A19 01/23/2018), according to PowerTOP, only reaches package C-State C7 and not C8, C9, C10, while the four CPUs itself do reach C-State C10 and CE. I was asked to look at: 1. `/sys/kernel/debug/pmc_core/package_cstate_show` 2. `/sys/kernel/debug/pmc_core/ltr` Trying to gather statistics, after the Debian Linux kernel 5.9.1 is now built with `INTEL_PMC_CORE=y`, `/sys/kernel/debug/pmc_core/` is still not created despite `sudo modprobe intel_pmc_core` being successful. (It’s not loaded automatically.) [ 1063.644680] calling pmc_core_driver_init+0x0/0x1000 [intel_pmc_core] @ 4252 [ 1063.644721] initcall pmc_core_driver_init+0x0/0x1000 [intel_pmc_core] returned 0 after 36 usecs The ACPI device `INT33A1` is there. Scope (_SB) { Device (PEPD) { Name (_HID, "INT33A1" /* Intel Power Engine */) // _HID: Hardware ID Name (_CID, EisaId ("PNP0D80") /* Windows-compatible System Power Management Controller */) // _CID: Compatible ID Name (_UID, One) // _UID: Unique ID Name (PEPP, Zero) Name (DEVS, Package (0x03) { 0x02, Package (0x01) { "\\_SB.PCI0.GFX0" }, Package (0x01) { "\\_SB.PCI0.SAT0.PRT1" } }) Name (DEVX, Package (0x08) The table `intel_pmc_core_ids` does not contain the Broadwell-U ID though, so I guess it’s not supported. $ lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09) 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) 00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller [8086:160c] (rev 09) 00:04.0 Signal processing controller [1180]: Intel Corporation Broadwell-U Processor Thermal Subsystem [8086:1603] (rev 09) 00:14.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB xHCI Controller [8086:9cb1] (rev 03) 00:16.0 Communication controller [0780]: Intel Corporation Wildcat Point-LP MEI Controller #1 [8086:9cba] (rev 03) 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection (3) I218-LM [8086:15a2] (rev 03) 00:1b.0 Audio device [0403]: Intel Corporation Wildcat Point-LP High Definition Audio Controller [8086:9ca0] (rev 03) 00:1c.0 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI Express Root Port #1 [8086:9c90] (rev e3) 00:1c.3 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI Express Root Port #4 [8086:9c96] (rev e3) 00:1d.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB EHCI Controller [8086:9ca6] (rev 03) 00:1f.0 ISA bridge [0601]: Intel Corporation Wildcat Point-LP LPC Controller [8086:9cc3] (rev 03) 00:1f.2 SATA controller [0106]: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] [8086:9c83] (rev 03) 00:1f.3 SMBus [0c05]: Intel Corporation Wildcat Point-LP SMBus Controller [8086:9ca2] (rev 03) 01:00.0 SD Host controller [0805]: O2 Micro, Inc. SD/MMC Card Reader Controller [1217:8520] (rev 01) 02:00.0 Network controller [0280]: Intel Corporation Wireless 7265 [8086:095a] (rev 59) Any idea, why the probe function `pmc_core_probe()` succeeds, despite the code below? cpu_id = x86_match_cpu(intel_pmc_core_ids); if (!cpu_id) return -ENODEV; The watchdog driver iTCO_wdt seems to load the module `pmc_core_bxt` despite I am unable to find the ACPI device `INT34D2` in the dissembled AML/ASL files. Kind regards, Paul
Linux 5.9: smartpqi: controller is offline: status code 0x6100c
Dear Linux folks, With Linux 5.9 and $ lspci -nn -s 89: 89:00.0 Serial Attached SCSI controller [0107]: Adaptec Smart Storage PQI 12G SAS/PCIe 3 [9005:028f] (rev 01) $ more /sys/devices/pci:88/:88:00.0/:89:00.0/host15/scsi_host/host15/driver_version 1.2.8-026 $ more /sys/devices/pci:88/:88:00.0/:89:00.0/host15/scsi_host/host15/firmware_version 2.62-0 the controller went offline with status code 0x6100c. Oct 14 14:54:01 done.molgen.mpg.de kernel: smartpqi :89:00.0: controller is offline: status code 0x6100c Oct 14 14:54:01 done.molgen.mpg.de kernel: smartpqi :89:00.0: controller offline Oct 14 14:54:01 done.molgen.mpg.de kernel: sd 15:0:2:0: [sdu] tag#709 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=6s Oct 14 14:54:01 done.molgen.mpg.de kernel: sd 15:0:15:0: [sdah] tag#274 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=6s Oct 14 14:54:01 done.molgen.mpg.de kernel: sd 15:0:4:0: [sdw] tag#516 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=6s Oct 14 14:54:01 done.molgen.mpg.de kernel: sd 15:0:4:0: [sdw] tag#516 CDB: Write(10) 2a 00 0d e6 9e 88 00 00 01 00 Oct 14 14:54:01 done.molgen.mpg.de kernel: blk_update_request: I/O error, dev sdw, sector 1865741376 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 Oct 14 14:54:01 done.molgen.mpg.de kernel: sd 15:0:0:0: [sds] tag#529 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=6s Oct 14 14:54:01 done.molgen.mpg.de kernel: sd 15:0:0:0: [sds] tag#529 CDB: Write(10) 2a 00 29 4e e8 ff 00 00 01 00 Oct 14 14:54:01 done.molgen.mpg.de kernel: blk_update_request: I/O error, dev sds, sector 5544298488 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 Oct 14 14:54:01 done.molgen.mpg.de kernel: sd 15:0:0:0: [sds] tag#627 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=6s Oct 14 14:54:01 done.molgen.mpg.de kernel: sd 15:0:0:0: [sds] tag#627 CDB: Read(10) 28 00 5d df 2c 04 00 00 04 00 Oct 14 14:54:01 done.molgen.mpg.de kernel: blk_update_request: I/O error, dev sds, sector 12599255072 op 0x0:(READ) flags 0x1000 phys_seg 1 prio class Oct 14 14:54:01 done.molgen.mpg.de kernel: sd 15:0:5:0: [sdx] tag#567 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=6s Oct 14 14:54:01 done.molgen.mpg.de kernel: sd 15:0:5:0: [sdx] tag#567 CDB: Write(10) 2a 00 21 4e ce 04 00 00 04 00 How can the status code 0x6100c be deciphered? Kind regards, Paul
Re: i8042_init: PS/2 mouse not detected with ACPIPnP/PnPBIOS
Dear Rafael, dear Dmitry, Am 12.10.20 um 13:00 schrieb Rafael J. Wysocki: On Mon, Oct 12, 2020 at 12:50 PM Paul Menzel wrote: Am 12.10.20 um 12:39 schrieb Rafael J. Wysocki: On Sun, Oct 11, 2020 at 1:08 AM Paul Menzel wrote: Am 08.10.20 um 00:16 schrieb Dmitry Torokhov: On Wed, Oct 07, 2020 at 11:18:41PM +0200, Paul Menzel wrote: On the Asus F2A85-M PRO Linux 5.9-rc8 (and previous versions) does not recognize a plugged in PS/2 mouse using the Plug & Play method. The PS/2 keyboard is detected fine, and using `i8042.nopnp`, the PS/2 mouse also works. [1.035915] calling i8042_init+0x0/0x42d @ 1 [1.035947] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 [1.035948] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp [1.036589] serio: i8042 KBD port at 0x60,0x64 irq 1 [1.036621] initcall i8042_init+0x0/0x42d returned 0 after 687 usecs But, the DSDT includes the “mouse device”. From acpidump > dump.bin; acpixtract dump.bin; iasl -d *dat; more dsdt.dsl we get Device (PS2M) { Name (_HID, EisaId ("PNP0F03") /* Microsoft PS/2-style Mouse */) // _HID: Hardware ID Name (_CID, EisaId ("PNP0F13") /* PS/2 Mouse */) // _CID: Compatible ID Method (_STA, 0, NotSerialized) // _STA: Status { If ((IOST & 0x4000)) { Return (0x0F) } Else { Return (Zero) } } and the identifiers PNP0F03 and PNP0F13 are both listed in the array `pnp_aux_devids[]`. But adding print statements to `i8042_pnp_aux_probe()`, I do not see them, so the function does not seem to be called. My guess is that _STA returns 0 indicating that the device is not present. I would try tracking where IOST is being set and figuring out why it does not have mouse bit enabled. Does the ACPI subsystem allow to track, how ACPI variables(?) like IOST are read and set? My guess would be that IOST is a field in an operation region which would indicate that it is initialized by the bootstrap part of the BIOS. Thank you for your answer. But how can I verify that? Inspecting the ACPI tables from the system in question could help you to find out whether or not IOST really is a field in an operation region, but its initial value may not be possible to determine this way. Is there a Linux kernel parameter, that would print it? Not that I know of. I created an issue in the Linux kernel bugtracker [1] and attached the output of `acpidump` there. Could If ((IOST & 0x4000)) versus If ((IOST & 0x0400)) be a typo? Kind regards, Paul [1]: https://bugzilla.kernel.org/show_bug.cgi?id=209657
Re: i8042_init: PS/2 mouse not detected with ACPIPnP/PnPBIOS
Dear Rafael, Am 12.10.20 um 12:39 schrieb Rafael J. Wysocki: On Sun, Oct 11, 2020 at 1:08 AM Paul Menzel wrote: Dear Dmitry, dear Rafael, dear Len, Am 08.10.20 um 00:16 schrieb Dmitry Torokhov: On Wed, Oct 07, 2020 at 11:18:41PM +0200, Paul Menzel wrote: On the Asus F2A85-M PRO Linux 5.9-rc8 (and previous versions) does not recognize a plugged in PS/2 mouse using the Plug & Play method. The PS/2 keyboard is detected fine, and using `i8042.nopnp`, the PS/2 mouse also works. [1.035915] calling i8042_init+0x0/0x42d @ 1 [1.035947] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 [1.035948] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp [1.036589] serio: i8042 KBD port at 0x60,0x64 irq 1 [1.036621] initcall i8042_init+0x0/0x42d returned 0 after 687 usecs But, the DSDT includes the “mouse device”. From acpidump > dump.bin; acpixtract dump.bin; iasl -d *dat; more dsdt.dsl we get Device (PS2M) { Name (_HID, EisaId ("PNP0F03") /* Microsoft PS/2-style Mouse */) // _HID: Hardware ID Name (_CID, EisaId ("PNP0F13") /* PS/2 Mouse */) // _CID: Compatible ID Method (_STA, 0, NotSerialized) // _STA: Status { If ((IOST & 0x4000)) { Return (0x0F) } Else { Return (Zero) } } and the identifiers PNP0F03 and PNP0F13 are both listed in the array `pnp_aux_devids[]`. But adding print statements to `i8042_pnp_aux_probe()`, I do not see them, so the function does not seem to be called. My guess is that _STA returns 0 indicating that the device is not present. I would try tracking where IOST is being set and figuring out why it does not have mouse bit enabled. Does the ACPI subsystem allow to track, how ACPI variables(?) like IOST are read and set? My guess would be that IOST is a field in an operation region which would indicate that it is initialized by the bootstrap part of the BIOS. Thank you for your answer. But how can I verify that? Is there a Linux kernel parameter, that would print it? Kind regards, Paul
Re: i8042_init: PS/2 mouse not detected with ACPIPnP/PnPBIOS
Dear Dmitry, dear Rafael, dear Len, Am 08.10.20 um 00:16 schrieb Dmitry Torokhov: On Wed, Oct 07, 2020 at 11:18:41PM +0200, Paul Menzel wrote: On the Asus F2A85-M PRO Linux 5.9-rc8 (and previous versions) does not recognize a plugged in PS/2 mouse using the Plug & Play method. The PS/2 keyboard is detected fine, and using `i8042.nopnp`, the PS/2 mouse also works. [1.035915] calling i8042_init+0x0/0x42d @ 1 [1.035947] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 [1.035948] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp [1.036589] serio: i8042 KBD port at 0x60,0x64 irq 1 [1.036621] initcall i8042_init+0x0/0x42d returned 0 after 687 usecs But, the DSDT includes the “mouse device”. From acpidump > dump.bin; acpixtract dump.bin; iasl -d *dat; more dsdt.dsl we get Device (PS2M) { Name (_HID, EisaId ("PNP0F03") /* Microsoft PS/2-style Mouse */) // _HID: Hardware ID Name (_CID, EisaId ("PNP0F13") /* PS/2 Mouse */) // _CID: Compatible ID Method (_STA, 0, NotSerialized) // _STA: Status { If ((IOST & 0x4000)) { Return (0x0F) } Else { Return (Zero) } } and the identifiers PNP0F03 and PNP0F13 are both listed in the array `pnp_aux_devids[]`. But adding print statements to `i8042_pnp_aux_probe()`, I do not see them, so the function does not seem to be called. My guess is that _STA returns 0 indicating that the device is not present. I would try tracking where IOST is being set and figuring out why it does not have mouse bit enabled. Does the ACPI subsystem allow to track, how ACPI variables(?) like IOST are read and set? Kind regards, Paul
i8042_init: PS/2 mouse not detected with ACPIPnP/PnPBIOS
Dear Linux folks, On the Asus F2A85-M PRO Linux 5.9-rc8 (and previous versions) does not recognize a plugged in PS/2 mouse using the Plug & Play method. The PS/2 keyboard is detected fine, and using `i8042.nopnp`, the PS/2 mouse also works. [1.035915] calling i8042_init+0x0/0x42d @ 1 [1.035947] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 [1.035948] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp [1.036589] serio: i8042 KBD port at 0x60,0x64 irq 1 [1.036621] initcall i8042_init+0x0/0x42d returned 0 after 687 usecs But, the DSDT includes the “mouse device”. From acpidump > dump.bin; acpixtract dump.bin; iasl -d *dat; more dsdt.dsl we get Device (PS2M) { Name (_HID, EisaId ("PNP0F03") /* Microsoft PS/2-style Mouse */) // _HID: Hardware ID Name (_CID, EisaId ("PNP0F13") /* PS/2 Mouse */) // _CID: Compatible ID Method (_STA, 0, NotSerialized) // _STA: Status { If ((IOST & 0x4000)) { Return (0x0F) } Else { Return (Zero) } } and the identifiers PNP0F03 and PNP0F13 are both listed in the array `pnp_aux_devids[]`. But adding print statements to `i8042_pnp_aux_probe()`, I do not see them, so the function does not seem to be called. Hints for further debugging are much appreciated. Kind regards, Paul
Re: [Intel-wired-lan] [PATCH] e1000: do not panic on malformed rx_desc
Dear Tong, Am 01.10.20 um 09:03 schrieb Paul Menzel: Am 08.09.20 um 18:22 schrieb Tong Zhang: length may be corrupted in rx_desc How can that be? and lead to panic, so check the sanity before passing it to skb_put [ 167.667701] skbuff: skb_over_panic: text:b1e32cc1 len:60224 put:60224 head:888055ac5000 data:888055ac5040 tail:0xeb80 end:0x6c0 dev:eth0 [ 167.668429] [ cut here ] [ 167.668661] kernel BUG at net/core/skbuff.c:109! [ 167.668910] invalid opcode: [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 167.669220] CPU: 1 PID: 170 Comm: sd-resolve Tainted: G W 5.8.0+ #1 [ 167.670161] RIP: 0010:skb_panic+0xc4/0xc6 [ 167.670363] Code: 89 f0 48 c7 c7 60 f2 de b2 55 48 8b 74 24 18 4d 89 f9 56 48 8b 54 24 18 4c 89 e6 52 48 8b 44 24 18 4c 89 ea 50 e8 31 c5 2a ff <0f> 0b 4c 8b 64 24 18 e8 f1 b4 48 ff 48 c7 c1 00 fc de b2 44 89 ee [ 167.671272] RSP: 0018:88806d109c68 EFLAGS: 00010286 [ 167.671527] RAX: 008c RBX: 888065e9af40 RCX: [ 167.671878] RDX: 11100da24c91 RSI: 0008 RDI: ed100da21380 [ 167.672227] RBP: 88806bde4000 R08: 008c R09: ed100da25cfb [ 167.672583] R10: 88806d12e7d7 R11: ed100da25cfa R12: b2defc40 [ 167.672931] R13: b1e32cc1 R14: eb40 R15: 888055ac5000 [ 167.673286] FS: 7fc5f5375700() GS:88806d10() knlGS: [ 167.673681] CS: 0010 DS: ES: CR0: 80050033 [ 167.673973] CR2: 00cb3008 CR3: 63d36000 CR4: 06e0 [ 167.674330] DR0: DR1: DR2: [ 167.674677] DR3: DR6: fffe0ff0 DR7: 0400 [ 167.675035] Call Trace: [ 167.675168] [ 167.675315] ? e1000_clean_rx_irq+0x311/0x630 [ 167.687459] skb_put.cold+0x1f/0x1f [ 167.687637] e1000_clean_rx_irq+0x311/0x630 [ 167.687852] e1000e_poll+0x19a/0x4d0 [ 167.688038] ? e1000_watchdog_task+0x9d0/0x9d0 [ 167.688262] ? credit_entropy_bits.constprop.0+0x6f/0x1c0 [ 167.688527] net_rx_action+0x26e/0x650 On what device did you test this? Signed-off-by: Tong Zhang --- drivers/net/ethernet/intel/e1000/e1000_main.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c index 1e6ec081fd9d..29e2ecb0358a 100644 --- a/drivers/net/ethernet/intel/e1000/e1000_main.c +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c @@ -4441,8 +4441,13 @@ static bool e1000_clean_rx_irq(struct e1000_adapter *adapter, */ length -= 4; - if (buffer_info->rxbuf.data == NULL) + if (buffer_info->rxbuf.data == NULL) { + /* check length sanity */ I’d remove the comment, and … + if (skb->tail + length > skb->end) { It’d be great, if you could use the same order as in the assignment. length > skb->end - skb->tail + length = skb->end - skb->tail; + } skb_put(skb, length); print a warning/an error here, as this seems to be a hardware issue. + } else /* copybreak skb */ skb_trim(skb, length); According to the coding style, the keyword `else` has to be on the same line as the `{`, and, the else branch also needs to be put in {}. Kind regards, Paul
Re: [Intel-wired-lan] [PATCH] e1000: do not panic on malformed rx_desc
Dear Tong, Thank you for your patch. Am 08.09.20 um 18:22 schrieb Tong Zhang: length may be corrupted in rx_desc How can that be? and lead to panic, so check the sanity before passing it to skb_put [ 167.667701] skbuff: skb_over_panic: text:b1e32cc1 len:60224 put:60224 head:888055ac5000 data:888055ac5040 tail:0xeb80 end:0x6c0 dev:e th0 [ 167.668429] [ cut here ] [ 167.668661] kernel BUG at net/core/skbuff.c:109! [ 167.668910] invalid opcode: [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 167.669220] CPU: 1 PID: 170 Comm: sd-resolve Tainted: GW 5.8.0+ #1 [ 167.670161] RIP: 0010:skb_panic+0xc4/0xc6 [ 167.670363] Code: 89 f0 48 c7 c7 60 f2 de b2 55 48 8b 74 24 18 4d 89 f9 56 48 8b 54 24 18 4c 89 e6 52 48 8b 44 24 18 4c 89 ea 50 e8 31 c5 2a ff <0f> 0b 4c 8b 64 24 18 e8 f1 b4 48 ff 48 c7 c1 00 fc de b2 44 89 ee [ 167.671272] RSP: 0018:88806d109c68 EFLAGS: 00010286 [ 167.671527] RAX: 008c RBX: 888065e9af40 RCX: [ 167.671878] RDX: 11100da24c91 RSI: 0008 RDI: ed100da21380 [ 167.672227] RBP: 88806bde4000 R08: 008c R09: ed100da25cfb [ 167.672583] R10: 88806d12e7d7 R11: ed100da25cfa R12: b2defc40 [ 167.672931] R13: b1e32cc1 R14: eb40 R15: 888055ac5000 [ 167.673286] FS: 7fc5f5375700() GS:88806d10() knlGS: [ 167.673681] CS: 0010 DS: ES: CR0: 80050033 [ 167.673973] CR2: 00cb3008 CR3: 63d36000 CR4: 06e0 [ 167.674330] DR0: DR1: DR2: [ 167.674677] DR3: DR6: fffe0ff0 DR7: 0400 [ 167.675035] Call Trace: [ 167.675168] [ 167.675315] ? e1000_clean_rx_irq+0x311/0x630 [ 167.687459] skb_put.cold+0x1f/0x1f [ 167.687637] e1000_clean_rx_irq+0x311/0x630 [ 167.687852] e1000e_poll+0x19a/0x4d0 [ 167.688038] ? e1000_watchdog_task+0x9d0/0x9d0 [ 167.688262] ? credit_entropy_bits.constprop.0+0x6f/0x1c0 [ 167.688527] net_rx_action+0x26e/0x650 On what device did you test this? Signed-off-by: Tong Zhang --- drivers/net/ethernet/intel/e1000/e1000_main.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c index 1e6ec081fd9d..29e2ecb0358a 100644 --- a/drivers/net/ethernet/intel/e1000/e1000_main.c +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c @@ -4441,8 +4441,13 @@ static bool e1000_clean_rx_irq(struct e1000_adapter *adapter, */ length -= 4; - if (buffer_info->rxbuf.data == NULL) + if (buffer_info->rxbuf.data == NULL) { + /* check length sanity */ + if (skb->tail + length > skb->end) { It’d be great, if you could use the same order as in the assignment. length > skb->end - skb->tail + length = skb->end - skb->tail; + } skb_put(skb, length); + } else /* copybreak skb */ skb_trim(skb, length); According to the coding style, the keyword `else` has to be on the same line as the `{`, and, the else branch also needs to be put in {}. Kind regards, Paul
Re: [Intel-wired-lan] [PATCH v3] e1000e: Increase iteration on polling MDIC ready bit
Dear Kai-Heng, Thank you for patch version 3. Am 24.09.20 um 18:45 schrieb Kai-Heng Feng: We are seeing the following error after S3 resume: [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020 [ 704.844232] e1000e :00:1f.6 eno1: MDI Write did not complete [ 704.902817] e1000e :00:1f.6 eno1: Setting page 0x6020 [ 704.903075] e1000e :00:1f.6 eno1: reading PHY page 769 (or 0x6020 shifted) reg 0x17 [ 704.903281] e1000e :00:1f.6 eno1: Setting page 0x6020 [ 704.903486] e1000e :00:1f.6 eno1: writing PHY page 769 (or 0x6020 shifted) reg 0x17 [ 704.943155] e1000e :00:1f.6 eno1: MDI Error ... [ 705.108161] e1000e :00:1f.6 eno1: Hardware Error As Andrew Lunn pointed out, MDIO has nothing to do with phy, and indeed increase polling iteration can resolve the issue. The root cause is quite likely Intel ME, since it's a blackbox to the kernel so the only approach we can take is to be patient and wait longer. Signed-off-by: Kai-Heng Feng --- v3: - Moving delay to end of loop doesn't save anytime, move it back. - Point out this is quitely likely caused by Intel ME. quietly You seem to have missed my comments regarding patch version 3. It’d be great if you improved the commit message with my suggestions. Without knowing what hardware this happened on, nobody, even later getting the hardware, can reproduce the your results. If you say the ME is involved, please also document the ME firmware version, which is used here. v2: - Increase polling iteration instead of powering down the phy. drivers/net/ethernet/intel/e1000e/phy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/e1000e/phy.c b/drivers/net/ethernet/intel/e1000e/phy.c index e11c877595fb..e6d4acd90937 100644 --- a/drivers/net/ethernet/intel/e1000e/phy.c +++ b/drivers/net/ethernet/intel/e1000e/phy.c @@ -203,7 +203,7 @@ s32 e1000e_write_phy_reg_mdic(struct e1000_hw *hw, u32 offset, u16 data) * Increasing the time out as testing showed failures with * the lower time out */ - for (i = 0; i < (E1000_GEN_POLL_TIMEOUT * 3); i++) { + for (i = 0; i < (E1000_GEN_POLL_TIMEOUT * 10); i++) { udelay(50); mdic = er32(MDIC); if (mdic & E1000_MDIC_READY) In the PCI subsystem, a warning is shown, when something takes more then 100 ms. As you increase it to over 320 ms, a warning should be printed to talk to the firmware folks, when it passes 100 ms. Kind regards, Paul
Re: [Intel-wired-lan] [PATCH v2] e1000e: Increase iteration on polling MDIC ready bit
Dear Kai-Heng, Thank you for sending version 2. Am 24.09.20 um 17:09 schrieb Kai-Heng Feng: We are seeing the following error after S3 resume: I’d be great if you added the system and used hardware, you are seeing this with. [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020 [ 704.844232] e1000e :00:1f.6 eno1: MDI Write did not complete A follow-up patch, should extend the message to include the timeout value. > MDI Write did not complete did not complete in … seconds. According to the Linux timestamps it’s 98 ms, which makes sense, as (640 * 3 * 50 μs = 96 ms). What crappy hardware is this, that it takes longer than 100 ms? [ 704.902817] e1000e :00:1f.6 eno1: Setting page 0x6020 [ 704.903075] e1000e :00:1f.6 eno1: reading PHY page 769 (or 0x6020 shifted) reg 0x17 [ 704.903281] e1000e :00:1f.6 eno1: Setting page 0x6020 [ 704.903486] e1000e :00:1f.6 eno1: writing PHY page 769 (or 0x6020 shifted) reg 0x17 [ 704.943155] e1000e :00:1f.6 eno1: MDI Error ... [ 705.108161] e1000e :00:1f.6 eno1: Hardware Error As Andrew Lunn pointed out, MDIO has nothing to do with phy, and indeed increase polling iteration can resolve the issue. Please explicitly state, what the current timeout value is, and what it is increased to. 640 * 3 * 50 μs = 96 ms 640 * 10 * 50 μs = 320 ms The macro definition also misses the unit. /* SerDes Control */ #define E1000_GEN_POLL_TIMEOUT 640 How did you determine, that tenfold that value is good. And not eightfold, for example? Please give the exact value (Linux log message timestamps should be enough), what the hardware needs now. As a commit message summary, I suggest: > e1000e: Increase MDIC ready bit polling timeout from 96 ms to 320 ms While at it, also move the delay to the end of loop, to potentially save 50 us. Signed-off-by: Kai-Heng Feng --- v2: - Increase polling iteration instead of powering down the phy. drivers/net/ethernet/intel/e1000e/phy.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/e1000e/phy.c b/drivers/net/ethernet/intel/e1000e/phy.c index e11c877595fb..72968a01164b 100644 --- a/drivers/net/ethernet/intel/e1000e/phy.c +++ b/drivers/net/ethernet/intel/e1000e/phy.c @@ -203,11 +203,12 @@ s32 e1000e_write_phy_reg_mdic(struct e1000_hw *hw, u32 offset, u16 data) * Increasing the time out as testing showed failures with * the lower time out */ - for (i = 0; i < (E1000_GEN_POLL_TIMEOUT * 3); i++) { - udelay(50); + for (i = 0; i < (E1000_GEN_POLL_TIMEOUT * 10); i++) { mdic = er32(MDIC); if (mdic & E1000_MDIC_READY) break; + + udelay(50); } if (!(mdic & E1000_MDIC_READY)) { e_dbg("MDI Write did not complete\n");
Re: [Intel-wired-lan] [PATCH] e1000e: Power cycle phy on PM resume
Dear Andrew, Am 23.09.20 um 21:28 schrieb Andrew Lunn: How much does this increase the resume time? Define resume time? Until you get the display manager unlock screen? Or do you need working networking? Until network is functional again. Currently, the speed negotiation alone takes three(?) seconds, so making it even longer is unacceptable. (You wrote it below.) It takes around 1.5 seconds for auto negotiation to get a link. I know it takes me longer than that to move my fingers to the keyboard and type in my password to unlock the screen. So by the time you actually get to see your desktop, you should have link. Not here. I've no idea about how the e1000e driver does link negotiation. But powering the PHY off means there is going to be a negotiation sometime later. But if you don't turn it off, the driver might be able to avoid doing an autoneg if the PHY has already done one when it got powered up. Indeed. Kind regards, Paul
Re: [Intel-wired-lan] [PATCH] e1000e: Power cycle phy on PM resume
Dear Kai-Heng, Am 23.09.20 um 16:46 schrieb Kai-Heng Feng: On Sep 23, 2020, at 21:28, Paul Menzel wrote: Am 23.09.20 um 09:47 schrieb Kai-Heng Feng: We are seeing the following error after S3 resume: [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020 [ 704.844232] e1000e :00:1f.6 eno1: MDI Write did not complete [ 704.902817] e1000e :00:1f.6 eno1: Setting page 0x6020 [ 704.903075] e1000e :00:1f.6 eno1: reading PHY page 769 (or 0x6020 shifted) reg 0x17 [ 704.903281] e1000e :00:1f.6 eno1: Setting page 0x6020 [ 704.903486] e1000e :00:1f.6 eno1: writing PHY page 769 (or 0x6020 shifted) reg 0x17 [ 704.943155] e1000e :00:1f.6 eno1: MDI Error ... [ 705.108161] e1000e :00:1f.6 eno1: Hardware Error Since we don't know what platform firmware may do to the phy, so let's power cycle the phy upon system resume to resolve the issue. Is there a bug report or list thread for this issue? No. That's why I sent a patch to start discussion :) Then please add on what systems that is. Signed-off-by: Kai-Heng Feng --- drivers/net/ethernet/intel/e1000e/netdev.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index 664e8ccc88d2..c2a87a408102 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -6968,6 +6968,8 @@ static __maybe_unused int e1000e_pm_resume(struct device *dev) !e1000e_check_me(hw->adapter->pdev->device)) e1000e_s0ix_exit_flow(adapter); + e1000_power_down_phy(adapter); + rc = __e1000_resume(pdev); if (rc) return rc; How much does this increase the resume time? I didn't measure it. Because for me it's more important to have a working device. Does it have a noticeable impact on your system's resume time? I am not able to test the patch right now. But resume time is important to me. As I do not have the problem, nothing should be changed for my system (Dell Latitude E7250). 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection (3) I218-LM [8086:15a2] (rev 03) Kind regards, Paul
Re: [Intel-wired-lan] [PATCH] e1000e: Power cycle phy on PM resume
Dear Kai-Heng, Am 23.09.20 um 09:47 schrieb Kai-Heng Feng: We are seeing the following error after S3 resume: [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020 [ 704.844232] e1000e :00:1f.6 eno1: MDI Write did not complete [ 704.902817] e1000e :00:1f.6 eno1: Setting page 0x6020 [ 704.903075] e1000e :00:1f.6 eno1: reading PHY page 769 (or 0x6020 shifted) reg 0x17 [ 704.903281] e1000e :00:1f.6 eno1: Setting page 0x6020 [ 704.903486] e1000e :00:1f.6 eno1: writing PHY page 769 (or 0x6020 shifted) reg 0x17 [ 704.943155] e1000e :00:1f.6 eno1: MDI Error ... [ 705.108161] e1000e :00:1f.6 eno1: Hardware Error Since we don't know what platform firmware may do to the phy, so let's power cycle the phy upon system resume to resolve the issue. Is there a bug report or list thread for this issue? Signed-off-by: Kai-Heng Feng --- drivers/net/ethernet/intel/e1000e/netdev.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index 664e8ccc88d2..c2a87a408102 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -6968,6 +6968,8 @@ static __maybe_unused int e1000e_pm_resume(struct device *dev) !e1000e_check_me(hw->adapter->pdev->device)) e1000e_s0ix_exit_flow(adapter); + e1000_power_down_phy(adapter); + rc = __e1000_resume(pdev); if (rc) return rc; How much does this increase the resume time? Kind regards, Paul
General protection fault: RIP: 0010:free_block+0xdc/0x1f0
Dear Andrew folks, dear Linux folks, With Linux 5.9-rc4 on a Dell OptiPlex 5080 with Intel Core i7-10700 CPU @ 2.90GHz, and external 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 OEM] [1002:6611] (rev 87) running graphical demanding applications glmark2 [1] and the Phoronix Test Suite [2] benchmark *pts/desktop-graphics* [3] $ git describe --tags v10.0.0m1-13-g0b5ddc3c0 I got three general protection faults, and it restarted or froze (no input devices working, screen froze and even network card (no ping)). Here the system restarted itself: kernel: general protection fault, probably for non-canonical address 0xdead0100: [#1] SMP NOPTI kernel: CPU: 2 PID: 9702 Comm: glmark2 Kdump: loaded Not tainted 5.9.0-rc4.mx64.343 #1 kernel: Hardware name: Dell Inc. OptiPlex 5080/032W55, BIOS 1.1.7 08/17/2020 kernel: RIP: 0010:free_block+0xdc/0x1f0 Here it froze: [14639.665745] general protection fault, probably for non-canonical address 0xdead0100: [#1] SMP NOPTI [14639.675917] CPU: 15 PID: 23094 Comm: pvpython Kdump: loaded Not tainted 5.9.0-rc4.mx64.343 #1 [14639.684431] Hardware name: Dell Inc. OptiPlex 5080/032W55, BIOS 1.1.7 08/17/2020 [14639.691823] RIP: 0010:free_block+0xdc/0x1f0 Here it froze: kernel: general protection fault, probably for non-canonical address 0xdead0100: [#1] SMP NOPTI kernel: CPU: 15 PID: 23094 Comm: pvpython Kdump: loaded Not tainted 5.9.0-rc4.mx64.343 #1 kernel: Hardware name: Dell Inc. OptiPlex 5080/032W55, BIOS 1.1.7 08/17/2020 kernel: RIP: 0010:free_block+0xdc/0x1f0 Running `scripts/decode_stacktrace.sh`: linux-5.9_rc4-343.x86_64/source$ scripts/decode_stacktrace.sh vmlinux < optiplex-5080-linux-5.9-rc4-gp-pvpython.txt [14528.718656] cgroup: fork rejected by pids controller in /user.slice/user-5272.slice/session-c6.scope [14639.665745] general protection fault, probably for non-canonical address 0xdead0100: [#1] SMP NOPTI [14639.675917] CPU: 15 PID: 23094 Comm: pvpython Kdump: loaded Not tainted 5.9.0-rc4.mx64.343 #1 [14639.684431] Hardware name: Dell Inc. OptiPlex 5080/032W55, BIOS 1.1.7 08/17/2020 [14639.691823] RIP: 0010:free_block (./include/linux/list.h:112 ./include/linux/list.h:135 ./include/linux/list.h:146 mm/slab.c:3336) [14639.696006] Code: 00 48 01 d0 48 c1 e8 0c 48 c1 e0 06 4c 01 e8 48 8b 50 08 48 8d 4a ff 83 e2 01 48 0f 45 c1 48 8b 48 08 48 8b 50 10 4c 8d 78 08 <48> 89 51 08 48 89 0a 4c 89 da 48 2b 50 28 4c 89 60 08 48 89 68 10 All code 0: 00 48 01add%cl,0x1(%rax) 3: d0 48 c1rorb -0x3f(%rax) 6: e8 0c 48 c1 e0 callq 0xe0c14817 b: 06 (bad) c: 4c 01 e8 add%r13,%rax f: 48 8b 50 08 mov0x8(%rax),%rdx 13: 48 8d 4a ff lea-0x1(%rdx),%rcx 17: 83 e2 01and$0x1,%edx 1a: 48 0f 45 c1 cmovne %rcx,%rax 1e: 48 8b 48 08 mov0x8(%rax),%rcx 22: 48 8b 50 10 mov0x10(%rax),%rdx 26: 4c 8d 78 08 lea0x8(%rax),%r15 2a:* 48 89 51 08 mov%rdx,0x8(%rcx) <-- trapping instruction 2e: 48 89 0amov%rcx,(%rdx) 31: 4c 89 damov%r11,%rdx 34: 48 2b 50 28 sub0x28(%rax),%rdx 38: 4c 89 60 08 mov%r12,0x8(%rax) 3c: 48 89 68 10 mov%rbp,0x10(%rax) Code starting with the faulting instruction === 0: 48 89 51 08 mov%rdx,0x8(%rcx) 4: 48 89 0amov%rcx,(%rdx) 7: 4c 89 damov%r11,%rdx a: 48 2b 50 28 sub0x28(%rax),%rdx e: 4c 89 60 08 mov%r12,0x8(%rax) 12: 48 89 68 10 mov%rbp,0x10(%rax) [14639.714747] RSP: 0018:c9001c26fab8 EFLAGS: 00010046 [14639.719970] RAX: ea000d193600 RBX: 8000 RCX: dead0100 [14639.727099] RDX: dead0122 RSI: 88842d5f3ef0 RDI: 88842b440300 [14639.734225] RBP: dead0122 R08: c9001c26fb30 R09: 88842b441280 [14639.741351] R10: 000f R11: 8883464d80c0 R12: dead0100 [14639.748477] R13: ea00 R14: 88842d5f3ff0 R15: ea000d193608 [14639.755604] FS: 7fd3b7e8f040() GS:88842d5c() knlGS: [14639.763692] CS: 0010 DS: ES: CR0: 80050033 [14639.769430] CR2: 7fd344233548 CR3: 0002f46aa003 CR4: 007706e0 [14639.776556] PKRU: 5554 [14639.779265] Call Trace: [14639.781717] ___cache_free (mm/slab.c:3389 mm/slab.c:3455) [14639.785463] kfree (./arch/x86/include/asm/irqflags.h:41 ./arch/x86/include/asm/irqflags.h:84 mm/slab.c:3757) [14639.788432] kmem_freepages (mm/slab.h:266 mm/slab.h:437 mm/slab.c:1406) [14639.792093]
Warnings about filesystem timestamp support until 2038
Dear Deepa, Commit v5.3-rc6-4-gf8b92ba67c5d3 (mount: Add mount warning for impending timestamp expiry) [1] results in a lot of warnings on our systems. xfs filesystem being mounted at /amd/salvadorthegunzerker/0 supports timestamps until 2038 (0x7fff) Unfortunately, I am missing the motivation for adding the warning in the commit message. Why is it warned about and what should users do about it? In our case, what should XFS and ext4 filesystem users do? Kind regards, Paul [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f8b92ba67c5d3a9e9468320078a97d950a3e748b
Re: Issue with iwd + Linux 5.8.3 + WPA Enterprise
Dear Caleb, Thank you for the report. Linux has a no regression policy, so the correct forum to report this to is the Linux kernel folks. I am adding the crypto and stable folks to the receiver list. Am 26.08.20 um 07:51 schrieb caljor...@hotmail.com: I wanted to note an issue that I have hit with iwd when I upgraded to the Linux 5.8.3 stable kernel. My office network uses WPA Enterprise with EAP-PEAPv0 + MSCHAPv2. When using this office network, upgrading to Linux 5.8.3 caused my system to refuse to associate successfully to the network. I get the following in my dmesg logs: [ 40.846535] wlan0: authenticate with :60 [ 40.850570] wlan0: send auth to :60 (try 1/3) [ 40.854627] wlan0: authenticated [ 40.855992] wlan0: associate with :60 (try 1/3) [ 40.860450] wlan0: RX AssocResp from :60 (capab=0x411 status=0 aid=11) [ 40.861620] wlan0: associated [ 41.886503] wlan0: deauthenticating from :60 by local choice (Reason: 23=IEEE8021X_FAILED) [ 42.360127] wlan0: authenticate with :22 [ 42.364584] wlan0: send auth to :22 (try 1/3) [ 42.370821] wlan0: authenticated [ 42.372658] wlan0: associate with :22 (try 1/3) [ 42.377426] wlan0: RX AssocResp from :22 (capab=0x411 status=0 aid=15) [ 42.378607] wlan0: associated [ 43.402009] wlan0: deauthenticating from :22 by local choice (Reason: 23=IEEE8021X_FAILED) [ 43.875921] wlan0: authenticate with :60 [ 43.879988] wlan0: send auth to :60 (try 1/3) [ 43.886244] wlan0: authenticated [ 43.889273] wlan0: associate with :60 (try 1/3) [ 43.894586] wlan0: RX AssocResp from :60 (capab=0x411 status=0 aid=11) [ 43.896077] wlan0: associated [ 44.918504] wlan0: deauthenticating from :60 by local choice (Reason: 23=IEEE8021X_FAILED) This continues as long as I let iwd run. I downgraded back to Linux 5.8.2, and verified that everything works as expected. I also tried using Linux 5.8.3 on a different system at my home, which uses WPA2-PSK. It worked fine (though it uses an Atheros wireless card instead of an Intel card - but I assume that is irrelevant). I decided to try to figure out what caused the issue in the changes for Linux 5.8.3. I assumed that it was something that changed in the crypto interface, which limited my bisection to a very few commits. Sure enough, I found that if I revert commit e91d82703ad0bc68942a7d91c1c3d993e3ad87f0 (crypto: algif_aead - Only wake up when ctx->more is zero), the problem goes away and I am able to associate to my WPA Enterprise network successfully, and use it. I found that in order to revert this commit, I also first had to revert 465c03e999102bddac9b1e132266c232c5456440 (crypto: af_alg - Fix regression on empty requests), because the two commits have coupled changes. I normally would have assumed that this should be sent to the kernel list, but I thought I would first mention it here because of what I found in some email threads on the Linux-Crypto list about the crypto interfaces to the kernel being sub-optimal and needing to be fixed. The changes in these commits look like they are just trying to fix what could be broken interfaces, so I thought that it would make sense to see what the iwd team thinks about the situation first. The wireless card I was using during this testing is an Intel Wireless 3165 (rev 81). If there is any additional information I could help provide, please let me know. It’d be great, if you verified, if the problem occurs with Linus’ master branch too. Kind regards, Paul
[PATCH v2 2/2] init/Kconfig: Increase default log buffer size from 128 KB to 512 KB
Commit f17a32e97e (let LOG_BUF_SHIFT default to 17) from 2008 was the last time, the the default log buffer size bump was increased. Machines have evolved, and on current hardware, enough memory is present, and some devices have over 200 PCI devices, like a two socket Skylake-E server, resulting a lot of lines. Therefore, increase the default from 128 KB to 512 KB. Anyone, with limited memory, can still lower it. Signed-off-by: Paul Menzel Cc: linux-kernel@vger.kernel.org --- v2: New patch in series. Is sending it to linux-kernel enough? If not, who to send it also to? init/Kconfig | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 9dc607e3806f..13df63517cc2 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -681,9 +681,9 @@ config IKHEADERS kheaders.ko is built which can be loaded on-demand to get access to headers. config LOG_BUF_SHIFT - int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" + int "Kernel log buffer size (17 => 128KB, 19 => 512KB)" range 12 25 - default 17 + default 19 depends on PRINTK help Select the minimal kernel log buffer size as a power of 2. @@ -692,6 +692,8 @@ config LOG_BUF_SHIFT by "log_buf_len" boot parameter. Examples: +19 => 512 KB +18 => 256 KB 17 => 128 KB 16 => 64 KB 15 => 32 KB @@ -718,7 +720,7 @@ config LOG_CPU_MAX_BUF_SHIFT with more CPUs. Therefore this value is used only when the sum of contributions is greater than the half of the default kernel ring buffer as defined by LOG_BUF_SHIFT. The default values are set - so that more than 16 CPUs are needed to trigger the allocation. + so that more than 64 CPUs are needed to trigger the allocation. Also this option is ignored when "log_buf_len" kernel parameter is used as it forces an exact (power of two) size of the ring buffer. -- 2.28.0
[PATCH v2 1/2] init/Kconfig: Fix CPU number in LOG_CPU_MAX_BUF_SHIFT description
Currently, LOG_BUF_SHIFT defaults to 17, which is 2 ^ 17 bytes = 128 KB, and LOG_CPU_MAX_BUF_SHIFT defaults to 12, which is 2 ^ 12 bytes = 4 KB. Half of 128 KB is 64 KB, so more than 16 CPUs are required for the value to be used, as then the sum of contributions is greater than 64 KB for the first time. My guess is, that the description was written with the configuration values used in the SUSE in mind. Fixes: 23b2899f7f ("printk: allow increasing the ring buffer depending on the number of CPUs") Cc: Luis R. Rodriguez Cc: linux-kernel@vger.kernel.org Reviewed-by: Petr Mladek Signed-off-by: Paul Menzel --- v2: Add Reviewed-by tag init/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/Kconfig b/init/Kconfig index d6a0b31b13dc..9dc607e3806f 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -718,7 +718,7 @@ config LOG_CPU_MAX_BUF_SHIFT with more CPUs. Therefore this value is used only when the sum of contributions is greater than the half of the default kernel ring buffer as defined by LOG_BUF_SHIFT. The default values are set - so that more than 64 CPUs are needed to trigger the allocation. + so that more than 16 CPUs are needed to trigger the allocation. Also this option is ignored when "log_buf_len" kernel parameter is used as it forces an exact (power of two) size of the ring buffer. -- 2.28.0
Re: Start messages in message buffer missing (dmesg)
Dear Linux folks, Am 11.08.20 um 00:13 schrieb Paul Menzel: Am 21.07.20 um 17:20 schrieb Paul Menzel: On two identical Dell PowerEdge T440 with Linux 5.4.39 and systemd 242 00:00.0 Host bridge [0600]: Intel Corporation Sky Lake-E DMI3 Registers [8086:2020] (rev 07) running `dmesg`, it’s truncated despite the buffer not yet filled. $ sudo dmidecode -t2 # dmidecode 3.0 Getting SMBIOS data from sysfs. SMBIOS 3.2 present. # SMBIOS implementations newer than version 3.0 are not # fully supported by this version of dmidecode. Handle 0x0200, DMI type 2, 8 bytes Base Board Information Manufacturer: Dell Inc. Product Name: 02KM69 Version: A04 The message cutoffs differ. @sang:~$ dmesg | head [ 6.362201] system 00:01: [mem 0xfed12010-0xfed1201f] has been reserved [ 6.369102] system 00:01: [mem 0xfed1b000-0xfed1bfff] has been reserved [ 6.376003] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active) [ 6.376176] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) [ 6.376319] pnp 00:03: Plug and Play ACPI device, IDs PNP0501 (active) [ 6.376451] system 00:04: [mem 0xfd00-0xfdab] has been reserved [ 6.383352] system 00:04: [mem 0xfdad-0xfdad] has been reserved [ 6.390251] system 00:04: [mem 0xfdb0-0xfdff] has been reserved [ 6.397149] system 00:04: [mem 0xfe00-0xfe00] has been reserved [ 6.404049] system 00:04: [mem 0xfe011000-0xfe01] has been reserved @mouches:~$ dmesg | head [ 6.623209] pci :00:1c.4: PCI bridge to [bus 02-03] [ 6.628723] pci :00:1c.4: bridge window [mem 0x9200-0x928f] [ 6.635795] pci :00:1c.4: bridge window [mem 0x9100-0x91ff 64bit pref] [ 6.644046] pci :04:00.0: BAR 6: assigned [mem 0x9000-0x9003 pref] [ 6.651772] pci :04:00.1: BAR 6: assigned [mem 0x9004-0x9007 pref] [ 6.659494] pci :00:1c.5: PCI bridge to [bus 04] [ 6.664752] pci :00:1c.5: bridge window [mem 0x9000-0x900f] [ 6.671834] pci :00:1c.5: bridge window [mem 0x92e0-0x92ef 64bit pref] [ 6.680085] pci_bus :00: resource 4 [io 0x-0x0cf7 window] [ 6.686566] pci_bus :00: resource 5 [io 0x1000-0x3fff window] @sang:~$ head /dev/kmsg 6,862,6362201,-;system 00:01: [mem 0xfed12010-0xfed1201f] has been reserved SUBSYSTEM=pnp DEVICE=+pnp:00:01 6,863,6369102,-;system 00:01: [mem 0xfed1b000-0xfed1bfff] has been reserved SUBSYSTEM=pnp DEVICE=+pnp:00:01 7,864,6376003,-;system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active) SUBSYSTEM=pnp DEVICE=+pnp:00:01 7,865,6376176,-;pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) @sang:~$ cp /dev/kmsg /dev/shm/kmsg ^C @sang:~$ ls -lh /dev/shm/kmsg -rw-r- 1 pmenzel pmenzel 135K Jul 21 13:53 /dev/shm/kmsg So, the size is smaller than 128 KB + 16 * 4 KB = 192 KB. The systemd journal contains some earlier messages. This seems incorrect. See below. @sang:~$ sudo journalctl -k | head -- Logs begin at Wed 2020-06-03 14:31:56 CEST, end at Tue 2020-07-21 13:54:38 CEST. -- Jul 16 18:08:59 sang.molgen.mpg.de kernel: Normal zone: 315392 pages used for memmap Jul 16 18:08:59 sang.molgen.mpg.de kernel: Normal zone: 20185088 pages, LIFO batch:63 Jul 16 18:08:59 sang.molgen.mpg.de kernel: Initmem setup node 1 [mem 0x00144000-0x00203fff] Jul 16 18:08:59 sang.molgen.mpg.de kernel: On node 1 totalpages: 12582912 Jul 16 18:08:59 sang.molgen.mpg.de kernel: Normal zone: 196608 pages used for memmap Jul 16 18:08:59 sang.molgen.mpg.de kernel: Normal zone: 12582912 pages, LIFO batch:63 Jul 16 18:08:59 sang.molgen.mpg.de kernel: ACPI: PM-Timer IO Port: 0x508 Jul 16 18:08:59 sang.molgen.mpg.de kernel: ACPI: Local APIC address 0xfee0 Jul 16 18:08:59 sang.molgen.mpg.de kernel: ACPI: X2APIC_NMI (uid[0x] high level lint[0x1]) @sang:~$ sudo journalctl -k > /dev/shm/journalctl-k.txt @sang:~$ ls -lh /dev/shm/journalctl-k.txt -rw-rw 1 pmenzel pmenzel 191K Jul 21 13:55 /dev/shm/journalctl-k.txt The systemd journal output starts at the same position on both systems. But now, trying to get the full log over serial console, the full log is now present too on one system, when running `dmesg`. Detaching the serial console, the behavior stays the same, that means all messages are there. I am confused, how this could have fixed anything. Is somebody interested into looking into this, or should a just fix the affected system by plugging in a serial cable too? It turns out, that the issue with the serial console seems to have been an exception or maybe a testing error. The issue still happens with current Linux master v5.8-11935-g8d3e09b43312 and the attached debug patch on top. But first, from `init/Kconfig`: The increased size means that a new buffer has to be allocated and the original static one is unused. It makes sense only on systems with more CPUs. Therefore this va
[PATCH] init/Kconfig: Fix CPU number in LOG_CPU_MAX_BUF_SHIFT description
Currently, LOG_BUF_SHIFT defaults to 17, which is 2 ^ 17 bytes = 128 KB, and LOG_CPU_MAX_BUF_SHIFT defaults to 12, which is 2 ^ 12 bytes = 4 KB. Half of 128 KB is 64 KB, so more than 16 CPUs are required for the value to be used, as then the sum of contributions is greater than 64 KB for the first time. My guess is, that the description was written with the configuration values used in the SUSE in mind. Cc: Luis R. Rodriguez Cc: linux-kernel@vger.kernel.org Fixes: 23b2899f7f ("printk: allow increasing the ring buffer depending on the number of CPUs") Signed-off-by: Paul Menzel --- init/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/Kconfig b/init/Kconfig index d6a0b31b13dc..9dc607e3806f 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -718,7 +718,7 @@ config LOG_CPU_MAX_BUF_SHIFT with more CPUs. Therefore this value is used only when the sum of contributions is greater than the half of the default kernel ring buffer as defined by LOG_BUF_SHIFT. The default values are set - so that more than 64 CPUs are needed to trigger the allocation. + so that more than 16 CPUs are needed to trigger the allocation. Also this option is ignored when "log_buf_len" kernel parameter is used as it forces an exact (power of two) size of the ring buffer. -- 2.28.0
Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free
Dear Linux folks, Am 25.07.20 um 07:20 schrieb Mazin Rezk: On Saturday, July 25, 2020 12:59 AM, Duncan wrote: On Sat, 25 Jul 2020 03:03:52 + Mazin Rezk wrote: Am 24.07.20 um 19:33 schrieb Kees Cook: There was a fix to disable the async path for this driver that worked around the bug too, yes? That seems like a safer and more focused change that doesn't revert the SLUB defense for all users, and would actually provide a complete, I think, workaround That said, I haven't seen the async disabling patch. If you could link to it, I'd be glad to test it out and perhaps we can use that instead. I'm confused. Not to put words in Kees' mouth; /I/ am confused (which admittedly could well be just because I make no claims to be a coder and am simply reading the bug and thread, but I'd appreciate some "unconfusing" anyway). My interpretation of the "async disabling" reference was that it was to comment #30 on the bug: https://bugzilla.kernel.org/show_bug.cgi?id=207383#c30 ... which (if I'm not confused on this point too) appears to be yours. There it was stated... I've also found that this bug exclusively occurs when commit_work is on the workqueue. After forcing drm_atomic_helper_commit to run all of the commits without adding to the workqueue and running the OS, the issue seems to have disappeared. Would not forcing all commits to run directly, without placing them on the workqueue, be "async disabling"? That's what I /thought/ he was referencing. Oh, I thought he was referring to a different patch. Kees, could I get your confirmation on this? The change I made actually affected all of the DRM code, although this could easily be changed to be specific to amdgpu. (By forcing blocking on amdgpu_dm's non-blocking commit code) That said, I'd still need to test further because I only did test it for a couple of hours then. Although it should work in theory. OTOH your base/context swap idea sounds like a possibly "less disturbance" workaround, if it works, and given the point in the commit cycle... (But if it's out Sunday it's likely too late to test and get it in now anyway; if it's another week, tho...) The base/context swap idea should make the use-after-free behave how it did in 5.6. Since the bug doesn't cause an issue in 5.6, it's less of a "less disturbance" workaround and more of a "no disturbance" workaround. Sorry for bothering, but is there now a solution, besides reverting the commits, to avoid freezes/crashes *without* performance regressions? Kind regards, Paul
Delays in PCI/ACPI initialization
Dear Linux folks, Trying to decrease the boot time on a Acer TravelMate 5735Z with Debian Sid/unstable and Linux 5.7.6, there are two delays of 100 ms. I created a separate issue for each of the delays. 1. [Bug 208703] PnP ACPI init has 100 ms delay until quirk message 2. [Bug 208705] New: 100 ms delay in PCI initialization But maybe they have the same cause, and are duplicates. It’d be great, if you took a look. Kind regards, Paul [1]: https://bugzilla.kernel.org/show_bug.cgi?id=208703 [2]: https://bugzilla.kernel.org/show_bug.cgi?id=208705
Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free
Dear Kees, Am 24.07.20 um 19:33 schrieb Kees Cook: On Fri, Jul 24, 2020 at 09:45:18AM +0200, Paul Menzel wrote: Am 24.07.20 um 00:32 schrieb Kees Cook: On Thu, Jul 23, 2020 at 09:10:15PM +, Mazin Rezk wrote: As Linux 5.8-rc7 is going to be released this Sunday, I wonder, if commit 3202fa62f ("slub: relocate freelist pointer to middle of object") should be reverted for now to fix the regression for the users according to Linux’ no regression policy. Once the AMDGPU/DRM driver issue is fixed, it can be reapplied. I know it’s not optimal, but as some testing is going to be involved for the fix, I’d argue it’s the best option for the users. Well, the SLUB defense was already released in v5.7, so I'm not sure it really helps for amdgpu_dm users seeing it there too. In my opinion, it would help, as the stable release could pick up the revert, ones it’s in Linus’ master branch. There was a fix to disable the async path for this driver that worked around the bug too, yes? That seems like a safer and more focused change that doesn't revert the SLUB defense for all users, and would actually provide a complete, I think, workaround whereas reverting the SLUB change means the race still exists. For example, it would be hit with slab poisoning, etc. I do not know. If there is such a fix, that would be great. But if you do not know, how should a normal user? ;-) Kind regards, Paul Kind regards, Paul
Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free
Dear Kees, Am 24.07.20 um 00:32 schrieb Kees Cook: On Thu, Jul 23, 2020 at 09:10:15PM +, Mazin Rezk wrote: When amdgpu_dm_atomic_commit_tail is running in the workqueue, drm_atomic_state_put will get called while amdgpu_dm_atomic_commit_tail is running, causing a race condition where state (and then dm_state) is sometimes freed while amdgpu_dm_atomic_commit_tail is running. This bug has occurred since 5.7-rc1 and is well documented among polaris11 users [1]. Prior to 5.7, this was not a noticeable issue since the freelist pointer was stored at the beginning of dm_state (base), which was unused. After changing the freelist pointer to be stored in the middle of the struct, the freelist pointer overwrote the context, causing dc_state to become garbage data and made the call to dm_enable_per_frame_crtc_master_sync dereference a freelist pointer. This patch fixes the aforementioned issue by calling drm_atomic_state_get in amdgpu_dm_atomic_commit before drm_atomic_helper_commit is called and drm_atomic_state_put after amdgpu_dm_atomic_commit_tail is complete. According to my testing on 5.8.0-rc6, this should fix bug 207383 on Bugzilla [1]. [1] https://bugzilla.kernel.org/show_bug.cgi?id=207383 Nice work tracking this down! Fixes: 3202fa62f ("slub: relocate freelist pointer to middle of object") I do, however, object to this Fixes tag. :) The flaw appears to have been with amdgpu_dm's reference tracking of "state" in the nonblocking case. (How this reference counting is supposed to work correctly, though, I'm not sure.) If I look at where the drm helper was split from being the default callback, it looks like this was what introduced the bug: da5c47f682ab ("drm/amd/display: Remove acrtc->stream") ? 3202fa62f certainly exposed it much more quickly, but there was a race even without 3202fa62f where something could have realloced the memory and written over it. I understand the Fixes tag mainly a help when backporting commits. As Linux 5.8-rc7 is going to be released this Sunday, I wonder, if commit 3202fa62f ("slub: relocate freelist pointer to middle of object") should be reverted for now to fix the regression for the users according to Linux’ no regression policy. Once the AMDGPU/DRM driver issue is fixed, it can be reapplied. I know it’s not optimal, but as some testing is going to be involved for the fix, I’d argue it’s the best option for the users. Kind regards, Paul
CPU pressure despite low load average
Dear Johannes, I am wondering, how PSI shows some CPU pressure (on average), while the load average, on a four thread system, shows a value well below four. $ grep -R . /proc/pressure/ /proc/pressure/io:some avg10=0.00 avg60=0.00 avg300=0.00 total=941766173 /proc/pressure/io:full avg10=0.00 avg60=0.00 avg300=0.00 total=818872877 /proc/pressure/cpu:some avg10=1.24 avg60=1.05 avg300=1.18 total=7522879562 /proc/pressure/memory:some avg10=0.00 avg60=0.00 avg300=0.00 total=62730674 /proc/pressure/memory:full avg10=0.00 avg60=0.00 avg300=0.00 total=37176371 $ uptime 15:50:39 up 8 days, 7:17, 1 user, load average: 0,90, 0,62, 0,60 Kind regards, Paul
`psi_avgs_work` shows up in PowerTOP
Dear Johannes, On the Dell Latitude E7250 with Debian Sid/unstable and Linux 5.6.7, running `powertop`, `psi_avgs_work` shows up there with 40 mW to 60 mW. The battery reports a discharge rate of 7.16 W The power consumed was 147 J The estimated remaining time is 1 hours, 31 minutes Summary: 795.2 wakeups/second, 0.0 GPU ops/seconds, 0.0 VFS ops/sec and 16.8% CPU use Power est. Usage Events/sCategory Description 2.62 W 5.5 ms/s 328.9Timer tick_sched_timer 817 mW 21.9 ms/s 99.9Process[PID 519673] firefox 521 mW 3.2 ms/s 65.1Process[PID 519710] firefox 270 mW 1.9 ms/s 33.8Timer hrtimer_wakeup 261 mW 0.4 pkts/sDevice Network interface: eno1 (e1000e) 162 mW 4.7 ms/s 19.8Process[PID 520008] /usr/lib/firefox/firefox -contentproc 156 mW 4.0 ms/s 19.1Process[PID 519728] firefox 146 mW 16.0 ms/s 16.4Process[PID 72917] /usr/bin/gnome-shell 125 mW 5.8 ms/s 15.0Process[PID 518973] /usr/lib/thunderbird/thunderbird 121 mW160.7 us/s 15.2Process[PID 11] [rcu_sched] 117 mW 5.2 ms/s 14.1Process[PID 520003] /usr/lib/firefox/firefox -contentproc 100 mW100.0% Device USB device: Fujitsu Keyboard (Fujitsu) 100 mW100.0% Device USB device: Jolla (Jolla) 100 mW 0.0% Device Display backlight 100 mW100.0% Device USB device: USB Optical Mouse (Logitech) 95.4 mW605.7 us/s 11.9Process[PID 519018] /usr/lib/thunderbird/thunderbird 91.3 mW 4.0 ms/s 11.0Process[PID 519906] /usr/lib/firefox/firefox -contentproc 84.9 mW 45.2 ms/s 5.0kWork intel_atomic_commit_work 80.1 mW 1.1 ms/s 9.9Interrupt [0] HI_SOFTIRQ 76.6 mW 30.1 us/s 9.6kWork kfree_rcu_monitor 75.8 mW 58.0 us/s 9.5kWork kfree_rcu_work 74.5 mW269.4 us/s 9.3kWork engine_retire 62.5 mW 1.7 ms/s 7.6Process[PID 73223] ibus-daemon --panel disable -r --xim 59.6 mW 73.5 us/s 7.5kWork psi_avgs_work 56.9 mW 8.1 ms/s 6.1Process[PID 72956] /usr/bin/Xwayland :0 -rootless -norese 54.7 mW 4.7 ms/s 6.3Interrupt [7] sched(softirq) 54.0 mW 32.1 us/s 6.8Timer intel_uncore_fw_release_timer […] Is that expected to show? I guess due to the granularity it is? Kind regards, Paul
Re: [PATCH v3 3/3] drm/amdgpu: Change type of module param `ppfeaturemask` to hexint
Dear Linus, dear Christian, Am 03.07.20 um 17:29 schrieb Christian König: Am 03.07.20 um 16:29 schrieb Paul Menzel: The newly added hexint helper is more convenient for bitmasks. Before: $ more /sys/module/amdgpu/parameters/ppfeaturemask 4294950911 After: $ more /sys/module/amdgpu/parameters/ppfeaturemask 0xbfff Cc: amd-...@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Paul Menzel Reviewed-by: Christian König for this one. Feel free to add my Acked-by to the other two, but I'm not familiar enough with the code to review those. Thank you. Sorry for being ignorant, but what is the way forward? Kind regards, Paul
[Regression] hangs caused by commit 3202fa62fb (slub: relocate freelist pointer to middle of object)
Dear Kees, dear Andrew, No idea, if you are aware of it yet, but three people verified that commit 3202fa62fb (slub: relocate freelist pointer to middle of object) causes a regression on AMD hardware [1]. It’d be great, if you took a look, and advised if this commit (and follow-ups) should be reverted, until the issue is analyzed. Kind regards, Paul [1]: https://bugzilla.kernel.org/show_bug.cgi?id=207383 "[Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail"
Re: [PATCH 00/22] add support for Clang LTO
Dear Sami, Am 13.07.20 um 01:34 schrieb Sami Tolvanen: On Sat, Jul 11, 2020 at 9:32 AM Paul Menzel wrote: Thank you very much for sending these changes. Do you have a branch, where your current work can be pulled from? Your branch on GitHub [1] seems 15 months old. The clang-lto branch is rebased regularly on top of Linus' tree. GitHub just looks at the commit date of the last commit in the tree, which isn't all that informative. Thank you for clearing this up, and sorry for not checking myself. Out of curiosity, I applied the changes, allowed the selection for i386 (x86), and with Clang 1:11~++20200701093119+ffee8040534-1~exp1 from Debian experimental, it failed with `Invalid absolute R_386_32 relocation: KERNEL_PAGES`: I haven't looked at getting this to work on i386, which is why we only select ARCH_SUPPORTS_LTO for x86_64. I would expect there to be a few issues to address. arch/x86/tools/relocs vmlinux > arch/x86/boot/compressed/vmlinux.relocs;arch/x86/tools/relocs --abs-relocs vmlinux Invalid absolute R_386_32 relocation: KERNEL_PAGES KERNEL_PAGES looks like a constant, so it's probably safe to ignore the absolute relocation in tools/relocs.c. Thank you for pointing me to the right direction. I am happy to report, that with the diff below (no idea to what list to add the string), Linux 5.8-rc5 with the LLVM/Clang/LTO patches on top, builds and boots on the ASRock E350M1. ``` diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 8f3bf34840cef..e91af127ed3c0 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -79,6 +79,7 @@ static const char * const sym_regex_kernel[S_NSYMTYPES] = { "__end_rodata_hpage_align|" #endif "__vvar_page|" + "KERNEL_PAGES|" "_end)$" }; ``` Kind regards, Paul
Re: [PATCH 00/22] add support for Clang LTO
Dear Sami, Am 24.06.20 um 22:31 schrieb Sami Tolvanen: This patch series adds support for building x86_64 and arm64 kernels with Clang's Link Time Optimization (LTO). In addition to performance, the primary motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to be used in the kernel. Google's Pixel devices have shipped with LTO+CFI kernels since 2018. Most of the patches are build system changes for handling LLVM bitcode, which Clang produces with LTO instead of ELF object files, postponing ELF processing until a later stage, and ensuring initcall ordering. Note that first objtool patch in the series is already in linux-next, but as it's needed with LTO, I'm including it also here to make testing easier. […] Thank you very much for sending these changes. Do you have a branch, where your current work can be pulled from? Your branch on GitHub [1] seems 15 months old. Out of curiosity, I applied the changes, allowed the selection for i386 (x86), and with Clang 1:11~++20200701093119+ffee8040534-1~exp1 from Debian experimental, it failed with `Invalid absolute R_386_32 relocation: KERNEL_PAGES`: make -f ./scripts/Makefile.build obj=arch/x86/boot arch/x86/boot/bzImage make -f ./scripts/Makefile.build obj=arch/x86/boot/compressed arch/x86/boot/compressed/vmlinux llvm-nm vmlinux | sed -n -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW] \(_text\|__bss_start\|_end\)$/#define VO_ _AC(0x,UL)/p' > arch/x86/boot/compressed/../voffset.h clang -Wp,-MMD,arch/x86/boot/compressed/.misc.o.d -nostdinc -isystem /usr/lib/llvm-11/lib/clang/11.0.0/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -Qunused-arguments -m32 -O2 -fno-strict-aliasing -fPIE -DDISABLE_BRANCH_PROFILING -march=i386 -mno-mmx -mno-sse -ffreestanding -fno-stack-protector -Wno-address-of-packed-member -Wno-gnu -Wno-pointer-sign -fmacro-prefix-map=./= -fno-asynchronous-unwind-tables-DKBUILD_MODFILE='"arch/x86/boot/compressed/misc"' -DKBUILD_BASENAME='"misc"' -DKBUILD_MODNAME='"misc"' -D__KBUILD_MODNAME=misc -c -o arch/x86/boot/compressed/misc.o arch/x86/boot/compressed/misc.c llvm-objcopy -R .comment -S vmlinux arch/x86/boot/compressed/vmlinux.bin arch/x86/tools/relocs vmlinux > arch/x86/boot/compressed/vmlinux.relocs;arch/x86/tools/relocs --abs-relocs vmlinux Invalid absolute R_386_32 relocation: KERNEL_PAGES make[2]: *** [arch/x86/boot/compressed/Makefile:134: arch/x86/boot/compressed/vmlinux.relocs] Error 1 make[2]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs' make[1]: *** [arch/x86/boot/Makefile:115: arch/x86/boot/compressed/vmlinux] Error 2 make: *** [arch/x86/Makefile:268: bzImage] Error 2 Kind regards, Paul [1]: https://github.com/samitolvanen/linux/tree/clang-lto
Re: i8042 AUX port [serio1] suspend takes a second on Dell XPS 13 9360
Dear Dmitry, dear Mario, Am 21.02.18 um 10:22 schrieb Paul Menzel: Am 15.02.2018 um 16:22 schrieb mario.limoncie...@dell.com: -Original Message- From: Paul Menzel [mailto:pmenzel+linux-in...@molgen.mpg.de] Sent: Thursday, February 15, 2018 2:26 AM On 02/14/18 18:11, mario.limoncie...@dell.com wrote: -Original Message- From: Paul Menzel [mailto:pmenzel+linux-in...@molgen.mpg.de] Sent: Wednesday, February 14, 2018 10:41 AM On 01/30/18 19:07, Dmitry Torokhov wrote: On Tue, Jan 30, 2018 at 09:52:45AM -0800, Dmitry Torokhov wrote: On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote: I do not know, when it started, but with Linux 4.14-rc8 and 4.15, benchmarking suspend and resume time with `sleepgraph.py` [1][2], there is a regression, that i8042 AUX port [serio1] suspend takes a second on Dell XPS 13 9360 and TUXEDO Book 1406. It would be really helpful to know when the regression started. So the reason it takes longer is because the touchpad does not want to talk to us for some reason and we wait until commands time out: [ 94.591636] calling serio1+ @ 2299, parent: i8042 [ 94.794292] psmouse serio1: Failed to disable mouse on isa0060/serio1 [ 95.593303] call serio1+ returned 0 after 974280 usecs but it is not clear why it happens, I do not think we changed anything in that path for a while, so it might be some other change affecting things indirectly. I'm afraid you'll have to narrow the scope, and ideally bisect. Please keep in mind the XPS 9360 has a touchpad that can operate in I2C or PS2 modes. It's connected to both buses and with the right initialization sequence will come up in I2C mode. Assuming Paul M. has compiled and used hid-multitouch and i2c-hid the touchpad should be operating in I2C mode. When this happens I expect that the touchpad shouldn't be responding to PS2 commands. As a debugging tactic, you may consider to unload psmouse before suspend and still see the touchpad operational. Thank you! Unloading *psmouse* with `sudo modprobe -r psmouse` indeed worked on the Dell XPS 13 9360, that means, the cursor is still functioning. Thank you for your replies. First of all, it looks like *only* the Dell system is effected as I was unable to reproduce it on the TUXEDO Book 1406. I have to verify that by finding old log files. Does this other laptop you are drawing a comparison to also have a touchpad that can operate in multiple modes? To make an accurate comparison you should determine what mode it's in. Yeah, removing the module *psmouse*, the cursor didn’t work there anymore. I was really sure, that I saw that problem once on the TUXEDO device too, but must have been mistaken, that’s why I corrected it. Sorry for the misunderstanding. So, why does *psmouse* get loaded on the Dell XPS 13 9360 since at least Linux 4.13? Or where the modules added causing the touchpad to operate in I2C mode, which causes PS2 to stop to work? It was like that before this laptop even launched to the market. It's been like that since way before 4.13. I want to say maybe 3.13ish is when I2C mode would come up instead. Indeed, analyzing the behavior on the current 8th generation Dell XPS 13 93*7*0 with the shipped Ubuntu with Linux 4.4.0-112-generic, the same delay is visible. The order of events goes something like this: 1) Touchpad is initially in PS2 mode 2) psmouse loads 3) It reports that it may be supportable by a different bus 4) The sequence to switch to I2C mode happens 5) i2c-hid and hid-multitouch get loaded 6) psmouse is no longer functional Dmitry is there a way that we can connect the two events? When i2c-hid finds the touchpad notify psmouse to unload or at least stop trying to access it to prevent the problem Paul is talking about with suspend? That would be great. Please tell me, if there is a bug tracker, where this issue should reported to to track it. The issue is still present with Linux 5.8-rc4. Does Mario’s plan sound feasible? Kind regards, Paul
drm: BUG: unable to handle page fault for address: 17ec6000
Dear Linux folks, Building Linux v5.8-rc4-25-gbfe91da29bfad with Clang/LLD 1:11~++20200701093119+ffee8040534-1~exp1 from Debian experimental for 32-bit (`ARCH=i386`), starting Weston (Wayland) or X.Org Server results in non-working screen, and Linux shows the trace below [1]. [ 502.044997] BUG: unable to handle page fault for address: 17ec6000 [ 502.045650] #PF: supervisor write access in kernel mode [ 502.046301] #PF: error_code(0x0002) - not-present page [ 502.046956] *pde = [ 502.047612] Oops: 0002 [#1] SMP [ 502.048269] CPU: 0 PID: 2125 Comm: Xorg.wrap Not tainted 5.8.0-rc4-00105-g4da71f1ee6263 #141 [ 502.048967] Hardware name: System manufacturer System Product Name/F2A85-M PRO, BIOS 6601 11/25/2014 [ 502.049686] EIP: __srcu_read_lock+0x11/0x20 [ 502.050413] Code: 83 e0 03 50 56 68 72 c6 99 dd 68 46 c6 99 dd e8 3a c8 fe ff 83 c4 10 eb ce 0f 1f 44 00 00 55 89 e5 8b 48 68 8b 40 7c 83 e1 01 <64> ff 04 88 f0 83 44 24 fc 00 89 c8 5d c3 90 0f 1f 44 00 00 55 89 [ 502.052027] EAX: EBX: f36671b8 ECX: EDX: 0286 [ 502.052856] ESI: f3f94eb8 EDI: f3e51c00 EBP: f303dd9c ESP: f303dd9c [ 502.053695] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010246 [ 502.054543] CR0: 80050033 CR2: 17ec6000 CR3: 2eea2000 CR4: 000406d0 [ 502.055402] Call Trace: [ 502.056275] drm_minor_acquire+0x6f/0x140 [drm] [ 502.057162] drm_stub_open+0x2e/0x110 [drm] [ 502.058049] chrdev_open+0xdd/0x1e0 [ 502.058937] do_dentry_open+0x21d/0x330 [ 502.059828] vfs_open+0x23/0x30 [ 502.060718] path_openat+0x947/0xd60 [ 502.061610] ? unlink_anon_vmas+0x53/0x120 [ 502.062504] do_filp_open+0x6d/0x100 [ 502.063404] ? __alloc_fd+0x73/0x140 [ 502.064305] do_sys_openat2+0x1b3/0x2a0 [ 502.065217] __ia32_sys_openat+0x90/0xb0 [ 502.066128] ? prepare_exit_to_usermode+0xa/0x20 [ 502.067046] do_fast_syscall_32+0x68/0xd0 [ 502.067970] do_SYSENTER_32+0x12/0x20 [ 502.068902] entry_SYSENTER_32+0x9f/0xf2 [ 502.069839] EIP: 0xb7ef14f9 [ 502.070764] Code: Bad RIP value. [ 502.071689] EAX: ffda EBX: ff9c ECX: bfa6a2ac EDX: 8002 [ 502.072654] ESI: EDI: b7ed1000 EBP: bfa6b2c8 ESP: bfa6a1c0 [ 502.073630] DS: 007b ES: 007b FS: GS: 0033 SS: 007b EFLAGS: 0246 [ 502.074615] Modules linked in: af_packet k10temp r8169 realtek i2c_piix4 snd_hda_codec_realtek snd_hda_codec_generic ohci_pci ohci_hcd ehci_pci snd_hda_codec_hdmi ehci_hcd radeon i2c_algo_bit snd_hda_intel ttm snd_intel_dspcfg snd_hda_codec drm_kms_helper snd_hda_core snd_pcm cfbimgblt cfbcopyarea cfbfillrect snd_timer sysimgblt syscopyarea sysfillrect snd fb_sys_fops xhci_pci xhci_hcd soundcore acpi_cpufreq drm drm_panel_orientation_quirks agpgart ipv6 nf_defrag_ipv6 [ 502.077895] CR2: 17ec6000 [ 502.079050] ---[ end trace ced4517b63a6db26 ]--- [ 502.080214] EIP: __srcu_read_lock+0x11/0x20 [ 502.081392] Code: 83 e0 03 50 56 68 72 c6 99 dd 68 46 c6 99 dd e8 3a c8 fe ff 83 c4 10 eb ce 0f 1f 44 00 00 55 89 e5 8b 48 68 8b 40 7c 83 e1 01 <64> ff 04 88 f0 83 44 24 fc 00 89 c8 5d c3 90 0f 1f 44 00 00 55 89 [ 502.083891] EAX: EBX: f36671b8 ECX: EDX: 0286 [ 502.085148] ESI: f3f94eb8 EDI: f3e51c00 EBP: f303dd9c ESP: f303dd9c [ 502.086406] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010246 [ 502.087675] CR0: 80050033 CR2: 17ec6000 CR3: 2eea2000 CR4: 000406d0 $ dmesg | ./scripts/decodecode [ 55.784870] Code: 83 e0 03 50 56 68 ca c6 99 cf 68 9e c6 99 cf e8 3a c8 fe ff 83 c4 10 eb ce 0f 1f 44 00 00 55 89 e5 8b 48 68 8b 40 7c 83 e1 01 <64> ff 04 88 f0 83 44 24 fc 00 89 c8 5d c3 90 0f 1f 44 00 00 55 89 All code 0: 83 e0 03and$0x3,%eax 3: 50 push %eax 4: 56 push %esi 5: 68 ca c6 99 cf push $0xcf99c6ca a: 68 9e c6 99 cf push $0xcf99c69e f: e8 3a c8 fe ff call 0xfffec84e 14: 83 c4 10add$0x10,%esp 17: eb ce jmp0xffe7 19: 0f 1f 44 00 00 nopl 0x0(%eax,%eax,1) 1e: 55 push %ebp 1f: 89 e5 mov%esp,%ebp 21: 8b 48 68mov0x68(%eax),%ecx 24: 8b 40 7cmov0x7c(%eax),%eax 27: 83 e1 01and$0x1,%ecx 2a:* 64 ff 04 88 incl %fs:(%eax,%ecx,4)<-- trapping instruction 2e: f0 83 44 24 fc 00 lock addl $0x0,-0x4(%esp) 34: 89 c8 mov%ecx,%eax 36: 5d pop%ebp 37: c3 ret 38: 90 nop 39: 0f 1f 44 00 00 nopl 0x0(%eax,%eax,1) 3e: 55 push %ebp 3f: 89 .byte 0x89 Code starting with the faulting instruction === 0: 64 ff 04 88 incl %fs:(%eax,%ecx,4) 4: f0 83 44 24 fc 00 lock addl $
Re: Dell XPS 13 9360: PM: Device 0000:39:00.0 failed to resume async: error -19
Dear Greg, Am 30.06.20 um 10:42 schrieb Greg KH: On Mon, Jun 29, 2020 at 10:30:59PM +0200, Paul Menzel wrote: On the Dell XPS 13 9360 with Ubuntu 20.04 LTS and Linux 5.4.0-39-generic, That is an old kernel (and a distro one), can you please try 5.7.6 from kernel.org? Trying Linux 5.8-rc4 from the Ubuntu Linux Kernel Mainline PPA [1], Linux logged the messages below for device :39:00.0 on each of the 50 resumes. [ 96.057592] xhci_hcd :39:00.0: Timeout while waiting for setup device command [ 101.433589] xhci_hcd :39:00.0: Timeout while waiting for setup device command In seven of the 50 cases, the timeout messages below was also logged. [ 51.431713] xhci_hcd :00:14.0: port 2 resume PLC timeout Please find the log messages attached. Kind regards, Paul [1]: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8-rc4/ # suspend-070820-152008 Ixpees mem 5.8.0-050800-generic # sysinfo | man:Dell Inc. | plat:XPS 13 9360 | cpu:Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz | bios:2.13.0 | biosdate:11/14/2019 | numcpu:4 | memsz:15896892 | memfr:14152840 # command | sleepgraph.py -config config/suspend.cfg -multi 50 15 # fwsuspend 0 fwresume 2706432 [ 49.291995] PM: suspend entry (deep) [ 49.319081] Filesystems sync: 0.027 seconds [ 49.319084] PM: Preparing system for sleep (deep) [ 49.320115] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 49.322052] OOM killer disabled. [ 49.322055] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 49.323356] PM: Suspending system (deep) [ 49.323405] printk: Suspending console(s) (use no_console_suspend to debug) [ 49.324078] input input32: calling input_dev_suspend+0x0/0x50 @ 2478, parent: 1-5:1.0 [ 49.324081] input input32: input_dev_suspend+0x0/0x50 returned 0 after 0 usecs [ 49.324085] input input30: calling input_dev_suspend+0x0/0x50 @ 2478, parent: 0003:04F3:2234.0002 [ 49.324087] input input30: input_dev_suspend+0x0/0x50 returned 0 after 0 usecs [ 49.324089] input input29: calling input_dev_suspend+0x0/0x50 @ 2478, parent: 0003:04F3:2234.0002 [ 49.324091] input input29: input_dev_suspend+0x0/0x50 returned 0 after 0 usecs [ 49.324093] input input28: calling input_dev_suspend+0x0/0x50 @ 2478, parent: 0003:04F3:2234.0002 [ 49.324095] input input28: input_dev_suspend+0x0/0x50 returned 0 after 0 usecs [ 49.324099] input input26: calling input_dev_suspend+0x0/0x50 @ 2478, parent: 0018:06CB:76AF.0001 [ 49.324101] input input26: input_dev_suspend+0x0/0x50 returned 0 after 0 usecs [ 49.324103] input input25: calling input_dev_suspend+0x0/0x50 @ 2478, parent: 0018:06CB:76AF.0001 [ 49.324105] input input25: input_dev_suspend+0x0/0x50 returned 0 after 0 usecs [ 49.324108] rfkill rfkill1: calling rfkill_suspend+0x0/0x20 @ 2478, parent: hci0 [ 49.324110] rfkill rfkill1: rfkill_suspend+0x0/0x20 returned 0 after 0 usecs [ 49.324155] i2c_hid i2c-DLL075B:01: calling acpi_subsys_suspend+0x0/0x60 @ 8, parent: i2c-8 [ 49.324720] i2c_hid i2c-DLL075B:01: acpi_subsys_suspend+0x0/0x60 returned 0 after 548 usecs [ 49.324734] coretemp coretemp.0: calling platform_pm_suspend+0x0/0x50 @ 2478, parent: platform [ 49.324737] coretemp coretemp.0: platform_pm_suspend+0x0/0x50 returned 0 after 1 usecs [ 49.324742] rfkill rfkill0: calling rfkill_suspend+0x0/0x20 @ 2478, parent: phy0 [ 49.324744] usb 3-1.3: calling usb_dev_suspend+0x0/0x20 @ 115, parent: 3-1 [ 49.324745] rfkill rfkill0: rfkill_suspend+0x0/0x20 returned 0 after 0 usecs [ 49.324749] usb 3-1.3: usb_dev_suspend+0x0/0x20 returned 0 after 3 usecs [ 49.324770] ieee80211 phy0: calling wiphy_suspend+0x0/0x290 [cfg80211] @ 115, parent: :3a:00.0 [ 49.324772] usb 4-1.4: calling usb_dev_suspend+0x0/0x20 @ 8, parent: 4-1 [ 49.324775] leds dell::kbd_backlight: calling led_suspend+0x0/0x30 @ 2478, parent: dell-laptop [ 49.324776] usb 1-4: calling usb_dev_suspend+0x0/0x20 @ 341, parent: usb1 [ 49.324777] wlp58s0: deauthenticating from 6c:f3:7f:10:a0:fa by local choice (Reason: 3=DEAUTH_LEAVING) [ 49.324778] leds dell::kbd_backlight: led_suspend+0x0/0x30 returned 0 after 0 usecs [ 49.324787] dell-laptop dell-laptop: calling platform_pm_suspend+0x0/0x50 @ 2478, parent: platform [ 49.324797] usb 1-5: calling usb_dev_suspend+0x0/0x20 @ 201, parent: usb1 [ 49.324800] usb 1-5: usb_dev_suspend+0x0/0x20 returned 0 after 1 usecs [ 49.324803] dell-laptop dell-laptop: platform_pm_suspend+0x0/0x50 returned 0 after 0 usecs [ 49.324805] usb 3-1: calling usb_dev_suspend+0x0/0x20 @ 201, parent: usb3 [ 49.324806] usb 1-4: usb_dev_suspend+0x0/0x20 returned 0 after 26 usecs [ 49.324809] input input17: calling input_dev_suspend+0x0/0x50 @ 2478, parent: 9DBB5994-A997-11DA-B012-B622A1EF5492 [ 49.324812] input input17: input_dev_suspend+0x0/0x50 returned 0 after 1 usecs [ 49.324814] usb 1-3: calling usb_dev_suspend+0x0/0x20 @ 341, parent: usb1 [ 49.324816] dell-smbios dell
Re: [PATCH v2] .gitignore: Do not track `defconfig` from `make savedefconfig`
Dear Masahiro, Am 05.07.20 um 09:14 schrieb Masahiro Yamada: On Thu, Jul 2, 2020 at 8:12 PM Paul Menzel wrote: Running `make savedefconfig` creates by default `defconfig`, which is, currently, on git’s radar, for example, `git status` lists this file as untracked. So, add the file to `.gitignore`, so it’s ignored by git. Cc: linux-kernel@vger.kernel.org Signed-off-by: Paul Menzel --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index 87b9dd8a163b..f07500889fba 100644 --- a/.gitignore +++ b/.gitignore @@ -143,6 +143,9 @@ x509.genkey /allrandom.config /allyes.config +# Kconfig presets, default savedefconfg output I just noticed this comment is wrong since 'defconfig' is not a preset. I will change it to 'Kconfig savedefconfig output'. Thank you for finding my error and correcting it. I couldn’t find out more about *presets*. $ git grep -i preset scripts/kconfig/ $ Where can I look, so I won’t repeat the same mistake next time? +/defconfig + # Kdevelop4 *.kdev4 -- 2.27.0 Kind regards, Paul
iwlwifi: TX on unused queue 5
Dear Linux folks, Since at least Linux 5.2.9 a warning is thrown by *iwlwifi*. [ 21.211815] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 22.685490] rfkill: input handler disabled [ 26.529753] iwlwifi :02:00.0: RF_KILL bit toggled to disable radio. [ 26.529754] iwlwifi :02:00.0: reporting RF_KILL (radio disabled) [ 26.530095] wlan0: deauthenticating from 54:67:51:dd:7a:b3 by local choice (Reason: 3=DEAUTH_LEAVING) [ 26.530170] [ cut here ] [ 26.530170] TX on unused queue 5 [ 26.530196] WARNING: CPU: 3 PID: 130 at drivers/net/wireless/intel/iwlwifi/pcie/tx.c:2337 iwl_trans_pcie_tx+0x9be/0x1080 [iwlwifi] [ 26.530197] Modules linked in: ctr ccm fuse binfmt_misc nls_ascii nls_cp437 vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc btusb btrtl btbcm btintel bluetooth ecdh_generic ecc x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm iwlmvm snd_hda_codec_realtek dell_laptop dell_wmi irqbypass snd_hda_codec_generic iTCO_wdt dell_smbios snd_hda_codec_hdmi mac80211 ledtrig_audio iTCO_vendor_support mei_wdt ppdev crc32_pclmul sparse_keymap dell_wmi_descriptor dcdbas wmi_bmof watchdog ghash_clmulni_intel libarc4 snd_hda_intel sdhci_pci intel_rapl_msr intel_cstate snd_intel_dspcfg dell_smm_hwmon tpm_tis cqhci intel_uncore snd_hda_codec sdhci tpm_tis_core i915 iwlwifi snd_hda_core mmc_core intel_rapl_perf tpm cfg80211 xhci_pci ehci_pci efi_pstore snd_hwdep e1000e xhci_hcd ehci_hcd efivars snd_pcm rng_core pcspkr sg joydev parport_pc drm_kms_helper wmi snd_timer parport usbcore snd cec mei_me ptp processor_thermal_device int3403_thermal video [ 26.530218] lpc_ich soundcore i2c_algo_bit mei i2c_i801 usb_common intel_rapl_common pps_core mfd_core button intel_soc_dts_iosf int3400_thermal dell_rbtn int3402_thermal acpi_thermal_rel int340x_thermal_zone rfkill battery acpi_pad ac drm pkcs8_key_parser efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic dm_crypt dm_mod sd_mod t10_pi crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common crc32c_intel ahci libahci aesni_intel libata glue_helper libaes crypto_simd psmouse scsi_mod evdev cryptd serio_raw fan [ 26.530233] CPU: 3 PID: 130 Comm: kworker/3:2 Not tainted 5.7.0-1-amd64 #1 Debian 5.7.6-1 [ 26.530234] Hardware name: Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018 [ 26.530247] Workqueue: events cfg80211_rfkill_block_work [cfg80211] [ 26.530251] RIP: 0010:iwl_trans_pcie_tx+0x9be/0x1080 [iwlwifi] [ 26.530253] Code: 80 3d a2 b7 02 00 00 b8 ea ff ff ff 0f 85 b2 f9 ff ff 89 ce 48 c7 c7 07 64 ce c0 89 04 24 c6 05 84 b7 02 00 01 e8 24 b2 db d2 <0f> 0b 8b 04 24 e9 90 f9 ff ff 48 c7 44 24 50 00 00 00 00 8b 44 24 [ 26.530253] RSP: 0018:b76240213778 EFLAGS: 00010286 [ 26.530254] RAX: RBX: 8d1d8e57c8f0 RCX: 0998 [ 26.530255] RDX: 0001 RSI: 0086 RDI: 0247 [ 26.530255] RBP: 8d1dc10f9e88 R08: 0998 R09: 0004 [ 26.530256] R10: R11: 0001 R12: 0005 [ 26.530256] R13: 0005 R14: 8d1d73762080 R15: 8d1dc10883e8 [ 26.530257] FS: () GS:8d1dcdd8() knlGS: [ 26.530258] CS: 0010 DS: ES: CR0: 80050033 [ 26.530258] CR2: 558f3adf3808 CR3: 0003bc6d4005 CR4: 003606e0 [ 26.530259] DR0: DR1: DR2: [ 26.530259] DR3: DR6: fffe0ff0 DR7: 0400 [ 26.530260] Call Trace: [ 26.530268] ? iwl_mvm_set_tx_cmd+0x1a9/0x4b0 [iwlmvm] [ 26.530273] ? iwl_mvm_get_tx_rate.isra.0+0x87/0xe0 [iwlmvm] [ 26.530277] ? iwl_mvm_get_tx_ant+0x40/0x70 [iwlmvm] [ 26.530281] ? iwl_mvm_set_tx_cmd_rate+0x79/0xc0 [iwlmvm] [ 26.530286] ? iwl_mvm_set_tx_params+0x33e/0x4f0 [iwlmvm] [ 26.530291] iwl_mvm_tx_mpdu+0x170/0x500 [iwlmvm] [ 26.530296] iwl_mvm_tx_skb_sta+0x19d/0x470 [iwlmvm] [ 26.530300] iwl_mvm_tx_skb+0x17/0x40 [iwlmvm] [ 26.530304] iwl_mvm_mac_itxq_xmit+0x76/0xa0 [iwlmvm] [ 26.530318] ieee80211_queue_skb+0x2b7/0x450 [mac80211] [ 26.530330] ieee80211_tx+0xe7/0x140 [mac80211] [ 26.530342] __ieee80211_tx_skb_tid_band+0x6c/0x80 [mac80211] [ 26.530353] ieee80211_send_deauth_disassoc+0xf5/0x120 [mac80211] [ 26.530365] ieee80211_set_disassoc+0x361/0x5b0 [mac80211] [ 26.530368] ? __switch_to_asm+0x40/0x70 [ 26.530380] ieee80211_mgd_deauth.cold+0x49/0x1bf [mac80211] [ 26.530392] cfg80211_mlme_deauth+0xb3/0x1d0 [cfg80211] [ 26.530396] ? rtc_dev_compat_ioctl+0x13/0x60 [ 26.530406] cfg80211_mlme_down+0x66/0x90 [cfg80211] [ 26.530418] cfg80211_disconnect+0x129/0x1e0 [cfg80211] [ 26.530427] cfg80211_leave+0x27/0x40 [cfg80211] [ 26.530435] cfg80211_netdev_notifier_call+0x1a9/0x560 [cfg80211] [ 26.530440] ? iwl_mvm_send_cmd+0x12/0x30 [iw
[PATCH v3 1/3] kernel/params.c: Align last argument with a tab
The second and third arguments are aligned with tabs, so do the same for the fourth. Cc: linux-kernel@vger.kernel.org Signed-off-by: Paul Menzel --- kernel/params.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/kernel/params.c b/kernel/params.c index 8e56f8b12d8f..111eee82b999 100644 --- a/kernel/params.c +++ b/kernel/params.c @@ -233,14 +233,14 @@ char *parse_args(const char *doing, EXPORT_SYMBOL(param_ops_##name) -STANDARD_PARAM_DEF(byte, unsigned char, "%hhu", kstrtou8); -STANDARD_PARAM_DEF(short, short, "%hi", kstrtos16); -STANDARD_PARAM_DEF(ushort, unsigned short, "%hu", kstrtou16); -STANDARD_PARAM_DEF(int,int,"%i", kstrtoint); -STANDARD_PARAM_DEF(uint, unsigned int, "%u", kstrtouint); -STANDARD_PARAM_DEF(long, long, "%li", kstrtol); -STANDARD_PARAM_DEF(ulong, unsigned long, "%lu", kstrtoul); -STANDARD_PARAM_DEF(ullong, unsigned long long, "%llu", kstrtoull); +STANDARD_PARAM_DEF(byte, unsigned char, "%hhu", kstrtou8); +STANDARD_PARAM_DEF(short, short, "%hi", kstrtos16); +STANDARD_PARAM_DEF(ushort, unsigned short, "%hu", kstrtou16); +STANDARD_PARAM_DEF(int,int,"%i", kstrtoint); +STANDARD_PARAM_DEF(uint, unsigned int, "%u", kstrtouint); +STANDARD_PARAM_DEF(long, long, "%li", kstrtol); +STANDARD_PARAM_DEF(ulong, unsigned long, "%lu", kstrtoul); +STANDARD_PARAM_DEF(ullong, unsigned long long, "%llu", kstrtoull); int param_set_charp(const char *val, const struct kernel_param *kp) { -- 2.26.2
[PATCH v3 3/3] drm/amdgpu: Change type of module param `ppfeaturemask` to hexint
The newly added hexint helper is more convenient for bitmasks. Before: $ more /sys/module/amdgpu/parameters/ppfeaturemask 4294950911 After: $ more /sys/module/amdgpu/parameters/ppfeaturemask 0xbfff Cc: amd-...@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Paul Menzel --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 126e74758a34..5c4263335cba 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -391,12 +391,12 @@ MODULE_PARM_DESC(sched_hw_submission, "the max number of HW submissions (default module_param_named(sched_hw_submission, amdgpu_sched_hw_submission, int, 0444); /** - * DOC: ppfeaturemask (uint) + * DOC: ppfeaturemask (hexint) * Override power features enabled. See enum PP_FEATURE_MASK in drivers/gpu/drm/amd/include/amd_shared.h. * The default is the current set of stable power features. */ MODULE_PARM_DESC(ppfeaturemask, "all power features enabled (default))"); -module_param_named(ppfeaturemask, amdgpu_pp_feature_mask, uint, 0444); +module_param_named(ppfeaturemask, amdgpu_pp_feature_mask, hexint, 0444); /** * DOC: forcelongtraining (uint) -- 2.26.2
[PATCH v3 2/3] moduleparams: Add hexint type parameter
For bitmasks printing values in hex is more convenient. Prefix with `0x` to make it clear, that it’s a hex value, and pad it out. Using the helper for `amdgpu.ppfeaturemask`, it will look like below. Before: $ more /sys/module/amdgpu/parameters/ppfeaturemask 4294950911 After: $ more /sys/module/amdgpu/parameters/ppfeaturemask 0xbfff Cc: linux-kernel@vger.kernel.org Cc: amd-...@lists.freedesktop.org Signed-off-by: Paul Menzel --- include/linux/moduleparam.h | 7 ++- kernel/params.c | 17 + 2 files changed, 15 insertions(+), 9 deletions(-) diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h index 3ef917ff0964..cff7261e98bb 100644 --- a/include/linux/moduleparam.h +++ b/include/linux/moduleparam.h @@ -118,7 +118,7 @@ struct kparam_array * you can create your own by defining those variables. * * Standard types are: - * byte, short, ushort, int, uint, long, ulong + * byte, hexint, short, ushort, int, uint, long, ulong * charp: a character pointer * bool: a bool, values 0/1, y/n, Y/N. * invbool: the above, only sense-reversed (N = true). @@ -448,6 +448,11 @@ extern int param_set_ullong(const char *val, const struct kernel_param *kp); extern int param_get_ullong(char *buffer, const struct kernel_param *kp); #define param_check_ullong(name, p) __param_check(name, p, unsigned long long) +extern const struct kernel_param_ops param_ops_hexint; +extern int param_set_hexint(const char *val, const struct kernel_param *kp); +extern int param_get_hexint(char *buffer, const struct kernel_param *kp); +#define param_check_hexint(name, p) param_check_uint(name, p) + extern const struct kernel_param_ops param_ops_charp; extern int param_set_charp(const char *val, const struct kernel_param *kp); extern int param_get_charp(char *buffer, const struct kernel_param *kp); diff --git a/kernel/params.c b/kernel/params.c index 111eee82b999..3835fb82c64b 100644 --- a/kernel/params.c +++ b/kernel/params.c @@ -233,14 +233,15 @@ char *parse_args(const char *doing, EXPORT_SYMBOL(param_ops_##name) -STANDARD_PARAM_DEF(byte, unsigned char, "%hhu", kstrtou8); -STANDARD_PARAM_DEF(short, short, "%hi", kstrtos16); -STANDARD_PARAM_DEF(ushort, unsigned short, "%hu", kstrtou16); -STANDARD_PARAM_DEF(int,int,"%i", kstrtoint); -STANDARD_PARAM_DEF(uint, unsigned int, "%u", kstrtouint); -STANDARD_PARAM_DEF(long, long, "%li", kstrtol); -STANDARD_PARAM_DEF(ulong, unsigned long, "%lu", kstrtoul); -STANDARD_PARAM_DEF(ullong, unsigned long long, "%llu", kstrtoull); +STANDARD_PARAM_DEF(byte, unsigned char, "%hhu", kstrtou8); +STANDARD_PARAM_DEF(short, short, "%hi", kstrtos16); +STANDARD_PARAM_DEF(ushort, unsigned short, "%hu", kstrtou16); +STANDARD_PARAM_DEF(int,int,"%i", kstrtoint); +STANDARD_PARAM_DEF(uint, unsigned int, "%u", kstrtouint); +STANDARD_PARAM_DEF(long, long, "%li", kstrtol); +STANDARD_PARAM_DEF(ulong, unsigned long, "%lu", kstrtoul); +STANDARD_PARAM_DEF(ullong, unsigned long long, "%llu", kstrtoull); +STANDARD_PARAM_DEF(hexint, unsigned int, "%#08x", kstrtouint); int param_set_charp(const char *val, const struct kernel_param *kp) { -- 2.26.2
Re: [PATCH 1/2] moduleparams: Add hex type parameter
Dear Linus, dear Christian, Am 02.07.20 um 21:42 schrieb Linus Torvalds: On Thu, Jul 2, 2020 at 7:42 AM Christian König wrote: I'm just not sure how well this is received upstream because it only covers u32 On the other hand that is probably also the most used. Not necessarily true. I'd argue that "unsigned long" is equally possible for some bit mask (or other hex-likely) type. So don't call it just "hex". Call it "hexint" (the hex does imply "unsigned", I feel - showing hex numbers with a sign sounds insane). That way, if somebody ends up wanting it for unsigned long values, we're not stuck. Good idea. Don.e Another option is to just say that hex values always have bit _sizes_. So "hex32" and "hex64" would also make sense as names to me. I went for int to be consistent in the naming, and kstrtouint is used in the macro. While at it, should the hex numbers always be padded out to the size? The example Paul used doesn't have that issue (high bit being set). Bbut often it may make sense to show a 32-bit hex number as "%#08x" because it really makes things clearer when you're looking at high bits, say. It's really hard to tell the difference between "just bit 27 set" and "just bit 31" set otherwise, and that's not all that uncommon when the bitmasks are sparse. Also good idea. Done. I just sent out the v2. Kind regards, Paul
[PATCH v2 2/2] drm/amdgpu: Change type of module param `ppfeaturemask` to hexint
The newly added hexint helper is more convenient for bitmasks. Before: $ more /sys/module/amdgpu/parameters/ppfeaturemask 4294950911 After: $ more /sys/module/amdgpu/parameters/ppfeaturemask 0xbfff Cc: amd-...@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Paul Menzel --- v2: Use new name hexint drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 126e74758a34..5c4263335cba 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -391,12 +391,12 @@ MODULE_PARM_DESC(sched_hw_submission, "the max number of HW submissions (default module_param_named(sched_hw_submission, amdgpu_sched_hw_submission, int, 0444); /** - * DOC: ppfeaturemask (uint) + * DOC: ppfeaturemask (hexint) * Override power features enabled. See enum PP_FEATURE_MASK in drivers/gpu/drm/amd/include/amd_shared.h. * The default is the current set of stable power features. */ MODULE_PARM_DESC(ppfeaturemask, "all power features enabled (default))"); -module_param_named(ppfeaturemask, amdgpu_pp_feature_mask, uint, 0444); +module_param_named(ppfeaturemask, amdgpu_pp_feature_mask, hexint, 0444); /** * DOC: forcelongtraining (uint) -- 2.26.2
[PATCH v2 1/2] moduleparams: Add hexint type parameter
For bitmasks printing values in hex is more convenient. Prefix with `0x` to make it clear, that it’s a hex value, and pad it out. Using the helper for `amdgpu.ppfeaturemask`, it will look like below. Before: $ more /sys/module/amdgpu/parameters/ppfeaturemask 4294950911 After: $ more /sys/module/amdgpu/parameters/ppfeaturemask 0xbfff Cc: linux-kernel@vger.kernel.org Cc: amd-...@lists.freedesktop.org Signed-off-by: Paul Menzel --- v2: Address review comments: Rename hex to hexint, and pad sizes include/linux/moduleparam.h | 7 ++- kernel/params.c | 17 + 2 files changed, 15 insertions(+), 9 deletions(-) diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h index 3ef917ff0964..cff7261e98bb 100644 --- a/include/linux/moduleparam.h +++ b/include/linux/moduleparam.h @@ -118,7 +118,7 @@ struct kparam_array * you can create your own by defining those variables. * * Standard types are: - * byte, short, ushort, int, uint, long, ulong + * byte, hexint, short, ushort, int, uint, long, ulong * charp: a character pointer * bool: a bool, values 0/1, y/n, Y/N. * invbool: the above, only sense-reversed (N = true). @@ -448,6 +448,11 @@ extern int param_set_ullong(const char *val, const struct kernel_param *kp); extern int param_get_ullong(char *buffer, const struct kernel_param *kp); #define param_check_ullong(name, p) __param_check(name, p, unsigned long long) +extern const struct kernel_param_ops param_ops_hexint; +extern int param_set_hexint(const char *val, const struct kernel_param *kp); +extern int param_get_hexint(char *buffer, const struct kernel_param *kp); +#define param_check_hexint(name, p) param_check_uint(name, p) + extern const struct kernel_param_ops param_ops_charp; extern int param_set_charp(const char *val, const struct kernel_param *kp); extern int param_get_charp(char *buffer, const struct kernel_param *kp); diff --git a/kernel/params.c b/kernel/params.c index 8e56f8b12d8f..487261eb836f 100644 --- a/kernel/params.c +++ b/kernel/params.c @@ -233,14 +233,15 @@ char *parse_args(const char *doing, EXPORT_SYMBOL(param_ops_##name) -STANDARD_PARAM_DEF(byte, unsigned char, "%hhu", kstrtou8); -STANDARD_PARAM_DEF(short, short, "%hi", kstrtos16); -STANDARD_PARAM_DEF(ushort, unsigned short, "%hu", kstrtou16); -STANDARD_PARAM_DEF(int,int,"%i", kstrtoint); -STANDARD_PARAM_DEF(uint, unsigned int, "%u", kstrtouint); -STANDARD_PARAM_DEF(long, long, "%li", kstrtol); -STANDARD_PARAM_DEF(ulong, unsigned long, "%lu", kstrtoul); -STANDARD_PARAM_DEF(ullong, unsigned long long, "%llu", kstrtoull); +STANDARD_PARAM_DEF(byte, unsigned char, "%hhu", kstrtou8); +STANDARD_PARAM_DEF(short, short, "%hi", kstrtos16); +STANDARD_PARAM_DEF(ushort, unsigned short, "%hu", kstrtou16); +STANDARD_PARAM_DEF(int,int,"%i", kstrtoint); +STANDARD_PARAM_DEF(uint, unsigned int, "%u",kstrtouint); +STANDARD_PARAM_DEF(long, long, "%li", kstrtol); +STANDARD_PARAM_DEF(ulong, unsigned long, "%lu", kstrtoul); +STANDARD_PARAM_DEF(ullong, unsigned long long, "%llu", kstrtoull); +STANDARD_PARAM_DEF(hexint, unsigned int, "%#08x", kstrtouint); int param_set_charp(const char *val, const struct kernel_param *kp) { -- 2.26.2
[PATCH 2/2] drm/amdgpu: Change type of module param `ppfeaturemask` to hex
The newly added hex helper is more convenient for bitmasks. Before: $ more /sys/module/amdgpu/parameters/ppfeaturemask 4294950911 After: $ more /sys/module/amdgpu/parameters/ppfeaturemask 0xbfff Cc: amd-...@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Paul Menzel --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 126e74758a34..35a66b374e3a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -391,12 +391,12 @@ MODULE_PARM_DESC(sched_hw_submission, "the max number of HW submissions (default module_param_named(sched_hw_submission, amdgpu_sched_hw_submission, int, 0444); /** - * DOC: ppfeaturemask (uint) + * DOC: ppfeaturemask (hex) * Override power features enabled. See enum PP_FEATURE_MASK in drivers/gpu/drm/amd/include/amd_shared.h. * The default is the current set of stable power features. */ MODULE_PARM_DESC(ppfeaturemask, "all power features enabled (default))"); -module_param_named(ppfeaturemask, amdgpu_pp_feature_mask, uint, 0444); +module_param_named(ppfeaturemask, amdgpu_pp_feature_mask, hex, 0444); /** * DOC: forcelongtraining (uint) -- 2.26.2
[PATCH 1/2] moduleparams: Add hex type parameter
For bitmasks printing values in hex is more convenient. Prefix with 0x (#) to make it clear, that it’s a hex value. Using the helper for `amdgpu.ppfeaturemask`, it will look like below. Before: $ more /sys/module/amdgpu/parameters/ppfeaturemask 4294950911 After: $ more /sys/module/amdgpu/parameters/ppfeaturemask 0xbfff Cc: linux-kernel@vger.kernel.org Cc: amd-...@lists.freedesktop.org Signed-off-by: Paul Menzel --- include/linux/moduleparam.h | 7 ++- kernel/params.c | 1 + 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h index 3ef917ff0964..408978fcfe27 100644 --- a/include/linux/moduleparam.h +++ b/include/linux/moduleparam.h @@ -118,7 +118,7 @@ struct kparam_array * you can create your own by defining those variables. * * Standard types are: - * byte, short, ushort, int, uint, long, ulong + * byte, hex, short, ushort, int, uint, long, ulong * charp: a character pointer * bool: a bool, values 0/1, y/n, Y/N. * invbool: the above, only sense-reversed (N = true). @@ -448,6 +448,11 @@ extern int param_set_ullong(const char *val, const struct kernel_param *kp); extern int param_get_ullong(char *buffer, const struct kernel_param *kp); #define param_check_ullong(name, p) __param_check(name, p, unsigned long long) +extern const struct kernel_param_ops param_ops_hex; +extern int param_set_hex(const char *val, const struct kernel_param *kp); +extern int param_get_hex(char *buffer, const struct kernel_param *kp); +#define param_check_hex(name, p) param_check_uint(name, p) + extern const struct kernel_param_ops param_ops_charp; extern int param_set_charp(const char *val, const struct kernel_param *kp); extern int param_get_charp(char *buffer, const struct kernel_param *kp); diff --git a/kernel/params.c b/kernel/params.c index 8e56f8b12d8f..ceca8394dac5 100644 --- a/kernel/params.c +++ b/kernel/params.c @@ -241,6 +241,7 @@ STANDARD_PARAM_DEF(uint,unsigned int, "%u", kstrtouint); STANDARD_PARAM_DEF(long, long, "%li", kstrtol); STANDARD_PARAM_DEF(ulong, unsigned long, "%lu", kstrtoul); STANDARD_PARAM_DEF(ullong, unsigned long long, "%llu", kstrtoull); +STANDARD_PARAM_DEF(hex,unsigned int, "%#x", kstrtouint); int param_set_charp(const char *val, const struct kernel_param *kp) { -- 2.26.2
[PATCH v2] .gitignore: Do not track `defconfig` from `make savedefconfig`
Running `make savedefconfig` creates by default `defconfig`, which is, currently, on git’s radar, for example, `git status` lists this file as untracked. So, add the file to `.gitignore`, so it’s ignored by git. Cc: linux-kernel@vger.kernel.org Signed-off-by: Paul Menzel --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index 87b9dd8a163b..f07500889fba 100644 --- a/.gitignore +++ b/.gitignore @@ -143,6 +143,9 @@ x509.genkey /allrandom.config /allyes.config +# Kconfig presets, default savedefconfg output +/defconfig + # Kdevelop4 *.kdev4 -- 2.27.0
[PATCH] .gitignore: Do not track `defconfig` from `make savedefconfig`
Signed-off-by: Paul Menzel --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 87b9dd8a163b..5c1a5349852b 100644 --- a/.gitignore +++ b/.gitignore @@ -142,6 +142,7 @@ x509.genkey /allno.config /allrandom.config /allyes.config +/defconfig # Kdevelop4 *.kdev4 -- 2.27.0
Dell XPS 13 9360: PM: Device 0000:39:00.0 failed to resume async: error -19
Dear Linux folks, On the Dell XPS 13 9360 with Ubuntu 20.04 LTS and Linux 5.4.0-39-generic, testing suspend/resume with `sudo ./sleepgraph.py -config config/suspend.cfg -multi 50 15` the failure below happened *once*. [ 535.034086] xhci_hcd :39:00.0: calling pci_pm_resume+0x0/0xa0 @ 2584, parent: :02:02.0 [ 535.034172] rtsx_pci :3b:00.0: pci_pm_resume+0x0/0xa0 returned 0 after 988 usecs [ 535.036252] mei_me :00:16.0: pci_pm_resume+0x0/0xa0 returned 0 after 3253 usecs [ 535.053868] xhci_hcd :39:00.0: Refused to change power state, currently in D3 [ 535.053890] xhci_hcd :39:00.0: Controller not ready at resume -19 [ 535.053891] xhci_hcd :39:00.0: PCI post-resume error -19! [ 535.053892] xhci_hcd :39:00.0: HC died; cleaning up [ 535.053907] PM: dpm_run_callback(): pci_pm_resume+0x0/0xa0 returns -19 [ 535.053910] xhci_hcd :39:00.0: pci_pm_resume+0x0/0xa0 returned -19 after 19366 usecs [ 535.053917] PM: Device :39:00.0 failed to resume async: error -19 […] [ 535.992968] PM: Finishing wakeup. [ 535.992972] OOM killer enabled. [ 535.992973] Restarting tasks ... [ 535.992991] xhci_hcd :39:00.0: remove, state 4 [ 535.993000] usb usb4: USB disconnect, device number 1 [ 535.993494] xhci_hcd :39:00.0: USB bus 4 deregistered [ 535.993509] xhci_hcd :39:00.0: remove, state 4 [ 535.993515] usb usb3: USB disconnect, device number 1 [ 535.998941] done. [ 536.002354] xhci_hcd :39:00.0: Host halt failed, -19 [ 536.002357] xhci_hcd :39:00.0: Host not accessible, reset failed. [ 536.002443] xhci_hcd :39:00.0: USB bus 3 deregistered [ 536.158698] PM: suspend exit Is that a Linux driver, or device/firmware problem? Kind regards, Paul # suspend-062920-134258 Ixpees mem 5.4.0-39-generic # sysinfo | man:Dell Inc. | plat:XPS 13 9360 | cpu:Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz | bios:2.13.0 | biosdate:11/14/2019 | numcpu:4 | memsz:15901316 | memfr:13430088 # command | sleepgraph.py -config config/suspend.cfg -multi 50 15 # fwsuspend 0 fwresume 1548751 [ 533.119362] PM: suspend entry (deep) [ 533.154898] Filesystems sync: 0.035 seconds [ 533.154905] PM: Preparing system for sleep (deep) [ 533.155595] Freezing user space processes ... (elapsed 0.004 seconds) done. [ 533.159624] OOM killer disabled. [ 533.159631] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 533.161050] PM: Suspending system (deep) [ 533.161138] printk: Suspending console(s) (use no_console_suspend to debug) [ 533.179681] rfkill rfkill10: calling rfkill_suspend+0x0/0x20 @ 2968, parent: hci0 [ 533.179693] rfkill rfkill10: rfkill_suspend+0x0/0x20 returned 0 after 4 usecs [ 533.179734] serio serio1: calling serio_suspend+0x0/0x20 @ 2968, parent: i8042 [ 533.179745] serio serio1: serio_suspend+0x0/0x20 returned 0 after 3 usecs [ 533.179771] usb usb4: calling usb_dev_suspend+0x0/0x20 @ 2559, parent: :39:00.0 [ 533.179786] input input31: calling input_dev_suspend+0x0/0x50 @ 2968, parent: 0018:06CB:76AF.0002 [ 533.179799] input input31: input_dev_suspend+0x0/0x50 returned 0 after 4 usecs [ 533.179810] thunderbolt :03:00.0: calling pci_pm_suspend+0x0/0x150 @ 2573, parent: :02:00.0 [ 533.179834] input input30: calling input_dev_suspend+0x0/0x50 @ 2968, parent: 0018:06CB:76AF.0002 [ 533.179846] pcieport :02:01.0: calling pci_pm_suspend+0x0/0x150 @ 2576, parent: :01:00.0 [ 533.179853] input input30: input_dev_suspend+0x0/0x50 returned 0 after 3 usecs [ 533.179865] pcieport :02:01.0: pci_pm_suspend+0x0/0x150 returned 0 after 7 usecs [ 533.179873] input input28: calling input_dev_suspend+0x0/0x50 @ 2968, parent: 0003:04F3:2234.0001 [ 533.179884] input input28: input_dev_suspend+0x0/0x50 returned 0 after 2 usecs [ 533.179895] input input27: calling input_dev_suspend+0x0/0x50 @ 2968, parent: 0003:04F3:2234.0001 [ 533.179902] usb usb3: calling usb_dev_suspend+0x0/0x20 @ 2545, parent: :39:00.0 [ 533.179908] input input27: input_dev_suspend+0x0/0x50 returned 0 after 2 usecs [ 533.179921] input input26: calling input_dev_suspend+0x0/0x50 @ 2968, parent: 0003:04F3:2234.0001 [ 533.179933] input input26: input_dev_suspend+0x0/0x50 returned 0 after 2 usecs [ 533.179957] leds platform::micmute: calling led_suspend+0x0/0x30 @ 2968, parent: dell-laptop [ 533.179963] leds platform::micmute: led_suspend+0x0/0x30 returned 0 after 2 usecs [ 533.179971] leds dell::kbd_backlight: calling led_suspend+0x0/0x30 @ 2968, parent: dell-laptop [ 533.179979] leds dell::kbd_backlight: led_suspend+0x0/0x30 returned 0 after 2 usecs [ 533.179994] rfkill rfkill1: calling rfkill_suspend+0x0/0x20 @ 2968, parent: phy0 [ 533.180004] rfkill rfkill1: rfkill_suspend+0x0/0x20 returned 0 after 2 usecs [ 533.180053] i2c_hid i2c-DLL075B:01: calling acpi_subsys_suspend+0x0/0x60 @ 2576, parent: i2c-8 [ 533.180113] ieee80211 phy0: calling wiphy_suspend+0x0/0x290 [cfg80211] @ 2580, parent: :3a:00.0 [
Re: [Intel-wired-lan] [PATCH] e1000e: continue to init phy even when failed to disable ULP
Dear Aaron, Thank you for your patch. (Rant: Some more fallout from the other patch, which nobody reverted.) Am 16.06.20 um 12:05 schrieb Aaron Ma: After commit "e1000e: disable s0ix entry and exit flows for ME systems", some ThinkPads always failed to disable ulp by ME. Please add the (short) commit hash from the master branch. s/ulp/ULP/ Please list one ThinkPad as example. commit "e1000e: Warn if disabling ULP failed" break out of init phy: 1. Please add the closing quote ". 2. Please add the commit hash. error log: [ 42.364753] e1000e :00:1f.6 enp0s31f6: Failed to disable ULP [ 42.524626] e1000e :00:1f.6 enp0s31f6: PHY Wakeup cause - Unicast Packet [ 42.822476] e1000e :00:1f.6 enp0s31f6: Hardware Error When disable s0ix, E1000_FWSM_ULP_CFG_DONE will never be 1. If continue to init phy like before, it can work as before. iperf test result good too. Chnage e_warn to e_dbg, in case it confuses. s/Chnage/Change/ Please leave the level warning, and improve the warning message instead, so a user knows what is going on. Could you please add a `Fixes:` tag and the URL to the bug report? Signed-off-by: Aaron Ma --- drivers/net/ethernet/intel/e1000e/ich8lan.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c index f999cca37a8a..63405819eb83 100644 --- a/drivers/net/ethernet/intel/e1000e/ich8lan.c +++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c @@ -302,8 +302,7 @@ static s32 e1000_init_phy_workarounds_pchlan(struct e1000_hw *hw) hw->dev_spec.ich8lan.ulp_state = e1000_ulp_state_unknown; ret_val = e1000_disable_ulp_lpt_lp(hw, true); if (ret_val) { - e_warn("Failed to disable ULP\n"); - goto out; + e_dbg("Failed to disable ULP\n"); } ret_val = hw->phy.ops.acquire(hw); Kind regards, Paul
Re: close() on some Intel CNP-LP PCI devices takes up to 2.7 s
Dear Mika, Am 09.06.20 um 17:44 schrieb Mika Westerberg: On Tue, Jun 09, 2020 at 05:39:21PM +0200, Paul Menzel wrote: On the Intel Cannon Point-LP laptop Dell Precision 3540 with a dedicated AMD graphics card (both graphics devices can be used) with Debian Sid/unstable with Linux 5.6.14, running lspci takes quite some time, and the screen even flickers a short moment before the result is displayed. Tracing lspci with strace, shows that the close() function of the three devices takes from • 00:1d.0 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #9 • 04:00.0 System peripheral: Intel Corporation JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016] (rev 02) • 3b:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Lexa XT [Radeon PRO WX 3100] takes from 270 ms to 2.5 s. 11:43:21.714391 openat(AT_FDCWD, "/sys/bus/pci/devices/:04:00.0/config", O_RDONLY) = 3 11:43:21.714448 pread64(3, "\206\200\331\25\6\4\20\0\2\0\200\10 \0\0\0\0\0\0\352\0\0\4\352\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0(\20\272\10\0\0\0\0\ 200\0\0\0\0\0\0\0\377\1\0\0", 64, 0) = 64 11:43:24.487818 close(3)= 0 11:43:24.489508 openat(AT_FDCWD, "/sys/bus/pci/devices/:00:1d.0/config", O_RDONLY) = 3 11:43:24.489598 pread64(3, "\206\200\260\235\7\4\20\0\360\0\4\6\20\0\201\0\0\0\0\0\0\0\0\0\0;;\0\0 \354 \354\1\300\21\320\0\0\0\0\0\0\0\0\0\0\0\0 @\0\0\0\0\0\0\0\377\1\22\0", 64, 0) = 64 11:43:24.91 close(3)= 0 11:43:24.988544 openat(AT_FDCWD, "/sys/bus/pci/devices/:3b:00.0/config", O_RDONLY) = 3 11:43:24.988584 pread64(3, "\2\20\205i\7\4\20\0\0\0\200\3\20\0\0\0\f\0\0\300\0\0\0\0\f\0\0\320\0\0\0\0\0010\0\0\0\0 \354\0\0\0\0(\20\272\10\0\0$\354H\0\0\0\0\0\0\0\377\1\0\0", 64, 0) = 64 11:43:25.252745 close(3) Unfortunately, I forgot to collect the tree output, but hopefully the attached Linux messages and strace of lspci output will be enough for the start. Please tell me, if you want me to create a bug report in the Linux bug tracker. Can you try this commit? https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/pm&id=ec411e02b7a2e785a4ed9ed283207cd14f48699d It should be in the mainline already as well. Note we still need to obey the delays required by the PCIe spec so 100ms after the link is trained but this one should at least get it down from 1100ms. Thank you for replying so quickly. Hopefully, I’ll be able to test the commit tomorrow. One question though. The commit talks about resuming from suspend. I understand that training happens there. In my case the system is already running. So I wonder, why link(?) training would still happening. Kind regards, Paul
Acer TravelMate 5735Z: atkbd serio0: Unknown key pressed (translated set 2, code 0x93 on isa0060/serio0)
Dear Linux folks, Using Debian Sid/unstable with Linux 5.6.14 on an (old) Acer TravelMate 5735Z, pressing the WIFI enable/disable function key works, and GNOME even shows the OSD notification. But Linux still logs this key as unknown. [ 1595.795162] atkbd serio0: Unknown key pressed (translated set 2, code 0x93 on isa0060/serio0). [ 1595.795167] atkbd serio0: Use 'setkeycodes e013 ' to make it known. [ 1595.801375] atkbd serio0: Unknown key released (translated set 2, code 0x93 on isa0060/serio0). [ 1595.801380] atkbd serio0: Use 'setkeycodes e013 ' to make it known. Can this be fixed upstream, and if so, where, or should these messages be ignored? Kind regards, Paul [0.00] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28 [0.00] Linux version 5.6.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-13)) #1 SMP Debian 5.6.14-1 (2020-05-23) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.6.0-2-amd64 root=UUID=e17cec4f-d2b8-4cc3-bd39-39a10ed422f4 ro quiet noisapnp cryptomgr.notests random.trust_cpu=on acpi_backlight=native [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009dfff] usable [0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbb86bfff] usable [0.00] BIOS-e820: [mem 0xbb86c000-0xbb8befff] reserved [0.00] BIOS-e820: [mem 0xbb8bf000-0xbb981fff] usable [0.00] BIOS-e820: [mem 0xbb982000-0xbb9befff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb9bf000-0xbb9e8fff] usable [0.00] BIOS-e820: [mem 0xbb9e9000-0xbb9fefff] ACPI data [0.00] BIOS-e820: [mem 0xbb9ff000-0xbb9f] usable [0.00] BIOS-e820: [mem 0xbba0-0xbfff] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed1-0xfed13fff] reserved [0.00] BIOS-e820: [mem 0xfed18000-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffe0-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: Acer TravelMate 5735Z/BA51_MV, BIOS V1.14 07/26/2011 [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 2294.219 MHz processor [0.004010] e820: update [mem 0x-0x0fff] usable ==> reserved [0.004012] e820: remove [mem 0x000a-0x000f] usable [0.004019] last_pfn = 0xbba00 max_arch_pfn = 0x4 [0.004026] MTRR default type: uncachable [0.004026] MTRR fixed ranges enabled: [0.004028] 0-9 write-back [0.004029] A-B uncachable [0.004031] C-D write-protect [0.004032] E-E uncachable [0.004033] F-F write-protect [0.004034] MTRR variable ranges enabled: [0.004035] 0 base 0FFE0 mask FFFE0 write-protect [0.004037] 1 base 0FFFC mask E uncachable [0.004038] 2 base 0 mask F8000 write-back [0.004040] 3 base 08000 mask FC000 write-back [0.004041] 4 base 0BC00 mask FFC00 uncachable [0.004042] 5 base 0BBC0 mask FFFC0 uncachable [0.004044] 6 base 0BBA0 mask FFFE0 uncachable [0.004044] 7 disabled [0.004603] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.017995] BRK [0xab201000, 0xab201fff] PGTABLE [0.017999] BRK [0xab202000, 0xab202fff] PGTABLE [0.018001] BRK [0xab203000, 0xab203fff] PGTABLE [0.018042] BRK [0xab204000, 0xab204fff] PGTABLE [0.018044] BRK [0xab205000, 0xab205fff] PGTABLE [0.018190] BRK [0xab206000, 0xab206fff] PGTABLE [0.018231] BRK [0xab207000, 0xab207fff] PGTABLE [0.018373] RAMDISK: [mem 0x370a1000-0x37847fff] [0.018381] ACPI: Early table checksum verification disabled [0.018386] ACPI: RSDP 0x000FE020 24 (v02 ACRSYS) [0.018390] ACPI: XSDT 0xBB9FE120 64 (v01 ACRSYS ACRPRDCT 0001 0113) [0.018397] ACPI: FACP 0xBB9FD000 F4 (v04 ACRSYS ACRPRDCT 0001 1025 0113) [0.018404] ACPI: DSDT 0xBB9EB000 00C119 (v
Re: [PATCH] iommu/amd: Fix event counter availability check
Dear Alexander, Thank you very much for the patch. Am 31.05.20 um 09:22 schrieb Alexander Monakov: Adding Shuah Khan to Cc: I've noticed you've seen this issue on Ryzen 2400GE; can you have a look at the patch? Would be nice to know if it fixes the problem for you too. On Fri, 29 May 2020, Alexander Monakov wrote: The driver performs an extra check if the IOMMU's capabilities advertise presence of performance counters: it verifies that counters are writable by writing a hard-coded value to a counter and testing that reading that counter gives back the same value. Unfortunately it does so quite early, even before pci_enable_device is called for the IOMMU, i.e. when accessing its MMIO space is not guaranteed to work. On Ryzen 4500U CPU, this actually breaks the test: the driver assumes the counters are not writable, and disables the functionality. Moving init_iommu_perf_ctr just after iommu_flush_all_caches resolves the issue. This is the earliest point in amd_iommu_init_pci where the call succeeds on my laptop. Signed-off-by: Alexander Monakov Cc: Joerg Roedel Cc: Suravee Suthikulpanit Cc: io...@lists.linux-foundation.org --- PS. I'm seeing another hiccup with IOMMU probing on my system: pci :00:00.2: can't derive routing for PCI INT A pci :00:00.2: PCI INT A: not connected Hopefully I can figure it out, but I'd appreciate hints. I guess it’s a firmware bug, but I contacted the linux-pci folks [1]. drivers/iommu/amd_iommu_init.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c index 5b81fd16f5fa..1b7ec6b6a282 100644 --- a/drivers/iommu/amd_iommu_init.c +++ b/drivers/iommu/amd_iommu_init.c @@ -1788,8 +1788,6 @@ static int __init iommu_init_pci(struct amd_iommu *iommu) if (iommu->cap & (1UL << IOMMU_CAP_NPCACHE)) amd_iommu_np_cache = true; - init_iommu_perf_ctr(iommu); - if (is_rd890_iommu(iommu->dev)) { int i, j; @@ -1891,8 +1889,10 @@ static int __init amd_iommu_init_pci(void) init_device_table_dma(); - for_each_iommu(iommu) + for_each_iommu(iommu) { iommu_flush_all_caches(iommu); + init_iommu_perf_ctr(iommu); + } if (!ret) print_iommu_info(); base-commit: 75caf310d16cc5e2f851c048cd597f5437013368 Thank you very much for fixing this issue, which is almost two years old for me. Tested-by: Paul Menzel MSI MSI MS-7A37/B350M MORTAR with AMD Ryzen 3 2200G Link: https://lore.kernel.org/linux-iommu/20180727102710.ga6...@8bytes.org/ Kind regards, Paul [1]: https://lore.kernel.org/linux-pci/8579bd14-e369-1141-917b-204d20cff...@molgen.mpg.de/
Re: [PATCH] tpm_tis_spi: Don't send anything during flow control
Dear Douglas, Thank you for the patch. Am 29.05.20 um 00:19 schrieb Douglas Anderson: During flow control we are just reading from the TPM, yet our spi_xfer has the tx_buf and rx_buf both non-NULL which means we're requesting a full duplex transfer. SPI is always somewhat of a full duplex protocol anyway and in theory the other side shouldn't really be looking at what we're sending it during flow control, but it's still a bit ugly to be sending some "random" data when we shouldn't. The default tpm_tis_spi_flow_control() tries to address this by setting 'phy->iobuf[0] = 0'. This partially avoids the problem of sending "random" data, but since our tx_buf and rx_buf both point to the same place I believe there is the potential of us sending the TPM's previous byte back to it if we hit the retry loop. Another flow control implementation, cr50_spi_flow_control(), doesn't address this at all. Let's clean this up and just make the tx_buf NULL before we call flow_control(). Not only does this ensure that we're not sending any "random" bytes but it also possibly could make the SPI controller behave in a slightly more optimal way. NOTE: no actual observed problems are fixed by this patch--it's was just made based on code inspection. s/it's was/it was/ Were you able to test this? Maybe in the “Chromebook QA arsenal”? Are you already running it in production on Google Chrome OS devices? Signed-off-by: Douglas Anderson --- drivers/char/tpm/tpm_tis_spi_main.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/char/tpm/tpm_tis_spi_main.c b/drivers/char/tpm/tpm_tis_spi_main.c index d96755935529..8d2c581a93c6 100644 --- a/drivers/char/tpm/tpm_tis_spi_main.c +++ b/drivers/char/tpm/tpm_tis_spi_main.c @@ -53,8 +53,6 @@ static int tpm_tis_spi_flow_control(struct tpm_tis_spi_phy *phy, if ((phy->iobuf[3] & 0x01) == 0) { // handle SPI wait states - phy->iobuf[0] = 0; - for (i = 0; i < TPM_RETRY; i++) { spi_xfer->len = 1; spi_message_init(&m); @@ -104,6 +102,8 @@ int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, if (ret < 0) goto exit; + /* Flow control transfers are receive only */ + spi_xfer.tx_buf = NULL; ret = phy->flow_control(phy, &spi_xfer); if (ret < 0) goto exit; @@ -113,9 +113,8 @@ int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, spi_xfer.delay.value = 5; spi_xfer.delay.unit = SPI_DELAY_UNIT_USECS; - if (in) { - spi_xfer.tx_buf = NULL; - } else if (out) { + if (out) { + spi_xfer.tx_buf = phy->iobuf; spi_xfer.rx_buf = NULL; memcpy(phy->iobuf, out, transfer_len); out += transfer_len; Reviewed-by: Paul Menzel Kind regards, Paul