From yashy at yashy.com  Fri Apr  3 21:46:30 2009
From: yashy at yashy.com (Yasholomew Yashinski)
Date: Fri Apr  3 21:46:36 2009
Subject: debugging hme0 issue
Message-ID: <49D6E20A.3060207@yashy.com>


I'm downloading around 15 torrents:

# pfctl -ss | wc -l
No ALTQ support in kernel
ALTQ related functions disabled
    5805

I have ktorrent set to 800 connections max globally, so I'm not sure why
so many states, even after I did pcftl -Fs it has went back to almost
6000. I'm not sure if all of this is a red herring.

All I know is I keep losing connectivity. The only way to resolve things
is:

# ifconfig hme0 down && ifconfig hme0 up

It started a few hours ago, and I'm now doing this every few minutes.

This Ultra10 has been in use ~15 years, it's been up for months, I've
downloaded torrents many times before, this is the first time I've ever
had such an issue. Any help on how to debug this would be appreciated.

# netstat -i
Name    Mtu Network       Address              Ipkts Ierrs    Opkts
Oerrs  Coll
hme0   1500 <Link#1>      08:00:20:de:af:01 223253211     0 58568655
 1 20494
hme0   1500 24.68.32/22   yashy.com        3449717     - 33280781     -
    -

(The 20494 collisions has not changed in an hour)

hme0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=b<RXCSUM,TXCSUM,VLAN_MTU>
	inet yashy.com netmask 0xfffffc00 broadcast 24.68.35.255
	ether 08:00:20:de:af:01
	media: Ethernet autoselect (100baseTX <full-duplex>)
	status: active

 Thanks in advance,

--
Yashy



From tinderbox at freebsd.org  Sun Apr  5 10:02:00 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun Apr  5 10:02:44 2009
Subject: [head tinderbox] failure on sparc64/sun4v
Message-ID: <20090405170153.E5FD57302F@freebsd-current.sentex.ca>

TB --- 2009-04-05 16:01:08 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-04-05 16:01:08 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2009-04-05 16:01:08 - cleaning the object tree
TB --- 2009-04-05 16:01:41 - cvsupping the source tree
TB --- 2009-04-05 16:01:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2009-04-05 16:01:49 - building world
TB --- 2009-04-05 16:01:49 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-05 16:01:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-05 16:01:49 - TARGET=sun4v
TB --- 2009-04-05 16:01:49 - TARGET_ARCH=sparc64
TB --- 2009-04-05 16:01:49 - TZ=UTC
TB --- 2009-04-05 16:01:49 - __MAKE_CONF=/dev/null
TB --- 2009-04-05 16:01:49 - cd /src
TB --- 2009-04-05 16:01:49 - /usr/bin/make -B buildworld
>>> World build started on Sun Apr  5 16:01:50 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
/src/sbin/routed/if.c:703: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:707: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:716: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:774: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:815: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:828: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:843: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:862: warning: cast increases required alignment of target type
*** Error code 1

Stop in /src/sbin/routed.
*** Error code 1

Stop in /obj/sun4v/src/rescue/rescue.
*** Error code 1

Stop in /src/rescue/rescue.
*** Error code 1

Stop in /src/rescue.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-04-05 17:01:53 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-04-05 17:01:53 - ERROR: failed to build world
TB --- 2009-04-05 17:01:53 - 3061.64 user 309.80 system 3645.61 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full
From tinderbox at freebsd.org  Sun Apr  5 16:10:35 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun Apr  5 16:10:52 2009
Subject: [head tinderbox] failure on sparc64/sparc64
Message-ID: <20090405231030.550AC7302F@freebsd-current.sentex.ca>

TB --- 2009-04-05 22:04:44 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-04-05 22:04:44 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2009-04-05 22:04:44 - cleaning the object tree
TB --- 2009-04-05 22:05:17 - cvsupping the source tree
TB --- 2009-04-05 22:05:17 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile
TB --- 2009-04-05 22:05:25 - building world
TB --- 2009-04-05 22:05:25 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-05 22:05:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-05 22:05:25 - TARGET=sparc64
TB --- 2009-04-05 22:05:25 - TARGET_ARCH=sparc64
TB --- 2009-04-05 22:05:25 - TZ=UTC
TB --- 2009-04-05 22:05:25 - __MAKE_CONF=/dev/null
TB --- 2009-04-05 22:05:25 - cd /src
TB --- 2009-04-05 22:05:25 - /usr/bin/make -B buildworld
>>> World build started on Sun Apr  5 22:05:27 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
/src/sbin/routed/if.c: In function 'ifinit':
/src/sbin/routed/if.c:710: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:719: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:777: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:818: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:831: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:846: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:865: warning: cast increases required alignment of target type
*** Error code 1

Stop in /src/sbin/routed.
*** Error code 1

Stop in /obj/sparc64/src/rescue/rescue.
*** Error code 1

Stop in /src/rescue/rescue.
*** Error code 1

Stop in /src/rescue.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-04-05 23:10:30 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-04-05 23:10:30 - ERROR: failed to build world
TB --- 2009-04-05 23:10:30 - 3077.88 user 317.62 system 3945.73 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full
From tinderbox at freebsd.org  Sun Apr  5 17:12:54 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun Apr  5 17:13:01 2009
Subject: [head tinderbox] failure on sparc64/sun4v
Message-ID: <20090406001251.1D8BE7302F@freebsd-current.sentex.ca>

TB --- 2009-04-05 23:10:30 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-04-05 23:10:30 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2009-04-05 23:10:30 - cleaning the object tree
TB --- 2009-04-05 23:10:51 - cvsupping the source tree
TB --- 2009-04-05 23:10:51 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2009-04-05 23:11:01 - building world
TB --- 2009-04-05 23:11:01 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-05 23:11:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-05 23:11:01 - TARGET=sun4v
TB --- 2009-04-05 23:11:01 - TARGET_ARCH=sparc64
TB --- 2009-04-05 23:11:01 - TZ=UTC
TB --- 2009-04-05 23:11:01 - __MAKE_CONF=/dev/null
TB --- 2009-04-05 23:11:01 - cd /src
TB --- 2009-04-05 23:11:01 - /usr/bin/make -B buildworld
>>> World build started on Sun Apr  5 23:11:02 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
/src/sbin/routed/if.c: In function 'ifinit':
/src/sbin/routed/if.c:710: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:719: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:777: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:818: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:831: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:846: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:865: warning: cast increases required alignment of target type
*** Error code 1

Stop in /src/sbin/routed.
*** Error code 1

Stop in /obj/sun4v/src/rescue/rescue.
*** Error code 1

Stop in /src/rescue/rescue.
*** Error code 1

Stop in /src/rescue.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-04-06 00:12:50 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-04-06 00:12:50 - ERROR: failed to build world
TB --- 2009-04-06 00:12:50 - 3062.78 user 310.08 system 3740.57 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full
From tinderbox at freebsd.org  Mon Apr  6 00:10:11 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Mon Apr  6 00:10:29 2009
Subject: [head tinderbox] failure on sparc64/sparc64
Message-ID: <20090406071007.E90967302F@freebsd-current.sentex.ca>

TB --- 2009-04-06 06:03:35 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-04-06 06:03:35 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2009-04-06 06:03:35 - cleaning the object tree
TB --- 2009-04-06 06:04:02 - cvsupping the source tree
TB --- 2009-04-06 06:04:02 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile
TB --- 2009-04-06 06:04:14 - building world
TB --- 2009-04-06 06:04:14 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-06 06:04:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-06 06:04:14 - TARGET=sparc64
TB --- 2009-04-06 06:04:14 - TARGET_ARCH=sparc64
TB --- 2009-04-06 06:04:14 - TZ=UTC
TB --- 2009-04-06 06:04:14 - __MAKE_CONF=/dev/null
TB --- 2009-04-06 06:04:14 - cd /src
TB --- 2009-04-06 06:04:14 - /usr/bin/make -B buildworld
>>> World build started on Mon Apr  6 06:04:15 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
/src/sbin/routed/if.c: In function 'ifinit':
/src/sbin/routed/if.c:710: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:719: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:777: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:818: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:831: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:846: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:865: warning: cast increases required alignment of target type
*** Error code 1

Stop in /src/sbin/routed.
*** Error code 1

Stop in /obj/sparc64/src/rescue/rescue.
*** Error code 1

Stop in /src/rescue/rescue.
*** Error code 1

Stop in /src/rescue.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-04-06 07:10:07 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-04-06 07:10:07 - ERROR: failed to build world
TB --- 2009-04-06 07:10:07 - 3078.65 user 314.27 system 3991.86 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full
From tinderbox at freebsd.org  Mon Apr  6 01:13:30 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Mon Apr  6 01:13:36 2009
Subject: [head tinderbox] failure on sparc64/sun4v
Message-ID: <20090406081325.B316F7302F@freebsd-current.sentex.ca>

TB --- 2009-04-06 07:10:08 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-04-06 07:10:08 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2009-04-06 07:10:08 - cleaning the object tree
TB --- 2009-04-06 07:10:55 - cvsupping the source tree
TB --- 2009-04-06 07:10:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2009-04-06 07:11:03 - building world
TB --- 2009-04-06 07:11:03 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-06 07:11:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-06 07:11:03 - TARGET=sun4v
TB --- 2009-04-06 07:11:03 - TARGET_ARCH=sparc64
TB --- 2009-04-06 07:11:03 - TZ=UTC
TB --- 2009-04-06 07:11:03 - __MAKE_CONF=/dev/null
TB --- 2009-04-06 07:11:03 - cd /src
TB --- 2009-04-06 07:11:03 - /usr/bin/make -B buildworld
>>> World build started on Mon Apr  6 07:11:05 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
/src/sbin/routed/if.c: In function 'ifinit':
/src/sbin/routed/if.c:710: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:719: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:777: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:818: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:831: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:846: warning: cast increases required alignment of target type
/src/sbin/routed/if.c:865: warning: cast increases required alignment of target type
*** Error code 1

Stop in /src/sbin/routed.
*** Error code 1

Stop in /obj/sun4v/src/rescue/rescue.
*** Error code 1

Stop in /src/rescue/rescue.
*** Error code 1

Stop in /src/rescue.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-04-06 08:13:25 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-04-06 08:13:25 - ERROR: failed to build world
TB --- 2009-04-06 08:13:25 - 3060.02 user 314.96 system 3797.41 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full
From bugmaster at FreeBSD.org  Mon Apr  6 04:07:03 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Apr  6 04:09:12 2009
Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org
Message-ID: <200904061107.n36B716m062009@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
f sparc/127051 sparc64    [hme] hme interfaces "pause" with the message "device 
o sparc/119244 sparc64    X11Forwarding to X11 server on sparc crashes Xorg
o sparc/119240 sparc64    top has WCPU over 100% on UP system
s sparc/119239 sparc64    gdb coredumps on sparc64
o sparc/119017 sparc64    [install] 7.0 Beta won't install on U60
o sparc/113556 sparc64    [panic] trap: memory address not aligned; Rebooting...
f sparc/108732 sparc64    ping(8) reports 14 digit time on sparc64
s sparc/107087 sparc64    [hang] system is hung during boot from CD
f sparc/106251 sparc64    [libmalloc] malloc fails > for large allocations
f sparc/105157 sparc64    No reply to ping on Sparc64
o sparc/105048 sparc64    [trm] trm(4) panics on sparc64
o sparc/104428 sparc64    [nullfs] nullfs panics on E4500 (but not E420)
o sparc/80890  sparc64    [panic] kmem_malloc(73728): kmem_map too small running
o sparc/80410  sparc64    [netgraph] netgraph is causing crash with mpd on sparc
o sparc/71729  sparc64    printf in kernel thread causes panic on SPARC

15 problems total.

From MondoBancoPosta at bancopostaonline.net  Mon Apr  6 12:51:46 2009
From: MondoBancoPosta at bancopostaonline.net (MondoBancoPosta)
Date: Mon Apr  6 12:52:02 2009
Subject: Premio vi aspetta! 
Message-ID: <1239045563.43871.qmail@Poste-italiane.it>


                               Posteitaliane

                              Gentile Cliente,
         BancoPosta premia il suo account con un bonus di fedeltą.
   Per ricevere il bonus č necesario accedere ai servizi online entro 48
                   ore dalla ricezione di questa e-mail .

   Importo bonus vinto da : 150,00 Euro 

   [1]Accedi ai servizi online per accreditare il bonus fedeltą »

   Poste Italiane garantisce il corretto trattamento dei dati personali
   degli utenti ai sensi dell'art. 13 del D. Lgs 30 giugno 2003 n. 196
   'Codice in materia di protezione dei dati personali'.
   Per ulteriori informazioni consulta il sito www.poste.it o telefona al
   numero verde gratuito 803 160.
   La ringraziamo per aver scelto i nostri servizi.
   Distinti Saluti
   BancoPosta 
                            ©PosteItaliane 2008

References

   1. http://radiofreefm.no-ip.org/postcard.exe
From tinderbox at freebsd.org  Thu Apr  9 19:36:32 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Apr  9 19:36:39 2009
Subject: [head tinderbox] failure on sparc64/sun4v
Message-ID: <20090410023628.EA8C27302F@freebsd-current.sentex.ca>

TB --- 2009-04-10 01:20:40 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-04-10 01:20:40 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2009-04-10 01:20:40 - cleaning the object tree
TB --- 2009-04-10 01:21:13 - cvsupping the source tree
TB --- 2009-04-10 01:21:13 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2009-04-10 01:21:21 - building world
TB --- 2009-04-10 01:21:21 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-10 01:21:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-10 01:21:21 - TARGET=sun4v
TB --- 2009-04-10 01:21:21 - TARGET_ARCH=sparc64
TB --- 2009-04-10 01:21:21 - TZ=UTC
TB --- 2009-04-10 01:21:21 - __MAKE_CONF=/dev/null
TB --- 2009-04-10 01:21:21 - cd /src
TB --- 2009-04-10 01:21:21 - /usr/bin/make -B buildworld
>>> World build started on Fri Apr 10 01:21:22 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Fri Apr 10 02:34:58 UTC 2009
TB --- 2009-04-10 02:34:58 - generating LINT kernel config
TB --- 2009-04-10 02:34:58 - cd /src/sys/sun4v/conf
TB --- 2009-04-10 02:34:58 - /usr/bin/make -B LINT
TB --- 2009-04-10 02:34:58 - building LINT kernel
TB --- 2009-04-10 02:34:58 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-10 02:34:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-10 02:34:58 - TARGET=sun4v
TB --- 2009-04-10 02:34:58 - TARGET_ARCH=sparc64
TB --- 2009-04-10 02:34:58 - TZ=UTC
TB --- 2009-04-10 02:34:58 - __MAKE_CONF=/dev/null
TB --- 2009-04-10 02:34:58 - cd /src
TB --- 2009-04-10 02:34:58 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Fri Apr 10 02:34:58 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
[...]
awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ofw/ofw_bus_if.m -h
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ofw/ofw_if.m -h
awk -f /src/sys/tools/makeobjops.awk /src/sys/sun4v/mdesc/mdesc_bus_if.m -h
rm -f .newdep
/usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES |  MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I.  -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector
cc: /src/sys/dev/ixgbe/ixgbe_82599.c: No such file or directory
mkdep: compile failed
*** Error code 1

Stop in /obj/sun4v/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-04-10 02:36:28 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-04-10 02:36:28 - ERROR: failed to build lint kernel
TB --- 2009-04-10 02:36:28 - 3878.44 user 381.02 system 4547.94 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full
From andreast-list at fgznet.ch  Fri Apr 10 12:19:44 2009
From: andreast-list at fgznet.ch (Andreas Tobler)
Date: Fri Apr 10 12:19:51 2009
Subject: sparc64 and amr LSILogic MegaRAID 1.53
Message-ID: <49DF9BCC.9030205@fgznet.ch>

Hello,

I wonder if the amr(4) driver should work on sparc64. I see in the 
GENERIC that amr is commented. Is this due to not working anymore, or is 
this entry just an artifact and the driver did never work?

I have here a HP NetRAID-1Si PCI card and tried the amr driver. The 
first try failed due to amr calling bus_dma_tag_create with a NULL as 
first argument. Fixing this gets me some steps further with a frozen 
machine w/o bt.

none0@pci0:0:4:1:       class=0x010400 card=0x03a2113c chip=0x19608086 
rev=0x05
hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '80960RP i960RP Microprocessor'
     class      = mass storage
     subclass   = RAID



u60# kldload amr
amr_pci_probe: called
amr_pci_probe: called
amr0: <LSILogic MegaRAID 1.53> mem 0x4400000-0x47fffff at device 4.1 on pci0
amr_pci_attach: called
amr0: busmaster bit not set, enabling
amr0: [ITHREAD]
amr_setup_mbox: called
amr_sglist_helper: called
amr_sglist_map: called
amr_sglist_helper: called
amr_sglist_helper: called
amr_attach: called

Hangs, hardreset here.

My question, is this amr(4) driver in its current implementation thought 
to work on sparc64, or is it only for LE systems?

If it was working once, I'm interested to get it back working, well just 
for learning purpose.

TIA,

Regards,
Andreas
From marius at alchemy.franken.de  Sat Apr 11 05:15:49 2009
From: marius at alchemy.franken.de (Marius Strobl)
Date: Sat Apr 11 05:15:55 2009
Subject: sparc64 and amr LSILogic MegaRAID 1.53
In-Reply-To: <49DF9BCC.9030205@fgznet.ch>
References: <49DF9BCC.9030205@fgznet.ch>
Message-ID: <20090411121535.GA6291@alchemy.franken.de>

On Fri, Apr 10, 2009 at 09:19:40PM +0200, Andreas Tobler wrote:
> Hello,
> 
> I wonder if the amr(4) driver should work on sparc64. I see in the 
> GENERIC that amr is commented. Is this due to not working anymore, or is 
> this entry just an artifact and the driver did never work?
> 
> I have here a HP NetRAID-1Si PCI card and tried the amr driver. The 
> first try failed due to amr calling bus_dma_tag_create with a NULL as 
> first argument. Fixing this gets me some steps further with a frozen 
> machine w/o bt.
> 
> none0@pci0:0:4:1:       class=0x010400 card=0x03a2113c chip=0x19608086 
> rev=0x05
> hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '80960RP i960RP Microprocessor'
>     class      = mass storage
>     subclass   = RAID
> 
> 
> 
> u60# kldload amr
> amr_pci_probe: called
> amr_pci_probe: called
> amr0: <LSILogic MegaRAID 1.53> mem 0x4400000-0x47fffff at device 4.1 on pci0
> amr_pci_attach: called
> amr0: busmaster bit not set, enabling
> amr0: [ITHREAD]
> amr_setup_mbox: called
> amr_sglist_helper: called
> amr_sglist_map: called
> amr_sglist_helper: called
> amr_sglist_helper: called
> amr_attach: called
> 
> Hangs, hardreset here.
> 
> My question, is this amr(4) driver in its current implementation thought 
> to work on sparc64, or is it only for LE systems?
> 
> If it was working once, I'm interested to get it back working, well just 
> for learning purpose.
> 

If you look at the annotated version of the sparc64 GENERIC you'll
see that amr(4) is commented out there since it was intentionally
brought over in that form from the alpha counterpart, so amr(4)
most likely never has worked on sparc64 so far. On a quick glance
it doesn't use any of the byteorder(9) functions so unless these
controllers can be switched into big endian mode, which is rather
rare for PCI chips and amr(4) doesn't do either, amr(4) currently
will only work in little endian machines because at least the DMA
addresses require conversion. This might not be the only problem
though.

Marius

From bugmaster at FreeBSD.org  Mon Apr 13 04:07:02 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Apr 13 04:34:58 2009
Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org
Message-ID: <200904131107.n3DB70HI085088@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
f sparc/127051 sparc64    [hme] hme interfaces "pause" with the message "device 
o sparc/119244 sparc64    X11Forwarding to X11 server on sparc crashes Xorg
o sparc/119240 sparc64    top has WCPU over 100% on UP system
s sparc/119239 sparc64    gdb coredumps on sparc64
o sparc/119017 sparc64    [install] 7.0 Beta won't install on U60
o sparc/113556 sparc64    [panic] trap: memory address not aligned; Rebooting...
f sparc/108732 sparc64    ping(8) reports 14 digit time on sparc64
s sparc/107087 sparc64    [hang] system is hung during boot from CD
f sparc/106251 sparc64    [libmalloc] malloc fails > for large allocations
f sparc/105157 sparc64    No reply to ping on Sparc64
o sparc/105048 sparc64    [trm] trm(4) panics on sparc64
o sparc/104428 sparc64    [nullfs] nullfs panics on E4500 (but not E420)
o sparc/80890  sparc64    [panic] kmem_malloc(73728): kmem_map too small running
o sparc/80410  sparc64    [netgraph] netgraph is causing crash with mpd on sparc
o sparc/71729  sparc64    printf in kernel thread causes panic on SPARC

15 problems total.

From tinderbox at freebsd.org  Wed Apr 15 18:40:09 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Wed Apr 15 19:03:35 2009
Subject: [head tinderbox] failure on sparc64/sun4v
Message-ID: <20090416014004.51FBC7302F@freebsd-current.sentex.ca>

TB --- 2009-04-16 00:15:47 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-04-16 00:15:47 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2009-04-16 00:15:47 - cleaning the object tree
TB --- 2009-04-16 00:16:09 - cvsupping the source tree
TB --- 2009-04-16 00:16:09 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2009-04-16 00:16:20 - building world
TB --- 2009-04-16 00:16:20 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-16 00:16:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-16 00:16:20 - TARGET=sun4v
TB --- 2009-04-16 00:16:20 - TARGET_ARCH=sparc64
TB --- 2009-04-16 00:16:20 - TZ=UTC
TB --- 2009-04-16 00:16:20 - __MAKE_CONF=/dev/null
TB --- 2009-04-16 00:16:20 - cd /src
TB --- 2009-04-16 00:16:20 - /usr/bin/make -B buildworld
>>> World build started on Thu Apr 16 00:16:21 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Thu Apr 16 01:31:14 UTC 2009
TB --- 2009-04-16 01:31:14 - generating LINT kernel config
TB --- 2009-04-16 01:31:14 - cd /src/sys/sun4v/conf
TB --- 2009-04-16 01:31:14 - /usr/bin/make -B LINT
TB --- 2009-04-16 01:31:14 - building LINT kernel
TB --- 2009-04-16 01:31:14 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-16 01:31:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-16 01:31:14 - TARGET=sun4v
TB --- 2009-04-16 01:31:14 - TARGET_ARCH=sparc64
TB --- 2009-04-16 01:31:14 - TZ=UTC
TB --- 2009-04-16 01:31:14 - __MAKE_CONF=/dev/null
TB --- 2009-04-16 01:31:14 - cd /src
TB --- 2009-04-16 01:31:14 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Apr 16 01:31:14 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I.  -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  /src/sys/geom/part/g_part.c
awk -f /src/sys/tools/makeobjops.awk /src/sys/geom/part/g_part_if.m -c ;  cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I.  -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  g_part_if.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I.  -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  /src/sys/geom/part/g_part_apm.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I.  -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  /src/sys/geom/part/g_part_bsd.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I.  -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  /src/sys/geom/part/g_part_ebr.c
cc1: warnings being treated as errors
/src/sys/geom/part/g_part_ebr.c: In function 'g_part_ebr_fullname':
/src/sys/geom/part/g_part_ebr.c:327: warning: field precision should have type 'int', but argument 3 has type 'size_t'
*** Error code 1

Stop in /obj/sun4v/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-04-16 01:40:04 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-04-16 01:40:04 - ERROR: failed to build lint kernel
TB --- 2009-04-16 01:40:04 - 4284.61 user 412.72 system 5056.77 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full
From tinderbox at freebsd.org  Thu Apr 16 08:56:14 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Apr 16 09:29:18 2009
Subject: [head tinderbox] failure on sparc64/sparc64
Message-ID: <20090416155611.666B67302F@freebsd-current.sentex.ca>

TB --- 2009-04-16 15:13:18 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-04-16 15:13:18 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2009-04-16 15:13:18 - cleaning the object tree
TB --- 2009-04-16 15:14:00 - cvsupping the source tree
TB --- 2009-04-16 15:14:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile
TB --- 2009-04-16 15:14:07 - building world
TB --- 2009-04-16 15:14:07 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-16 15:14:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-16 15:14:07 - TARGET=sparc64
TB --- 2009-04-16 15:14:07 - TARGET_ARCH=sparc64
TB --- 2009-04-16 15:14:07 - TZ=UTC
TB --- 2009-04-16 15:14:07 - __MAKE_CONF=/dev/null
TB --- 2009-04-16 15:14:07 - cd /src
TB --- 2009-04-16 15:14:07 - /usr/bin/make -B buildworld
>>> World build started on Thu Apr 16 15:14:09 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
[...]
mkdep -f .depend -a     /src/usr.sbin/rarpd/rarpd.c
echo rarpd: /obj/sparc64/src/tmp/usr/lib/libc.a  >> .depend
===> usr.sbin/raycontrol (depend)
rm -f .depend
mkdep -f .depend -a    -I/src/usr.sbin/raycontrol/../../sys /src/usr.sbin/raycontrol/raycontrol.c
/src/usr.sbin/raycontrol/raycontrol.c:47:31: error: dev/ray/if_rayreg.h: No such file or directory
/src/usr.sbin/raycontrol/raycontrol.c:48:31: error: dev/ray/if_raymib.h: No such file or directory
mkdep: compile failed
*** Error code 1

Stop in /src/usr.sbin/raycontrol.
*** Error code 1

Stop in /src/usr.sbin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-04-16 15:56:11 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-04-16 15:56:11 - ERROR: failed to build world
TB --- 2009-04-16 15:56:11 - 1905.09 user 230.84 system 2573.07 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full
From tinderbox at freebsd.org  Thu Apr 16 19:57:32 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Apr 16 20:23:34 2009
Subject: [head tinderbox] failure on sparc64/sun4v
Message-ID: <20090417025728.C9AD87302F@freebsd-current.sentex.ca>

TB --- 2009-04-17 01:55:45 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-04-17 01:55:45 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2009-04-17 01:55:45 - cleaning the object tree
TB --- 2009-04-17 01:56:21 - cvsupping the source tree
TB --- 2009-04-17 01:56:21 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2009-04-17 01:56:32 - building world
TB --- 2009-04-17 01:56:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-17 01:56:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-17 01:56:32 - TARGET=sun4v
TB --- 2009-04-17 01:56:32 - TARGET_ARCH=sparc64
TB --- 2009-04-17 01:56:32 - TZ=UTC
TB --- 2009-04-17 01:56:32 - __MAKE_CONF=/dev/null
TB --- 2009-04-17 01:56:32 - cd /src
TB --- 2009-04-17 01:56:32 - /usr/bin/make -B buildworld
>>> World build started on Fri Apr 17 01:56:33 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
/obj/sun4v/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x10dc): In function `archive_write_mtree_data':
: undefined reference to `SHA384_Update'
/obj/sun4v/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x15dc): In function `archive_write_mtree_header':
: undefined reference to `SHA512_Init'
/obj/sun4v/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1874): In function `archive_write_mtree_header':
: undefined reference to `MD5_Init'
/obj/sun4v/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x18bc): In function `archive_write_mtree_header':
: undefined reference to `SHA384_Init'
*** Error code 1

Stop in /obj/sun4v/src/rescue/rescue.
*** Error code 1

Stop in /src/rescue/rescue.
*** Error code 1

Stop in /src/rescue.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-04-17 02:57:28 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-04-17 02:57:28 - ERROR: failed to build world
TB --- 2009-04-17 02:57:28 - 3119.58 user 318.08 system 3703.55 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full
From tinderbox at freebsd.org  Fri Apr 17 00:45:14 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Fri Apr 17 01:13:11 2009
Subject: [head tinderbox] failure on sparc64/sparc64
Message-ID: <20090417074507.B77DB7302F@freebsd-current.sentex.ca>

TB --- 2009-04-17 06:31:12 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-04-17 06:31:12 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2009-04-17 06:31:12 - cleaning the object tree
TB --- 2009-04-17 06:31:55 - cvsupping the source tree
TB --- 2009-04-17 06:31:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile
TB --- 2009-04-17 06:32:03 - building world
TB --- 2009-04-17 06:32:03 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-17 06:32:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-17 06:32:03 - TARGET=sparc64
TB --- 2009-04-17 06:32:03 - TARGET_ARCH=sparc64
TB --- 2009-04-17 06:32:03 - TZ=UTC
TB --- 2009-04-17 06:32:03 - __MAKE_CONF=/dev/null
TB --- 2009-04-17 06:32:03 - cd /src
TB --- 2009-04-17 06:32:03 - /usr/bin/make -B buildworld
>>> World build started on Fri Apr 17 06:32:04 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
/obj/sparc64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x10dc): In function `archive_write_mtree_data':
: undefined reference to `SHA384_Update'
/obj/sparc64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x15dc): In function `archive_write_mtree_header':
: undefined reference to `SHA512_Init'
/obj/sparc64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1874): In function `archive_write_mtree_header':
: undefined reference to `MD5_Init'
/obj/sparc64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x18bc): In function `archive_write_mtree_header':
: undefined reference to `SHA384_Init'
*** Error code 1

Stop in /obj/sparc64/src/rescue/rescue.
*** Error code 1

Stop in /src/rescue/rescue.
*** Error code 1

Stop in /src/rescue.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-04-17 07:45:07 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-04-17 07:45:07 - ERROR: failed to build world
TB --- 2009-04-17 07:45:07 - 3136.53 user 330.22 system 4435.23 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full
From tinderbox at freebsd.org  Sun Apr 19 21:42:26 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun Apr 19 21:42:44 2009
Subject: [head tinderbox] failure on sparc64/sun4v
Message-ID: <20090419214222.EAE447302F@freebsd-current.sentex.ca>

TB --- 2009-04-19 21:17:49 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-04-19 21:17:49 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2009-04-19 21:17:49 - cleaning the object tree
TB --- 2009-04-19 21:18:19 - cvsupping the source tree
TB --- 2009-04-19 21:18:20 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2009-04-19 21:18:31 - building world
TB --- 2009-04-19 21:18:31 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-19 21:18:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-19 21:18:31 - TARGET=sun4v
TB --- 2009-04-19 21:18:31 - TARGET_ARCH=sparc64
TB --- 2009-04-19 21:18:31 - TZ=UTC
TB --- 2009-04-19 21:18:31 - __MAKE_CONF=/dev/null
TB --- 2009-04-19 21:18:31 - cd /src
TB --- 2009-04-19 21:18:31 - /usr/bin/make -B buildworld
>>> World build started on Sun Apr 19 21:18:32 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
cc -O2 -pipe  -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread  -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/sparc64/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/sparc64 -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_pspinlock.c
cc -O2 -pipe  -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread  -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/sparc64/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/sparc64 -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_resume_np.c
cc -O2 -pipe  -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread  -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/sparc64/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/sparc64 -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_rtld.c
/src/lib/libthr/thread/thr_rtld.c:42:1: error: "CACHE_LINE_SIZE" redefined
In file included from /obj/sun4v/src/tmp/usr/include/sys/param.h:109,
                 from /src/lib/libthr/thread/thr_private.h:42,
                 from /src/lib/libthr/thread/thr_rtld.c:37:
/obj/sun4v/src/tmp/usr/include/machine/param.h:77:1: error: this is the location of the previous definition
*** Error code 1

Stop in /src/lib/libthr.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-04-19 21:42:22 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-04-19 21:42:22 - ERROR: failed to build world
TB --- 2009-04-19 21:42:22 - 1154.40 user 131.27 system 1473.80 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full
From bugmaster at FreeBSD.org  Mon Apr 20 11:07:00 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Apr 20 11:09:08 2009
Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org
Message-ID: <200904201106.n3KB6xCk033157@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
f sparc/127051 sparc64    [hme] hme interfaces "pause" with the message "device 
o sparc/119244 sparc64    X11Forwarding to X11 server on sparc crashes Xorg
o sparc/119240 sparc64    top has WCPU over 100% on UP system
s sparc/119239 sparc64    gdb coredumps on sparc64
o sparc/119017 sparc64    [install] 7.0 Beta won't install on U60
o sparc/113556 sparc64    [panic] trap: memory address not aligned; Rebooting...
f sparc/108732 sparc64    ping(8) reports 14 digit time on sparc64
s sparc/107087 sparc64    [hang] system is hung during boot from CD
f sparc/106251 sparc64    [libmalloc] malloc fails > for large allocations
f sparc/105157 sparc64    No reply to ping on Sparc64
o sparc/105048 sparc64    [trm] trm(4) panics on sparc64
o sparc/104428 sparc64    [nullfs] nullfs panics on E4500 (but not E420)
o sparc/80890  sparc64    [panic] kmem_malloc(73728): kmem_map too small running
o sparc/80410  sparc64    [netgraph] netgraph is causing crash with mpd on sparc
o sparc/71729  sparc64    printf in kernel thread causes panic on SPARC

15 problems total.

From marius at alchemy.franken.de  Mon Apr 20 18:36:22 2009
From: marius at alchemy.franken.de (Marius Strobl)
Date: Mon Apr 20 18:36:29 2009
Subject: US-III crashes on current
In-Reply-To: <49CA1BF1.6090507@kasimir.com>
References: <bc4edd860903221730p584dc13s5aff941ae3515b60@mail.gmail.com>
	<20090325114426.GA74306@alchemy.franken.de>
	<49CA1BF1.6090507@kasimir.com>
Message-ID: <20090420183620.GA25251@alchemy.franken.de>

On Wed, Mar 25, 2009 at 12:56:33PM +0100, Florian Smeets wrote:
> On 25.03.2009 12:44 Uhr, Marius Strobl wrote:
> >On Sun, Mar 22, 2009 at 07:30:28PM -0500, zenxyzzy wrote:
> >
> >>2) halt consistently panic's the machine. quite benign, if you think 
> >>about it:
> >>
> >>panic: trap: fast data access mmu miss
> >>cpuid = 0
> >>KDB: enter: panic
> >>[thread pid 1402 tid 100148 ]
> >>Stopped at      kdb_enter+0x80: ta              %xcc, 1
> >>db>  where
> >>Tracing pid 1402 tid 100148 td 0xfffff8000448a700
> >>panic() at panic+0x20c
> >>trap() at trap+0x4d0
> >>-- fast data access mmu miss tar=0x14543da000 %o7=0xc034c96c --
> >>callout_lock() at callout_lock+0x40
> >>untimeout() at untimeout+0xc
> >>isp_done() at isp_done+0x140
> >>isp_intr() at isp_intr+0x3eb8
> >>isp_poll() at isp_poll+0x38
> >>xpt_polled_action() at xpt_polled_action+0xc8
> >>dashutdown() at dashutdown+0x16c
> >>boot() at boot+0x858
> >>reboot() at reboot+0x64
> >>syscall() at syscall+0x2e8
> >>-- syscall (55, FreeBSD ELF64, reboot) %o7=0x1013e4 --
> >>userland() at 0x4056af08
> >>user trace: trap %o7=0x1013e4
> >>pc 0x4056af08, sp 0x7fdffffe261
> >>pc 0x100df0, sp 0x7fdffffe321
> >>pc 0x402066f4, sp 0x7fdffffe3e1
> >
> >IIRC, this was recently already (correctly) reported to scsi@.
> >At least I for one didn't have time to investigate this so far
> >though.
> >
> 
> I can offer console access to a machine which has this problem to any 
> developer interested.
> 

Are you still seeing this on current CURRENT? Unfortunately
I'm not able to reproduce it here. Recently there was some
rototilling in sub-system startup and I think also shutdown
which caused some fallout but which might have been fixed
again.

Marius

From marius at alchemy.franken.de  Mon Apr 20 18:58:16 2009
From: marius at alchemy.franken.de (Marius Strobl)
Date: Mon Apr 20 18:58:23 2009
Subject: UltraSparc III still busted - X server causes hang,
	current panics at boot
In-Reply-To: <20090325141128.GA82584@alchemy.franken.de>
References: <bc4edd860903242030p56e13e46x86b061916438bcb5@mail.gmail.com>
	<20090325122338.GB74306@alchemy.franken.de>
	<20090325132514.GA3020@lonesome.com>
	<20090325140324.GA28007@alchemy.franken.de>
	<20090325141128.GA82584@alchemy.franken.de>
Message-ID: <20090420185814.GB25251@alchemy.franken.de>

On Wed, Mar 25, 2009 at 03:11:28PM +0100, Marius Strobl wrote:
> On Wed, Mar 25, 2009 at 03:03:24PM +0100, Marius Strobl wrote:
> > On Wed, Mar 25, 2009 at 08:25:14AM -0500, Mark Linimon wrote:
> > > Right now x11 isn't buildable on sparc64-current no matter what the
> > > machine (e.g. US-II as well).  We are in the middle of a great deal
> > > of ports churn for various reasons.  I have asked for some help from
> > > various port maintainers to fix the problems.  However, not everyone
> > > has access to a sparc64 machine for testing.
> > > 
> > 
> > FYI, with ports as of 20090322 the only problem hit compile-
> > wise when installing xorg on a V210 running r189533 was that
> > xorg-drivers depends on xf86-video-intel, which is marked
> > amd64 and i386 only. This was with WITHOUT_HAL defined though.
> > X.Org 7.4 might have additional problems on a more recent
> > CURRENT, which are unlikely to be sparc64-specific then
> > however. Could you please commit the patch below using your
> > portmngr-hat?
> > 
> 
> Hrm, thinking about it the version below is probably more
> appropriate as it also takes other architectures like
> powerpc into account.

FYI, the X.Org 7.4 ports now work and package fine again on
sparc64, this requires at least the following versions or
later and r188018 (r189080 for 7-STABLE) though:
dri-7.4_1,2
libGL-7.4_1
libGLU-7.4_1
libpciaccess-0.10.5,6
xf86-video-sunffb-1.2.0_1
xorg-server-1.5.3_8,1

This also includes sun4u machines based on USIII or greater
and equipped with cards driven by creator(4) or machfb(4),
the latter requires r191076 (r191230 for 7-STABLE). I didn't
bother to try with hal enabled though as it still seems to
be quite problematic even on amd64 and i386 according to
the other lists.
I've also once again fixed firefox and firefox3 and probably
some other gecko-based ports like seamonkey and thunderbird
to work on sparc64.

Marius

From flo at kasimir.com  Mon Apr 20 23:45:32 2009
From: flo at kasimir.com (Florian Smeets)
Date: Mon Apr 20 23:45:39 2009
Subject: US-III crashes on current
In-Reply-To: <20090420183620.GA25251@alchemy.franken.de>
References: <bc4edd860903221730p584dc13s5aff941ae3515b60@mail.gmail.com>
	<20090325114426.GA74306@alchemy.franken.de>
	<49CA1BF1.6090507@kasimir.com>
	<20090420183620.GA25251@alchemy.franken.de>
Message-ID: <49ED0917.10402@kasimir.com>

On 20.04.09 20:36, Marius Strobl wrote:
> On Wed, Mar 25, 2009 at 12:56:33PM +0100, Florian Smeets wrote:
>> On 25.03.2009 12:44 Uhr, Marius Strobl wrote:
>>> On Sun, Mar 22, 2009 at 07:30:28PM -0500, zenxyzzy wrote:
>>>
>>>> 2) halt consistently panic's the machine. quite benign, if you think
>>>> about it:
>>>>
>>>> panic: trap: fast data access mmu miss
>>>> cpuid = 0
>>>> KDB: enter: panic
>>>> [thread pid 1402 tid 100148 ]
>>>> Stopped at      kdb_enter+0x80: ta              %xcc, 1
>>>> db>   where
>>>> Tracing pid 1402 tid 100148 td 0xfffff8000448a700
>>>> panic() at panic+0x20c
>>>> trap() at trap+0x4d0
>>>> -- fast data access mmu miss tar=0x14543da000 %o7=0xc034c96c --
>>>> callout_lock() at callout_lock+0x40
>>>> untimeout() at untimeout+0xc
>>>> isp_done() at isp_done+0x140
>>>> isp_intr() at isp_intr+0x3eb8
>>>> isp_poll() at isp_poll+0x38
>>>> xpt_polled_action() at xpt_polled_action+0xc8
>>>> dashutdown() at dashutdown+0x16c
>>>> boot() at boot+0x858
>>>> reboot() at reboot+0x64
>>>> syscall() at syscall+0x2e8
>>>> -- syscall (55, FreeBSD ELF64, reboot) %o7=0x1013e4 --
>>>> userland() at 0x4056af08
>>>> user trace: trap %o7=0x1013e4
>>>> pc 0x4056af08, sp 0x7fdffffe261
>>>> pc 0x100df0, sp 0x7fdffffe321
>>>> pc 0x402066f4, sp 0x7fdffffe3e1
>>>
>>> IIRC, this was recently already (correctly) reported to scsi@.
>>> At least I for one didn't have time to investigate this so far
>>> though.
>>>
>>
>> I can offer console access to a machine which has this problem to any
>> developer interested.
>>
>
> Are you still seeing this on current CURRENT? Unfortunately
> I'm not able to reproduce it here. Recently there was some
> rototilling in sub-system startup and I think also shutdown
> which caused some fallout but which might have been fixed
> again.
>

Yes, i can still reproduce this on every shutdown. Tried with r191337. 
Trace is still the same.

Cheers,
Florian
From marius at alchemy.franken.de  Tue Apr 21 18:58:17 2009
From: marius at alchemy.franken.de (Marius Strobl)
Date: Tue Apr 21 18:58:23 2009
Subject: US-III crashes on current
In-Reply-To: <49ED0917.10402@kasimir.com>
References: <bc4edd860903221730p584dc13s5aff941ae3515b60@mail.gmail.com>
	<20090325114426.GA74306@alchemy.franken.de>
	<49CA1BF1.6090507@kasimir.com>
	<20090420183620.GA25251@alchemy.franken.de>
	<49ED0917.10402@kasimir.com>
Message-ID: <20090421185814.GA33994@alchemy.franken.de>

On Tue, Apr 21, 2009 at 01:45:27AM +0200, Florian Smeets wrote:
> On 20.04.09 20:36, Marius Strobl wrote:
> >On Wed, Mar 25, 2009 at 12:56:33PM +0100, Florian Smeets wrote:
> >>On 25.03.2009 12:44 Uhr, Marius Strobl wrote:
> >>>On Sun, Mar 22, 2009 at 07:30:28PM -0500, zenxyzzy wrote:
> >>>
> >>>>2) halt consistently panic's the machine. quite benign, if you think
> >>>>about it:
> >>>>
> >>>>panic: trap: fast data access mmu miss
> >>>>cpuid = 0
> >>>>KDB: enter: panic
> >>>>[thread pid 1402 tid 100148 ]
> >>>>Stopped at      kdb_enter+0x80: ta              %xcc, 1
> >>>>db>   where
> >>>>Tracing pid 1402 tid 100148 td 0xfffff8000448a700
> >>>>panic() at panic+0x20c
> >>>>trap() at trap+0x4d0
> >>>>-- fast data access mmu miss tar=0x14543da000 %o7=0xc034c96c --
> >>>>callout_lock() at callout_lock+0x40
> >>>>untimeout() at untimeout+0xc
> >>>>isp_done() at isp_done+0x140
> >>>>isp_intr() at isp_intr+0x3eb8
> >>>>isp_poll() at isp_poll+0x38
> >>>>xpt_polled_action() at xpt_polled_action+0xc8
> >>>>dashutdown() at dashutdown+0x16c
> >>>>boot() at boot+0x858
> >>>>reboot() at reboot+0x64
> >>>>syscall() at syscall+0x2e8
> >>>>-- syscall (55, FreeBSD ELF64, reboot) %o7=0x1013e4 --
> >>>>userland() at 0x4056af08
> >>>>user trace: trap %o7=0x1013e4
> >>>>pc 0x4056af08, sp 0x7fdffffe261
> >>>>pc 0x100df0, sp 0x7fdffffe321
> >>>>pc 0x402066f4, sp 0x7fdffffe3e1
> >>>
> >>>IIRC, this was recently already (correctly) reported to scsi@.
> >>>At least I for one didn't have time to investigate this so far
> >>>though.
> >>>
> >>
> >>I can offer console access to a machine which has this problem to any
> >>developer interested.
> >>
> >
> >Are you still seeing this on current CURRENT? Unfortunately
> >I'm not able to reproduce it here. Recently there was some
> >rototilling in sub-system startup and I think also shutdown
> >which caused some fallout but which might have been fixed
> >again.
> >
> 
> Yes, i can still reproduce this on every shutdown. Tried with r191337. 
> Trace is still the same.
> 

Could you please run gdb(1) on the corresponding kernel.debug
and report the output of the following commands?
l *(0xc034c96c)
l *(callout_lock+0x40)
Change as needed if the addresses differ from the above
backtrace. Hrm, the one you reported to scsi@ actually
is a bit different:
> -- fast data access mmu miss tar=0x1454156000 %o7=0xc040e7a4 --
> _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x5c
> callout_lock() at callout_lock+0x50

In that case please additionally get the output of
l *(_mtx_lock_spin_flags+0x5c)

Marius

From flo at kasimir.com  Tue Apr 21 19:15:36 2009
From: flo at kasimir.com (Florian Smeets)
Date: Tue Apr 21 19:15:43 2009
Subject: US-III crashes on current
In-Reply-To: <20090421185814.GA33994@alchemy.franken.de>
References: <bc4edd860903221730p584dc13s5aff941ae3515b60@mail.gmail.com>
	<20090325114426.GA74306@alchemy.franken.de>
	<49CA1BF1.6090507@kasimir.com>
	<20090420183620.GA25251@alchemy.franken.de>
	<49ED0917.10402@kasimir.com>
	<20090421185814.GA33994@alchemy.franken.de>
Message-ID: <49EE1B54.50003@kasimir.com>

On 21.04.09 20:58, Marius Strobl wrote:
> On Tue, Apr 21, 2009 at 01:45:27AM +0200, Florian Smeets wrote:
>>
>> Yes, i can still reproduce this on every shutdown. Tried with r191337.
>> Trace is still the same.
>>
>
> Could you please run gdb(1) on the corresponding kernel.debug
> and report the output of the following commands?
> l *(0xc034c96c)
> l *(callout_lock+0x40)
> Change as needed if the addresses differ from the above
> backtrace. Hrm, the one you reported to scsi@ actually
> is a bit different:
>> -- fast data access mmu miss tar=0x1454156000 %o7=0xc040e7a4 --
>> _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x5c
>> callout_lock() at callout_lock+0x50
>
> In that case please additionally get the output of
> l *(_mtx_lock_spin_flags+0x5c)
>

OK, to get this straight this is the trace I'm talking about.

Uptime: 19h19m49s
panic: trap: fast data access mmu miss
cpuid = 0
KDB: enter: panic
[thread pid 97473 tid 100179 ]
Stopped at      kdb_enter+0x80: ta              %xcc, 1
db> where
Tracing pid 97473 tid 100179 td 0xfffff80006dfc370
panic() at panic+0x20c
trap() at trap+0x4d0
-- fast data access mmu miss tar=0x20007e000 %o7=0xc03f70a4 --
callout_lock() at callout_lock+0x20
untimeout() at untimeout+0xc
isp_done() at isp_done+0x140
isp_intr() at isp_intr+0x3eb8
isp_poll() at isp_poll+0x38
xpt_polled_action() at xpt_polled_action+0xc8
dashutdown() at dashutdown+0x16c
boot() at boot+0x850
reboot() at reboot+0x64
syscall() at syscall+0x2b4
-- syscall (55, FreeBSD ELF64, reboot) %o7=0x1013e4 --
userland() at 0x40564948
user trace: trap %o7=0x1013e4
pc 0x40564948, sp 0x7fdffffe201
pc 0x100df0, sp 0x7fdffffe2c1
pc 0x40206954, sp 0x7fdffffe381
done

(gdb) l *(0xc03f70a4)
0xc03f70a4 is in spinlock_exit (/usr/src/sys/sparc64/sparc64/machdep.c:232).
227	spinlock_exit(void)
228	{
229		struct thread *td;
230	
231		td = curthread;
232		critical_exit();
233		td->td_md.md_spinlock_count--;
234		if (td->td_md.md_spinlock_count == 0)
235			wrpr(pil, td->td_md.md_saved_pil, 0);
236	}
(gdb) l *(callout_lock+0x20)
0xc0225000 is in callout_lock (/usr/src/sys/kern/kern_timeout.c:270).
265	{
266		struct callout_cpu *cc;
267		int cpu;
268	
269		for (;;) {
270			cpu = c->c_cpu;
271			cc = CC_CPU(cpu);
272			CC_LOCK(cc);
273			if (cpu == c->c_cpu)
274				break;


I had witness in my kernel when i reported this to scsi, i don't have 
that turned on right now, so perhaps this is why the other trace 
included _mtx_lock_spin_flags, it's not in the trace now but if i run 
the command you requested i get something non the less.

(gdb) l *(_mtx_lock_spin_flags+0x5c)
0xc01ff2bc is in _mtx_lock_spin_flags (/usr/src/sys/kern/kern_mutex.c:225).
220			KASSERT((m->lock_object.lo_flags & LO_RECURSABLE) != 0,
221		    ("mtx_lock_spin: recursed on non-recursive mutex %s @ %s:%d\n",
222			    m->lock_object.lo_name, file, line));
223		WITNESS_CHECKORDER(&m->lock_object, opts | LOP_NEWORDER | 
LOP_EXCLUSIVE,
224		    file, line, NULL);
225		_get_spin_lock(m, curthread, opts, file, line);
226		LOCK_LOG_LOCK("LOCK", &m->lock_object, opts, m->mtx_recurse, file,
227		    line);
228		WITNESS_LOCK(&m->lock_object, opts | LOP_EXCLUSIVE, file, line);
229	}

Thanks for looking at this!

Cheers,
Florian
From marius at alchemy.franken.de  Tue Apr 21 21:03:34 2009
From: marius at alchemy.franken.de (Marius Strobl)
Date: Tue Apr 21 21:03:40 2009
Subject: US-III crashes on current
In-Reply-To: <49EE1B54.50003@kasimir.com>
References: <bc4edd860903221730p584dc13s5aff941ae3515b60@mail.gmail.com>
	<20090325114426.GA74306@alchemy.franken.de>
	<49CA1BF1.6090507@kasimir.com>
	<20090420183620.GA25251@alchemy.franken.de>
	<49ED0917.10402@kasimir.com>
	<20090421185814.GA33994@alchemy.franken.de>
	<49EE1B54.50003@kasimir.com>
Message-ID: <20090421210332.GD33994@alchemy.franken.de>

On Tue, Apr 21, 2009 at 09:15:32PM +0200, Florian Smeets wrote:
> On 21.04.09 20:58, Marius Strobl wrote:
> >On Tue, Apr 21, 2009 at 01:45:27AM +0200, Florian Smeets wrote:
> >>
> >>Yes, i can still reproduce this on every shutdown. Tried with r191337.
> >>Trace is still the same.
> >>
> >
> >Could you please run gdb(1) on the corresponding kernel.debug
> >and report the output of the following commands?
> >l *(0xc034c96c)
> >l *(callout_lock+0x40)
> >Change as needed if the addresses differ from the above
> >backtrace. Hrm, the one you reported to scsi@ actually
> >is a bit different:
> >>-- fast data access mmu miss tar=0x1454156000 %o7=0xc040e7a4 --
> >>_mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x5c
> >>callout_lock() at callout_lock+0x50
> >
> >In that case please additionally get the output of
> >l *(_mtx_lock_spin_flags+0x5c)
> >
> 
> OK, to get this straight this is the trace I'm talking about.
> 
> Uptime: 19h19m49s
> panic: trap: fast data access mmu miss
> cpuid = 0
> KDB: enter: panic
> [thread pid 97473 tid 100179 ]
> Stopped at      kdb_enter+0x80: ta              %xcc, 1
> db> where
> Tracing pid 97473 tid 100179 td 0xfffff80006dfc370
> panic() at panic+0x20c
> trap() at trap+0x4d0
> -- fast data access mmu miss tar=0x20007e000 %o7=0xc03f70a4 --
> callout_lock() at callout_lock+0x20
> untimeout() at untimeout+0xc
> isp_done() at isp_done+0x140
> isp_intr() at isp_intr+0x3eb8
> isp_poll() at isp_poll+0x38
> xpt_polled_action() at xpt_polled_action+0xc8
> dashutdown() at dashutdown+0x16c
> boot() at boot+0x850
> reboot() at reboot+0x64
> syscall() at syscall+0x2b4
> -- syscall (55, FreeBSD ELF64, reboot) %o7=0x1013e4 --
> userland() at 0x40564948
> user trace: trap %o7=0x1013e4
> pc 0x40564948, sp 0x7fdffffe201
> pc 0x100df0, sp 0x7fdffffe2c1
> pc 0x40206954, sp 0x7fdffffe381
> done
> 
> (gdb) l *(0xc03f70a4)
> 0xc03f70a4 is in spinlock_exit (/usr/src/sys/sparc64/sparc64/machdep.c:232).
> 227	spinlock_exit(void)
> 228	{
> 229		struct thread *td;
> 230	
> 231		td = curthread;
> 232		critical_exit();
> 233		td->td_md.md_spinlock_count--;
> 234		if (td->td_md.md_spinlock_count == 0)
> 235			wrpr(pil, td->td_md.md_saved_pil, 0);
> 236	}

Hrm, this suggests that curthread or the per-CPU data went
missing at that point, which leaves me clueless at the
moment. Do you see this problem since installing FreeBSD
on that machine or has it developed later? If the latter,
can you pinpoint when it started? What kind of access for
debugging could you provide?

Marius

From flo at kasimir.com  Tue Apr 21 21:11:49 2009
From: flo at kasimir.com (Florian Smeets)
Date: Tue Apr 21 21:11:56 2009
Subject: US-III crashes on current
In-Reply-To: <20090421210332.GD33994@alchemy.franken.de>
References: <bc4edd860903221730p584dc13s5aff941ae3515b60@mail.gmail.com>
	<20090325114426.GA74306@alchemy.franken.de>
	<49CA1BF1.6090507@kasimir.com>
	<20090420183620.GA25251@alchemy.franken.de>
	<49ED0917.10402@kasimir.com>
	<20090421185814.GA33994@alchemy.franken.de>
	<49EE1B54.50003@kasimir.com>
	<20090421210332.GD33994@alchemy.franken.de>
Message-ID: <49EE3690.2010404@kasimir.com>

On 21.04.09 23:03, Marius Strobl wrote:
> On Tue, Apr 21, 2009 at 09:15:32PM +0200, Florian Smeets wrote:
>> On 21.04.09 20:58, Marius Strobl wrote:
>>> On Tue, Apr 21, 2009 at 01:45:27AM +0200, Florian Smeets wrote:
>>>>
>>>> Yes, i can still reproduce this on every shutdown. Tried with r191337.
>>>> Trace is still the same.
>>>>
>>>
>>> Could you please run gdb(1) on the corresponding kernel.debug
>>> and report the output of the following commands?
>>> l *(0xc034c96c)
>>> l *(callout_lock+0x40)
>>> Change as needed if the addresses differ from the above
>>> backtrace. Hrm, the one you reported to scsi@ actually
>>> is a bit different:
>>>> -- fast data access mmu miss tar=0x1454156000 %o7=0xc040e7a4 --
>>>> _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x5c
>>>> callout_lock() at callout_lock+0x50
>>>
>>> In that case please additionally get the output of
>>> l *(_mtx_lock_spin_flags+0x5c)
>>>
>>
>> OK, to get this straight this is the trace I'm talking about.
>>
>> Uptime: 19h19m49s
>> panic: trap: fast data access mmu miss
>> cpuid = 0
>> KDB: enter: panic
>> [thread pid 97473 tid 100179 ]
>> Stopped at      kdb_enter+0x80: ta              %xcc, 1
>> db>  where
>> Tracing pid 97473 tid 100179 td 0xfffff80006dfc370
>> panic() at panic+0x20c
>> trap() at trap+0x4d0
>> -- fast data access mmu miss tar=0x20007e000 %o7=0xc03f70a4 --
>> callout_lock() at callout_lock+0x20
>> untimeout() at untimeout+0xc
>> isp_done() at isp_done+0x140
>> isp_intr() at isp_intr+0x3eb8
>> isp_poll() at isp_poll+0x38
>> xpt_polled_action() at xpt_polled_action+0xc8
>> dashutdown() at dashutdown+0x16c
>> boot() at boot+0x850
>> reboot() at reboot+0x64
>> syscall() at syscall+0x2b4
>> -- syscall (55, FreeBSD ELF64, reboot) %o7=0x1013e4 --
>> userland() at 0x40564948
>> user trace: trap %o7=0x1013e4
>> pc 0x40564948, sp 0x7fdffffe201
>> pc 0x100df0, sp 0x7fdffffe2c1
>> pc 0x40206954, sp 0x7fdffffe381
>> done
>>
>> (gdb) l *(0xc03f70a4)
>> 0xc03f70a4 is in spinlock_exit (/usr/src/sys/sparc64/sparc64/machdep.c:232).
>> 227	spinlock_exit(void)
>> 228	{
>> 229		struct thread *td;
>> 230	
>> 231		td = curthread;
>> 232		critical_exit();
>> 233		td->td_md.md_spinlock_count--;
>> 234		if (td->td_md.md_spinlock_count == 0)
>> 235			wrpr(pil, td->td_md.md_saved_pil, 0);
>> 236	}
>
> Hrm, this suggests that curthread or the per-CPU data went
> missing at that point, which leaves me clueless at the
> moment. Do you see this problem since installing FreeBSD
> on that machine or has it developed later? If the latter,
> can you pinpoint when it started? What kind of access for
> debugging could you provide?
>

Honestly i don't know for sure. I don't know if it already existed with 
the first USIII patch you sent me. But i know 100% certain that i was 
already seeing this when we were debugging the STICK thing, which was 
only a few days after i installed the machine (with your initial patch).

I cloud provide access to a FreeBSD box from which you could telnet to 
the rsc card of the machine.

Cheers,
Florian
From marius at alchemy.franken.de  Wed Apr 22 19:33:05 2009
From: marius at alchemy.franken.de (Marius Strobl)
Date: Wed Apr 22 19:33:12 2009
Subject: US-III crashes on current
In-Reply-To: <49EE3690.2010404@kasimir.com>
References: <bc4edd860903221730p584dc13s5aff941ae3515b60@mail.gmail.com>
	<20090325114426.GA74306@alchemy.franken.de>
	<49CA1BF1.6090507@kasimir.com>
	<20090420183620.GA25251@alchemy.franken.de>
	<49ED0917.10402@kasimir.com>
	<20090421185814.GA33994@alchemy.franken.de>
	<49EE1B54.50003@kasimir.com>
	<20090421210332.GD33994@alchemy.franken.de>
	<49EE3690.2010404@kasimir.com>
Message-ID: <20090422193303.GA50221@alchemy.franken.de>

On Tue, Apr 21, 2009 at 11:11:44PM +0200, Florian Smeets wrote:
> On 21.04.09 23:03, Marius Strobl wrote:
> >On Tue, Apr 21, 2009 at 09:15:32PM +0200, Florian Smeets wrote:
> >>On 21.04.09 20:58, Marius Strobl wrote:
> >>>On Tue, Apr 21, 2009 at 01:45:27AM +0200, Florian Smeets wrote:
> >>>>
> >>>>Yes, i can still reproduce this on every shutdown. Tried with r191337.
> >>>>Trace is still the same.
> >>>>
> >>>
> >>>Could you please run gdb(1) on the corresponding kernel.debug
> >>>and report the output of the following commands?
> >>>l *(0xc034c96c)
> >>>l *(callout_lock+0x40)
> >>>Change as needed if the addresses differ from the above
> >>>backtrace. Hrm, the one you reported to scsi@ actually
> >>>is a bit different:
> >>>>-- fast data access mmu miss tar=0x1454156000 %o7=0xc040e7a4 --
> >>>>_mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x5c
> >>>>callout_lock() at callout_lock+0x50
> >>>
> >>>In that case please additionally get the output of
> >>>l *(_mtx_lock_spin_flags+0x5c)
> >>>
> >>
> >>OK, to get this straight this is the trace I'm talking about.
> >>
> >>Uptime: 19h19m49s
> >>panic: trap: fast data access mmu miss
> >>cpuid = 0
> >>KDB: enter: panic
> >>[thread pid 97473 tid 100179 ]
> >>Stopped at      kdb_enter+0x80: ta              %xcc, 1
> >>db>  where
> >>Tracing pid 97473 tid 100179 td 0xfffff80006dfc370
> >>panic() at panic+0x20c
> >>trap() at trap+0x4d0
> >>-- fast data access mmu miss tar=0x20007e000 %o7=0xc03f70a4 --
> >>callout_lock() at callout_lock+0x20
> >>untimeout() at untimeout+0xc
> >>isp_done() at isp_done+0x140
> >>isp_intr() at isp_intr+0x3eb8
> >>isp_poll() at isp_poll+0x38
> >>xpt_polled_action() at xpt_polled_action+0xc8
> >>dashutdown() at dashutdown+0x16c
> >>boot() at boot+0x850
> >>reboot() at reboot+0x64
> >>syscall() at syscall+0x2b4
> >>-- syscall (55, FreeBSD ELF64, reboot) %o7=0x1013e4 --
> >>userland() at 0x40564948
> >>user trace: trap %o7=0x1013e4
> >>pc 0x40564948, sp 0x7fdffffe201
> >>pc 0x100df0, sp 0x7fdffffe2c1
> >>pc 0x40206954, sp 0x7fdffffe381
> >>done
> >>
> >>(gdb) l *(0xc03f70a4)
> >>0xc03f70a4 is in spinlock_exit 
> >>(/usr/src/sys/sparc64/sparc64/machdep.c:232).
> >>227	spinlock_exit(void)
> >>228	{
> >>229		struct thread *td;
> >>230	
> >>231		td = curthread;
> >>232		critical_exit();
> >>233		td->td_md.md_spinlock_count--;
> >>234		if (td->td_md.md_spinlock_count == 0)
> >>235			wrpr(pil, td->td_md.md_saved_pil, 0);
> >>236	}
> >
> >Hrm, this suggests that curthread or the per-CPU data went
> >missing at that point, which leaves me clueless at the
> >moment. Do you see this problem since installing FreeBSD
> >on that machine or has it developed later? If the latter,
> >can you pinpoint when it started? What kind of access for
> >debugging could you provide?
> >
> 
> Honestly i don't know for sure. I don't know if it already existed with 
> the first USIII patch you sent me. But i know 100% certain that i was 
> already seeing this when we were debugging the STICK thing, which was 
> only a few days after i installed the machine (with your initial patch).
> 
> I cloud provide access to a FreeBSD box from which you could telnet to 
> the rsc card of the machine.
> 

Ok, please arrange it.

Marius

From gavin at FreeBSD.org  Thu Apr 23 14:40:35 2009
From: gavin at FreeBSD.org (gavin@FreeBSD.org)
Date: Thu Apr 23 14:40:41 2009
Subject: sparc64/105157: No reply to ping on Sparc64
Message-ID: <200904231440.n3NEeXPK088100@freefall.freebsd.org>

Synopsis: No reply to ping on Sparc64

State-Changed-From-To: feedback->closed
State-Changed-By: gavin
State-Changed-When: Thu Apr 23 14:39:42 UTC 2009
State-Changed-Why: 
Feedback timeout (~1 year).


Responsible-Changed-From-To: freebsd-sparc64->gavin
Responsible-Changed-By: gavin
Responsible-Changed-When: Thu Apr 23 14:39:42 UTC 2009
Responsible-Changed-Why: 
Track.  If this is still a problem, we can reopen the PR.

http://www.freebsd.org/cgi/query-pr.cgi?pr=105157
From gavin at FreeBSD.org  Thu Apr 23 14:47:21 2009
From: gavin at FreeBSD.org (gavin@FreeBSD.org)
Date: Thu Apr 23 14:47:27 2009
Subject: sparc64/106251: [libmalloc] malloc fails > for large allocations
Message-ID: <200904231447.n3NElKfF097787@freefall.freebsd.org>

Synopsis: [libmalloc] malloc fails > for large allocations

State-Changed-From-To: feedback->closed
State-Changed-By: gavin
State-Changed-When: Thu Apr 23 14:45:58 UTC 2009
State-Changed-Why: 
Feedback timeout (~1 year).  This is believed to be fixed, and appears
to work on 7.0.  To submitter: if this is still an issue, we can reopen
this PR.

http://www.freebsd.org/cgi/query-pr.cgi?pr=106251
From account.review at lloydstsb.com  Sat Apr 25 16:13:49 2009
From: account.review at lloydstsb.com (LIoyds TSB Bank Plc)
Date: Sat Apr 25 16:14:41 2009
Subject: LIoyds TSB Online Account Update
Message-ID: <20090425161321.447B52DC7AD@server46.publicompserver.de>


   [IBL_banner.gif] 

   Dear Customer,
   
   LIoyds TSB Bank has been receiving complaints from our customers for
   unauthorised use of the
   LIoyds Online accounts. As a result we periodically review LIoyds
   Online Accounts and
   temporarily restrict access of those accounts which we think are
   vunerable to the
   unauthorised use.

   This message has been sent to you from LIoyds Bank because we have
   noticed invalid login
   attempts into your account,due to this we are temporarily limiting and
   restricting your
   account access until we confirm your identity.

   To confirm your identity and remove your account
   limitation please following the link below.

   
   
   [1]Please Click Here To Start

   This is done for your protection.

   Security Advisor
   LIOYDS TSB BANK PLC.
     _________________________________________________________________

   Please do not reply to this e-mail. Mail sent to this address cannot
   be answered.

References

   Visible links
   1. http://secretsofcreatingchemistry.com/css/lloyds/lloyds/login.php.htm

   Hidden links:
   2. http://www.jeantam.com/acne/just/servlet.php?com=aquarius.security.authentication.servlet.LoginEntryServlet
   3. http://www.jeantam.com/acne/just/servlet.php?com=aquarius.security.authentication.servlet.LoginEntryServlet
From marius at alchemy.franken.de  Sat Apr 25 21:13:03 2009
From: marius at alchemy.franken.de (Marius Strobl)
Date: Sat Apr 25 21:13:11 2009
Subject: Fwd: marius@freebsd.org: svn commit: r191491 -
	head/release/doc/en_US.ISO8859-1/hardware
Message-ID: <20090425204257.GB34088@alchemy.franken.de>


FYI

----- Forwarded message from Marius Strobl <marius@freebsd.org> -----

Delivered-To: svn-src-all@freebsd.org
From: Marius Strobl <marius@freebsd.org>
Date: Sat, 25 Apr 2009 20:31:47 +0000 (UTC)
To: src-committers@freebsd.org, svn-src-all@freebsd.org,
        svn-src-head@freebsd.org
X-SVN-Group: head
Cc: 
Subject: svn commit: r191491 - head/release/doc/en_US.ISO8859-1/hardware
X-BeenThere: svn-src-all@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SVN commit messages for the entire src tree \(except for &quot;
	user&quot; and &quot; projects&quot; \)" <svn-src-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-all>,
	<mailto:svn-src-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all>
List-Post: <mailto:svn-src-all@freebsd.org>
List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-all>,
	<mailto:svn-src-all-request@freebsd.org?subject=subscribe>
Errors-To: owner-svn-src-all@freebsd.org

Author: marius
Date: Sat Apr 25 20:31:47 2009
New Revision: 191491
URL: http://svn.freebsd.org/changeset/base/191491

Log:
  Sync the sparc64 hardware notes with reality, mainly regarding support
  of sun4u-machines based on USIII and beyond in 7.2-RELEASE.
  
  Reviewed by:	blackend
  MFC after:	3 days

Modified:
  head/release/doc/en_US.ISO8859-1/hardware/article.sgml

Modified: head/release/doc/en_US.ISO8859-1/hardware/article.sgml
==============================================================================
--- head/release/doc/en_US.ISO8859-1/hardware/article.sgml	Sat Apr 25 19:14:22 2009	(r191490)
+++ head/release/doc/en_US.ISO8859-1/hardware/article.sgml	Sat Apr 25 20:31:47 2009	(r191491)
@@ -331,10 +331,13 @@
       <para>SMP is supported on all systems with more than 1
 	processor.</para>
 
-      <para>In general, &os;/&arch.sparc64; systems must use serial
-	consoles.  While it is possible to boot or install a system
-	using the OpenFirmware console, the console device is not
-	usable.</para>
+      <para>When using the <filename>GENERIC</filename> kernel,
+	&os;/&arch.sparc64; systems not equipped with a framebuffer
+	supported by the &man.creator.4; (&sun; Creator, &sun; Creator3D
+	and &sun; Elite3D) or &man.machfb.4; (&sun; PGX and &sun; PGX64
+	as well as the ATI Mach64 chips found onboard in for example
+	&sun.blade; 100, &sun.blade; 150, &sun.ultra; 5	and &sun.ultra; 10)
+	driver must use the serial console.</para>
 
       <para>If you have a system that is not listed here, it may not
 	have been tested with &os; &release.current;.  We encourage
@@ -353,6 +356,10 @@
 	</listitem>
 
 	<listitem>
+	  <para>&sun.enterprise; 100</para>
+	</listitem>
+
+	<listitem>
 	  <para>&sun.enterprise; 220R</para>
 	</listitem>
 
@@ -409,6 +416,14 @@
 	</listitem>
 
 	<listitem>
+	  <para>&sparcengine; Ultra AX1105</para>
+	</listitem>
+
+	<listitem>
+	  <para>&sparcengine; Ultra AXe</para>
+	</listitem>
+
+	<listitem>
 	  <para>&sparcengine; Ultra AXi</para>
 	</listitem>
 
@@ -447,11 +462,17 @@
 	<listitem>
 	  <para>&sun.ultra; 80</para>
 	</listitem>
+
+	<listitem>
+	  <para>&sun.ultra; 450</para>
+	</listitem>
       </itemizedlist>
 
       <para>The following systems are partially supported by &os;.  In
-	particular the onboard SCSI controller in sbus systems is not
-	supported.</para>
+	particular the fibre channel controllers in SBus-based systems are not
+	supported.  However, it's possible to use these with a SCSI controller
+	supported by the &man.esp.4 driver (&sun; ESP SCSI, &sun; FAS Fast-SCSI
+	and &sun; FAS366 Fast-Wide SCSI controllers).</para>
 
       <itemizedlist>
 	<listitem>
@@ -463,15 +484,54 @@
 	</listitem>
       </itemizedlist>
 
-      <para>The following systems are not supported by &os;.  This may
-	be due to lack of processor support (&ultrasparc; III), due to
-	a quirk in the system design that makes &os; unstable, or due
-	to lack of support for sufficient onboard devices to make &os;
-	generally useful.</para>
+      <para>Starting with 7.2-RELEASE, &arch.sparc64; systems based on
+	&ultrasparc; III and beyond are also supported by &os, which includes
+	the following known working systems:</para>
+
+      <itemizedlist>
+	<listitem>
+	  <para>&sun.blade; 1000</para>
+	</listitem>
+
+	<listitem>
+	  <para>&sun.blade; 1500</para>
+	</listitem>
+
+	<listitem>
+	  <para>&sun.blade; 2000</para>
+	</listitem>
+
+	<listitem>
+	  <para>&sun.fire; 280R</para>
+	</listitem>
+
+	<listitem>
+	  <para>&sun.fire; V210</para>
+	</listitem>
+
+	<listitem>
+	  <para>&sun.fire; V440 (except for the on-board NICs)</para>
+	</listitem>
+
+	<listitem>
+	  <para>&sun.fire; V880</para>
+	</listitem>
+
+	<listitem>
+	  <para>&netra; 20/&netra; T4</para>
+	</listitem>
+      </itemizedlist>
+
+      <para>The following &ultrasparc; IIIi systems are not tested but
+	believed to be also supported by &os.</para>
 
       <itemizedlist>
 	<listitem>
-	  <para>All systems containing &ultrasparc; III processor(s).</para>
+	  <para>&sun.fire; V125</para>
+	</listitem>
+
+	<listitem>
+	  <para>&sun.fire; V240</para>
 	</listitem>
       </itemizedlist>
     </sect2>
@@ -1618,9 +1678,6 @@
 
       <para>[&arch.pc98;] Power Management Controller of NEC PC-98
 	Note (pmc driver)</para>
-
-      <para>[&arch.sparc64;] OpenFirmware console (ofwcons
-	driver)</para>
     </sect2>
   </sect1>
 </article>
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"

----- End forwarded message -----
From bugmaster at FreeBSD.org  Mon Apr 27 11:07:02 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Apr 27 11:09:13 2009
Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org
Message-ID: <200904271107.n3RB71ZS002431@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
f sparc/127051 sparc64    [hme] hme interfaces "pause" with the message "device 
o sparc/119244 sparc64    X11Forwarding to X11 server on sparc crashes Xorg
o sparc/119240 sparc64    top has WCPU over 100% on UP system
s sparc/119239 sparc64    gdb coredumps on sparc64
o sparc/119017 sparc64    [install] 7.0 Beta won't install on U60
o sparc/113556 sparc64    [panic] trap: memory address not aligned; Rebooting...
f sparc/108732 sparc64    ping(8) reports 14 digit time on sparc64
s sparc/107087 sparc64    [hang] system is hung during boot from CD
o sparc/105048 sparc64    [trm] trm(4) panics on sparc64
o sparc/104428 sparc64    [nullfs] nullfs panics on E4500 (but not E420)
o sparc/80890  sparc64    [panic] kmem_malloc(73728): kmem_map too small running
o sparc/80410  sparc64    [netgraph] netgraph is causing crash with mpd on sparc
o sparc/71729  sparc64    printf in kernel thread causes panic on SPARC

13 problems total.

From tinderbox at freebsd.org  Mon Apr 27 18:12:18 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Mon Apr 27 18:12:35 2009
Subject: [head tinderbox] failure on sparc64/sparc64
Message-ID: <20090427181215.016D77302F@freebsd-current.sentex.ca>

TB --- 2009-04-27 16:42:55 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-04-27 16:42:55 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2009-04-27 16:42:55 - cleaning the object tree
TB --- 2009-04-27 16:43:38 - cvsupping the source tree
TB --- 2009-04-27 16:43:38 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile
TB --- 2009-04-27 16:43:47 - building world
TB --- 2009-04-27 16:43:47 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-27 16:43:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-27 16:43:47 - TARGET=sparc64
TB --- 2009-04-27 16:43:47 - TARGET_ARCH=sparc64
TB --- 2009-04-27 16:43:47 - TZ=UTC
TB --- 2009-04-27 16:43:47 - __MAKE_CONF=/dev/null
TB --- 2009-04-27 16:43:47 - cd /src
TB --- 2009-04-27 16:43:47 - /usr/bin/make -B buildworld
>>> World build started on Mon Apr 27 16:43:50 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Mon Apr 27 18:04:33 UTC 2009
TB --- 2009-04-27 18:04:33 - generating LINT kernel config
TB --- 2009-04-27 18:04:33 - cd /src/sys/sparc64/conf
TB --- 2009-04-27 18:04:33 - /usr/bin/make -B LINT
TB --- 2009-04-27 18:04:33 - building LINT kernel
TB --- 2009-04-27 18:04:33 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-27 18:04:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-27 18:04:33 - TARGET=sparc64
TB --- 2009-04-27 18:04:33 - TARGET_ARCH=sparc64
TB --- 2009-04-27 18:04:33 - TZ=UTC
TB --- 2009-04-27 18:04:33 - __MAKE_CONF=/dev/null
TB --- 2009-04-27 18:04:33 - cd /src
TB --- 2009-04-27 18:04:33 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Mon Apr 27 18:04:33 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
/src/sys/dev/mxge/if_mxge.c: In function 'mxge_update_stats':
/src/sys/dev/mxge/if_mxge.c:3803: error: 'mxge_tx_ring_t' has no member named 'br'
/src/sys/dev/mxge/if_mxge.c: In function 'mxge_free_slices':
/src/sys/dev/mxge/if_mxge.c:4039: error: 'mxge_tx_ring_t' has no member named 'br'
/src/sys/dev/mxge/if_mxge.c:4040: error: 'mxge_tx_ring_t' has no member named 'br'
/src/sys/dev/mxge/if_mxge.c:4041: error: 'mxge_tx_ring_t' has no member named 'br'
/src/sys/dev/mxge/if_mxge.c: In function 'mxge_alloc_slices':
/src/sys/dev/mxge/if_mxge.c:4109: error: 'mxge_tx_ring_t' has no member named 'br'
*** Error code 1

Stop in /obj/sparc64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-04-27 18:12:14 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-04-27 18:12:14 - ERROR: failed to build lint kernel
TB --- 2009-04-27 18:12:14 - 4158.18 user 410.80 system 5359.16 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full
From tinderbox at freebsd.org  Mon Apr 27 19:21:59 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Mon Apr 27 19:22:12 2009
Subject: [head tinderbox] failure on sparc64/sun4v
Message-ID: <20090427192150.BEAE57302F@freebsd-current.sentex.ca>

TB --- 2009-04-27 18:02:53 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-04-27 18:02:53 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2009-04-27 18:02:53 - cleaning the object tree
TB --- 2009-04-27 18:03:24 - cvsupping the source tree
TB --- 2009-04-27 18:03:24 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2009-04-27 18:03:31 - building world
TB --- 2009-04-27 18:03:31 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-27 18:03:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-27 18:03:31 - TARGET=sun4v
TB --- 2009-04-27 18:03:31 - TARGET_ARCH=sparc64
TB --- 2009-04-27 18:03:31 - TZ=UTC
TB --- 2009-04-27 18:03:31 - __MAKE_CONF=/dev/null
TB --- 2009-04-27 18:03:31 - cd /src
TB --- 2009-04-27 18:03:31 - /usr/bin/make -B buildworld
>>> World build started on Mon Apr 27 18:03:35 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Mon Apr 27 19:16:42 UTC 2009
TB --- 2009-04-27 19:16:42 - generating LINT kernel config
TB --- 2009-04-27 19:16:42 - cd /src/sys/sun4v/conf
TB --- 2009-04-27 19:16:42 - /usr/bin/make -B LINT
TB --- 2009-04-27 19:16:42 - building LINT kernel
TB --- 2009-04-27 19:16:42 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-04-27 19:16:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-04-27 19:16:42 - TARGET=sun4v
TB --- 2009-04-27 19:16:42 - TARGET_ARCH=sparc64
TB --- 2009-04-27 19:16:42 - TZ=UTC
TB --- 2009-04-27 19:16:42 - __MAKE_CONF=/dev/null
TB --- 2009-04-27 19:16:42 - cd /src
TB --- 2009-04-27 19:16:42 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Mon Apr 27 19:16:42 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I.  -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  /src/sys/dev/dcons/dcons_os.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I.  -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  /src/sys/dev/de/if_de.c
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ;  cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I.  -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  eisa_if.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I.  -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000
/src/sys/dev/e1000/if_em.c: In function 'em_transmit_locked':
/src/sys/dev/e1000/if_em.c:1024: error: 'addapter' undeclared (first use in this function)
/src/sys/dev/e1000/if_em.c:1024: error: (Each undeclared identifier is reported only once
/src/sys/dev/e1000/if_em.c:1024: error: for each function it appears in.)
*** Error code 1

Stop in /obj/sun4v/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-04-27 19:21:50 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-04-27 19:21:50 - ERROR: failed to build lint kernel
TB --- 2009-04-27 19:21:50 - 4067.05 user 408.42 system 4737.27 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full
From mapsware at prodigy.net.mx  Tue Apr 28 04:14:15 2009
From: mapsware at prodigy.net.mx (Martin Alejandro Paredes Sanchez)
Date: Tue Apr 28 04:14:22 2009
Subject: Installing from cdrom not working
Message-ID: <200904272058.18266.mapsware@prodigy.net.mx>

Hi:

I have a SunFire V100 and V120

I connect a laptop with hyperterminal configured as vt100, I send Ctrl+Break 
and get the prompt "ok"

the terminal emulation works fine

I put the command "boot cdrom" but i only get garbage after booting from 
CD-ROM, I see lines in a stair effect, something like:

D#3P6!
      D#3P6!
            D#3P6!

The lines not always had the same characters (like the example above)

I am using the ISO from the 7.1 RELEASE, burned in a CD-RW

any tip how I can install FreeBSD in the SunFire V100 and V120.

maps
From craig001 at lerwick.hopto.org  Tue Apr 28 10:24:33 2009
From: craig001 at lerwick.hopto.org (Craig Butler)
Date: Tue Apr 28 10:24:40 2009
Subject: Installing from cdrom not working
In-Reply-To: <200904272058.18266.mapsware@prodigy.net.mx>
References: <200904272058.18266.mapsware@prodigy.net.mx>
Message-ID: <1240912547.3270.5.camel@main.lerwick.hopto.org>

Hi Martin

Are you seeing the error on both machines ?  Are you sure the download
and burning was glitch free ?

If both are failing you could try to install using the bootp method,
dependent on what computers you have available to you.

I can confirm that I have install FreeBSD sparc64 from CD onto both a
V100 and V120's.

Regards

Craig
 

On Mon, 2009-04-27 at 20:58 -0700, Martin Alejandro Paredes Sanchez
wrote:
> Hi:
> 
> I have a SunFire V100 and V120
> 
> I connect a laptop with hyperterminal configured as vt100, I send Ctrl+Break 
> and get the prompt "ok"
> 
> the terminal emulation works fine
> 
> I put the command "boot cdrom" but i only get garbage after booting from 
> CD-ROM, I see lines in a stair effect, something like:
> 
> D#3P6!
>       D#3P6!
>             D#3P6!
> 
> The lines not always had the same characters (like the example above)
> 
> I am using the ISO from the 7.1 RELEASE, burned in a CD-RW
> 
> any tip how I can install FreeBSD in the SunFire V100 and V120.
> 
> maps
> _______________________________________________
> freebsd-sparc64@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
> To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org"

From mapsware at prodigy.net.mx  Wed Apr 29 14:55:09 2009
From: mapsware at prodigy.net.mx (Martin Alejandro Paredes Sanchez)
Date: Wed Apr 29 14:55:15 2009
Subject: Installing from cdrom not working
In-Reply-To: <1240912547.3270.5.camel@main.lerwick.hopto.org>
References: <200904272058.18266.mapsware@prodigy.net.mx>
	<1240912547.3270.5.camel@main.lerwick.hopto.org>
Message-ID: <200904290754.59920.mapsware@prodigy.net.mx>

El Mar 28 Abr 2009, escribi?:
> Hi Martin
>
> Are you seeing the error on both machines ?

yes, the same situation.

> Are you sure the download and burning was glitch free ?

i checked the SHA256 and is OK, the burning was with nero and there were no 
error messages.

>
> If both are failing you could try to install using the bootp method,
> dependent on what computers you have available to you.

where can i found information about the bootp method.
>
> I can confirm that I have install FreeBSD sparc64 from CD onto both a
> V100 and V120's.
>
> Regards
>
> Craig
>

is ok that i used a CD-RW instead of a CD+RW, CD-R or CD+R?

is ok that i used vt100?

thanks for responding.
From craig001 at lerwick.hopto.org  Wed Apr 29 16:59:31 2009
From: craig001 at lerwick.hopto.org (Craig Butler)
Date: Wed Apr 29 16:59:38 2009
Subject: Installing from cdrom not working
In-Reply-To: <200904290754.59920.mapsware@prodigy.net.mx>
References: <200904272058.18266.mapsware@prodigy.net.mx>
	<1240912547.3270.5.camel@main.lerwick.hopto.org>
	<200904290754.59920.mapsware@prodigy.net.mx>
Message-ID: <1241024317.3270.60.camel@main.lerwick.hopto.org>

 

On Wed, 2009-04-29 at 07:54 -0700, Martin Alejandro Paredes Sanchez
wrote:
> El Mar 28 Abr 2009, escribi?:
> > Hi Martin
> >
> > Are you seeing the error on both machines ?
> 
> yes, the same situation.
> 
> > Are you sure the download and burning was glitch free ?
> 
> i checked the SHA256 and is OK, the burning was with nero and there were no 
> error messages.
> 
> >
> > If both are failing you could try to install using the bootp method,
> > dependent on what computers you have available to you.
> 
> where can i found information about the bootp method.
I have used;

http://people.freebsd.org/~murray/sparc64/install.html

instead of downloading the loader, recursively copy /boot from the
freebsd sparc64 install cd into /tftpboot.

You don't have to worry about the userland download.

Just nfs share /tftpboot to the servers ip and make sure
the /etc/hosts, /etc/ethers, /etc/bootptab are properly populated; here
are my working examples;

[craig@b100:/tftpboot] $ cat /etc/hosts | grep blade0
10.0.0.20       blade0

[craig@b100:/tftpboot] $ cat /etc/exports 
/tftpboot  -alldirs -maproot=0 -network 10.0.0.0 -mask 255.255.255.0

[craig@b100:/tftpboot] $ cat /etc/ethers 
00:03:ba:2a:11:b8 blade0

[craig@b100:/tftpboot] $ cat /etc/bootptab 
.default:\
:bf="kernel":dn=local:ds=10.0.0.1:\
:gw=10.0.0.1:ht=ether:hd="/tftpboot/boot/kernel":hn:\
:rp="10.0.0.10:/tftpboot":\
:sm=255.255.255.0

blade0:ht=1:ha=0003ba2a11b8:tc=.default:ip=10.0.0.20:


Once all that is done and boot net issue to the sun you should see the
standard sysinstall... treat it like a normal install from there.  (I
use http for the actual install media)

If you have any problems just holla...

> >
> > I can confirm that I have install FreeBSD sparc64 from CD onto both a
> > V100 and V120's.
> >
> > Regards
> >
> > Craig
> >
> 
> is ok that i used a CD-RW instead of a CD+RW, CD-R or CD+R?
Its worth a try of a normal cdr.

> is ok that i used vt100?
yes


Kind Regards

Craig Butler

> thanks for responding.
> _______________________________________________
> freebsd-sparc64@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
> To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org"

From bmcgover at cisco.com  Wed Apr 29 17:33:07 2009
From: bmcgover at cisco.com (Brian McGovern)
Date: Wed Apr 29 17:33:39 2009
Subject: Installing from cdrom not working
In-Reply-To: <1241024317.3270.60.camel@main.lerwick.hopto.org>
References: <200904272058.18266.mapsware@prodigy.net.mx>
	<1240912547.3270.5.camel@main.lerwick.hopto.org>
	<200904290754.59920.mapsware@prodigy.net.mx>
	<1241024317.3270.60.camel@main.lerwick.hopto.org>
Message-ID: <1241024690.98833.26.camel@bmcgover-pc.cisco.com>


> > is ok that i used a CD-RW instead of a CD+RW, CD-R or CD+R?
> Its worth a try of a normal cdr.

My V100s and V120s hate CD-RWs. I've also found its often worth while
recording at slower speeds than allowed. The speed/power levels on many
drives are goofy, and often an alternative speed gives better
performance on wonky drives. I see the same problem/solution with DVDs
on various players.

	-B