Lots of burn-in testing needed before signing, upstreaming.
NOTE: I set default Y to maximize testing by default.
Is there a better way to do this ?
Signed-off-by: Jim Cromie <[email protected]>
---
drivers/gpu/drm/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index ba3fb04bb691..ff478fcba67e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -52,8 +52,7 @@ config DRM_DEBUG_MM
config DRM_USE_DYNAMIC_DEBUG
bool "use dynamic debug to implement drm.debug"
- default n
- depends on BROKEN
+ default y
depends on DRM
depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
depends on JUMP_LABEL
--
2.41.0
hi, Jim Cromie,
we send this report to you to consult that if there is any limitation to use
this CONFIG_DRM_USE_DYNAMIC_DEBUG?
attached config is a randconfig which has CONFIG_DRM_USE_DYNAMIC_DEBUG, the
kernel built with it failed to boot in our tests, but we also tested with some
other config then the issue cannot reproduce.
below full report FYI.
Hello,
kernel test robot noticed "WARNING:at_lib/dynamic_debug.c:#ddebug_add_module" on:
commit: fb82a8bb4e30dcf042c48563987ad3a24a416f5d ("[Intel-gfx] [PATCH v5 19/22] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN")
url: https://github.com/intel-lab-lkp/linux/commits/Jim-Cromie/drm-use-correct-ccflags-y-syntax/20230802-010749
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link: https://lore.kernel.org/all/[email protected]/
patch subject: [Intel-gfx] [PATCH v5 19/22] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN
in testcase: boot
compiler: gcc-12
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
(please refer to attached dmesg/kmsg for entire log/backtrace)
+---------------------------------------------------+------------+------------+
| | 65140d4c78 | fb82a8bb4e |
+---------------------------------------------------+------------+------------+
| boot_successes | 9 | 0 |
| boot_failures | 0 | 9 |
| WARNING:at_lib/dynamic_debug.c:#ddebug_add_module | 0 | 9 |
| RIP:ddebug_add_module | 0 | 9 |
| canonical_address#:#[##] | 0 | 9 |
| RIP:ddebug_apply_params | 0 | 9 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 9 |
+---------------------------------------------------+------------+------------+
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-lkp/[email protected]
[ 160.100324][ T1] ------------[ cut here ]------------
[ 160.101595][ T1] WARNING: CPU: 0 PID: 1 at lib/dynamic_debug.c:1276 ddebug_add_module+0x4d6/0xe60
[ 160.102398][ T1] Modules linked in:
[ 160.103308][ T1] CPU: 0 PID: 1 Comm: swapper Tainted: G T 6.5.0-rc2-00390-gfb82a8bb4e30 #1 b775713fd4db82275e1a7a7db67cb8700a0f04d5
[ 160.105851][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 160.107741][ T1] RIP: 0010:ddebug_add_module+0x4d6/0xe60
[ 160.109484][ T1] Code: 0f b6 04 28 84 c0 74 08 3c 03 0f 8e 6f 06 00 00 48 8b 44 24 20 8b 50 20 41 39 d6 0f 83 f6 00 00 00 4d 85 e4 0f 85 48 ff ff ff <0f> 0b eb
c0 48 8b 44 24 30 80 38 00 0f 85 4b 07 00 00 4c 89 63 28
[ 160.112874][ T1] RSP: 0000:ffffc9000001fca0 EFLAGS: 00010246
[ 160.114265][ T1] RAX: 1ffffffff15aebdb RBX: ffff888110da5280 RCX: 1ffff92000003fb6
[ 160.115682][ T1] RDX: 1ffff110221b4a55 RSI: 0000000000000003 RDI: ffffffff8ad75ee0
[ 160.117200][ T1] RBP: ffffffff873e7040 R08: 0000000000000000 R09: 0000000000000000
[ 160.118881][ T1] R10: ffff888110da52a8 R11: 0000000000000000 R12: ffffffff8ad75ed8
[ 160.120444][ T1] R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000
[ 160.122329][ T1] FS: 0000000000000000(0000) GS:ffffffff88d36000(0000) knlGS:0000000000000000
[ 160.124024][ T1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 160.125391][ T1] CR2: ffff88843ffff000 CR3: 0000000008d03000 CR4: 00000000000406f0
[ 160.127038][ T1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 160.128981][ T1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 160.130732][ T1] Call Trace:
[ 160.132054][ T1] <TASK>
[ 160.132822][ T1] ? __warn+0xc7/0x240
[ 160.133787][ T1] ? ddebug_add_module+0x4d6/0xe60
[ 160.135430][ T1] ? report_bug+0x23f/0x2b0
[ 160.136388][ T1] ? handle_bug+0x3c/0x70
[ 160.137284][ T1] ? exc_invalid_op+0x17/0x50
[ 160.138305][ T1] ? asm_exc_invalid_op+0x1a/0x20
[ 160.138791][ T1] ? ddebug_add_module+0x4d6/0xe60
[ 160.139985][ T1] dynamic_debug_init+0x25f/0x7a0
[ 160.142169][ T1] ? dynamic_debug_init_control+0x130/0x130
[ 160.143423][ T1] ? rng_is_initialized+0x20/0x20
[ 160.144508][ T1] ? dynamic_debug_init_control+0x130/0x130
[ 160.145538][ T1] do_one_initcall+0x98/0x310
[ 160.146598][ T1] ? trace_event_raw_event_initcall_level+0x180/0x180
[ 160.148400][ T1] ? arch_irq_work_raise+0x8a/0x110
[ 160.149532][ T1] kernel_init_freeable+0x1fb/0x4f0
[ 160.150688][ T1] ? rest_init+0x220/0x220
[ 160.152078][ T1] kernel_init+0x1f/0x1e0
[ 160.153048][ T1] ? _raw_spin_unlock_irq+0x28/0x50
[ 160.154172][ T1] ret_from_fork+0x31/0x70
[ 160.155058][ T1] ? rest_init+0x220/0x220
[ 160.156034][ T1] ret_from_fork_asm+0x11/0x20
[ 160.157085][ T1] RIP: 0000:0x0
[ 160.157907][ T1] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[ 160.158910][ T1] RSP: 0000:0000000000000000 EFLAGS: 00000000 ORIG_RAX: 0000000000000000
[ 160.160706][ T1] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 160.162296][ T1] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 160.165053][ T1] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 160.166755][ T1] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[ 160.168389][ T1] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 160.171762][ T1] </TASK>
[ 160.172480][ T1] irq event stamp: 2561
[ 160.173373][ T1] hardirqs last enabled at (2571): [<ffffffff812eebb0>] __up_console_sem+0x60/0x80
[ 160.175651][ T1] hardirqs last disabled at (2582): [<ffffffff812eeb95>] __up_console_sem+0x45/0x80
[ 160.177661][ T1] softirqs last enabled at (2060): [<ffffffff86715ee4>] __do_softirq+0x384/0x729
[ 160.179047][ T1] softirqs last disabled at (2051): [<ffffffff811e249f>] irq_exit_rcu+0x8f/0xc0
[ 160.182321][ T1] ---[ end trace 0000000000000000 ]---
[ 160.185285][ T1] general protection fault, probably for non-canonical address 0xebee69ad6bedaec8: 0000 [#1] PREEMPT KASAN
[ 160.187519][ T1] KASAN: maybe wild-memory-access in range [0x5f736d6b5f6d7640-0x5f736d6b5f6d7647]
[ 160.188373][ T1] CPU: 0 PID: 1 Comm: swapper Tainted: G W T 6.5.0-rc2-00390-gfb82a8bb4e30 #1 b775713fd4db82275e1a7a7db67cb8700a0f04d5
[ 160.188373][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 160.188373][ T1] RIP: 0010:ddebug_apply_params+0x63/0x520
[ 160.188373][ T1] Code: 48 85 ed 0f 84 54 02 00 00 83 f8 01 0f 8f e4 00 00 00 48 8d bd e0 03 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 2a 04 00 00 48 8d bd a0 03 00 00 4c 8b a5 e0 03
[ 160.188373][ T1] RSP: 0000:ffffc9000001fc50 EFLAGS: 00010203
[ 160.188373][ T1] RAX: dffffc0000000000 RBX: ffffffff873e7040 RCX: dffffc0000000000
[ 160.188373][ T1] RDX: 0bee6dad6bedaec8 RSI: 0000000000000000 RDI: 5f736d6b5f6d7644
[ 160.188373][ T1] RBP: 5f736d6b5f6d7264 R08: 0000000000000000 R09: 0000000000000000
[ 160.188373][ T1] R10: ffff888110da52a8 R11: 0000000000000000 R12: fffff52000003fb8
[ 160.188373][ T1] R13: ffffffff8ad75ee8 R14: 0000000000000001 R15: dffffc0000000000
[ 160.188373][ T1] FS: 0000000000000000(0000) GS:ffffffff88d36000(0000) knlGS:0000000000000000
[ 160.188373][ T1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 160.188373][ T1] CR2: ffffffffffffffd6 CR3: 0000000008d03000 CR4: 00000000000406f0
[ 160.188373][ T1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 160.188373][ T1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 160.188373][ T1] Call Trace:
[ 160.188373][ T1] <TASK>
[ 160.188373][ T1] ? die_addr+0x40/0xa0
[ 160.188373][ T1] ? exc_general_protection+0x111/0x1e0
[ 160.188373][ T1] ? asm_exc_general_protection+0x26/0x30
[ 160.188373][ T1] ? ddebug_apply_params+0x63/0x520
[ 160.188373][ T1] ddebug_add_module+0x674/0xe60
[ 160.188373][ T1] dynamic_debug_init+0x25f/0x7a0
[ 160.188373][ T1] ? dynamic_debug_init_control+0x130/0x130
[ 160.188373][ T1] ? rng_is_initialized+0x20/0x20
[ 160.188373][ T1] ? dynamic_debug_init_control+0x130/0x130
[ 160.188373][ T1] do_one_initcall+0x98/0x310
[ 160.188373][ T1] ? trace_event_raw_event_initcall_level+0x180/0x180
[ 160.188373][ T1] ? arch_irq_work_raise+0x8a/0x110
[ 160.188373][ T1] kernel_init_freeable+0x1fb/0x4f0
[ 160.188373][ T1] ? rest_init+0x220/0x220
[ 160.188373][ T1] kernel_init+0x1f/0x1e0
[ 160.188373][ T1] ? _raw_spin_unlock_irq+0x28/0x50
[ 160.188373][ T1] ret_from_fork+0x31/0x70
[ 160.188373][ T1] ? rest_init+0x220/0x220
[ 160.188373][ T1] ret_from_fork_asm+0x11/0x20
[ 160.188373][ T1] RIP: 0000:0x0
[ 160.188373][ T1] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[ 160.188373][ T1] RSP: 0000:0000000000000000 EFLAGS: 00000000 ORIG_RAX: 0000000000000000
[ 160.188373][ T1] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 160.188373][ T1] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 160.188373][ T1] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 160.188373][ T1] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[ 160.188373][ T1] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 160.188373][ T1] </TASK>
[ 160.188373][ T1] Modules linked in:
[ 160.188598][ T12] Callback from call_rcu_tasks_rude() invoked.
[ 160.191769][ T13] Callback from call_rcu_tasks_trace() invoked.
[ 160.193039][ T1] ---[ end trace 0000000000000000 ]---
[ 160.195146][ T1] RIP: 0010:ddebug_apply_params+0x63/0x520
[ 160.198738][ T1] Code: 48 85 ed 0f 84 54 02 00 00 83 f8 01 0f 8f e4 00 00 00 48 8d bd e0 03 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 2a 04 00 00 48 8d bd a0 03 00 00 4c 8b a5 e0 03
[ 160.202579][ T1] RSP: 0000:ffffc9000001fc50 EFLAGS: 00010203
[ 160.204178][ T1] RAX: dffffc0000000000 RBX: ffffffff873e7040 RCX: dffffc0000000000
[ 160.205499][ T1] RDX: 0bee6dad6bedaec8 RSI: 0000000000000000 RDI: 5f736d6b5f6d7644
[ 160.207053][ T1] RBP: 5f736d6b5f6d7264 R08: 0000000000000000 R09: 0000000000000000
[ 160.208839][ T1] R10: ffff888110da52a8 R11: 0000000000000000 R12: fffff52000003fb8
[ 160.210401][ T1] R13: ffffffff8ad75ee8 R14: 0000000000000001 R15: dffffc0000000000
[ 160.212172][ T1] FS: 0000000000000000(0000) GS:ffffffff88d36000(0000) knlGS:0000000000000000
[ 160.213927][ T1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 160.215394][ T1] CR2: ffffffffffffffd6 CR3: 0000000008d03000 CR4: 00000000000406f0
[ 160.216967][ T1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 160.218373][ T1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 160.218858][ T1] Kernel panic - not syncing: Fatal exception
To reproduce:
# build kernel
cd linux
cp config-6.5.0-rc2-00390-gfb82a8bb4e30 .config
make HOSTCC=gcc-12 CC=gcc-12 ARCH=x86_64 olddefconfig prepare modules_prepare bzImage modules
make HOSTCC=gcc-12 CC=gcc-12 ARCH=x86_64 INSTALL_MOD_PATH=<mod-install-dir> modules_install
cd <mod-install-dir>
find lib/ | cpio -o -H newc --quiet | gzip > modules.cgz
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> -m modules.cgz job-script # job-script is attached in this email
# if come across any failure that blocks the test,
# please remove ~/.lkp and /lkp dir to run from a clean state.
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Thu, Aug 3, 2023 at 1:14 AM kernel test robot <[email protected]> wrote:
>
>
> hi, Jim Cromie,
>
> we send this report to you to consult that if there is any limitation to use
> this CONFIG_DRM_USE_DYNAMIC_DEBUG?
> attached config is a randconfig which has CONFIG_DRM_USE_DYNAMIC_DEBUG, the
> kernel built with it failed to boot in our tests, but we also tested with some
> other config then the issue cannot reproduce.
>
> below full report FYI.
>
> To reproduce:
>
> # build kernel
> cd linux
> cp config-6.5.0-rc2-00390-gfb82a8bb4e30 .config
> make HOSTCC=gcc-12 CC=gcc-12 ARCH=x86_64 olddefconfig prepare modules_prepare bzImage modules
> make HOSTCC=gcc-12 CC=gcc-12 ARCH=x86_64 INSTALL_MOD_PATH=<mod-install-dir> modules_install
> cd <mod-install-dir>
> find lib/ | cpio -o -H newc --quiet | gzip > modules.cgz
>
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k <bzImage> -m modules.cgz job-script # job-script is attached in this email
>
> # if come across any failure that blocks the test,
> # please remove ~/.lkp and /lkp dir to run from a clean state.
>
I have recapitulated this, except I used make.cross , and the gcc I
had that was close.
If I can get the test to run, maybe I can get the same error.
If I run to completion, I'll return to get a closer match on gcc version.
Ive gotten to qemu, but its failing on "initrd is too large"
[jimc@frodo lkp-tests]$ bin/lkp qemu -k
/home/jimc/projects/lx/wk-suren/builds/8-3-lkp/./arch/x86_64/boot/bzImage
-m /home/jimc/projects/lx/wk-suren/builds/8-3-lkp/Imods/modules.cgz
~/Downloads/job-script
try-run: /home/jimc/projects/lkp-tests/bin/qemu
try-run: /home/jimc/projects/lkp-tests/sbin/qemu
try-run: /home/jimc/projects/lkp-tests/tools/qemu
try-run: /home/jimc/projects/lkp-tests/lkp-exec/qemu
~/projects/lkp-tests/pkg/lkp-src ~/projects/lkp-tests
x86_64
==> Making package: lkp-src 0-1 (Thu Aug 3 01:37:51 PM MDT 2023)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Removing existing $pkgdir/ directory...
==> Starting build()...
make: Entering directory '/home/jimc/projects/lkp-tests/bin/event'
gcc -D_FORTIFY_SOURCE=2 -c -o wakeup.o wakeup.c
In file included from /usr/include/sys/types.h:25,
from wakeup.c:1:
/usr/include/features.h:413:4: warning: #warning _FORTIFY_SOURCE
requires compiling with optimization (-O) [-Wcpp]
413 | # warning _FORTIFY_SOURCE requires compiling with optimization (-O)
| ^~~~~~~
gcc -Wl,-O1,--sort-common,--as-needed,-z,relro -static -o wakeup wakeup.o
rm -f wakeup.o
strip wakeup
make: Leaving directory '/home/jimc/projects/lkp-tests/bin/event'
==> Entering fakeroot environment...
x86_64
==> Starting package()...
==> Creating package "lkp-src"...
14610330 blocks
renamed '/home/jimc/.lkp/cache/lkp-x86_64.cgz.tmp' ->
'/home/jimc/.lkp/cache/lkp-x86_64.cgz'
==> Leaving fakeroot environment.
==> Finished making: lkp-src 0-1 (Thu Aug 3 01:42:18 PM MDT 2023)
~/projects/lkp-tests
result_root: /home/jimc/.lkp//result/boot/1/vm-snb/yocto-i386-minimal-20190520.cgz/x86_64-randconfig-x015-20230731/gcc-12/fb82a8bb4e30dcf042c48563987ad3a24a416f5d/8
downloading initrds ...
use local modules: /home/jimc/.lkp/cache/modules.cgz
skip downloading
/home/jimc/.lkp/cache/osimage/yocto/yocto-i386-minimal-20190520.cgz
17916 blocks
exec command: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -m 8G
-fsdev local,id=test_dev,path=/home/jimc/.lkp//result/boot/1/vm-snb/yocto-i386-minimal-20190520.cgz/x86_64-randconfig-x015-20230731/gcc-12/fb82a8bb4e30dcf042c48563987ad3a24a416f5d/8,security_model=none
-device virtio-9p-pci,fsdev=test_dev,mount_tag=9p/virtfs_mount -kernel
/home/jimc/projects/lx/wk-suren/builds/8-3-lkp/./arch/x86_64/boot/bzImage
-append root=/dev/ram0
RESULT_ROOT=/result/boot/1/vm-snb/yocto-i386-minimal-20190520.cgz/x86_64-randconfig-x015-20230731/gcc-12/fb82a8bb4e30dcf042c48563987ad3a24a416f5d/3
BOOT_IMAGE=/pkg/linux/x86_64-randconfig-x015-20230731/gcc-12/fb82a8bb4e30dcf042c48563987ad3a24a416f5d/vmlinuz-6.5.0-rc2-00390-gfb82a8bb4e30
branch=linux-review/Jim-Cromie/drm-use-correct-ccflags-y-syntax/20230802-010749
job=/lkp/jobs/scheduled/vm-meta-58/boot-1-yocto-i386-minimal-20190520.cgz-x86_64-randconfig-x015-20230731-fb82a8bb4e30-20230803-93950-6g16ti-3.yaml
user=lkp ARCH=x86_64 kconfig=x86_64-randconfig-x015-20230731
commit=fb82a8bb4e30dcf042c48563987ad3a24a416f5d nmi_watchdog=0
vmalloc=256M initramfs_async=0 page_owner=on max_uptime=600
LKP_LOCAL_RUN=1 selinux=0 debug apic=debug sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on
panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic
load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8
systemd.log_level=err ignore_loglevel console=tty0
earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw ip=dhcp
result_service=9p/virtfs_mount -initrd
/home/jimc/.lkp/cache/final_initrd -smp 2 -m 1312M -no-reboot -device
i6300esb -rtc base=localtime -device e1000,netdev=net0 -netdev
user,id=net0 -display none -monitor null -serial stdio
qemu: initrd is too large, cannot support.(max: 1375567871, need 6117354712)
looking at qemu.git src (Im probly running fedora's version) but its
gotta be close..
[jimc@frodo qemu]$ ack -B3 -A3 'initrd is too large'
hw/i386/x86.c
878- initrd_size = g_mapped_file_get_length(mapped_file);
879- initrd_max = x86ms->below_4g_mem_size - acpi_data_size - 1;
880- if (initrd_size >= initrd_max) {
881: fprintf(stderr, "qemu: initrd is too large,
cannot support."
882- "(max: %"PRIu32", need %"PRId64")\n",
883- initrd_max, (uint64_t)initrd_size);
884- exit(1);
--
1023- initrd_data = g_mapped_file_get_contents(mapped_file);
1024- initrd_size = g_mapped_file_get_length(mapped_file);
1025- if (initrd_size >= initrd_max) {
1026: fprintf(stderr, "qemu: initrd is too large, cannot support."
1027- "(max: %"PRIu32", need %"PRId64")\n",
1028- initrd_max, (uint64_t)initrd_size);
1029- exit(1);
This doesnt seem like this is a limitation I can just hack around.
why is it in i386 anyway ?
Im surprised JUMP_LABEL is supported on i386
>
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
>
>
On Thu, Aug 3, 2023 at 1:14 AM kernel test robot <[email protected]> wrote:
>
>
> hi, Jim Cromie,
>
> we send this report to you to consult that if there is any limitation to use
> this CONFIG_DRM_USE_DYNAMIC_DEBUG?
> attached config is a randconfig which has CONFIG_DRM_USE_DYNAMIC_DEBUG, the
> kernel built with it failed to boot in our tests, but we also tested with some
> other config then the issue cannot reproduce.
>
Theres no limitation I know of - particularly not CONFIG related
on an earlier version, I saw some odd transient / red-herring
linker-errors (collisions on __UNIQUE_ID constructs)
on s390, mips, older gcc (iirc - I could go find it in lkp-reports if
its meaningful)
that had me hacking at the fallback which uses __LINE__
But this seems different.