Re: [Intel-gfx] [PATCH v5 19/22] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN

From: jim . cromie
Date: Thu Aug 03 2023 - 16:04:43 EST


On Thu, Aug 3, 2023 at 1:14 AM kernel test robot <oliver.sang@xxxxxxxxx> 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
>
>