To save time, I recommend using QEMU and an up-to-date Debian/m68k SID virtual machine to produce the vmlinux and initrd files needed for use
with Penguin on your slower machines.
AFAIK, the initrd must be created on the system that is using the initrd
(or an identical system, at least that was the response I received a
while back when I was unsuccessfully trying to use the initrd that ships
on the Debian install CD).
On Sun, 5 Feb 2023, Stan Johnson wrote:
To save time, I recommend using QEMU and an up-to-date Debian/m68k SID virtual machine to produce the vmlinux and initrd files needed for use with Penguin on your slower machines.
AFAIK, the initrd must be created on the system that is using the initrd (or an identical system, at least that was the response I received a
while back when I was unsuccessfully trying to use the initrd that ships on the Debian install CD).
If that was true, how could Debian ship a single initrd that works on
Atari, Amiga, Mac etc.? They could not.
When you need to generate a valid Debian/m68k vmlinux/initrd combination that is also current, then you'll need a Debian/m68k system that is
current. The quickest way to get it is an emulator.
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).
On 2/6/23 12:52 AM, Geert Uytterhoeven wrote:
On Mon, Feb 6, 2023 at 4:42 AM Stan Johnson <[email protected]> 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..
...
Please see attached.
...
[ 34.440000] calling key_proc_init+0x0/0x5e @ 1
[ 34.470000] initcall key_proc_init+0x0/0x5e returned 0 after 1307 usecs
[ 34.500000] calling asymmetric_key_init+0x0/0x10 @ 1
[ 34.520000] Key type asymmetric registered
[ 34.540000] initcall asymmetric_key_init+0x0/0x10 returned 0 after 22481 usecs
[ 34.570000] calling x509_key_init+0x0/0x16 @ 1
[ 34.580000] Asymmetric key parser 'x509' registered
[ 34.600000] initcall x509_key_init+0x0/0x16 returned 0 after 14116 usecs
[ 34.620000] calling crypto_kdf108_init+0x0/0x13a @ 1
On 2/6/23 8:25 PM, Finn Thain wrote:
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)?
Yes, I do have the L2 cache card installed in the IIci.
If you think it would be useful, I don't mind letting the SE/30 run
overnight to see if it eventually boots.
If you think it would be useful, I don't mind letting the SE/30 run
overnight to see if it eventually boots.
If anyone knows of a 68030 emulator (maybe Basilisk?) that can boot
Linux, then I might be able to use that for faster testing.
This difference alone could probably double or triple the performance
even without the clock speed change.
The stack smashing appears to be intermittent. And it doesn't show up
while booting the kernel; it only shows up while sysvinit scripts are
running (I haven't tested using systemd, since that would be too painful
on any 68030 slower than about 40 MHz). It takes too long to boot slow systems using Debian's kernel to run repeated tests, and QEMU only
emulates 68040, so it appears to be necessary to test on real hardware.
It's not my goal to get my config files closer to Debian's, anyway. My
goal is to have the fewest number of config files for different groups
of systems.
If anyone knows of a 68030 emulator (maybe Basilisk?) that can boot
Linux, then I might be able to use that for faster testing.
On 2/7/23 4:20 PM, Finn Thain wrote:
On Tue, 7 Feb 2023, Stan Johnson wrote:
...
Preventing pointless key generation would be beneficial for all Macs, Amigas, Ataris, emulators etc. and measuring the performance of one model of Mac versus that of another model seems a bit irrelevant to me.
Sure, but unless Debian unsupported is willing to manage config files
for the various systems, then it's not likely to happen.
Moreover, you've shown that your kernel builds produce stack smashing errors whereas Debian's build does not. To resolve the problem with your builds, why not begin by eliminating some of the differences between your build and Debian's?
The stack smashing appears to be intermittent. And it doesn't show up
while booting the kernel; it only shows up while sysvinit scripts are
running (I haven't tested using systemd, since that would be too painful
on any 68030 slower than about 40 MHz).
It takes too long to boot slow systems using Debian's kernel to run
repeated tests ...
If the stack smashing is caused by a kernel bug that is hidden by
Debian's choice of config options, then it would still be useful to
identify the bug. If there is something missing from my config files
that is causing the problem, then that would still be a kernel bug in
its sanity checking of options.
Preventing pointless key generation would be beneficial for all Macs, Amigas, Ataris, emulators etc. and measuring the performance of one model
of Mac versus that of another model seems a bit irrelevant to me.
On 2/7/23 4:20 PM, Finn Thain wrote:
On Tue, 7 Feb 2023, Stan Johnson wrote:
...
Preventing pointless key generation would be beneficial for all Macs, Amigas, Ataris, emulators etc. and measuring the performance of one model of Mac versus that of another model seems a bit irrelevant to me.
Sure, but unless Debian unsupported
is willing to manage config files for the various systems, then it's
not likely to happen. I currently use separate config files for the
following Macs, to build kernels with no initrd, no modules, and only
minimal network and video support:
1) 68030 8 MiB, no network (PB-170)
2) 68030 >8 MiB (SE/30, IIci, IIfx, Centris LC III, etc.)
3) 68040 (Centris 650, PB 550c, etc.)
If the stack smashing is caused by a kernel bug that is hidden by
Debian's choice of config options, then it would still be useful to
identify the bug. If there is something missing from my config files
that is causing the problem, then that would still be a kernel bug in
its sanity checking of options. Your script will be helpful if it
becomes necessary to identify specific offending options.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 43:08:12 |
| Calls: | 12,111 |
| Calls today: | 2 |
| Files: | 15,008 |
| Messages: | 6,518,438 |