New to this list but I have had a Macintosh SE/30 running Linux off and
on for six years.
It's worked fine all this time, but I just recently decided to upgrade
the Debian.
The hardware is a Macintosh SE Superdrive, SE/30 mainboard, 80 MB RAM, 1
GB HD, and an ethernet card.
The Mac system is OS
rom "
hwclock " is a complaint that the date is not within range. "hwclock
--systohc " does nothing. I thought I saw something in the 2.2.25 kernel
that fixed the hardware clock issue. Let me do some catch up with
kernels before tinkering or saying anything further. My 2.2.6 k
Ingo,
I cleaned out my whole /var/spool tonight on my Fedora box. Lots of
print jobs from months ago were abandoned there. It was good to clean
the spool folders out. Not something I regularly attend to. So a
cleanout script run by cron would be a great idea.
Richard
(the guy with a few SE
perfectly. I have an SE/30 for which I
installed Debian potato with a 2.2 kernel. I upgraded to a 2.6 kernel
and it's choppy now. When the etch version is all the way ready for
m68k, I want to try a clean install.
Richard Waterfield
LilleTomte wrote:
Hi all,
Apologies if this is obvious
by bsrl 0xc0040aa0 and obviously does not
point to a valid address.
> If I read that right, it’s the equivalent of: mov a2,dword ptr [a0]
a0=tls_get_addr@plt(...)
a2=*(a0)
in c-like pseudocode, but I do not know enough to make sense of the args to
tls_get_addr@plt.
Richard
--
%d5,%sp@-
>0xc00f1ece <__res_init+26>: movel %d5,%sp@
my m68k coding skills are a little rusty but that looks bizarely obfuscated,
a bunch of asm instructions that could be saved quite easilly?
Richard
---
Name and OpenPGP keys available from pgp key servers
--
To UNSUBSCRI
d spot something.
Richard
---
Name and OpenPGP keys available from pgp key servers
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110201150347.GA20414@rz
> kernel even knows what timezone it is in (?)
it does not.. reason for a few mind boggling hacks in kernel-ntp code.
Richard
---
Name and OpenPGP keys available from pgp key servers
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe"
may have changed with
coldfire related changes?
Richard
---
Name and OpenPGP keys available from pgp key servers
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.
ite sure how much of the heavy maths these programs do is
inlined.. possibly we would need separate binaries of the programs
as well but do not think so.
Richard
---
Name and OpenPGP keys available from pgp key servers
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a sub
n expected integer value in d0 while
pointers return in a0.
With -O0 this often happens to work as the compiler generates an intermediate
move to d0 which would be optimised away with -O2.
Richard
---
Name and OpenPGP keys available from pgp key servers
--
To UNSUBSCRIBE, email to debian-
Hi,
when you suspect the assembler look at the output of "objdump -S test.o" and
compare with assembler input. You can also try to singlestep the asm code,
(stepi, info registers) in gdb and perhaps you have "ddd" or similar available?
Richard
---
Name and OpenPGP keys av
exactly will be broken? Afaics kernel ABIs have been since long pretty
carefully designed to avoid this problems and noone of the mentioned examples
should touch them anyway.
Thus.. is there any need to change the kernel ABI?
Richard
g that. Radically redefining "c" after 35 years of existence
for next to zero gain wasn't such a great idea imho.
I hope the kernel ABI can remain stable and everything else is the problem of
libraries?
Richard
and not break anything so the acceptance would be pretty low.
The problem arises only when people start doing "strange" things with such
structs. Can we define strange things in a better way? It appears to me all
modern c standards somewhat lack an attribute to mark a struct as being
"special use" and thus emit more warnings and avoid some kinds of trickery.
Richard
On August 28, 2023 10:57:25 AM UTC, John Paul Adrian Glaubitz
wrote:
>On Sat, 2023-08-26 at 19:24 +0000, Richard wrote:
>> > Not only mold but also most notably the following projects:
>>
>> a linker that is broken by a slightly unusual alignment isn't exactl
On August 28, 2023 11:26:58 AM UTC, Richard wrote:
>
>
>
>On August 28, 2023 7:00:07 AM UTC, Geert Uytterhoeven
>wrote:
>>On Sun, Aug 27, 2023 at 11:36 AM James Le Cuirot
>> wrote:
>>> On Sun, 2023-08-27 at 10:46 +1000, Finn Thain wrote:
>>
>>
U
alignment these days? Also, would we change the kernel and interfaces at the
same time? How about boot programs and similar?
Richard
.
Richard
t worried
> about the overhead of having an extra page per thread to store 32 bits.
slightly dangerous, but how about reserving a few bytes above stack?
Richard
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
could someone here use this machine?
Richard
--- Begin Message ---
> Richard Zidlicky <[EMAIL PROTECTED]>
Oh, wow. I didn't notice your e-mail address until now.
OT: I've got an LC4 with upgraded processor (full 68040 at 25MHz), upgraded
RAM (24 MB, no less), a splendid
e and memory usage.
The big ABI change that was discussed some time ago would have involved lot
more - increasing the alignment of elements inside structs and alignment of
array elements. Especially the struct alignment change would break plenty
of stuff.
I am not sure what happens if the futex is
On Sat, Jun 05, 2010 at 09:19:51AM +0200, Geert Uytterhoeven wrote:
> On Sat, Jun 5, 2010 at 00:52, Richard Zidlicky wrote:
> > On Fri, Jun 04, 2010 at 10:57:50PM +0200, Geert Uytterhoeven wrote:
> > this is the hardware behaviour but the compiler is free to use more
> >
On Sat, Jun 05, 2010 at 12:21:47PM +1000, Finn Thain wrote:
>
> On Sat, 5 Jun 2010, Richard Zidlicky wrote:
>
> > I am not sure what happens if the futex is inside a "misaligned struct"
> > - would that be handled with an attribute of the futex?
>
> I
On Sat, Jun 05, 2010 at 11:21:42AM +0200, Andreas Schwab wrote:
> Richard Zidlicky writes:
>
> > As I see it the stack-allocated futex could be automagicaly aligned when
> > pushed as
> > argument to a function
>
> Futexes are indexed by address. You cannot mov
it)
> | */
> |
> | #define FUT_OFF_INODE1 /* We set bit 0 if key has a reference on inode
> */
> | #define FUT_OFF_MMSHARED 2 /* We set bit 1 if key has a reference on mm */
>
> I.e. the futex code uses the two low order bits for its private
> purposes (nihil novi sub sole).
> Not much we can do about that...
why does not a simple "__attribute__ ((aligned (4)))" work?
Richard
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100607195211.ga6...@linux-m68k.org
re – is that a gcc-4.5 thing (I’m
> strictly concentrating on gcc-4{3,4} with libc-2.7 at the moment)?
might make sense to have separate m68020-40 and m68060. 68020-30 appear
almost the same as 68040 from gcc point of view.
Richard
--
To UNSUBSCRIBE, email to debian-68k-requ...@
Am 09.01.2012 03:52, schrieb Ben Hutchings:
> On Sun, 2012-01-08 at 17:29 -0800, Linus Torvalds wrote:
>> On Sun, Jan 8, 2012 at 5:06 PM, richard -rw- weinberger
>> wrote:
>>> On Mon, Jan 9, 2012 at 1:18 AM, Linus Torvalds
>>> wrote:
>>>> Ok, both
e to compile SSL libs and OpenSSH with the
-m68020-60 settings, otherwise it will attempt to use the long mul
insns which have to be emulated in software on 68060.. with
horrible results as you see.
Richard
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
most printk's, especially in interrupt code should be protected
by a static static counter to ensure they don't cause more harm than
use..
Richard
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
the bvme6000
> > and mvme16x kernel image packages. The aforementioned packages can be
> > found at:
> >
> > http://linux.barhop.co.uk/m68k-kernel-2.4.18/
>
> Something seems to be wrong with the ext3 patch, Richard?
>
> find kernel -path '*/pcmcia/*'
uot;CoreKeyboard"
> Option "XkbRules" "xfree86"
> Option "XkbModel""macintosh"
> Option "XkbLayout""us"
> EndSection
try 'XkbDisable' in the InputDevice section or 'startx -- -kb'
Richard
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
seems to be almost doing it. If the scripts are -x,
> they display in the browser window. If they're +x, they just show a blank
> white page with nothing useful.
>
> Any ideas what I'm doing wrong? I'm perfectly willing to switch back to
> Roxen or Apache given some tips on how to get them to work properly.
did you check /var/log/httpd* ?
Richard
t use -fomit-frame-pointer but is a horrible hack.
I assume some special gcc function attribute like 'return_result_in_d0'
could be implemented. Otoh why is gcl doing such strange things?
Richard
g as you don't use -fomit-frame-pointer but is a horrible hack.
>
> I don't think that -fomit-frame-pointer has any influence on this, but if
> it does, then only by chance.
it has, the code to generate the extra a0->d0 move is in
FUNCTION_EXTRA_EPILOGUE which gets omitted with -fomit-frame-pointer
Richard
On Fri, Aug 02, 2002 at 05:00:20PM +1000, Ross Vumbaca wrote:
> Hi,
> Now what do I do?
get linux-m68k sources:
cvs -d :pserver:[EMAIL PROTECTED]:/home/linux-m68k/cvsroot login
cvs -z 2 -d :pserver:[EMAIL PROTECTED]:/home/linux-m68k/cvsroot co -r m68k-2_4
linux
Password: anon
Richard
nd
'go' it.
Richard
On Mon, Aug 12, 2002 at 10:56:23PM +0200, Kars de Jong wrote:
> Hello everyone,
>
> At work I found an old Motorola Delta crate gathering dust. On closer
> inspection it contained an MVME147SA-1 SBC, an MVME332XT serial wossname and
> a cradle with 3
all?
> Any assistance tracking this problem down would be appreciated. It's probably
> just poor #ifdef placement.
very likely.
Richard
oesn't have complete
library support.
Kaffe 1.06 required appended patch, didn't check if it was accepted
for 1.0.7 yet. It did feel pretty sluggish on a 68060 but that may
have been because of a gcc issue with long long arithmetic on this
CPU.
Richard
--- kaffe-1.0.6/config/m68k/jit.h.rz
y key pair should be created using
> /dev/random, while for session keys /dev/urandom is good enough).
/dev/random? /dev/urandom? You are kidding. This randmomness is used
to create authorisation cookies for X which in my understanding provide
ZERO security. Use plain libc rand() and the security is exactly the same.
Richard
These are not small floating point errors, but rather large
ones. Of course it depends on whether you are looking at
the number of significant places in agreement or the
number in disagreement:)
I would guess that one is using single precision IEEE
floats and the other is using double precision. I
On Fri, Sep 20, 2002 at 09:17:49AM -0400, Camm Maguire wrote:
> That did it -- thanks! As Richard Fateman observed, its quite
> surprising the magnitude of the difference was so large. Apparently
> m68k has the more accurate answer, right? In any case, I'm adding
> -fflo
e dynamic loader
in glibc, not sure if this is already fixed in debian.
I have attached some patches in case you want to play with it. The gcc
patch has also the effect to change cpu target default to 68020-60.
Richard
>From [EMAIL PROTECTED] Sat Aug 24 20:18:13 2002
Return-Path:
Received: (from [E
sk in the m68k
kernel mailing list.
Richard
3.2 with a
> recent snapshot of binutils and your patches?
that's what I am running now.
Richard
ld send them to me i would appreciate it as i can
> only run X in 640x400 or 800x600 at the moment even though my gfx card and
> monitor should be capable of running much higher resolutions
perhaps you don't need them at all, not sure. mknod would create the
devices eg:
mknod fb9 c 29 9
Richard
I noticed that swafish from 3.0 dies, not really a surprise for
me because librep was broken on m68k for very long time. I have yesterday
recompiled with gcc-3.2 and it seems to work reliably so there is hope..
meanwhile it would be good if m68k could have a different default wm
- fluxbox would be great.
Richard
maped and because
of the relocation a lot of the code will be paged in.
Richard
the
framebufferdevice and instead uses some defaults.
Btw your email headers are prety misleading.
Richard
uction to flush the
cache, but iirc there is nothing like that on 68020-30.
Richard
se tell us the appropriate XFConfig file magic.
no Mac, on the Q60 it works out of the box.
> Using the woody installer to set up X on a Macintosh is an exercise in
> futility.
it needs just a few example configurations for m68k to make it easy
I guess. After all there is not much choice what to configure, only
the keyboard.
Richard
On Fri, Nov 22, 2002 at 02:44:47PM +0100, Stefan Reinauer wrote:
> * Richard Zidlicky <[EMAIL PROTECTED]> [021007 13:51]:
> > > make CFLAGS='-O' LIBCFLAGS='-g -O2' \
> > > LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap
> >
x86 Linux
should work on m68k.
Richard
be necessary anyway.
cacheflush returns 0 on success or -1 and errno so for debugging it
would be very good idea to test for errors. The complete range passed
to cacheflush must be legal address, otherwise cacheflush will return
an error without doing any flush.
Which kernel version was that? Can you see if the failed flushes
were cornercases like address near page-boundaries? What kind
of ranges need to be flushed?
Richard
is certainly better. It would be still
good to figure out what exactly went wrong with SCOPE_LINE though.
Richard
m68k
> > (CCing the glibc people)
>
> Anything new here ?
I hope you have fixed your mailer, last time I found no way to send you
a reply.
Richard
On Thu, Dec 19, 2002 at 11:52:52AM -0500, Camm Maguire wrote:
> Greetings!
>
> Richard Zidlicky <[EMAIL PROTECTED]> writes:
>
> > On Mon, Dec 16, 2002 at 03:05:37PM -0500, Camm Maguire wrote:
> >
> > Hi,
> >
> > > > Which kernel version wa
CPU will do
a maximum about 6MB/s even for fully buffered io (as shown by hdparm -T)
Richard
also installed woody, and set up xfree from woody (config file see
> attachment)
module loading is still broken on 68060, missing cacheflush somewhere.
Untill this can be fixed use the statically linked version of the
X server which should be in the debuggibg package.
Richard
ed to the time spent with paging.
It would be certainly good to have the module loader, but for the
average m68k user this is of no benefit and so I think m68k should
default to statically linked Xserver.
Richard
get usable colours on my Q40 was to
hardcode this into hw/xfree86/drivers/fbdev/fbdev.c. Strangely
there is another fbdev driver in hw/kdrive/fbdev, what is this
good for?
Richard
kernel question, try asking in linux-m68k mailing list.
Richard
shed
> light on this. I have been looking at include/linux/version.h to
> determine the verion I've got. Today, I downloaded the whole tree
> from scratch using tag 2_2_23 but I ended up without this file.
look into Makefile, I think version.h is generated out of it. If there
is a tag it should be visible in the top CVS subdir.
Richard
e something obvious.
Richard
h
> glibc-2.3.1-9. I need to build gcc-3.2-3.2.2ds3 in the 1st stage
> using with gcc-2.95, because debian gcc-3.2 cannot build itself!
which binutils are used? Some older versions had bugs that were
only triggered by gcc-3.2
Richard
ironment.
seems to be the version used during the build as well. Haven't
tested this version but the problems I mentioned were much older..
lets see what the new build does.
Richard
>
...
> 5. Fix an ELF/m68k bug.
important but probably not the solution for this problem.
I will try bootstrapping an unpatched 3.2 release in my
environment.
Richard
drive, and while booting, after it enters
> runlevel 2, and after it's loaded inetd and statd and lockd, it's stuck
> at loading nfsd. The machine seems to be locked up. At least I don't
> know how to interrupt it. And I can't get to another virtual console
> either.
disable automatic startup of nfsd and try it manually with strace.
Richard
ually fairly trivial, however 2.7 is so
old I have never done it myself and may need some special binutils version,
patches or something..
Richard
fo) == R_68K_NONE)
+return;
else
_dl_reloc_bad_type (map, ELF32_R_TYPE (reloc->r_info), 1);
}
No idea if it is fixed or going to be fixed in some newer binutils.
The inefficiency introduced by this patch is minimal so it won´t
hurt if it stays in glibc for a while.
Richard
pgpKxTuvaGVqv.pgp
Description: PGP signature
generated by the compiler or comming from some auxiliary
lib? Looking at m68k.md I have no idea how it should get generated.
Richard
if sufficient docs
are available.
Btw what are the details of the 68060 Milan?
Richard
anges related to PCI and asm-m68k/io.h
to make Hades work again. I have changed io.h to allow some existing
m68k ISA bridges to work and some changes went in to prepare for the
anticipated Amiga PCI bridges - haven´t heard much about these lately?
Which PCI drivers did the Hades use anyway?
cc´ing to [EMAIL PROTECTED]
Richard
s (from
> stdio-common) with gcc -m68060, it generates few fsun instructions...
That explains it ;)
Look at glibc-*/sysdeps/m68k/fpu/bits/mathinline.h
Richard
Debian.
Compiler seems allright, probably the kernel sources you used aren´t any
good.
Get m68k sources as:
cvs -d :pserver:[EMAIL PROTECTED]:/home/linux-m68k/cvsroot login
cvs -z 2 -d :pserver:[EMAIL PROTECTED]:/home/linux-m68k/cvsroot co -r m68k-2_4
Currently 2.4 kernels won´t work on macs
Richard
, mulsi3 calls should not be generated unless you happen to use
-m68000 compiler option. Is there perhaps an explicit call to it from
sacn/mul_n.c ? What happens if you compile that module with -m68020 ?
Richard
k it is time to use multilibs for m68k-linux.
Richard
ly NFS-mounting /usr/include and /lib most likely won´t work :(
Richard
s not working. I know
> it's a setting, as at the console the keyboard is fine.
try the usual procedure: does ´xev´ return anything for these
keyboard combinations?
> Also is it common to have the system completely lock frequently when
> installing packages from cdrom?
not for me.. anything unusual in /var/log/messages?
Richard
On Mon, Feb 24, 2003 at 11:26:39AM -0500, Camm Maguire wrote:
> Greetings!
>
> Richard Zidlicky <[EMAIL PROTECTED]> writes:
>
> > On Tue, Feb 18, 2003 at 04:46:46PM -0500, Camm Maguire wrote:
> > > Greetings, and thanks for the insight. GCL does a subbuil
s the gcc 2.95.4, and it runs fine
> when building Linux-ELF-binaries (like e2fsprogs, cdrecord, etc.).
gcc272 might be a better choice for a 2.2 kernel.
Richard
out.
I don´t think 2 MB/s is so bad on m68k, there are probably other
factors than won´t let it go much faster anyway.
Richard
few more datapoints. Iirc my IDE is on something like a 10 MHz bus.
I remember a 68040 40 MHz had so little reserves im memory bandwidth
and CPU power that even io buffered in RAM (not in disk buffer) had
a maximum throughput of about 5.6 MB/s.
Richard
GER-SHIFT
LONGLONG
LONGLONG-ADD
LONGLONG-MUL
LONGLONG-DIV
GENERAL_FLOAT
DOUBLE
DOUBLE-MULADD
DOUBLE-SQRT
DOUBLE-TRIG
DOUBLE-EXP
DOUBLE-LOG
FLOAT
FLOAT-MULADD
...
...
...
STRING
I have probably overengineered it quite a bit as I do usually ;)
Richard
s the serial console use
> (baurdate, handshake, bits) and (most importantly) which port, since the TT
> has 4 (MFP1, SCC-A, SCC-B, MFP2)?
see arch/m68k/head.S around line 2812 for details. Default appears to be
MFP, 1 stopbit, no parity, 9600 baud.
Richard
ly. gmp nowadays takes cpu type "m68k" to mean plain 68000,
> compiling for "m68020" should result in code that's faster, and
> probably a little smaller.
it would run faster on 68020-40 CPU´s, the problem is it would
also run *much* slower on 68060 CPU´s.. so there should be
2 version of it built.
Richard
um.
>
> Hope anyone can make heads or tails of this...
only after you run it through ksymoops ;)
Richard
on m68k. It used
> to be for Linux/PPC and Linux/m68k, but apparently this got changed for
> PPC and in the process it was assumed 'off' for all platforms.
apparently it isn´t needed for the Q40 either.
Richard
On Tue, Apr 15, 2003 at 08:12:20AM +1000, Kevin Ryde wrote:
> Richard Zidlicky <[EMAIL PROTECTED]> writes:
> >
> > it would run faster on 68020-40 CPU´s, the problem is it would
> > also run *much* slower on 68060 CPU´s..
>
> Oh, you mean 68881 emulated on 060?
uces unusable code.
I got it fixed by making gcc producing m68060 code by default.
> I guess as a minimum the gmp configs ought to select the 68000 code in
> preference to the 68020 when building for 060.
with gmp you can do ./configure (m68060-linux|m68020-linux) and it
ought to do the right thing.
Richard
ve improved, still have the hacked sources
if you are interested.
Richard
ool, but the kernel doesn't see any of them. I had
a look in /proc/partition-formats and mac is listed, so it hasn't been
left out of the kernel by mistake.
Any suggestions? Any further info required?
Many thanks,
Richard
On Wed, May 07, 2003 at 08:58:52PM +1200, Richard Hector wrote:
> Hi all,
>
> The problem I'm having is that whether I use the Apple tool (from System
> 7.1) or mac-fdisk from within the installation system, the kernel won't
> recognise the partition table properly. It
ion line/other which will
> let me swap the buttons for work under X and the twm (default) window
> manager. My guess is that this would be done in the XF86Config-4 file
> in the mouse section, but I have not seen anything on this.
xmodmap -e "pointer = 3 2 1"
Richard
I assume it is there for m68k too.
Richard
On x86:
[EMAIL PROTECTED]:/mirror$ dpkg -S sfdisk
util-linux: /usr/share/man/man8/sfdisk.8.gz
util-linux: /sbin/sfdisk
util-linux: /usr/share/doc/util-linux/examples/sfdisk.examples.gz
for ealier error messages.
Richard
lem with mutt on m68k, even reading strange
maildirs and mboxes worked fine.
If the mbox is nonstandard, try feeding it through
formail:
formail -ds new_mbox
mutt -f new_mbox
Richard
; formail -ds new_mbox
strange, it should split the mails in every case and not
generate wrong headers.
Richard
nary-m68k from yesterday (20030902):
> >
> > % gcc --version
> > gcc (GCC) 3.3.2 20030812 (Debian prerelease)
> > Copyright (C) 2003 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions. There is NO
> > warranty; not even fo
processed sources of the apne and 8390 modules.
Richard
1 - 100 of 153 matches
Mail list logo
