Kernel crash on boot with current cvs (todays)

Kernel crash on boot with current cvs (todays)

[Florian Lohoff]

Hi,
i just tried to boot an Indy of mine with the current cvs (from this
morning) and it crashes 


ksymoops 2.4.1 on i686 2.2.18ext3.  Options used
     -v vmlinux-2.4.3 (specified)
     -K (specified)
     -L (specified)
     -o lib/modules/2.4.3 (specified)
     -m System.map-2.4.3 (specified)

No modules in ksyms, skipping objects
kernel BUG at semaphore.c:235!
Unable to handle kernel paging request at virtual address 00000000, epc == 8800f02c, ra == 8800f02c
$0 : 00000000 3004fc00 0000001f 89d0e000
$4 : 00000017 00000000 00000001 88669440
$8 : 0000000a 8814cc50 00000000 00000000
$12: 00000000 8814c870 fffffff9 0000000a
$16: 8866977c 00000000 89d0e000 88669784
$20: 89d0ff04 89d0ff00 89d0fea0 00000009
$24: 89d0fcf2 ffffffff
$28: 89d0e000 89d0fdd8 7fff7ba0 8800f02c
epc   : 8800f02c
Using defaults from ksymoops -t elf32-little -a unknown
Status: 3004fc03
Cause : 3000000c
Process start-stop-daem (pid: 211, stackpage=89d0e000)
Stack: 88106e30 88106e48 000000eb 00000000 8866977c 88669760 8800ed54 2aba3820
       00000000 885d1280 88064cf0 88065cd4 00000000 89d0e000 88669784 88669784
       fffffffe 88669760 89e24640 8866977c 89d0ff04 88064b50 89e24460 8bd1d8e0
       89d0ff00 89d0ff00 89e24640 89d0ff00 89e24640 8b6d400d 89d0ff00 89d0ff04
       880655d0 88065598 89e24640 88060cf4 89e24460 8b6d400d 8bd1d960 8bd1d960
       88053f88 ...
Call Trace: [<88106e30>] [<88106e48>] [<8800ed54>] [<88064cf0>] [<88065cd4>] [<88064b50>] [<880655d0>] [<88065598>] [<88060cf4>] [<88053f88>] [<88054074>] [<88054cc0>] [<88054c68>] [<88053794>] [<88050414>] [<8800fe08>] [<8800fe08>]
Code: 240600eb  0e007d99  00000000 <ae200000> 26040010  24050003  0e007085  24060001  0a003bf9
Error (Oops_bfd_perror): scan_arch for specified architecture Success

>>RA;  8800f02c <__rwsem_wake+b8/dc>
>>???; 8800f02c <__rwsem_wake+b8/dc>   <=====
Trace; 88106e30 <__gnu_compiled_c+d90/1204>
Trace; 88106e48 <__gnu_compiled_c+da8/1204>
Trace; 8800ed54 <__down_read+1dc/1e4>
Trace; 88064cf0 <proc_root_link+b4/e4>
Trace; 88065cd4 <proc_pid_make_inode+24/10c>
Trace; 88064b50 <proc_exe_link+1cc/1d4>
Trace; 880655d0 <proc_pid_follow_link+98/b0>
Trace; 88065598 <proc_pid_follow_link+60/b0>
Trace; 88060cf4 <update_atime+6c/78>
Trace; 88053f88 <path_walk+334/a94>
Trace; 88054074 <path_walk+420/a94>
Trace; 88054cc0 <__user_walk+78/94>
Trace; 88054c68 <__user_walk+20/94>
Trace; 88053794 <path_release+18/74>
Trace; 88050414 <sys_newstat+20/98>
Trace; 8800fe08 <stack_done+1c/38>
Trace; 8800fe08 <stack_done+1c/38>

1 error issued.  Results may not be reliable.


-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Kernel crash on boot with current cvs (todays)

[Keith Owens]

On Mon, 11 Jun 2001 00:03:59 +0200, 
Florian Lohoff <flo@rfc822.org> wrote:
>i just tried to boot an Indy of mine with the current cvs (from this
>morning) and it crashes 
>
>ksymoops 2.4.1 on i686 2.2.18ext3.  Options used
>Using defaults from ksymoops -t elf32-little -a unknown
>Error (Oops_bfd_perror): scan_arch for specified architecture Success

I cannot help with the oops but your ksymoops run has problems.  When
doing cross system oops debugging, you need to specify the target
machine and architecture with the -t and -a flags.  Otherwise ksymoops 
defaults to the current machine.  Adding -t and -a will fix the above
error and decode the code: line.

Re: Kernel crash on boot with current cvs (todays)

[Florian Lohoff]

On Mon, Jun 11, 2001 at 01:53:04PM +1000, Keith Owens wrote:
> On Mon, 11 Jun 2001 00:03:59 +0200, 
> Florian Lohoff <flo@rfc822.org> wrote:
> >i just tried to boot an Indy of mine with the current cvs (from this
> >morning) and it crashes 
> >
> >ksymoops 2.4.1 on i686 2.2.18ext3.  Options used
> >Using defaults from ksymoops -t elf32-little -a unknown
> >Error (Oops_bfd_perror): scan_arch for specified architecture Success
> 
> I cannot help with the oops but your ksymoops run has problems.  When
> doing cross system oops debugging, you need to specify the target
> machine and architecture with the -t and -a flags.  Otherwise ksymoops 
> defaults to the current machine.  Adding -t and -a will fix the above
> error and decode the code: line.

Nope - it wont as it strictly uses the /usr/bin/objdump - You have to
set the environment var "KSYMOOPS_OBJDUMP"

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Kernel crash on boot with current cvs (todays)

[Maciej W. Rozycki]

On Mon, 11 Jun 2001, Florian Lohoff wrote:

> Nope - it wont as it strictly uses the /usr/bin/objdump - You have to
> set the environment var "KSYMOOPS_OBJDUMP"

 Good it has a way to override the default, but wouldn't looking for
objdump in the PATH variable (i.e. using execvp()) be more reasonable?
This way ksymoops would always work in a cross-compilation environment
(i.e. with $tooldir/bin preceding $bindir in PATH).

 Just an ad-hoc idea...

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Kernel crash on boot with current cvs (todays)

[Keith M Wesolowski]

On Tue, Jun 12, 2001 at 03:01:32AM +0200, Maciej W. Rozycki wrote:

>  Good it has a way to override the default, but wouldn't looking for
> objdump in the PATH variable (i.e. using execvp()) be more reasonable?
> This way ksymoops would always work in a cross-compilation environment
> (i.e. with $tooldir/bin preceding $bindir in PATH).

Actually, it would probably be preferable to try first arch-os-objdump
and maybe one or two other similar variants and then search the path.
Supposing I have multiple cross environments on my machine...

-- 
Keith M Wesolowski <wesolows@foobazco.org> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
	"Nothing motivates a man more than to see his boss put
	 in an honest day's work." -- The fortune file

Re: Kernel crash on boot with current cvs (todays)

[Maciej W. Rozycki]

On Mon, 11 Jun 2001, Keith M Wesolowski wrote:

> Actually, it would probably be preferable to try first arch-os-objdump
> and maybe one or two other similar variants and then search the path.

 Sure, if you know how to guess the names (I don't).  The PATH approach
should work well if you choose one cross environment at a time.

> Supposing I have multiple cross environments on my machine...

 Does anyone have only a single one? ;-)  (Having a complete mipsel-linux,
a basic alpha-linux and a few obscure partial environments...) 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Kernel crash on boot with current cvs (todays)

[Keith Owens]

> On Mon, 11 Jun 2001, Florian Lohoff wrote:
> 
> > Nope - it wont as it strictly uses the /usr/bin/objdump - You have to
> > set the environment var "KSYMOOPS_OBJDUMP"
> 
>  Good it has a way to override the default, but wouldn't looking for
> objdump in the PATH variable (i.e. using execvp()) be more reasonable?
> This way ksymoops would always work in a cross-compilation environment
> (i.e. with $tooldir/bin preceding $bindir in PATH).

I originally designed ksymoops that way but there are so many different
methods of naming the binutils for cross compile environments that I
gave up.  Using the path runs the risk of picking random versions of nm
and objdump and still not being correct.  Anybody running cross compile
has to specify parameters for System.map, ksyms and objects, so adding
paths for binutils is a small change and is the only way to guarantee
that the correct versions are used.

Re: Kernel crash on boot with current cvs (todays)

[Ralf Baechle]

On Mon, Jun 11, 2001 at 12:03:59AM +0200, Florian Lohoff wrote:

> Hi,
> i just tried to boot an Indy of mine with the current cvs (from this
> morning) and it crashes 

> No modules in ksyms, skipping objects
> kernel BUG at semaphore.c:235!
> Unable to handle kernel paging request at virtual address 00000000, epc == 8800f02c, ra == 8800f02c

This is a known and yet unresolved problem.  Yet I'm surprised - so far
I've only seen this problem on mips64.

  Ralf

Re: Kernel crash on boot with current cvs (todays)

[Raoul Borenius]

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

Hi,

On Mon, Jun 11, 2001 at 06:42:49AM +0200, Ralf Baechle wrote:
> On Mon, Jun 11, 2001 at 12:03:59AM +0200, Florian Lohoff wrote:
> 
> > Hi,
> > i just tried to boot an Indy of mine with the current cvs (from this
> > morning) and it crashes 
> 
> > No modules in ksyms, skipping objects
> > kernel BUG at semaphore.c:235!
> > Unable to handle kernel paging request at virtual address 00000000, epc == 8800f02c, ra == 8800f02c
> 
> This is a known and yet unresolved problem.  Yet I'm surprised - so far
> I've only seen this problem on mips64.
> 
>   Ralf

Just FYI: the same happens on our Indy, see trace.txt and boot.txt.

Hope it helps...

Regards

Raoul

 ---------------------------------------------------------------------
 Raoul Gunnar Borenius		Deutsches Forschungsnetz e.V.
 WiNShuttle			Lindenspürstr.32, 70176 Stuttgart
 Phone  : +49 711 63314-206	FAX: +49 711 63314-133
 E-Mail : borenius@shuttle.de	http://www.shuttle.de
 ---------------------------------------------------------------------


[-- Attachment #2: trace.txt --]
[-- Type: text/plain, Size: 3804 bytes --]

ksymoops 2.4.1 on mips 2.4.3-cvs20010611.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.3-cvs20010611/ (default)
     -m /boot/System.map-2.4.3-cvs20010611 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file?
Starting periodic command scheduler: cronkernel BUG at semaphore.c:235!
Unable to handle kernel paging request at virtual address 00000000, epc == 8800eed0, ra == 8800eed0
$0 : 00000000 1000fc00 0000001f 00000001
$4 : 00000017 0000001f 8f626000 886603a0
$8 : 000d1b70 0000003c 00079c00 00000000
$12: 88157570 fffffff9 ffffffff 8f627ce2
$16: 8866059c 00000000 8f627f00 886605a4
$20: 8f627f04 8f627f00 8f627f04 00000009
$24: 00000002 0000000a
$28: 8f626000 8f627dd0 7fff7bb0 8800eed0
epc   : 8800eed0
Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
Status: 1000fc03
Cause : 0000000c
Process start-stop-daem (pid: 129, stackpage=8f626000)
Stack: 881080e0 881081c4 000000eb 00000002 8866059c 8f626000 8800eb5c 8806854c
       00000000 8ff862e0 88067590 00000000 00000000 8f626000 886605a8 886605a8
       fffffffe 88660580 8f627f00 8866059c 880672ac 880679c4 8f8deca0 8f9ad8a0
       8f627f00 8f9ada20 00000000 8f9ada20 8f627f00 8814200d 8f627e98 8f627f00
       88067e28 88067dc4 8f9ada20 88060364 8f627e98 8f627f00 8f8deca0 8f8deca0
       8f9ada20 ...
Call Trace: [<881080e0>] [<881081c4>] [<8800eb5c>] [<8806854c>] [<88067590>] [<880672ac>] [<880679c4>] [<88067e28>] [<88067dc4>] [<88060364>] [<88053da4>] [<88054488>] [<88053070>] [<8804fdf8>] [<8804fe50>] [<8800fca8>] [<8800fca8>]
Code: 24a581c4  0e007c56  240600eb <ae200000> 26040014  24050003  0e006f4a  24060001  8fbf0018 

>>RA;  8800eed0 <__rwsem_wake+98/c8>
>>PC;  8800eed0 <__rwsem_wake+98/c8>   <=====
Trace; 881080e0 <prom_getsysid+1638/2414>
Trace; 881081c4 <prom_getsysid+171c/2414>
Trace; 8800eb5c <__down_read+84/194>
Trace; 8806854c <proc_pid_make_inode+24/110>
Trace; 88067590 <proc_root_link+c0/e0>
Trace; 880672ac <proc_exe_link+78/1bc>
Trace; 880679c4 <proc_check_root+134/194>
Trace; 88067e28 <proc_pid_follow_link+88/b0>
Trace; 88067dc4 <proc_pid_follow_link+24/b0>
Trace; 88060364 <update_atime+64/70>
Trace; 88053da4 <path_walk+88c/9e8>
Trace; 88054488 <__user_walk+5c/90>
Trace; 88053070 <path_release+18/6c>
Trace; 8804fdf8 <sys_newstat+20/90>
Trace; 8804fe50 <sys_newstat+78/90>
Trace; 8800fca8 <stack_done+1c/38>
Trace; 8800fca8 <stack_done+1c/38>
Code;  8800eec4 <__rwsem_wake+8c/c8>
0000000000000000 <_PC>:
Code;  8800eec4 <__rwsem_wake+8c/c8>
   0:   24a581c4  addiu   $a1,$a1,-32316
Code;  8800eec8 <__rwsem_wake+90/c8>
   4:   0e007c56  jal     801f158 <_PC+0x801f158> 9002e01c <END_OF_CODE+7eb359c/????>
Code;  8800eecc <__rwsem_wake+94/c8>
   8:   240600eb  li      $a2,235
Code;  8800eed0 <__rwsem_wake+98/c8>   <=====
   c:   ae200000  sw      $zero,0($s1)   <=====
Code;  8800eed4 <__rwsem_wake+9c/c8>
  10:   26040014  addiu   $a0,$s0,20
Code;  8800eed8 <__rwsem_wake+a0/c8>
  14:   24050003  li      $a1,3
Code;  8800eedc <__rwsem_wake+a4/c8>
  18:   0e006f4a  jal     801bd28 <_PC+0x801bd28> 9002abec <END_OF_CODE+7eb016c/????>
Code;  8800eee0 <__rwsem_wake+a8/c8>
  1c:   24060001  li      $a2,1
Code;  8800eee4 <__rwsem_wake+ac/c8>
  20:   8fbf0018  lw      $ra,24($sp)


2 warnings issued.  Results may not be reliable.

[-- Attachment #3: boot.txt --]
[-- Type: text/plain, Size: 5996 bytes --]

>> printenv
SystemPartition=scsi(0)disk(1)rdisk(0)partition(8)
OSLoadPartition=/dev/sda1                         
OSLoader=vmlinux         
OSLoadFilename=/vmlinux
AutoLoad=Yes           
TimeZone=PST8PDT
console=d       
diskless=0
dbaud=9600
volume=2  
sgilogo=y
autopower=y
eaddr=08:00:69:08:4f:b2
ConsoleOut=serial(0)   
ConsoleIn=serial(0) 
cpufreq=100        
>> boot    
ARCH: SGI-IP22
PROMLIB: ARC firmware Version 1 Revision 10
CPU: MIPS-R4600 FPU<MIPS-R4600FPC> ICACHE DCACHE 
Loading R4000 MMU routines.
CPU revision is: 00002020
Primary instruction cache 16kb, linesize 32 bytes.
Primary data cache 16kb, linesize 32 bytes.
Linux version 2.4.3-cvs20010611 (raoul@bunny) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #12 Mon Jun 11 16:22:41 CEST 2001
MC: SGI memory controller Revision 3
Determined physical RAM map:
 memory: 00001000 @ 00000000 (reserved)
 memory: 00001000 @ 00001000 (reserved)
 memory: 00179000 @ 08002000 (reserved)
 memory: 005c5000 @ 0817b000 (usable)
 memory: 000c0000 @ 08740000 (ROM data)
 memory: 07800000 @ 08800000 (usable)
On node 0 totalpages: 65536
zone(0): 65536 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/sda1
Calibrating system timer... 500000 [100.00 MHz CPU]
Console: colour dummy device 80x25
zs0: console input
Console: ttyS0 (Zilog8530)
Calibrating delay loop... 99.73 BogoMIPS
Memory: 124408k/128788k available (1231k kernel code, 4380k reserved, 77k data, 52k init)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
VFS: Diskquotas version dquot_6.4.0 initialized
Checking for 'wait' instruction...  available.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4

Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd v1.8
initialize_kbd: Keyboard reset failed, no ACK
pty: 256 Unix98 ptys configured
keyboard: Timeout - AT keyboard not present?
keyboard: Timeout - AT keyboard not present?
DS1286 Real Time Clock Driver v1.0
streamable misc devices registered (keyb:150, gfx:148)
block: queued sectors max/low 82378kB/27459kB, 256 slots per queue
sgiseeq.c: David S. Miller (dm@engr.sgi.com)
eth0: SGI Seeq8003 08:00:69:08:4f:b2 
SCSI subsystem driver Revision: 1.00
wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00
           setup_args=,,,,,,,,,
           Version 1.25 - 09/Jul/1997, Compiled Jun 11 2001 at 16:24:01
scsi0 : SGI WD93
 sending SDTR 0103013f0csync_xfer=2c  Vendor: CONNER    Model: CFP2105S  2.14GB  Rev: 2B4B
  Type:   Direct-Access                      ANSI SCSI revision: 02
 sending SDTR 0103013f0csync_xfer=2c  Vendor: SGI       Model: IBMDSAS-3540      Rev: S47K
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 1, lun 0
Detected scsi disk sdb at scsi0, channel 0, id 2, lun 0
SCSI device sda: 4194304 512-byte hdwr sectors (2147 MB)
Partition check:
 sda: sda1 sda2 sda3 sda4
SCSI device sdb: 1070496 512-byte hdwr sectors (548 MB)
 sdb: sdb1 sdb2 sdb3
SGI Zilog8530 serial driver version 1.00
tty00 at 0xbfbd9830 (irq = 21) is a Zilog8530
tty01 at 0xbfbd9838 (irq = 21) is a Zilog8530
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing prom memory: 768kb freed
Freeing unused kernel memory: 52k freed
INIT: version 2.78 booting
Activating swap...
Adding Swap: 138992k swap-space (priority -1)
Checking root file system...
Parallelizing fsck version 1.20 (25-May-2001)
/dev/sda1: clean, 28429/243840 files, 138949/487542 blocks
Checking all file systems...
Parallelizing fsck version 1.20 (25-May-2001)
Setting kernel variables.
Mounting local filesystems...
tmpfs on /dev/shm type shm (rw)
Cleaning: /etc/network/ifstate.
Setting up IP spoofing protection: rp_filter.
Configuring network interfaces: done.

Setting the System Clock using the Hardware Clock as reference...
System Clock set. Local time: Mon Jun 11 16:31:33 CEST 2001

Cleaning: /tmp /var/lock /var/run.
Initializing random number generator... done.
INIT: Entering runlevel: 2
Starting system log daemon: syslogd.
Starting kernel log daemon: klogd.
Starting internet superserver: inetd.
Starting OpenBSD Secure Shell server: sshd.
Starting NTP server: ntpd.
Starting periodic command scheduler: cronkernel BUG at semaphore.c:235!
Unable to handle kernel paging request at virtual address 00000000, epc == 8800eed0, ra == 8800eed0
Oops in fault.c:do_page_fault, line 172:
$0 : 00000000 1000fc00 0000001f 00000001
$4 : 00000017 0000001f 8f626000 886603a0
$8 : 000d1b70 0000003c 00079c00 00000000
$12: 88157570 fffffff9 ffffffff 8f627ce2
$16: 8866059c 00000000 8f627f00 886605a4
$20: 8f627f04 8f627f00 8f627f04 00000009
$24: 00000002 0000000a
$28: 8f626000 8f627dd0 7fff7bb0 8800eed0
epc   : 8800eed0
Status: 1000fc03
Cause : 0000000c
Process start-stop-daem (pid: 129, stackpage=8f626000)
Stack: 881080e0 881081c4 000000eb 00000002 8866059c 8f626000 8800eb5c 8806854c
       00000000 8ff862e0 88067590 00000000 00000000 8f626000 886605a8 886605a8
       fffffffe 88660580 8f627f00 8866059c 880672ac 880679c4 8f8deca0 8f9ad8a0
       8f627f00 8f9ada20 00000000 8f9ada20 8f627f00 8814200d 8f627e98 8f627f00
       88067e28 88067dc4 8f9ada20 88060364 8f627e98 8f627f00 8f8deca0 8f8deca0
       8f9ada20 ...
Call Trace: [<881080e0>] [<881081c4>] [<8800eb5c>] [<8806854c>] [<88067590>] [<880672ac>] [<880679c4>] [<88067e28>] [<88067dc4>] [<88060364>] [<88053da4>] [<88054488>] [<88053070>] [<8804fdf8>] [<8804fe50>] [<8800fca8>] [<8800fca8>]
Code: 24a581c4  0e007c56  240600eb <ae200000> 26040014  24050003  0e006f4a  24060001  8fbf0018 

Re: Kernel crash on boot with current cvs (todays)

[Florian Lohoff]

On Mon, Jun 11, 2001 at 04:50:19PM +0200, Raoul Borenius wrote:
> Linux version 2.4.3-cvs20010611 (raoul@bunny) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #12 Mon Jun 11 16:22:41 CEST 2001
> MC: SGI memory controller Revision 3

I got a hint that it might be the compile to produce this bug - I was
suggested to use some gcc 3.0 prerelease. I now checked again and i am
already using some gcc 3.0

Linux version 2.4.3 (flo@paradigm) (gcc version 3.0 20010303 (prerelease))
#1 Mon Jun 11 00:27:09 CEST 2001

(flo@paradigm)~# mips-linux-gcc -v
Reading specs from /usr/local/lib/gcc-lib/mips-linux/3.0/specs
Configured with: ./configure --prefix=/usr/local --target=mips-linux --enable-languages=c --with-newlib --disable-shared
gcc version 3.0 20010303 (prerelease)
(flo@paradigm)~# mips-linux-as -v
GNU assembler version 2.11.90 (mips-linux) using BFD version 2.11.90

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Kernel crash on boot with current cvs (todays)

[Ralf Baechle]

On Tue, Jun 12, 2001 at 12:09:27PM +0200, Florian Lohoff wrote:

> I got a hint that it might be the compile to produce this bug - I was
> suggested to use some gcc 3.0 prerelease. I now checked again and i am
> already using some gcc 3.0

It's not a tool related bug but a genuine kernel bug in our semaphore code.
Which - unfortunately is a bit of headache to fix but is more or less the #1
on the list of my instabilities right now.

  Ralf

Re: Kernel crash on boot with current cvs (todays)

[H . J . Lu]

On Tue, Jun 12, 2001 at 01:53:06PM +0200, Ralf Baechle wrote:
> On Tue, Jun 12, 2001 at 12:09:27PM +0200, Florian Lohoff wrote:
> 
> > I got a hint that it might be the compile to produce this bug - I was
> > suggested to use some gcc 3.0 prerelease. I now checked again and i am
> > already using some gcc 3.0
> 
> It's not a tool related bug but a genuine kernel bug in our semaphore code.
> Which - unfortunately is a bit of headache to fix but is more or less the #1
> on the list of my instabilities right now.

I have some kernel crashes which are cured by some gcc/binutils changes
which I don't believe should make any differences. I thought I could
take out the mips64 and -march patches. But wtithout them, the user
applications seem ok, but the kernel crashes in all different places.
I have to put them back in. They may be kernel bugs and my gcc/binutils
changes may just hide them.

BTW, what is the current 2.4 kernel patches for Algorithmics P6032?

Thanks.


H.J.

Re: Kernel crash on boot with current cvs (todays)

[Florian Lohoff]

On Wed, Jun 13, 2001 at 10:06:02AM +0200, Raoul Borenius wrote:
> Hi,
> 
> On Tue, Jun 12, 2001 at 01:53:06PM +0200, Ralf Baechle wrote:
> > On Tue, Jun 12, 2001 at 12:09:27PM +0200, Florian Lohoff wrote:
> > 
> > > I got a hint that it might be the compile to produce this bug - I was
> > > suggested to use some gcc 3.0 prerelease. I now checked again and i am
> > > already using some gcc 3.0
> > 
> > It's not a tool related bug but a genuine kernel bug in our semaphore code.
> > Which - unfortunately is a bit of headache to fix but is more or less the #1
> > on the list of my instabilities right now.
> 
> Thanx for the quick response. Just to confirm that, here is the same crash
> with the kernel from
> 
> ftp://ftp.rfc822.org/pub/local/debian-mips/kernel/kernel-image-2.4.3-ip22-r4k.tgz
> 
> Using ksymoops gave a lot of warnings this time. Don't know why, the
> System.map should be the right one (it's out of
> kernel-image-2.4.3-ip22-r4k.tgz).

This is because the system map has been generated with newer binutils
which always dump the addresses as 64Bit addresses. Load the system
map into an text editor and delete the first ffffffff from the
addresses 1,$ s/^ffffffff//

> Warning (compare_maps): mismatch on symbol EISA_bus  , ksyms_base says 88162b44, System.map says ffffffff88162b44.  Ignoring ksyms_base entry
> Warning (compare_maps): mismatch on symbol ROOT_DEV  , ksyms_base says 881711e8, System.map says ffffffff881711e8.  Ignoring ksyms_base entry
> Warning (compare_maps): mismatch on symbol ___strtok  , ksyms_base says 88194d68, System.map says ffffffff88194d68.  Ignoring ksyms_base entry
> Warning (compare_maps): mismatch on symbol ___wait_on_page  , ksyms_base says 88032a20, System.map says ffffffff88032a20.  Ignoring ksyms_base entry
> Warning (compare_maps): mismatch on symbol __alloc_pages  , ksyms_base says 8803de98, System.map says ffffffff8803de98.  Ignoring ksyms_base entry
> Warning (compare_maps): mismatch on symbol __bforget  , ksyms_base says 880472b8, System.map says ffffffff880472b8.  Ignoring ksyms_base entry

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Kernel crash on boot with current cvs (todays)

[Keith Owens]

On Wed, 13 Jun 2001 12:56:10 +0200, 
Florian Lohoff <flo@rfc822.org> wrote:
>> Using ksymoops gave a lot of warnings this time. Don't know why, the
>> System.map should be the right one (it's out of
>> kernel-image-2.4.3-ip22-r4k.tgz).
>
>This is because the system map has been generated with newer binutils
>which always dump the addresses as 64Bit addresses.

Looks like I need to add a new option to ksymoops.  -T <bits>, truncate
all addresses to this bit size.  Added to my list for the next ksymoops
release.

Re: Kernel crash on boot with current cvs (todays)

[Ralf Baechle]

On Wed, Jun 13, 2001 at 09:34:18PM +1000, Keith Owens wrote:

> On Wed, 13 Jun 2001 12:56:10 +0200, 
> Florian Lohoff <flo@rfc822.org> wrote:
> >> Using ksymoops gave a lot of warnings this time. Don't know why, the
> >> System.map should be the right one (it's out of
> >> kernel-image-2.4.3-ip22-r4k.tgz).
> >
> >This is because the system map has been generated with newer binutils
> >which always dump the addresses as 64Bit addresses.
> 
> Looks like I need to add a new option to ksymoops.  -T <bits>, truncate
> all addresses to this bit size.  Added to my list for the next ksymoops
> release.

That can be done automatically.  For 32-bit ELF files mips*-linux binutils
dump some of the addresses as 32-bit addresses, some as sign-extended (!)
64-bit addresses.  So ksymops should just sign extend any 32-bit addresses
to 64-bit and then work on full lenght addresses.

Is ksymoops able to handle 64-bit addresses when running on a 32-bit host?
That is a common case for many people when decoding their MIPS oopses.

  Ralf

ksymoops changes for mips (was Kernel crash on boot with current cvs)

[Keith Owens]

On Wed, 13 Jun 2001 14:05:51 +0200, 
Ralf Baechle <ralf@oss.sgi.com> wrote:
>On Wed, Jun 13, 2001 at 09:34:18PM +1000, Keith Owens wrote:
>> Looks like I need to add a new option to ksymoops.  -T <bits>, truncate
>> all addresses to this bit size.  Added to my list for the next ksymoops
>> release.
>
>That can be done automatically.  For 32-bit ELF files mips*-linux binutils
>dump some of the addresses as 32-bit addresses, some as sign-extended (!)
>64-bit addresses.  So ksymops should just sign extend any 32-bit addresses
>to 64-bit and then work on full lenght addresses.

Some utilities extend with leading 0, some with leading 1, some with
special values (alpha).  It is safer to truncate everything to the
specified width instead of guessing what the extension value is.

>Is ksymoops able to handle 64-bit addresses when running on a 32-bit host?
>That is a common case for many people when decoding their MIPS oopses.

Yes and no.  The framework is there to handle 32/64 splits, sparc
already uses it.  mips does not currently use the framework because the
oops report does not identify the machine type 32/64, MSB/LSB.  We
discussed this in January and I asked for a small change to mips64 oops
output (below), was that ever done?

------

From: Keith Owens <kaos@ocs.com.au>
To: Ralf Baechle <ralf@uni-koblenz.de>
Subject: Re: ksymoops on origin 
Date: Sat, 06 Jan 2001 18:21:35 +1100

ksymoops is designed to run on any build arch and debug an oops report
from any other target arch, as long as binutils supports the target
arch.  The presence or absence of __MIPSEL__ or __MIPSEB__ on the build
system says nothing about the type of the failing target, ksymoops
relies on text in the oops report to determine special cases like 32
bit userland and 64 bit kernel.

The best option is for a mips64 kernel to indicate that it is 64 bit
and its endianess.  Instead of printing

  "epc     : %016lx\n"

print

  "epc     : %016lx (64 "
#ifdef __MIPSEL__
		"LSB"
#else
		"MSB"
#endif
		")\n"

If you make that change to arch/mips64/mm/andes.c,
arch/mips64/mm/r4xx0.c and any other places that print epc on mips64
then I will change ksymoops to look for (64 [LM]SB) on the epc line and
decode accordingly.

While we are on the topic of 32 bit userland and 64 bit kernel, how
does mips64 handle modules?  modutils 2.4.0 has no support for mips64,
do you have any code?  Also I assume that you will want the same
ability as sparc, to compile modutils as a 32 bit program which can
handle both 32 and 64 bit modules.

Re: ksymoops changes for mips (was Kernel crash on boot with current cvs)

[Ralf Baechle]

On Wed, Jun 13, 2001 at 10:19:14PM +1000, Keith Owens wrote:

> >That can be done automatically.  For 32-bit ELF files mips*-linux binutils
> >dump some of the addresses as 32-bit addresses, some as sign-extended (!)
> >64-bit addresses.  So ksymops should just sign extend any 32-bit addresses
> >to 64-bit and then work on full lenght addresses.
> 
> Some utilities extend with leading 0, some with leading 1, some with
> special values (alpha).  It is safer to truncate everything to the
> specified width instead of guessing what the extension value is.

That's a processor specific thing.  In case of MIPS only signed extension
is correct.  Some older binutils did unsigned extension and that's plain
wrong.

> >Is ksymoops able to handle 64-bit addresses when running on a 32-bit host?
> >That is a common case for many people when decoding their MIPS oopses.
> 
> Yes and no.  The framework is there to handle 32/64 splits, sparc
> already uses it.  mips does not currently use the framework because the
> oops report does not identify the machine type 32/64, MSB/LSB.  We
> discussed this in January and I asked for a small change to mips64 oops
> output (below), was that ever done?

Nothing - ``Guilty as charged.  Filed in my "to do when I have time" folder,
which overflowed about 3 years ago :(.''

  Ralf

Re: ksymoops changes for mips

[Keith Owens]

On Wed, 13 Jun 2001 22:19:14 +1000, 
Keith Owens <kaos@melbourne.sgi.com> wrote:
>ksymoops is designed to run on any build arch and debug an oops report
>from any other target arch, as long as binutils supports the target
>arch.  The presence or absence of __MIPSEL__ or __MIPSEB__ on the build
>system says nothing about the type of the failing target, ksymoops
>relies on text in the oops report to determine special cases like 32
>bit userland and 64 bit kernel.
>
>The best option is for a mips64 kernel to indicate that it is 64 bit
>and its endianess.  Instead of printing
>
>  "epc     : %016lx\n"
>
>print
>
>  "epc     : %016lx (64 "
>#ifdef __MIPSEL__
>		"LSB"
>#else
>		"MSB"
>#endif
>		")\n"

I have a new ksymoops release coming up.  Is it OK if I include code to
look for (64 LSB) and (64 MSB) in the oops and decode accordingly.  I
don't expect the kernel to produce this output immediately, I just want
agreement on the format that will be produced.

Re: ksymoops changes for mips

[Thiemo Seufer]

Keith Owens wrote:
[snip]
> >The best option is for a mips64 kernel to indicate that it is 64 bit
> >and its endianess.  Instead of printing
> >
> >  "epc     : %016lx\n"
> >
> >print
> >
> >  "epc     : %016lx (64 "
> >#ifdef __MIPSEL__
> >		"LSB"
> >#else
> >		"MSB"
> >#endif
> >		")\n"
> 
> I have a new ksymoops release coming up.  Is it OK if I include code to
> look for (64 LSB) and (64 MSB) in the oops and decode accordingly.  I
> don't expect the kernel to produce this output immediately, I just want
> agreement on the format that will be produced.

The appended patch introduces the new format in mips64. Maybe this speeds
up agreement about it. :-)


Thiemo


diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/mm/andes.c linux/arch/mips64/mm/andes.c
--- linux-orig/arch/mips64/mm/andes.c	Sat May 26 00:25:39 2001
+++ linux/arch/mips64/mm/andes.c	Thu Jun 28 15:19:32 2001
@@ -332,7 +381,13 @@
 	printk("Lo      : %016lx\n", regs->lo);
 
 	/* Saved cp0 registers. */
-	printk("epc     : %016lx\nbadvaddr: %016lx\n",
+	printk("epc     : %016lx (64 "
+#ifdef __MIPSEL__
+	       "LSB"
+#else
+	       "MSB"
+#endif
+	       ")\nbadvaddr: %016lx\n",
 	       regs->cp0_epc, regs->cp0_badvaddr);
 	printk("Status  : %08x\nCause   : %08x\n",
 	       (unsigned int) regs->cp0_status, (unsigned int) regs->cp0_cause);
diff -BurPX /bigdisk/dl/src/dontdiff linux-orig/arch/mips64/mm/r4xx0.c linux/arch/mips64/mm/r4xx0.c
--- linux-orig/arch/mips64/mm/r4xx0.c	Thu Mar 29 17:11:46 2001
+++ linux/arch/mips64/mm/r4xx0.c	Thu Jun 28 14:51:20 2001
@@ -2125,7 +2118,13 @@
 	printk("Lo      : %016lx\n", regs->lo);
 
 	/* Saved cp0 registers. */
-	printk("epc     : %016lx\nbadvaddr: %016lx\n",
+	printk("epc     : %016lx (64 "
+#ifdef __MIPSEL__
+	       "LSB"
+#else
+	       "MSB"
+#endif
+	       ")\nbadvaddr: %016lx\n",
 	       regs->cp0_epc, regs->cp0_badvaddr);
 	printk("Status  : %08x\nCause   : %08x\n",
 	       (unsigned int) regs->cp0_status, (unsigned int) regs->cp0_cause);

Re: ksymoops changes for mips

[Keith Owens]

On Thu, 28 Jun 2001 16:32:51 +0200, 
Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> wrote:
>Keith Owens wrote:
>[snip]
>> >The best option is for a mips64 kernel to indicate that it is 64 bit
>> >and its endianess.  Instead of printing
>
>The appended patch introduces the new format in mips64. Maybe this speeds
>up agreement about it. :-)

I am updating ksymoops now and need some information.  Could somebody
tell me what this produces on mips?

# objdump -h ksymoops | head -8
# objdump -h mips64-lsb-vmlinux | head -8
# objdump -h mips64-msb-vmlinux | head -8

where mips64-[lm]sb-vmlinux are kernels compiled for 64 bit with LSB
and MSB.

Re: ksymoops changes for mips

[Keith Owens]

On Tue, 31 Jul 2001 13:57:45 +1000, 
Keith Owens <kaos@ocs.com.au> wrote:
>I am updating ksymoops now and need some information.  Could somebody
>tell me what this produces on mips?
>
># objdump -h ksymoops | head -8
># objdump -h mips64-lsb-vmlinux | head -8
># objdump -h mips64-msb-vmlinux | head -8
>
>where mips64-[lm]sb-vmlinux are kernels compiled for 64 bit with LSB
>and MSB.

Sorry, that should have been objdump -x, not objdump -h, I need the
architecture type as well as the file format.

Re: ksymoops changes for mips

[Keith Owens]

Resend, no response.

On Thu, 28 Jun 2001 16:32:51 +0200, 
Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> wrote:
>Keith Owens wrote:
>[snip]
>> >The best option is for a mips64 kernel to indicate that it is 64 bit
>> >and its endianess.  Instead of printing
>
>The appended patch introduces the new format in mips64. Maybe this speeds
>up agreement about it. :-)

I am updating ksymoops now and need some information.  Could somebody
tell me what this produces on mips?

# objdump -x ksymoops | head -8
# objdump -x mips64-lsb-vmlinux | head -8
# objdump -x mips64-msb-vmlinux | head -8

where mips64-[lm]sb-vmlinux are kernels compiled for 64 bit with LSB
and MSB.

Re: ksymoops changes for mips

[Thiemo Seufer]

Keith Owens wrote:
> Resend, no response.

I tried to send you something via PM, but your email address
gave errors.

   ----- Transcript of session follows -----
   451 <kaos@ocs.com.au>... reply: read error from mail.ocs.com.au.
   <kaos@ocs.com.au>... Deferred: Connection reset by mail.ocs.com.au.
   Warning: message still undelivered after 4 hours
   Will keep trying until message is 5 days old

[snip]
   > >I am updating ksymoops now and need some information.  Could somebody
   > >tell me what this produces on mips?
   > >
   > ># objdump -h ksymoops | head -8
   > ># objdump -h mips64-lsb-vmlinux | head -8
   > ># objdump -h mips64-msb-vmlinux | head -8
   > >
   > >where mips64-[lm]sb-vmlinux are kernels compiled for 64 bit with LSB
   > >and MSB.
   >
   > Sorry, that should have been objdump -x, not objdump -h, I need the
   > architecture type as well as the file format.
   
   What I have is not the "official" CVS kernel but a patched version,
   along with a patched toolchain. It already uses elf64-tradbigmips
   instead of elf64-bigmips and has a different start address as it
   is loaded in 64bit address space. I haven't cared about little
   endian yet (no such hardware).
   
   So it's just for reference for now, possibly it helps.
   
   
   Thiemo
   
   
   -----------------------------------------------------------------------
   
   mips64-msb-vmlinux:     file format elf64-tradbigmips
   mips64-msb-vmlinux
   architecture: mips:8000, flags 0x00000112:
   EXEC_P, HAS_SYMS, D_PAGED
   start address 0xa8000000201b4000
   
   Program Header:

Re: Kernel crash on boot with current cvs (todays)

[Maciej W. Rozycki]

On Wed, 13 Jun 2001, Ralf Baechle wrote:

> That can be done automatically.  For 32-bit ELF files mips*-linux binutils
> dump some of the addresses as 32-bit addresses, some as sign-extended (!)
> 64-bit addresses.  So ksymops should just sign extend any 32-bit addresses
> to 64-bit and then work on full lenght addresses.
> 
> Is ksymoops able to handle 64-bit addresses when running on a 32-bit host?
> That is a common case for many people when decoding their MIPS oopses.

 The point is whether addresses should be extended at all if a 32-bit
target is selected.  IMHO -- not, that's a limitation of BFD when
configured for both a 32-bit and a 64-bit target and it should be fixed
sooner or later (at least it's on my to-do list for some time).  BFD is
free to handle addresses as it likes internally, be it 64-bit or 32-bit,
but they should be truncated on final output to a 32-bit target, as they
already are for certain cases. 

 I'm not sure we need to work it around in ksymoops until BFD is fixed --
`cut -c8- < System.map' works as a charm.  It might be worth documenting,
though. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Kernel crash on boot with current cvs (todays)

[Keith Owens]

On Wed, 13 Jun 2001 15:44:28 +0200 (MET DST), 
"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:
> The point is whether addresses should be extended at all if a 32-bit
>target is selected.  IMHO -- not ...
> I'm not sure we need to work it around in ksymoops until BFD is fixed --
>`cut -c8- < System.map' works as a charm.

ksymoops also reads the output from nm and objdump internally, it is
just a little difficult to run cut -c8- on that data ;).

Re: Kernel crash on boot with current cvs (todays)

[Maciej W. Rozycki]

On Thu, 14 Jun 2001, Keith Owens wrote:

> ksymoops also reads the output from nm and objdump internally, it is
> just a little difficult to run cut -c8- on that data ;).

 I see.  So a workaround is likely needed for now.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Kernel crash on boot with current cvs (todays)

[Ralf Baechle]

On Wed, Jun 13, 2001 at 03:44:28PM +0200, Maciej W. Rozycki wrote:

>  The point is whether addresses should be extended at all if a 32-bit
> target is selected.  IMHO -- not, that's a limitation of BFD when
> configured for both a 32-bit and a 64-bit target and it should be fixed
> sooner or later (at least it's on my to-do list for some time).  BFD is
> free to handle addresses as it likes internally, be it 64-bit or 32-bit,
> but they should be truncated on final output to a 32-bit target, as they
> already are for certain cases. 

Agreed, that'd be much more readable for humans.  For processing by
software having some canonical form, that is 64-bit would be a bit more
handy though.

  Ralf

Re: Kernel crash on boot with current cvs (todays)

[Raoul Borenius]

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

On Wed, Jun 13, 2001 at 12:56:10PM +0200, Florian Lohoff wrote:
> > 
> > Using ksymoops gave a lot of warnings this time. Don't know why, the
> > System.map should be the right one (it's out of
> > kernel-image-2.4.3-ip22-r4k.tgz).
> 
> This is because the system map has been generated with newer binutils
> which always dump the addresses as 64Bit addresses. Load the system
> map into an text editor and delete the first ffffffff from the
> addresses 1,$ s/^ffffffff//

Should have looked closer, sorry...

I've attached the output of ksymoops.

Regrds

Raoul

 ---------------------------------------------------------------------
 Raoul Gunnar Borenius		Deutsches Forschungsnetz e.V.
 WiNShuttle			Lindenspürstr.32, 70176 Stuttgart
 Phone  : +49 711 63314-206	FAX: +49 711 63314-133
 E-Mail : borenius@shuttle.de	http://www.shuttle.de
 ---------------------------------------------------------------------



[-- Attachment #2: trace.txt --]
[-- Type: text/plain, Size: 3321 bytes --]

ksymoops 2.4.1 on mips 2.4.3.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.3/ (default)
     -m /boot/System.map-2.4.3 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file?
Starting periodic command scheduler: cronkernel BUG at semaphore.c:235!
Unable to handle kernel paging request at virtual address 00000000, epc == 8800e                               e5c, ra == 8800ee5c
$0 : 00000000 1000fc00 0000001f 8f63a000
$4 : 00000017 00000000 00000001 8877a3a0
$8 : 0000000a 88171cc0 00000000 00000000
$12: 00000000 881718e0 fffffff9 0000000a
$16: 8877a59c 00000000 8f63a000 8877a5a4
$20: 8f63bf04 8f63bf00 8f63bea0 00000009
$24: 8f63bcf2 ffffffff
$28: 8f63a000 8f63bdd8 7fff7bb0 8800ee5c
epc   : 8800ee5c
Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
Status: 1000fc03
Cause : 0000000c
Process start-stop-daem (pid: 129, stackpage=8f63a000)
Stack: 88124dc0 88124dd8 000000eb 00000000 8877a59c 8877a580 8800eb84 10011f10
       00000000 8ffa02c0 88063810 880647f4 00000000 8f63a000 8877a5a4 8877a5a4
       fffffffe 8877a580 8fac4840 8877a59c 8f63bf04 88063670 8fac4660 8f8cec20
       8f63bf00 8f63bf00 8fac4840 8f63bf00 8fac4840 8814b00d 8f63bf00 8f63bf04
       880640f0 880640b8 8fac4840 8805f7f4 8fac4660 8814b00d 8f8ceca0 8f8ceca0
       88052a88 ...
Call Trace: [<88124dc0>] [<88124dd8>] [<8800eb84>] [<88063810>] [<880647f4>] [<8                               8063670>] [<880640f0>] [<880640b8>] [<8805f7f4>] [<88052a88>] [<88052b74>] [<880
537c0>] [<88053768>] [<88052294>] [<8804ef14>] [<8800fc28>] [<8800c638>] [<c013d                               686>]
Code: 240600eb  0e007859  00000000 <ae200000> 26040010  24050003  0e006b45  2406

>>RA;  8800ee5c <__rwsem_wake+b8/dc>
>>PC;  8800ee5c <__rwsem_wake+b8/dc>   <=====
Trace; 88124dc0 <prom_getsysid+cc8/106c>
Trace; 88124dd8 <prom_getsysid+ce0/106c>
Trace; 8800eb84 <__down_read+1dc/1e4>
Trace; 88063810 <proc_root_link+b4/e4>
Trace; 880647f4 <proc_pid_make_inode+24/10c>
Code;  8800ee50 <__rwsem_wake+ac/dc>
0000000000000000 <_PC>:
Code;  8800ee50 <__rwsem_wake+ac/dc>
   0:   240600eb  li      $a2,235
Code;  8800ee54 <__rwsem_wake+b0/dc>
   4:   0e007859  jal     801e164 <_PC+0x801e164> 9002cfb4 <END_OF_CODE+7e98120/????>
Code;  8800ee58 <__rwsem_wake+b4/dc>
   8:   00000000  nop
Code;  8800ee5c <__rwsem_wake+b8/dc>   <=====
   c:   ae200000  sw      $zero,0($s1)   <=====
Code;  8800ee60 <__rwsem_wake+bc/dc>
  10:   26040010  addiu   $a0,$s0,16
Code;  8800ee64 <__rwsem_wake+c0/dc>
  14:   24050003  li      $a1,3
Code;  8800ee68 <__rwsem_wake+c4/dc>
  18:   0e006b45  jal     801ad14 <_PC+0x801ad14> 90029b64 <END_OF_CODE+7e94cd0/????>
Code;  8800ee6c <__rwsem_wake+c8/dc>
  1c:   24060000  li      $a2,0

0001  0a003b85

2 warnings issued.  Results may not be reliable.

Re: Kernel crash on boot with current cvs (todays)

[Keith Owens]

On Wed, 13 Jun 2001 13:37:51 +0200, 
borenius@shuttle.de (Raoul Borenius) wrote:
>Unable to handle kernel paging request at virtual address 00000000, epc == 8800e                               e5c, ra == 8800ee5c
>Call Trace: [<88124dc0>] [<88124dd8>] [<8800eb84>] [<88063810>] [<880647f4>] [<8                               8063670>] [<880640f0>] [<880640b8>] [<8805f7f4>] [<88052a88>] [<88052b74>] [<880
>537c0>] [<88053768>] [<88052294>] [<8804ef14>] [<8800fc28>] [<8800c638>] [<c013d                               686>]

The epc line and the call trace have embedded spaces and newlines which
are preventing ksymoops from doing a full conversion.  Try again with
the extra characters removed, i.e.

Unable to handle kernel paging request at virtual address 00000000, epc == 8800e5c, ra == 8800ee5c
....
Call Trace: [<88124dc0>] [<88124dd8>] [<8800eb84>] [<88063810>]
[<880647f4>] [<88063670>] [<880640f0>] [<880640b8>] [<8805f7f4>]
[<88052a88>] [<88052b74>] [<880537c0>] [<88053768>] [<88052294>]
[<8804ef14>] [<8800fc28>] [<8800c638>] [<c013d686>]
Code: ...

Re: Kernel crash on boot with current cvs (todays)

[Keith Owens]

On Wed, 13 Jun 2001 13:37:51 +0200, 
borenius@shuttle.de (Raoul Borenius) wrote:
>Unable to handle kernel paging request at virtual address 00000000, epc == 8800e                               e5c, ra == 8800ee5c
>Call Trace: [<88124dc0>] [<88124dd8>] [<8800eb84>] [<88063810>] [<880647f4>] [<8                               8063670>] [<880640f0>] [<880640b8>] [<8805f7f4>] [<88052a88>] [<88052b74>] [<880
>537c0>] [<88053768>] [<88052294>] [<8804ef14>] [<8800fc28>] [<8800c638>] [<c013d                               686>]

The epc line and the call trace have embedded spaces and newlines which
are preventing ksymoops from doing a full conversion.  Try again with
the extra characters removed, i.e.

Unable to handle kernel paging request at virtual address 00000000, epc == 8800e5c, ra == 8800ee5c
....
Call Trace: [<88124dc0>] [<88124dd8>] [<8800eb84>] [<88063810>]
[<880647f4>] [<88063670>] [<880640f0>] [<880640b8>] [<8805f7f4>]
[<88052a88>] [<88052b74>] [<880537c0>] [<88053768>] [<88052294>]
[<8804ef14>] [<8800fc28>] [<8800c638>] [<c013d686>]
Code: ...

Re: Kernel crash on boot with current cvs (todays)

[Raoul Borenius]

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

On Wed, Jun 13, 2001 at 09:46:20PM +1000, Keith Owens wrote:
> On Wed, 13 Jun 2001 13:37:51 +0200, 
> borenius@shuttle.de (Raoul Borenius) wrote:
> >Unable to handle kernel paging request at virtual address 00000000, epc == 8800e                               e5c, ra == 8800ee5c
> >Call Trace: [<88124dc0>] [<88124dd8>] [<8800eb84>] [<88063810>] [<880647f4>] [<8                               8063670>] [<880640f0>] [<880640b8>] [<8805f7f4>] [<88052a88>] [<88052b74>] [<880
> >537c0>] [<88053768>] [<88052294>] [<8804ef14>] [<8800fc28>] [<8800c638>] [<c013d                               686>]
> 
> The epc line and the call trace have embedded spaces and newlines which
> are preventing ksymoops from doing a full conversion.  Try again with
> the extra characters removed, i.e.

Sorry about that. These things happen every time I try to do five or more
things at the same time...

Hope the trace is ok now.

Regards

Raoul

 ---------------------------------------------------------------------
 Raoul Gunnar Borenius		Deutsches Forschungsnetz e.V.
 WiNShuttle			Lindenspürstr.32, 70176 Stuttgart
 Phone  : +49 711 63314-206	FAX: +49 711 63314-133
 E-Mail : borenius@shuttle.de	http://www.shuttle.de
 ---------------------------------------------------------------------

[-- Attachment #2: trace.txt --]
[-- Type: text/plain, Size: 3620 bytes --]

ksymoops 2.4.1 on mips 2.4.3.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.3/ (default)
     -m /boot/System.map-2.4.3 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file?
Starting periodic command scheduler: cronkernel BUG at semaphore.c:235!
Unable to handle kernel paging request at virtual address 00000000, epc == 8800e                               e5c, ra == 8800ee5c
$0 : 00000000 1000fc00 0000001f 8f63a000
$4 : 00000017 00000000 00000001 8877a3a0
$8 : 0000000a 88171cc0 00000000 00000000
$12: 00000000 881718e0 fffffff9 0000000a
$16: 8877a59c 00000000 8f63a000 8877a5a4
$20: 8f63bf04 8f63bf00 8f63bea0 00000009
$24: 8f63bcf2 ffffffff
$28: 8f63a000 8f63bdd8 7fff7bb0 8800ee5c
epc   : 8800ee5c
Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
Status: 1000fc03
Cause : 0000000c
Process start-stop-daem (pid: 129, stackpage=8f63a000)
Stack: 88124dc0 88124dd8 000000eb 00000000 8877a59c 8877a580 8800eb84 10011f10
       00000000 8ffa02c0 88063810 880647f4 00000000 8f63a000 8877a5a4 8877a5a4
       fffffffe 8877a580 8fac4840 8877a59c 8f63bf04 88063670 8fac4660 8f8cec20
       8f63bf00 8f63bf00 8fac4840 8f63bf00 8fac4840 8814b00d 8f63bf00 8f63bf04
       880640f0 880640b8 8fac4840 8805f7f4 8fac4660 8814b00d 8f8ceca0 8f8ceca0
       88052a88 ...
Call Trace: [<88124dc0>] [<88124dd8>] [<8800eb84>] [<88063810>] [<880647f4>] [<88063670>] [<880640f0>] [<880640b8>] [<8805f7f4>] [<88052a88>] [<88052b74>] [<880 537c0>] [<88053768>] [<88052294>] [<8804ef14>] [<8800fc28>] [<8800c638>] [<c013d686>]
Code: 240600eb  0e007859  00000000 <ae200000> 26040010  24050003  0e006b45  24060001  0a003b85

>>RA;  8800ee5c <__rwsem_wake+b8/dc>
>>PC;  8800ee5c <__rwsem_wake+b8/dc>   <=====
Trace; 88124dc0 <prom_getsysid+cc8/106c>
Trace; 88124dd8 <prom_getsysid+ce0/106c>
Trace; 8800eb84 <__down_read+1dc/1e4>
Trace; 88063810 <proc_root_link+b4/e4>
Trace; 880647f4 <proc_pid_make_inode+24/10c>
Trace; 88063670 <proc_exe_link+1cc/1d4>
Trace; 880640f0 <proc_pid_follow_link+98/b0>
Trace; 880640b8 <proc_pid_follow_link+60/b0>
Trace; 8805f7f4 <update_atime+6c/78>
Trace; 88052a88 <path_walk+334/a94>
Trace; 88052b74 <path_walk+420/a94>
Code;  8800ee50 <__rwsem_wake+ac/dc>
0000000000000000 <_PC>:
Code;  8800ee50 <__rwsem_wake+ac/dc>
   0:   240600eb  li      $a2,235
Code;  8800ee54 <__rwsem_wake+b0/dc>
   4:   0e007859  jal     801e164 <_PC+0x801e164> 9002cfb4 <END_OF_CODE+7e98120/????>
Code;  8800ee58 <__rwsem_wake+b4/dc>
   8:   00000000  nop
Code;  8800ee5c <__rwsem_wake+b8/dc>   <=====
   c:   ae200000  sw      $zero,0($s1)   <=====
Code;  8800ee60 <__rwsem_wake+bc/dc>
  10:   26040010  addiu   $a0,$s0,16
Code;  8800ee64 <__rwsem_wake+c0/dc>
  14:   24050003  li      $a1,3
Code;  8800ee68 <__rwsem_wake+c4/dc>
  18:   0e006b45  jal     801ad14 <_PC+0x801ad14> 90029b64 <END_OF_CODE+7e94cd0/????>
Code;  8800ee6c <__rwsem_wake+c8/dc>
  1c:   24060001  li      $a2,1
Code;  8800ee70 <__rwsem_wake+cc/dc>
  20:   0a003b85  j       800ee14 <_PC+0x800ee14> 9001dc64 <END_OF_CODE+7e88dd0/????>


2 warnings issued.  Results may not be reliable.