Hi David,
I have sucessfully tested the attached patch on Sparc32:sun4c.
Is there any chance of this getting sufficiantly tested on other
architectures to get in into v2.6.22 ?
Regards
Mark Fortescue.From: Mark Fortescue <[EMAIL PROTECTED]>, David Woodhouse <[EMAIL PROTECTED]>
On Wed, 2007-07-04 at 11:27 +0100, Mark Fortescue wrote:
> Another related point that may also need to be considered is that I think
> I am correct in saying that on ARM and on the 64bit platforms, sizeof
> (unsigned long long) is 16 (128bits).
No, it's always 64 bits.
> Should the RedZone
Hi David,
Another related point that may also need to be considered is that I think
I am correct in saying that on ARM and on the 64bit platforms, sizeof
(unsigned long long) is 16 (128bits).
Should the RedZone words be specified as __u64 not the unsigned long long
used or does the
Hi David,
Another related point that may also need to be considered is that I think
I am correct in saying that on ARM and on the 64bit platforms, sizeof
(unsigned long long) is 16 (128bits).
Should the RedZone words be specified as __u64 not the unsigned long long
used or does the
On Wed, 2007-07-04 at 11:27 +0100, Mark Fortescue wrote:
Another related point that may also need to be considered is that I think
I am correct in saying that on ARM and on the 64bit platforms, sizeof
(unsigned long long) is 16 (128bits).
No, it's always 64 bits.
Should the RedZone words
Hi David,
I have sucessfully tested the attached patch on Sparc32:sun4c.
Is there any chance of this getting sufficiantly tested on other
architectures to get in into v2.6.22 ?
Regards
Mark Fortescue.From: Mark Fortescue [EMAIL PROTECTED], David Woodhouse [EMAIL PROTECTED]
Verious
On Wed, 2007-07-04 at 04:27 +0100, Mark Fortescue wrote:
> I tried the previous patch and it looks like it fixes the issue however
> one of the test builds I did caused depmod to use up all available memory
> (40M - kernel memory) before taking out the kernel with the oom killer.
> At present, I
Hi David,
I tried the previous patch and it looks like it fixes the issue however
one of the test builds I did caused depmod to use up all available memory
(40M - kernel memory) before taking out the kernel with the oom killer.
At present, I do not know if it is a depmod issue or a kernel
On Tue, 2007-07-03 at 23:47 +0100, Mark Fortescue wrote:
> Hi David,
>
> I will try out your patch shortly.
Thanks.
> I may be wrong about the size calculations but if you take a look at lines
> 2174 to 2188 and 2207 to 2203, reading the comments suggest to me that
> these need to be changed
Hi David,
I will try out your patch shortly.
On Tue, 3 Jul 2007, David Woodhouse wrote:
On Tue, 2007-07-03 at 22:25 +0100, Mark Fortescue wrote:
The problem is that sun4c Sparc32 can't handle un-aligned variables so
having a 64bit readzone word that is not aligned on a 64bit boundary is a
On Tue, 2007-07-03 at 14:41 -0700, David Miller wrote:
> Please don't use get_unaligned() or whatever to fix this, it's
> going to generate the byte-at-a-time accesses on sparc64
> which doesn't need it since the redzone will be aligned.
Yes, get_unaligned() would suck. But 'u64
On Tue, 2007-07-03 at 22:25 +0100, Mark Fortescue wrote:
> The problem is that sun4c Sparc32 can't handle un-aligned variables so
> having a 64bit readzone word that is not aligned on a 64bit boundary is a
> problem.
Surely, it can. You just have to tell the compiler that it's not
properly
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Tue, 03 Jul 2007 15:26:18 -0400
> On Tue, 2007-07-03 at 19:57 +0100, Mark Fortescue wrote:
> > > Commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66 partially fixed alignment
> > > issues but does not ensure that all 64bit alignment requirements of
>
Hi David,
The problem is that sun4c Sparc32 can't handle un-aligned variables so
having a 64bit readzone word that is not aligned on a 64bit boundary is a
problem.
In addition, having looked at the size calculations, it looks to me as if
not all of them got updated to handle 64bit redzone
On Tue, 2007-07-03 at 19:57 +0100, Mark Fortescue wrote:
> > Commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66 partially fixed alignment
> > issues but does not ensure that all 64bit alignment requirements of sparc32
> > are met. Tests have shown that the redzone2 word can become misallignd.
Hi all,
I have tested a solution to the random invalid instruction occourances on
sparc32 (sun4c). I have attached the patch as my mail client messes up
patch files.
The problem apears to be an alignment error of the redzone2 word, caused
by the userword not being forced onto a 64bit
Hi all,
I have tested a solution to the random invalid instruction occourances on
sparc32 (sun4c). I have attached the patch as my mail client messes up
patch files.
The problem apears to be an alignment error of the redzone2 word, caused
by the userword not being forced onto a 64bit
On Tue, 2007-07-03 at 19:57 +0100, Mark Fortescue wrote:
Commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66 partially fixed alignment
issues but does not ensure that all 64bit alignment requirements of sparc32
are met. Tests have shown that the redzone2 word can become misallignd.
Oops,
Hi David,
The problem is that sun4c Sparc32 can't handle un-aligned variables so
having a 64bit readzone word that is not aligned on a 64bit boundary is a
problem.
In addition, having looked at the size calculations, it looks to me as if
not all of them got updated to handle 64bit redzone
From: David Woodhouse [EMAIL PROTECTED]
Date: Tue, 03 Jul 2007 15:26:18 -0400
On Tue, 2007-07-03 at 19:57 +0100, Mark Fortescue wrote:
Commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66 partially fixed alignment
issues but does not ensure that all 64bit alignment requirements of
sparc32
On Tue, 2007-07-03 at 22:25 +0100, Mark Fortescue wrote:
The problem is that sun4c Sparc32 can't handle un-aligned variables so
having a 64bit readzone word that is not aligned on a 64bit boundary is a
problem.
Surely, it can. You just have to tell the compiler that it's not
properly
On Tue, 2007-07-03 at 14:41 -0700, David Miller wrote:
Please don't use get_unaligned() or whatever to fix this, it's
going to generate the byte-at-a-time accesses on sparc64
which doesn't need it since the redzone will be aligned.
Yes, get_unaligned() would suck. But 'u64
Hi David,
I will try out your patch shortly.
On Tue, 3 Jul 2007, David Woodhouse wrote:
On Tue, 2007-07-03 at 22:25 +0100, Mark Fortescue wrote:
The problem is that sun4c Sparc32 can't handle un-aligned variables so
having a 64bit readzone word that is not aligned on a 64bit boundary is a
On Tue, 2007-07-03 at 23:47 +0100, Mark Fortescue wrote:
Hi David,
I will try out your patch shortly.
Thanks.
I may be wrong about the size calculations but if you take a look at lines
2174 to 2188 and 2207 to 2203, reading the comments suggest to me that
these need to be changed to
Hi David,
I tried the previous patch and it looks like it fixes the issue however
one of the test builds I did caused depmod to use up all available memory
(40M - kernel memory) before taking out the kernel with the oom killer.
At present, I do not know if it is a depmod issue or a kernel
On Wed, 2007-07-04 at 04:27 +0100, Mark Fortescue wrote:
I tried the previous patch and it looks like it fixes the issue however
one of the test builds I did caused depmod to use up all available memory
(40M - kernel memory) before taking out the kernel with the oom killer.
At present, I do
26 matches
Mail list logo
