Re: Exception while loading kernel

Re: Exception while loading kernel

[Giuseppe Sacco]

Hi all,
I compiled the latest kernel 2.6.22.4 from www.kernel.org and 2.6.23-rc3
from linux-.mips.org using the .config from Debian
linux-image-2.6.22-1-r5k_ip32 and activating CONFIG_NFSD_V4 and a few
network device drivers.

The command I used to compile was:

$ fakeroot make-kpkg --revision 2:2.6.22 \
	--append-to-version -1gs-r5k-ip32 --arch-in-name buildpackage

When I boot an SGI O2 r5k with any of those kernel, I get this error message:
---------------------------------------------------------------------------
Loading 64-bit executable
Loading program segment 1 at 0x80005000, offset=0x0 4000, size = 0x0 4f8086
5dc000      (cache: 95.0%)Zeroing memory ar 0x82f611, size 0 0x0
Starting ELF64 kernel

Exception: <vector=Normal>
Status register: 0x34010082<CU1,CU0,FR,DE,IPL=8,KX,MODE=KERNEL>
Cause register: 0x8014<CE=0,IP8,EXC=WADE>
Exception PC: 0x802204fc, Exception RA: 0x804da7ac
Write address error exception, bad address: 0xfffff000
  Saved user regs in hex (&gpda 0x81060e08, &_regs 0x81061008):
  arg: 81070000 0 804ff518 1
  tmp: 81070000 1000 80516868 fff8054b ffffffff 81412ef4 a13fb0d0 8
  sve: 81070000 4083ae51 0 4608a976 0 0 0 80ee80d5
  t8 81070000 t9 0 at 0 v0 0 v1 0 k1 fffff000
  gp 81070000 fp 0 sp 0 ra 0

PANIC: Unexpected exception

[Press reset or ENTER to restart.]
---------------------------------------------------------------------------

If I understand correctly the problem happened at address 0x802204fc, so
I checked the system.map file and found
ffffffff802204c4 T __bzero
ffffffff80220524 t memset_partial

If I understand correctly, the kernel was executing the __bzero function
and tried accessing the invalid address 0xfffff000.

Other, maybe useful, addresses from system.map are:

ffffffff804da6e8 t init_bootmem_core
ffffffff804da7c8 t $L99

ffffffff80516868 b contig_bootmem_data

ffffffff804ff4e8 B boot_mem_map
ffffffff804ff7f0 B fw_arg0

>From these number, I guess that boot_mem_map contain an invalid address.
Is this correct?

Bye,
Giuseppe

Re: Exception while loading kernel

[Giuseppe Sacco]

Hi all,
I compiled the latest kernel 2.6.22.4 from www.kernel.org and 2.6.23-rc3
from linux-.mips.org using the .config from Debian
linux-image-2.6.22-1-r5k_ip32 and activating CONFIG_NFSD_V4 and a few
network device drivers.

The command I used to compile was:

$ fakeroot make-kpkg --revision 2:2.6.22 \
	--append-to-version -1gs-r5k-ip32 --arch-in-name buildpackage

When I boot an SGI O2 r5k with any of those kernel, I get this error message:
---------------------------------------------------------------------------
Loading 64-bit executable
Loading program segment 1 at 0x80005000, offset=0x0 4000, size = 0x0 4f8086
5dc000      (cache: 95.0%)Zeroing memory ar 0x82f611, size 0 0x0
Starting ELF64 kernel

Exception: <vector=Normal>
Status register: 0x34010082<CU1,CU0,FR,DE,IPL=8,KX,MODE=KERNEL>
Cause register: 0x8014<CE=0,IP8,EXC=WADE>
Exception PC: 0x802204fc, Exception RA: 0x804da7ac
Write address error exception, bad address: 0xfffff000
  Saved user regs in hex (&gpda 0x81060e08, &_regs 0x81061008):
  arg: 81070000 0 804ff518 1
  tmp: 81070000 1000 80516868 fff8054b ffffffff 81412ef4 a13fb0d0 8
  sve: 81070000 4083ae51 0 4608a976 0 0 0 80ee80d5
  t8 81070000 t9 0 at 0 v0 0 v1 0 k1 fffff000
  gp 81070000 fp 0 sp 0 ra 0

PANIC: Unexpected exception

[Press reset or ENTER to restart.]
---------------------------------------------------------------------------

If I understand correctly the problem happened at address 0x802204fc, so
I checked the system.map file and found
ffffffff802204c4 T __bzero
ffffffff80220524 t memset_partial

If I understand correctly, the kernel was executing the __bzero function
and tried accessing the invalid address 0xfffff000.

Other, maybe useful, addresses from system.map are:

ffffffff804da6e8 t init_bootmem_core
ffffffff804da7c8 t $L99

ffffffff80516868 b contig_bootmem_data

ffffffff804ff4e8 B boot_mem_map
ffffffff804ff7f0 B fw_arg0

From these number, I guess that boot_mem_map contain an invalid address.
Is this correct?

Bye,
Giuseppe

Re: Exception while loading kernel

[Markus Gothe]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

What about trying 2.6.22 from linux-mips.org in first place?

//Markus

Giuseppe Sacco wrote:
> Hi all, I compiled the latest kernel 2.6.22.4 from www.kernel.org
> and 2.6.23-rc3 from linux-.mips.org using the .config from Debian
> linux-image-2.6.22-1-r5k_ip32 and activating CONFIG_NFSD_V4 and a
> few network device drivers.
>
> The command I used to compile was:
>
> $ fakeroot make-kpkg --revision 2:2.6.22 \ --append-to-version
> -1gs-r5k-ip32 --arch-in-name buildpackage
>
> When I boot an SGI O2 r5k with any of those kernel, I get this
> error message:
> ---------------------------------------------------------------------------
>  Loading 64-bit executable Loading program segment 1 at 0x80005000,
> offset=0x0 4000, size = 0x0 4f8086 5dc000      (cache:
> 95.0%)Zeroing memory ar 0x82f611, size 0 0x0 Starting ELF64 kernel
>
> Exception: <vector=Normal> Status register:
> 0x34010082<CU1,CU0,FR,DE,IPL=8,KX,MODE=KERNEL> Cause register:
> 0x8014<CE=0,IP8,EXC=WADE> Exception PC: 0x802204fc, Exception RA:
> 0x804da7ac Write address error exception, bad address: 0xfffff000
> Saved user regs in hex (&gpda 0x81060e08, &_regs 0x81061008): arg:
> 81070000 0 804ff518 1 tmp: 81070000 1000 80516868 fff8054b ffffffff
> 81412ef4 a13fb0d0 8 sve: 81070000 4083ae51 0 4608a976 0 0 0
> 80ee80d5 t8 81070000 t9 0 at 0 v0 0 v1 0 k1 fffff000 gp 81070000 fp
> 0 sp 0 ra 0
>
> PANIC: Unexpected exception
>
> [Press reset or ENTER to restart.]
> ---------------------------------------------------------------------------
>
>
> If I understand correctly the problem happened at address
> 0x802204fc, so I checked the system.map file and found
> ffffffff802204c4 T __bzero ffffffff80220524 t memset_partial
>
> If I understand correctly, the kernel was executing the __bzero
> function and tried accessing the invalid address 0xfffff000.
>
> Other, maybe useful, addresses from system.map are:
>
> ffffffff804da6e8 t init_bootmem_core ffffffff804da7c8 t $L99
>
> ffffffff80516868 b contig_bootmem_data
>
> ffffffff804ff4e8 B boot_mem_map ffffffff804ff7f0 B fw_arg0
>
>> From these number, I guess that boot_mem_map contain an invalid
>> address.
> Is this correct?
>
> Bye, Giuseppe
>
>


- --
_______________________________________

Mr Markus Gothe
Software Engineer

Phone: +46 (0)13 21 81 20 (ext. 1046)
Fax: +46 (0)13 21 21 15
Mobile: +46 (0)73 718 72 80
Diskettgatan 11, SE-583 35 Linköping, Sweden
www.27m.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG0ssO6I0XmJx2NrwRCBk2AKCxH0yLfT8oA8Eu4GXyuIn/jRpbYQCfUphJ
YfP0wfQiLu2Qd+tz8+PZHQM=
=ofTk
-----END PGP SIGNATURE-----

Re: Exception while loading kernel

[Giuseppe Sacco]

Il giorno lun, 27/08/2007 alle 15.01 +0200, Markus Gothe ha scritto:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> What about trying 2.6.22 from linux-mips.org in first place?

I am going to recompile and try it.

Thanks,
Giuseppe

Re: Exception while loading kernel

[Giuseppe Sacco]

Hi Markus,

Il giorno lun, 27/08/2007 alle 15.01 +0200, Markus Gothe ha scritto:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> What about trying 2.6.22 from linux-mips.org in first place?
> 
> //Markus

2.6.22.2, downloaded from linux-mips.org, display the same problem. I
got:

Exception PC: 0x8022051c, Exception RA: 0x804da7ec
tmp: 81070000 1000 80516868 fff8054b ffffffff 81412ef4 a13fab68 7

and, from my System.map file,

ffffffff802204e4 T __bzero
ffffffff80220544 t memset_partial

ffffffff804da728 t init_bootmem_core
ffffffff804da808 t $L99

ffffffff80516860 B percpu_pagelist_fraction
ffffffff80516868 b contig_bootmem_data

Bye,
Giuseppe

Re: Exception while loading kernel

[Markus Gothe]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

Use gdb and list the read address.

//Markus

On 28 Aug, 2007, at 19:18 , Giuseppe Sacco wrote:

> Hi Markus,
>
> Il giorno lun, 27/08/2007 alle 15.01 +0200, Markus Gothe ha scritto:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> What about trying 2.6.22 from linux-mips.org in first place?
>>
>> //Markus
>
> 2.6.22.2, downloaded from linux-mips.org, display the same problem. I
> got:
>
> Exception PC: 0x8022051c, Exception RA: 0x804da7ec
> tmp: 81070000 1000 80516868 fff8054b ffffffff 81412ef4 a13fab68 7
>
> and, from my System.map file,
>
> ffffffff802204e4 T __bzero
> ffffffff80220544 t memset_partial
>
> ffffffff804da728 t init_bootmem_core
> ffffffff804da808 t $L99
>
> ffffffff80516860 B percpu_pagelist_fraction
> ffffffff80516868 b contig_bootmem_data
>
> Bye,
> Giuseppe
>
>

_______________________________________

Mr Markus Gothe
Software Engineer

Phone: +46 (0)13 21 81 20 (ext. 1046)
Fax: +46 (0)13 21 21 15
Mobile: +46 (0)73 718 72 80
Diskettgatan 11, SE-583 35 Linköping, Sweden
www.27m.com



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: Exception while loading kernel

[Giuseppe Sacco]

Hi Markus,

On Wed, 29 Aug 2007 04:25:35 +0200 Markus Gothe <markus.gothe@27m.se> wrote:
> Use gdb and list the read address.
> 
> //Markus

I never debugged the kernel. From what I read I should use something like kgdb. Did I understand correctly? Would you please point me the some documentation source for debugging as you wish?

Thanks,
Giuseppe

Re: Exception while loading kernel

[Ricardo Mendoza]

Try to build the kernel with CONFIG_BUILD_ELF64=n

Also, there's no support for kgdb on ip32 at the moment.


     Ricardo

Re: Exception while loading kernel

[Giuseppe Sacco]

Hi Ricardo,

Il giorno mer, 29/08/2007 alle 04.33 -0400, Ricardo Mendoza ha scritto:
> Try to build the kernel with CONFIG_BUILD_ELF64=n
> 
> Also, there's no support for kgdb on ip32 at the moment.

I already tried the 32bit kernel and I found the same problem. Are you
telling me that I should use 32bit for debugging instead of 64?

Bye,
Giuseppe

Re: Exception while loading kernel

[Ricardo Mendoza]

On 8/29/07, Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org> wrote:

> I already tried the 32bit kernel and I found the same problem. Are you
> telling me that I should use 32bit for debugging instead of 64?

No, what I'm telling you to do is to try and build it with
CONFIG_BUILD_ELF64 disabled, more explicitly that is under Executable
file formats or something like that. About kgdb debugging, what I am
telling you is that ip32 has no hook ups coded for it yet, in other
words, no support.


     Ricardo

Re: Exception while loading kernel

[Markus Gothe]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Ricardo Mendoza wrote:
> On 8/29/07, Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org>
> wrote:
>
>> I already tried the 32bit kernel and I found the same problem.
>> Are you telling me that I should use 32bit for debugging instead
>> of 64?
>
> No, what I'm telling you to do is to try and build it with
> CONFIG_BUILD_ELF64 disabled, more explicitly that is under
> Executable file formats or something like that. About kgdb
> debugging, what I am telling you is that ip32 has no hook ups coded
> for it yet, in other words, no support.
>
>
> Ricardo
>
You're all wrong build it with -g (i.e. enable 'Kernel
Hacking'-options), then strip it and saved the copy with debugging
symbols. Then you run gdb on the one with debugging symbols and voila
you get the function.

//Markus

- --
_______________________________________

Mr Markus Gothe
Software Engineer

Phone: +46 (0)13 21 81 20 (ext. 1046)
Fax: +46 (0)13 21 21 15
Mobile: +46 (0)73 718 72 80
Diskettgatan 11, SE-583 35 Linköping, Sweden
www.27m.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG1aQt6I0XmJx2NrwRCAi+AJ9mpYqqEFnRPl9+f9MDRPUhAGHBBwCgkYXL
U0ltGP7+Y+2xj9itgyjfJ6E=
=fgJH
-----END PGP SIGNATURE-----

Re: Exception while loading kernel

[Ricardo Mendoza]

On 8/29/07, Markus Gothe <markus.gothe@27m.se> wrote:

> You're all wrong build it with -g (i.e. enable 'Kernel
> Hacking'-options), then strip it and saved the copy with debugging
> symbols. Then you run gdb on the one with debugging symbols and voila
> you get the function.

I am talking ip32 specific here, ELF64 is a no go there. The exception
thrown is the same as when an ELF64 binary attempts to be loaded on my
ip32. I am sure his problem is not with code because ip32 works; even
less with that much of an early code (I hope you can see linux
exception vectors are not even installed).

Try that then do all the debugging you want ;)


     Ricardo

Re: Exception while loading kernel

[Giuseppe Sacco]

Hi Markus,

Il giorno mer, 29/08/2007 alle 04.25 +0200, Markus Gothe ha scritto:
> Use gdb and list the read address.

I think I understood what you mean. I recompiled the kernel adding the
debug symbols, stripped it and booted with it.
There I got those numbers (using the 32bit version):

Exception PC: 0x8021c9fc, Exception RA: 0x804ddc6c
gpda 0x81060e08, _regs 0x81061008
arg: 81070000 0 80503518 1
tmp: 81070000 1000 8051a868 fff8054f ffffffff 81412ef4 a13fab68 7
sve: 81070000 4083ae51 0 4608a976 0 4085cc91 0 3ed97758

then run gdb and issue those commands:

(gdb) info symbol 0x8021c9fc
__bzero + 56 in section .text
(gdb) info symbol 0x804ddc6c
init_bootmem_core + 196 in section .init.text
(gdb) list *0x804ddc6c
0x804ddc6c is in init_bootmem_core (mm/bootmem.c:107).
102              */
103             mapsize = get_mapsize(bdata);
104             memset(bdata->node_bootmem_map, 0xff, mapsize);
105
106             return mapsize;
107     }
108
109     /*
110      * Marks a particular physical memory range as unallocatable. Usable RAM
111      * might be used for boot-time allocations - or it might get added
(gdb) list *0x8021c9fc
No source file for address 0x8021c9fc.
(gdb) disassemble 0x804ddc6c
Dump of assembler code for function init_bootmem_core:
0xffffffff804ddba8 <init_bootmem_core+0>:       daddiu  sp,sp,-32
0xffffffff804ddbac <init_bootmem_core+4>:       sd      ra,16(sp)
0xffffffff804ddbb0 <init_bootmem_core+8>:       sd      s1,8(sp)
0xffffffff804ddbb4 <init_bootmem_core+12>:      sd      s0,0(sp)
0xffffffff804ddbb8 <init_bootmem_core+16>:      li      v0,-13
0xffffffff804ddbbc <init_bootmem_core+20>:      ld      s1,648(a0)
0xffffffff804ddbc0 <init_bootmem_core+24>:      dsll    a1,a1,0xc
0xffffffff804ddbc4 <init_bootmem_core+28>:      dsll32  v0,v0,0x1b
0xffffffff804ddbc8 <init_bootmem_core+32>:      daddu   a1,a1,v0
0xffffffff804ddbcc <init_bootmem_core+36>:      dsll    a2,a2,0xc
0xffffffff804ddbd0 <init_bootmem_core+40>:      sd      a1,16(s1)
0xffffffff804ddbd4 <init_bootmem_core+44>:      sd      a3,8(s1)
0xffffffff804ddbd8 <init_bootmem_core+48>:      sd      a2,0(s1)
0xffffffff804ddbdc <init_bootmem_core+52>:      lui     v1,0x0
0xffffffff804ddbe0 <init_bootmem_core+56>:      lui     at,0x8049
0xffffffff804ddbe4 <init_bootmem_core+60>:      daddiu  v1,v1,0
0xffffffff804ddbe8 <init_bootmem_core+64>:      dsll32  v1,v1,0x0
0xffffffff804ddbec <init_bootmem_core+68>:      daddu   v1,v1,at
0xffffffff804ddbf0 <init_bootmem_core+72>:      ld      v1,2112(v1)
0xffffffff804ddbf4 <init_bootmem_core+76>:      lui     a1,0x0
0xffffffff804ddbf8 <init_bootmem_core+80>:      lui     at,0x8049
0xffffffff804ddbfc <init_bootmem_core+84>:      daddiu  a1,a1,0
0xffffffff804ddc00 <init_bootmem_core+88>:      daddiu  at,at,2112
0xffffffff804ddc04 <init_bootmem_core+92>:      dsll32  a1,a1,0x0
0xffffffff804ddc08 <init_bootmem_core+96>:      daddu   a1,a1,at
0xffffffff804ddc0c <init_bootmem_core+100>:     bnel    v1,a1,0x804ddc88 <init_bootmem_core+224>
0xffffffff804ddc10 <init_bootmem_core+104>:     ld      v0,-48(v1)
0xffffffff804ddc14 <init_bootmem_core+108>:     daddiu  v0,s1,48
0xffffffff804ddc18 <init_bootmem_core+112>:     sd      a1,48(s1)
0xffffffff804ddc1c <init_bootmem_core+116>:     move    a0,s1
0xffffffff804ddc20 <init_bootmem_core+120>:     lui     at,0x0
0xffffffff804ddc24 <init_bootmem_core+124>:     daddiu  at,at,0
0xffffffff804ddc28 <init_bootmem_core+128>:     dsll    at,at,0x10
0xffffffff804ddc2c <init_bootmem_core+132>:     daddiu  at,at,-32695
0xffffffff804ddc30 <init_bootmem_core+136>:     dsll    at,at,0x10
0xffffffff804ddc34 <init_bootmem_core+140>:     sd      v0,2120(at)
0xffffffff804ddc38 <init_bootmem_core+144>:     lui     at,0x0
0xffffffff804ddc3c <init_bootmem_core+148>:     daddiu  at,at,0
0xffffffff804ddc40 <init_bootmem_core+152>:     dsll    at,at,0x10
0xffffffff804ddc44 <init_bootmem_core+156>:     daddiu  at,at,-32695
0xffffffff804ddc48 <init_bootmem_core+160>:     dsll    at,at,0x10
0xffffffff804ddc4c <init_bootmem_core+164>:     sd      v0,2112(at)
0xffffffff804ddc50 <init_bootmem_core+168>:     jal     0x804dd5c8 <get_mapsize>
0xffffffff804ddc54 <init_bootmem_core+172>:     sd      a1,8(v0)
0xffffffff804ddc58 <init_bootmem_core+176>:     ld      a0,16(s1)
0xffffffff804ddc5c <init_bootmem_core+180>:     move    s0,v0
0xffffffff804ddc60 <init_bootmem_core+184>:     li      a1,255
0xffffffff804ddc64 <init_bootmem_core+188>:     jal     0x8021c9a0 <memset>
0xffffffff804ddc68 <init_bootmem_core+192>:     move    a2,v0
0xffffffff804ddc6c <init_bootmem_core+196>:     move    v0,s0
0xffffffff804ddc70 <init_bootmem_core+200>:     ld      ra,16(sp)
0xffffffff804ddc74 <init_bootmem_core+204>:     ld      s1,8(sp)
0xffffffff804ddc78 <init_bootmem_core+208>:     ld      s0,0(sp)
0xffffffff804ddc7c <init_bootmem_core+212>:     jr      ra
[...]
(gdb) info line *0x804ddc6c
Line 107 of "mm/bootmem.c" starts at address 0x804ddc6c <init_bootmem_core+196> and ends at 0x804ddc88 <init_bootmem_core+224>.
(gdb) info line *0x804ddc6b
Line 104 of "mm/bootmem.c" starts at address 0x804ddc60 <init_bootmem_core+184> and ends at 0x804ddc6c <init_bootmem_core+196>.


So, it this what you requested?

>From what I understand the problem may be that bdata->node_bootmem_map
maybe incorrectly initialised for this machine.

Bye,
Giuseppe

Re: Exception while loading kernel

[Giuseppe Sacco]

Hi Markus,

Il giorno mer, 29/08/2007 alle 04.25 +0200, Markus Gothe ha scritto:
> Use gdb and list the read address.

I think I understood what you mean. I recompiled the kernel adding the
debug symbols, stripped it and booted with it.
There I got those numbers (using the 32bit version):

Exception PC: 0x8021c9fc, Exception RA: 0x804ddc6c
gpda 0x81060e08, _regs 0x81061008
arg: 81070000 0 80503518 1
tmp: 81070000 1000 8051a868 fff8054f ffffffff 81412ef4 a13fab68 7
sve: 81070000 4083ae51 0 4608a976 0 4085cc91 0 3ed97758

then run gdb and issue those commands:

(gdb) info symbol 0x8021c9fc
__bzero + 56 in section .text
(gdb) info symbol 0x804ddc6c
init_bootmem_core + 196 in section .init.text
(gdb) list *0x804ddc6c
0x804ddc6c is in init_bootmem_core (mm/bootmem.c:107).
102              */
103             mapsize = get_mapsize(bdata);
104             memset(bdata->node_bootmem_map, 0xff, mapsize);
105
106             return mapsize;
107     }
108
109     /*
110      * Marks a particular physical memory range as unallocatable. Usable RAM
111      * might be used for boot-time allocations - or it might get added
(gdb) list *0x8021c9fc
No source file for address 0x8021c9fc.
(gdb) disassemble 0x804ddc6c
Dump of assembler code for function init_bootmem_core:
0xffffffff804ddba8 <init_bootmem_core+0>:       daddiu  sp,sp,-32
0xffffffff804ddbac <init_bootmem_core+4>:       sd      ra,16(sp)
0xffffffff804ddbb0 <init_bootmem_core+8>:       sd      s1,8(sp)
0xffffffff804ddbb4 <init_bootmem_core+12>:      sd      s0,0(sp)
0xffffffff804ddbb8 <init_bootmem_core+16>:      li      v0,-13
0xffffffff804ddbbc <init_bootmem_core+20>:      ld      s1,648(a0)
0xffffffff804ddbc0 <init_bootmem_core+24>:      dsll    a1,a1,0xc
0xffffffff804ddbc4 <init_bootmem_core+28>:      dsll32  v0,v0,0x1b
0xffffffff804ddbc8 <init_bootmem_core+32>:      daddu   a1,a1,v0
0xffffffff804ddbcc <init_bootmem_core+36>:      dsll    a2,a2,0xc
0xffffffff804ddbd0 <init_bootmem_core+40>:      sd      a1,16(s1)
0xffffffff804ddbd4 <init_bootmem_core+44>:      sd      a3,8(s1)
0xffffffff804ddbd8 <init_bootmem_core+48>:      sd      a2,0(s1)
0xffffffff804ddbdc <init_bootmem_core+52>:      lui     v1,0x0
0xffffffff804ddbe0 <init_bootmem_core+56>:      lui     at,0x8049
0xffffffff804ddbe4 <init_bootmem_core+60>:      daddiu  v1,v1,0
0xffffffff804ddbe8 <init_bootmem_core+64>:      dsll32  v1,v1,0x0
0xffffffff804ddbec <init_bootmem_core+68>:      daddu   v1,v1,at
0xffffffff804ddbf0 <init_bootmem_core+72>:      ld      v1,2112(v1)
0xffffffff804ddbf4 <init_bootmem_core+76>:      lui     a1,0x0
0xffffffff804ddbf8 <init_bootmem_core+80>:      lui     at,0x8049
0xffffffff804ddbfc <init_bootmem_core+84>:      daddiu  a1,a1,0
0xffffffff804ddc00 <init_bootmem_core+88>:      daddiu  at,at,2112
0xffffffff804ddc04 <init_bootmem_core+92>:      dsll32  a1,a1,0x0
0xffffffff804ddc08 <init_bootmem_core+96>:      daddu   a1,a1,at
0xffffffff804ddc0c <init_bootmem_core+100>:     bnel    v1,a1,0x804ddc88 <init_bootmem_core+224>
0xffffffff804ddc10 <init_bootmem_core+104>:     ld      v0,-48(v1)
0xffffffff804ddc14 <init_bootmem_core+108>:     daddiu  v0,s1,48
0xffffffff804ddc18 <init_bootmem_core+112>:     sd      a1,48(s1)
0xffffffff804ddc1c <init_bootmem_core+116>:     move    a0,s1
0xffffffff804ddc20 <init_bootmem_core+120>:     lui     at,0x0
0xffffffff804ddc24 <init_bootmem_core+124>:     daddiu  at,at,0
0xffffffff804ddc28 <init_bootmem_core+128>:     dsll    at,at,0x10
0xffffffff804ddc2c <init_bootmem_core+132>:     daddiu  at,at,-32695
0xffffffff804ddc30 <init_bootmem_core+136>:     dsll    at,at,0x10
0xffffffff804ddc34 <init_bootmem_core+140>:     sd      v0,2120(at)
0xffffffff804ddc38 <init_bootmem_core+144>:     lui     at,0x0
0xffffffff804ddc3c <init_bootmem_core+148>:     daddiu  at,at,0
0xffffffff804ddc40 <init_bootmem_core+152>:     dsll    at,at,0x10
0xffffffff804ddc44 <init_bootmem_core+156>:     daddiu  at,at,-32695
0xffffffff804ddc48 <init_bootmem_core+160>:     dsll    at,at,0x10
0xffffffff804ddc4c <init_bootmem_core+164>:     sd      v0,2112(at)
0xffffffff804ddc50 <init_bootmem_core+168>:     jal     0x804dd5c8 <get_mapsize>
0xffffffff804ddc54 <init_bootmem_core+172>:     sd      a1,8(v0)
0xffffffff804ddc58 <init_bootmem_core+176>:     ld      a0,16(s1)
0xffffffff804ddc5c <init_bootmem_core+180>:     move    s0,v0
0xffffffff804ddc60 <init_bootmem_core+184>:     li      a1,255
0xffffffff804ddc64 <init_bootmem_core+188>:     jal     0x8021c9a0 <memset>
0xffffffff804ddc68 <init_bootmem_core+192>:     move    a2,v0
0xffffffff804ddc6c <init_bootmem_core+196>:     move    v0,s0
0xffffffff804ddc70 <init_bootmem_core+200>:     ld      ra,16(sp)
0xffffffff804ddc74 <init_bootmem_core+204>:     ld      s1,8(sp)
0xffffffff804ddc78 <init_bootmem_core+208>:     ld      s0,0(sp)
0xffffffff804ddc7c <init_bootmem_core+212>:     jr      ra
[...]
(gdb) info line *0x804ddc6c
Line 107 of "mm/bootmem.c" starts at address 0x804ddc6c <init_bootmem_core+196> and ends at 0x804ddc88 <init_bootmem_core+224>.
(gdb) info line *0x804ddc6b
Line 104 of "mm/bootmem.c" starts at address 0x804ddc60 <init_bootmem_core+184> and ends at 0x804ddc6c <init_bootmem_core+196>.


So, it this what you requested?

From what I understand the problem may be that bdata->node_bootmem_map
maybe incorrectly initialised for this machine.

Bye,
Giuseppe

Re: Exception while loading kernel

[Markus Gothe]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yes, this is usually the way (I use) to debug the kernel without using
kdbg /
adding hooks for kdbg.

Seems to me like a memory-addressing issue.

//Markus

Giuseppe Sacco wrote:
> Hi Markus,
>
> Il giorno mer, 29/08/2007 alle 04.25 +0200, Markus Gothe ha
> scritto:
>> Use gdb and list the read address.
>
> I think I understood what you mean. I recompiled the kernel adding
> the debug symbols, stripped it and booted with it. There I got
> those numbers (using the 32bit version):
>
> Exception PC: 0x8021c9fc, Exception RA: 0x804ddc6c gpda 0x81060e08,
> _regs 0x81061008 arg: 81070000 0 80503518 1 tmp: 81070000 1000
> 8051a868 fff8054f ffffffff 81412ef4 a13fab68 7 sve: 81070000
> 4083ae51 0 4608a976 0 4085cc91 0 3ed97758
>
> then run gdb and issue those commands:
>
> (gdb) info symbol 0x8021c9fc __bzero + 56 in section .text (gdb)
> info symbol 0x804ddc6c init_bootmem_core + 196 in section
> .init.text (gdb) list *0x804ddc6c 0x804ddc6c is in
> init_bootmem_core (mm/bootmem.c:107). 102              */ 103
> mapsize = get_mapsize(bdata); 104
> memset(bdata->node_bootmem_map, 0xff, mapsize); 105 106
> return mapsize; 107     } 108 109     /* 110      * Marks a
> particular physical memory range as unallocatable. Usable RAM 111
> * might be used for boot-time allocations - or it might get added
> (gdb) list *0x8021c9fc No source file for address 0x8021c9fc. (gdb)
> disassemble 0x804ddc6c Dump of assembler code for function
> init_bootmem_core: 0xffffffff804ddba8 <init_bootmem_core+0>:
> daddiu  sp,sp,-32 0xffffffff804ddbac <init_bootmem_core+4>:
> sd      ra,16(sp) 0xffffffff804ddbb0 <init_bootmem_core+8>:
> sd      s1,8(sp) 0xffffffff804ddbb4 <init_bootmem_core+12>:      sd
> s0,0(sp) 0xffffffff804ddbb8 <init_bootmem_core+16>:      li
> v0,-13 0xffffffff804ddbbc <init_bootmem_core+20>:      ld
> s1,648(a0) 0xffffffff804ddbc0 <init_bootmem_core+24>:      dsll
> a1,a1,0xc 0xffffffff804ddbc4 <init_bootmem_core+28>:      dsll32
> v0,v0,0x1b 0xffffffff804ddbc8 <init_bootmem_core+32>:      daddu
> a1,a1,v0 0xffffffff804ddbcc <init_bootmem_core+36>:      dsll
> a2,a2,0xc 0xffffffff804ddbd0 <init_bootmem_core+40>:      sd
> a1,16(s1) 0xffffffff804ddbd4 <init_bootmem_core+44>:      sd
> a3,8(s1) 0xffffffff804ddbd8 <init_bootmem_core+48>:      sd
> a2,0(s1) 0xffffffff804ddbdc <init_bootmem_core+52>:      lui
> v1,0x0 0xffffffff804ddbe0 <init_bootmem_core+56>:      lui
> at,0x8049 0xffffffff804ddbe4 <init_bootmem_core+60>:      daddiu
> v1,v1,0 0xffffffff804ddbe8 <init_bootmem_core+64>:      dsll32
> v1,v1,0x0 0xffffffff804ddbec <init_bootmem_core+68>:      daddu
> v1,v1,at 0xffffffff804ddbf0 <init_bootmem_core+72>:      ld
> v1,2112(v1) 0xffffffff804ddbf4 <init_bootmem_core+76>:      lui
> a1,0x0 0xffffffff804ddbf8 <init_bootmem_core+80>:      lui
> at,0x8049 0xffffffff804ddbfc <init_bootmem_core+84>:      daddiu
> a1,a1,0 0xffffffff804ddc00 <init_bootmem_core+88>:      daddiu
> at,at,2112 0xffffffff804ddc04 <init_bootmem_core+92>:      dsll32
> a1,a1,0x0 0xffffffff804ddc08 <init_bootmem_core+96>:      daddu
> a1,a1,at 0xffffffff804ddc0c <init_bootmem_core+100>:     bnel
> v1,a1,0x804ddc88 <init_bootmem_core+224> 0xffffffff804ddc10
> <init_bootmem_core+104>:     ld      v0,-48(v1) 0xffffffff804ddc14
> <init_bootmem_core+108>:     daddiu  v0,s1,48 0xffffffff804ddc18
> <init_bootmem_core+112>:     sd      a1,48(s1) 0xffffffff804ddc1c
> <init_bootmem_core+116>:     move    a0,s1 0xffffffff804ddc20
> <init_bootmem_core+120>:     lui     at,0x0 0xffffffff804ddc24
> <init_bootmem_core+124>:     daddiu  at,at,0 0xffffffff804ddc28
> <init_bootmem_core+128>:     dsll    at,at,0x10 0xffffffff804ddc2c
> <init_bootmem_core+132>:     daddiu  at,at,-32695
> 0xffffffff804ddc30 <init_bootmem_core+136>:     dsll    at,at,0x10
> 0xffffffff804ddc34 <init_bootmem_core+140>:     sd      v0,2120(at)
>  0xffffffff804ddc38 <init_bootmem_core+144>:     lui     at,0x0
> 0xffffffff804ddc3c <init_bootmem_core+148>:     daddiu  at,at,0
> 0xffffffff804ddc40 <init_bootmem_core+152>:     dsll    at,at,0x10
> 0xffffffff804ddc44 <init_bootmem_core+156>:     daddiu
> at,at,-32695 0xffffffff804ddc48 <init_bootmem_core+160>:     dsll
> at,at,0x10 0xffffffff804ddc4c <init_bootmem_core+164>:     sd
> v0,2112(at) 0xffffffff804ddc50 <init_bootmem_core+168>:     jal
> 0x804dd5c8 <get_mapsize> 0xffffffff804ddc54
> <init_bootmem_core+172>:     sd      a1,8(v0) 0xffffffff804ddc58
> <init_bootmem_core+176>:     ld      a0,16(s1) 0xffffffff804ddc5c
> <init_bootmem_core+180>:     move    s0,v0 0xffffffff804ddc60
> <init_bootmem_core+184>:     li      a1,255 0xffffffff804ddc64
> <init_bootmem_core+188>:     jal     0x8021c9a0 <memset>
> 0xffffffff804ddc68 <init_bootmem_core+192>:     move    a2,v0
> 0xffffffff804ddc6c <init_bootmem_core+196>:     move    v0,s0
> 0xffffffff804ddc70 <init_bootmem_core+200>:     ld      ra,16(sp)
> 0xffffffff804ddc74 <init_bootmem_core+204>:     ld      s1,8(sp)
> 0xffffffff804ddc78 <init_bootmem_core+208>:     ld      s0,0(sp)
> 0xffffffff804ddc7c <init_bootmem_core+212>:     jr      ra [...]
> (gdb) info line *0x804ddc6c Line 107 of "mm/bootmem.c" starts at
> address 0x804ddc6c <init_bootmem_core+196> and ends at 0x804ddc88
> <init_bootmem_core+224>. (gdb) info line *0x804ddc6b Line 104 of
> "mm/bootmem.c" starts at address 0x804ddc60 <init_bootmem_core+184>
> and ends at 0x804ddc6c <init_bootmem_core+196>.
>
>
> So, it this what you requested?
>
>> From what I understand the problem may be that
>> bdata->node_bootmem_map
> maybe incorrectly initialised for this machine.
>
> Bye, Giuseppe
>
>


- --
_______________________________________

Mr Markus Gothe
Software Engineer

Phone: +46 (0)13 21 81 20 (ext. 1046)
Fax: +46 (0)13 21 21 15
Mobile: +46 (0)73 718 72 80
Diskettgatan 11, SE-583 35 Linköping, Sweden
www.27m.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG1xR56I0XmJx2NrwRCCIIAJ9qqcFcMJK7izUn/yJUiUQwufHnYACeIiqt
tNI/Ew/0EFKp7Qzxi3issJU=
=NbCf
-----END PGP SIGNATURE-----

Re: Exception while loading kernel

[Giuseppe Sacco]

Il giorno gio, 30/08/2007 alle 22.04 +0200, Markus Gothe ha scritto:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Yes, this is usually the way (I use) to debug the kernel without using
> kdbg /
> adding hooks for kdbg.
> 
> Seems to me like a memory-addressing issue.

May I provide more information on this problem? Is it enought for fixing
it?

Thanks,
Giuseppe

Re: Exception while loading kernel

[Giuseppe Sacco]

Il giorno mer, 29/08/2007 alle 06.05 -0400, Ricardo Mendoza ha scritto:
> On 8/29/07, Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org> wrote:
> 
> > I already tried the 32bit kernel and I found the same problem. Are you
> > telling me that I should use 32bit for debugging instead of 64?
> 
> No, what I'm telling you to do is to try and build it with
> CONFIG_BUILD_ELF64 disabled, more explicitly that is under Executable
> file formats or something like that. About kgdb debugging, what I am
> telling you is that ip32 has no hook ups coded for it yet, in other
> words, no support.

I tried recompiling the 2.6.23-rc3 from linux-mips.org with
CONFIG_BUILD_ELF64=n, but I got a compiler error:

  CC [M]  net/sched/em_nbyte.o
  CC [M]  net/sched/em_u32.o
  CC [M]  net/sched/em_meta.o
net/sched/em_meta.c: In function ‘meta_int_loadavg_0’:
net/sched/em_meta.c:127: error: PRINT_OPERAND, invalid operand for relocation
(const:DI (plus:DI (symbol_ref:DI ("avenrun") [flags 0x40] <var_decl 0x2b357f50 avenrun>)
        (const_int 4 [0x4])))
net/sched/em_meta.c:127: internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see <URL:file:///usr/share/doc/gcc-4.1/README.Bugs>.
{standard input}: Assembler messages:
{standard input}:2436: Warning: end of file not at end of a line; newline inserted
{standard input}:2547: Warning: missing .end at end of assembly
Preprocessed source stored into /tmp/cc0KjlCH.out file, please attach this to your bugreport.
make[3]: *** [net/sched/em_meta.o] Error 1
make[2]: *** [net/sched] Error 2
make[1]: *** [net] Error 2
make[1]: Leaving directory `/usr/local/src/linux-2.6.23-rc3'
make: *** [debian/stamp-build-kernel] Error 2

I will try to submit the bug report to gcc.

Bye,
Giuseppe

Re: Exception while loading kernel

[Markus Gothe]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Which version are the toolchain binutils,gcc) you're using?

//Markus

Giuseppe Sacco wrote:
> Il giorno mer, 29/08/2007 alle 06.05 -0400, Ricardo Mendoza ha
> scritto:
>> On 8/29/07, Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org>
>> wrote:
>>
>>> I already tried the 32bit kernel and I found the same problem.
>>> Are you telling me that I should use 32bit for debugging
>>> instead of 64?
>> No, what I'm telling you to do is to try and build it with
>> CONFIG_BUILD_ELF64 disabled, more explicitly that is under
>> Executable file formats or something like that. About kgdb
>> debugging, what I am telling you is that ip32 has no hook ups
>> coded for it yet, in other words, no support.
>
> I tried recompiling the 2.6.23-rc3 from linux-mips.org with
> CONFIG_BUILD_ELF64=n, but I got a compiler error:
>
> CC [M]  net/sched/em_nbyte.o CC [M]  net/sched/em_u32.o CC [M]
> net/sched/em_meta.o net/sched/em_meta.c: In function
> �meta_int_loadavg_0�: net/sched/em_meta.c:127: error:
> PRINT_OPERAND, invalid operand for relocation (const:DI (plus:DI
> (symbol_ref:DI ("avenrun") [flags 0x40] <var_decl 0x2b357f50
> avenrun>) (const_int 4 [0x4]))) net/sched/em_meta.c:127: internal
> compiler error: in print_operand_reloc, at config/mips/mips.c:5579
> Please submit a full bug report, with preprocessed source if
> appropriate. See <URL:http://gcc.gnu.org/bugs.html> for
> instructions. For Debian GNU/Linux specific bug reporting
> instructions, see <URL:file:///usr/share/doc/gcc-4.1/README.Bugs>.
> {standard input}: Assembler messages: {standard input}:2436:
> Warning: end of file not at end of a line; newline inserted
> {standard input}:2547: Warning: missing .end at end of assembly
> Preprocessed source stored into /tmp/cc0KjlCH.out file, please
> attach this to your bugreport. make[3]: *** [net/sched/em_meta.o]
> Error 1 make[2]: *** [net/sched] Error 2 make[1]: *** [net] Error 2
>  make[1]: Leaving directory `/usr/local/src/linux-2.6.23-rc3' make:
> *** [debian/stamp-build-kernel] Error 2
>
> I will try to submit the bug report to gcc.
>
> Bye, Giuseppe
>
>


- --
_______________________________________

Mr Markus Gothe
Software Engineer

Phone: +46 (0)13 21 81 20 (ext. 1046)
Fax: +46 (0)13 21 21 15
Mobile: +46 (0)73 718 72 80
Diskettgatan 11, SE-583 35 Linköping, Sweden
www.27m.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG17/u6I0XmJx2NrwRCEgWAKC/gDbBFTt2o6Vu8eiJr1J7BwOTFgCeODEq
DxydsZElXSV+ubTV8wQWGrc=
=ur/q
-----END PGP SIGNATURE-----

Re: Exception while loading kernel

[Giuseppe Sacco]

Il giorno ven, 31/08/2007 alle 09.14 +0200, Markus Gothe ha scritto:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Which version are the toolchain binutils,gcc) you're using?

2.17-3 from Debian stable "etch".
I reported the problem on gcc bugzilla, but I read the note about
binutils version when unset CONFIG_BUILD_ELF64.

Bye,
Giuseppe

Re: Exception while loading kernel

[J. Scott Kasten]

Hi Giuseppe,

I think I'm getting a clue what is happening to your kernel.  Would you 
please do an "ls -l" in your /boot and tell me exactly HOW BIG your 
System.map and kernel files are?  :)

I took your config as is from the link below and pulled the linux-mips 
source, built it and then made a fascinating discovery when I tried to set 
it up for a boot.

The System.map was OVER 50 MEGS, and the kernel weighed in at a HEFTY 87 
MEGS.

In the various parts of the kernel config, you will see some options for 
the kernel sysmbol table, driver symbols, etc...  Try turning some of 
those off.  In particular, I noticed in your config:

CONFIG_UNUSED_SYMBOLS=y

I suspect you are stressing things that haven't been looked at lately.

Anyway, rebuild with some things turned off, and let us know if your 
little blue box still explodes.

Regards,

-S-

On Thu, 30 Aug 2007, Giuseppe Sacco wrote:

> Il giorno gio, 30/08/2007 alle 09.37 -0400, J. Scott Kasten ha scritto:
>> Giuseppe,
>>
>> Let's review for just a second.  If I understand, you are booting the
>> debian pre-built 2.6.18-4 just fine.  However, any kernel you build
>> yourself seems to be borked.  Correct?
>
> No, I may rebuild 2.6.18 just fine. I even added a few device drivers
> without problems. Lately I tried a more recent kernel, i.e. 2.6.22.2
> 2.6.22.4 and 2.6.23-rc3, bot no one of them seems to boot on an SGI O2.
>
>> You don't need to spam the list with it, but please gzip one or more of
>> your .config files, label them as to kernel version, and email me direct
>> off list.  I would like to try and recreate your problem and see what can
>> be learned here.
>
> you may get the config (for 2.6.22.2 download from linux-mips.org) from
> http://eppesuigoccas.homedns.org/~giuseppe/debian/config-2.6.22.2.bz2
>
> Thanks,
> Giuseppe
>
>
> -- 
> To UNSUBSCRIBE, email to debian-mips-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>

Re: Exception while loading kernel

[Giuseppe Sacco]

Hi -S-,

On Thu, 6 Sep 2007 06:58:15 -0400 (EDT) "J. Scott Kasten" <jscottkasten@yahoo.com> wrote:
[...] 
> The System.map was OVER 50 MEGS, and the kernel weighed in at a HEFTY 87 
> MEGS.

My kernel and System.map looks very normal. I had the same file sizes you reported, but only when compiling with all debug symbols. Once stripped the kernel became at the normal size, about 8Mb.

When I got the large kernel, I stripped it before copying it in /boot. Arcboot never used the large file.

Bye,
Giuseppe