On 6/10/25 5:26 AM, John Paul Adrian Glaubitz wrote:
> ...
> On m68k, on the other hand, the user base is so small and insignificant
> that the costs for introducing the change are negligible and the profits
> for making the change strongly outweigh the disadvantages.
> ...
As part of that "small
On 11/13/24 2:01 PM, John Paul Adrian Glaubitz wrote:
>> SysVInit uses a huge set of bash scripts where every action involves
spawning
>>> a new shell while systemd does all of that in C. Compiled C code is
>>> definitely
>>> faster on an m68k machine than hundreds of shell scripts.
>>
>> Yes,
On 11/13/24 12:55 PM, John Paul Adrian Glaubitz wrote:
> On Thu, 2024-11-14 at 07:36 +1300, Michael Schmitz wrote:
>> I didn't say that - just supporting Arnd's point that much of the RAM
>> constrained old m68k software won't benefit from today's user space.
>
> We're talking about an open sourc
On 8/3/24 5:06 PM, Finn Thain wrote:
>
> 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,
>
> Ea
report to Debian.
As a workaround, dump works on other platforms (such as x86_64), so it's
possible to use those platforms to backup m68k filesystems.
thanks
-Stan Johnson
that are fast enough and have plenty of memory. YMMV
-Stan Johnson
Hi Adrian,
On 5/23/23 11:05 AM, John Paul Adrian Glaubitz wrote:
> ...
>
> We don't have any specific patches but we're building our packages using
> qemu-user and not qemu-system which is why we aren't running into memory
> constraints that quickly.
>
> For what is worth, you should use the "vi
Hello,
Does anyone know whether the developers for the Debian m68k port have
run into an issue while compiling gcc (beginning around gcc-12), as
documented at this link:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
If you are not seeing any issues, then you might be using a set of
options
Hi Andreas, Finn and Michael,
With no patches installed, I see stack smashing on my IIci after one
boot using a customized 6.2.12 kernel, no initrd, and Debian's SID and
dash. Also, Finn's test program (compiled using gcc 12) generates
illegal instructions, as expected.
With the patch below insta
> ... I'll check
> this weekend to see whether QEMU is still not seeing any problem with my
> latest kernel builds together with the latest Debian SID.
Confirmed, there is still no stack smashing in QEMU 7.2.0 with kernel
6.1.12 and the current Debian SID.
The client reports this:
root@m68k:~# c
Finn,
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" was recently added.
>>
>
> And if you find the last good us
Finn,
On 2/17/23 4:49 PM, Finn Thain wrote:
> 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 configur
On 2/17/23 3:38 PM, Finn Thain 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
> bu
On 2/17/23 2:54 PM, Finn Thain wrote:
>
> 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,
Hi Michael,
On 2/17/23 1:31 PM, Michael Schmitz wrote:
> ...
>
> 'dpkg hold' should mark packages so apt won't consider them for
> upgrading. You may want to check what other packages depend on newer
> versions of sysvinit before attempting that (search for 'sysvinit-utils
> (>=' in the Packages
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:
# apt-get source sysvinit=3.06-2
Reading package lists... Done
E: You must
Hi Adrian,
On 2/16/23 3:07 AM, John Paul Adrian Glaubitz wrote:
> Hi Stan!
>
> On Wed, 2023-02-15 at 19:44 -0700, Stan Johnson wrote:
>> Going from 15 min to about 4 min seems worth the effort on old hardware.
>> As always, YMMV. Developers who use QEMU or other emulators l
On 2/15/23 9:16 PM, Finn Thain wrote:
> 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
>>
To wrap up my stack smashing tests, I ran a few tests on a Mac IIfx (128
MiB, external SCSI2SD). Serial console logs are attached.
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
On 2/11/23 3:11 PM, 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
Michael,
On 2/10/23 12:55 AM, Michael Schmitz wrote:
> ...
>
> Without Al's patch, I doubt even in case a uaccess fault happens with
> signal pending we'd return -1 from send_fault_sig() (the no_context path
> isn't taken and do_page_fault() returns without error). No kernel
> messages expected i
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 tables on 030 to see
>> if they are rare enough to al
On 2/9/23 2:22 AM, John Paul Adrian Glaubitz wrote:
> On Wed, 2023-02-08 at 10:39 -0700, 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
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 seem
On 2/7/23 3:14 PM, Brad Boyer wrote:
> On Tue, Feb 07, 2023 at 12:41:52PM -0700, Stan Johnson wrote:
>> 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 eventu
Hi Brad,
On 2/7/23 12:28 PM, Brad Boyer wrote:
> On Tue, Feb 07, 2023 at 12:31:17AM -0700, Stan Johnson wrote:
>> 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.
>>&
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's patch works.
>
> Botching up a fault retry and carrying on may wel
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..
>>> ...
>>
>> P
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
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.
On 2/5/23 4:18 PM, John Paul Adrian Glaubitz wrote:
> On Mon, 2023-02-06 at 09:29 +1100, Finn Thain wrote:
>> ...
>
>> 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 g
On 2/3/23 4:39 PM, Finn Thain wrote:
Hi Finn,
> 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/S01mount
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.
>
> The kernel is not involved in function calls other
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:
>
es
are being terminated/aborted, I'm not sure where to start.
thanks for any suggestions
-Stan Johnson user...@yahoo.com
On 7/26/21 8:58 PM, Finn Thain wrote:
> On Mon, 26 Jul 2021, Stan Johnson wrote:
>
>> Hello,
>>
>> I'm trying to update Debian SID for m68k in QEMU.
>>
>> After a successful "apt-get update", "apt-get dist-upgrade" fails here:
>>
On 7/22/21 5:57 PM, Brad Boyer wrote:
> On Thu, Jul 22, 2021 at 07:32:49PM +1000, Finn Thain wrote:
>>> $ cat /proc/cpuinfo
>>> CPU:68030
>>> MMU:68030
>>> FPU:68882
>>
>> I wonder if that hardware should be expected to give the same result as
>> 680
On 4/15/21 12:30 AM, Carsten Strotmann wrote:
> Hi Stan,
>
> On 15 Apr 2021, at 4:23, Finn Thain wrote:
>
>> Most of that is probably password hashing. Look in /etc/shadow and you'll
>> probably find long password hashes. If you're not worried about weak
>> hashes, you could switch to DES which i
On 3/16/21 1:04 AM, Finn Thain wrote:
> On Mon, 15 Mar 2021, Stan Johnson wrote:
>
>>
>> The issue appears not to be limited to built-in video. With 16 MiB in
>> Bank A (4 x 4 MiB), 64 MiB in Bank B (4 x 16 MiB), a RasterOps
>> ColorBoard 264 in the Nubus sl
39 matches
Mail list logo
