| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAJfuBxz1RT-U_Pphz11CPv4u+SOioBTkOYOVmDvscZJ-jM7Wng@mail.gmail.com>
Date: Thu, 3 Aug 2023 14:04:10 -0600
From: jim.cromie@...il.com
To: kernel test robot <oliver.sang@...el.com>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com,
dri-devel@...ts.freedesktop.org, daniel.vetter@...ll.ch,
daniel@...ll.ch, jbaron@...mai.com, gregkh@...uxfoundation.org,
linux-kernel@...r.kernel.org, amd-gfx@...ts.freedesktop.org,
intel-gvt-dev@...ts.freedesktop.org,
intel-gfx@...ts.freedesktop.org, jani.nikula@...el.com,
linux@...musvillemoes.dk, seanpaul@...omium.org, joe@...ches.com
Subject: Re: [Intel-gfx] [PATCH v5 19/22] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG
un-BROKEN
On Thu, Aug 3, 2023 at 1:14 AM kernel test robot <oliver.sang@...el.com> 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@...do 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@...do 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
>
>
Powered by blists - more mailing lists