On Saturday 02 June 2007 16:54, Patrick McHardy wrote:
> Patrick McHardy wrote:
> > Jan Engelhardt wrote:
> >>This is fixed in 2.6.21, thanks.
> >
> > Yes, the hashlimit compat issue is. But the underlying problem still
> > persists, I'll send you a patch for testing soon.
>
> Here it is, could you
From: Sam Ravnborg <[EMAIL PROTECTED]>
Date: Sun, 3 Jun 2007 01:00:50 +0200
> Btw I cannot see why ia64 does not give warnings with their use
> of .data.patch.*. It could be a modpost bug...
Keep in mind that if you prefix a section name with ".data.foo"
or ".text.foo" this might have meaning for
On Sat, Jun 02, 2007 at 02:02:20PM -0700, David Miller wrote:
> From: Sam Ravnborg <[EMAIL PROTECTED]>
> Date: Sat, 2 Jun 2007 22:32:06 +0200
>
> > The good news is that there is a nice pattern here. All sections that
> > have the references end in _patch.
> > So a simple solution is to teach modp
From: Sam Ravnborg <[EMAIL PROTECTED]>
Date: Sat, 2 Jun 2007 22:32:06 +0200
> The good news is that there is a nice pattern here. All sections that
> have the references end in _patch.
> So a simple solution is to teach modpost to not warn about references
> from a section named *_patch to .init.t
Hi David.
As per discussion in other mail I have looked into the section
mismatch warnings coming from trampoline.S
If the section is changed to .init.text it gives the following warnings:
WARNING: arch/sparc64/kernel/built-in.o(.sun4v_1insn_patch+0x8): Section
mismatch: reference to .init.text
From: Mark Fortescue <[EMAIL PROTECTED]>
Date: Sat, 2 Jun 2007 19:46:21 +0100 (BST)
> Some versions of GCC may be capable of sorting out the correct code
> but my experience is avoid the situation to start with by using code
> similar to memcpy (&x, &un_aligned_x, sizeof x).
This unfortunately do
Hi Jan,
Definatly not on sun4c (sparc32) and probably not on other sparc.
16bit values have to be 16bit aligned.
32bit values have to be 32bit aligned.
64bit values have to be 64bit aligned (e.g. double x).
Some versions of GCC may be capable of sorting out the correct code but my
experience i
Hi,
I was just wondering, since sparc is one of these alignment-sensitive
architectures, is it actually valid to dereference at odd positions,
e.g...?
*(uint16_t *)uint8_ptr[something_not_divisible_by_2];
*(uint32_t *)uint8_ptr[something_not_divisible_by_4];
etc.
Jan
--
-
To u
Jan Engelhardt wrote:
> On Jun 2 2007 14:54, Patrick McHardy wrote:
>
>>Here it is, could you please test whether it fixes the crash by
>>backing out the hashlimit compat patch and triggering the size
>>error again? Thanks.
>
> [connlimit compat]
>
> Kernel built, rebooted, no panics or thelike.
On Jun 2 2007 14:54, Patrick McHardy wrote:
>Patrick McHardy wrote:
>> Jan Engelhardt wrote:
>>
>>>This is fixed in 2.6.21, thanks.
>>
>> Yes, the hashlimit compat issue is. But the underlying problem still
>> persists, I'll send you a patch for testing soon.
>
>Here it is, could you please test
Jan Engelhardt wrote:
> On Jun 2 2007 14:54, Patrick McHardy wrote:
>
This is fixed in 2.6.21, thanks.
>>>
>>>Yes, the hashlimit compat issue is. But the underlying problem still
>>>persists, I'll send you a patch for testing soon.
>>
>>Here it is, could you please test whether it fixes the cr
On Jun 2 2007 14:54, Patrick McHardy wrote:
>>>This is fixed in 2.6.21, thanks.
>>
>> Yes, the hashlimit compat issue is. But the underlying problem still
>> persists, I'll send you a patch for testing soon.
>
>Here it is, could you please test whether it fixes the crash by
>backing out the hashl
Patrick McHardy wrote:
> Jan Engelhardt wrote:
>
>>This is fixed in 2.6.21, thanks.
>
>
>
> Yes, the hashlimit compat issue is. But the underlying problem still
> persists, I'll send you a patch for testing soon.
Here it is, could you please test whether it fixes the crash by
backing out the
13 matches
Mail list logo
