Re: Debian initramfs/initrd, was Re: stack smashing detected
Hi Geert, On 2/6/23 12:52 AM, Geert Uytterhoeven wrote: > Hi Stan, > > On Mon, Feb 6, 2023 at 4:42 AM Stan Johnson wrote: >> On an SE/30 with 128 MiB memory, the latest Debian SID kernel >> (vmlinux-6.1.0-2-m68k), using Debian SID modules, and with >> initrd-6.1.0-2-m68k built on the SE/30, hangs after the initial >> "ABCFGHIJK" (I tried it twice). > > If you get to "K", you're almost at the end of arch/m68k/kernel/head.S, > and it is very likely the kernel C-code actually started. > Do you get any output using "debug earlyprintk" on the kernel command > line? > ... Please see the attached serial console log, which all happened within an hour after I set the Penguin loose (I have Penguin-19 configured to use 32768 K memory). There was nothing more after two additional hours. Creation of the initrd completed normally (and I know now that I can just use the one that gets created in QEMU), and I confirmed the MD5 checksums of the kernel and initrd after copying them to MacOS. -Stan ABCFGHIJK [0.00] Linux version 6.1.0-2-m68k (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-12) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90 .20230104) #1 Debian 6.1.7-1 (2023-01-18) [0.00] printk: debug: ignoring loglevel setting. [0.00] printk: bootconsole [debug0] enabled [0.00] Detected Macintosh model: 9 [0.00] Penguin bootinfo data: [0.00] Video: addr 0xfee08040 row 0x40 depth 1 dimensions 512 x 342 [0.00] Videological 0xf0208040 phys. 0xfee08040, SCC at 0x50f04000 [0.00] Boottime: 0x63e0cc5b GMTBias: 0xfe5c [0.00] Machine ID: 9 CPUid: 0x1 memory size: 0x80 [0.00] Apple Macintosh SE/30 [0.00] initrd: 077d8c00 - 0800 [0.00] Zone ranges: [0.00] DMA [mem 0x-0x007f] [0.00] Normal empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x07ff] [0.00] Initmem setup node 0 [mem 0x-0x07ff] [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 32448 [0.00] Kernel command line: root=/dev/sda5 console=tty0 console=ttyS0,38400n8 ignore_loglevel earlyprintk [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) [0.00] Sorting __ex_table... [0.00] mem auto-init: stack:all(zero), heap alloc:on, heap free:off [0.00] Memory: 115716K/131072K available (3647K kernel code, 583K rwdata, 1168K rodata, 168K init, 179K bss, 15356K reserved, 0K cma-reserved) [0.00] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS: 200 [0.00] clocksource: via1: mask: 0x max_cycles: 0x, max_idle_ns: 2439823894983 ns [0.04] Console: colour dummy device 80x25 [0.21] printk: console [tty0] enabled [0.22] printk: console [ttyS0] enabled [0.22] printk: console [ttyS0] enabled [0.26] printk: bootconsole [debug0] disabled [0.26] printk: bootconsole [debug0] disabled [0.30] Calibrating delay loop... 3.48 BogoMIPS (lpj=17408) [0.46] pid_max: default: 32768 minimum: 301 [0.82] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.84] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [1.47] cblist_init_generic: Setting adjustable number of callback queues. [1.48] cblist_init_generic: Setting shift to 0 and lim to 1. [1.70] devtmpfs: initialized [2.02] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [2.05] futex hash table entries: 256 (order: -1, 3072 bytes, linear) [2.52] NET: Registered PF_NETLINK/PF_ROUTE protocol family [2.59] DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations [2.62] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations [4.41] NuBus: Scanning NuBus slots. [4.66] SCSI subsystem initialized [5.02] clocksource: Switched to clocksource via1 [5.21] VFS: Disk quotas dquot_6.6.0 [5.25] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [7.88] NET: Registered PF_INET protocol family [7.94] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear) [8.28] tcp_listen_portaddr_hash hash table entries: 1024 (order: 0, 4096 bytes, linear) [8.33] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear) [8.35] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear) [8.37] TCP bind hash table entries: 1024 (order: 1, 8192 bytes, l
Re: Debian initramfs/initrd, was Re: stack smashing detected
Hi Stan,
On Mon, Feb 6, 2023 at 9:31 PM Stan Johnson wrote:
> On 2/6/23 12:52 AM, Geert Uytterhoeven wrote:
> > On Mon, Feb 6, 2023 at 4:42 AM Stan Johnson wrote:
> >> On an SE/30 with 128 MiB memory, the latest Debian SID kernel
> >> (vmlinux-6.1.0-2-m68k), using Debian SID modules, and with
> >> initrd-6.1.0-2-m68k built on the SE/30, hangs after the initial
> >> "ABCFGHIJK" (I tried it twice).
> >
> > If you get to "K", you're almost at the end of arch/m68k/kernel/head.S,
> > and it is very likely the kernel C-code actually started.
> > Do you get any output using "debug earlyprintk" on the kernel command
> > line?
> > ...
>
> Please see the attached serial console log, which all happened within an
> hour after I set the Penguin loose (I have Penguin-19 configured to use
> 32768 K memory). There was nothing more after two additional hours.
Thanks, so the kernel does start, but hangs later.
Adding "initcall_debug" to the kernel command line may reveal more..
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: Debian initramfs/initrd, was Re: stack smashing detected
Hi Geert, On 2/6/23 1:36 PM, Geert Uytterhoeven wrote: > ... > > Thanks, so the kernel does start, but hangs later. > Adding "initcall_debug" to the kernel command line may reveal more.. > ... Please see attached. thanks -Stan se-30_02062023-1.txt.xz Description: Binary data
Re: Debian initramfs/initrd, was Re: stack smashing detected
On Mon, 6 Feb 2023, Stan Johnson wrote: > > Thanks, so the kernel does start, but hangs later. > > Adding "initcall_debug" to the kernel command line may reveal more.. > > ... > > Please see attached. > > ... > > [ 34.44] calling key_proc_init+0x0/0x5e @ 1 > [ 34.47] initcall key_proc_init+0x0/0x5e returned 0 after 1307 usecs > [ 34.50] calling asymmetric_key_init+0x0/0x10 @ 1 > [ 34.52] Key type asymmetric registered > [ 34.54] initcall asymmetric_key_init+0x0/0x10 returned 0 after 22481 > usecs > [ 34.57] calling x509_key_init+0x0/0x16 @ 1 > [ 34.58] Asymmetric key parser 'x509' registered > [ 34.60] initcall x509_key_init+0x0/0x16 returned 0 after 14116 usecs > [ 34.62] calling crypto_kdf108_init+0x0/0x13a @ 1 > You could try 'initcall_blacklist=key_proc_init' or initcall_blacklist=x509_key_init' etc. This kind of thing has come up before. https://lists.debian.org/debian-68k/2019/06/msg00020.html https://lists.debian.org/debian-68k/2019/06/msg00066.html These systems are too slow for needless key generation so a bug report may be needed.
Re: Debian initramfs/initrd, was Re: stack smashing detected
Hi Finn, On 2/6/23 8:25 PM, Finn Thain wrote: > > On Mon, 6 Feb 2023, Stan Johnson wrote: > >>> Thanks, so the kernel does start, but hangs later. >>> Adding "initcall_debug" to the kernel command line may reveal more.. >>> ... >> >> Please see attached. >> >> ... >> >> [ 34.44] calling key_proc_init+0x0/0x5e @ 1 >> [ 34.47] initcall key_proc_init+0x0/0x5e returned 0 after 1307 usecs >> [ 34.50] calling asymmetric_key_init+0x0/0x10 @ 1 >> [ 34.52] Key type asymmetric registered >> [ 34.54] initcall asymmetric_key_init+0x0/0x10 returned 0 after 22481 >> usecs >> [ 34.57] calling x509_key_init+0x0/0x16 @ 1 >> [ 34.58] Asymmetric key parser 'x509' registered >> [ 34.60] initcall x509_key_init+0x0/0x16 returned 0 after 14116 usecs >> [ 34.62] calling crypto_kdf108_init+0x0/0x13a @ 1 >> > > You could try 'initcall_blacklist=key_proc_init' or > initcall_blacklist=x509_key_init' etc. > > This kind of thing has come up before. > https://lists.debian.org/debian-68k/2019/06/msg00020.html > https://lists.debian.org/debian-68k/2019/06/msg00066.html > > These systems are too slow for needless key generation so a bug report > may be needed. > The Mac IIci (25 MHz) is only about 50% faster that the SE/30 (16 MHz). The Debian kernel booted on the IIci, though it took somewhere between 30 and 60 minutes. If it were just slowness, shouldn't the SE/30 be expected to boot in about 60 to 120 minutes (I let it run for 3 hours)? I agree that the SE/30 (and any 68030 system with the possible exception of the IIfx) is too slow for things that aren't needed, which is why I use custom kernels (no certificates or keys, no modules, no initrd, no USB/Firewire/ATA, and only limited network and video). But it should still be possible to test a generic Debian kernel even on the slowest systems if they have enough memory.
