tags 539378 fixed-upstream
thanks
Fix is now in upstream mainline: b4f2e2ad5348063ef94aa623f6f09b52ecaf0990
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Saturday 01 August 2009, Carlos O'Donell wrote:
> I suggest you use Dave's patch please, it is IMO the most correct
> patch.
Right. I think the original patch is probably responsible for endless
errors on shutdown/reboot:
Bad Address (null pointer deref?): Code=15 regs=bea7cf70
(Addr=
On Sat, Aug 1, 2009 at 3:07 PM, John David
Anglin wrote:
> Signed-off-by: John David Anglin
>
Frans,
I suggest you use Dave's patch please, it is IMO the most correct patch.
Helge, Kyle, thanks also for the initial patches!
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ.
> > case ELF_STUB_GOT:
> > - stub->insns[0] = 0x537b;/* ldd 0(%dp),%dp */
> > + stub->insns[0] = 0x537b;/* ldd 0(%dp),%dp */
> > stub->insns[1] = 0x53610020;/* ldd 10(%dp),%r1 */
> > stub->insns[2] = 0xe820d000;
On Fri, 31 Jul 2009, Carlos O'Donell wrote:
> >> + if (d <= 15)
> >> + stub->insns[0] |= reassemble_14(d);
> >
> > reassemble_14 is wrong for ldd format 3. Need format 5 and im5 insertion.
>
> This is using reassemble_14 for ldd format 5, which is correct.
Huh?
tags 539378 patch
thanks
On Saturday 01 August 2009, Helge Deller wrote:
> Kyle, you beat me.
> Attached is my patch
>
> Tested and works.
Works for me too. Cool.
Your patch contained a few whitespace errors and, because of that, one
unnecessary change. Attached a version with those cleane
On Thu, Jul 30, 2009 at 8:37 PM, John David
Anglin wrote:
>> case ELF_STUB_GOT:
>> - stub->insns[0] = 0x537b; /* ldd 0(%dp),%dp */
>> + stub->insns[0] = 0x537b; /* ldd 0(%dp),%dp */
>> stub->insns[1] = 0x53610020; /* ldd 10(%d
On Fri, Jul 31, 2009 at 7:38 PM, Kyle McMartin wrote:
> Is it as simple as:
>
> diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
> index ef5caf2..0502fab 100644
> --- a/arch/parisc/kernel/module.c
> +++ b/arch/parisc/kernel/module.c
> @@ -82,13 +82,6 @@
> return
> > case ELF_STUB_GOT:
> > - stub->insns[0] = 0x537b;/* ldd 0(%dp),%dp */
> > + stub->insns[0] = 0x537b;/* ldd 0(%dp),%dp */
> > stub->insns[1] = 0x53610020;/* ldd 10(%dp),%r1 */
> > stub->insns[2] = 0xe820d000;
> case ELF_STUB_GOT:
> - stub->insns[0] = 0x537b;/* ldd 0(%dp),%dp */
> + stub->insns[0] = 0x537b;/* ldd 0(%dp),%dp */
> stub->insns[1] = 0x53610020;/* ldd 10(%dp),%r1 */
> stub->insns[2] = 0xe820d000;
On 08/01/2009 01:38 AM, Kyle McMartin wrote:
On Fri, Jul 31, 2009 at 06:00:48PM -0400, Carlos O'Donell wrote:
On Fri, Jul 31, 2009 at 5:26 PM, John David
Anglin wrote:
I don't have more details... The idea is as Carlos outlined. There's
code in the binutils elf32-hppa.c and elf64-hppa.c file
On Fri, Jul 31, 2009 at 06:00:48PM -0400, Carlos O'Donell wrote:
> On Fri, Jul 31, 2009 at 5:26 PM, John David
> Anglin wrote:
> > I don't have more details... The idea is as Carlos outlined. There's
> > code in the binutils elf32-hppa.c and elf64-hppa.c files to implement
> > the above for dynam
On Fri, Jul 31, 2009 at 5:26 PM, John David
Anglin wrote:
> I don't have more details... The idea is as Carlos outlined. There's
> code in the binutils elf32-hppa.c and elf64-hppa.c files to implement
> the above for dynamic libraries. That's what made me think of it.
Binutils is not involved i
> On Fri, Jul 31, 2009 at 5:09 PM, Helge Deller wrote:
> > On 07/31/2009 09:03 PM, John David Anglin wrote:
> >>>
> >>> Only 32-bit targets have the 14-bit signed immediate offset (0x3fff),
> >>> which becomes a 13-bit limit when loading positive offsets e.g.
> >>> +0x1fff or 1023 GOT slots.
> >>
>
On Fri, Jul 31, 2009 at 5:09 PM, Helge Deller wrote:
> On 07/31/2009 09:03 PM, John David Anglin wrote:
>>>
>>> Only 32-bit targets have the 14-bit signed immediate offset (0x3fff),
>>> which becomes a 13-bit limit when loading positive offsets e.g.
>>> +0x1fff or 1023 GOT slots.
>>
>> Can't we off
On Fri, Jul 31, 2009 at 5:13 PM, Carlos O'Donell wrote:
> On Fri, Jul 31, 2009 at 5:09 PM, Helge Deller wrote:
>> On 07/31/2009 09:03 PM, John David Anglin wrote:
Only 32-bit targets have the 14-bit signed immediate offset (0x3fff),
which becomes a 13-bit limit when loading positive
On 07/31/2009 08:49 PM, Carlos O'Donell wrote:
[...]
However, on 64-bit the long format of ldd has a 16-bit signed
immediate offset (0x), meaning it can reach +0x7fff e.g. 4095 GOT
slots.
Do you have the time to test something out?
* Make this conditional on 32-bit vs. 64-bit and allow for
On 07/31/2009 09:03 PM, John David Anglin wrote:
Only 32-bit targets have the 14-bit signed immediate offset (0x3fff),
which becomes a 13-bit limit when loading positive offsets e.g.
+0x1fff or 1023 GOT slots.
Can't we offset the table and double the number of entries?
Dave,
Can you explain t
> On Fri, Jul 31, 2009 at 5:17 AM, Frans Pop wrote:
> > Affects both stable and unstable!
> >
> > kernel: Linux version 2.6.26-2-parisc64-smp [...]
> > kernel: nfs: Global Offset Table overflow (used 1075, allowed 1023)
> >
> > kernel: Linux version 2.6.30-1-parisc64 [...]
> > kernel: nfs: Global O
On Fri, Jul 31, 2009 at 5:17 AM, Frans Pop wrote:
> Affects both stable and unstable!
>
> kernel: Linux version 2.6.26-2-parisc64-smp [...]
> kernel: nfs: Global Offset Table overflow (used 1075, allowed 1023)
>
> kernel: Linux version 2.6.30-1-parisc64 [...]
> kernel: nfs: Global Offset Table over
Package: linux-2.6
Version: 2.6.26-15
Severity: normal
Affects both stable and unstable!
kernel: Linux version 2.6.26-2-parisc64-smp [...]
kernel: nfs: Global Offset Table overflow (used 1075, allowed 1023)
kernel: Linux version 2.6.30-1-parisc64 [...]
kernel: nfs: Global Offset Table overflow (
21 matches
Mail list logo
