[Fwd: Can't activate swap partitions]

[Fwd: Can't activate swap partitions]

[Carsten Langgaard]

No one seemed to answer, so I try again, because I think we have a
general problem with the "bit"-functions in include/asm-mips64/bitops.h.
I don't think we can make the address 64-bit aligned in these functions,
without hurting a lot of drivers which use these functions to operate on
32-bit aligned data.
One of the issues is that "integer" and "long integer" used to be 32-bit
(in the 32-bit kernel), but now "long" is 64 bit. 
I can see on the ia64 part, they already has taken care of this by
saying that bit 0 is the LSB of addr; bit 32 is the LSB of (addr+1).
This is the beauty about little endian, the lower 32 bit are located on
the same address no matter if you access the data as a 32-bit or 64-bit
access. This of course doesn't count for big endian, so the ia64
approach can't be used on a big endian system.

Has anyone any ideas how to handle this without making a lot of changes
in the general code and thereby hurting the other architectures.

/Carsten



-------- Original Message --------
Subject: Can't activate swap partitions
Date: Thu, 18 Jan 2001 16:30:15 +0100
From: Carsten Langgaard <carstenl@mips.com>
To: linux-mips@oss.sgi.com

I'm having some problems with activating swap partitions when using a 64
bit kernel on a 32 bit userland.
I think I know what the problem is.
The structure of the swap devices is that the first 4096 bytes contains
a bitmap. Bits that have been set indicate that the page of memory for
which the number in the swap space matches the offset of the bit at the
start of the space is available for paging.
The problem is then these bits are being checked, through the test_bit
function call, where we read 64 bit at a time, and they where written 32
bit at a time (from the 32 bit kernel).
Note: we are talking about a bigendian system.

A little example to illustrate that I mean:

Set bit 0-53 to 1 and clear bit 54-63 (stored with 32 bit access)
ADDR = 0xffffffff;
ADDR+4 = 0x003fffff;

If I read it as two 32 bit words I get the same result (bit 0-53 is
set), but if I read it as one 64 bit double-word I get.

ADDR = 0xffffffff0003ffff;

Now bit 0-17 and bit 32-63 is set.

The bottom line is that I don't think we can make the address 64 bit
aligned in the "set/clear-and-test" functions in
include/asm-mips64/bitops.h, without hurting a lot of drivers which use
these functions to operate on hw-defined data-structures.

/Carsten



--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: [Fwd: Can't activate swap partitions]

[Geert Uytterhoeven]

On Mon, 22 Jan 2001, Carsten Langgaard wrote:
> No one seemed to answer, so I try again, because I think we have a
> general problem with the "bit"-functions in include/asm-mips64/bitops.h.
> I don't think we can make the address 64-bit aligned in these functions,
> without hurting a lot of drivers which use these functions to operate on
> 32-bit aligned data.
> One of the issues is that "integer" and "long integer" used to be 32-bit
> (in the 32-bit kernel), but now "long" is 64 bit. 

The consensus about bitops is to always use `unsigned long', although IMHO a
predefined type (bitops_t) would be better. On e.g. m68k a byte would be
sufficient, assumed you don't need more than 8 bits. Or bitsops_t8 for minimum
8 bits, bitsops_t16 for minimum 16 bits, etc....

> I can see on the ia64 part, they already has taken care of this by
> saying that bit 0 is the LSB of addr; bit 32 is the LSB of (addr+1).
> This is the beauty about little endian, the lower 32 bit are located on
> the same address no matter if you access the data as a 32-bit or 64-bit
> access. This of course doesn't count for big endian, so the ia64
> approach can't be used on a big endian system.
> 
> Has anyone any ideas how to handle this without making a lot of changes
> in the general code and thereby hurting the other architectures.

Your problem is special because you have a machine that can run in either
32-bit or 64-bit mode.

> I'm having some problems with activating swap partitions when using a 64
> bit kernel on a 32 bit userland.
> I think I know what the problem is.
> The structure of the swap devices is that the first 4096 bytes contains
> a bitmap. Bits that have been set indicate that the page of memory for
> which the number in the swap space matches the offset of the bit at the
> start of the space is available for paging.
> The problem is then these bits are being checked, through the test_bit
> function call, where we read 64 bit at a time, and they where written 32
> bit at a time (from the 32 bit kernel).
> Note: we are talking about a bigendian system.

I suggest to put an explicit `mkswap' command in the startup scripts. It's not
needed to preserver the swap space contents between successive reboots (you
can't switch from 32-bit to 64-bit or vice versa without rebooting, right?).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

Re: [Fwd: Can't activate swap partitions]

[Carsten Langgaard]

Geert Uytterhoeven wrote:

> On Mon, 22 Jan 2001, Carsten Langgaard wrote:
> > No one seemed to answer, so I try again, because I think we have a
> > general problem with the "bit"-functions in include/asm-mips64/bitops.h.
> > I don't think we can make the address 64-bit aligned in these functions,
> > without hurting a lot of drivers which use these functions to operate on
> > 32-bit aligned data.
> > One of the issues is that "integer" and "long integer" used to be 32-bit
> > (in the 32-bit kernel), but now "long" is 64 bit.
>
> The consensus about bitops is to always use `unsigned long', although IMHO a
> predefined type (bitops_t) would be better. On e.g. m68k a byte would be
> sufficient, assumed you don't need more than 8 bits. Or bitsops_t8 for minimum
> 8 bits, bitsops_t16 for minimum 16 bits, etc....
>
> > I can see on the ia64 part, they already has taken care of this by
> > saying that bit 0 is the LSB of addr; bit 32 is the LSB of (addr+1).
> > This is the beauty about little endian, the lower 32 bit are located on
> > the same address no matter if you access the data as a 32-bit or 64-bit
> > access. This of course doesn't count for big endian, so the ia64
> > approach can't be used on a big endian system.
> >
> > Has anyone any ideas how to handle this without making a lot of changes
> > in the general code and thereby hurting the other architectures.
>
> Your problem is special because you have a machine that can run in either
> 32-bit or 64-bit mode.
>
> > I'm having some problems with activating swap partitions when using a 64
> > bit kernel on a 32 bit userland.
> > I think I know what the problem is.
> > The structure of the swap devices is that the first 4096 bytes contains
> > a bitmap. Bits that have been set indicate that the page of memory for
> > which the number in the swap space matches the offset of the bit at the
> > start of the space is available for paging.
> > The problem is then these bits are being checked, through the test_bit
> > function call, where we read 64 bit at a time, and they where written 32
> > bit at a time (from the 32 bit kernel).
> > Note: we are talking about a bigendian system.
>
> I suggest to put an explicit `mkswap' command in the startup scripts. It's not
> needed to preserver the swap space contents between successive reboots (you
> can't switch from 32-bit to 64-bit or vice versa without rebooting, right?).

That will probably solve my swap partition problem, but I think there are other
potential problems as mention above.
I don't think we can guarantee that data always are 32-bit aligned.

>
> Gr{oetje,eeting}s,
>
>                                                 Geert
>
> --
> Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
> Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
> Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: [Fwd: Can't activate swap partitions]

[Carsten Langgaard]

Geert Uytterhoeven wrote:

> On Mon, 22 Jan 2001, Carsten Langgaard wrote:
> > No one seemed to answer, so I try again, because I think we have a
> > general problem with the "bit"-functions in include/asm-mips64/bitops.h.
> > I don't think we can make the address 64-bit aligned in these functions,
> > without hurting a lot of drivers which use these functions to operate on
> > 32-bit aligned data.
> > One of the issues is that "integer" and "long integer" used to be 32-bit
> > (in the 32-bit kernel), but now "long" is 64 bit.
>
> The consensus about bitops is to always use `unsigned long', although IMHO a
> predefined type (bitops_t) would be better. On e.g. m68k a byte would be
> sufficient, assumed you don't need more than 8 bits. Or bitsops_t8 for minimum
> 8 bits, bitsops_t16 for minimum 16 bits, etc....
>
> > I can see on the ia64 part, they already has taken care of this by
> > saying that bit 0 is the LSB of addr; bit 32 is the LSB of (addr+1).
> > This is the beauty about little endian, the lower 32 bit are located on
> > the same address no matter if you access the data as a 32-bit or 64-bit
> > access. This of course doesn't count for big endian, so the ia64
> > approach can't be used on a big endian system.
> >
> > Has anyone any ideas how to handle this without making a lot of changes
> > in the general code and thereby hurting the other architectures.
>
> Your problem is special because you have a machine that can run in either
> 32-bit or 64-bit mode.
>
> > I'm having some problems with activating swap partitions when using a 64
> > bit kernel on a 32 bit userland.
> > I think I know what the problem is.
> > The structure of the swap devices is that the first 4096 bytes contains
> > a bitmap. Bits that have been set indicate that the page of memory for
> > which the number in the swap space matches the offset of the bit at the
> > start of the space is available for paging.
> > The problem is then these bits are being checked, through the test_bit
> > function call, where we read 64 bit at a time, and they where written 32
> > bit at a time (from the 32 bit kernel).
> > Note: we are talking about a bigendian system.
>
> I suggest to put an explicit `mkswap' command in the startup scripts. It's not
> needed to preserver the swap space contents between successive reboots (you
> can't switch from 32-bit to 64-bit or vice versa without rebooting, right?).
>

I tried to use mkswap, but it also fails:

mkswap /dev/hda2
unknown ioctl: 00001260

>
> Gr{oetje,eeting}s,
>
>                                                 Geert
>
> --
> Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
> Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
> Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com