MC Parity Error

MC Parity Error

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

Hi,
success report for the MC Bus Error handler :)

Apr 19 23:17:32 resume kernel: MC Bus Error
Apr 19 23:17:32 resume kernel: CPU error 0x380<RD PAR > @ 0x0f4c6308
Apr 19 23:17:32 resume kernel: Instruction bus error, epc == 2accf310, ra == 2accf2c8

I guess i have bad memory. The interesting point is that the machine
continued to run for another 2 days. Shouldnt a memory error halt the
machine ?

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
                        Heisenberg may have been here.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: MC Parity Error

[Maciej W. Rozycki]

On Fri, 23 Apr 2004, Florian Lohoff wrote:

> success report for the MC Bus Error handler :)
> 
> Apr 19 23:17:32 resume kernel: MC Bus Error
> Apr 19 23:17:32 resume kernel: CPU error 0x380<RD PAR > @ 0x0f4c6308
> Apr 19 23:17:32 resume kernel: Instruction bus error, epc == 2accf310, ra == 2accf2c8
> 
> I guess i have bad memory. The interesting point is that the machine
> continued to run for another 2 days. Shouldnt a memory error halt the
> machine ?

 As it happened in the user mode, I'd expect only the victim process to be
killed.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: MC Parity Error

[Ralf Baechle]

On Fri, Apr 23, 2004 at 03:11:19PM +0200, Maciej W. Rozycki wrote:

> > success report for the MC Bus Error handler :)
> > 
> > Apr 19 23:17:32 resume kernel: MC Bus Error
> > Apr 19 23:17:32 resume kernel: CPU error 0x380<RD PAR > @ 0x0f4c6308
> > Apr 19 23:17:32 resume kernel: Instruction bus error, epc == 2accf310, ra == 2accf2c8
> > 
> > I guess i have bad memory. The interesting point is that the machine
> > continued to run for another 2 days. Shouldnt a memory error halt the
> > machine ?
> 
>  As it happened in the user mode, I'd expect only the victim process to be
> killed.

The KSU bits are meaningless.  On Indy like most other MIPS systems a
bus error exception may be delayed.  So the generic solution requires
tracking down the actual user, something which in the current kernel is
relativly easy due to rmap.

  Ralf

Re: MC Parity Error

[Maciej W. Rozycki]

On Fri, 23 Apr 2004, Ralf Baechle wrote:

> > > success report for the MC Bus Error handler :)
> > > 
> > > Apr 19 23:17:32 resume kernel: MC Bus Error
> > > Apr 19 23:17:32 resume kernel: CPU error 0x380<RD PAR > @ 0x0f4c6308
> > > Apr 19 23:17:32 resume kernel: Instruction bus error, epc == 2accf310, ra == 2accf2c8
> > > 
> > > I guess i have bad memory. The interesting point is that the machine
> > > continued to run for another 2 days. Shouldnt a memory error halt the
> > > machine ?
> > 
> >  As it happened in the user mode, I'd expect only the victim process to be
> > killed.
> 
> The KSU bits are meaningless.  On Indy like most other MIPS systems a
> bus error exception may be delayed.  So the generic solution requires

 I beg your pardon?  AFAIK, bus errors are documented to be reported
precisely and my past experience with the systems I use confirms this.  
Otherwise bits in <asm/paccess.h> wouldn't work, but they do.  Of course
this is true for errors happening on read transactions (I have troubles
imagining a delayed read), but the semantics of the exception is defined
only for reads anyway.  For other transactions a general-purpose interrupt
should be used (and normally is).  Such an interrupt can happen any time,
indeed (but here it was an IBE, not an interrupt).

> tracking down the actual user, something which in the current kernel is
> relativly easy due to rmap.

 Well, that may be tough anyway -- imagine an uncorrectable memory error 
on a DMA transaction. ;-)

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: MC Parity Error

[Dominic Sweetman]

Maciej W. Rozycki (macro@ds2.pg.gda.pl) writes:

> > The KSU bits are meaningless.  On Indy like most other MIPS systems a
> > bus error exception may be delayed.  So the generic solution requires
> 
>  I beg your pardon?  AFAIK, bus errors are documented to be reported
> precisely...

You're both right :-) Data errors like this on an R4x00 are reported
as cache parity errors, and cache parity error exceptions are precise.
There's also a signalling mechanism typically used for an invalid
memory address, which generates a "bus error" exception, which is not
precise.

--
Dominic Sweetman
MIPS Technologies.

Re: MC Parity Error

[Maciej W. Rozycki]

On Fri, 23 Apr 2004, Dominic Sweetman wrote:

> > > The KSU bits are meaningless.  On Indy like most other MIPS systems a
> > > bus error exception may be delayed.  So the generic solution requires
> > 
> >  I beg your pardon?  AFAIK, bus errors are documented to be reported
> > precisely...
> 
> You're both right :-) Data errors like this on an R4x00 are reported
> as cache parity errors, and cache parity error exceptions are precise.
> There's also a signalling mechanism typically used for an invalid
> memory address, which generates a "bus error" exception, which is not
> precise.

 I refer to the situation, when SysCmd(5) is set in a response to a
processor read request.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

32-bit ABI

[Stanislaw Skowronek]

Hello,

why do we attempt to compile the kernel with 32-bit GAS abi and 64-bit GCC
abi? Is it because the module loader is broken and supports only 32-bit
ELFs? Then what about machines which load their kernels at weird 64-bit
addresses, like 0xa800000020004000 (Octane)?

I have changed it to 64-bit abi in my Octane kernel, because it won't even
compile otherwise. I've got gcc 3.3.2, gas 2.14.

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.

Re: 32-bit ABI

[Thiemo Seufer]

Stanislaw Skowronek wrote:
> Hello,
> 
> why do we attempt to compile the kernel with 32-bit GAS abi and 64-bit GCC
> abi?

It optimizes away a few hundred kB of kernel code, but requires in turn
a sign-extended load-address plus ugly objcopy hacks.

> Is it because the module loader is broken and supports only 32-bit
> ELFs? Then what about machines which load their kernels at weird 64-bit
> addresses, like 0xa800000020004000 (Octane)?

Ah, the same as for IP28. :-) They can't be supported by the current
scheme.

> I have changed it to 64-bit abi in my Octane kernel, because it won't even
> compile otherwise. I've got gcc 3.3.2, gas 2.14.

You'll have to extend all the hand-coded asm memory accesses to do
64bit adressing as well.


Thiemo

Re: 32-bit ABI

[Ralf Baechle]

On Sat, Apr 24, 2004 at 08:28:09AM +0200, Stanislaw Skowronek wrote:

> why do we attempt to compile the kernel with 32-bit GAS abi and 64-bit GCC
> abi? Is it because the module loader is broken and supports only 32-bit
> ELFs? Then what about machines which load their kernels at weird 64-bit
> addresses, like 0xa800000020004000 (Octane)?

The whole thing was born as a dirty hack back in '99 or so to avoid the
totally broken and imcomplete implementation of 64-bit MIPS ELF in binutils.
By using these options we run the kernel in CKSEG0 which means 32-bit ELF
will suffice.  A nice side effect if a reduction of kernel size - this in
the end made the code model which was born as a hack the way of choice.

So there is no relation at all to modules.  You btw. can load 64-bit ELF
modules into a kernel which was built using above trick as 32-bit ELF.
That's necessary because modules are currently allocated through vmalloc
which allocates space in XKSEG.

A code model which I'm considering as alternative is -G optimization but
that will require a good bit of work; we would have to free up $28 which
right now we're already using for the current pointer.  A bunch of
declaration would simply need to be fixed.  Module loaders would need
support for R_MIPS_GPREL16 and we'd need a solution for the problem of
the kernel being too large, therefore overflowing the small data section.
Th latter is probably going to require binutils hacking, so non-trivial.

> I have changed it to 64-bit abi in my Octane kernel, because it won't even
> compile otherwise. I've got gcc 3.3.2, gas 2.14.

Octane has no memory at all in CKSEG0?

>   Paranoid: one who is truly in touch with reality.

The fact that you're paranoid doesn't meant they're not out to get you.

  Ralf

Re: 32-bit ABI

[Stanislaw Skowronek]

> So there is no relation at all to modules.  You btw. can load 64-bit ELF
> modules into a kernel which was built using above trick as 32-bit ELF.
> That's necessary because modules are currently allocated through vmalloc
> which allocates space in XKSEG.

Ah, so it's like that. Great. Is the ELF64 support still not correct?

> > I have changed it to 64-bit abi in my Octane kernel, because it won't even
> > compile otherwise. I've got gcc 3.3.2, gas 2.14.
> Octane has no memory at all in CKSEG0?

Well, as far as I know, and I'm probably right, it _does_ have some memory
there. A whopping 16 kilobytes of memory mirrored by the HEART to allow
placing exception vectors there (what a weird idea).

And you can't remap, I repeat, can't remap anything under 0x20000000
because there are the small Xtalk windows and HEART registers and God only
knows what else.

Stanislaw Skowronek

Re: 32-bit ABI

[Ralf Baechle]

On Sat, Apr 24, 2004 at 09:31:14AM +0200, Stanislaw Skowronek wrote:

> > So there is no relation at all to modules.  You btw. can load 64-bit ELF
> > modules into a kernel which was built using above trick as 32-bit ELF.
> > That's necessary because modules are currently allocated through vmalloc
> > which allocates space in XKSEG.
> 
> Ah, so it's like that. Great. Is the ELF64 support still not correct?

No, it's supposed to be working now.

> > > I have changed it to 64-bit abi in my Octane kernel, because it won't even
> > > compile otherwise. I've got gcc 3.3.2, gas 2.14.
> > Octane has no memory at all in CKSEG0?
> 
> Well, as far as I know, and I'm probably right, it _does_ have some memory
> there. A whopping 16 kilobytes of memory mirrored by the HEART to allow
> placing exception vectors there (what a weird idea).

That's what the processor expects.

  Ralf

Re: 32-bit ABI

[Stanislaw Skowronek]

> > Ah, so it's like that. Great. Is the ELF64 support still not correct?
> No, it's supposed to be working now.

OK. File it away under 'compatibility cruft' then ;)

> > Well, as far as I know, and I'm probably right, it _does_ have some memory
> > there. A whopping 16 kilobytes of memory mirrored by the HEART to allow
> > placing exception vectors there (what a weird idea).
> That's what the processor expects.

Yeah. The weirdness is not in that part; what's weird is placing the rest
of memory somewhere else.

Stanislaw

Re: 32-bit ABI

[Maciej W. Rozycki]

On Sat, 24 Apr 2004, Stanislaw Skowronek wrote:

> Yeah. The weirdness is not in that part; what's weird is placing the rest
> of memory somewhere else.

 Perhaps to be able to put iomem stuff in CKSEG1 without implying a hole
in the RAM.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 32-bit ABI

[Ralf Baechle]

On Sat, Apr 24, 2004 at 09:51:22AM +0200, Maciej W. Rozycki wrote:

> > Yeah. The weirdness is not in that part; what's weird is placing the rest
> > of memory somewhere else.
> 
>  Perhaps to be able to put iomem stuff in CKSEG1 without implying a hole
> in the RAM.

The machine is running a 64-bit kernel so likely it was designed with
little consideration for 32-bit issues.

  Ralf

Re: 32-bit ABI

[Maciej W. Rozycki]

On Sat, 24 Apr 2004, Ralf Baechle wrote:

> > > Yeah. The weirdness is not in that part; what's weird is placing the rest
> > > of memory somewhere else.
> > 
> >  Perhaps to be able to put iomem stuff in CKSEG1 without implying a hole
> > in the RAM.
> 
> The machine is running a 64-bit kernel so likely it was designed with
> little consideration for 32-bit issues.

 Well, the exception arrangement requires RAM starting from the physical
address 0.  It seems natural to place RAM just there, avoiding additional
complexity to address decoders.  But then firmware has to be somewere
around 0x1fc00000, so to support more than 508MB of RAM the designers
would have to create a hole in RAM, which would have to be handled by the
OS then.  Thus abandoning the idea of putting RAM low, placing it
somewhere above 0x1fffffff and just mapping some of it at 0 for the
exceptions seems a better solution.

 Fortunately everything is not a PC. :-)

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 32-bit ABI

[Stanislaw Skowronek]

>  Well, the exception arrangement requires RAM starting from the physical
> address 0.  It seems natural to place RAM just there, avoiding additional
> complexity to address decoders.  But then firmware has to be somewere
> around 0x1fc00000, so to support more than 508MB of RAM the designers
> would have to create a hole in RAM, which would have to be handled by the
> OS then.  Thus abandoning the idea of putting RAM low, placing it
> somewhere above 0x1fffffff and just mapping some of it at 0 for the
> exceptions seems a better solution.

OK, I forgot about the firmware placement. Why didn't they move it to
somewhere else when booting 64-bit? (A rhetorical question, I know.)

I would place some fixed code there. Or a different memory, maybe 16 kB of
static RAM so it will always be fast. With what is now, we have physical
and virtual aliasing and it's all a bit like a 

> Fortunately everything is not a PC. :-)

Yes, fortunately. The 386 memory management is a joke. The BIOS in the
middle is an even darker joke. Well, in my opinion the R8000 was right in
not having compatibility segments.

Stanislaw

Re: 32-bit ABI

[Ralf Baechle]

On Sat, Apr 24, 2004 at 10:07:02AM +0200, Maciej W. Rozycki wrote:

> > > > Yeah. The weirdness is not in that part; what's weird is placing the rest
> > > > of memory somewhere else.
> > > 
> > >  Perhaps to be able to put iomem stuff in CKSEG1 without implying a hole
> > > in the RAM.
> > 
> > The machine is running a 64-bit kernel so likely it was designed with
> > little consideration for 32-bit issues.
> 
>  Well, the exception arrangement requires RAM starting from the physical
> address 0.  It seems natural to place RAM just there, avoiding additional
> complexity to address decoders.  But then firmware has to be somewere
> around 0x1fc00000, so to support more than 508MB of RAM the designers
> would have to create a hole in RAM, which would have to be handled by the
> OS then.  Thus abandoning the idea of putting RAM low, placing it
> somewhere above 0x1fffffff and just mapping some of it at 0 for the
> exceptions seems a better solution.
> 
>  Fortunately everything is not a PC. :-)

Actually the R10000 way to do something like this is to use the uncached
attribute like in the Origin.  It allows using the same physical address
space several times for different purposes.  So on node 0 of an Origin
indeed memory starts at physical address zero and there is no hole for
the firmware.  IP27 is afaik the only system using this R10000 feature
which surprises me a little due to the otherwise great similarity of these
two systems.

  Ralf

Re: 32-bit ABI

[Maciej W. Rozycki]

On Sat, 24 Apr 2004, Ralf Baechle wrote:

> Actually the R10000 way to do something like this is to use the uncached
> attribute like in the Origin.  It allows using the same physical address
> space several times for different purposes.  So on node 0 of an Origin
> indeed memory starts at physical address zero and there is no hole for
> the firmware.  IP27 is afaik the only system using this R10000 feature
> which surprises me a little due to the otherwise great similarity of these
> two systems.

 That precludes the firmware from being run cached, though.  Not very 
nice, especially for callbacks, but perhaps a bit easier to deal with.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 32-bit ABI

[Ralf Baechle]

On Sat, Apr 24, 2004 at 10:23:34AM +0200, Maciej W. Rozycki wrote:

> > Actually the R10000 way to do something like this is to use the uncached
> > attribute like in the Origin.  It allows using the same physical address
> > space several times for different purposes.  So on node 0 of an Origin
> > indeed memory starts at physical address zero and there is no hole for
> > the firmware.  IP27 is afaik the only system using this R10000 feature
> > which surprises me a little due to the otherwise great similarity of these
> > two systems.
> 
>  That precludes the firmware from being run cached, though.  Not very 
> nice, especially for callbacks, but perhaps a bit easier to deal with.

Sane firmware copies itself to RAM at the earliest possible stage anyway -
ROMs are way too slow.

  Ralf

Re: 32-bit ABI

[Maciej W. Rozycki]

On Sat, 24 Apr 2004, Ralf Baechle wrote:

> >  That precludes the firmware from being run cached, though.  Not very 
> > nice, especially for callbacks, but perhaps a bit easier to deal with.
> 
> Sane firmware copies itself to RAM at the earliest possible stage anyway -
> ROMs are way too slow.

 Indeed, though it excludes the RAM used from the OS control (unless the 
OS wants to block itself from the access to callbacks).

 FYI, DEC copies only the bits it currently needs (and e.g. option ROMs 
typically cannot be directly executed at all as they often are 8-bit, but 
return word-aligned data) and when booting the OS certain callback vector 
entries point to RAM and others to ROM.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 32-bit ABI

[Ralf Baechle]

On Sat, Apr 24, 2004 at 09:46:46AM +0200, Stanislaw Skowronek wrote:

> > > Ah, so it's like that. Great. Is the ELF64 support still not correct?
> > No, it's supposed to be working now.
> 
> OK. File it away under 'compatibility cruft' then ;)

The size difference this makes is still very significant.  In case of an
IP27 kernel default config:

   text    data     bss     dec     hex filename
2626662  747232  165760 3539654  3602c6 vmlinux
2907645 1283808  165760 4357213  427c5d vmlinux

The first kernel was built with the stock Makefile; the second was modified
to use 64-bit ELF using gcc 2.95.4 / binutils 2.13.2.1.  So I'd call those
817559 bytes kernel obesity ;)

> > > Well, as far as I know, and I'm probably right, it _does_ have some memory
> > > there. A whopping 16 kilobytes of memory mirrored by the HEART to allow
> > > placing exception vectors there (what a weird idea).
> > That's what the processor expects.
> 
> Yeah. The weirdness is not in that part; what's weird is placing the rest
> of memory somewhere else.

Not uncommon on SGI systems.  The Indy's memory also starts at 128MB; only
a few kB for exeption vectors are mirrored to physical address 0.

  Ralf

Re: 32-bit ABI

[Stanislaw Skowronek]

> The first kernel was built with the stock Makefile; the second was modified
> to use 64-bit ELF using gcc 2.95.4 / binutils 2.13.2.1.  So I'd call those
> 817559 bytes kernel obesity ;)

Yeah, true. It's really appalling. Make it a config option then, default
'n'. I will set it to 'y' for SGI_IP30. The Octane firmware has no
problems booting ELF64 (don't know about ELF32 though).

> > Yeah. The weirdness is not in that part; what's weird is placing the rest
> > of memory somewhere else.
> Not uncommon on SGI systems.  The Indy's memory also starts at 128MB; only
> a few kB for exeption vectors are mirrored to physical address 0.

They made a habit of this. The bastards. ;)

Stanislaw

Re: 32-bit ABI

[Thiemo Seufer]

Stanislaw Skowronek wrote:
> > The first kernel was built with the stock Makefile; the second was modified
> > to use 64-bit ELF using gcc 2.95.4 / binutils 2.13.2.1.  So I'd call those
> > 817559 bytes kernel obesity ;)
> 
> Yeah, true. It's really appalling. Make it a config option then, default
> 'n'. I will set it to 'y' for SGI_IP30. The Octane firmware has no
> problems booting ELF64 (don't know about ELF32 though).

The IP28 firmware refuses to boot ELF32.


Thiemo

Re: 32-bit ABI

[Thiemo Seufer]

Ralf Baechle wrote:
[snip]
> A code model which I'm considering as alternative is -G optimization but
> that will require a good bit of work; we would have to free up $28 which
> right now we're already using for the current pointer.

Gas has currently not much support for non-PIC n64 GP optimizations. The
recent changes have simplified the task of implementing them, though.


Thiemo

Re: 32-bit ABI

[Maciej W. Rozycki]

On Sat, 24 Apr 2004, Stanislaw Skowronek wrote:

> why do we attempt to compile the kernel with 32-bit GAS abi and 64-bit GCC
> abi? Is it because the module loader is broken and supports only 32-bit
> ELFs? Then what about machines which load their kernels at weird 64-bit
> addresses, like 0xa800000020004000 (Octane)?

1. Backward compatibility.  Old versions of gas/ld were buggy or
non-functional (depending on the version used) when using the (n)64 ABI.  
Search the mailing list archives -- I'm pretty sure anything since
2.13.2.1 should be safe, though.

2. Using the o32 ABI makes the binary smaller due to 32-bit pointers.  If
used without care, it can lead to pointer crops, though.  Anyway, some
people say it's important for them, despite the associated hassle.

> I have changed it to 64-bit abi in my Octane kernel, because it won't even
> compile otherwise. I've got gcc 3.3.2, gas 2.14.

 I know.  I build using (n)64 consistently for two years successfully --
it's OK even with gcc 2.95.x.  Making a choice between the ABIs for gas
user-selectable is on my to-do list for some time.  For now I think `make
gas-abi=64 ...' is probably the easiest workaround, though you'll need to
objcopy the resulting image to a 32-bit ELF file manually if your firmware
or loader cannot cope with 64-bit ELF binaries.  Well, I don't like the
automatic copy anyway -- it wastes too much disk space in the long run;
perhaps as a compromise it should be user-selectable, too (ditto about
SREC).

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 32-bit ABI

[Stanislaw Skowronek]

>  I know.  I build using (n)64 consistently for two years successfully --
> it's OK even with gcc 2.95.x.  Making a choice between the ABIs for gas
> user-selectable is on my to-do list for some time.  For now I think `make
> gas-abi=64 ...' is probably the easiest workaround, though you'll need to
> objcopy the resulting image to a 32-bit ELF file manually if your firmware
> or loader cannot cope with 64-bit ELF binaries.  Well, I don't like the
> automatic copy anyway -- it wastes too much disk space in the long run;
> perhaps as a compromise it should be user-selectable, too (ditto about
> SREC).

True, the kernel is *huge* (some 7 MB). But there *will* be pointer crops
if I'm using the xkphys, and I can't use ckseg0 because there are only 16
kilobytes of RAM mapped there for exceptions. So I have to use abi=64. It
does work for me, anyway.

I think it really should be a config option. Even if not actually
user-selectable (why should it be?), it should default to 'y' for Octanes
and 'n' for everything else :)

Thank you for all your explanations. My idea about modules was because I
noticed some int->ptr conversion warnings I don't like at all.

Stanislaw Skowronek

Re: 32-bit ABI

[Ralf Baechle]

On Sat, Apr 24, 2004 at 09:34:55AM +0200, Stanislaw Skowronek wrote:

> True, the kernel is *huge* (some 7 MB). But there *will* be pointer crops
> if I'm using the xkphys, and I can't use ckseg0 because there are only 16
> kilobytes of RAM mapped there for exceptions. So I have to use abi=64. It
> does work for me, anyway.

You could use a mapped address space, CKSEG2/3.

  Ralf

Re: 32-bit ABI

[Stanislaw Skowronek]

> > True, the kernel is *huge* (some 7 MB). But there *will* be pointer crops
> > if I'm using the xkphys, and I can't use ckseg0 because there are only 16
> > kilobytes of RAM mapped there for exceptions. So I have to use abi=64. It
> > does work for me, anyway.
> You could use a mapped address space, CKSEG2/3.

Yes, I could. I even know how to do that (thanks to Ralf's IP27 support),
however I think that making the kernel 64-bit-clean would benefit us all.

Stanislaw

Re: 32-bit ABI

[Maciej W. Rozycki]

On Sat, 24 Apr 2004, Stanislaw Skowronek wrote:

> True, the kernel is *huge* (some 7 MB). But there *will* be pointer crops

 Hmm, it depends on the number of drivers built-in -- my binaries are
usually around 3MB.  Or perhaps you should try strip? ;-)  You'll lose
symbol information for ksymoops then, though.

> if I'm using the xkphys, and I can't use ckseg0 because there are only 16
> kilobytes of RAM mapped there for exceptions. So I have to use abi=64. It
> does work for me, anyway.

 Sure, why wouldn't it?  Note, the current Makefile setup is intentionally 
easily tweakable for a fully 64-bit build.

> I think it really should be a config option. Even if not actually
> user-selectable (why should it be?), it should default to 'y' for Octanes
> and 'n' for everything else :)

 Well, I don't need it to be selectable, but I'd set all systems to use
the (n)64 ABI unconditionally, and the next minute someone would complain.  
;-)  Perhaps it can be unconditional for systems where the other setting 
makes no sense at all.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +