Control: tags -1 + moreinfo unreproducible Hi Jörn,
On Sat, May 18, 2024 at 09:37:03AM +0200, Jörn Heusipp wrote: > Package: src:linux > Version: 6.7.12-1 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: osm...@problemloesungsmaschine.de > > Hello Debian kernel team! > > > Linux 6.7.12-1 (686-pae) fails to boot for me on this system. > > It hangs right after: > === > Loading Linux 6.7.12-686-pae ... > Loading initial ramdisk ... > === > > Booting with 'earlyprintk=vga', I managed to capture a stack trace on video. I > stitched together an image showing it as a whole: > <https://manx.datengang.de/temp/linux-6.7.12-crash.png>, and also attached. > > Trimmed transcription (might contain typos) of the crash (I can transcribe all > of it if really needed, but I figured the type of crash and the trace itself > could be sufficient): > === > BUG: kernel NULL pointer dereference, address: 00000010 > #PF: supervisor write access in kernel mode > #PF: error_code(0x0002) - not-present page > Oops: 0002 [#1] PREEMPT SMP NOPTI > [...] > EIP: __ring_buffer_alloc+0x32/0x194 > [...] > show_regs > __die > page_fault_oops > kernelmode_fixup_or_oops.constprop > __bad_area_nosemaphore.constprop > bad_area_nosemaphore > do_user_addr_fault > prb_read_valid > exc_page_fault > pvclock_clocksource_read_nowd > handle_exception > pvclock_clocksource_read_nowd > __ring_buffer_alloc > pvclock_clocksource_read_nowd > __ring_buffer_alloc > early_trace_init > start_kernel > i386_start_kernel > startup_32_smp > [...] > === > > The line immediately before the crash reads > "ftrace: allocated 78 pages with 4 groups". > > linux 6.8.9-1 (686-pae) from unstable shows the same behaviour; it also > crashes. > > I am still running 6.6.15-2 on this box for now, which works completely fine > (as did all Debian Testing kernels since at least the 2.6.32 days on this > particular box). 6.7.12-1 (amd64) also works fine on all of my amd64 boxes. I cannot reproduce this problem. If you still can with the recent 6.8.11-1 landed in unstable, you might try to bisect the changes in upstream kernel to determine the breaking commit? Regards, Salvatore
