-
Notifications
You must be signed in to change notification settings - Fork 53
/
Changelog
6699 lines (4816 loc) · 266 KB
/
Changelog
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
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
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
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
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
powerpc-utils-1.3.12
=====================================================================
commit 2f0bdb051fe70fbd6cb608ea1b63a75223dc44a4
Author: Tyrel Datwyler <[email protected]>
Date: Tue Feb 6 16:58:12 2024 -0800
lsslot: fix reporting of L3 caches with -b option
Currently if a L2 cache has an associated dependent L3 cache the lsslot
command for cpu connector types will fail to report the L3 cache when
using the -b option. This is due to a typo such that the check is made
between the the L2 caches l2-cache property value and its own
ibm,phandle property. The check should be against the L3 caches
ibm,phandle property as the l2-cache property contains the phandle of
the dependent cache.
Without patch:
./src/drmgr/lsslot -c cpu -b
drc-name OFDT-node drc_index thread id(s) l2-cache l3-cache
CPU 1 PowerPC,POWER8@0 10000000 0 1 2 3 4 5 6 7 l2-cache@200a N/A
With patch:
./src/drmgr/lsslot -c cpu -b
drc-name OFDT-node drc_index thread id(s) l2-cache l3-cache
CPU 1 PowerPC,POWER8@0 10000000 0 1 2 3 4 5 6 7 l2-cache@200a l3-cache@310a
Signed-off-by: Tyrel Datwyler <[email protected]>
commit a63f08289611e3c76814a3b9fbb7ef7c56d13ff5
Author: Tyrel Datwyler <[email protected]>
Date: Thu Feb 1 07:19:58 2024 +0530
lsslot: fix and unify formatting of cpu slots
When listing cpu slots with and without the -b option the formatting is
inconsistent and some column headers and associated data are not aligned.
Adjusted format strings accordingly.
Without patch:
localhost:~/powerpc-utils # ./src/drmgr/lsslot -c cpu
drc-name OFDT-node drc_index thread id(s)
CPU 41 PowerPC,POWER10@28 10000028 28 29 2a 2b 2c 2d 2e 2f
CPU 33 PowerPC,POWER10@20 10000020 20 21 22 23 24 25 26 27
CPU 25 PowerPC,POWER10@18 10000018 18 19 1a 1b 1c 1d 1e 1f
CPU 17 PowerPC,POWER10@10 10000010 10 11 12 13 14 15 16 17
CPU 9 PowerPC,POWER10@8 10000008 8 9 a b c d e f
CPU 1 PowerPC,POWER10@0 10000000 0 1 2 3 4 5 6 7
localhost:~/powerpc-utils # ./src/drmgr/lsslot -c cpu -b
drc-name OFDT-node drc_index thread id(s) l2-cache l3-cache
CPU 41 PowerPC,POWER10@28 10000028 28 29 2a 2b 2c 2d 2e 2f N/A N/A
CPU 33 PowerPC,POWER10@20 10000020 20 21 22 23 24 25 26 27 N/A N/A
CPU 25 PowerPC,POWER10@18 10000018 18 19 1a 1b 1c 1d 1e 1f N/A N/A
CPU 17 PowerPC,POWER10@10 10000010 10 11 12 13 14 15 16 17 N/A N/A
CPU 9 PowerPC,POWER10@8 10000008 8 9 a b c d e f N/A N/A
CPU 1 PowerPC,POWER10@0 10000000 0 1 2 3 4 5 6 7 N/A N/A
With patch:
localhost:~/powerpc-utils # ./src/drmgr/lsslot -c cpu
drc-name OFDT-node drc_index thread id(s)
CPU 41 PowerPC,POWER10@28 10000028 28 29 2a 2b 2c 2d 2e 2f
CPU 33 PowerPC,POWER10@20 10000020 20 21 22 23 24 25 26 27
CPU 25 PowerPC,POWER10@18 10000018 18 19 1a 1b 1c 1d 1e 1f
CPU 17 PowerPC,POWER10@10 10000010 10 11 12 13 14 15 16 17
CPU 9 PowerPC,POWER10@8 10000008 8 9 a b c d e f
CPU 1 PowerPC,POWER10@0 10000000 0 1 2 3 4 5 6 7
localhost:~/powerpc-utils # ./src/drmgr/lsslot -c cpu -b
drc-name OFDT-node drc_index thread id(s) l2-cache l3-cache
CPU 41 PowerPC,POWER10@28 10000028 28 29 2a 2b 2c 2d 2e 2f N/A N/A
CPU 33 PowerPC,POWER10@20 10000020 20 21 22 23 24 25 26 27 N/A N/A
CPU 25 PowerPC,POWER10@18 10000018 18 19 1a 1b 1c 1d 1e 1f N/A N/A
CPU 17 PowerPC,POWER10@10 10000010 10 11 12 13 14 15 16 17 N/A N/A
CPU 9 PowerPC,POWER10@8 10000008 8 9 a b c d e f N/A N/A
CPU 1 PowerPC,POWER10@0 10000000 0 1 2 3 4 5 6 7 N/A N/A
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 01bc16de40385467cd32440da43ff02b0f0e856c
Author: Tyrel Datwyler <[email protected]>
Date: Thu Feb 1 07:02:49 2024 +0530
lsslot: fix displaying cpu slots and caches with -b option
The format string for printing the drc-name, OFDT-node, and drc-index in
list_cpus_and_caches() contains a spurious '%' qualifier at the end of
the string. Historically, this was ignored by compilers and the string
populated anyways. However, we since observed lsslot built on SLES 15
SP6 where the string is not populated.
Removing the spurious '%' fixes the issue.
Without patch:
localhost:~ # lsslot -c cpu -b
drc-name OFDT-node drc_index thread id(s) l2-cache l3-cache
28 29 2a 2b 2c 2d 2e 2f N/A N/A
20 21 22 23 24 25 26 27 N/A N/A
18 19 1a 1b 1c 1d 1e 1f N/A N/A
10 11 12 13 14 15 16 17 N/A N/A
8 9 a b c d e f N/A N/A
0 1 2 3 4 5 6 7 N/A N/A
With patch:
localhost:~/powerpc-utils # ./src/drmgr/lsslot -c cpu -b
drc-name OFDT-node drc_index thread id(s) l2-cache l3-cache
CPU 41 PowerPC,POWER10@28 10000028 28 29 2a 2b 2c 2d 2e 2f N/A N/A
CPU 33 PowerPC,POWER10@20 10000020 20 21 22 23 24 25 26 27 N/A N/A
CPU 25 PowerPC,POWER10@18 10000018 18 19 1a 1b 1c 1d 1e 1f N/A N/A
CPU 17 PowerPC,POWER10@10 10000010 10 11 12 13 14 15 16 17 N/A N/A
CPU 9 PowerPC,POWER10@8 10000008 8 9 a b c d e f N/A N/A
CPU 1 PowerPC,POWER10@0 10000000 0 1 2 3 4 5 6 7 N/A N/A
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 5f825c75c6dfc2a95af1eebb6e364587d178deee
Author: Michal Suchanek <[email protected]>
Date: Thu Jul 21 12:38:16 2022 +0200
hcn-init: Split services per connection manager.
The universal service using network.service alias does not work
reliably.
Use one service per supported connection manager.
Signed-off-by: Michal Suchanek <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit f1a8ed892e18b83cb0483e8f8f8cbc512fa8510c
Author: Laurent Dufour <[email protected]>
Date: Thu Aug 10 11:47:07 2023 +0200
ppc64_cpu/info: fix bad report when non continuous CPU ids
When CPU ids are not continuous, let say that the kernel didn't reuse a set
of CPU ids already used on a different nodes, the output of ppc64_cpu
--info is not correct.
For instance, in the example below the CPU id 48 to 55 haven't been reused
by the kernel when a CPU has been added after a LPM operation.
Note that the system is running in SMT=4.
The numactl -H command is providing the correct set of CPU:
ltczep3-lp4:~ # numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 64 65 66 67 68 69 70 71
node 0 size: 7177 MB
node 0 free: 4235 MB
node 1 cpus: 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
node 1 size: 24508 MB
node 1 free: 23539 MB
node distances:
node 0 1
0: 10 40
1: 40 10
But ppc64_cpu --info is reporting the CPUs 48 to 55 offlined while not
reporting at all the CPU 65 to 71:
ltczep3-lp4:~ # ppc64_cpu --info
Core 0: 0* 1* 2* 3* 4* 5* 6* 7*
Core 1: 8* 9* 10* 11* 12* 13* 14* 15*
Core 2: 16* 17* 18* 19* 20* 21* 22* 23*
Core 3: 24* 25* 26* 27* 28* 29* 30* 31*
Core 4: 32* 33* 34* 35* 36* 37* 38* 39*
Core 5: 40* 41* 42* 43* 44* 45* 46* 47*
Core 6: 48 49 50 51 52 53 54 55
This is because it is considering that the CPU id are continuous which is
not the case here.
To prevent that, when looking for a core, it is now first checking that the
physical_id of the first thread in that core is defined (not -1). If that
the case this means that CPU/core is present.
With that patch applied, ppc64_cpu --info is reporting:
ltczep3-lp4:~ # pc64_cpu --info
Core 0: 0* 1* 2* 3* 4 5 6 7
Core 1: 8* 9* 10* 11* 12 13 14 15
Core 2: 16* 17* 18* 19* 20 21 22 23
Core 3: 24* 25* 26* 27* 28 29 30 31
Core 4: 32* 33* 34* 35* 36 37 38 39
Core 5: 40* 41* 42* 43* 44 45 46 47
Core 6: 64* 65* 66* 67* 68 69 70 71
Signed-off-by: Laurent Dufour <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit d604cc779741c29cbdc8da97cbfc1512fd21fc1b
Author: Likhitha Korrapati <[email protected]>
Date: Fri Aug 11 00:41:14 2023 -0500
nvram man page and --help output are not in sync
The nvram man page and the output from --help option are not in
sync and few of the options are missing in man page.
The options that are missing are ascii, dump, nvram-size, zero.
These options are added through the commit ids [1], [2].
This patch adds the above missing options to the nvram.
[1] https://github.com/ibm-power-utilities/powerpc-utils/commit/0e09f4e2898e7dea556479b018a7f4bf12108099
[2] https://github.com/ibm-power-utilities/powerpc-utils/commit/976dbe9bb7b01b135cac3e7bbd1dce0cdc88636a
Signed-off-by: Likhitha Korrapati <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 882335a30d04032d2684e165f70646b368a788b4
Author: Wen Xiong <[email protected]>
Date: Tue Jan 30 10:49:13 2024 -0600
bootlist: Support multiple dev paths for a nvme boot device
Multipath splitter drawer is going to support two physical paths for
each nvme device.
This patch adds the support for multiple device/of paths for a nvme boot
device.
For example,
#lsslot -c pci
U50EE.001.WZS000E-P3-C1-R1 U.2 PCI-E capable, Rev 4, 4x lanes with 2x
lanes connected 0581:10:00.0
U50EE.001.WZS000E-P3-C1-R2 U.2 PCI-E capable, Rev 4, 4x lanes with 2x
lanes connected 0521:10:00.0
#nvme list-subsys
nvme-subsys1 -
NQN=nqn.1994-11.com.samsung:nvme:PM1735a:2.5-inch:S6RUNE0R900042
hostnqn=nqn.2014-08.org.nvmexpress:uuid:3c6c1ace-e9b1-4a17-8ff0-6a84d3dd15f4
iopolicy=numa
\
+- nvme1 pcie 0523:20:00.0 live
+- nvme0 pcie 0583:20:00.0 live
# bootlist -m normal nvme1n1
# bootlist -m normal -o
nvme0
nvme1n1
#bootlist -m normal -r
/pci@800000020000583/pci1014,6bc@0/namespace@1
/pci@800000020000523/pci1014,6bc@0/namespace@1
Signed-off-by: Wen Xiong <[email protected]>
[tyreld: fixup whitespace errors]
Signed-off-by: Tyrel Datwyler <[email protected]>
commit a6d31caf4eaa453d3ec879f02163b3a515789b85
Author: Likhitha Korrapati <[email protected]>
Date: Mon Sep 11 05:23:37 2023 -0500
powerpc/nvram: Fix Segmentation fault issue in nvram-size.
nvram-size option results in segmentation fault when the user
specifies value larger than the default nvram size
Without the patch:
[root@xxx ~]# nvram --nvram-size 1048592
nvram: WARNING: expected 1048592 bytes, but only read 15360!
Segmentation fault (core dumped)
Segmentation fault is caused because the phead->length is becoming 0.
And because of this the p_start doesn't get updated which makes the
while loop run infinitely resulting in segmentation fault.
This patch adds a condition check for phead->length to avoid infinite
while loop.
With the patch:
[root@xxx src]# ./nvram --nvram-size 1048592
./nvram: WARNING: expected 1048592 bytes, but only read 15360!
[root@xxx src]# ./nvram --nvram-size 268435456
./nvram: WARNING: expected 268435456 bytes, but only read 15360!
[root@xxx src]#
Reported-by: Shirisha Ganta <[email protected]>
Signed-off-by: Likhitha Korrapati <[email protected]>
[tyreld: fixed up else block]
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 3f72b8326a2fc9a9dffb4b31d0ce3abf12e24751
Author: Likhitha Korrapati <[email protected]>
Date: Thu Jan 25 15:44:02 2024 +0530
powerpc/nvram: fix segmentation fault issue in print-config
print-config option in nvram results in segmentation fault when the
user provides a very large value.
without the patch:
[root@xxx powerpc-utils]# nvram --print-config=real-mode?
true
[root@xxx powerpc-utils]# nvram --print-config=$(perl -e 'p
rint "A"x1000000')
Segmentation fault (core dumped)
The Segmentation fault occurs because the code tries to access memory
beyond the bounds of the data at index varlen. varlen is the length of
the string provided by the user.
This patch adds a condition to check whether the length of the data is
greater than varlen to prevent accessing out of bounds.
with the patch:
[root@xxx powerpc-utils]# ./src/nvram --print-config=real-m
ode?
true
[root@xxx powerpc-utils]# ./src/nvram --print-config=$(perl
-e 'print "A"x1000000')
Reported-by: Shirisha Ganta <[email protected]>
Signed-off-by: Likhitha Korrapati <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 8a7aa61c5f520df03e53e6f7e1d63b7d5c432376
Author: Wen Xiong <[email protected]>
Date: Wed Nov 15 14:37:43 2023 -0600
powerpc-utils/scripts/ofpathname: handle nsid of nvme device as hex number
Installation fails if nsid of nvme device is greater than 10.
The patch fixes the issue and handle nsid of nvme ad a hex number.
Signed-off-by: Wen Xiong <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 9caa77e4477a73064a6deea253fd3faea32648fb
Author: Likhitha Korrapati <[email protected]>
Date: Fri Nov 17 01:42:29 2023 -0500
rtas_dbg: Fix the large negative values in rtas_dbg
without the patch:
[root@xxx powerpc-utils]# rtas_dbg -l ibm,rks-hcalls
Could not get rtas token for ibm,indicator-0002
Could not get rtas token for ibm,integrated-stop-self
Could not get rtas token for ibm,indicator-9005
Could not get rtas token for ibm,extended-os-term
Could not get rtas token for ibm,indicator-0001
Could not get rtas token for ibm,sensor-0009
Could not get rtas token for ibm,recoverable-epow3
Could not get rtas token for ibm,sensor-9005
Could not get rtas token for ibm,change-msix-capable
Could not get rtas token for ibm,sensor-0005
Could not get rtas token for ibm,sensor-0001
ibm,rks-hcalls -536870912
The large negatives values are due to incompatible format(%d).
The data type of the token variable is uint32_t.This patch
modifies the format(%u) to align with its data type(uint32_t).
with the patch:
[root@xxx powerpc-utils]# ./src/rtas_dbg -l ibm,rks-hcalls
Could not get rtas token for ibm,indicator-0002
Could not get rtas token for ibm,integrated-stop-self
Could not get rtas token for ibm,indicator-9005
Could not get rtas token for ibm,extended-os-term
Could not get rtas token for ibm,indicator-0001
Could not get rtas token for ibm,sensor-0009
Could not get rtas token for ibm,recoverable-epow3
Could not get rtas token for ibm,sensor-9005
Could not get rtas token for ibm,change-msix-capable
Could not get rtas token for ibm,sensor-0005
Could not get rtas token for ibm,sensor-0001
ibm,rks-hcalls 3758096384
Reported-by: Shirisha Ganta <[email protected]>
Signed-off-by: Likhitha Korrapati <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit c1d6a1473211e4e470aee8256d613f16a75897d6
Author: Laurent Dufour <[email protected]>
Date: Wed Apr 5 17:49:23 2023 +0200
drmgr: Add CPU hook in the man page
Also fixing few minor typos.
Signed-off-by: Laurent Dufour <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit d23e7ad0ed939dcd33f97839e0551707c78af77a
Author: Laurent Dufour <[email protected]>
Date: Wed Apr 5 17:49:22 2023 +0200
drmgr/cpu: add CPU add and remove operation's hooks
Call drmgr's hooks before and after a CPU add or remove operation is done.
At the PRE phase, the DRC_COUNT hook parameter is set to the desired number
of CPU to add or remove. At the POST phase, it is set to the actual number
of CPU added or removed.
Signed-off-by: Laurent Dufour <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 24500fe33ceb84423730cb1ed654efbdc43deba8
Author: Laurent Dufour <[email protected]>
Date: Wed Apr 5 17:49:21 2023 +0200
drmgr/common: add a DRC_COUNT parameter to the hooks
The new DRC_COUNT will be set when running operation on countable items,
like adding or removing CPUs.
For the migration operation, this doesn't make sense and it is set to 0.
Using a signed integer so we can pass signed values, if needed in the
future.
Signed-off-by: Laurent Dufour <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 35a7487f0ec039bf8ea9e3c87f3b176ca1580145
Author: Laurent Dufour <[email protected]>
Date: Wed Apr 5 17:49:20 2023 +0200
drmgr/common: drmgr: Add action parameter to the hook mechanism
The user action is now exported to the hook ran by drmgr.
It is exported in the environment variable ACTION.
Signed-off-by: Laurent Dufour <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit c2922361b9bb2647b862056aa40095cdbfefee2f
Author: Laurent Dufour <[email protected]>
Date: Wed Apr 5 17:49:19 2023 +0200
drmgr/common: make drc_type_str and hook_phase_name const
The drc_type_str and hook_phase_name should be declared as const.
No functional changes.
Fixes: 372599ed28d6 ("drmgr: introduce a DRC type name table")
Fixes: e0928dc5e537 ("drmgr: introducing the hook framework")
Suggested-by: Tyrel Datwyler <[email protected]>
Signed-off-by: Laurent Dufour <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit dee15756bcb287ccf39a904be07c90107b13844b
Author: Laurent Dufour <[email protected]>
Date: Wed May 3 10:50:15 2023 +0200
lparstat: Fix offline threads uninitialized entries
When some threads are offline, lparstat -E is failing like that:
$ ppc64_cpu --info # CPU 20 is offline
Core 0: 0* 1* 2* 3* 4* 5* 6* 7*
Core 1: 8* 9* 10* 11* 12* 13* 14* 15*
Core 2: 16* 17* 18* 19* 20 21* 22* 23*
Core 3: 24* 25* 26* 27* 28* 29* 30* 31*
Core 4: 32* 33* 34* 35* 36* 37* 38* 39*
Core 5: 40* 41* 42* 43* 44* 45* 46* 47*
$ lparstat -E
Failed to read /sys/devices/system/cpu/cpu0/spurr
The message is complaining about CPU0 but the real issue is that in
parse_sysfs_values() the test cpu_sysfs_fds[i].spurr >= 0 is valid even if
the entry has not been initialized (cpu_sysfs_fds is alloc cleared). So
if the number of threads online seen in assign_cpu_sysfs_fds is lower than
threads_in_system, the loop in parse_sysfs_values() will read uninitialized
entry, where .cpu=0.
To prevent that, unset entries in the cpu_sysfs_fds should have the spurr
fd set to -1.
Signed-off-by: Laurent Dufour <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit b2672fa3d462217ccd057a2cd307af2448e78757
Author: Laurent Dufour <[email protected]>
Date: Wed May 3 10:50:14 2023 +0200
lparstat: report mixed SMT state
when SMT state is mixed like this one (CPU 4 is offline):
$ ppc64_cpu --info
Core 0: 0* 1* 2* 3* 4 5* 6* 7*
Core 1: 8* 9* 10* 11* 12* 13* 14* 15*
Core 2: 16* 17* 18* 19* 20* 21* 22* 23*
Core 3: 24* 25* 26* 27* 28* 29* 30* 31*
Core 4: 32* 33* 34* 35* 36* 37* 38* 39*
Core 5: 40* 41* 42* 43* 44* 45* 46* 47*
$ ppc64_cpu --smt
SMT=7: 0
SMT=8: 1-5
ppc64_cpu --smt is handling that nicely but lparstat failed reporting the
SMT state:
$ /usr/sbin/lparstat
Failed to get smt state
System Configuration
type=Dedicated mode=Capped smt=Capped lcpu=6 mem=65969728 kB cpus=0 ent=6.00
%user %sys %wait %idle physc %entc lbusy app vcsw phint
----- ----- ----- ----- ----- ----- ----- ----- ----- -----
0.02 0.01 0.00 99.97 3.41 56.83 0.02 0.00 4061778 156
Makes lparstat reporting "smt=mixed" in that case.
__do_smt is now returning 0 when the SMT state is mixed instead of -1 which
is also reported when an error is detected.
This doesn't change the call made by ppc64_cpu which is using
print_smt_state=true and so is expecting a returned value equal to 0 or -1.
With that patch applied, lparstat print that in the above case:
$lparstat
System Configuration
type=Dedicated mode=Capped smt=Mixed lcpu=6 mem=65969728 kB cpus=0 ent=6.00
%user %sys %wait %idle physc %entc lbusy app vcsw phint
----- ----- ----- ----- ----- ----- ----- ----- ----- -----
0.01 0.01 0.00 99.97 3.43 57.17 0.02 0.00 4105654 156
Signed-off-by: Laurent Dufour <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 73ba26c1240a25e7699449e82cfc09dad10fed80
Author: Sathvika Vasireddy <[email protected]>
Date: Fri Dec 9 15:26:46 2022 +0530
lparstat: Fix negative values seen while running lparstat with -E option
Negative values are seen while running lparstat with -E option.
This is because delta_purr value is less than delta_idle_purr.
Given that these values are read from different sources, a
small variation in the values is possible. So, in such cases,
round down delta_idle_purr to delta_purr.
Without this patch:
=====
System Configuration
type=Dedicated mode=Capped smt=8 lcpu=240 mem=67033290112 kB cpus=0
ent=240.00
---Actual--- -Normalized-
%busy %idle Frequency %busy %idle
------ ------ ------------- ------ ------
-0.03 100.02 3.93GHz[111%] 0.01 110.97
0.00 100.00 3.93GHz[111%] 0.01 110.99
-0.04 100.03 3.93GHz[111%] 0.01 110.98
0.06 99.95 3.93GHz[111%] 0.01 110.99
0.02 99.98 3.93GHz[111%] 0.01 110.99
=====
With this patch:
=====
System Configuration
type=Dedicated mode=Capped smt=8 lcpu=240 mem=67033290112 kB cpus=0
ent=240.00
---Actual--- -Normalized-
%busy %idle Frequency %busy %idle
------ ------ ------------- ------ ------
0.03 99.96 3.93GHz[111%] 0.01 110.98
0.00 100.00 3.93GHz[111%] 0.01 110.99
0.03 99.97 3.93GHz[111%] 0.01 110.99
0.00 100.00 3.93GHz[111%] 0.01 110.99
0.09 99.90 3.93GHz[111%] 0.01 110.99
=====
Reported-by: Shirisha Ganta <[email protected]>
Signed-off-by: Sathvika Vasireddy <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
powerpc-utils-1.3.11
=====================================================================
commit fc3b6044401e5625bc825d594f8b89fda49b6596
Author: Tyrel Datwyler <[email protected]>
Date: Tue Jan 17 17:32:10 2023 -0800
ci: rev Ubuntu action runner from 20.04 -> 22.04
Move the CI runner from previous LTS release to the current LTS release.
This as the added benefit of moving the gcc-toolchain from gcc-9 to
gcc-11.
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 72b1a6e9b739382716b4c06829d3f99555be398e
Author: Tyrel Datwyler <[email protected]>
Date: Wed Jan 18 16:19:48 2023 -0800
errinjct: use PATH_MAX instead of BUFSZ
The arbitary BUFSZ macro of 4000 is less than that of PATH_MAX defined
by Linux. BUFSZ is only used for pathname buffer allocations. As such
remove BUFSZ macro and use PATH_MAX instead.
Suggested-by: Nathan Lynch <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 21b6e512edd651c1297794c1eb4c70f8adb143fc
Author: Tyrel Datwyler <[email protected]>
Date: Wed Jan 18 15:46:27 2023 -0800
errinjct: pass full device reg path to get_config_addr_from_reg()
The following string truncation error is reported by gcc-11 and gcc-12
toolchains:
In file included from /usr/powerpc-linux-gnu/include/string.h:535,
from src/errinjct/ioa_bus_error.c:34:
In function ‘strncpy’,
inlined from ‘get_config_addr_from_reg’ at src/errinjct/ioa_bus_error.c:207:2,
inlined from ‘hunt_loc_code’ at src/errinjct/ioa_bus_error.c:415:9:
Warning: /usr/powerpc-linux-gnu/include/bits/string_fortified.h:95:10: warning: ‘__builtin_strncpy’ output may be truncated copying 3995 bytes from a string of length 3999 [-Wstringop-truncation]
This is the result of the caller defining a buffer of BUFSZ, but the
callee only copying BUFSZ-5 of data into a new string so that there is
room to strcat "/reg" to the resulting pathname. We can save a strncpy
and static buffer allocation by doing the strcat of "/reg" to the
pathname before calling get_conig_addr_from_reg() which in general
appears to be inlined anyways.
Reported-by: John Paul Adrian Glaubitz <[email protected]>
Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit a540ff88416413b080e572c074e57aad362c3e50
Author: Tyrel Datwyler <[email protected]>
Date: Wed Jan 18 15:28:13 2023 -0800
serv_config: cast param to correct size before byte swap
The first two bytes of the param buffer returned by the
ibm,get-system-parameter RTAS call contain the the length of the
remaining data in the buffer. However, param is a char buffer and
as such the current code attempts to use be16toh which only gets one
byte of data. Type cast param to (uint16_t *) before the dereference to
ensure we get both bytes of data. This fixes the following string
truncation error with gcc-11 and gcc-12 toolchains:
In file included from /usr/powerpc-linux-gnu/include/string.h:535,
from src/serv_config.c:50:
In function ‘strncpy’,
inlined from ‘retrieve_value’ at src/serv_config.c:710:5:
Error: /usr/powerpc-linux-gnu/include/bits/string_fortified.h:95:10: error: ‘__builtin_strncpy’ output may be truncated copying between 0 and 255 bytes from a string of length 4997 [-Werror=stringop-truncation]
Reported-by: John Paul Adrian Glaubitz <[email protected]>
Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 73b1bdf7452e1825c797dcf708fd1b9e6b518ca5
Author: Tyrel Datwyler <[email protected]>
Date: Wed Jan 4 16:20:55 2023 -0800
configure.ac: replace deprecated AC_HELP_STRING macro
AC_HELP_STRING has been deprecated in favor of AS_HELP_STRING.
Signed-off-by: Tyrel Datwyler <[email protected]>
commit b661a2e221232c7064efa6779ac82c6f1399d0b4
Author: Tyrel Datwyler <[email protected]>
Date: Wed Jan 4 16:16:51 2023 -0800
ci: update checkout@v2 action to checkout@v3
Node.js 12 actions are deprecated. Update checkout action to v3 which
uses Node.js 16. In response to the following CI warning:
Node.js 12 actions are deprecated. For more information see:
https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/.
Please update the following actions to use Node.js 16: actions/checkout@v2
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 52df81cc1b937b235f7dbdc1dd92e38b99def1c7
Author: Nathan Lynch <[email protected]>
Date: Wed Jan 4 14:02:52 2023 -0600
configure.ac: disable -Werror by default
Enabling -Werror should be opt-in and done only in known
environments (e.g. a seldom-changing build configuration in
CI). Making -Werror the default for our build configuration causes
more pain for downstream projects than it's worth. It remains enabled
in the project CI (see previous commit).
Signed-off-by: Nathan Lynch <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 57a8c1c4de7c5de7606b15b58691d0f81aa1158b
Author: Nathan Lynch <[email protected]>
Date: Wed Jan 4 14:02:51 2023 -0600
CI: enable -Werror for builds
The CI builds all seem to be warning-free. Ensure we fail runs when
new warnings are introduced.
Signed-off-by: Nathan Lynch <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 3607e6dabdef641c363233eddd3a1cf8c2e5c6d8
Author: John Paul Adrian Glaubitz <[email protected]>
Date: Mon Dec 26 10:54:38 2022 +0100
drmgr/drslot_chrp_hea: Prefer strlen() to check for valid string length
This fixes the following warning when building with gcc-12 that is
the result of sysfs_dev_path being a fixed-sized array which means
that (char *)sysfs_dev_path never be NULL:
src/drmgr/drslot_chrp_hea.c: In function 'hotplug_port':
src/drmgr/drslot_chrp_hea.c:124:13: error: the comparison will always evaluate as 'true' for the address of 'sysfs_dev_path' will never be NULL [-Werror=address]
124 | if (! hea->sysfs_dev_path) {
| ^
In file included from src/drmgr/drpci.h:25,
from src/drmgr/rtas_calls.h:25,
from src/drmgr/dr.h:30,
from src/drmgr/drslot_chrp_hea.c:31:
src/drmgr/ofdt.h:84:25: note: 'sysfs_dev_path' declared here
84 | char sysfs_dev_path[DR_PATH_MAX];
| ^~~~~~~~~~~~~~
Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
Reviewed-by: Nathan Lynch <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 5de0a4a070981b5ee005f2242b31db5422be297a
Author: John Paul Adrian Glaubitz <[email protected]>
Date: Mon Dec 26 10:54:37 2022 +0100
drmgr/common_pci: Prefer strlen() to check for valid string length
This fixes the following warning when building with gcc-12 that is
the result of ofdt_path being a fixed-sized array which means that
(char *)ofdt_path never be NULL:
src/drmgr/common_pci.c: In function 'devspec_check_node':
src/drmgr/common_pci.c:465:29: error: the comparison will always evaluate as 'false' for the address of 'ofdt_path' will never be NULL [-Werror=address]
465 | if (node->ofdt_path == NULL)
| ^~
In file included from src/drmgr/drpci.h:25,
from src/drmgr/rtas_calls.h:25,
from src/drmgr/dr.h:30,
from src/drmgr/common_pci.c:31:
src/drmgr/ofdt.h:78:25: note: 'ofdt_path' declared here
78 | char ofdt_path[DR_PATH_MAX];
|
Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
Reviewed-by: Nathan Lynch <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit aef8f14ed8b241ab66d88fb9a5aeefe47a847267
Author: John Paul Adrian Glaubitz <[email protected]>
Date: Mon Dec 26 10:54:36 2022 +0100
vcpustat: Add missing field initialization to quell compiler warning
This fixes the following compiler warning when building with gcc-12:
In file included from /usr/include/stdio.h:906,
from src/vcpustat.c:26:
In function 'printf',
inlined from 'print_stats' at src/vcpustat.c:182:4:
/usr/include/powerpc64-linux-gnu/bits/stdio2.h:86:10: error: 'stat.far_numa_node' may be used uninitialized [-Werror=maybe-uninitialized]
86 | return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ());
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/vcpustat.c: In function 'print_stats':
src/vcpustat.c:144:34: note: 'stat.far_numa_node' was declared here
144 | struct vcpudispatch_stat stat;
| ^~~~
Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
Reviewed-by: Nathan Lynch <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 04e5c9646296e1f12048723bba4cee663c3f74ed
Author: Wen Xiong <[email protected]>
Date: Thu Dec 1 05:22:37 2022 -0600
ofpathname: Handle nsid as hex in nvmf boot/install support
Didn't handle nsid correctly in nvmf boot/install support.
Need to handle it as hexadecimal number
For example,
/pci@800000020000132/fibre-channel@0,1/nvme-of/controller@50050768101935e5,ffff
:nqn=nqn.1986-03.com.ibm:nvme:2145.0000020420006CEA/namespace@26c
26c should be a hexadecimal number.
Signed-off-by: Wen Xiong <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 3847a1c25a640394c4afd2b8938ad21190bf5dbe
Author: Wen Xiong <[email protected]>
Date: Fri Oct 28 09:20:38 2022 -0500
Support multiple dev paths for a nvmf boot device
This patch adds the support for multiple dev/of paths with a nvmf boot dev
# bootlist -m normal -o nvme1n4
nvme1n4
nvme3n4
nvme5n4
nvme6n4
# bootlist -m normal -o
nvme1n4
nvme3n4
nvme5n4
nvme6n4
# bootlist -m normal -r
/pci@800000020000017/fibre-channel@0/nvme-of/controller@50050768101935e5,ffff:nqn=nqn.1986-03.com.ibm:nvme:2145.0000020420006CEA/namespace@147
/pci@800000020000017/fibre-channel@0/nvme-of/controller@5005076810193675,ffff:nqn=nqn.1986-03.com.ibm:nvme:2145.0000020420006CEA/namespace@147
/pci@800000020000017/fibre-channel@0,1/nvme-of/controller@5005076810193675,ffff:nqn=nqn.1986-03.com.ibm:nvme:2145.0000020420006CEA/namespace@147
/pci@800000020000017/fibre-channel@0,1/nvme-of/controller@50050768101935e5,ffff:nqn=nqn.1986-03.com.ibm:nvme:2145.0000020420006CEA/namespace@147
Signed-off-by: Wen Xiong <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit acaf9c45a340f9bb49d6b21ba7ad60c21326ea73
Author: Mingming Cao <[email protected]>
Date: Mon Nov 7 14:39:02 2022 -0800
hcnmgr: Fix setting primary slave across reboots
Using nmcli to set bonding of primary slave so that is set correctly
across reboots.
Signed-off-by: Mingming Cao <[email protected]>
[tyreld: Reworded commit log]
Signed-off-by: Tyrel Datwyler <[email protected]>
commit b6bd4ddd0c0a24cce97c220ab0cadfd004dd58c4
Author: Sathvika Vasireddy <[email protected]>
Date: Fri Jul 15 14:35:13 2022 +0530
lparstat: Fix array overflow issue
lparstat is trying to read from out of bound file descriptors. Fix
this by making sure array overflow does not occur.
Without this patch:
===================================================================
ltcden8-lp7:/home/sathvika/powerpc-utils # lparstat -E 1 1
Failed to /sys/devices/system/cpu/cpu1162167776/spurr
===================================================================
With this patch:
===================================================================
ltcden8-lp7:/home/sathvika/powerpc-utils # ./src/lparstat -E 1 1
System Configuration
type=Dedicated mode=Capped smt=8 lcpu=6 mem=81341376 kB cpus=0 ent=6.00
---Actual--- -Normalized-
%busy %idle Frequency %busy %idle
------ ------ ------------- ------ ------
0.01 99.99 4.00GHz[116%] 0.02 115.98
====================================================================
Reported-by: Sachin Sant <[email protected]>
Signed-off-by: Sathvika Vasireddy <[email protected]>
Tested-by: Sachin Sant <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit b1b9e76de0f3ab1dfcd9426779fa20fd77cd5625
Author: Luciano Chavez <[email protected]>
Date: Wed Aug 24 21:11:32 2022 -0500
lsslot: Fix lsslot -c mem output when using 4GB LMB size
When using a LMB size of 4GB, the output of lsslot -c mem would get
reported incorrectly as:
Dynamic Reconfiguration Memory (LMB size 0x0)
:
DRC Index: 80000001 Address: 100000000
Removable: No Associativity: (index: 1) 0 1 4 9
Section(s):
This patch changes the declaration of the _node_u._smem._lmb_size from
a uint32_t to uint64_t to store the value properly. Any variables that
store the lmb_size are also declared as uint64_t. In addition, we
use the PRIx64 macro in printf statements to properly print the
lmb_size value.
The patch also includes a necessary change to declare the global
variable block_sz_bytes as a uint64_t to fix an infinite loop in
the function get_mem_scns() when the above changes were introduced.
Signed-off-by: Luciano Chavez <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit e1f1deb06d9168a95a381a2236e1d8c693d3d229
Author: Luciano Chavez <[email protected]>
Date: Wed Aug 24 21:17:54 2022 -0500
lsslot: Explicity declare that lmb_address be displayed in hexadecimal
A printf statement used is lsslot.c was specifying the macro PRIu64 to
display the lmb_address. Depending on the compilation, this would
either display as a hexadecimal or decimal value.
This patch replaces PRIu64 with PRIx64 to explicitly declare to print
the value as hexadecimal as that was is normally expected of an address.
Signed-off-by: Luciano Chavez <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit f4c2b0d142f623e7dd28a5d685e446d41be75601
Author: Naveen N. Rao <[email protected]>
Date: Thu Aug 25 12:19:27 2022 +0530
lparstat: Fix display of mode for dedicated-donating partition
From the lparstat man page:
mode
Indicates whether the partition processor capacity is capped or uncapped
allowing it to consume idle cycles from the shared pool. Dedicated LPAR
is capped or donating.
However, on a dedicated partition, lparstat always displays the mode as
'Capped' today. Fix this by using 'DedDonMode' field from lparcfg for
determining the cycle donation status of a dedicated partition.
On a dedicated-donating partition:
$ grep -e shared -e DedDonMode -e capped /proc/powerpc/lparcfg
DedDonMode=1
capped=1
shared_processor_mode=0
Before this patch:
$ lparstat
System Configuration
type=Dedicated mode=Capped smt=8 lcpu=1 mem=3335424 kB cpus=0 ent=1.00
After this patch:
$ lparstat
System Configuration
type=Dedicated mode=Donating smt=8 lcpu=1 mem=3335424 kB cpus=0 ent=1.00
Signed-off-by: Naveen N. Rao <[email protected]>
Reviewed-by: Nathan Lynch <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit 7698adc945372e901c2bc3f7066a5a1c219bf1d8
Author: Laurent Dufour <[email protected]>
Date: Fri Sep 16 18:39:18 2022 +0200
drmgr: add the drmgr-hooks man file.
This man page describe the various drmgr's hooks.
Signed-off-by: Laurent Dufour <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit d0bc79aedaf76eff09a5d1f399da09561a4d4d7d
Author: Laurent Dufour <[email protected]>
Date: Fri Sep 16 18:39:17 2022 +0200
drmgr: introducing the LPM hooks
There are 3 hooks run when an LPM is performed:
1. check before the LPM is really initiated
1 bis. undocheck if check failed.
2. pre just before entering the switch over
3. post at the end of the LPM operation
Only the check hook's return status is taken in account. If the check hook
return value is different from 0, the LPM is aborted and the outputs of the
check hook are reported to the end user through the HMC.
In the case at least one check hook returned a non zero status, the
undocheck event is run (for all the hooks), and the pre and post events are
not triggered.
The post event is triggered even if the LPM operation has failed.
Signed-off-by: Laurent Dufour <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
commit e0928dc5e5375591a4cff6ffabc6063771288f59
Author: Laurent Dufour <[email protected]>
Date: Fri Sep 16 18:39:16 2022 +0200
drmgr: introducing the hook framework
The hook framework run in a sequence any executable file found in the
relevant directory (/etc/drmgr.d/<DRC TYPE NAME>/)
The hook are run according to the versionsort()'s output order.
The hook inherits from drmgr its standard I/O streams. All others file
descriptor should have the close on exec flag set to ensure they will be
closed when executing an hook.