Adrian,
On 14/11/24 01:54, John Paul Adrian Glaubitz wrote:
On Tue, 2024-10-29 at 07:57 +1300, Michael Schmitz wrote:
Arnd,
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
Arnd,
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 you have better understanding than me
of what m68k hardware
Hi Finn,
Am 10.08.2024 um 12:42 schrieb Finn Thain:
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-3
Hi Adrian,
On 29/08/23 22:51, John Paul Adrian Glaubitz wrote:
On Mon, 2023-08-28 at 15:17 +0200, Andreas Schwab wrote:
On Aug 28 2023, John Paul Adrian Glaubitz wrote:
The FP failures are most likely the result of the limitations of the FPU
emulation
in QEMU for m68k. ARAnyM is known to hav
ng related to
Amiga permission bit handling, quite recent fixes, even in 2023, I did
not found that size fixing patch.
I recalled a discussion where Michael Schmitz talked to Jens Axboe after
I asked whether the patch got in on 2023-08-21. I thought back then it
would have went in, but maybe the las
supported).
What am I missing here?
Cheers,
Michael
Am 12.06.2023 um 17:36 schrieb John Paul Adrian Glaubitz:
Hello Michael!
On Jun 12, 2023, at 6:43 AM, Michael Schmitz wrote:
Hi Carlos,
Am 10.06.2023 um 06:29 schrieb Carlos Milán Figueredo:
From: John Paul Adrian Glau
Hi Carlos,
Am 10.06.2023 um 06:29 schrieb Carlos Milán Figueredo:
From: John Paul Adrian Glaubitz
Sent: Wednesday, June 7, 2023 9:30
Subject: Re: Updated installation images for Debian Ports 2023-06-06
Hi Adrian,
Right, this completely fell of the table. I will try to prepare the changes for
Hi Finn,
On 25/04/23 14:32, Michael Schmitz wrote:
Hi Finn,
Am 25.04.2023 um 13:55 schrieb Finn Thain:
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
Hi Finn,
Am 26.04.2023 um 16:42 schrieb Finn Thain:
If the long format frame was corrupted while on the user stack, the
partially completed MOVEM won't be resumed correctly. That's why I was
concerned about a bug in sys_sigreturn.
Yes, it turns out I hadn't read mangle_kernel_stack() carefully
Hi Finn,
Am 26.04.2023 um 14:02 schrieb Finn Thain:
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
Hi Finn,
Am 26.04.2023 um 15:27 schrieb Finn Thain:
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
Hi Andreas,
On 26/04/23 07:46, Michael Schmitz wrote:
Hi Andreas,
On 25/04/23 23:25, Andreas Schwab wrote:
On Apr 25 2023, Finn Thain wrote:
It turns out that doing so (patch below) does make the problem go away.
Was the exception frame getting clobbered?
diff --git a/arch/m68k/kernel
Hi Andreas,
On 25/04/23 23:25, Andreas Schwab wrote:
On Apr 25 2023, Finn Thain wrote:
It turns out that doing so (patch below) does make the problem go away.
Was the exception frame getting clobbered?
diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
index b9f6908a31bc..9410
Hi Finn,
Am 25.04.2023 um 14:32 schrieb Michael Schmitz:
Maybe we should try modifying get_sigframe() to increase the gap between
the signal and exception frames from 0-1 long words up to 64-65 long
words.
It turns out that doing so (patch below) does make the problem go away.
Was the
Hi Andreas,
Am 22.04.2023 um 22:12 schrieb Andreas Schwab:
On Apr 22 2023, Michael Schmitz wrote:
This is the definition from the kernel's
include/uapi/asm-generic/ucontext.h:
That's not actually used by m68k, it uses
arch/m68k/include/asm/ucontext.h, which confusingly isn't
Hi Finn,
Am 25.04.2023 um 13:55 schrieb Finn Thain:
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
Hi Finn,
Am 24.04.2023 um 15:51 schrieb Michael Schmitz:
Hi Andreas,
On 24/04/23 09:48, Andreas Schwab wrote:
On Apr 24 2023, Michael Schmitz wrote:
Not sure what third argument you referred to in another mail.
See struct sigframe and struct rt_sigframe. The non-rt signal handler
gets
Hi Andreas,
On 24/04/23 09:48, Andreas Schwab wrote:
On Apr 24 2023, Michael Schmitz wrote:
Not sure what third argument you referred to in another mail.
See struct sigframe and struct rt_sigframe. The non-rt signal handler
gets signal number, vector number and sigcontext*. The rt signal
Hi Finn,
On 23/04/23 19:46, Finn Thain wrote:
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 corrupt
Hi Finn,
On 23/04/23 21:23, Finn Thain wrote:
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
Hi Andreas,
On 23/04/23 20:23, Andreas Schwab wrote:
On Apr 23 2023, Michael Schmitz wrote:
Wasn't too hard actually. The signo parameter passed to the handler turns
out to be passed by reference, and signo is located 4 bytes into the
kernel sigframe.
That's not "pass
Hi Finn, Andreas,
Am 23.04.2023 um 13:41 schrieb Michael Schmitz:
Hi Andreas,
Am 23.04.2023 um 08:46 schrieb Andreas Schwab:
On Apr 23 2023, Michael Schmitz wrote:
I'll see whether the signal context is available on the stack even if
the
handler isn't passed that parameter.
Hi Andreas,
Am 23.04.2023 um 08:46 schrieb Andreas Schwab:
On Apr 23 2023, Michael Schmitz wrote:
I'll see whether the signal context is available on the stack even if the
handler isn't passed that parameter.
The signal context is always on the stack, and used by the
(rt_)sigretu
Hi Andreas,
Am 23.04.2023 um 06:38 schrieb Andreas Schwab:
On Apr 23 2023, Michael Schmitz wrote:
Now I wonder who adds sigmask ... and whether that's also ending up on the
user stack.
The kernel only writes the first 64 bits of the signal mask, as it does
for all signal mask re
Hi Andreas,
Am 22.04.2023 um 22:12 schrieb Andreas Schwab:
On Apr 22 2023, Michael Schmitz wrote:
This is the definition from the kernel's
include/uapi/asm-generic/ucontext.h:
That's not actually used by m68k, it uses
arch/m68k/include/asm/ucontext.h, which confusingly isn't
Hi Finn,
Am 22.04.2023 um 19:54 schrieb Michael Schmitz:
Hi Finn,
Am 21.04.2023 um 21:18 schrieb Michael Schmitz:
Hi Finn,
Am 21.04.2023 um 20:30 schrieb Finn Thain:
On Fri, 21 Apr 2023, Michael Schmitz wrote:
How often did a page fault happen when executing moveml, in other
programs
Hi Andreas,
Am 22.04.2023 um 20:07 schrieb Andreas Schwab:
On Apr 22 2023, Michael Schmitz wrote:
Took a little while to figure out that the ucontext format changed in the
decade or two since my userland's libc headers were generated.
In which way did it change?
This is the defin
Hi Finn,
Am 21.04.2023 um 21:18 schrieb Michael Schmitz:
Hi Finn,
Am 21.04.2023 um 20:30 schrieb Finn Thain:
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
Hi Finn,
Am 21.04.2023 um 20:30 schrieb Finn Thain:
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&#
Hi Finn,
Am 21.04.2023 um 09:58 schrieb Michael Schmitz:
Hi Finn,
On 20/04/23 20:55, Finn Thain wrote:
But in any case, it looks like we can eliminate the bus error code. Same
fault on both 030 and 040 with very different bus error handlers is
highly unlikely.
There's no failure on
Hi Finn,
On 21/04/23 13:15, Finn Thain wrote:
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 2
On 21/04/23 09:58, Michael Schmitz wrote:
Hi Finn,
On 20/04/23 20:55, Finn Thain wrote:
But in any case, it looks like we can eliminate the bus error code.
Same
fault on both 030 and 040 with very different bus error handlers is
highly unlikely.
There's no failure on '040. QE
Hi Finn,
On 20/04/23 20:55, Finn Thain wrote:
But in any case, it looks like we can eliminate the bus error code. Same
fault on both 030 and 040 with very different bus error handlers is
highly unlikely.
There's no failure on '040. QEMU and Motorola '040 gave the same result.
Sorry, my fau
Hi Finn,
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 page fault. That's not surprising considering the PC in the
signal frame in the dash crash was a MOVE
Hi Finn,
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 tested a Motorola '040 and got the same result.
OK, that would mean the bus error was just the most reliable way to get
do_
Hi Finn,
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 fault handled at the page boundary.
Can you try and fault in as many of these stack pages as possible, ahead
of filling
0
(gdb)
Am 20.04.2023 um 14:57 schrieb Finn Thain:
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
Hi Finn,
On 19/04/23 22:50, Finn Thain wrote:
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 overwritt
Hi Finn,
Am 19.04.2023 um 13:50 schrieb Finn Thain:
I would have expected to see a different signal trampoline (for
sys_rt_sigreturn) ...
Well, this seems to be the trampoline from setup_frame() and not
setup_rt_frame().
According to the manpages I've seen, glibc ought to pick rt signals if
Hi Finn,
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:
The backtrace confirms that this signal was delivered during execution
of __wait3(). (Delivery can happen during execution of __libc_fork()
but I just
Hi Finn,
Am 16.04.2023 um 18:44 schrieb Finn Thain:
As I understand this, the call to sys_sigreturn() removes both this code
(signal trampoline IIRC) and the signal stack...
I don't see that stuff getting removed when I run dash under gdb under
QEMU. With breakpoints at the head of onsig() and
Hi Finn,
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 signal delivery.
The signal stack is set up immediately below USP, from m
Hi Geert,
Am 11.04.2023 um 19:19 schrieb Geert Uytterhoeven:
Hi Michael,
On Tue, Apr 11, 2023 at 6:56 AM 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
Hi Finn,
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 easiest way to do that is to log all wait and signal syscalls, as
well as process exit. That
Hi Finn,
Am 10.04.2023 um 21:39 schrieb Finn Thain:
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
Hi Finn,
Am 09.04.2023 um 19:32 schrieb Finn Thain:
Looks like cat < /proc/self/maps | grep stack would give us enough
information without overwhelming the serial console?
OTOH - if you can show the error is gone without stack address
randomization, that would be a hint maybe?
The results be
Hi Finn,
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. (I said previously I was unable to reproduce this in a single
user mode shell but it turned out to be more subtle.
Hi Finn,
Am 07.04.2023 um 16:03 schrieb Finn Thain:
So, again, the best avenue I can think of for such experiments to
modify the kernel to either keep track of the times of the wait4
syscalls and
The easiest way to do that is to log all wait and signal syscalls, as
well as process exit. That m
Hi Geert,
Am 08.04.2023 um 00:06 schrieb Geert Uytterhoeven:
Hi Michael,
On Fri, Apr 7, 2023 at 3:58 AM Michael Schmitz wrote:
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 go
to the serial console
Hi Finn,
Am 05.04.2023 um 14:00 schrieb Finn Thain:
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) set
Hi Finn,
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) set osabi GNU/Linux
(gdb) file /bin/dash
Reading symbols from /bin/dash...
Reading symbols from
Hi Finn,
Am 02.04.2023 um 21:31 schrieb Finn Thain:
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_t
Hi Finn,
On 2/04/23 22:46, Finn Thain wrote:
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 (
Hi Finn,
nice work!
Am 01.04.2023 um 22:27 schrieb Finn Thain:
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 (below).
The call to __GI___wait4_time64 causes %a3 to be sav
Hi Stephen,
replacing 'm68k' by one of the officially supported architectures (I
used 'amd64') will give a working URL. This does contain a workaround to
shut up the new warning:
"
If you were pointed to this chapter by apt you can prevent it from
continuously notifying you about this change
:
Hi,
On 27.2.2023 9.19, Michael Schmitz wrote:
Am 27.02.2023 um 18:55 schrieb Finn Thain:
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
] memcmp+0x0/0x5c
+[<002c7d82>] _printk+0x0/0x18
+[<00428eda>] start_kernel+0x80/0x5b0
+[<000684e8>] pcpu_alloc+0x88/0x3b4
+[<00428322>] _sinittext+0x322/0x9b0
On Mon, Feb 27, 2023 at 7:30 AM Finn Thain wrote:
On Mon, 27 Feb 2023, Michael Schmitz wrote:
I
Hi Finn,
Am 27.02.2023 um 18:55 schrieb Finn Thain:
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
Hi Geert,
Am 27.02.2023 um 01:52 schrieb Geert Uytterhoeven:
On Sun, Feb 26, 2023 at 12:02 PM Geert Uytterhoeven
wrote:
On Tue, Feb 21, 2023 at 4:53 PM John Paul Adrian Glaubitz
wrote:
On Tue, 2023-02-21 at 15:55 +0100, Geert Uytterhoeven wrote:
Looks surprisingly similar to the issue repor
Hi Geert, Stephen,
Am 27.02.2023 um 01:52 schrieb Geert Uytterhoeven:
On Sun, Feb 26, 2023 at 12:02 PM Geert Uytterhoeven
wrote:
On Tue, Feb 21, 2023 at 4:53 PM John Paul Adrian Glaubitz
wrote:
On Tue, 2023-02-21 at 15:55 +0100, Geert Uytterhoeven wrote:
Looks surprisingly similar to the is
Hi Adrian,
Am 25.02.2023 um 08:49 schrieb John Paul Adrian Glaubitz:
Hi Michael!
On Sat, 2023-02-25 at 08:39 +1300, Michael Schmitz wrote:
the only commits to hit arch/m68k/mm between 5.15 and now are:
29f28f8b826d m68k: fix livelock in uaccess
6d0b92254510 m68k/mm: enable
panic log Adrian posted.
Cheers,
Michael
Am 24.02.2023 um 16:02 schrieb Michael Schmitz:
Hi Stephen,
that's apparently been corrected in later versions. Commit
ca831f29f8f25c97182e726429b38c0802200c8f (in from 5.17).
I doubt this would lead to different code generated.
Which was t
Hi Stephen,
that's apparently been corrected in later versions. Commit
ca831f29f8f25c97182e726429b38c0802200c8f (in from 5.17).
I doubt this would lead to different code generated.
Which was the first broken version you tried? That would narrow down the
search range considerably...
Cheers,
Correcting myself again...
On 22/02/23 13:53, Michael Schmitz wrote:
Hi Adrian,
On 22/02/23 10:46, John Paul Adrian Glaubitz wrote:
Hi Michael!
On Wed, 2023-02-22 at 10:09 +1300, Michael Schmitz wrote:
a1 is just before the end of your RAM chunk. If that's a longword
Actually it
Hi Adrian,
On 22/02/23 10:46, John Paul Adrian Glaubitz wrote:
Hi Michael!
On Wed, 2023-02-22 at 10:09 +1300, Michael Schmitz wrote:
a1 is just before the end of your RAM chunk. If that's a longword
Actually it isn't that close - if I read the stack correctly, we're
comp
Hi Adrian,
On 22/02/23 04:53, John Paul Adrian Glaubitz wrote:
Hi Geert!
On Tue, 2023-02-21 at 15:55 +0100, Geert Uytterhoeven wrote:
Looks surprisingly similar to the issue reported by Stan.
Do the mitigations given in
https://lore.kernel.org/all/camuhmdutkr2zvzijflxvs9d_injbktsnqqqfo1oxnjhze
Hi Andreas,
Am 18.02.2023 um 20:59 schrieb Andreas Schwab:
On Feb 18 2023, Michael Schmitz wrote:
Not sure it's wise to allow init to abort though.
When PID 1 exits, the kernel panics.
I might have been a mite subtle there ...
Anyway - Finn's intention was to log signals cau
Hi Finn,
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?
PID 1 is special, it never receives signals it doesn't handle.
I see. I wonder if there is some way to configure the kern
Hi Stan,
Am 18.02.2023 um 06:09 schrieb Stan Johnson:
Hi Michael,
On 2/16/23 4:10 PM, Michael Schmitz wrote:
...
'apt-get source sysvinit=3.06-2' will download and unpack that specific
version. That should unpack the source in sysvinit-3.06-2/.
That doesn't work for me:
#
Hi Stan,
On 16/02/23 15:44, Stan Johnson wrote:
I could re-install the previous sysvinit over the version in the current
Debian SID and see if the stack smashing is still gone. I don't know how
to do that, but if someone has instructions, I'll try. I'm guessing I
need to download the previous .d
Hi Stan,
Am 10.02.2023 um 13:24 schrieb Stan Johnson:
Hi Michael,
On 2/8/23 8:41 PM, Michael Schmitz wrote:
...
Following the 040 code a bit further, I suspect that happens in the 040
writeback handler, so this may be a red herring.
I'll try and log such accesses caught by exception t
Hi Stan,
Am 08.02.2023 um 11:58 schrieb Michael Schmitz:
Thanks Stan,
On 8/02/23 08:37, Stan Johnson wrote:
Hi Michael,
On 2/5/23 3:19 PM, Michael Schmitz wrote:
...
Seeing Finn's report that Al Viro's VM_FAULT_RETRY fix may have solved
his task corruption troubles on 040, I ju
Thanks Stan,
On 8/02/23 08:37, Stan Johnson wrote:
Hi Michael,
On 2/5/23 3:19 PM, Michael Schmitz wrote:
...
Seeing Finn's report that Al Viro's VM_FAULT_RETRY fix may have solved
his task corruption troubles on 040, I just noticed that I probably
misunderstood how Al
Hi Stan,
Am 02.02.2023 um 07:51 schrieb Michael Schmitz:
But since we're touching on copy_to_user() here - the 'remove set_fs'
patch set by Christoph Hellwig refactored the m68k inline helpers around
July 2021. Can you test a kernel prior to those patches (5.15-rc2)?
That&
Hi Stan,
Am 03.02.2023 um 12:16 schrieb Stan Johnson:
On 2/1/23 11:51 AM, Michael Schmitz wrote:
...
The stack canary mechanism pushes a token on the stack at function
entry, and compares against that token's value at function exit. This is
all code generated by gcc in the user binary.
Hi Stan,
On 2/02/23 05:38, Stan Johnson wrote:
On 1/30/23 8:05 PM, Michael Schmitz wrote:
...
Am 30.01.2023 um 17:00 schrieb Stan Johnson:
Hello,
I am seeing anywhere from zero to four of the following errors while
booting Linux on 68030 systems and using sysvinit startup scripts:
*** stack
Hi Stan,
Am 30.01.2023 um 17:00 schrieb Stan Johnson:
Hello,
I am seeing anywhere from zero to four of the following errors while
booting Linux on 68030 systems and using sysvinit startup scripts:
*** stack smashing detected ***: terminated
Aborted
I usually (but not always) see three of the
e, so some regression may well have crept in ...
Cheers,
Michael
Am 23.12.2022 um 21:19 schrieb Carsten Strotmann:
Hi,
On 23 Dec 2022, at 3:26, Michael Schmitz wrote:
Hi Stefan,
Am 22.12.2022 um 11:17 schrieb Finn Thain:
ip address add 192.168.1.10/24 dev eth0
ok
ip route add de
Hi Christian,
That's odd - this is what I use for my TOS boot partition in fstab:
/dev/sda1 /tosmsdos defaults,noauto
At one time, the option 'atari' would have been needed to get the
correct behaviour for GEMDOS partitions (16 bit FAT instead of 32 bit),
but that is long
Hi Stefan,
Am 22.12.2022 um 11:17 schrieb Finn Thain:
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 default gateway addre
Hi Geert,
Am 09.09.2022 um 19:34 schrieb Geert Uytterhoeven:
Hi Michael,
On Fri, Sep 9, 2022 at 7:03 AM Michael Schmitz wrote:
Am 09.09.2022 um 13:36 schrieb Finn Thain:
Kernel 5.19, intrd 5.19
[0.00] Linux version 5.19.0-1-m68k (debian-ker...@lists.debian.org)
(gcc-11 (Debian
Hi Finn,
Am 09.09.2022 um 13:36 schrieb Finn Thain:
Kernel 5.19, intrd 5.19
[0.00] Linux version 5.19.0-1-m68k (debian-ker...@lists.debian.org)
(gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian)
2.38.90.20220713) #1 Debian 5.19.6-1 (2022-09-01)
[0.00] print
Hi Carlos
Am 07.02.2022 um 11:55 schrieb Michael Schmitz:
Hi Finn,
Am 06.02.2022 um 17:02 schrieb Finn Thain:
On Sun, 6 Feb 2022, Michael Schmitz wrote:
Hi Carlos,
even 7 MB uncompressed seems a little big to me (if using modules for
anything not essential to boot).
Maybe
Hi Finn,
Am 06.02.2022 um 17:02 schrieb Finn Thain:
On Sun, 6 Feb 2022, Michael Schmitz wrote:
Hi Carlos,
even 7 MB uncompressed seems a little big to me (if using modules for
anything not essential to boot).
Maybe CONFIG_DEBUG_INFO needs to be disabled:
$ ./scripts/config -d
Hi Carlos,
even 7 MB uncompressed seems a little big to me (if using modules for
anything not essential to boot).
If you can send me your .config (or a link to download the kernel image
package), I'll compare with what I've used for v5.15.
The tricky part might be generating the initrd imag
.
(untested, but can't do much damage if you try...)
Cheers,
Michael
Am 07.01.2022 um 12:03 schrieb Carlos Milán Figueredo:
Hi Michael,
From: Michael Schmitz
Sent: miércoles, 5 de enero de 2022 7:39
You'll have to build your own kernel image binary package with the patch
included, an
Hi Carlos,
Am 04.01.2022 um 12:19 schrieb Carlos Milán Figueredo:
Hi Michael,
Many thanks for the patch! Let see if I can test on my Amiga somehow.
From: Michael Schmitz
Sent: lunes, 3 de enero de 2022 8:24
ARAnyM should work, too. You just need to add the attached patch to the
list of
Hi Carlos,
Am 03.01.2022 um 11:13 schrieb Carlos Milán Figueredo:
Hi Michael,
From: Michael Schmitz
Sent: sábado, 1 de enero de 2022 23:36
I was under the impression that you could (cross-)build your own kernel
and initrd? If that's not an option, testing is going to be much harder.
Hi Carlos,
Am 01.01.2022 um 16:22 schrieb Carlos Milán Figueredo:
Hi Michael, happy new year!
From: Michael Schmitz
Sent: viernes, 31 de diciembre de 2021 8:51
Thanks, I'll check the prefix size and send a patch by PM.
I will need also some help for testing it, as I do not have a
Hi Andreas,
Am 31.12.2021 um 10:26 schrieb Andreas 'count' Kotes:
Hello Michael,
On 29/12/2021 21:31, Michael Schmitz wrote:
Am 26.12.2021 um 09:34 schrieb Carlos Milán Figueredo:
Merry Christmas! I could finally make the tests.
From: Michael Schmitz
Sent: lunes, 13 de diciembre
Hi Carlos,
Am 30.12.2021 um 12:43 schrieb Carlos Milán Figueredo:
Hi Michael,
From: Michael Schmitz
Sent: miércoles, 29 de diciembre de 2021 21:31
Looking for PCMCIA ethernet card: ethernet PCMCIA card inserted
(unnamed net_device) (uninitialized): PCMCIA NE**00 ethercard probe
not found
Hi Carlos,
Merry Christmas to you, too!
Am 26.12.2021 um 09:34 schrieb Carlos Milán Figueredo:
Merry Christmas! I could finally make the tests.
From: Michael Schmitz
Sent: lunes, 13 de diciembre de 2021 7:52
Look for a line containing "Looking for PCMCIA ethernet card : " in the
Carlos,
Am 09.12.2021 um 01:40 schrieb Carlos Milán Figueredo:
Hi again everyone,
While I figure out how to build a snapshot NETINST ISO, I decided to
give a try to the "nativehd" initrd. This is a interesting one, as it
brings up network on the very first stage of the d-i and download
install
Hi Adrian,
On 28/09/21 21:17, John Paul Adrian Glaubitz wrote:
Hi Michael!
On 9/28/21 09:19, Michael Schmitz wrote:
Fixes should have "[net]", new development "[net-next]".
OK - patch has hopefully made it to netdev now.
I'm not seeing it here, am I m
Hi Geert,
On 28/09/21 20:12, Geert Uytterhoeven wrote:
We're at rc3 (i.e. past merge window), so net-next should be open for
submission.
Quick inspection of DaveM's netdev status page confirms that it indeed is.
I've so far sent APNE patches to net, not net-next, as these are
improvements to
Hi Carlos,
On 28/09/21 10:44, Carlos Milán Figueredo wrote:
Hi Michael!
From: Michael Schmitz
Sent: lunes, 27 de septiembre de 2021 0:00
Please check whether your card is indeed one of the supported 8390 or
compatible based cards (10 or 100 Mbit).
Taking a look at the Windows drivers, I
Hi Geert,
thanks for your words of encouragement!
On 27/09/21 21:11, Geert Uytterhoeven wrote:
Hi Michael,
On Mon, Sep 27, 2021 at 12:02 AM Michael Schmitz wrote:
I wouldn't hold my breath waiting for the 16 bit / 100 Mbit patches to
be accepted into the mainstream kernel. Haven'
Hi Adrian,
yes, and I urgently need another few weeks confined in my home office
to tackle that one ...
Cheers,
Michael
On Mon, Sep 27, 2021 at 9:28 PM John Paul Adrian Glaubitz
wrote:
>
> On 9/27/21 10:11, Geert Uytterhoeven wrote:
> > On Mon, Sep 27, 2021 at 12:02 AM Mic
I can test it on Sarge hd-media, but
not on recent snapshots.
Also, I have seen there have been very recent kernel patches from Michael
Schmitz to the Amiga PCMCIA driver [2], it looks like for probing 16-bit cards;
so I think it will be better to make tests on a recent kernel snapshot rather
th
Hi Geert,
On 23/08/21 19:36, Geert Uytterhoeven wrote:
+
+ if ((len_cftuple = pcmcia_copy_tuple(CISTPL_CFTABLE_ENTRY, cftuple, 256))
< 3) {
+ pr_cont("no cftable entry for card\n");
+ /* XXX: shouldn't we re-enable irq here? */
+ } else {
+
1 - 100 of 1131 matches
Mail list logo
