sparc64/92033: dc(4) issues on Ultra10

Yasholomew Yashinski yashy at
Mon Feb 6 17:10:08 PST 2006

The following reply was made to PR sparc64/92033; it has been noted by GNATS.

From: Yasholomew Yashinski <yashy at>
To: John Baldwin <jhb at>
Cc: freebsd-sparc64 at, Doug White <dwhite at>, 
 freebsd-gnats-submit at
Subject: Re: sparc64/92033: dc(4) issues on Ultra10
Date: Mon, 06 Feb 2006 20:06:41 -0500

 John Baldwin wrote:
 >>>>dc0: <Macronix 98715/98715A 10/100BaseTX> port 0x400-0x4ff mem
 >>>>0x1800000-0x18000ff at device 2.0 on pci2 miibus1: <MII bus> on dc0
 >>>>dcphy0: <Intel 21143 NWAY media interface> on miibus1
 >>>>dcphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 >>>>dc0: [GIANT-LOCKED]
 >>>>Unread portion of the kernel message buffer:
 >>>>panic: trap: data access error
 >>>>Uptime: 4m15s
 >>>>Dumping 512 MB (2 chunks)
 >>>>  chunk at 0: 268435456 bytes |
 >>>Can you consistently reproduce this problem? If so, it is likely a device
 >>>driver bug.  The data_access_error trap doesn't usually indicate a
 >>>hardware issue.
 >>Yes. As noted below, as soon as dc0 is called upon, the kernel
 >>cores. This happens every time dc0 is called upon.
 > Can you figure out which instance of CSR_READ_4() or DC_CLRBIT() is triggering 
 > this panic?
 I've added:
 options DDB
 to my kernel.
 When I try "boot -d" it just brings me up to a standard login prompt. So
 I tried option two:
 #  sysctl debug.enter_debugger=ddb
 sysctl: unknown oid 'debug.enter_debugger'
 at which point I went to the console and tried CTRL+ALT+ESC, in which
 case the kernel appeared to core and the system rebooted. However it's
 not recognized by gdb:
 This GDB was configured as "sparc64-marcel-freebsd"...
 "/var/crash/vmcore.8" is not a core dump: File format not recognized
 while on this topic (the next page in the handbook):
 # gdb -k /usr/obj/usr/src/sys/COLONEL/kernel
 gdb: unrecognized option `-k'
 Use `gdb --help' for a complete list of options.
  Thanks in Advance,

More information about the freebsd-sparc64 mailing list