From: Carsten Langgaard <carstenl@mips.com>
To: linux-mips@oss.sgi.com
Subject: [Fwd: Can't activate swap partitions]
Date: Mon, 22 Jan 2001 15:46:09 +0100 [thread overview]
Message-ID: <3A6C47B1.731AE4FD@mips.com> (raw)
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
next reply other threads:[~2001-01-22 14:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-22 14:46 Carsten Langgaard [this message]
2001-01-22 15:00 ` [Fwd: Can't activate swap partitions] Geert Uytterhoeven
2001-01-22 15:23 ` Carsten Langgaard
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=3A6C47B1.731AE4FD@mips.com \
--to=carstenl@mips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox