Hello Alan,
On 16. 03. 24 21:35, Alan Stern wrote:
> Below is a patch meant to get the number of resets back to what it
> should be. I'd appreciate it if you can test this, and report the
> kernel log output along with the usbmon output for the normal case and
> also with the "old_scheme_first" parameter set.
>
> I'm not very hopeful that this will solve the problem, but there's a
> good chance it will help point us in the right direction by removing
> extraneous complications.
unfortunately you were right, the problem is still unresolved with your
patch. I hope the traces will provide some new insights then.
Regards
Jan
###############################
# Patched - new scheme (6.6.21)
###############################
[ 149.638997] usb 1-1.2: new full-speed USB device number 8 using ehci-pci
[ 149.640602] usb 1-1.2: device descriptor read/64, error -32
[ 149.811493] usb 1-1.2: device descriptor read/64, error -32
[ 149.986051] usb 1-1.2: new full-speed USB device number 9 using ehci-pci
[ 149.987370] usb 1-1.2: device descriptor read/64, error -32
[ 150.163337] usb 1-1.2: device descriptor read/64, error -32
[ 150.266422] usb 1-1-port2: attempt power cycle
[ 150.750045] usb 1-1.2: new full-speed USB device number 10 using ehci-pci
[ 151.162030] usb 1-1.2: device not accepting address 10, error -32
[ 151.430029] usb 1-1.2: new full-speed USB device number 11 using ehci-pci
[ 151.445492] usb 1-1.2: device descriptor read/8, error -32
[ 151.633637] usb 1-1.2: device descriptor read/8, error -32
[ 151.739227] usb 1-1-port2: unable to enumerate USB device
ffff8881003dc9c0 149518477 C Ii:1:002:1 0:2048 1 = 04
ffff8881003dc9c0 149518517 S Ii:1:002:1 -115:2048 1 <
ffff888139ff8480 149518558 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888139ff8480 149518935 C Ci:1:002:0 0 4 = 01010100
ffff888139ff8480 149518951 S Co:1:002:0 s 23 01 0010 0002 0000 0
ffff888139ff8480 149519199 C Co:1:002:0 0 0
ffff888139ff8480 149519229 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888139ff8480 149519467 C Ci:1:002:0 0 4 = 01010000
ffff888139ff8480 149546106 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888139ff8480 149546393 C Ci:1:002:0 0 4 = 01010000
ffff888139ff8480 149573113 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888139ff8480 149573442 C Ci:1:002:0 0 4 = 01010000
ffff888139ff8480 149600103 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888139ff8480 149600309 C Ci:1:002:0 0 4 = 01010000
ffff888139ff8480 149627105 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888139ff8480 149627441 C Ci:1:002:0 0 4 = 01010000
ffff888139ff8480 149627495 S Co:1:002:0 s 23 03 0004 0002 0000 0
ffff888139ff8480 149627699 C Co:1:002:0 0 0
ffff888139ff8480 149639104 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888139ff8480 149639364 C Ci:1:002:0 0 4 = 03011000
ffff888139ff8480 149639401 S Co:1:002:0 s 23 01 0014 0002 0000 0
ffff888139ff8480 149639619 C Co:1:002:0 0 0
ffff888139ff8480 149691082 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
ffff888139ff8480 149691572 C Ci:1:000:0 -32 0
ffff8881419950c0 149691656 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
ffff8881419950c0 149691905 C Ci:1:000:0 -32 0
ffff8881419950c0 149691917 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
ffff8881419950c0 149692565 C Ci:1:000:0 -32 0
ffff8881419950c0 149798110 S Co:1:002:0 s 23 03 0004 0002 0000 0
ffff8881419950c0 149798431 C Co:1:002:0 0 0
ffff8881419950c0 149810115 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff8881419950c0 149810401 C Ci:1:002:0 0 4 = 03011000
ffff8881419950c0 149810427 S Co:1:002:0 s 23 01 0014 0002 0000 0
ffff8881419950c0 149810864 C Co:1:002:0 0 0
ffff8881419950c0 149862123 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
ffff8881419950c0 149862618 C Ci:1:000:0 -32 0
ffff8881419950c0 149862653 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
ffff8881419950c0 149863135 C Ci:1:000:0 -32 0
ffff8881419950c0 149863165 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
ffff8881419950c0 149863534 C Ci:1:000:0 -32 0
ffff8881419950c0 149974112 S Co:1:002:0 s 23 01 0001 0002 0000 0
ffff8881419950c0 149974320 C Co:1:002:0 0 0
ffff888141995000 149974393 S Co:1:002:0 s 23 03 0004 0002 0000 0
ffff888141995000 149974575 C Co:1:002:0 0 0
ffff888141995000 149986107 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888141995000 149986437 C Ci:1:002:0 0 4 = 03011000
ffff888141995000 149986471 S Co:1:002:0 s 23 01 0014 0002 0000 0
ffff888141995000 149986696 C Co:1:002:0 0 0
ffff888141995000 150038142 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
ffff888141995000 150038648 C Ci:1:000:0 -32 0
ffff888141995000 150038672 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
ffff888141995000 150039032 C Ci:1:000:0 -32 0
ffff888141995000 150039046 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
ffff888141995000 150039358 C Ci:1:000:0 -32 0
ffff888141995000 150150113 S Co:1:002:0 s 23 03 0004 0002 0000 0
ffff888141995000 150150417 C Co:1:002:0 0 0
ffff888141995000 150162111 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888141995000 150162387 C Ci:1:002:0 0 4 = 03011000
ffff888141995000 150162418 S Co:1:002:0 s 23 01 0014 0002 0000 0
ffff888141995000 150162648 C Co:1:002:0 0 0
ffff888141995000 150214119 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
ffff888141995000 150214598 C Ci:1:000:0 -32 0
ffff888141995000 150214632 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
ffff888141995000 150214912 C Ci:1:000:0 -32 0
ffff888141995000 150214930 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
ffff888141995000 150215314 C Ci:1:000:0 -32 0
ffff888141995000 150318106 S Co:1:002:0 s 23 01 0001 0002 0000 0
ffff888141995000 150318446 C Co:1:002:0 0 0
ffff8881419950c0 150318517 S Co:1:002:0 s 23 01 0008 0002 0000 0
ffff8881419950c0 150318704 C Co:1:002:0 0 0
ffff8881419950c0 150526102 S Co:1:002:0 s 23 03 0008 0002 0000 0
ffff8881419950c0 150526430 C Co:1:002:0 0 0
ffff8881003dc9c0 150542516 C Ii:1:002:1 0:2048 1 = 04
ffff8881003dc9c0 150542548 S Ii:1:002:1 -115:2048 1 <
ffff8881419950c0 150630112 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff8881419950c0 150630417 C Ci:1:002:0 0 4 = 01010100
ffff8881419950c0 150630450 S Co:1:002:0 s 23 01 0010 0002 0000 0
ffff8881419950c0 150630685 C Co:1:002:0 0 0
ffff8881419950c0 150657105 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff8881419950c0 150657423 C Ci:1:002:0 0 4 = 01010000
ffff888141995000 150684024 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888141995000 150684290 C Ci:1:002:0 0 4 = 01010000
ffff888141995000 150711108 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888141995000 150711365 C Ci:1:002:0 0 4 = 01010000
ffff888141995000 150738112 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888141995000 150738437 C Ci:1:002:0 0 4 = 01010000
ffff888141995000 150738494 S Co:1:002:0 s 23 03 0004 0002 0000 0
ffff888141995000 150738692 C Co:1:002:0 0 0
ffff888141995000 150750108 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888141995000 150750364 C Ci:1:002:0 0 4 = 03011000
ffff888141995000 150750399 S Co:1:002:0 s 23 01 0014 0002 0000 0
ffff888141995000 150750621 C Co:1:002:0 0 0
ffff888141995000 150802147 S Co:1:000:0 s 00 05 000a 0000 0000 0
ffff888141995000 150802527 C Co:1:000:0 -32 0
ffff888141995000 151006106 S Co:1:000:0 s 00 05 000a 0000 0000 0
ffff888141995000 151006560 C Co:1:000:0 -32 0
ffff8881003dc9c0 151054453 C Ii:1:002:1 0:2048 1 = 04
ffff8881003dc9c0 151054467 S Ii:1:002:1 -115:2048 1 <
ffff888141995000 151215694 S Co:1:002:0 s 23 01 0001 0002 0000 0
ffff888141995000 151216068 C Co:1:002:0 0 0
ffff888141995180 151216115 S Co:1:002:0 s 23 03 0004 0002 0000 0
ffff888141995180 151216315 C Co:1:002:0 0 0
ffff888141995180 151228102 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888141995180 151228380 C Ci:1:002:0 0 4 = 03011100
ffff888141995180 151228417 S Co:1:002:0 s 23 01 0010 0002 0000 0
ffff888141995180 151228638 C Co:1:002:0 0 0
ffff888141995180 151228664 S Co:1:002:0 s 23 03 0004 0002 0000 0
ffff888141995180 151228899 C Co:1:002:0 0 0
ffff8881003dc9c0 151310482 C Ii:1:002:1 0:2048 1 = 04
ffff8881003dc9c0 151310497 S Ii:1:002:1 -115:2048 1 <
ffff888141995180 151430108 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888141995180 151430419 C Ci:1:002:0 0 4 = 03011000
ffff888141995180 151430455 S Co:1:002:0 s 23 01 0014 0002 0000 0
ffff888141995180 151430693 C Co:1:002:0 0 0
ffff888141995180 151482140 S Co:1:000:0 s 00 05 000b 0000 0000 0
ffff888141995180 151482405 C Co:1:000:0 0 0
ffff888141995000 151496106 S Ci:1:011:0 s 80 06 0100 0000 0008 8 <
ffff888141995000 151496622 C Ci:1:011:0 -32 0
ffff888141995000 151496658 S Ci:1:011:0 s 80 06 0100 0000 0008 8 <
ffff888141995000 151497138 C Ci:1:011:0 -32 0
ffff888141995000 151497169 S Ci:1:011:0 s 80 06 0100 0000 0008 8 <
ffff888141995000 151497486 C Ci:1:011:0 -32 0
ffff888141995000 151606108 S Co:1:002:0 s 23 03 0004 0002 0000 0
ffff888141995000 151606374 C Co:1:002:0 0 0
ffff888141995000 151618105 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888141995000 151618344 C Ci:1:002:0 0 4 = 03011000
ffff888141995000 151618379 S Co:1:002:0 s 23 01 0014 0002 0000 0
ffff888141995000 151618599 C Co:1:002:0 0 0
ffff888141995000 151670136 S Co:1:000:0 s 00 05 000b 0000 0000 0
ffff888141995000 151670488 C Co:1:000:0 0 0
ffff888141995180 151684039 S Ci:1:011:0 s 80 06 0100 0000 0008 8 <
ffff888141995180 151684454 C Ci:1:011:0 -32 0
ffff888141995180 151684532 S Ci:1:011:0 s 80 06 0100 0000 0008 8 <
ffff888141995180 151684785 C Ci:1:011:0 -32 0
ffff888141995180 151684834 S Ci:1:011:0 s 80 06 0100 0000 0008 8 <
ffff888141995180 151685618 C Ci:1:011:0 -32 0
ffff888141995180 151791035 S Co:1:002:0 s 23 01 0001 0002 0000 0
ffff888141995180 151791290 C Co:1:002:0 0 0
ffff888141995000 151792277 S Co:1:002:0 s 23 01 0001 0002 0000 0
ffff888141995000 151792534 C Co:1:002:0 0 0
ffff888141995000 151792564 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888141995000 151792796 C Ci:1:002:0 0 4 = 01010000
###############################
# Patched - old scheme (6.6.21)
###############################
[ 272.774542] usb 1-1.2: new full-speed USB device number 12 using ehci-pci
[ 273.185546] usb 1-1.2: device not accepting address 12, error -32
[ 273.251550] usb 1-1.2: new full-speed USB device number 13 using ehci-pci
[ 273.665491] usb 1-1.2: device not accepting address 13, error -32
[ 273.667236] usb 1-1-port2: attempt power cycle
[ 274.203558] usb 1-1.2: new full-speed USB device number 14 using ehci-pci
[ 274.283841] usb 1-1.2: New USB device found, idVendor=0658,
idProduct=0200, bcdDevice= 0.00
[ 274.283867] usb 1-1.2: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 274.309310] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[ 274.309355] usbcore: registered new interface driver cdc_acm
[ 274.309357] cdc_acm: USB Abstract Control Model driver for USB modems
and ISDN adapters
ffff8881003dc9c0 272654268 C Ii:1:002:1 0:2048 1 = 04
ffff8881003dc9c0 272654316 S Ii:1:002:1 -115:2048 1 <
ffff888145ae1780 272654483 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 272654726 C Ci:1:002:0 0 4 = 01010100
ffff888145ae1780 272654739 S Co:1:002:0 s 23 01 0010 0002 0000 0
ffff888145ae1780 272654993 C Co:1:002:0 0 0
ffff888145ae1780 272655020 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 272655255 C Ci:1:002:0 0 4 = 01010000
ffff888145ae1780 272682096 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 272682378 C Ci:1:002:0 0 4 = 01010000
ffff888145ae1780 272709128 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 272709311 C Ci:1:002:0 0 4 = 01010000
ffff888145ae1780 272736109 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 272736445 C Ci:1:002:0 0 4 = 01010000
ffff888145ae1780 272763140 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 272763338 C Ci:1:002:0 0 4 = 01010000
ffff888145ae1780 272763393 S Co:1:002:0 s 23 03 0004 0002 0000 0
ffff888145ae1780 272763595 C Co:1:002:0 0 0
ffff888145ae1780 272775074 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 272775275 C Ci:1:002:0 0 4 = 03011000
ffff888145ae1780 272775314 S Co:1:002:0 s 23 01 0014 0002 0000 0
ffff888145ae1780 272775729 C Co:1:002:0 0 0
ffff888145ae1780 272827142 S Co:1:000:0 s 00 05 000c 0000 0000 0
ffff888145ae1780 272827417 C Co:1:000:0 -32 0
ffff888145ae1780 273030123 S Co:1:000:0 s 00 05 000c 0000 0000 0
ffff888145ae1780 273030664 C Co:1:000:0 -32 0
ffff888145ae1780 273239645 S Co:1:002:0 s 23 01 0001 0002 0000 0
ffff888145ae1780 273239905 C Co:1:002:0 0 0
ffff888145ae1d80 273239949 S Co:1:002:0 s 23 03 0004 0002 0000 0
ffff888145ae1d80 273240163 C Co:1:002:0 0 0
ffff888145ae1d80 273252126 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1d80 273252423 C Ci:1:002:0 0 4 = 03011000
ffff888145ae1d80 273252447 S Co:1:002:0 s 23 01 0014 0002 0000 0
ffff888145ae1d80 273252680 C Co:1:002:0 0 0
ffff888145ae1d80 273304146 S Co:1:000:0 s 00 05 000d 0000 0000 0
ffff888145ae1d80 273304402 C Co:1:000:0 -32 0
ffff888145ae1d80 273510101 S Co:1:000:0 s 00 05 000d 0000 0000 0
ffff888145ae1d80 273510377 C Co:1:000:0 -32 0
ffff888145ae1d80 273719545 S Co:1:002:0 s 23 01 0001 0002 0000 0
ffff888145ae1d80 273719772 C Co:1:002:0 0 0
ffff888145ae1780 273719812 S Co:1:002:0 s 23 01 0008 0002 0000 0
ffff888145ae1780 273720047 C Co:1:002:0 0 0
ffff888145ae1780 273926112 S Co:1:002:0 s 23 03 0008 0002 0000 0
ffff888145ae1780 273926406 C Co:1:002:0 0 0
ffff8881003dc9c0 273934050 C Ii:1:002:1 0:2048 1 = 04
ffff8881003dc9c0 273934081 S Ii:1:002:1 -115:2048 1 <
ffff888145ae1780 274030115 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 274030418 C Ci:1:002:0 0 4 = 01010100
ffff888145ae1780 274030442 S Co:1:002:0 s 23 01 0010 0002 0000 0
ffff888145ae1780 274030677 C Co:1:002:0 0 0
ffff888145ae1780 274057089 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 274057416 C Ci:1:002:0 0 4 = 01010000
ffff888145ae1780 274084090 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 274084322 C Ci:1:002:0 0 4 = 01010100
ffff888145ae1780 274084353 S Co:1:002:0 s 23 01 0010 0002 0000 0
ffff888145ae1780 274084578 C Co:1:002:0 0 0
ffff888145ae1780 274111090 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 274111317 C Ci:1:002:0 0 4 = 01010000
ffff888145ae1780 274138114 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 274138418 C Ci:1:002:0 0 4 = 01010000
ffff888145ae1780 274165108 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 274165350 C Ci:1:002:0 0 4 = 01010000
ffff888145ae1780 274192122 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 274192263 C Ci:1:002:0 0 4 = 01010000
ffff888145ae1780 274192320 S Co:1:002:0 s 23 03 0004 0002 0000 0
ffff888145ae1780 274192521 C Co:1:002:0 0 0
ffff888145ae1780 274204052 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 274204382 C Ci:1:002:0 0 4 = 03011000
ffff888145ae1780 274204405 S Co:1:002:0 s 23 01 0014 0002 0000 0
ffff888145ae1780 274204652 C Co:1:002:0 0 0
ffff888145ae1780 274256143 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
ffff888145ae1780 274256517 C Ci:1:000:0 0 8 = 12010002 02000008
ffff888145ae1780 274256546 S Co:1:002:0 s 23 03 0004 0002 0000 0
ffff888145ae1780 274256743 C Co:1:002:0 0 0
ffff888145ae1780 274268088 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1780 274268362 C Ci:1:002:0 0 4 = 03011000
ffff888145ae1780 274268388 S Co:1:002:0 s 23 01 0014 0002 0000 0
ffff888145ae1780 274268618 C Co:1:002:0 0 0
ffff888145ae1780 274320112 S Co:1:000:0 s 00 05 000e 0000 0000 0
ffff888145ae1780 274320449 C Co:1:000:0 0 0
ffff888145ae1d80 274334110 S Ci:1:014:0 s 80 06 0100 0000 0012 18 <
ffff888145ae1d80 274334545 C Ci:1:014:0 0 18 = 12010002 02000008
58060002 00000000 0001
ffff888145ae1d80 274334577 S Ci:1:014:0 s 80 06 0600 0000 000a 10 <
ffff888145ae1d80 274334813 C Ci:1:014:0 -32 0
ffff888145ae1d80 274334843 S Ci:1:014:0 s 80 06 0600 0000 000a 10 <
ffff888145ae1d80 274335150 C Ci:1:014:0 -32 0
ffff888145ae1d80 274335168 S Ci:1:014:0 s 80 06 0600 0000 000a 10 <
ffff888145ae1d80 274335581 C Ci:1:014:0 -32 0
ffff888145ae1d80 274335610 S Ci:1:014:0 s 80 06 0200 0000 0009 9 <
ffff888145ae1d80 274335914 C Ci:1:014:0 0 9 = 09024300 02010080 32
ffff888145ae1d80 274335932 S Ci:1:014:0 s 80 06 0200 0000 0043 67 <
ffff888145ae1d80 274336373 C Ci:1:014:0 0 67 = 09024300 02010080
32090400 00010202 01000524 00100105 24010001 04240200
ffff888145ae1900 274336803 S Co:1:014:0 s 00 09 0001 0000 0000 0
ffff888145ae1900 274337062 C Co:1:014:0 0 0
ffff888145ae1900 274340120 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff888145ae1900 274340243 C Ci:1:002:0 0 4 = 03010000
ffff888121658a80 274361461 S Co:1:014:0 s 21 20 0000 0000 0007 7 =
80250000 000008
ffff888121658a80 274361751 C Co:1:014:0 0 7 >
On 08.03.24 11:07, bumyong.lee wrote: > >> Hmmm. 6.8 final is due. Is that something we can live with? Or would it be >> a good idea to revert above commit for now and reapply it when something >> better emerged? I doubt that the answer is "yes, let's do that", but I >> have to ask. > > I couldn't find better way now. > I think it's better to follow you mentioned 6.8 is out, but that issue afaics was not resolved, so allow me to ask: did "submit a revert" fell through the cracks or is there some other solution in the works? Or am I missing something? Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page. #regzbot poke
On 09.03.24 11:18, Thorsten Leemhuis wrote: > Hi! This is the start of a thread I'll use for updating minor properties > of regressions tracked by regzbot. Consider telling your mailer to > ignore this thread, the replies are unlikely to be of relevance for you, > but done here to ensure a public paper trail. #regzbot report: https://lore.kernel.org/all/20240314084412.1127-1-johan%2Blinaro@kernel.org/ #regzbot introduced: 7dcd3e014aa7 #regzbot title: Bluetooth: Lenovo ThinkPad X13s broken #regzbot fix: Revert "Bluetooth: hci_qca: Set BDA quirk bit if fwnode exists in DT" #regzbot report: https://bugzilla.kernel.org/show_bug.cgi?id=218587 #regzbot introduced: 4d0c8d0aef63 #regzbot title: mmc core block.c: optee/fTPM access to RPMB via tee-supplicant broken #regzbot relate: https://lore.kernel.org/linux-mmc/20240313133744.2405325-1-mikko.rapeli@linaro.org/ #regzbot report: https://lore.kernel.org/regressions/ZeoAPFIF6NClUl4P@debian.local/ #regzbot duplicate: https://gitlab.freedesktop.org/drm/misc/kernel/-/issues/36 #regzbot fix: 9cbd1dae842737bfafa4b
On 16.03.24 17:12, Martin Steigerwald wrote: > Martin Steigerwald - 16.03.24, 17:02:44 CET: >> ThinkPad T14 AMD Gen 1 fails to hibernate with self-compiled 6.8.1. >> Hibernation works correctly with self-compiled 6.7.9. > > Apparently 6.8.1 does not even reboot correctly anymore. runit on Devuan. > It says it is doing the system reboot but then nothing happens. > > As for hibernation the kernel cancels the attempt and returns back to > user space desktop session. > >> Trying to use "no_console_suspend" to debug next. Will not do bisect >> between major kernel releases on a production machine. FWIW, without a bisection I guess no developer will take a closer look (but I might be wrong and you lucky here!), as any change in those hundreds of drivers used on that machine can possibly lead to problems like yours. So without a bisection we are likely stuck here, unless someone else runs into the same problem and bisects or fixes it. Sorry, but that's just how it is. > [...] Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
On 18.03.24 16:32, Guenter Roeck wrote: > On 3/18/24 08:04, Linux regression tracking (Thorsten Leemhuis) wrote: >> On 11.03.24 18:04, Guenter Roeck wrote: >>> On Sat, Feb 10, 2024 at 07:12:39AM -0800, Guenter Roeck wrote: >>>> >>>> when running checksum unit tests on sh4 qemu emulations, I get the >>>> following >>>> errors. >>> >>> Adding to regression tracker. >>> >>> #regzbot ^introduced cadc4e1a2b4d2 >> >> Hmmm, thx for that, but well, I'm a bit taken back and forth here. That >> commit afaics is from v3.0-rc1 and Linus iirc at least once said >> something along the lines of "a regression only reported after a long >> time at some point becomes just a bug". I'd say that applies there, >> which is why I'm wondering if tracking this really is worth it. > > Not my call to make. I'll keep in mind to not add "bugs" to the regression > tracker in the future. From my side there is no need for you to keep that in mind, as "somewhat added this regression to the tracking" might be something that will occasionally make a developer finally fix the problem -- which is why I waited a few days with today's reply. :-D > Feel free to drop. Let me do that: #regzbot inconclusive: really old regression > For my understanding, what is "a long time" ? That is a good question and I guess the answer like so often in kernel land depends on the regression in question. :-/ Also note that that "iirc" really was meant like it, as I might misremember. I just checked and found two related quotes, but the situations are somewhat different: https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/ """ And yes, I do consider "regression in an earlier release" to be a regression that needs fixing. There's obviously a time limit: if that "regression in an earlier release" was a year or more ago, and just took forever for people to notice, and it had semantic changes that now mean that fixing the regression could cause a _new_ regression, then that can cause me to go "Oh, now the new semantics are what we have to live with". """ And also: https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/ """ And obviously, if users take years to even notice that something broke, or if we have sane ways to work around the breakage that doesn't make for too much trouble for users (ie "ok, there are a handful of users, and they can use a kernel command line to work around it" kind of things) we've also been a bit less strict. """ Ciao, Thorsten
On 3/18/24 08:04, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 11.03.24 18:04, Guenter Roeck wrote:
>> On Sat, Feb 10, 2024 at 07:12:39AM -0800, Guenter Roeck wrote:
>>>
>>> when running checksum unit tests on sh4 qemu emulations, I get the following
>>> errors.
>>
>> Adding to regression tracker.
>>
>> #regzbot ^introduced cadc4e1a2b4d2
>
> Hmmm, thx for that, but well, I'm a bit taken back and forth here. That
> commit afaics is from v3.0-rc1 and Linus iirc at least once said
> something along the lines of "a regression only reported after a long
> time at some point becomes just a bug". I'd say that applies there,
> which is why I'm wondering if tracking this really is worth it.
>
Not my call to make. I'll keep in mind to not add "bugs" to the regression
tracker in the future. Feel free to drop.
For my understanding, what is "a long time" ?
Thanks,
Guenter
On 11.03.24 18:04, Guenter Roeck wrote: > On Sat, Feb 10, 2024 at 07:12:39AM -0800, Guenter Roeck wrote: >> >> when running checksum unit tests on sh4 qemu emulations, I get the following >> errors. > > Adding to regression tracker. > > #regzbot ^introduced cadc4e1a2b4d2 Hmmm, thx for that, but well, I'm a bit taken back and forth here. That commit afaics is from v3.0-rc1 and Linus iirc at least once said something along the lines of "a regression only reported after a long time at some point becomes just a bug". I'd say that applies there, which is why I'm wondering if tracking this really is worth it. Ciao, Thorsten >> KTAP version 1 >> # Subtest: checksum >> # module: checksum_kunit >> 1..5 >> # test_csum_fixed_random_inputs: ASSERTION FAILED at lib/checksum_kunit.c:500 >> Expected ( u64)result == ( u64)expec, but >> ( u64)result == 53378 (0xd082) >> ( u64)expec == 33488 (0x82d0) >> not ok 1 test_csum_fixed_random_inputs >> # test_csum_all_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:525 >> Expected ( u64)result == ( u64)expec, but >> ( u64)result == 65281 (0xff01) >> ( u64)expec == 65280 (0xff00) >> not ok 2 test_csum_all_carry_inputs >> # test_csum_no_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:573 >> Expected ( u64)result == ( u64)expec, but >> ( u64)result == 65535 (0xffff) >> ( u64)expec == 65534 (0xfffe) >> not ok 3 test_csum_no_carry_inputs >> ok 4 test_ip_fast_csum >> ok 5 test_csum_ipv6_magic >> # checksum: pass:2 fail:3 skip:0 total:5 >> >> The above is with from a little endian system. On a big endian system, >> the test result is as follows. >> >> KTAP version 1 >> # Subtest: checksum >> # module: checksum_kunit >> 1..5 >> # test_csum_fixed_random_inputs: ASSERTION FAILED at lib/checksum_kunit.c:500 >> Expected ( u64)result == ( u64)expec, but >> ( u64)result == 33488 (0x82d0) >> ( u64)expec == 53378 (0xd082) >> not ok 1 test_csum_fixed_random_inputs >> # test_csum_all_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:525 >> Expected ( u64)result == ( u64)expec, but >> ( u64)result == 65281 (0xff01) >> ( u64)expec == 255 (0xff) >> not ok 2 test_csum_all_carry_inputs >> # test_csum_no_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:565 >> Expected ( u64)result == ( u64)expec, but >> ( u64)result == 1020 (0x3fc) >> ( u64)expec == 0 (0x0) >> not ok 3 test_csum_no_carry_inputs >> # test_ip_fast_csum: ASSERTION FAILED at lib/checksum_kunit.c:589 >> Expected ( u64)expected == ( u64)csum_result, but >> ( u64)expected == 55939 (0xda83) >> ( u64)csum_result == 33754 (0x83da) >> not ok 4 test_ip_fast_csum >> # test_csum_ipv6_magic: ASSERTION FAILED at lib/checksum_kunit.c:617 >> Expected ( u64)expected_csum_ipv6_magic[i] == ( u64)csum_ipv6_magic(saddr, daddr, len, proto, csum), but >> ( u64)expected_csum_ipv6_magic[i] == 6356 (0x18d4) >> ( u64)csum_ipv6_magic(saddr, daddr, len, proto, csum) == 43586 (0xaa42) >> not ok 5 test_csum_ipv6_magic >> # checksum: pass:0 fail:5 skip:0 total:5 >> >> Note that test_ip_fast_csum and test_csum_ipv6_magic fail on all big endian >> systems due to a bug in the test code, unrelated to this problem. >> >> Analysis shows that the errors are seen only if the buffer is misaligned. >> Looking into arch/sh/lib/checksum.S, I found commit cadc4e1a2b4d2 ("sh: >> Handle calling csum_partial with misaligned data") which seemed to be >> related. Reverting that commit fixes the problem. >> This suggests that something may be wrong with that commit. Alternatively, >> of course, it may be possible that something is wrong with the qemu >> emulation, but that seems unlikely. >> >> Thanks, >> Guenter
On 11.03.24 19:21, Petr Tesařík wrote: > On Mon, 11 Mar 2024 18:43:59 +0100 > Eric Dumazet <edumazet@google.com> wrote: >> On Mon, Mar 11, 2024 at 6:25 PM Petr Tesařík <petr@tesarici.cz> wrote: >>> On Wed, 6 Mar 2024 12:11:57 +0100 >>> Petr Tesarik <petr@tesarici.cz> wrote: >>> >>>> Fix bogus lockdep warnings if multiple u64_stats_sync variables are >>>> initialized in the same file. >>>> >>>> With CONFIG_LOCKDEP, seqcount_init() is a macro which declares: >>>> >>>> static struct lock_class_key __key; >>>> >>>> Since u64_stats_init() is a function (albeit an inline one), all calls >>>> within the same file end up using the same instance, effectively treating >>>> them all as a single lock-class. >>> What happens with this fix now? >>> >>> IIUC it should be reviewed by Eric, but I don't know through which tree >>> it should be merged. Any plans yet? >> >> I thought I gave a reply, but apparently not . >> >> Reviewed-by: Eric Dumazet <edumazet@google.com> > > Thank you! Great. Just wondering, as there afaics was no activity since about one week: what is the plan forward here? Is the "through which tree it should be merged" question still unresolved? I quickly looked and it seems two of the last tree changes to that file over the past years went through net-next (the other one through the tip tree). That's why I CCed the other two net maintainers and the net list now. Or is the plan to merge this after the merge window? Or only merge it for 6.10, as it are bogus lockdep warnings that are being fixed? Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page. #regzbot poke
On Mon, 18 Mar 2024 at 14:14, Radek Podgorny <radek@podgorny.cz> wrote: > > hello ard, > > so, i have some bad news. unfortunately, none of the suggested changes > resolves the issue. :-( > ... except reverting the patch that you bisected the regression to, right? > the last two patches still lead to boot-stuck system. > What does 'boot-stuck' mean? Please provide as much context as you can. More is more. > overall, the patches only make the difference in error being printed: > sometimes it's something like "wrong padding", Can you share the entire, exact error message? > sometimes the "invalid > magic" message. i only noticed later so i can't really tell which patch > leads to which message but i can retry them all and tell you exactly if > it helps. > Yes, please. > anyway, if you have any other patches, i'll be more than happy to test > them out (and be more careful about the message this time)! > We should be able to narrow down why that one particular change causes the issue. I can split the change in question into smaller ones to see which exact change triggers the failure. And many thanks for taking the time - I really want to figure out what is happening here.
[-- Attachment #1.1: Type: text/plain, Size: 1014 bytes --] hello ard, so, i have some bad news. unfortunately, none of the suggested changes resolves the issue. :-( the last two patches still lead to boot-stuck system. overall, the patches only make the difference in error being printed: sometimes it's something like "wrong padding", sometimes the "invalid magic" message. i only noticed later so i can't really tell which patch leads to which message but i can retry them all and tell you exactly if it helps. anyway, if you have any other patches, i'll be more than happy to test them out (and be more careful about the message this time)! thanks, r. On 3/15/24 19:25, Ard Biesheuvel wrote: > On Fri, 15 Mar 2024 at 19:11, Radek Podgorny <radek@podgorny.cz> wrote: >> >> ok, will. the kernel with previous patch is still compiling so i'll >> queue it. ;-) >> >> anyway, should i apply this as a separate patch or as an addition to the >> previous one (the one with bss.efistub addition)? >> > > Only this one change please. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --]
Thorsten Leemhuis <linux@leemhuis.info> writes:
> Here are a few small improvements for Documentation/admin-guide/
> verify-bugs-and-bisect-regressions.rst.
>
> * The "improve install instructions" aspects (link to distro docs, Arch
> support) were brought up on the list and in a chat.
>
> * The "check tainted status" thing was something I had forgotten; I
> noticed this aspect should likely be covered while doing some early
> work to better align Documentation/admin-guide/reporting-issues.rst
> with this text.
>
> * The rest are minor fixes for things. Many are things I noticed while
> working on the above changes. Quite a few are also things Petr Tesařík
> brought to my attention (many thx!).
>
> Ciao, Thorsten
>
> Thorsten Leemhuis (4):
> docs: verify/bisect: improve install instructions
> docs: verify/bisect: check taint flag
> docs: verify/bisect: drop 'v' prefix, EOL aspect, and assorted fixes
> docs: verify/bisect: remove a level of indenting
>
> .../verify-bugs-and-bisect-regressions.rst | 389 ++++++++++--------
> 1 file changed, 211 insertions(+), 178 deletions(-)
I've gone ahead and applied these, thanks.
jon
Nícolas F. R. A. Prado <nfraprado@collabora.com> writes:
> A couple tweaks to the commands in the regression documentation to make
> them up-to-date and less confusing.
>
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
> Changes in v2:
> - Reworded patch 1:
> - s/collon/colon/
> - Made title and message more straightforward
> - Link to v1: https://lore.kernel.org/r/20240308-regzbot-fixes-v1-0-577a4fe16e12@collabora.com
>
> ---
> Nícolas F. R. A. Prado (2):
> docs: *-regressions.rst: Add colon to regzbot commands
> docs: handling-regressions.rst: Update regzbot command fixed-by to fix
>
> Documentation/admin-guide/reporting-regressions.rst | 2 +-
> Documentation/process/handling-regressions.rst | 12 ++++++------
> 2 files changed, 7 insertions(+), 7 deletions(-)
Applied, thanks.
jon
Instruct readers to check the taint flag, as the reason why it's set might directly or indirectly cause the bug or interfere with testing. Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> --- .../verify-bugs-and-bisect-regressions.rst | 64 ++++++++++++++----- 1 file changed, 49 insertions(+), 15 deletions(-) diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst index fb82118bb011b9..632372e343d89f 100644 --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst @@ -113,6 +113,7 @@ will be considered the 'good' release and used to prepare the .config file. # checking if the output of the next two commands matches: tail -n 1 ~/kernels-built uname -r + cat /proc/sys/kernel/tainted c) Check if the problem occurs with this kernel as well. @@ -572,21 +573,29 @@ be a waste of time. [:ref:`details<introlatestcheck_bisref>`] Remember the identifier momentarily, as it will help you pick the right kernel from the boot menu upon restarting. -.. _recheckbroken_bissbs: - -* Reboot into the kernel you just built and check if the feature that is - expected to be broken really is. - - Start by making sure the kernel you booted is the one you just built. When - unsure, check if the output of these commands show the exact same release - identifier:: +* Reboot into your newly built kernel. To ensure your actually started the one + you just built, you might want to verify if the output of these commands + matches:: tail -n 1 ~/kernels-built uname -r - Now verify if the feature that causes trouble works with your newly built - kernel. If things work while investigating a regression, check the reference - section for further details. +.. _tainted_bissbs: + +* Check if the kernel marked itself as 'tainted':: + + cat /proc/sys/kernel/tainted + + If that command does not return '0', check the reference section, as the cause + for this might interfere with your testing. + + [:ref:`details<tainted_bisref>`] + +.. _recheckbroken_bissbs: + +* Verify if your bug occurs with the newly built kernel. If it does not, check + out the instructions in the reference section to ensure nothing went sideways + during your tests. [:ref:`details<recheckbroken_bisref>`] @@ -616,11 +625,14 @@ be a waste of time. [:ref:`details<introlatestcheck_bisref>`] make -s kernelrelease | tee -a ~/kernels-built reboot - Now verify if you booted the kernel you intended to start, to then check if - everything works fine with this kernel:: + Confirm you booted the kernel you intended to start and check its tainted + status:: tail -n 1 ~/kernels-built uname -r + cat /proc/sys/kernel/tainted + + Now verify if this kernel is showing the problem. [:ref:`details<recheckstablebroken_bisref>`] @@ -1629,13 +1641,32 @@ need to look in different places. [:ref:`back to step-by-step guide <storagespace_bissbs>`] +.. _tainted_bisref: + +Check if your newly built kernel considers itself 'tainted' +----------------------------------------------------------- + + *Check if the kernel marked itself as 'tainted'.* + [:ref:`... <tainted_bissbs>`] + +Linux marks itself as tainted when something happens that potentially leads to +follow-up errors that look totally unrelated. That is why developers might +ignore or react scantly to reports from tainted kernels -- unless of course the +kernel set the flag right when the reported bug occurred. + +That's why you want check why a kernel is tainted as explained in +Documentation/admin-guide/tainted-kernels.rst; doing so is also in your own +interest, as your testing might be flawed otherwise. + +[:ref:`back to step-by-step guide <tainted_bissbs>`] + .. _recheckbroken_bisref: Check the kernel built from the latest codebase ----------------------------------------------- - *Reboot into the kernel you just built and check if the feature that regressed - is really broken there.* [:ref:`... <recheckbroken_bissbs>`] + *Verify if your bug occurs with the newly built kernel.* + [:ref:`... <recheckbroken_bissbs>`] There are a couple of reasons why the regression you face might not show up with your own kernel built from the latest codebase. These are the most frequent: @@ -1712,6 +1743,9 @@ In case the feature that broke with newer kernels does not work with your first self-built kernel, find and resolve the cause before moving on. There are a multitude of reasons why this might happen. Some ideas where to look: +* Check the taint status and the output of ``dmesg``, maybe something unrelated + went wrong. + * Maybe localmodconfig did something odd and disabled the module required to test the feature? Then you might want to recreate a .config file based on the one from the last working kernel and skip trimming it down; manually disabling -- 2.44.0
Remove a unnecessary level of indenting in some areas of the reference section. No text changes. Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> --- .../verify-bugs-and-bisect-regressions.rst | 114 +++++++++--------- 1 file changed, 57 insertions(+), 57 deletions(-) diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst index ee9df7ecb02ac7..d3504826f40154 100644 --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst @@ -1138,12 +1138,12 @@ Git clone of Linus' mainline repository. There is nothing more to say about that -- but there are two alternatives ways to retrieve the sources that might work better for you: - * If you have an unreliable internet connection, consider - :ref:`using a 'Git bundle'<sources_bundle_bisref>`. +* If you have an unreliable internet connection, consider + :ref:`using a 'Git bundle'<sources_bundle_bisref>`. - * If downloading the complete repository would take too long or requires too - much storage space, consider :ref:`using a 'shallow - clone'<sources_shallow_bisref>`. +* If downloading the complete repository would take too long or requires too + much storage space, consider :ref:`using a 'shallow + clone'<sources_shallow_bisref>`. .. _sources_bundle_bisref: @@ -1195,23 +1195,23 @@ branches as explained in the step-by-step guide. Note, shallow clones have a few peculiar characteristics: - * For bisections the history needs to be deepened a few mainline versions - farther than it seems necessary, as explained above already. That's because - Git otherwise will be unable to revert or describe most of the commits within - a range (say 6.1..6.2), as they are internally based on earlier kernels - releases (like 6.0-rc2 or 5.19-rc3). +* For bisections the history needs to be deepened a few mainline versions + farther than it seems necessary, as explained above already. That's because + Git otherwise will be unable to revert or describe most of the commits within + a range (say 6.1..6.2), as they are internally based on earlier kernels + releases (like 6.0-rc2 or 5.19-rc3). - * This document in most places uses ``git fetch`` with ``--shallow-exclude=`` - to specify the earliest version you care about (or to be precise: its git - tag). You alternatively can use the parameter ``--shallow-since=`` to specify - an absolute (say ``'2023-07-15'``) or relative (``'12 months'``) date to - define the depth of the history you want to download. When using them while - bisecting mainline, ensure to deepen the history to at least 7 months before - the release of the mainline release your 'good' kernel is based on. +* This document in most places uses ``git fetch`` with ``--shallow-exclude=`` + to specify the earliest version you care about (or to be precise: its git + tag). You alternatively can use the parameter ``--shallow-since=`` to specify + an absolute (say ``'2023-07-15'``) or relative (``'12 months'``) date to + define the depth of the history you want to download. When using them while + bisecting mainline, ensure to deepen the history to at least 7 months before + the release of the mainline release your 'good' kernel is based on. - * Be warned, when deepening your clone you might encounter an error like - 'fatal: error in object: unshallow cafecaca0c0dacafecaca0c0dacafecaca0c0da'. - In that case run ``git repack -d`` and try again. +* Be warned, when deepening your clone you might encounter an error like + 'fatal: error in object: unshallow cafecaca0c0dacafecaca0c0dacafecaca0c0da'. + In that case run ``git repack -d`` and try again. [:ref:`back to step-by-step guide <sources_bissbs>`] [:ref:`back to section intro <sources_bisref>`] @@ -1235,23 +1235,23 @@ locate the right build configuration.* Two things can easily go wrong when creating a .config file as advised: - * The oldconfig target will use a .config file from your build directory, if - one is already present there (e.g. '~/linux/.config'). That's totally fine if - that's what you intend (see next step), but in all other cases you want to - delete it. This for example is important in case you followed this guide - further, but due to problems come back here to redo the configuration from - scratch. +* The oldconfig target will use a .config file from your build directory, if + one is already present there (e.g. '~/linux/.config'). That's totally fine if + that's what you intend (see next step), but in all other cases you want to + delete it. This for example is important in case you followed this guide + further, but due to problems come back here to redo the configuration from + scratch. - * Sometimes olddefconfig is unable to locate the .config file for your running - kernel and will use defaults, as briefly outlined in the guide. In that case - check if your distribution ships the configuration somewhere and manually put - it in the right place (e.g. '~/linux/.config') if it does. On distributions - where /proc/config.gz exists this can be achieved using this command:: +* Sometimes olddefconfig is unable to locate the .config file for your running + kernel and will use defaults, as briefly outlined in the guide. In that case + check if your distribution ships the configuration somewhere and manually put + it in the right place (e.g. '~/linux/.config') if it does. On distributions + where /proc/config.gz exists this can be achieved using this command:: - zcat /proc/config.gz > .config + zcat /proc/config.gz > .config - Once you put it there, run ``make olddefconfig`` again to adjust it to the - needs of the kernel about to be built. + Once you put it there, run ``make olddefconfig`` again to adjust it to the + needs of the kernel about to be built. Note, the olddefconfig target will set any undefined build options to their default value. If you prefer to set such configuration options manually, use @@ -1393,16 +1393,16 @@ when following this guide on a few commodity distributions. **Debian:** - * Remove a stale reference to a certificate file that would cause your build to - fail:: +* Remove a stale reference to a certificate file that would cause your build to + fail:: - ./scripts/config --set-str SYSTEM_TRUSTED_KEYS '' + ./scripts/config --set-str SYSTEM_TRUSTED_KEYS '' - Alternatively, download the needed certificate and make that configuration - option point to it, as `the Debian handbook explains in more detail - <https://debian-handbook.info/browse/stable/sect.kernel-compilation.html>`_ - -- or generate your own, as explained in - Documentation/admin-guide/module-signing.rst. + Alternatively, download the needed certificate and make that configuration + option point to it, as `the Debian handbook explains in more detail + <https://debian-handbook.info/browse/stable/sect.kernel-compilation.html>`_ + -- or generate your own, as explained in + Documentation/admin-guide/module-signing.rst. [:ref:`back to step-by-step guide <configmods_bissbs>`] @@ -1563,11 +1563,11 @@ The step-by-step guide uses the default make targets (e.g. 'bzImage' and steps of the guide then install. You instead can also directly build everything and directly package it up by using one of the following targets: - * ``make -j $(nproc --all) bindeb-pkg`` to generate a deb package +* ``make -j $(nproc --all) bindeb-pkg`` to generate a deb package - * ``make -j $(nproc --all) binrpm-pkg`` to generate a rpm package +* ``make -j $(nproc --all) binrpm-pkg`` to generate a rpm package - * ``make -j $(nproc --all) tarbz2-pkg`` to generate a bz2 compressed tarball +* ``make -j $(nproc --all) tarbz2-pkg`` to generate a bz2 compressed tarball This is just a selection of available make targets for this purpose, see ``make help`` for others. You can also use these targets after running @@ -1599,20 +1599,20 @@ If installkernel is found, the kernel's build system will delegate the actual installation of your kernel image to this executable, which then performs some or all of these tasks: - * On almost all Linux distributions installkernel will store your kernel's - image in /boot/, usually as '/boot/vmlinuz-<kernelrelease_id>'; often it will - put a 'System.map-<kernelrelease_id>' alongside it. +* On almost all Linux distributions installkernel will store your kernel's + image in /boot/, usually as '/boot/vmlinuz-<kernelrelease_id>'; often it will + put a 'System.map-<kernelrelease_id>' alongside it. - * On most distributions installkernel will then generate an 'initramfs' - (sometimes also called 'initrd'), which usually are stored as - '/boot/initramfs-<kernelrelease_id>.img' or - '/boot/initrd-<kernelrelease_id>'. Commodity distributions rely on this file - for booting, hence ensure to execute the make target 'modules_install' first, - as your distribution's initramfs generator otherwise will be unable to find - the modules that go into the image. +* On most distributions installkernel will then generate an 'initramfs' + (sometimes also called 'initrd'), which usually are stored as + '/boot/initramfs-<kernelrelease_id>.img' or + '/boot/initrd-<kernelrelease_id>'. Commodity distributions rely on this file + for booting, hence ensure to execute the make target 'modules_install' first, + as your distribution's initramfs generator otherwise will be unable to find + the modules that go into the image. - * On some distributions installkernel will then add an entry for your kernel - to your bootloader's configuration. +* On some distributions installkernel will then add an entry for your kernel + to your bootloader's configuration. You have to take care of some or all of the tasks yourself, if your distribution lacks a installkernel script or does only handle part of them. -- 2.44.0
A bunch of minor fixes and improvements and two other things: - Explain the 'v' version prefix when it's first used, but drop it everywhere in the text for consistency. Also drop single quotes around a few version numbers. - Point out that testing a stable/longterm kernel only makes sense if the series is still supported. Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> --- .../verify-bugs-and-bisect-regressions.rst | 117 ++++++++++-------- 1 file changed, 62 insertions(+), 55 deletions(-) diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst index 632372e343d89f..ee9df7ecb02ac7 100644 --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst @@ -39,13 +39,13 @@ aspects, all of which might be essential in your present case.]* developers**, execute just the *preparations* and *segment 1*; while doing so, consider the newest Linux kernel you regularly use to be the 'working' kernel. In the following example that's assumed to be 6.0.13, which is why the sources -of v6.0 will be used to prepare the .config file. +of 6.0 will be used to prepare the .config file. **In case you face a regression**, follow the steps at least till the end of *segment 2*. Then you can submit a preliminary report -- or continue with *segment 3*, which describes how to perform a bisection needed for a full-fledged regression report. In the following example 6.0.13 is assumed to be -the 'working' kernel and 6.1.5 to be the first 'broken', which is why v6.0 +the 'working' kernel and 6.1.5 to be the first 'broken', which is why 6.0 will be considered the 'good' release and used to prepare the .config file. * **Preparations**: set up everything to build your own kernels:: @@ -232,9 +232,10 @@ developers are obliged to act upon. :ref:`Supplementary tasks: cleanup during and after following this guide.<introclosure_bissbs>` The steps in each segment illustrate the important aspects of the process, while -a comprehensive reference section holds additional details. The latter sometimes -also outlines alternative approaches, pitfalls, as well as problems that might -occur at the particular step -- and how to get things rolling again. +a comprehensive reference section holds additional details for almost all of the +steps. The reference section sometimes also outlines alternative approaches, +pitfalls, as well as problems that might occur at the particular step -- and how +to get things rolling again. For further details on how to report Linux kernel issues or regressions check out Documentation/admin-guide/reporting-issues.rst, which works in conjunction @@ -285,23 +286,23 @@ Preparations: set up everything to build your own kernels Do you follow this guide to verify if a bug is present in the code developers care for? Then consider the mainline release your 'working' kernel (the newest one you regularly use) is based on to be the 'good' version; if your 'working' - kernel for example is '6.0.11', then your 'good' kernel is 'v6.0'. + kernel for example is 6.0.11, then your 'good' kernel is 6.0. In case you face a regression, it depends on the version range where the regression was introduced: * Something which used to work in Linux 6.0 broke when switching to Linux - 6.1-rc1? Then henceforth regard 'v6.0' as the last known 'good' version - and 'v6.1-rc1' as the first 'bad' one. + 6.1-rc1? Then henceforth regard 6.0 as the last known 'good' version + and 6.1-rc1 as the first 'bad' one. * Some function stopped working when updating from 6.0.11 to 6.1.4? Then for - the time being consider 'v6.0' as the last 'good' version and 'v6.1.4' as + the time being consider 6.0 as the last 'good' version and 6.1.4 as the 'bad' one. Note, at this point it is merely assumed that 6.0 is fine; this assumption will be checked in segment 2. * A feature you used in 6.0.11 does not work at all or worse in 6.1.13? In that case you want to bisect within a stable/longterm series: consider - 'v6.0.11' as the last known 'good' version and 'v6.0.13' as the first 'bad' + 6.0.11 as the last known 'good' version and 6.0.13 as the first 'bad' one. Note, in this case you still want to compile and test a mainline kernel as explained in segment 1: the outcome will determine if you need to report your issue to the regular developers or the stable team. @@ -351,7 +352,7 @@ Preparations: set up everything to build your own kernels internet connections.* Execute the following command to retrieve a fresh mainline codebase while - preparing things to add stable/longterm branches later:: + preparing things to add branches for stable/longterm series later:: git clone -o mainline --no-checkout \ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ~/linux/ @@ -370,14 +371,19 @@ Preparations: set up everything to build your own kernels identifier using ``uname -r``. Afterwards check out the source code for the version earlier established as - 'good' (in this example this is assumed to be 6.0) and create a .config file:: + 'good'. In the following example command this is assumed to be 6.0; note that + the version number in this and all later Git commands needs to be prefixed + with a 'v':: git checkout --detach v6.0 + + Now create a build configuration file:: + make olddefconfig - The second command will try to locate the build configuration file for the - running kernel and then adjust it for the needs of the kernel sources you - checked out. While doing so, it will print a few lines you need to check. + The kernel build scripts then will try to locate the build configuration file + for the running kernel and then adjust it for the needs of the kernel sources + you checked out. While doing so, it will print a few lines you need to check. Look out for a line starting with '# using defaults found in'. It should be followed by a path to a file in '/boot/' that contains the release identifier @@ -601,11 +607,12 @@ be a waste of time. [:ref:`details<introlatestcheck_bisref>`] .. _recheckstablebroken_bissbs: -* Are you facing a problem within a stable/longterm release, but failed to - reproduce it with the mainline kernel you just built? Then check if the latest - codebase for the particular series might already fix the problem. To do so, - add the stable series Git branch for your 'good' kernel (again, this here is - assumed to be 6.0) and check out the latest version:: +* Are you facing a problem within a stable/longterm series, but failed to + reproduce it with the mainline kernel you just built? One that according to + the `front page of kernel.org <https://kernel.org/>`_ is still supported? Then + check if the latest codebase for the particular series might already fix the + problem. To do so, add the stable series Git branch for your 'good' kernel + (again, this here is assumed to be 6.0) and check out the latest version:: cd ~/linux/ git remote set-branches --add stable linux-6.0.y @@ -639,7 +646,7 @@ be a waste of time. [:ref:`details<introlatestcheck_bisref>`] Do you follow this guide to verify if a problem is present in the code currently supported by Linux kernel developers? Then you are done at this point. If you later want to remove the kernel you just built, check out -:ref:`Supplementary tasks: cleanup during and after following this guide.<introclosure_bissbs>`. +:ref:`Supplementary tasks: cleanup during and after following this guide<introclosure_bissbs>`. In case you face a regression, move on and execute at least the next segment as well. @@ -678,7 +685,7 @@ otherwise would be a waste of time. [:ref:`details<introworkingcheck_bisref>`] reboot When the system booted, you may want to verify once again that the - kernel you started is the one you just built: + kernel you started is the one you just built:: tail -n 1 ~/kernels-built uname -r @@ -701,7 +708,7 @@ configuration created earlier this works a lot faster than many people assume: overall on average it will often just take about 10 to 15 minutes to compile each kernel on commodity x86 machines. -* In case your 'bad' version is a stable/longterm release (say v6.1.5), add its +* In case your 'bad' version is a stable/longterm release (say 6.1.5), add its stable branch, unless you already did so earlier:: cd ~/linux/ @@ -1191,8 +1198,8 @@ Note, shallow clones have a few peculiar characteristics: * For bisections the history needs to be deepened a few mainline versions farther than it seems necessary, as explained above already. That's because Git otherwise will be unable to revert or describe most of the commits within - a range (say v6.1..v6.2), as they are internally based on earlier kernels - releases (like v6.0-rc2 or 5.19-rc3). + a range (say 6.1..6.2), as they are internally based on earlier kernels + releases (like 6.0-rc2 or 5.19-rc3). * This document in most places uses ``git fetch`` with ``--shallow-exclude=`` to specify the earliest version you care about (or to be precise: its git @@ -1257,7 +1264,7 @@ restrictions). Occasionally odd things happen when trying to use a config file prepared for one kernel (say 6.1) on an older mainline release -- especially if it is much older -(say v5.15). That's one of the reasons why the previous step in the guide told +(say 5.15). That's one of the reasons why the previous step in the guide told you to boot the kernel where everything works. If you manually add a .config file you thus want to ensure it's from the working kernel and not from a one that shows the regression. @@ -1407,12 +1414,12 @@ Individual adjustments *If you want to influence the other aspects of the configuration, do so now.* [:ref:`... <configmods_bissbs>`] -You at this point can use a command like ``make menuconfig`` to enable or -disable certain features using a text-based user interface; to use a graphical -configuration utility, call the make target ``xconfig`` or ``gconfig`` instead. -All of them require development libraries from toolkits they are based on -(ncurses, Qt5, Gtk2); an error message will tell you if something required is -missing. +At this point you can use a command like ``make menuconfig`` or ``make nconfig`` +to enable or disable certain features using a text-based user interface; to use +a graphical configuration utility, run ``make xconfig`` instead. Both of them +require development libraries from toolkits they are rely on (ncurses +respectively Qt5 or Qt6); an error message will tell you if something required +is missing. [:ref:`back to step-by-step guide <configmods_bissbs>`] @@ -1489,10 +1496,10 @@ highly recommended for these reasons: .. _checkoutmaster_bisref: -Checkout the latest Linux codebase ----------------------------------- +Check out the latest Linux codebase +----------------------------------- - *Checkout the latest Linux codebase.* + *Check out the latest Linux codebase.* [:ref:`... <introlatestcheck_bissbs>`] In case you later want to recheck if an ever newer codebase might fix the @@ -1520,7 +1527,7 @@ When a build error occurs, it might be caused by some aspect of your machine's setup that often can be fixed quickly; other times though the problem lies in the code and can only be fixed by a developer. A close examination of the failure messages coupled with some research on the internet will often tell you -which of the two it is. To perform such a investigation, restart the build +which of the two it is. To perform such investigation, restart the build process like this:: make V=1 @@ -1543,10 +1550,10 @@ often one of the hits will provide a solution for your problem, too. If you do not find anything that matches your problem, try again from a different angle by modifying your search terms or using another line from the error messages. -In the end, most trouble you are to run into has likely been encountered and +In the end, most issues you run into have likely been encountered and reported by others already. That includes issues where the cause is not your -system, but lies the code. If you run into one of those, you might thus find a -solution (e.g. a patch) or workaround for your problem, too. +system, but lies in the code. If you run into one of those, you might thus find a +solution (e.g. a patch) or workaround for your issue, too. Package your kernel up ~~~~~~~~~~~~~~~~~~~~~~ @@ -1662,18 +1669,18 @@ interest, as your testing might be flawed otherwise. .. _recheckbroken_bisref: -Check the kernel built from the latest codebase ------------------------------------------------ +Check the kernel built from a recent mainline codebase +------------------------------------------------------ *Verify if your bug occurs with the newly built kernel.* [:ref:`... <recheckbroken_bissbs>`] -There are a couple of reasons why the regression you face might not show up with -your own kernel built from the latest codebase. These are the most frequent: +There are a couple of reasons why your bug or regression might not show up with +the kernel you built from the latest codebase. These are the most frequent: -* The cause for the regression was fixed meanwhile. +* The bug was fixed meanwhile. -* The regression with the broken kernel was caused by a change in the build +* What you suspected to be a regression was caused by a change in the build configuration the provider of your kernel carried out. * Your problem might be a race condition that does not show up with your kernel; @@ -1725,9 +1732,9 @@ it's possible that the thing that regressed might never have worked in vanilla builds of the 'good' version in the first place. There is a third reason for those that noticed a regression between -stable/longterm kernels of different series (e.g. v6.0.13..v6.1.5): it will +stable/longterm kernels of different series (e.g. 6.0.13..6.1.5): it will ensure the kernel version you assumed to be 'good' earlier in the process (e.g. -v6.0) actually is working. +6.0) actually is working. [:ref:`back to step-by-step guide <introworkingcheck_bissbs>`] @@ -1760,8 +1767,8 @@ multitude of reasons why this might happen. Some ideas where to look: Note, if you found and fixed problems with the .config file, you want to use it to build another kernel from the latest codebase, as your earlier tests with -mainline and the latest version from an affected stable/longterm series most -likely has been flawed. +mainline and the latest version from an affected stable/longterm series were most +likely flawed. [:ref:`back to step-by-step guide <recheckworking_bissbs>`] @@ -1774,8 +1781,8 @@ Start the bisection 'good' and 'bad'.* [:ref:`... <bisectstart_bissbs>`] This will start the bisection process; the last of the commands will make Git -checkout a commit round about half-way between the 'good' and the 'bad' changes -for your to test. +check out a commit round about half-way between the 'good' and the 'bad' changes +for you to test. [:ref:`back to step-by-step guide <bisectstart_bissbs>`] @@ -1800,7 +1807,7 @@ There are two things worth of note here: * Those slightly odd looking version identifiers can happen during bisections, because the Linux kernel subsystems prepare their changes for a new mainline release (say 6.2) before its predecessor (e.g. 6.1) is finished. They thus - base them on a somewhat earlier point like v6.1-rc1 or even v6.0 -- and then + base them on a somewhat earlier point like 6.1-rc1 or even 6.0 -- and then get merged for 6.2 without rebasing nor squashing them once 6.1 is out. This leads to those slightly odd looking version identifiers coming up during bisections. @@ -1816,7 +1823,7 @@ Bisection checkpoint [:ref:`... <bisecttest_bissbs>`] Ensure what you tell Git is accurate: getting it wrong just one time will bring -the rest of the bisection totally of course, hence all testing after that point +the rest of the bisection totally off course, hence all testing after that point will be for nothing. [:ref:`back to step-by-step guide <bisecttest_bissbs>`] @@ -1837,7 +1844,7 @@ instead of testing ten or more kernels you might only have to build a few to resolve things. The .config file is put aside, as there is a decent chance that developers might -ask for it after you reported the regression. +ask for it after you report the regression. [:ref:`back to step-by-step guide <bisectlog_bissbs>`] @@ -1887,7 +1894,7 @@ simply remove its modules directory in /lib/modules/. The other place is /boot/, where typically two up to five files will be placed during installation of a kernel. All of them usually contain the release name in -their file name, but how many files and their exact name depends somewhat on +their file name, but how many files and their exact names depend somewhat on your distribution's installkernel executable and its initramfs generator. On some distributions the ``kernel-install remove...`` command mentioned in the step-by-step guide will delete all of these files for you while also removing -- 2.44.0
These changes among others ensure modules will be installed when /sbin/installkernel is missing. Furthermore describe better what tasks the script ideally performs so that users can more easily check if those have been taken care of. In addition to that point to the distro's documentation for further details on installing kernels manually. Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> --- .../verify-bugs-and-bisect-regressions.rst | 122 ++++++++---------- 1 file changed, 57 insertions(+), 65 deletions(-) diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst index 58211840ac6ffb..fb82118bb011b9 100644 --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst @@ -99,7 +99,8 @@ will be considered the 'good' release and used to prepare the .config file. # * Note: on Arch Linux, its derivatives and a few other distributions # the following commands will do nothing at all or only part of the # job. See the step-by-step guide for further details. - command -v installkernel && sudo make modules_install install + sudo make modules_install + command -v installkernel && sudo make install # * Check how much space your self-built kernel actually needs, which # enables you to make better estimates later: du -ch /boot/*$(make -s kernelrelease)* | tail -n 1 @@ -520,44 +521,32 @@ be a waste of time. [:ref:`details<introlatestcheck_bisref>`] * Install your newly built kernel. - Before doing so, consider checking if there is still enough room for it:: + Before doing so, consider checking if there is still enough space for it:: df -h /boot/ /lib/modules/ - 150 MByte in /boot/ and 200 in /lib/modules/ usually suffice. Those are rough - estimates assuming the worst case. How much your kernels actually require will - be determined later. + For now assume 150 MByte in /boot/ and 200 in /lib/modules/ will suffice; how + much your kernels actually require will be determined later during this guide. - Now install the kernel, which will be saved in parallel to the kernels from - your Linux distribution:: + Now install the kernel's modules and its image, which will be stored in + parallel to the your Linux distribution's kernels:: - command -v installkernel && sudo make modules_install install + sudo make modules_install + command -v installkernel && sudo make install - On many commodity Linux distributions this will take care of everything - required to boot your kernel. You might want to ensure that's the case by - checking if your boot loader's configuration was updated; furthermore ensure - an initramfs (also known as initrd) exists, which on many distributions can be - achieved by running ``ls -l /boot/init*$(make -s kernelrelease)*``. Those - steps are recommended, as there are quite a few Linux distribution where above - command is insufficient: + The second command ideally will take care of three steps required at this + point: copying the kernel's image to /boot/, generating an initramfs, and + adding an entry for both to the boot loader's configuration. - * On Arch Linux, its derivatives, many immutable Linux distributions, and a - few others the above command does nothing at, as they lack 'installkernel' - executable. + Sadly some distributions (among them Arch Linux, its derivatives, and many + immutable Linux distributions) will perform none or only some of those tasks. + You therefore want to check if all of them were taken care of and manually + perform those that were not. The reference section provides further details on + that; your distribution's documentation might help, too. - * Some distributions install the kernel, but don't add an entry for your - kernel in your boot loader's configuration -- the kernel thus won't show up - in the boot menu. - - * Some distributions add a boot loader menu entry, but don't create an - initramfs on installation -- in that case your kernel most likely will be - unable to mount the root partition during bootup. - - If any of that applies to you, see the reference section for further guidance. - Once you figured out what to do, consider writing down the necessary - installation steps: if you will build more kernels as described in - segment 2 and 3, you will have to execute these commands every time that - ``command -v installkernel [...]`` comes up again. + Once you figured out the steps needed at this point, consider writing them + down: if you will build more kernels as described in segment 2 and 3, you will + have to perform those again after executing ``command -v installkernel [...]``. [:ref:`details<install_bisref>`] @@ -622,7 +611,8 @@ be a waste of time. [:ref:`details<introlatestcheck_bisref>`] make -j $(nproc --all) # * Check if the free space suffices holding another kernel: df -h /boot/ /lib/modules/ - command -v installkernel && sudo make modules_install install + sudo make modules_install + command -v installkernel && sudo make install make -s kernelrelease | tee -a ~/kernels-built reboot @@ -670,7 +660,8 @@ otherwise would be a waste of time. [:ref:`details<introworkingcheck_bisref>`] make -j $(nproc --all) # * Check if the free space suffices holding another kernel: df -h /boot/ /lib/modules/ - command -v installkernel && sudo make modules_install install + sudo make modules_install + command -v installkernel && sudo make install make -s kernelrelease | tee -a ~/kernels-built reboot @@ -727,7 +718,8 @@ each kernel on commodity x86 machines. make -j $(nproc --all) # * Check if the free space suffices holding another kernel: df -h /boot/ /lib/modules/ - command -v installkernel && sudo make modules_install install + sudo make modules_install + command -v installkernel && sudo make install make -s kernelrelease | tee -a ~/kernels-built reboot @@ -843,7 +835,8 @@ each kernel on commodity x86 machines. make -j $(nproc --all) && # * Check if the free space suffices holding another kernel: df -h /boot/ /lib/modules/ - command -v installkernel && sudo make modules_install install + sudo make modules_install + command -v installkernel && sudo make install Make -s kernelrelease | tee -a ~/kernels-built reboot @@ -1580,39 +1573,38 @@ Put the kernel in place *Install the kernel you just built.* [:ref:`... <install_bissbs>`] What you need to do after executing the command in the step-by-step guide -depends on the existence and the implementation of an ``installkernel`` -executable. Many commodity Linux distributions ship such a kernel installer in -'/sbin/' that does everything needed, hence there is nothing left for you -except rebooting. But some distributions contain an installkernel that does -only part of the job -- and a few lack it completely and leave all the work to -you. - -If ``installkernel`` is found, the kernel's build system will delegate the -actual installation of your kernel's image and related files to this executable. -On almost all Linux distributions it will store the image as '/boot/vmlinuz- -<kernelrelease identifier>' and put a 'System.map-<kernelrelease -identifier>' alongside it. Your kernel will thus be installed in parallel to any -existing ones, unless you already have one with exactly the same release name. - -Installkernel on many distributions will afterwards generate an 'initramfs' -(often also called 'initrd'), which commodity distributions rely on for booting; -hence be sure to keep the order of the two make targets used in the step-by-step -guide, as things will go sideways if you install your kernel's image before its -modules. Often installkernel will then add your kernel to the bootloader -configuration, too. You have to take care of one or both of these tasks -yourself, if your distributions installkernel doesn't handle them. - -A few distributions like Arch Linux and its derivatives totally lack an -installkernel executable. On those just install the modules using the kernel's -build system and then install the image and the System.map file manually:: - - sudo make modules_install +depends on the existence and the implementation of ``/sbin/installkernel`` +executable on your distribution. + +If installkernel is found, the kernel's build system will delegate the actual +installation of your kernel image to this executable, which then performs some +or all of these tasks: + + * On almost all Linux distributions installkernel will store your kernel's + image in /boot/, usually as '/boot/vmlinuz-<kernelrelease_id>'; often it will + put a 'System.map-<kernelrelease_id>' alongside it. + + * On most distributions installkernel will then generate an 'initramfs' + (sometimes also called 'initrd'), which usually are stored as + '/boot/initramfs-<kernelrelease_id>.img' or + '/boot/initrd-<kernelrelease_id>'. Commodity distributions rely on this file + for booting, hence ensure to execute the make target 'modules_install' first, + as your distribution's initramfs generator otherwise will be unable to find + the modules that go into the image. + + * On some distributions installkernel will then add an entry for your kernel + to your bootloader's configuration. + +You have to take care of some or all of the tasks yourself, if your +distribution lacks a installkernel script or does only handle part of them. +Consult the distribution's documentation for details. If in doubt, install the +kernel manually:: + sudo install -m 0600 $(make -s image_name) /boot/vmlinuz-$(make -s kernelrelease) sudo install -m 0600 System.map /boot/System.map-$(make -s kernelrelease) -If your distribution boots with the help of an initramfs, now generate one for -your kernel using the tools your distribution provides for this process. -Afterwards add your kernel to your bootloader configuration and reboot. +Now generate your initramfs using the tools your distribution provides for this +process. Afterwards add your kernel to your bootloader configuration and reboot. [:ref:`back to step-by-step guide <install_bissbs>`] -- 2.44.0
Here are a few small improvements for Documentation/admin-guide/ verify-bugs-and-bisect-regressions.rst. * The "improve install instructions" aspects (link to distro docs, Arch support) were brought up on the list and in a chat. * The "check tainted status" thing was something I had forgotten; I noticed this aspect should likely be covered while doing some early work to better align Documentation/admin-guide/reporting-issues.rst with this text. * The rest are minor fixes for things. Many are things I noticed while working on the above changes. Quite a few are also things Petr Tesařík brought to my attention (many thx!). Ciao, Thorsten Thorsten Leemhuis (4): docs: verify/bisect: improve install instructions docs: verify/bisect: check taint flag docs: verify/bisect: drop 'v' prefix, EOL aspect, and assorted fixes docs: verify/bisect: remove a level of indenting .../verify-bugs-and-bisect-regressions.rst | 389 ++++++++++-------- 1 file changed, 211 insertions(+), 178 deletions(-) base-commit: 0c8e9b538ed7ecf4159b080ab0dafca3941c69db -- 2.44.0
On Tue, Mar 12, 2024 at 09:57:06AM +0100, Jan Čermák wrote: > Hi Alan > > On 11. 03. 24 15:43, Alan Stern wrote: > > Well, at least this means you do have a way of using the device, even > > if it is rather awkward. It might even work on the Raspberry Pi machine. > > Still, I'm looking for a more permanent and robust solution. If it were only > a single device I'm using myself, I could come up with a workaround. > However, this is one of the very few available Z-Wave USB interfaces and > there are more users affected. So far we went with reverting the patches, > but that's surely not the way we want to go forward. > > > The device is so non-responsive, I'm amazed it ever works at all. > > Judging by the usbmon traces, it doesn't look as if it would work on a > > Windows system. > > > > Actually, if you have access to a computer running Windows or Mac OSX > > and you can try out the device on that computer, it would be good to > > get the equivalent of a usbmon trace (something like a Wireshark > > capture log would do). If those systems manage to do something that > > Linux doesn't, we ought to know what it is. > > Fredrik (one of the original reporters) is following this conversation, here > [1] are logs from his machine with some details in the ticket [2]. He also > wonders why the initialization doesn't work only on USB2 ports but works on > USB3 if the initialization code is shared between those two. It's very difficult to compare the Windows log with the usbmon trace. However, something Frederik mentioned about the number of resets led me to check more closely. There are some extra unnecessary resets in the usbmon trace, and a reset that should be there is missing. Below is a patch meant to get the number of resets back to what it should be. I'd appreciate it if you can test this, and report the kernel log output along with the usbmon output for the normal case and also with the "old_scheme_first" parameter set. I'm not very hopeful that this will solve the problem, but there's a good chance it will help point us in the right direction by removing extraneous complications. Alan Stern drivers/usb/core/hub.c | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-) Index: usb-devel/drivers/usb/core/hub.c =================================================================== --- usb-devel.orig/drivers/usb/core/hub.c +++ usb-devel/drivers/usb/core/hub.c @@ -4961,6 +4961,18 @@ hub_port_init(struct usb_hub *hub, struc break; } + if (retries > 0) { + retval = hub_port_reset(hub, port1, udev, delay, false); + if (retval < 0) /* error or disconnect */ + goto fail; + if (oldspeed != udev->speed) { + dev_dbg(&udev->dev, + "device reset changed speed!\n"); + retval = -ENODEV; + goto fail; + } + } + if (do_new_scheme) { retval = hub_enable_device(udev); if (retval < 0) { @@ -4972,6 +4984,13 @@ hub_port_init(struct usb_hub *hub, struc maxp0 = get_bMaxPacketSize0(udev, buf, GET_DESCRIPTOR_BUFSIZE, retries == 0); + if (maxp0 < 0) { + if (maxp0 != -ENODEV) + dev_err(&udev->dev, "device descriptor read/64, error %d\n", + maxp0); + retval = maxp0; + continue; + } if (maxp0 > 0 && !initial && maxp0 != udev->descriptor.bMaxPacketSize0) { dev_err(&udev->dev, "device reset changed ep0 maxpacket size!\n"); @@ -4988,13 +5007,6 @@ hub_port_init(struct usb_hub *hub, struc retval = -ENODEV; goto fail; } - if (maxp0 < 0) { - if (maxp0 != -ENODEV) - dev_err(&udev->dev, "device descriptor read/64, error %d\n", - maxp0); - retval = maxp0; - continue; - } } for (operations = 0; operations < SET_ADDRESS_TRIES; ++operations) { @@ -5533,6 +5545,7 @@ loop: msleep(2 * hub_power_on_good_delay(hub)); usb_hub_set_port_power(hdev, hub, port1, true); msleep(hub_power_on_good_delay(hub)); + hub_port_debounce_be_stable(hub, port1); } } if (hub->hdev->parent ||
Martin Steigerwald - 16.03.24, 17:02:44 CET: > ThinkPad T14 AMD Gen 1 fails to hibernate with self-compiled 6.8.1. > Hibernation works correctly with self-compiled 6.7.9. Apparently 6.8.1 does not even reboot correctly anymore. runit on Devuan. It says it is doing the system reboot but then nothing happens. As for hibernation the kernel cancels the attempt and returns back to user space desktop session. > Trying to use "no_console_suspend" to debug next. Will not do bisect > between major kernel releases on a production machine. Output with "no_console_suspend": [ 82.593360] r8169 0000:05:00.0 en1: Link is Down [ 83.196401] PM: hibernation: hibernation entry [ 83.671489] Filesystems sync: 0.121 seconds [ 83.671977] Freezing user space processes [ 83.674855] Freezing user space processes completed (elapsed 0.002 seconds) [ 83.674879] OOM killer disabled. [ 83.675111] PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff] [ 83.675114] PM: hibernation: Marking nosave pages: [mem 0x0009f000-0x000fffff] [ 83.675117] PM: hibernation: Marking nosave pages: [mem 0x09c00000-0x09d00fff] [ 83.675122] PM: hibernation: Marking nosave pages: [mem 0x09f00000-0x09f0ffff] [ 83.675123] PM: hibernation: Marking nosave pages: [mem 0xa2357000-0xa2357fff] [ 83.675125] PM: hibernation: Marking nosave pages: [mem 0xa2364000-0xa2365fff] [ 83.675126] PM: hibernation: Marking nosave pages: [mem 0xa2373000-0xa2374fff] [ 83.675128] PM: hibernation: Marking nosave pages: [mem 0xa2385000-0xa2385fff] [ 83.675129] PM: hibernation: Marking nosave pages: [mem 0xb9532000-0xb95c2fff] [ 83.675132] PM: hibernation: Marking nosave pages: [mem 0xbd9de000-0xcc3fdfff] [ 83.675620] PM: hibernation: Marking nosave pages: [mem 0xce000000-0xffffffff] [ 83.676393] PM: hibernation: Basic memory bitmaps created [ 83.681188] PM: hibernation: Preallocating image memory [ 85.599072] PM: hibernation: Allocated 2043901 pages for snapshot [ 85.599105] PM: hibernation: Allocated 8175604 kbytes in 1.91 seconds (4280.42 MB/s) [ 85.599125] Freezing remaining freezable tasks [ 85.600726] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 85.611679] port 0000:02:00.1:0.0: PM: dpm_run_callback(): pm_runtime_force_suspend+0x0/0x120 returns -16 [ 85.611709] port 0000:02:00.1:0.0: PM: failed to freeze: error -16 [ 86.303477] PM: hibernation: Basic memory bitmaps freed [ 86.304003] OOM killer enabled. [ 86.304582] Restarting tasks ... done. [ 86.307452] thermal thermal_zone0: failed to read out thermal zone (-61) [ 86.307507] PM: hibernation: hibernation exit [ 86.331566] Generic FE-GE Realtek PHY r8169-0-200:00: attached PHY driver (mii_bus:phy_addr=r8169-0-200:00, irq=MAC) [ 86.932558] r8169 0000:02:00.0 en0: rtl_ep_ocp_read_cond == 0 (loop: 30, delay: 10000). [ 87.004862] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4694] [ 87.038125] r8169 0000:02:00.0 en0: Link is Down [ 87.043559] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1162..] [ 87.067568] Generic FE-GE Realtek PHY r8169-0-500:00: attached PHY driver (mii_bus:phy_addr=r8169-0-500:00, irq=MAC) [ 87.204101] r8169 0000:05:00.0 en1: Link is Down [ 90.639039] r8169 0000:05:00.0 en1: Link is Up - 1Gbps/Full - flow control rx/tx Downgrading to 6.7. Thanks. -- Martin
Hi! ThinkPad T14 AMD Gen 1 fails to hibernate with self-compiled 6.8.1. Hibernation works correctly with self-compiled 6.7.9. Trying to use "no_console_suspend" to debug next. Will not do bisect between major kernel releases on a production machine. [ 409.847217] PM: hibernation: hibernation entry [ 409.874672] Filesystems sync: 0.027 seconds [ 409.875204] Freezing user space processes [ 409.877765] Freezing user space processes completed (elapsed 0.002 seconds) [ 409.877770] OOM killer disabled. [ 409.878027] PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff] [ 409.878031] PM: hibernation: Marking nosave pages: [mem 0x0009f000-0x000fffff] [ 409.878034] PM: hibernation: Marking nosave pages: [mem 0x09c00000-0x09d00fff] [ 409.878039] PM: hibernation: Marking nosave pages: [mem 0x09f00000-0x09f0ffff] [ 409.878041] PM: hibernation: Marking nosave pages: [mem 0xa2356000-0xa2356fff] [ 409.878042] PM: hibernation: Marking nosave pages: [mem 0xa2363000-0xa2364fff] [ 409.878043] PM: hibernation: Marking nosave pages: [mem 0xa2372000-0xa2373fff] [ 409.878045] PM: hibernation: Marking nosave pages: [mem 0xa2384000-0xa2384fff] [ 409.878046] PM: hibernation: Marking nosave pages: [mem 0xb9c57000-0xb9ce7fff] [ 409.878049] PM: hibernation: Marking nosave pages: [mem 0xbd9de000-0xcc3fdfff] [ 409.878530] PM: hibernation: Marking nosave pages: [mem 0xce000000-0xffffffff] [ 409.879306] PM: hibernation: Basic memory bitmaps created [ 409.884500] PM: hibernation: Preallocating image memory [ 412.146014] PM: hibernation: Allocated 2800864 pages for snapshot [ 412.146022] PM: hibernation: Allocated 11203456 kbytes in 2.26 seconds (4957.28 MB/s) [ 412.146025] Freezing remaining freezable tasks [ 412.147610] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 412.147829] printk: Suspending console(s) (use no_console_suspend to debug) [ 412.158400] port 0000:02:00.1:0.0: PM: dpm_run_callback(): pm_runtime_force_suspend+0x0/0x120 returns -16 [ 412.158418] port 0000:02:00.1:0.0: PM: failed to freeze: error -16 [ 413.879379] PM: hibernation: Basic memory bitmaps freed [ 413.879847] OOM killer enabled. [ 413.879852] Restarting tasks ... done. [ 413.882304] PM: hibernation: hibernation exit Best, -- Martin
On Fri, 15 Mar 2024 at 19:11, Radek Podgorny <radek@podgorny.cz> wrote:
>
> ok, will. the kernel with previous patch is still compiling so i'll
> queue it. ;-)
>
> anyway, should i apply this as a separate patch or as an addition to the
> previous one (the one with bss.efistub addition)?
>
Only this one change please.
[-- Attachment #1.1: Type: text/plain, Size: 1743 bytes --] ok, will. the kernel with previous patch is still compiling so i'll queue it. ;-) anyway, should i apply this as a separate patch or as an addition to the previous one (the one with bss.efistub addition)? r. On 3/15/24 18:48, Ard Biesheuvel wrote: > On Fri, 15 Mar 2024 at 17:24, Radek Podgorny <radek@podgorny.cz> wrote: >> >> it's systemd-boot. attaching bootctl output. now looking at it, it seems >> that while systemd (and systemd-boot) gets timely updates on my system >> (currently at 255.4), the stub (is this how it's called?) does not get >> updated automatically in the efi partition (still at version 244?). >> >> i can try to update it. but i'll wait for your instructions since this >> may be some rare situation and we may use it for testing. >> >> anyway, i'm compiling new kernel with your suggested changes right now >> so i'll let you know how it turned out, soon. >> >> r. >> >> p.s.: ha! nevermind, i just checked the other systems which boot fine >> and they also are on stub (?) 244 so it's probably not the cause. >> > > OK that makes sense. > > I installed Arch linux in a VM (what a pain!) but I don't think the > distro has anything to do with it. > > I did realize that reverting that patch is not going to be a full > solution in any case. > > Could you please try whether the following fix works for you? > > --- a/drivers/firmware/efi/libstub/x86-stub.c > +++ b/drivers/firmware/efi/libstub/x86-stub.c > @@ -473,6 +473,9 @@ > int options_size = 0; > efi_status_t status; > char *cmdline_ptr; > + extern char _bss[], _ebss[]; > + > + memset(_bss, 0, _ebss - _bss); > > efi_system_table = sys_table_arg; [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --]
On Fri, 15 Mar 2024 at 17:24, Radek Podgorny <radek@podgorny.cz> wrote:
>
> it's systemd-boot. attaching bootctl output. now looking at it, it seems
> that while systemd (and systemd-boot) gets timely updates on my system
> (currently at 255.4), the stub (is this how it's called?) does not get
> updated automatically in the efi partition (still at version 244?).
>
> i can try to update it. but i'll wait for your instructions since this
> may be some rare situation and we may use it for testing.
>
> anyway, i'm compiling new kernel with your suggested changes right now
> so i'll let you know how it turned out, soon.
>
> r.
>
> p.s.: ha! nevermind, i just checked the other systems which boot fine
> and they also are on stub (?) 244 so it's probably not the cause.
>
OK that makes sense.
I installed Arch linux in a VM (what a pain!) but I don't think the
distro has anything to do with it.
I did realize that reverting that patch is not going to be a full
solution in any case.
Could you please try whether the following fix works for you?
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -473,6 +473,9 @@
int options_size = 0;
efi_status_t status;
char *cmdline_ptr;
+ extern char _bss[], _ebss[];
+
+ memset(_bss, 0, _ebss - _bss);
efi_system_table = sys_table_arg;
[-- Attachment #1.1.1: Type: text/plain, Size: 1431 bytes --] it's systemd-boot. attaching bootctl output. now looking at it, it seems that while systemd (and systemd-boot) gets timely updates on my system (currently at 255.4), the stub (is this how it's called?) does not get updated automatically in the efi partition (still at version 244?). i can try to update it. but i'll wait for your instructions since this may be some rare situation and we may use it for testing. anyway, i'm compiling new kernel with your suggested changes right now so i'll let you know how it turned out, soon. r. p.s.: ha! nevermind, i just checked the other systems which boot fine and they also are on stub (?) 244 so it's probably not the cause. On 3/15/24 17:08, Ard Biesheuvel wrote: > On Fri, 15 Mar 2024 at 16:33, Ard Biesheuvel <ardb@kernel.org> wrote: >> >> On Fri, 15 Mar 2024 at 15:12, Radek Podgorny <radek@podgorny.cz> wrote: >>> >>> hi ard, thanks for the effort! >>> >>> so, your first recommended patch (the memset thing), applied to current >>> mainline (6.8) DOES NOT resolve the issue. >>> >>> the second recommendation, a revert patch, applied to the same mainline >>> tree, indeed DOES resolve the problem. >>> >>> just to be sure, i'm attaching the revert patch. >>> >> >> Actually, that is not the patch I had in mind. >> >> Please revert >> >> x86/efi: Drop EFI stub .bss from .data section >> > > BTW which bootloader are you using? [-- Attachment #1.1.2: bootctl.txt --] [-- Type: text/plain, Size: 3663 bytes --] ^[[0mSystem: Firmware: UEFI 2.31 (American Megatrends 4.651) Firmware Arch: x64 Secure Boot: disabled (unsupported) TPM2 Support: no Measured UKI: no Boot into FW: not supported ^[[0mCurrent Boot Loader: Product: systemd-boot 244-1-arch Features: ✓ Boot counting ✓ Menu timeout control ✓ One-shot menu timeout control ✓ Default entry control ✓ One-shot entry control ✓ Support for XBOOTLDR partition ✓ Support for passing random seed to OS ✗ Load drop-in drivers ✗ Support Type #1 sort-key field ✗ Support @saved pseudo-entry ✗ Support Type #1 devicetree field ✗ Enroll SecureBoot keys ✗ Retain SHIM protocols ✗ Menu can be disabled ✓ Boot loader sets ESP information ESP: /dev/disk/by-partuuid/2adefc75-3da0-4c3d-9449-ea0114a4b281 File: └─/EFI/systemd/systemd-bootx64.efi ^[[0mRandom Seed: System Token: set Exists: yes ^[[0mAvailable Boot Loaders on ESP: ESP: /boot (/dev/disk/by-partuuid/2adefc75-3da0-4c3d-9449-ea0114a4b281) File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 244-1-arch) └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 244-1-arch) ^[[0mBoot Loaders Listed in EFI Variables: Title: Linux Boot Manager ID: 0x0009 Status: active, boot-order Partition: /dev/disk/by-partuuid/2adefc75-3da0-4c3d-9449-ea0114a4b281 File: └─/EFI/systemd/systemd-bootx64.efi Title: Linux Boot Manager ID: 0x0008 Status: active, boot-order Partition: /dev/disk/by-partuuid/dacde831-60af-4f8c-bbb2-c4b03a3265e4 File: └─/EFI/systemd/systemd-bootx64.efi Title: Linux Boot Manager ID: 0x0001 Status: active, boot-order Partition: /dev/disk/by-partuuid/f9169784-d163-4c58-a95d-26deb4145714 File: └─/EFI/systemd/systemd-bootx64.efi Title: Linux Boot Manager ID: 0x0004 Status: active, boot-order Partition: /dev/disk/by-partuuid/ed77cf92-2acd-4e2b-be07-b6f1e4cded29 File: └─/EFI/systemd/systemd-bootx64.efi Title: Linux Boot Manager ID: 0x0000 Status: active, boot-order Partition: /dev/disk/by-partuuid/ca18d734-d8b3-48f8-b68e-3e4ae919e0c6 File: └─/EFI/systemd/systemd-bootx64.efi Title: Linux Boot Manager ID: 0x0002 Status: active, boot-order Partition: /dev/disk/by-partuuid/896b1d31-733e-417a-a740-a787acff3f15 File: └─/EFI/systemd/systemd-bootx64.efi Title: Linux Boot Manager ID: 0x0003 Status: active, boot-order Partition: /dev/disk/by-partuuid/e7bf6fc5-0bf6-4dc2-8116-c2dbc8999a54 File: └─/EFI/systemd/systemd-bootx64.efi Title: Linux Boot Manager ID: 0x0006 Status: active, boot-order Partition: /dev/disk/by-partuuid/6d9fa765-a4c9-4723-becf-61105a9d1f30 File: └─/EFI/systemd/systemd-bootx64.efi ^[[0mBoot Loader Entries: $BOOT: /boot (/dev/disk/by-partuuid/2adefc75-3da0-4c3d-9449-ea0114a4b281) token: arch ^[[0mDefault Boot Loader Entry: type: Boot Loader Specification Type #1 (.conf) title: Arch Linux id: arch.conf source: /boot//loader/entries/arch.conf linux: /boot//vmlinuz-linux initrd: /boot//intel-ucode.img /boot//initramfs-linux.img options: root=/dev/disk/by-label/MATLA_ROOT rw [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --]
On Fri, 15 Mar 2024 at 16:33, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 15 Mar 2024 at 15:12, Radek Podgorny <radek@podgorny.cz> wrote:
> >
> > hi ard, thanks for the effort!
> >
> > so, your first recommended patch (the memset thing), applied to current
> > mainline (6.8) DOES NOT resolve the issue.
> >
> > the second recommendation, a revert patch, applied to the same mainline
> > tree, indeed DOES resolve the problem.
> >
> > just to be sure, i'm attaching the revert patch.
> >
>
> Actually, that is not the patch I had in mind.
>
> Please revert
>
> x86/efi: Drop EFI stub .bss from .data section
>
BTW which bootloader are you using?