NetBSD Problem Report #9678

Received: (qmail 21634 invoked from network); 26 Mar 2000 21:12:09 -0000
Message-Id: <200003262106.XAA16668@q700.hf.org>
Date: Sun, 26 Mar 2000 23:06:55 +0200 (CEST)
From: hauke@Espresso.Rhein-Neckar.DE
Reply-To: hauke@Espresso.Rhein-Neckar.DE
To: gnats-bugs@gnats.netbsd.org
Subject: gdb fails to debug kernel core dump on mac68k
X-Send-Pr-Version: 3.95

>Number:         9678
>Category:       port-mac68k
>Synopsis:       gdb fails to debug kernel core dump on mac68k
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-mac68k-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 26 13:15:01 +0000 2000
>Closed-Date:    
>Last-Modified:  Mon Nov 21 04:08:43 +0000 2005
>Originator:     Hauke Fath
>Release:        1.4V
>Organization:
Einzeln auftretender Radfahrer
>Environment:

System: NetBSD 1.4V (CHUCK) #5: Thu Mar 23 00:27:26 CET 2000
    hauke@q700.hf.org:/usr/src/sys/arch/mac68k/compile/CHUCK
Apple Macintosh IIcx  (68030)

>Description:
trying to debug a NetBSD -current core, all I see in gdb is

chuck# gdb netbsd.gdb
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "m68k--netbsd"...
(gdb) target kcore /var/crash/netbsd.2.core
panic: Bus error
#0  0x0 in ?? ()
(gdb) bt
#0  0x0 in ?? ()
(gdb)

when, according to ddb, I should see something like

db> t
_cpu_Debugger(71ca2c,100,71ca68,12ee7e,12e97d) + 6
_panic(12e97d) + 56
_trap(0,75d,8c9003) + 2b6
_sbc_pdma_in(3e2800,1,ff,2000c1c) + 11c
_ncr5380_data_xfer(3e2800,1) + 20c
_ncr5380_machine(3e2800) + 182
_ncr5380_sched(3e2800) + 40e
_ncr5380_scsi_cmd(3ec000) + 1da
_scsipi_execute_xs(3ec000) + 90
_scsi_scsipi_cmd(3dd480,3f38b4,6,2000c18,ff,0,7d0,3f3808,818) + 14a
_scsistrategy(3f3808) + 188
_physio(11249c,3f3808,d0a,100000,1c04c,3f3884) + 2fa
_scsipi_do_ioctl(3dd480,d0a,c05e5101,71ceac,3,6f3640) + 1d2
_sdioctl(d0a,c05e5101,71ceac,3,6f3640) + 552
_spec_ioctl(71cdc0) + 8c
_VOP_IOCTL(7100d0,c05e5101,71ceac,3,3ddf00,6f3640) + 5a
_vn_ioctl(70c060,c05e5101,71ceac,6f3640) + d4
_sys_ioctl(6f3640,71cf6c,71cf64) + 338
_syscall(36) + 1b4
_trap0() + e
db>

This happens with the 1.4V system as well as with a 1.4Q system.
I've seen it work on i386, but I don't remember trying gdb on a 
core dump on mac68k.

>How-To-Repeat:
Have a -current NetBSD/mac68k installation dump core, build a kernel 
with "-g" and look at the core dump. Be very surprised about what you see.

>Fix:
None, sorry.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: jdolecek 
State-Changed-When: Sat Sep 29 13:23:39 PDT 2001 
State-Changed-Why:  
Does this problem still happen on 1.5.2 or -current? 

From: "Perry E. Metzger" <perry@piermont.com>
To: hauke@Espresso.Rhein-Neckar.DE
Cc: gnats-bugs@gnats.netbsd.org, perry@piermont.com
Subject: Re: port-mac68k/9678
Date: 04 Apr 2003 16:37:57 -0500

 >Synopsis:       gdb fails to debug kernel core dump on mac68k

 Is this still a problem in more recent versions of NetBSD?

 Perry

From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: hauke@Espresso.Rhein-Neckar.DE, gnats-bugs@gnats.netbsd.org,
  perry@piermont.com
Subject: Re: port-mac68k/9678
Date: Sat, 5 Apr 2003 21:01:08 +0200

 At 16:37 Uhr -0500 4.4.2003, Perry E. Metzger wrote:
 >>Synopsis:       gdb fails to debug kernel core dump on mac68k
 >
 >Is this still a problem in more recent versions of NetBSD?

 I suppose this is an a.out toolchain problem and so will not occur on 1.6
 and newer. Unfortunately, my last 1.5 machine ( a Mac IIci) has died from
 leaking capacitors, so I cannot ATM check if the issue is still present in
 1.5.4.

 	hauke

 --
 /~\  The ASCII Ribbon Campaign
 \ /    No HTML/RTF in email
  X     No Word docs in email
 / \  Respect for open standards


State-Changed-From-To: feedback->closed 
State-Changed-By: perry 
State-Changed-When: Sat Apr 5 11:40:22 PST 2003 
State-Changed-Why:  
Submitter indicates that the problem probably does not impact ELF 
toolchains. In any case, he does not currently have a machine with which 
to conduct tests. 

From: "Perry E. Metzger" <perry@piermont.com>
To: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
Cc: Scott Reynolds <scottr@netbsd.org>, gnats-bugs@gnats.netbsd.org
Subject: Re: port-mac68k/9678
Date: 07 Apr 2003 16:38:19 -0400

 Hauke Fath <hauke@Espresso.Rhein-Neckar.DE> writes:
 > So, yes, the 1.5 branch still has the problem.

 I'm more interested in whether 1.6 or -current have it -- 1.5 will go
 out of maintenance as soon as we release 2.0.

 Perry

From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>,
  Scott Reynolds <scottr@netbsd.org>, gnats-bugs@gnats.netbsd.org
Subject: Re: port-mac68k/9678
Date: Mon, 7 Apr 2003 23:16:02 +0200

 At 16:38 Uhr -0400 7.4.2003, Perry E. Metzger wrote:
 >Hauke Fath <hauke@Espresso.Rhein-Neckar.DE> writes:
 >> So, yes, the 1.5 branch still has the problem.
 >
 >I'm more interested in whether 1.6 or -current have it -- 1.5 will go
 >out of maintenance as soon as we release 2.0.

 I understand.

 I shall set up a mac68k 1.6 branch installation in the next days and have a
 try.

 	hauke

 --
 /~\  The ASCII Ribbon Campaign
 \ /    No HTML/RTF in email
  X     No Word docs in email
 / \  Respect for open standards



From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>,
  Scott Reynolds <scottr@netbsd.org>, gnats-bugs@gnats.netbsd.org
Subject: Re: port-mac68k/9678
Date: Wed, 9 Apr 2003 13:49:01 +0200

 At 16:38 Uhr -0400 7.4.2003, Perry E. Metzger wrote:
 >I'm more interested in whether 1.6 or -current have it -- 1.5 will go
 >out of maintenance as soon as we release 2.0.

 On the 2003-04-07 1.6.1 snapshot, I cannot get a coredump from within ddb:

 ----------------------------------------------------------------------------

 Bootstrapping NetBSD/mac68k.
 Getting mapping from MMU.
 Loaded at 0x0
 System RAM: 71303168 bytes in 17408 pages.
      Low = 0x0, high = 0x4400000
 On-board video at addr 0xf9000e00 (phys 0xf9000e00), len 0xff200.
 Done.
 Bootstrapping the pmap system.
 Pmap bootstrapped.
 Moving ROMBase from 0x40800000 to 0x90a000.
 Video address 0xf9000e00 -> 0xb0ae00.
 [ using 427260 bytes of netbsd ELF symbol table ]
 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002
     The NetBSD Foundation, Inc.  All rights reserved.
 Copyright (c) 1982, 1986, 1989, 1991, 1993
     The Regents of the University of California.  All rights reserved.

 NetBSD 1.6.1 (GENERICSBC) #0: Tue Apr  8 14:02:45 UTC 2003

 autobuild@tgm.daemon.org:/autobuild/netbsd-1-6/mac68k/OBJ/autobuild/netbsd-1
 -6/src/sys/arch/mac68k/compile/GENERICSBC
 Apple Macintosh Quadra 700  (68040)

 [...]

 Starting sshd.
 Starting inetd.
 Starting cron.
 Wed Apr  9 13:40:33 CEST 2003
 Apr  9 13:40:36 q700 getty[211]: /dev/ttyE0: Device not configured
 Stopped at      cpu_Debugger+0x6:       unlk    a6
 db> sync
 syncing disks... done

 dumping to dev 4,9 offset 186257
 dump Kernel Illegal Instruction trap.
 trap type 2, code = 0x0, v = 0x0
 kernel program counter = 0x1a0
 kernel: Illegal instruction trap
 pid = -1, pc = 000001A0, ps = 2700, sfc = 1, dfc = 1
 Registers:
              0        1        2        3        4        5        6        7
 dreg: 000000FF 00000001 00000008 0000000C 0002D791 001F1340 0000003C 00000000
 areg: 01024200 01002452 000A7860 0008BC6E 00000000 00000000 00000000 FFFFCFFC

 Kernel stack (001DCE2A):
 1DCE2A: 001A2518 001DCE7A 00000080 00000008 0000000C 0002D791 001F1340 0000003C
 1DCE4A: 00000000 000A7860 0008BC6E 00000000 00000000 00000000 00000000 00000000
 1DCE6A: 0000308C 00000002 00000000 00000000 000000FF 00000001 00000008 0000000C
 1DCE8A: 0002D791 001F1340 0000003C 00000000 01024200 01002452 000A7860 0008BC6E
 1DCEAA: 00000000 00000000 00000000 FFFFCFFC 00000000 27000000 01A00010 00000000
 1DCECA: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 1DCEEA: 00000000 001F1340 0000003C 001DE42C 0008BC6E 0008BC6E 001DE668 0019CAB4
 1DCF0A: 001886EA 0002D792 001DCF26 0019C5AC 0008BC6E 0008BF1C 00000100 001DCF36
 1DCF2A: 0008A6DA 00000100 00000000 001DCFEA 0008A30E 00000010 00000000 00220E90
 1DCF4A: 001DCF72 00220E90 0000000F 000A7844 001AB1A8 01007234 00000020 00000010
 1DCF6A: 001B9E38 00220E90 0000000F 001DD0A2 001F1340 0000003C 001DE42C 000A7844
 1DCF8A: 0000000A 001DCF9E 0019201C 00816002 0000000D 001DCFB2 001DCFB2 0008BB7C
 1DCFAA: 0000000A 0008B71C 001DCFC6 0008C1FA 0000000A 001F0118 0008B71C 001DCFE2
 1DCFCA: 0008BB50 0000000A 00220E90 0000000F 000A7844 001AB1A8 001DCFF2 0008BBDC
 1DCFEA: 001DD046 00089FB0 001DE668 001B9CC8 001B9F53 01007234
 panic: Illegal instruction
 Stopped at      cpu_Debugger+0x6:       unlk    a6
 db> sync

 dumping to dev 4,9 offset 186257
 dump uvm_fault(0x1f5f78, 0xc3c26000, 0, 0x1) -> 0xe
   type 8, code [mmu,,ssw]: 505
 trap type 8, code = 0x505, v = 0xc3c26854
 kernel program counter = 0x13024
 kernel: MMU fault trap
 trap during panic!
 pid = -1, pc = 00013024, ps = 2704, sfc = 1, dfc = 1
 Registers:
              0        1        2        3        4        5        6        7
 dreg: 00002200 0000FFFF 00142700 00002003 00000200 001DC9E2 00000000 00000000
 areg: 0105904B 0105904B 01059034 C3C26700 00208770 01024200 001DC966 FFFFCFFC

 Kernel stack (001DC87E):
 1DC87E: 001A2518 001DC8CE 00000080 00142700 00002003 00000200 001DC9E2 00000000
 1DC89E: 00000000 01059034 C3C26700 00208770 01024200 00000000 00000001 001DC966
 1DC8BE: 000030A8 00000008 00000505 C3C26854 00002200 0000FFFF 00142700 00002003
 1DC8DE: 00000200 001DC9E2 00000000 00000000 0105904B 0105904B 01059034 C3C26700
 1DC8FE: 00208770 01024200 001DC966 FFFFCFFC 00000000 27040001 30247008 001DC912
 1DC91E: 05050085 00050005 C3C26854 01059034 00000000 00000000 00149E5D 00208770
 1DC93E: 00012FF2 0105904B 001DC9A2 0000000A 00149E5D 00000001 00208770 01024200
 1DC95E: 01002480 00000000 001DC9B2 00188856 01002480 00000000 00208770 00208770
 1DC97E: 00000000 000000A0 00000004 0000000C 0002D791 001F1340 001DC9E2 001DCC32
 1DC99E: 001886EA 2A000014 9E5D0000 01000000 00000000 001DCBE2 0019C788 00000409
 1DC9BE: 0002D791 001DC9E2 00000200 001DC9EA 00222130 00000228 000A7860 0008BC6E
 1DC9DE: 00000000 04878FCA 000001F8 6D616336 386B0000 00000000 00000000 00001000
 1DC9FE: 00000000 FFFFFFFE 00000002 FFFFF000 00000016 003FF000 00000019 01FC0000
 1DCA1E: 00000012 0003F000 0000000C FFFFFE00 FFFFFF00 00000001 FFFFF000 0028C000
 1DCA3E: 00000000 00222118 00000000 00000000 00000000 00000000 043FE000 00000000
 1DCA5E: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 panic: MMU fault
 Stopped at      cpu_Debugger+0x6:       unlk    a6
 db> reboot
 uvm_fault(0x1f5f78, 0xc3c26000, 0, 0x1) -> 0xe
   type 8, code [mmu,,ssw]: 505
 trap type 8, code = 0x505, v = 0xc3c26854
 kernel program counter = 0x13024
 kernel: MMU fault trap
 trap during panic!
 pid = -1, pc = 00013024, ps = 2704, sfc = 1, dfc = 1
 Registers:
              0        1        2        3        4        5        6        7
 dreg: 00002200 0000FFFF 00002700 00040103 00002200 00000000 00000000 0017F8EA
 areg: 0105907F 0105907F 01059068 C3C26700 010580A0 01024200 001DC56A FFFFCFFC

 Kernel stack (001DC482):
 1DC482: 001A2518 001DC4D2 00000080 00002700 00040103 00002200 00000000 00000000
 1DC4A2: 0017F8EA 01059068 C3C26700 010580A0 01024200 00000000 00000001 001DC56A
 1DC4C2: 000030A8 00000008 00000505 C3C26854 00002200 0000FFFF 00002700 00040103
 1DC4E2: 00002200 00000000 00000000 0017F8EA 0105907F 0105907F 01059068 C3C26700
 1DC502: 010580A0 01024200 001DC56A FFFFCFFC 00000000 27040001 30247008 001DC516
 1DC522: 05050085 00050025 C3C26854 01059068 00000000 00000000 00002700 010580A0
 1DC542: 00012FF2 0105907F 0105812C 0000000A 00002700 00000700 010580A0 01024200
 1DC562: 01002480 00221EA2 001DC59A 0017FB98 01002480 00000000 010580A0 00000004
 1DC582: 00000000 00000002 010580A0 0105812C 01024200 01002480 001DC5CE 0017FD6A
 1DC5A2: 01002480 0000000A 00000000 001DC81A FFFFFFFE 00000505 C3C26854 010580A0
 1DC5C2: 0105812C 00000000 01024200 001DC5EE 00181528 010580A0 00000103 01024200
 1DC5E2: 0008BC6E 001DE668 00000000 001DC622 0017E16A 01024200 001DC64E 0000000A
 1DC602: 00000000 00000000 00000004 000186A0 00000000 00000103 00000000 0105AC00
 1DC622: 001DC65E 00187196 01024200 001DC64E 0000000A 00000000 00000000 00000004
 1DC642: 000186A0 00000000 00000103 35000000 00000000 0000C66A 00000000 001DC672
 1DC662: 0018840E 0105AC00 00000003 0020FCE4 001DC682 0009F34E 0105AC00 0008BC6E
 panic: MMU fault
 Stopped at      cpu_Debugger+0x6:       unlk    a6
 db> reboot
 rebooting...

 ----------------------------------------------------------------------------

 Food for a new PR?

 	hauke

 --
 /~\  The ASCII Ribbon Campaign
 \ /    No HTML/RTF in email
  X     No Word docs in email
 / \  Respect for open standards



From: "Perry E. Metzger" <perry@piermont.com>
To: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
Cc: Scott Reynolds <scottr@netbsd.org>, gnats-bugs@gnats.netbsd.org
Subject: Re: port-mac68k/9678
Date: 09 Apr 2003 11:08:06 -0400

 Hauke Fath <hauke@Espresso.Rhein-Neckar.DE> writes:
 > At 16:38 Uhr -0400 7.4.2003, Perry E. Metzger wrote:
 > >I'm more interested in whether 1.6 or -current have it -- 1.5 will go
 > >out of maintenance as soon as we release 2.0.
 > 
 > On the 2003-04-07 1.6.1 snapshot, I cannot get a coredump from within ddb:
 [...]
 > Food for a new PR?

 Potentially, yah.
State-Changed-From-To: closed->open
State-Changed-By: chs@netbsd.org
State-Changed-When: Mon, 21 Nov 2005 04:08:43 +0000
State-Changed-Why:
this bug still exists in the m68k ELF world.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.