Package: linux-2.6
Version: 2.6.30-3
Severity: important
The 2.6.30-1-parisc64-smp kernel fails to boot on my J5600 system.
The non-smp kernel does boot correctly and the oops also indicates
an smp problem.
Boot log from serial console attached.
-- System Information:
Debian Release:
* Frans Pop elen...@planet.nl [2009-07-31 08:17]:
The 2.6.30-1-parisc64-smp kernel fails to boot on my J5600 system.
The non-smp kernel does boot correctly and the oops also indicates
an smp problem.
Copying debian-h...@lists.debian.org...
Boot log from serial console attached.
-- System
Hmm. The Badness at smp.c warning isn't new of course. That was also
there with .24 and .26 (the last working kernel I have).
What is new is that the boot now hangs immediately after that point.
I also note the following in the boot messages:
unwind_init: start = 0x404b9144, end = 0x404e5204,
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
During compilations using gcc-4.3 of the upstream 2.6.31-rc4 kernel, I
twice noticed the warning below. As the compilation was done with '-j4',
I'm not sure what code causes it. I'm also not sure if the example below
is the same as the first time I saw it.
Is this something to worry about, or to
On Friday 31 July 2009, Frans Pop wrote:
Hmm. The Badness at smp.c warning isn't new of course. That was also
there with .24 and .26 (the last working kernel I have).
What is new is that the boot now hangs immediately after that point.
Whatever the problem is, it looks to be solved in
On Fri, Jul 31, 2009 at 11:13 AM, Frans Popelen...@planet.nl wrote:
On Friday 31 July 2009, Frans Pop wrote:
Hmm. The Badness at smp.c warning isn't new of course. That was also
there with .24 and .26 (the last working kernel I have).
What is new is that the boot now hangs immediately after
On Fri, Jul 31, 2009 at 10:26 AM, Frans Popelen...@planet.nl wrote:
During compilations using gcc-4.3 of the upstream 2.6.31-rc4 kernel, I
twice noticed the warning below. As the compilation was done with '-j4',
I'm not sure what code causes it. I'm also not sure if the example below
is the
fyi: http://bugs.debian.org/539378
--
dann frazier
--
To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Friday 31 July 2009, Carlos O'Donell wrote:
On Fri, Jul 31, 2009 at 10:26 AM, Frans Popelen...@planet.nl wrote:
During compilations using gcc-4.3 of the upstream 2.6.31-rc4 kernel,
I twice noticed the warning below. As the compilation was done with
'-j4', I'm not sure what code causes
On Fri, 31 Jul 2009, Carlos O'Donell wrote:
On Fri, Jul 31, 2009 at 10:26 AM, Frans Popelen...@planet.nl wrote:
During compilations using gcc-4.3 of the upstream 2.6.31-rc4 kernel, I
twice noticed the warning below. As the compilation was done with '-j4',
I'm not sure what code causes it.
On Fri, Jul 31, 2009 at 5:17 AM, Frans Popelen...@planet.nl 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
On Fri, Jul 31, 2009 at 2:18 PM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
On Fri, 31 Jul 2009, Carlos O'Donell wrote:
On Fri, Jul 31, 2009 at 10:26 AM, Frans Popelen...@planet.nl wrote:
During compilations using gcc-4.3 of the upstream 2.6.31-rc4 kernel, I
twice noticed the warning
On Fri, Jul 31, 2009 at 2:00 PM, dann frazierda...@debian.org wrote:
fyi: http://bugs.debian.org/539378
Thanks Dann. I've written up a response along with sketch of a
solution. My free time is pretty swamped with porter work and glibc
testing, so I was hoping one of the kernel hackers could
On Fri, Jul 31, 2009 at 1:45 PM, Frans Popelen...@planet.nl wrote:
On Friday 31 July 2009, Carlos O'Donell wrote:
I'm glad this is fixed in 2.6.31-rc4, do you need any more help from
the porters?
Well, it might be nice if the responsible change(s) could be identified.
Possibly they could be
On Fri, Jul 31, 2009 at 5:17 AM, Frans Popelen...@planet.nl 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:
GCC loads various constants with depwi and depdi. =A0The deposit length
was wrong.
If I understand correctly, are you saying that debian's gcc is at
fault, and that the bug was never in a released version of gcc?
No, the bug is present in all released versions of gcc. They need
to build
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
On Fri, Jul 31, 2009 at 5:09 PM, Helge Dellerdel...@gmx.de 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 offset
On Fri, Jul 31, 2009 at 5:13 PM, Carlos O'Donellcar...@systemhalted.org wrote:
On Fri, Jul 31, 2009 at 5:09 PM, Helge Dellerdel...@gmx.de 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
On 07/30/2009 07:44 PM, John David Anglin wrote:
On Thu, Jul 30, 2009 at 10:50 AM, Andreas Bartha...@not.so.argh.org wrote:
You know your porters mailing list best, but I want to highlight some of
the issues:
http://lists.debian.org/debian-hppa/2009/07/msg2.html
I can't comment on this
On Fri, Jul 31, 2009 at 5:09 PM, Helge Dellerdel...@gmx.de 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
On Fri, Jul 31, 2009 at 5:26 PM, John David
Anglind...@hiauly1.hia.nrc.ca 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.
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
Anglind...@hiauly1.hia.nrc.ca wrote:
I don't have more details... The idea is as Carlos outlined. There's
code in the binutils
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
Anglind...@hiauly1.hia.nrc.ca 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
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;/* bve
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;/* bve (%r1)
On Fri, Jul 31, 2009 at 7:38 PM, Kyle McMartink...@mcmartin.ca 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 @@
On Thu, Jul 30, 2009 at 8:37 PM, John David
Anglind...@hiauly1.hia.nrc.ca 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;
30 matches
Mail list logo
