All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carsten Langgaard <carstenl@mips.com>
To: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Cc: linux-mips@oss.sgi.com
Subject: Re: [Fwd: Can't activate swap partitions]
Date: Mon, 22 Jan 2001 16:23:51 +0100	[thread overview]
Message-ID: <3A6C5087.70B33B2B@mips.com> (raw)
In-Reply-To: Pine.GSO.4.10.10101221556400.7996-100000@escobaria.sonytel.be

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

  reply	other threads:[~2001-01-22 15:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-22 14:46 [Fwd: Can't activate swap partitions] Carsten Langgaard
2001-01-22 15:00 ` Geert Uytterhoeven
2001-01-22 15:23   ` Carsten Langgaard [this message]
2001-01-22 16:28   ` Carsten Langgaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A6C5087.70B33B2B@mips.com \
    --to=carstenl@mips.com \
    --cc=Geert.Uytterhoeven@sonycom.com \
    --cc=linux-mips@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.