Re: [PATCH] iommu/amd: Fix extended features logging

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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 

Re: Marvell: hw perfevents: unable to count PMU IRQs

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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)

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

[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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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.

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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(>filter, mask);
err = ixgbe_fdir_write_perfect_filter_82599(hw, >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(>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(>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(>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

[Paul Menzel]

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 = >resource[PCI_ROM_RESOURCE];
+   struct pci_bus_region region;
+   u32 rom_addr;
+
+   pci_read_config_dword(dev, dev->rom_base_reg, _addr);
+
+   if (rom_addr & PCI_ROM_ADDRESS_ENABLE)
+   return;
+
+   pcibios_resource_to_bus(dev->bus, , 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 was run?

120 s delay during boot with smaller initrd

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

[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

[Paul Menzel]

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

[Paul Menzel]

[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`?

[Paul Menzel]

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

[Paul Menzel]

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 = >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 = >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(>dev, DPM_FLAG_NO_DIRECT_COMPLETE);

+   dev_pm_set_driver_flags(>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(>dev);



Kind regards,

Paul

[PATCH] ixgbe: Support external GBE SerDes PHY BCM54616s

[Paul Menzel]

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()

[Paul Menzel]

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(>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(>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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[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;
+   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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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) 

Warnings about filesystem timestamp support until 2038

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[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.
-- 
2.28.0

Re: Start messages in message buffer missing (dmesg)

[Paul Menzel]

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

[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.

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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)

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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`

[Paul Menzel]

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

[Paul Menzel]

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 

[PATCH v3 1/3] kernel/params.c: Align last argument with a tab

[Paul Menzel]

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

[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 
---
 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

[Paul Menzel]

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

[Paul Menzel]

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

[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 
---
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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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`

[Paul Menzel]

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`

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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

[Paul Menzel]

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=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)

[Paul Menzel]

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 

Re: [PATCH] iommu/amd: Fix event counter availability check

[Paul Menzel]

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

[Paul Menzel]

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();
@@ -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, _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

AMD Ryzen: pci 0000:00:00.2: can't derive routing for PCI INT A

[Paul Menzel]

Dear Linux folks,


On most (if not all) AMD Ryzen systems, including the Dell OptiPlex 
5055, [1][2], Linux prints the warning below:


$ dmesg --level=warn
[0.871377] pci :00:00.2: can't derive routing for PCI INT A
[0.871732] pci :00:00.2: PCI INT A: not connected
[0.884890]  PPR NX GT IA GA PC GA_vAPIC
$ more /proc/version
Linux version 5.4.39.mx64.334 (r...@lol.molgen.mpg.de) (gcc version 
7.5.0 (GCC)) #1 SMP Thu May 7 14:27:50 CEST 2020

pmenzel@donut:~$ dmesg | grep 'DMI:'
[0.00] DMI: Dell Inc. OptiPlex 5055 Ryzen CPU/0P03DX, BIOS 
1.1.20 05/31/2019


The system seems to work fine. What effect might be caused by the 
missing routing information?


I assume this is a firmware issue? Can I patch the ACPI tables to 
provide the correct information?


Should this indeed be an AMD AGESA issue, it be great, if somebody with 
contacts at AMD could be forward this to the appropriate folks.



Kind regards,

Paul


[1]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1804589
[2]: https://bugs.launchpad.net/dell-sputnik/+bug/1881121

watchdog: iTCO_wdt: cannot register miscdev on minor=130 (err=-16).

[Paul Menzel]

Dear Linux folks,


Linux 5.4.39 reports the watchdog messages below on a Dell PowerEdge 
T630 with 12x E5-2603 v4 @ 1.70GHz.


DMI: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.5.4 08/17/2017

```
handsomejack:~$ more /proc/version
Linux version 5.4.39.mx64.334 (r...@lol.molgen.mpg.de) (gcc version 
7.5.0 (GCC)) #1 SMP Thu May 7 14:27:50 CEST 2020

handsomejack:~$ grep TCO /boot/config-5.4.39.mx64.334
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
# CONFIG_SP5100_TCO is not set
CONFIG_ITCO_WDT=y
CONFIG_ITCO_VENDOR_SUPPORT=y
CONFIG_NV_TCO=y
# CONFIG_INTEL_SMARTCONNECT is not set
# CONFIG_EXTCON is not set
handsomejack:~$ dmesg --level=err
[   11.618887] watchdog: iTCO_wdt: cannot register miscdev on minor=130 
(err=-16).
[   11.627956] watchdog: iTCO_wdt: a legacy watchdog module is probably 
present.

handsomejack:~$ dmesg | grep -e iTCO -e watchdog
[   11.603138] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   11.609888] iTCO_wdt: Found a Wellsburg TCO device (Version=2, 
TCOBASE=0x0460)
[   11.618887] watchdog: iTCO_wdt: cannot register miscdev on minor=130 
(err=-16).
[   11.627956] watchdog: iTCO_wdt: a legacy watchdog module is probably 
present.

[   11.636462] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   11.643679] iTCO_vendor_support: vendor-support=0
handsomejack:~$ ls -l /dev/watchdog
crw--- 1 root root 10, 130 May 26 11:40 /dev/watchdog
```

Together the error and success messages are from the same module are 
confusing me a little. How can I find out the legacy watchdog module?



Kind regards,

Paul