Re: Plan needed for switching m68k to 32-bit alignment

On Thu, 14 Nov 2024, Geert Uytterhoeven wrote: > On Sun, Oct 27, 2024 at 7:16 AM Finn Thain wrote: > > On Sun, 27 Oct 2024, Thorsten Glaser wrote: > > > Finn Thain dixit: > > > > > > >That would mean __alignof__(foo.b) == sizeof(foo.b) but that's no

Re: Plan needed for switching m68k to 32-bit alignment

On Wed, 13 Nov 2024, Thorsten Glaser wrote: > > But, as has been pointed out, if we make the current alignment explicit > everywhere, the kernel ABI does not have to change¹. And new syscalls, > ioctls, structs, etc. can just be made with natural alignment in mind (I > bet most are already an

Re: Plan needed for switching m68k to 32-bit alignment

On Wed, 13 Nov 2024, John Paul Adrian Glaubitz wrote: > > > 3) among all 680x0 developers interested in the NetBSD ABI > > The alignment issue affects NetBSD as well. > My experiments showed that my NetBSD/mac68k system aligns int struct members like my i686 system does.

Re: Plan needed for switching m68k to 32-bit alignment

On Wed, 13 Nov 2024, John Paul Adrian Glaubitz wrote: > > Then don't leave it to chance. > > What is supposed to mean? Are you implying that I never tried to address > this? > Obviously, it means I'm not interested in your estimation of the chances of rejection. But you're still trying to t

Re: Plan needed for switching m68k to 32-bit alignment

On Wed, 13 Nov 2024, John Paul Adrian Glaubitz wrote: > On Mon, 2024-10-28 at 19:40 +1100, Finn Thain wrote: > > On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote: > > > > > What ecosystem? Do you honestly care that any hobbyist cares about > > > having t

Re: Plan needed for switching m68k to 32-bit alignment

On Tue, 29 Oct 2024, Michael Schmitz wrote: > On 25/10/24 22:55, Arnd Bergmann wrote: > > > I also expect that a lot of users (of m68k kernels) are never going to > > get the benefits as they are already stuck on older userspace because > > of added bloat in new software releases. I assume yo

Re: Plan needed for switching m68k to 32-bit alignment

On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote: > On Mon, 2024-10-28 at 15:51 +1100, Finn Thain wrote: > > > You talk about "applications ... being written". Well, two days ago I > > mentioned several groups of applications: (1) core packages that >

Re: Plan needed for switching m68k to 32-bit alignment

On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote: > > For Debian, we have superh and i386, out of these. It is entirely > > possible that Qt et al. can work with this, but these all have natural > > alignment for quantities ≤ 32 bits. > > I'm not aware of any serious issues with alignment

Re: Plan needed for switching m68k to 32-bit alignment

On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote: > What ecosystem? Do you honestly care that any hobbyist cares about > having to reinstall their retro computers? > The issue is not just old binaries. You made the same mistake in your message to Arnd when you said "we're not allowed to

Re: Plan needed for switching m68k to 32-bit alignment

On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote: > > > > That seems to imply that someone requires that those packages are > > ported. But without a bug report from such a user, to say the package > > is broken or missing, one must question the real requirement. > > People have tried th

Re: Plan needed for switching m68k to 32-bit alignment

On Mon, 28 Oct 2024, Thorsten Glaser wrote: > ... You don’t understand the problem: applications are being written > that require natural alignment for at least 32-bit and smaller > quantities, some possibly for all quantities even. We need these > applications to work, and we cannot redesign

Re: Plan needed for switching m68k to 32-bit alignment

On Sun, 27 Oct 2024, Thorsten Glaser wrote: > Finn Thain dixit: > > >That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the > >case on my Linux/i686 system. 4 != 8: > > > >struct baa { > >int a; > >long long b; >

Re: Plan needed for switching m68k to 32-bit alignment

On Sun, 27 Oct 2024, Thorsten Glaser wrote: > >https://gcc.gnu.org/wiki/RustFrontEnd > > That’s assuming it can build the same stuff the same way so it can be > used in packaging. > Not an assumption. I simply pointed out an opportunity for collaboration, because I see the primary problem fa

Re: Plan needed for switching m68k to 32-bit alignment

On Sun, 27 Oct 2024, Thorsten Glaser wrote: > > > >That seems to imply that someone requires that those packages are > >ported. > > Yes, we do. Rust especially is killing the entire FOSS ecosystem. > > These all are conditio sine qua nōn when it comes to continuing > Linux/m68k, as a whole. >

Re: Plan needed for switching m68k to 32-bit alignment

On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote: > On Fri, 2024-10-25 at 20:06 +1100, Finn Thain wrote: > > On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote: > > > > > the m68k port has reached the point where switching the default > > > alignment fr

Re: Plan needed for switching m68k to 32-bit alignment

On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote: > the m68k port has reached the point where switching the default > alignment from 16-bit to 32-bit is inevitable as the number of packages > affected by alignment issues have become too large. It even includes > Python 3.13 these days. >

Re: dump, restore

On Sat, 10 Aug 2024, Michael Schmitz wrote: > >> Anyway, if I run dump under strace I see no CLONE_INTO_CGROUP flag: > > strace may not be aware of the CLONE_INTO_CGROUP flag yet? How old is > your strace binary? > I don't think strace is the problem. If it was, we should still see all the

Re: dump, restore

On Fri, 9 Aug 2024, I wrote: > > On Sat, 3 Aug 2024, Stan Johnson wrote: > > > > > Using "-a" appears to be a better option than just specifying a really > > long tape size. Unfortunately, it also doesn't work. The problem seems > > to affect only m68k; ppc-32, ppc-64, x86-32 and x86-64 all

Re: dump, restore

On Sat, 3 Aug 2024, Stan Johnson wrote: > > Using "-a" appears to be a better option than just specifying a really > long tape size. Unfortunately, it also doesn't work. The problem seems > to affect only m68k; ppc-32, ppc-64, x86-32 and x86-64 all work as > expected... I reproduced the proble

Re: dump, restore

On Sat, 3 Aug 2024, Stan Johnson wrote: > > root@m68k:/data# dump 0sbf 99 64 dumpfile.dmp /dev/sda5 > ... > DUMP: Context save fork fails in parent 912 > The manpage says, Each reel requires a new process, so parent processes for reels already written just hang around until th

Re: Tuple and changes for m68k with -malign-int

On Mon, 28 Aug 2023, John Paul Adrian Glaubitz wrote: > > And since we have to break the ABI anyway to be able to use 64-bit > time_t If you're worried about Y2038, aren't you jumping the gun? I reckon we have about 10 years in which to figure out what a better m68k ABI should look like. > I

Re: Tuple and changes for m68k with -malign-int

On Mon, 28 Aug 2023, John Paul Adrian Glaubitz wrote: > On Mon, 2023-08-28 at 08:56 +0200, Geert Uytterhoeven wrote: > > > And potentially more in the future, which may be anticipated on the > > > basis that "those users don't need a stable ABI any more, so let's > > > just ignore the portabil

Re: Tuple and changes for m68k with -malign-int

On Sat, 26 Aug 2023, John Paul Adrian Glaubitz wrote: > On Sat, 2023-08-26 at 09:53 +0100, James Le Cuirot wrote: > ... > > Not only mold but also most notably the following projects: > > - LLVM > - Firebird Database > - OpenJDK > - Various Qt packages > And potentially more in the future, w

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Fri, 21 Jul 2023, Matthew Wilcox wrote: > > You've misunderstood. Google have decided to subject the entire kernel > (including obsolete unmaintained filesystems) to stress tests that it's > never had before. IOW these bugs have been there since the code was > merged. There's nothing to

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Fri, 21 Jul 2023, Dave Chinner wrote: > > I suspect that this is one of those catch-22 situations: distros are > > going to enable every feature under the sun. That doesn't mean that > > anyone is actually _using_ them these days. I think the value of filesystem code is not just a question o

Re: GCC compilation fails while compiling gimple-match.cc

On Tue, 23 May 2023, John Paul Adrian Glaubitz wrote: > > I am using the virt m68k VM. > > OK. The only other project that comes to my mind where you run into > memory exhaustion issue with qemu-system is the GHC Haskell compiler. > Building it on qemu-user works fine there, too. > Were those

Re: signal delivery, was Re: reliable reproducer

On Wed, 26 Apr 2023, Michael Schmitz wrote: > In my copy of entry.S, sys_sigreturn has SAVE_SWITCH_STACK, just as > sys_rt_sigreturn does. > You're right. I think I've been at this too long.

Re: signal delivery, was Re: reliable reproducer

On Wed, 26 Apr 2023, Michael Schmitz wrote: > It seems I got confused about user and kernel stack there myself. And > managed to confuse almost everyone else about this bug. Apologies for > the incessant noise. > Likewise... I think it amuses some readers and annoys others ;-) > What matters

Re: signal delivery, was Re: reliable reproducer

On Wed, 26 Apr 2023, Michael Schmitz wrote: > On 26/04/23 07:46, Michael Schmitz wrote: > > > > I had thought the 030 could resume the interrupted instruction using > > the information from the exception frame - and that does appear to > > work in all other cases except where signal delivery get

Re: signal delivery, was Re: reliable reproducer

On Wed, 26 Apr 2023, Michael Schmitz wrote: > Thanks - we had seen evidence that a bus error generated mid-instruction > did leave the USP at the address where the bus fault happened (not > before the instruction started, neither what it would have been once the > instruction completed), and th

Re: signal delivery, was Re: reliable reproducer

On Tue, 25 Apr 2023, Andreas Schwab wrote: > Please try this patch. Thanks for looking into this. Your patch solves the problem for me and doesn't seem to cause any regression. Tested-by: Finn Thain > Signal delivery should only happen at insn boundaries, but due to the &g

Re: signal delivery, was Re: reliable reproducer

On Tue, 25 Apr 2023, Finn Thain wrote: > On Tue, 25 Apr 2023, Michael Schmitz wrote: > > > As to a cause for the corruption: all the calculations in setup_frame > > and sys_sigreturn use fsize, but get_sigframe() masks off the result > > of usp - sizeof(sigframe) - f

Re: reliable reproducer, was Re: core dump analysis

On Mon, 24 Apr 2023, Michael Schmitz wrote: > > I don't understand these results. If usp was really overwritten, the > > program would have crashed early, no? > > I think we're still at the point where rec() is called recursively, > before any returns. Right. I wasn't thinking. I'll try to co

Re: reliable reproducer, was Re: core dump analysis

On Sun, 23 Apr 2023, Michael Schmitz wrote: > Am 23.04.2023 um 13:41 schrieb Michael Schmitz: > > Though the question remains - is this expected behaviour for programs > that do deep recursion on the stack while taking signals (and the reason > for the option to run signal handlers on an altern

Re: core dump analysis, was Re: stack smashing detected

On Wed, 19 Apr 2023, Michael Schmitz wrote: > > I wonder what we'd see if we patched the kernel to log every user data > > write fault caused by a MOVEM instruction. I'll try to code that up. > > If these instructions did always cause stack corruption on 030, I think > we would have noticed lon

Re: reliable reproducer, was Re: core dump analysis

On Fri, 21 Apr 2023, Michael Schmitz wrote: > > How often did a page fault happen when executing moveml, in other > programs? > The printk() I placed in bus_error030() was conditional on the short word at the instruction pointer. It didn't consider all forms of movem, just 0x48e7 which is th

Re: reliable reproducer, was Re: core dump analysis

On Thu, 20 Apr 2023, Finn Thain wrote: > > I modified the test program to execute rec() to full depth with no > forking, then do it again with forking. > > root@(none):/root# while ./stack-test 5000 ; do : ; done > starting recursion > done. > starting recursion with

Re: reliable reproducer, was Re: core dump analysis

Fri, 21 Apr 2023 11:15:22 +1000 (AEST)n Thu, 20 Apr 2023, Michael Schmitz wrote: > > In my tests, increasing the depth does not cause a monotonous increase > in fault probability. 16k depth only has four crashes, 8k had nine. I'll > stick with 20 for now. > My tests used 'norandmaps' in t

Re: reliable reproducer, was Re: core dump analysis

On Thu, 20 Apr 2023, Michael Schmitz wrote: > Am 20.04.2023 um 19:47 schrieb Finn Thain: > >>> So all the stack pages would have been faulted in well before the > >>> failure shows up. It appears to be the signal that's the problem and > >>> not the p

Re: reliable reproducer, was Re: core dump analysis

On Thu, 20 Apr 2023, Michael Schmitz wrote: > Am 20.04.2023 um 18:04 schrieb Finn Thain: > > On Wed, 19 Apr 2023, I wrote: > > > >> Oddly, the program never detects any stack corruption when run on the > >> QEMU '040. > >> > > > > I te

Re: reliable reproducer, was Re: core dump analysis

On Thu, 20 Apr 2023, Michael Schmitz wrote: > Am 20.04.2023 um 17:17 schrieb Finn Thain: > > On Thu, 20 Apr 2023, Michael Schmitz wrote: > > > >>> > >>> As with dash, the corruption lies the page boundary. > >> > >> Hence implies a page

Re: reliable reproducer, was Re: core dump analysis

On Wed, 19 Apr 2023, I wrote: > Oddly, the program never detects any stack corruption when run on the > QEMU '040. > I tested a Motorola '040 and got the same result.

Re: reliable reproducer, was Re: core dump analysis

On Thu, 20 Apr 2023, I wrote: > > So it must be that a MOVEM went awry when a signal got delivered. Or signal delivery went awry after a MOVEM got resumed?

Re: reliable reproducer, was Re: core dump analysis

On Thu, 20 Apr 2023, Michael Schmitz wrote: > > > > As with dash, the corruption lies the page boundary. > > Hence implies a page fault handled at the page boundary. > > Can you try and fault in as many of these stack pages as possible, ahead > of filling the stack? (Depending on how much RAM y

Re: reliable reproducer, was Re: core dump analysis

On Thu, 20 Apr 2023, Michael Schmitz wrote: > Can you try and fault in as many of these stack pages as possible, ahead > of filling the stack? (Depending on how much RAM you have ...). Maybe we > would need to lock those pages into memory? Just to show that with no > page faults (but still sign

Re: reliable reproducer, was Re: core dump analysis

On Wed, 19 Apr 2023, Geert Uytterhoeven wrote: > Does it also fail on a very old kernel image you still have lying > around? Just to rule out a recent kernel bug. > These are two mainline builds I've tried (among others): [0.00] Linux version 4.14.0-mac (fthain@nippy) (gcc version 6.

reliable reproducer, was Re: core dump analysis

On Tue, 18 Apr 2023, Michael Schmitz wrote: > > ... I think what's stored there is the extra frame content for a format > b bus error frame. But that extra frame is incomplete at best (should be > 22 longwords, only a4 are seen). Probably overwritten by the stack frame > from __GI___wait4_time

Re: core dump analysis, was Re: stack smashing detected

On Tue, 18 Apr 2023, Michael Schmitz wrote: > Am 18.04.2023 um 14:04 schrieb Finn Thain: > > On Tue, 18 Apr 2023, Michael Schmitz wrote: > >> Am 16.04.2023 um 18:44 schrieb Finn Thain: > >> > >>> 0xe750: 0xc01a

Re: core dump analysis, was Re: stack smashing detected

On Tue, 18 Apr 2023, Michael Schmitz wrote: > Am 16.04.2023 um 18:44 schrieb Finn Thain: > > > > > The backtrace confirms that this signal was delivered during execution > > of __wait3(). (Delivery can happen during execution of __libc_fork() > > but I just rep

Re: core dump analysis, was Re: stack smashing detected

On Sun, 16 Apr 2023, Michael Schmitz wrote: > Am 14.04.2023 um 21:30 schrieb Finn Thain: > > Would signal delivery erase any of the memory immediately below the > > USP? If so, it would erase those old stack frames, which would give > > some indication of the timing of sign

Re: core dump analysis, was Re: stack smashing detected

On Wed, 5 Apr 2023, I wrote: > > I don't care that much what dash does as long as it isn't corrupting > it's own stack, which is a real possibility, and one which gdb's data > watch point would normally resolve. And yet I have no way to tackle > that. > > I've been running gdb under QEMU, whe

Re: instrumentation, was Re: core dump analysis

On Tue, 11 Apr 2023, Michael Schmitz wrote: > Am 11.04.2023 um 12:20 schrieb Finn Thain: > > On Sun, 9 Apr 2023, Michael Schmitz wrote: > >> Am 08.04.2023 um 00:06 schrieb Geert Uytterhoeven: > >>> On Fri, Apr 7, 2023 at 3:58 AM Michael Schmitz >>>> The

Re: kernel behaviour, was Re: dash behaviour

On Tue, 11 Apr 2023, Michael Schmitz wrote: > > > > I was able to find some command line options (init_on_alloc, > > init_on_free) and the related Kconfig symbols > > (CONFIG_INIT_ON_ALLOC_DEFAULT_ON, CONFIG_INIT_ON_FREE_DEFAULT_ON). > > Right - not sure how I managed to miss those. > > init_o

instrumentation, was Re: core dump analysis

On Sun, 9 Apr 2023, Michael Schmitz wrote: > Am 08.04.2023 um 00:06 schrieb Geert Uytterhoeven: > > > > On Fri, Apr 7, 2023 at 3:58 AM Michael Schmitz >> The easiest way to do that is to log all wait and signal syscalls, as > >> well as process exit. That might alter timing if these log messages

kernel behaviour, was Re: dash behaviour

On Mon, 10 Apr 2023, Michael Schmitz wrote: > > > > So I guess this bug has more to do with timing and little to do with > > state, contrary to my guesswork above. And no doubt I will have to > > What may still vary is physical mapping - I remember you had used some > tool before to parse proc/

Re: dash behaviour, was Re: core dump analysis

On Sun, 9 Apr 2023, Michael Schmitz wrote: > Am 09.04.2023 um 16:42 schrieb Finn Thain: > > On Sun, 9 Apr 2023, Michael Schmitz wrote: > > > >>> > >>> The only way I have found to alter dash's inclination to crash is to > >>> reboot

Re: dash behaviour, was Re: core dump analysis

On Sun, 9 Apr 2023, Michael Schmitz wrote: > > > > The only way I have found to alter dash's inclination to crash is to > > reboot. (I said previously I was unable to reproduce this in a single > > user mode shell but it turned out to be more subtle.) > > I wonder what could change from one boo

Re: core dump analysis, was Re: stack smashing detected

On Tue, 4 Apr 2023, I wrote: > On Tue, 4 Apr 2023, I wrote: > > > > > The actual corruption might offer a clue here. I believe the saved %a3 > > was clobbered with the value 0xefee1068 which seems to be a pointer into > > some stack frame that would have come into existence shortly after > >

Re: dash behaviour, was Re: core dump analysis

On Fri, 7 Apr 2023, Geert Uytterhoeven wrote: > > > > The only way I have found to alter dash's inclination to crash is to > > reboot. (I said previously I was unable to reproduce this in a single > > user mode shell but it turned out to be more subtle.) > > That sounds like memory corruption s

dash behaviour, was Re: core dump analysis

On Fri, 7 Apr 2023, Michael Schmitz wrote: > Am 05.04.2023 um 14:00 schrieb Finn Thain: > > On Wed, 5 Apr 2023, Michael Schmitz wrote: > > > >> That means we may well see both signals delivered at the same time if > >> the parent shell wasn't sche

Re: core dump analysis, was Re: stack smashing detected

On Wed, 5 Apr 2023, Michael Schmitz wrote: > On 4/04/23 12:13, Finn Thain wrote: > > It looks like I messed up. waitproc() appears to have been invoked > > twice, which is why wait3 was invoked twice... > > > > GNU gdb (Debian 13.1-2) 13.1 > > ... > > (gdb)

Re: core dump analysis, was Re: stack smashing detected

On Tue, 4 Apr 2023, I wrote: > > The actual corruption might offer a clue here. I believe the saved %a3 > was clobbered with the value 0xefee1068 which seems to be a pointer into > some stack frame that would have come into existence shortly after > __GI___wait4_time64 was called. Wrong... it

Re: core dump analysis, was Re: stack smashing detected

On Mon, 3 Apr 2023, Michael Schmitz wrote: > Am 02.04.2023 um 21:31 schrieb Finn Thain: > > > >> > >> Maybe an interaction between (multiple?) signals and syscall > >> return... > > > > When running dash from gdb in QEMU, there's only one sig

Re: core dump analysis, was Re: stack smashing detected

On Mon, 3 Apr 2023, Michael Schmitz wrote: > On 2/04/23 22:46, Finn Thain wrote: > > > This is odd: > > > > https://sources.debian.org/src/dash/0.5.12-2/src/jobs.c/?hl=1165#L1165 > > > >1176 do { > >1177 gotsi

Re: core dump analysis, was Re: stack smashing detected

On Sat, 1 Apr 2023, Andreas Schwab wrote: > On Apr 01 2023, Finn Thain wrote: > > > So, in summary, the canary validation failed in this case not because > > the canary got clobbered but because %a3 got clobbered, somewhere > > between __wait3+24 and __wait3+70 (bel

Re: core dump analysis, was Re: stack smashing detected

On Sun, 2 Apr 2023, Michael Schmitz wrote: > Saved registers are restored from the stack before return from > __GI___wait4_time64 but we don't know which of the two wait4 call sites > was used, do we? > > What registers does __m68k_read_tp@plt clobber? > But that won't matter to the caller, _

Re: core dump analysis, was Re: stack smashing detected

On 31 Mar 2023, I wrote, > ... > > So %a3 was a pointer into stack frame 6?? > > (gdb) x/z $a3 > 0xefee1068: 0xc00e0172 > > Clearly 0xd000c38e != 0xc00e0172 (that is, %fp@(-4) != %a3@) but did the > canary value change? It rather looks like the canary pointer is wrong... > So the questio

Re: core dump analysis, was Re: stack smashing detected

On 28 March 2023, I wrote, > > Looking at sysdeps/unix/sysv/linux/wait3.c, I guess the only possible > place for a buffer overrun would be struct __rusage64 usage64. > https://sources.debian.org/src/glibc/2.36-8/sysdeps/unix/sysv/linux/wait3.c/?hl=41#L41 > ... but now I see the usage64 vari

core dump analysis, was Re: stack smashing detected

On Sat, 18 Feb 2023, I wrote: > On Fri, 17 Feb 2023, Stan Johnson wrote: > > > > > That's not to say a SIGABRT is ignored, it just doesn't kill PID 1. > > > > I doubt that /sbin/init is generating the "stack smashing detected" > error but you may need to modify it to find out. If you can't fi

Re: gdb failure: "core file format not supported"

On Mon, 27 Mar 2023, Geert Uytterhoeven wrote: > On Mon, Mar 27, 2023 at 2:47 AM Finn Thain wrote: > > I wasn't able to add the linux-m68k list to the bug report Cc list. > > > > I'm forwarding this as I don't know the answer to Tom's question... > >

Re: gdb failure: "core file format not supported"

I wasn't able to add the linux-m68k list to the bug report Cc list. I'm forwarding this as I don't know the answer to Tom's question... On Sat, 25 Mar 2023, tromey at sourceware dot org wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=30273 > > Tom Tromey changed: > >Wha

Re: gdb failure: "core file format not supported"

[Cc: linux-m68k] On Fri, 10 Mar 2023, I wrote: > root@panmac:~# gdb --core core.0 > GNU gdb (Debian 13.1-2) 13.1 > Copyright (C) 2023 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change a

gdb failure: "core file format not supported"

I've been attempting to debug a dash crash (reported in a different thread). I was able to capture some core dumps but gdb doesn't like them. root@panmac:~# file core.? core.0: ELF 32-bit MSB core file, Motorola m68k, 68020, version 1 (SYSV), SVR4-style, from '/bin/sh /etc/init.d/mountkernfs.s

Re: Kernel versions 6.x don't boot on Amiga 4000

On Mon, 27 Feb 2023, I wrote: > On Mon, 27 Feb 2023, Michael Schmitz wrote: > > > > > I wonder whether Finn's memtest patch merely exposed another MM bug > > > > A kernel patch may be easier than a bootloader patch (even if this is a > bootloader bug) particularly if it affects multiple pl

Re: Kernel versions 6.x don't boot on Amiga 4000

On Mon, 27 Feb 2023, Michael Schmitz wrote: > > I wonder whether Finn's memtest patch merely exposed another MM bug > A kernel patch may be easier than a bootloader patch (even if this is a bootloader bug) particularly if it affects multiple platforms. A partial revert of my patch (below) wi

Re: Kernel versions 6.x don't boot on Amiga 4000

On Mon, 27 Feb 2023, Michael Schmitz wrote: > > > > Bisected to commit 376e3fdecb0dcae2 ("m68k: Enable memtest > > functionality") in v5.17-rc1. Reverting that on top of latest fixes > > the issue. > > Yes, I'm sorry to say that was the only likely candidate. Can't see why > though - are Macs

Re: stack smashing detected

On Fri, 17 Feb 2023, Stan Johnson wrote: > On 2/17/23 4:24 PM, Finn Thain wrote: > > > > On Fri, 17 Feb 2023, Stan Johnson wrote: > > > >> > >> The error could have been exposed in any package where > >> "-fstack-protector-strong"

Re: stack smashing detected

On Sat, 18 Feb 2023, Michael Schmitz wrote: > Am 18.02.2023 um 12:49 schrieb Finn Thain: > > On Sat, 18 Feb 2023, Andreas Schwab wrote: > > > >> On Feb 18 2023, Finn Thain wrote: > >> > >>> Why do you say init ignores SIGABRT? > >> >

Re: stack smashing detected

On Fri, 17 Feb 2023, Stan Johnson wrote: > > What's interesting to me is that although there are stack smashing > errors and "aborted" messages during boot, nothing seems to have > actually failed or aborted (note that no processes are named as > "terminated" or "aborted" in the messages).

Re: stack smashing detected

On Sat, 18 Feb 2023, Andreas Schwab wrote: > On Feb 18 2023, Finn Thain wrote: > > > Why do you say init ignores SIGABRT? > > PID 1 is special, it never receives signals it doesn't handle. > I see. I wonder if there is some way to configure the kernel so that P

Re: stack smashing detected

On Fri, 17 Feb 2023, Stan Johnson wrote: > > The error could have been exposed in any package where > "-fstack-protector-strong" was recently added. > And if you find the last good userland binary, what then? Fix the bad userland binary? That's wonderful but it doesn't explain why the bad

Re: stack smashing detected

On Fri, 17 Feb 2023, Stan Johnson wrote: > > That's not to say a SIGABRT is ignored, it just doesn't kill PID 1. > I doubt that /sbin/init is generating the "stack smashing detected" error but you may need to modify it to find out. If you can't figure out which userland binary is involved, yo

Re: stack smashing detected

On Fri, 17 Feb 2023, Stan Johnson wrote: > I noticed that /sbin/init seems to ignore SIGABRT, so I thought that > might mean that init itself was somehow triggering the stack smashing > but nothing was really aborting, but I could be wrong about that. Why do you say init ignores SIGABRT? I co

Re: Getting back in the saddle - Mac LC475

s with egret > mentions. I forget what I was up to at the time, but I suspect I was > working with someone (Finn Thain?) about getting Egret working better. I > have a 4.12 from somewhere that isn't working. I feel bad for > disappearing, but life is complex. Unfortunately I have a

Re: stack smashing detected

On Wed, 15 Feb 2023, Stan Johnson wrote: > > 1) Default Debian kernel (vmlinux-6.1.0-4-m68k, initrd-6.1.0-4-m68k) >Default Debian sysvinit scripts >Boot time (ABC... to login prompt): 15 min 3 sec >NIC not detected, no stack smashing > Did you check whether the NIC module (mac8390)

Re: stack smashing detected

On Sun, 12 Feb 2023, Finn Thain wrote: > > On Sat, 11 Feb 2023, Stan Johnson wrote: > > > v5.1 x SCSI2SD crashes, goes offline with activity LED on, > > rootfs corrupted, needed to be restored from backups, SCSI2SD SD card > > needed to have the Apple d

Re: stack smashing detected

On Sat, 11 Feb 2023, Stan Johnson wrote: > I think if there were hardware problems with the SCSI2SD board or the SD > card, then I would be seeing lots of errors in MacOS and with v6.x > kernels. > That's not true in general. But I can agree that certain SCSI device faults will show up in any

Re: stack smashing detected

On Sat, 11 Feb 2023, Stan Johnson wrote: > v5.1 x SCSI2SD crashes, goes offline with activity LED on, > rootfs corrupted, needed to be restored from backups, SCSI2SD SD card > needed to have the Apple driver updated to boot MacOS > > v4.20 bad stack smashing on first boot, co

Re: Debian initramfs/initrd, was Re: stack smashing detected

On Wed, 8 Feb 2023, Stan Johnson wrote: > 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

Re: Debian initramfs/initrd, was Re: stack smashing detected

On Tue, 7 Feb 2023, Stan Johnson wrote: > If you think it would be useful, I don't mind letting the SE/30 run > overnight to see if it eventually boots. > Preventing pointless key generation would be beneficial for all Macs, Amigas, Ataris, emulators etc. and measuring the performance of one

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

Debian initramfs/initrd, was Re: stack smashing detected

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 t

Re: stack smashing detected

On Wed, 1 Feb 2023, Stan Johnson wrote: > > After logging the start and end of each script, I see that the "stack > smashing detected" error often happens while running > "/etc/rcS.d/S01mountkernfs.sh" (/etc/init.d/mountkernfs.sh). I'll try to > isolate it to a particular command. > That bri

Re: Work on adding TLS support to LLVM on m68k

On Sat, 28 Jan 2023, John Paul Adrian Glaubitz wrote: > Hello! > > The maintainers of the m68k backend in LLVM have started initial > planning for adding TLS support. An issue for that has been opened in > the LLVM Github tracker [1]. > > If anyone can help shed more light on how TLS works o

Re: Debian 11 installation attempt / walkthrough

On Fri, 23 Dec 2022, Stefan Niestegge wrote: > The login timeout is too short. Checking if the password is correct > takes too long. > It's for security -- you can't log in, but neither can your enemy. I was joking ... actually, it's a regression caused by progress. The solution is to use old

Re: Debian 11 installation attempt / walkthrough

On Fri, 23 Dec 2022, Michael Schmitz wrote: > Am 22.12.2022 um 11:17 schrieb Finn Thain: > > > ip address add 192.168.1.10/24 dev eth0 > > ip link set dev eth0 up > > ip route add default via 192.168.1.1 > > Perhaps add 'ip route add 192.168.1.0/24 dev eth0&#

Re: Debian 11 installation attempt / walkthrough

On Wed, 21 Dec 2022, Stefan Niestegge wrote: > > > > ip address add 192.168.1.10/24 dev eth0 > ok > > ip route add default via 192.168.1.1 > ip: RTNETLINK answers: Network is unreachable > > > > > where "192.168.1.10/24" is the IP address of the Falcon machine and > > "192.168.1.1" is the defau

Re: Booting Kernel on Amiga 3000

Hi Michael, On Fri, 9 Sep 2022, Michael Schmitz wrote: > > I know nothing about the way amiboot works, and how the RAM chunk to > copy the initrd image to is selected. Same here. This is not a bug I can resolve. It's a bug for someone who knows Amiga hardware and amiboot algorithms. > Just

Re: Booting Kernel on Amiga 3000

On Fri, 9 Sep 2022, Stephen Walsh wrote: > Here's a test of kernel 5.16, intrid 5.16. It exited to busybox saying > it couldn’t find /dev/sda2 (root fs) > > ... > [ 116.98] scsi 1:0:0:0: tag#16 abort command > [ 117.00] scsi 1:0:0:0: tag#16 New error handler wants HOST reset, cmd > b2

Re: Booting Kernel on Amiga 3000

On Fri, 9 Sep 2022, Stephen Walsh wrote: > Hi Finn, > > On Fri, 9 Sep 2022 11:36:49 +1000 (AEST) > Finn Thain wrote: > > > You mean, you tried kernel 5.15 with initrd 5.19? The question is, > > "did it oops?". Having seen the results below, I suspect

  1   2   3   4   5   6   7   8   9   >