From craig001 at lerwick.hopto.org Sat Nov 1 14:59:11 2008 From: craig001 at lerwick.hopto.org (Craig Butler) Date: Sat Nov 1 14:59:17 2008 Subject: Free Ultra2 in Silicon Valley, USA In-Reply-To: <20081031131827.GA9613@soaustin.net> References: <20081031124442.GB9102@soaustin.net> <183638.12752.qm@web56802.mail.re3.yahoo.com> <20081031131827.GA9613@soaustin.net> Message-ID: <1225576740.92270.2.camel@main.lerwick.hopto.org> On Fri, 2008-10-31 at 08:18 -0500, Mark Linimon wrote: > On Fri, Oct 31, 2008 at 06:02:28AM -0700, mdh wrote: > > A dual CPU Ultra2 is going to be a lot more powerful than an Ultra5. > > Hmm, ok, didn't know that. If no-one else claims it first, perhaps > I can claim it for the build cluster and pull one of the Ultra 5s. > I intend to be out in .ca.us for meetBSD. > > > E4500's can be relatively beefy. > > We could have gotten our hands on some more of them in .ca.us but the > problem is who wants to pay for the power :-( Really, their time has > come and gone. > > > OK, this is probably way over my head, but I'll bite - what exactly > > happens if you don't breakpoint through it? > > http://people.freebsd.org/~linimon/studies/dmesgs/dmesg.netra_1_t200.txt . > > This appears to be some kind of race condition; my guess from fooling > around with it is that some interrupt is enabled, and then fires, before > the setup to handle it is finished. (Note that the same kernel runs > fine on the 100s). By stepping through it, you can see it fail at > different locations; without stepping through it, it is always at > the same. > > Unfortunately my notes are at home and that machine is unreachable ATM. > > mcl > _______________________________________________ > 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" Guys, I be prepared to pay for delivery to the UK (as long as its reasonable) and can put it in me rack next to the other build servers if you like. How heavy is an ultra 2 ? Regards Craig B From craig001 at lerwick.hopto.org Sat Nov 1 15:03:48 2008 From: craig001 at lerwick.hopto.org (Craig Butler) Date: Sat Nov 1 15:04:04 2008 Subject: Free Ultra2 in Silicon Valley, USA In-Reply-To: <20081031043122.GA50470@dragon.genyosha.net> References: <20081031043122.GA50470@dragon.genyosha.net> Message-ID: <1225577018.92270.6.camel@main.lerwick.hopto.org> On Thu, 2008-10-30 at 21:31 -0700, Steve Rikli wrote: > I've got an Ultra2 to make available to the project. > > Short config: Ultra2 2x400MHz, 2GB RAM, 2x72GB disk, CDROM > SBus: ge GigE, f/w/d SCSI, hme+SCSI, serial adapter (501-1931) > > Full 'dmesg' is attached. > > The hardware is pretty clean and in good shape -- I adopted it from > a friend who moved. I've installed 6.2 on it to clean the disks and > verify the hardware. > > The Ultra2 is located in Sunnyvale, California, USA. I estimate it > would cost around US$35-40 to ship it inside the USA, but I only ask > for exact shipping in return -- if it's less, so much the better ;-) > and local pickups are also welcome. > > Please give this nice ole box a good FreeBSD home! > > Cheers, > sr. > _______________________________________________ > 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" Stevie, Could you price up delivery to Scotland please, preferably DHL as they have an in house custom clearance house. Thanks Craig Butler From sr at genyosha.net Sat Nov 1 15:49:22 2008 From: sr at genyosha.net (Steve Rikli) Date: Sat Nov 1 15:49:28 2008 Subject: Free Ultra2 in Silicon Valley, USA In-Reply-To: <1225576740.92270.2.camel@main.lerwick.hopto.org> References: <20081031124442.GB9102@soaustin.net> <183638.12752.qm@web56802.mail.re3.yahoo.com> <20081031131827.GA9613@soaustin.net> <1225576740.92270.2.camel@main.lerwick.hopto.org> Message-ID: <20081101224921.GA51647@dragon.genyosha.net> On Sat, Nov 01, 2008 at 09:59:00PM +0000, Craig Butler wrote: > On Fri, 2008-10-31 at 08:18 -0500, Mark Linimon wrote: > > On Fri, Oct 31, 2008 at 06:02:28AM -0700, mdh wrote: > > > A dual CPU Ultra2 is going to be a lot more powerful than an Ultra5. > > > > Hmm, ok, didn't know that. If no-one else claims it first, perhaps > > I can claim it for the build cluster and pull one of the Ultra 5s. > > I intend to be out in .ca.us for meetBSD. > > > > > E4500's can be relatively beefy. > > > > We could have gotten our hands on some more of them in .ca.us but the > > problem is who wants to pay for the power :-( Really, their time has > > come and gone. > > ... > > Guys, > > I be prepared to pay for delivery to the UK (as long as its reasonable) > and can put it in me rack next to the other build servers if you like. > > How heavy is an ultra 2 ? I shipped one similar to this recently via UPS -- the box weighs a little over 41 lbs. and measures 23x23x10". Because it only travelled within California, USA it was about $20 to ship. We looked into shipping one overseas but it was too costly -- the US Postal Service wouldn't take it (too large) and UPS et al would have charged well over $100. If you'd like to try arranging something else feel free to contact me off-list -- I'm happy to give this gear to FreeBSD if we can find a way. Cheers, sr. From tinderbox at freebsd.org Sun Nov 2 12:19:00 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Nov 2 12:19:11 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081102201856.1C6FF73039@freebsd-current.sentex.ca> TB --- 2008-11-02 19:09:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-11-02 19:09:11 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-02 19:09:11 - cleaning the object tree TB --- 2008-11-02 19:09:41 - cvsupping the source tree TB --- 2008-11-02 19:09:41 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-02 19:09:48 - building world (CFLAGS=-O -pipe) TB --- 2008-11-02 19:09:48 - cd /src TB --- 2008-11-02 19:09:48 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 2 19:09:50 UTC 2008 >>> 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 Sun Nov 2 20:18:55 UTC 2008 TB --- 2008-11-02 20:18:55 - generating LINT kernel config TB --- 2008-11-02 20:18:55 - cd /src/sys/sparc64/conf TB --- 2008-11-02 20:18:55 - /usr/bin/make -B LINT TB --- 2008-11-02 20:18:55 - building LINT kernel (COPTFLAGS=) TB --- 2008-11-02 20:18:55 - cd /src TB --- 2008-11-02 20:18:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 2 20:18:55 UTC 2008 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /src/sys/sparc64/conf; PATH=/obj/sparc64/src/tmp/legacy/usr/sbin:/obj/sparc64/src/tmp/legacy/usr/bin:/obj/sparc64/src/tmp/legacy/usr/games:/obj/sparc64/src/tmp/usr/sbin:/obj/sparc64/src/tmp/usr/bin:/obj/sparc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/sparc64/src/sys/LINT /src/sys/sparc64/conf/LINT WARNING: duplicate option `GEOM_BSD' encountered. WARNING: duplicate option `GEOM_SUNLABEL' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: duplicate option `SUNKBD_EMULATE_ATKBD' encountered. /src/sys/sparc64/conf/LINT: unknown option "RL_TWISTER_ENABLE" *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-02 20:18:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-02 20:18:55 - ERROR: failed to build lint kernel TB --- 2008-11-02 20:18:55 - tinderbox aborted TB --- 2970.84 user 364.32 system 4184.88 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Sun Nov 2 12:32:17 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Nov 2 12:32:35 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20081102203215.60C4173039@freebsd-current.sentex.ca> TB --- 2008-11-02 19:25:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-11-02 19:25:56 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-11-02 19:25:56 - cleaning the object tree TB --- 2008-11-02 19:26:22 - cvsupping the source tree TB --- 2008-11-02 19:26:22 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-11-02 19:26:30 - building world (CFLAGS=-O -pipe) TB --- 2008-11-02 19:26:30 - cd /src TB --- 2008-11-02 19:26:30 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 2 19:26:31 UTC 2008 >>> 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 Sun Nov 2 20:32:15 UTC 2008 TB --- 2008-11-02 20:32:15 - generating LINT kernel config TB --- 2008-11-02 20:32:15 - cd /src/sys/sun4v/conf TB --- 2008-11-02 20:32:15 - /usr/bin/make -B LINT TB --- 2008-11-02 20:32:15 - building LINT kernel (COPTFLAGS=) TB --- 2008-11-02 20:32:15 - cd /src TB --- 2008-11-02 20:32:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 2 20:32:15 UTC 2008 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /src/sys/sun4v/conf; PATH=/obj/sun4v/src/tmp/legacy/usr/sbin:/obj/sun4v/src/tmp/legacy/usr/bin:/obj/sun4v/src/tmp/legacy/usr/games:/obj/sun4v/src/tmp/usr/sbin:/obj/sun4v/src/tmp/usr/bin:/obj/sun4v/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/sun4v/src/sys/LINT /src/sys/sun4v/conf/LINT WARNING: duplicate option `GEOM_BSD' encountered. WARNING: duplicate option `GEOM_SUNLABEL' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. /src/sys/sun4v/conf/LINT: unknown option "RL_TWISTER_ENABLE" *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-02 20:32:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-02 20:32:15 - ERROR: failed to build lint kernel TB --- 2008-11-02 20:32:15 - tinderbox aborted TB --- 2957.13 user 363.23 system 3978.42 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Sun Nov 2 19:00:20 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Nov 2 19:00:26 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081103030015.4D73273039@freebsd-current.sentex.ca> TB --- 2008-11-03 01:49:36 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-11-03 01:49:36 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-03 01:49:36 - cleaning the object tree TB --- 2008-11-03 01:49:58 - cvsupping the source tree TB --- 2008-11-03 01:49:58 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-03 01:50:04 - building world (CFLAGS=-O -pipe) TB --- 2008-11-03 01:50:04 - cd /src TB --- 2008-11-03 01:50:04 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 3 01:50:09 UTC 2008 >>> 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 Nov 3 03:00:13 UTC 2008 TB --- 2008-11-03 03:00:13 - generating LINT kernel config TB --- 2008-11-03 03:00:13 - cd /src/sys/sparc64/conf TB --- 2008-11-03 03:00:13 - /usr/bin/make -B LINT TB --- 2008-11-03 03:00:13 - building LINT kernel (COPTFLAGS=) TB --- 2008-11-03 03:00:13 - cd /src TB --- 2008-11-03 03:00:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Nov 3 03:00:13 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree [...] ===> aio (cleandir) rm -f export_syms aio.ko aio.kld vfs_aio.o opt_vfs_aio.h vnode_if.h vnode_if_newproto.h vnode_if_typedef.h rm -f @ machine rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> amr (cleandir) rm -f export_syms amr.ko amr.kld amr.o amr_pci.o amr_disk.o pci_if.h bus_if.h device_if.h ===> amr/amr_cam (clean) cd: can't cd to /src/sys/modules/amr/amr_cam *** Error code 2 Stop in /src/sys/modules/amr. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-03 03:00:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-03 03:00:15 - ERROR: failed to build lint kernel TB --- 2008-11-03 03:00:15 - tinderbox aborted TB --- 2972.62 user 362.02 system 4238.88 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Sun Nov 2 19:35:09 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Nov 2 19:35:16 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20081103033506.E3E2473039@freebsd-current.sentex.ca> TB --- 2008-11-03 02:33:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-11-03 02:33:11 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-11-03 02:33:11 - cleaning the object tree TB --- 2008-11-03 02:33:28 - cvsupping the source tree TB --- 2008-11-03 02:33:28 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-11-03 02:33:36 - building world (CFLAGS=-O -pipe) TB --- 2008-11-03 02:33:36 - cd /src TB --- 2008-11-03 02:33:36 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 3 02:33:38 UTC 2008 >>> 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 Nov 3 03:35:05 UTC 2008 TB --- 2008-11-03 03:35:05 - generating LINT kernel config TB --- 2008-11-03 03:35:05 - cd /src/sys/sun4v/conf TB --- 2008-11-03 03:35:05 - /usr/bin/make -B LINT TB --- 2008-11-03 03:35:05 - building LINT kernel (COPTFLAGS=) TB --- 2008-11-03 03:35:05 - cd /src TB --- 2008-11-03 03:35:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Nov 3 03:35:05 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree [...] ===> aio (cleandir) rm -f export_syms aio.ko aio.kld vfs_aio.o opt_vfs_aio.h vnode_if.h vnode_if_newproto.h vnode_if_typedef.h rm -f @ machine sparc64 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> amr (cleandir) rm -f export_syms amr.ko amr.kld amr.o amr_pci.o amr_disk.o pci_if.h bus_if.h device_if.h ===> amr/amr_cam (clean) cd: can't cd to /src/sys/modules/amr/amr_cam *** Error code 2 Stop in /src/sys/modules/amr. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-03 03:35:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-03 03:35:06 - ERROR: failed to build lint kernel TB --- 2008-11-03 03:35:06 - tinderbox aborted TB --- 2936.71 user 358.66 system 3715.55 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From bugmaster at FreeBSD.org Mon Nov 3 03:07:00 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 3 03:08:59 2008 Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org Message-ID: <200811031106.mA3B6xH3011044@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 7.0 Beta won't install on U60 o sparc/118932 sparc64 7.0-BETA4/sparc-64 kernel panic in rip_output o sparc/113556 sparc64 panic: trap: memory address not aligned; Rebooting... o sparc/109908 sparc64 apache22 mod_perl issue on sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 s sparc/107087 sparc64 system is hinged 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 17 problems total. From fbsd-sparc64 at bzerk.org Mon Nov 3 04:02:19 2008 From: fbsd-sparc64 at bzerk.org (Ruben de Groot) Date: Mon Nov 3 04:02:26 2008 Subject: kgdb on sparc64 Message-ID: <20081103120215.GA32257@ei.bzerk.org> Hi, After upgrading to 7.1-PRERELEASE last month I'm seeing some spontaneous reboots with crash dumps on this Netra X1. How can I debug this as kgdb seems not to be working? # uname -r 7.1-PRERELEASE # kgdb /usr/obj/usr/src/sys/N4I/kernel.debug /var/crash/vmcore.1 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-marcel-freebsd"...^C GDB can't read core files on this machine. regards, Ruben From marius at alchemy.franken.de Mon Nov 3 14:11:14 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Mon Nov 3 14:11:23 2008 Subject: kgdb on sparc64 In-Reply-To: <20081103120215.GA32257@ei.bzerk.org> References: <20081103120215.GA32257@ei.bzerk.org> Message-ID: <20081103221111.GA8256@alchemy.franken.de> On Mon, Nov 03, 2008 at 01:02:15PM +0100, Ruben de Groot wrote: > > Hi, > > After upgrading to 7.1-PRERELEASE last month I'm seeing some > spontaneous reboots with crash dumps on this Netra X1. How > can I debug this as kgdb seems not to be working? > > # uname -r > 7.1-PRERELEASE > # kgdb /usr/obj/usr/src/sys/N4I/kernel.debug /var/crash/vmcore.1 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "sparc64-marcel-freebsd"...^C > GDB can't read core files on this machine. > I've never had much luck with kgdb(1) on any arch and use devel/gdb53 which still has '-k' instead (for sparc64 just remove the BROKEN from the port Makefile; the problem leading to that one being added was fixed some time a go). For your purposes it's probably simpler to just build a kernel with debugger by adding "options DDB", "options KDB" and "makeoptions DEBUG=-g". Then when the kernel panics just enter "backtrace" on the console. With a X1 you most likely use serial console anyway so you can easily capture the output. Marius From marius at alchemy.franken.de Mon Nov 3 14:30:45 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Mon Nov 3 14:30:51 2008 Subject: Free Ultra2 in Silicon Valley, USA In-Reply-To: <20081031131827.GA9613@soaustin.net> References: <20081031124442.GB9102@soaustin.net> <183638.12752.qm@web56802.mail.re3.yahoo.com> <20081031131827.GA9613@soaustin.net> Message-ID: <20081103223042.GB8256@alchemy.franken.de> On Fri, Oct 31, 2008 at 08:18:27AM -0500, Mark Linimon wrote: > On Fri, Oct 31, 2008 at 06:02:28AM -0700, mdh wrote: > > A dual CPU Ultra2 is going to be a lot more powerful than an Ultra5. > > Hmm, ok, didn't know that. If no-one else claims it first, perhaps > I can claim it for the build cluster and pull one of the Ultra 5s. > I intend to be out in .ca.us for meetBSD. > > > E4500's can be relatively beefy. > > We could have gotten our hands on some more of them in .ca.us but the > problem is who wants to pay for the power :-( Really, their time has > come and gone. > > > OK, this is probably way over my head, but I'll bite - what exactly > > happens if you don't breakpoint through it? > > http://people.freebsd.org/~linimon/studies/dmesgs/dmesg.netra_1_t200.txt . > > This appears to be some kind of race condition; my guess from fooling > around with it is that some interrupt is enabled, and then fires, before > the setup to handle it is finished. (Note that the same kernel runs > fine on the 100s). By stepping through it, you can see it fail at > different locations; without stepping through it, it is always at > the same. > > Unfortunately my notes are at home and that machine is unreachable ATM. > It's more likely that a device is exceeding the mapping provided, which causes the uncorrectable DMA error interrupt and in turn happens in different locations depending on how far the CPU has progressed since the transfer request was issued to the device. Anyway, the panic message provided isn't enough info to even guess what the real cause is. I think the easiest way to proceed would be to remove the remaining NIC (is there a reason you disabled gem(4) for the on-board ones?) and mass storage controller drivers one by one and see when the panic goes away. I'd begin with just disabling ATAPI DMA (meanwhile done by the sparc64 loader by default) though as ata(4) has a known issue causing data corruption with the ALI M5229 and ATAPI DMA on sparc64, which isn't impossible to be related with your problem. That said, my T1 AC200 is running fine and I've never seen such a problem with it... Marius From gavin at FreeBSD.org Mon Nov 3 16:46:20 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Mon Nov 3 16:46:32 2008 Subject: Booting of snapshot-iso on SUN Fire V280R In-Reply-To: <20081029081558.GB31338@alchemy.franken.de> References: <20081028172823.GO5156@darkthrone.kvedulv.de> <20081028221321.GA32214@alchemy.franken.de> <20081029001112.GR5156@darkthrone.kvedulv.de> <20081029081558.GB31338@alchemy.franken.de> Message-ID: <20081104001405.F60712@ury.york.ac.uk> On Wed, 29 Oct 2008, Marius Strobl wrote: > I'm uploading a new one at: > http://people.freebsd.org/~marius/8.0-20081028-SNAP-sparc64-disc1.iso.gz > The size when finished will be 323917911 bytes and the checksum > of the uncompressed image is: > MD5 (8.0-20081028-SNAP-sparc64-disc1.iso) = 5373c81c341e5dcff3055b1995300574 Can you verify this md5 please? gavin@rho 15% ls -l 8.0-20081028-SNAP-sparc64-disc1.iso.gz -rw-r--r-- 1 gavin gavin 323917911 Oct 29 03:07 8.0-20081028-SNAP-sparc64-disc1.iso.gz gavin@rho 16% md5 8.0-20081028-SNAP-sparc64-disc1.iso.gz MD5 (8.0-20081028-SNAP-sparc64-disc1.iso.gz) = 2a55e0b980ceda2fcd79bea8a574af69 I get the same running md5 directly on freefall. Thanks, Gavin From marius at alchemy.franken.de Mon Nov 3 23:41:13 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Mon Nov 3 23:41:20 2008 Subject: Booting of snapshot-iso on SUN Fire V280R In-Reply-To: <20081104001405.F60712@ury.york.ac.uk> References: <20081028172823.GO5156@darkthrone.kvedulv.de> <20081028221321.GA32214@alchemy.franken.de> <20081029001112.GR5156@darkthrone.kvedulv.de> <20081029081558.GB31338@alchemy.franken.de> <20081104001405.F60712@ury.york.ac.uk> Message-ID: <20081104074111.GD31338@alchemy.franken.de> On Tue, Nov 04, 2008 at 12:15:52AM +0000, Gavin Atkinson wrote: > On Wed, 29 Oct 2008, Marius Strobl wrote: > >I'm uploading a new one at: > >http://people.freebsd.org/~marius/8.0-20081028-SNAP-sparc64-disc1.iso.gz > >The size when finished will be 323917911 bytes and the checksum > >of the uncompressed image is: > >MD5 (8.0-20081028-SNAP-sparc64-disc1.iso) = > >5373c81c341e5dcff3055b1995300574 > > Can you verify this md5 please? > > gavin@rho 15% ls -l 8.0-20081028-SNAP-sparc64-disc1.iso.gz > -rw-r--r-- 1 gavin gavin 323917911 Oct 29 03:07 > 8.0-20081028-SNAP-sparc64-disc1.iso.gz > gavin@rho 16% md5 8.0-20081028-SNAP-sparc64-disc1.iso.gz > MD5 (8.0-20081028-SNAP-sparc64-disc1.iso.gz) = > 2a55e0b980ceda2fcd79bea8a574af69 > > I get the same running md5 directly on freefall. > just unzip it... marius@freefall:/home/marius > gzip -cd public_html/8.0-20081028-SNAP-sparc64-disc1.iso.gz | md5 5373c81c341e5dcff3055b1995300574 Marius From gavin.atkinson at ury.york.ac.uk Tue Nov 4 03:44:57 2008 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Tue Nov 4 03:45:04 2008 Subject: Booting of snapshot-iso on SUN Fire V280R In-Reply-To: <20081104074111.GD31338@alchemy.franken.de> References: <20081028172823.GO5156@darkthrone.kvedulv.de> <20081028221321.GA32214@alchemy.franken.de> <20081029001112.GR5156@darkthrone.kvedulv.de> <20081029081558.GB31338@alchemy.franken.de> <20081104001405.F60712@ury.york.ac.uk> <20081104074111.GD31338@alchemy.franken.de> Message-ID: <20081104111233.X84554@ury.york.ac.uk> On Tue, 4 Nov 2008, Marius Strobl wrote: > just unzip it... > > marius@freefall:/home/marius > gzip -cd public_html/8.0-20081028-SNAP-sparc64-disc1.iso.gz | md5 > 5373c81c341e5dcff3055b1995300574 Gah. I knew I was up too late to be productive. Sorry all! Gavin From linimon at lonesome.com Tue Nov 4 03:57:23 2008 From: linimon at lonesome.com (Mark Linimon) Date: Tue Nov 4 03:57:29 2008 Subject: Free Ultra2 in Silicon Valley, USA In-Reply-To: <20081103223042.GB8256@alchemy.franken.de> References: <20081031124442.GB9102@soaustin.net> <183638.12752.qm@web56802.mail.re3.yahoo.com> <20081031131827.GA9613@soaustin.net> <20081103223042.GB8256@alchemy.franken.de> Message-ID: <20081104115722.GA28394@soaustin.net> On Mon, Nov 03, 2008 at 11:30:42PM +0100, Marius Strobl wrote: > Anyway, the panic message provided isn't enough info to even > guess what the real cause is. I think I have more notes at home (not accessible ATM). > I think the easiest way to proceed would be to remove the remaining > NIC (is there a reason you disabled gem(4) for the on-board ones?) The kernels that we run are pretty lean; it's possible that that driver is not included. Or, are you talking about something in the hardware setup? > and mass storage controller drivers one by one and see when the > panic goes away. Is this something that can be done remotely? I'm a thousand miles away from the machines :-) > That said, my T1 AC200 is running fine and I've never seen such a > problem with it... These things have an add-in card with 4 more ethernet slots IIRC; could the difference in configuration explain things? mcl From mdh_lists at yahoo.com Tue Nov 4 05:09:01 2008 From: mdh_lists at yahoo.com (mdh) Date: Tue Nov 4 05:09:08 2008 Subject: Netra T1-200 debugging (was: Free Ultra2 in Silicon Valley, USA) In-Reply-To: <20081104115722.GA28394@soaustin.net> Message-ID: <477229.94848.qm@web56805.mail.re3.yahoo.com> --- On Tue, 11/4/08, Mark Linimon wrote: > From: Mark Linimon > Subject: Re: Free Ultra2 in Silicon Valley, USA > To: "Marius Strobl" > Cc: "Mark Linimon" , "mdh" , freebsd-sparc64@freebsd.org > Date: Tuesday, November 4, 2008, 6:57 AM > On Mon, Nov 03, 2008 at 11:30:42PM +0100, Marius Strobl > wrote: > > Anyway, the panic message provided isn't enough > info to even > > guess what the real cause is. > > I think I have more notes at home (not accessible ATM). > > > I think the easiest way to proceed would be to remove > the remaining > > NIC (is there a reason you disabled gem(4) for the > on-board ones?) > > The kernels that we run are pretty lean; it's possible > that that > driver is not included. Or, are you talking about > something in the > hardware setup? > > > and mass storage controller drivers one by one and see > when the > > panic goes away. > > Is this something that can be done remotely? I'm a > thousand miles > away from the machines :-) By the way, I'm pretty sure that there's no ATA controller in these. Should just be good ole SCSI. I mention this because I noticed Marius mentioned the ata driver in another message. > > > That said, my T1 AC200 is running fine and I've > never seen such a > > problem with it... > > These things have an add-in card with 4 more ethernet slots > IIRC; > could the difference in configuration explain things? That's interesting. Any chance we could try and boot one (preferably 3 or 4 times just to be certain) with the qfe/qge taken out? The T1-200 supported a couple of quad gigabit cards (Sun P/Ns 501-6738 and 501-6522) which I've never seen before personally. I haven't ever worked with a T1-200 myself. It does indeed look like an intermediate step, engineering-wise, between two very well-engineered machines (the T1-105 and the V120). Marius, I'm curious - the T1-200 has dual-eri interfaces on the mainboard, similar to the V100/V120? - mdh From linimon at lonesome.com Tue Nov 4 09:13:27 2008 From: linimon at lonesome.com (Mark Linimon) Date: Tue Nov 4 09:13:32 2008 Subject: Netra T1-200 debugging (was: Free Ultra2 in Silicon Valley, USA) In-Reply-To: <477229.94848.qm@web56805.mail.re3.yahoo.com> References: <20081104115722.GA28394@soaustin.net> <477229.94848.qm@web56805.mail.re3.yahoo.com> Message-ID: <20081104171326.GB32691@soaustin.net> On Tue, Nov 04, 2008 at 05:09:00AM -0800, mdh wrote: > By the way, I'm pretty sure that there's no ATA controller in these. Nope, appears to have a CDROM on ata2. > Any chance we could try and boot one (preferably 3 or 4 times just to > be certain) with the qfe/qge taken out? Can this be done via hints? (OTOH the quad card is being picked up by the hme driver ...) mcl From tinderbox at freebsd.org Tue Nov 4 12:14:44 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Nov 4 12:14:50 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081104201440.EF5B573039@freebsd-current.sentex.ca> TB --- 2008-11-04 19:51:50 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-11-04 19:51:50 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-04 19:51:50 - cleaning the object tree TB --- 2008-11-04 19:52:24 - cvsupping the source tree TB --- 2008-11-04 19:52:24 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-04 19:52:31 - building world (CFLAGS=-O -pipe) TB --- 2008-11-04 19:52:31 - cd /src TB --- 2008-11-04 19:52:31 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 4 19:52:34 UTC 2008 >>> 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 [...] rm -f .depend mkdep -f .depend -a -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ /src/lib/libutil/_secure_path.c /src/lib/libutil/auth.c /src/lib/libutil/gr_util.c /src/lib/libutil/expand_number.c /src/lib/libutil/flopen.c /src/lib/libutil/fparseln.c /src/lib/libutil/hexdump.c /src/lib/libutil/humanize_number.c /src/lib/libutil/kld.c /src/lib/libutil/login.c /src/lib/libutil/login_auth.c /src/lib/libutil/login_cap.c /src/lib/libutil/login_class.c /src/lib/libutil/login_crypt.c /src/lib/libutil/login_ok.c /src/lib/libutil/login_times.c /src/lib/libutil/login_tty.c /src/lib/libutil/logout.c /src/lib/libutil/logwtmp.c /src/lib/libutil/pidfile.c /src/lib/libutil/property.c /src/lib/libutil/pty.c /src/lib/libutil/pw_util.c /src/lib/libutil/realhostname.c /src/lib/libutil/stub.c /src/lib/libutil/trimdomain.c /src/lib/libutil/uucplock.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/_secure_path.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/auth.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/gr_util.c cc1: warnings being treated as errors /src/lib/libutil/gr_util.c: In function 'gr_dup': /src/lib/libutil/gr_util.c:154: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libutil. *** 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 --- 2008-11-04 20:14:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-04 20:14:40 - ERROR: failed to build world TB --- 2008-11-04 20:14:40 - tinderbox aborted TB --- 937.29 user 133.59 system 1370.37 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Tue Nov 4 12:21:05 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Nov 4 12:21:21 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20081104202102.F1FEC73039@freebsd-current.sentex.ca> TB --- 2008-11-04 19:59:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-11-04 19:59:35 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-11-04 19:59:35 - cleaning the object tree TB --- 2008-11-04 20:00:00 - cvsupping the source tree TB --- 2008-11-04 20:00:00 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-11-04 20:00:06 - building world (CFLAGS=-O -pipe) TB --- 2008-11-04 20:00:06 - cd /src TB --- 2008-11-04 20:00:06 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 4 20:00:08 UTC 2008 >>> 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 [...] rm -f .depend mkdep -f .depend -a -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ /src/lib/libutil/_secure_path.c /src/lib/libutil/auth.c /src/lib/libutil/gr_util.c /src/lib/libutil/expand_number.c /src/lib/libutil/flopen.c /src/lib/libutil/fparseln.c /src/lib/libutil/hexdump.c /src/lib/libutil/humanize_number.c /src/lib/libutil/kld.c /src/lib/libutil/login.c /src/lib/libutil/login_auth.c /src/lib/libutil/login_cap.c /src/lib/libutil/login_class.c /src/lib/libutil/login_crypt.c /src/lib/libutil/login_ok.c /src/lib/libutil/login_times.c /src/lib/libutil/login_tty.c /src/lib/libutil/logout.c /src/lib/libutil/logwtmp.c /src/lib/libutil/pidfile.c /src/lib/libutil/property.c /src/lib/libutil/pty.c /src/lib/libutil/pw_util.c /src/lib/libutil/realhostname.c /src/lib/libutil/stub.c /src/lib/libutil/trimdomain.c /src/lib/libutil/uucplock.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/_secure_path.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/auth.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/gr_util.c cc1: warnings being treated as errors /src/lib/libutil/gr_util.c: In function 'gr_dup': /src/lib/libutil/gr_util.c:154: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libutil. *** 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 --- 2008-11-04 20:21:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-04 20:21:02 - ERROR: failed to build world TB --- 2008-11-04 20:21:02 - tinderbox aborted TB --- 936.58 user 130.71 system 1287.57 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From marius at alchemy.franken.de Tue Nov 4 14:10:05 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Tue Nov 4 14:10:19 2008 Subject: Free Ultra2 in Silicon Valley, USA In-Reply-To: <20081104115722.GA28394@soaustin.net> References: <20081031124442.GB9102@soaustin.net> <183638.12752.qm@web56802.mail.re3.yahoo.com> <20081031131827.GA9613@soaustin.net> <20081103223042.GB8256@alchemy.franken.de> <20081104115722.GA28394@soaustin.net> Message-ID: <20081104221003.GE31338@alchemy.franken.de> On Tue, Nov 04, 2008 at 05:57:22AM -0600, Mark Linimon wrote: > On Mon, Nov 03, 2008 at 11:30:42PM +0100, Marius Strobl wrote: > > Anyway, the panic message provided isn't enough info to even > > guess what the real cause is. > > I think I have more notes at home (not accessible ATM). > > > I think the easiest way to proceed would be to remove the remaining > > NIC (is there a reason you disabled gem(4) for the on-board ones?) > > The kernels that we run are pretty lean; it's possible that that > driver is not included. Or, are you talking about something in the > hardware setup? No, I just wondered if there's a reason gem(4) wasn't included in the kernel, f.e. hme(4) worked better for you or something... > > > and mass storage controller drivers one by one and see when the > > panic goes away. > > Is this something that can be done remotely? I'm a thousand miles > away from the machines :-) Well, if you can't netboot them you already lost when it comes to getting a working kernel onto them unless there's someone onsite who can insert a CD with a working one. Otherwise you can experiment pretty much anything including removal of the drivers required to mount root remotely as long as you've access to the serial console. > > > That said, my T1 AC200 is running fine and I've never seen such a > > problem with it... > > These things have an add-in card with 4 more ethernet slots IIRC; > could the difference in configuration explain things? > That might make the difference and I've planned to give that configuration a try but I need to fetch mine from the datacenter in order to do so. Marius From marius at alchemy.franken.de Tue Nov 4 14:49:30 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Tue Nov 4 14:49:38 2008 Subject: Netra T1-200 debugging (was: Free Ultra2 in Silicon Valley, USA) In-Reply-To: <477229.94848.qm@web56805.mail.re3.yahoo.com> References: <20081104115722.GA28394@soaustin.net> <477229.94848.qm@web56805.mail.re3.yahoo.com> Message-ID: <20081104224928.GF31338@alchemy.franken.de> On Tue, Nov 04, 2008 at 05:09:00AM -0800, mdh wrote: > > By the way, I'm pretty sure that there's no ATA controller in these. Should just be good ole SCSI. I mention this because I noticed Marius mentioned the ata driver in another message. Well, there in fact is an ATA controller in T1 200... > > I haven't ever worked with a T1-200 myself. It does indeed look like an intermediate step, engineering-wise, between two very well-engineered machines (the T1-105 and the V120). > > Marius, I'm curious - the T1-200 has dual-eri interfaces on the mainboard, similar to the V100/V120? > AFAICT the T1 200 and V120 share the exact same mainboard, the former is just the telco version with a different front bezel and not sold with an 650MHz CPU. IMO "both" are very well engineered. T1 105 seem more like the first try of Sun doing an 1U machine. They even didn't build these an own motherboard but recycled the CP1500 cPCI module which is just mounted inside the chasis together with an expansion board. IMO this setup and the resulting wiring makes these machines seem kind of fragile. From reading just this list I got the impression that the mezzanine RAM these machines use is prone to be defective. V100 are different beasts again and seem to be designed with lowest-cost in mind. They have a rather small mainboard without a PCI-slot, not even ERI NICs but Davicom DM9102A and of course no SCSI. Otherwise these are the same generation technology as T1 200/V120, while T1 105 belong to the previous one. Marius From mdh_lists at yahoo.com Tue Nov 4 15:02:47 2008 From: mdh_lists at yahoo.com (mdh) Date: Tue Nov 4 15:02:53 2008 Subject: Netra T1-200 debugging (was: Free Ultra2 in Silicon Valley, USA) In-Reply-To: <20081104224928.GF31338@alchemy.franken.de> Message-ID: <975276.72521.qm@web56803.mail.re3.yahoo.com> --- On Tue, 11/4/08, Marius Strobl wrote: > From: Marius Strobl > Subject: Re: Netra T1-200 debugging (was: Free Ultra2 in Silicon Valley, USA) > To: "mdh" > Cc: "Mark Linimon" , freebsd-sparc64@freebsd.org > Date: Tuesday, November 4, 2008, 5:49 PM > On Tue, Nov 04, 2008 at 05:09:00AM -0800, mdh wrote: > > > > By the way, I'm pretty sure that there's no > ATA controller in these. Should just be good ole SCSI. I > mention this because I noticed Marius mentioned the ata > driver in another message. > > Well, there in fact is an ATA controller in T1 200... OK. I wasn't aware that those CDROMs were not SCSI-connected. Just out of curiosity, did they still show up as 't6' in /dev? ;) > > > > > I haven't ever worked with a T1-200 myself. It > does indeed look like an intermediate step, > engineering-wise, between two very well-engineered machines > (the T1-105 and the V120). > > > > Marius, I'm curious - the T1-200 has dual-eri > interfaces on the mainboard, similar to the V100/V120? > > > > AFAICT the T1 200 and V120 share the exact same mainboard, > the former is just the telco version with a different front > bezel and not sold with an 650MHz CPU. IMO "both" > are very > well engineered. Ahhh, OK. > T1 105 seem more like the first try of Sun doing an 1U > machine. They even didn't build these an own > motherboard > but recycled the CP1500 cPCI module which is just mounted > inside the chasis together with an expansion board. IMO > this setup and the resulting wiring makes these machines > seem kind of fragile. From reading just this list I got > the impression that the mezzanine RAM these machines use > is prone to be defective. I've never had a problem personally, but it was just that - their first try at a 1u box. > V100 are different beasts again and seem to be designed > with lowest-cost in mind. They have a rather small > mainboard without a PCI-slot, not even ERI NICs but > Davicom DM9102A and of course no SCSI. Otherwise these > are the same generation technology as T1 200/V120, while > T1 105 belong to the previous one. The V100 was preceded by the "Netra X1" which was similar to the V100 but had a shorter chassis. The X1 had a V-series front bezel, but was still branded Netra. I actually liked the X1's for their size and price; they were Sun's first "really-really-cheap" SPARC-based server. It wasn't particularly reliable, sadly, but was practically disposable anyway at under $700 a pop. It came out in between the T1-105 and the V-series. - mdh From tinderbox at freebsd.org Tue Nov 4 17:13:17 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Nov 4 17:13:25 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081105011314.4165573039@freebsd-current.sentex.ca> TB --- 2008-11-05 00:50:25 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-11-05 00:50:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-05 00:50:25 - cleaning the object tree TB --- 2008-11-05 00:50:34 - cvsupping the source tree TB --- 2008-11-05 00:50:34 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-05 00:50:41 - building world (CFLAGS=-O -pipe) TB --- 2008-11-05 00:50:41 - cd /src TB --- 2008-11-05 00:50:41 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 5 00:50:45 UTC 2008 >>> 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 [...] rm -f .depend mkdep -f .depend -a -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ /src/lib/libutil/_secure_path.c /src/lib/libutil/auth.c /src/lib/libutil/gr_util.c /src/lib/libutil/expand_number.c /src/lib/libutil/flopen.c /src/lib/libutil/fparseln.c /src/lib/libutil/hexdump.c /src/lib/libutil/humanize_number.c /src/lib/libutil/kld.c /src/lib/libutil/login.c /src/lib/libutil/login_auth.c /src/lib/libutil/login_cap.c /src/lib/libutil/login_class.c /src/lib/libutil/login_crypt.c /src/lib/libutil/login_ok.c /src/lib/libutil/login_times.c /src/lib/libutil/login_tty.c /src/lib/libutil/logout.c /src/lib/libutil/logwtmp.c /src/lib/libutil/pidfile.c /src/lib/libutil/property.c /src/lib/libutil/pty.c /src/lib/libutil/pw_util.c /src/lib/libutil/realhostname.c /src/lib/libutil/stub.c /src/lib/libutil/trimdomain.c /src/lib/libutil/uucplock.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/_secure_path.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/auth.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/gr_util.c cc1: warnings being treated as errors /src/lib/libutil/gr_util.c: In function 'gr_dup': /src/lib/libutil/gr_util.c:154: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libutil. *** 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 --- 2008-11-05 01:13:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-05 01:13:13 - ERROR: failed to build world TB --- 2008-11-05 01:13:13 - tinderbox aborted TB --- 936.92 user 132.16 system 1368.16 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Tue Nov 4 17:31:23 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Nov 4 17:31:36 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20081105013120.8FAAF73039@freebsd-current.sentex.ca> TB --- 2008-11-05 01:11:55 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-11-05 01:11:55 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-11-05 01:11:55 - cleaning the object tree TB --- 2008-11-05 01:12:03 - cvsupping the source tree TB --- 2008-11-05 01:12:03 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-11-05 01:12:08 - building world (CFLAGS=-O -pipe) TB --- 2008-11-05 01:12:08 - cd /src TB --- 2008-11-05 01:12:08 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 5 01:12:09 UTC 2008 >>> 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 [...] rm -f .depend mkdep -f .depend -a -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ /src/lib/libutil/_secure_path.c /src/lib/libutil/auth.c /src/lib/libutil/gr_util.c /src/lib/libutil/expand_number.c /src/lib/libutil/flopen.c /src/lib/libutil/fparseln.c /src/lib/libutil/hexdump.c /src/lib/libutil/humanize_number.c /src/lib/libutil/kld.c /src/lib/libutil/login.c /src/lib/libutil/login_auth.c /src/lib/libutil/login_cap.c /src/lib/libutil/login_class.c /src/lib/libutil/login_crypt.c /src/lib/libutil/login_ok.c /src/lib/libutil/login_times.c /src/lib/libutil/login_tty.c /src/lib/libutil/logout.c /src/lib/libutil/logwtmp.c /src/lib/libutil/pidfile.c /src/lib/libutil/property.c /src/lib/libutil/pty.c /src/lib/libutil/pw_util.c /src/lib/libutil/realhostname.c /src/lib/libutil/stub.c /src/lib/libutil/trimdomain.c /src/lib/libutil/uucplock.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/_secure_path.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/auth.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/gr_util.c cc1: warnings being treated as errors /src/lib/libutil/gr_util.c: In function 'gr_dup': /src/lib/libutil/gr_util.c:154: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libutil. *** 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 --- 2008-11-05 01:31:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-05 01:31:20 - ERROR: failed to build world TB --- 2008-11-05 01:31:20 - tinderbox aborted TB --- 926.62 user 128.38 system 1165.56 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From johan at giantfoo.org Tue Nov 4 17:38:12 2008 From: johan at giantfoo.org (Johan A. van Zanten) Date: Tue Nov 4 17:38:19 2008 Subject: Netra T1-200 debugging In-Reply-To: <20081104224928.GF31338@alchemy.franken.de> References: <20081104115722.GA28394@soaustin.net> <477229.94848.qm@web56805.mail.re3.yahoo.com> <20081104224928.GF31338@alchemy.franken.de> Message-ID: <20081104.192013.179942973.johan@giantfoo.org> Last year i was looking at used Netras, especially from the angle of power consumption and BTU generation, and put together this table: http://www.giantfoo.org/~johan/tech/sun-machine-specs.html It's probably a little out of date now, at least regarding price and whether or not it will run NetBSD, but maybe it'd save someone a little time. -johan From scf at FreeBSD.org Tue Nov 4 20:23:16 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Tue Nov 4 20:23:28 2008 Subject: [head tinderbox] failure on sparc64/sun4v In-Reply-To: <20081105013120.8FAAF73039@freebsd-current.sentex.ca> References: <20081105013120.8FAAF73039@freebsd-current.sentex.ca> Message-ID: On Tue, 4 Nov 2008, FreeBSD Tinderbox wrote: *snip* > cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/gr_util.c > cc1: warnings being treated as errors > /src/lib/libutil/gr_util.c: In function 'gr_dup': > /src/lib/libutil/gr_util.c:154: warning: cast increases required alignment of target type > *** Error code 1 Does the following patch fix this warning (due to r184635) correctly? It should align the (char **) pointer correctly within the allocated buffer. The (void *) cast is necessary because gcc is not able to detect that the alignment was fixed. Better solutions are welcome. http://www.farley.org/freebsd/tmp/libutil.patch Sean -- scf@FreeBSD.org From tinderbox at freebsd.org Tue Nov 4 22:14:04 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Nov 4 22:14:11 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081105061401.1F47373039@freebsd-current.sentex.ca> TB --- 2008-11-05 05:51:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-11-05 05:51:35 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-05 05:51:35 - cleaning the object tree TB --- 2008-11-05 05:51:41 - cvsupping the source tree TB --- 2008-11-05 05:51:41 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-05 05:51:47 - building world (CFLAGS=-O -pipe) TB --- 2008-11-05 05:51:47 - cd /src TB --- 2008-11-05 05:51:47 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 5 05:51:49 UTC 2008 >>> 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 [...] rm -f .depend mkdep -f .depend -a -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ /src/lib/libutil/_secure_path.c /src/lib/libutil/auth.c /src/lib/libutil/gr_util.c /src/lib/libutil/expand_number.c /src/lib/libutil/flopen.c /src/lib/libutil/fparseln.c /src/lib/libutil/hexdump.c /src/lib/libutil/humanize_number.c /src/lib/libutil/kld.c /src/lib/libutil/login.c /src/lib/libutil/login_auth.c /src/lib/libutil/login_cap.c /src/lib/libutil/login_class.c /src/lib/libutil/login_crypt.c /src/lib/libutil/login_ok.c /src/lib/libutil/login_times.c /src/lib/libutil/login_tty.c /src/lib/libutil/logout.c /src/lib/libutil/logwtmp.c /src/lib/libutil/pidfile.c /src/lib/libutil/property.c /src/lib/libutil/pty.c /src/lib/libutil/pw_util.c /src/lib/libutil/realhostname.c /src/lib/libutil/stub.c /src/lib/libutil/trimdomain.c /src/lib/libutil/uucplock.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/_secure_path.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/auth.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/gr_util.c cc1: warnings being treated as errors /src/lib/libutil/gr_util.c: In function 'gr_dup': /src/lib/libutil/gr_util.c:154: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libutil. *** 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 --- 2008-11-05 06:14:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-05 06:14:00 - ERROR: failed to build world TB --- 2008-11-05 06:14:00 - tinderbox aborted TB --- 935.91 user 131.13 system 1345.47 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Tue Nov 4 22:31:09 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Nov 4 22:31:15 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20081105063107.4C2A373039@freebsd-current.sentex.ca> TB --- 2008-11-05 06:11:41 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-11-05 06:11:41 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-11-05 06:11:41 - cleaning the object tree TB --- 2008-11-05 06:11:47 - cvsupping the source tree TB --- 2008-11-05 06:11:47 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-11-05 06:11:53 - building world (CFLAGS=-O -pipe) TB --- 2008-11-05 06:11:53 - cd /src TB --- 2008-11-05 06:11:53 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 5 06:11:54 UTC 2008 >>> 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 [...] rm -f .depend mkdep -f .depend -a -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ /src/lib/libutil/_secure_path.c /src/lib/libutil/auth.c /src/lib/libutil/gr_util.c /src/lib/libutil/expand_number.c /src/lib/libutil/flopen.c /src/lib/libutil/fparseln.c /src/lib/libutil/hexdump.c /src/lib/libutil/humanize_number.c /src/lib/libutil/kld.c /src/lib/libutil/login.c /src/lib/libutil/login_auth.c /src/lib/libutil/login_cap.c /src/lib/libutil/login_class.c /src/lib/libutil/login_crypt.c /src/lib/libutil/login_ok.c /src/lib/libutil/login_times.c /src/lib/libutil/login_tty.c /src/lib/libutil/logout.c /src/lib/libutil/logwtmp.c /src/lib/libutil/pidfile.c /src/lib/libutil/property.c /src/lib/libutil/pty.c /src/lib/libutil/pw_util.c /src/lib/libutil/realhostname.c /src/lib/libutil/stub.c /src/lib/libutil/trimdomain.c /src/lib/libutil/uucplock.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/_secure_path.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/auth.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/gr_util.c cc1: warnings being treated as errors /src/lib/libutil/gr_util.c: In function 'gr_dup': /src/lib/libutil/gr_util.c:154: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libutil. *** 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 --- 2008-11-05 06:31:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-05 06:31:07 - ERROR: failed to build world TB --- 2008-11-05 06:31:07 - tinderbox aborted TB --- 925.80 user 129.03 system 1166.10 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Wed Nov 5 03:17:39 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Nov 5 03:17:56 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081105111736.18E2273039@freebsd-current.sentex.ca> TB --- 2008-11-05 10:54:58 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-11-05 10:54:58 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-05 10:54:58 - cleaning the object tree TB --- 2008-11-05 10:55:07 - cvsupping the source tree TB --- 2008-11-05 10:55:07 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-05 10:55:13 - building world (CFLAGS=-O -pipe) TB --- 2008-11-05 10:55:13 - cd /src TB --- 2008-11-05 10:55:13 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 5 10:55:15 UTC 2008 >>> 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 [...] rm -f .depend mkdep -f .depend -a -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ /src/lib/libutil/_secure_path.c /src/lib/libutil/auth.c /src/lib/libutil/gr_util.c /src/lib/libutil/expand_number.c /src/lib/libutil/flopen.c /src/lib/libutil/fparseln.c /src/lib/libutil/hexdump.c /src/lib/libutil/humanize_number.c /src/lib/libutil/kld.c /src/lib/libutil/login.c /src/lib/libutil/login_auth.c /src/lib/libutil/login_cap.c /src/lib/libutil/login_class.c /src/lib/libutil/login_crypt.c /src/lib/libutil/login_ok.c /src/lib/libutil/login_times.c /src/lib/libutil/login_tty.c /src/lib/libutil/logout.c /src/lib/libutil/logwtmp.c /src/lib/libutil/pidfile.c /src/lib/libutil/property.c /src/lib/libutil/pty.c /src/lib/libutil/pw_util.c /src/lib/libutil/realhostname.c /src/lib/libutil/stub.c /src/lib/libutil/trimdomain.c /src/lib/libutil/uucplock.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/_secure_path.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/auth.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/gr_util.c cc1: warnings being treated as errors /src/lib/libutil/gr_util.c: In function 'gr_dup': /src/lib/libutil/gr_util.c:154: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libutil. *** 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 --- 2008-11-05 11:17:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-05 11:17:35 - ERROR: failed to build world TB --- 2008-11-05 11:17:35 - tinderbox aborted TB --- 937.66 user 130.27 system 1357.38 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Wed Nov 5 03:33:56 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Nov 5 03:34:08 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20081105113354.1EF6873039@freebsd-current.sentex.ca> TB --- 2008-11-05 11:14:02 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-11-05 11:14:02 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-11-05 11:14:02 - cleaning the object tree TB --- 2008-11-05 11:14:13 - cvsupping the source tree TB --- 2008-11-05 11:14:13 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-11-05 11:14:19 - building world (CFLAGS=-O -pipe) TB --- 2008-11-05 11:14:19 - cd /src TB --- 2008-11-05 11:14:19 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 5 11:14:21 UTC 2008 >>> 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 [...] rm -f .depend mkdep -f .depend -a -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ /src/lib/libutil/_secure_path.c /src/lib/libutil/auth.c /src/lib/libutil/gr_util.c /src/lib/libutil/expand_number.c /src/lib/libutil/flopen.c /src/lib/libutil/fparseln.c /src/lib/libutil/hexdump.c /src/lib/libutil/humanize_number.c /src/lib/libutil/kld.c /src/lib/libutil/login.c /src/lib/libutil/login_auth.c /src/lib/libutil/login_cap.c /src/lib/libutil/login_class.c /src/lib/libutil/login_crypt.c /src/lib/libutil/login_ok.c /src/lib/libutil/login_times.c /src/lib/libutil/login_tty.c /src/lib/libutil/logout.c /src/lib/libutil/logwtmp.c /src/lib/libutil/pidfile.c /src/lib/libutil/property.c /src/lib/libutil/pty.c /src/lib/libutil/pw_util.c /src/lib/libutil/realhostname.c /src/lib/libutil/stub.c /src/lib/libutil/trimdomain.c /src/lib/libutil/uucplock.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/_secure_path.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/auth.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/gr_util.c cc1: warnings being treated as errors /src/lib/libutil/gr_util.c: In function 'gr_dup': /src/lib/libutil/gr_util.c:154: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libutil. *** 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 --- 2008-11-05 11:33:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-05 11:33:54 - ERROR: failed to build world TB --- 2008-11-05 11:33:54 - tinderbox aborted TB --- 925.65 user 129.72 system 1191.24 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From linimon at lonesome.com Wed Nov 5 10:47:47 2008 From: linimon at lonesome.com (Mark Linimon) Date: Wed Nov 5 10:47:53 2008 Subject: Free Ultra2 in Silicon Valley, USA In-Reply-To: <20081104221003.GE31338@alchemy.franken.de> References: <20081031124442.GB9102@soaustin.net> <183638.12752.qm@web56802.mail.re3.yahoo.com> <20081031131827.GA9613@soaustin.net> <20081103223042.GB8256@alchemy.franken.de> <20081104115722.GA28394@soaustin.net> <20081104221003.GE31338@alchemy.franken.de> Message-ID: <20081105184746.GA26875@soaustin.net> On Tue, Nov 04, 2008 at 11:10:03PM +0100, Marius Strobl wrote: > I've planned to give that configuration a try but I need to fetch > mine from the datacenter in order to do so. No rush, I'm still traveling. mcl From linimon at lonesome.com Wed Nov 5 10:52:20 2008 From: linimon at lonesome.com (Mark Linimon) Date: Wed Nov 5 10:52:25 2008 Subject: Netra T1-200 debugging In-Reply-To: <20081104.192013.179942973.johan@giantfoo.org> References: <20081104115722.GA28394@soaustin.net> <477229.94848.qm@web56805.mail.re3.yahoo.com> <20081104224928.GF31338@alchemy.franken.de> <20081104.192013.179942973.johan@giantfoo.org> Message-ID: <20081105185219.GB26875@soaustin.net> fwiw, the only difference in the "AC200" and the "DC200" is the power supply (the latter were designed for telco DC power racks). Thanks for the update. mcl From carton at Ivy.NET Wed Nov 5 10:54:56 2008 From: carton at Ivy.NET (Miles Nordin) Date: Wed Nov 5 10:55:08 2008 Subject: Netra T1-200 debugging In-Reply-To: <20081104224928.GF31338@alchemy.franken.de> (Marius Strobl's message of "Tue, 4 Nov 2008 23:49:28 +0100") References: <20081104115722.GA28394@soaustin.net> <477229.94848.qm@web56805.mail.re3.yahoo.com> <20081104224928.GF31338@alchemy.franken.de> Message-ID: >>>>> "ms" == Marius Strobl writes: ms> Well, there in fact is an ATA controller in T1 200... yes definitely has ATA CD-ROM. atapci0: port 0x400-0x407,0x418-0x41b,0x410-0x417,0x408-0x40b,0x420-0x42f at device 13.0 on pci1 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata2: on atapci0 ata3: on atapci0 acd0: CDRW at ata2-master UDMA33 >> Marius, I'm curious - the T1-200 has dual-eri interfaces yeah it has 100Mbit/s interfaces that attach as gem under FreeBSD. gem0: mem 0xe0400000-0xe041ffff at device 12.1 on pci1 miibus0: on gem0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto gem0: 2kB RX FIFO, 2kB TX FIFO gem0: Ethernet address: 00:03:ba:0f:aa:45 gem1: mem 0xe0440000-0xe045ffff at device 5.1 on pci1 miibus1: on gem1 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto gem1: 2kB RX FIFO, 2kB TX FIFO gem1: Ethernet address: 00:03:ba:0f:aa:45 IIRC they don't work well or I wanted device polling on 6.0 or something i forget, so I'm using mine with a bge card, but good luck getting the same working stepping of 57xx chip that I've got. bge0: mem 0x10000-0x1ffff at device 5.0 on pci2 miibus2: on bge0 brgphy0: on miibus2 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:09:5b:60:3a:75 The T1 105 has hme interfaces but I didn't load a driver for them. atapci0: port 0x1000-0x1007,0x1008-0x100b,0x1010-0x1017,0x1018-0x101b,0x1020-0x102f at device 14.0 on pci3 ata2: on atapci0 ata3: on atapci0 pci3: at device 15.0 (no driver attached) pci3: at device 15.1 (no driver attached) X1 has two digital tulips, tlp or dc ms> AFAICT the T1 200 and V120 share the exact same mainboard, I was about to say, ``no,'' but I think you're right: http://web.ivy.net/~carton/sun-feh-2_1/Systems/Netra_T1_AC200/Netra_T1_AC200_top_zoom.html http://web.ivy.net/~carton/sun-feh-2_1/Systems/SunFireV120/SunFireV120_top_zoom.html I've both, and think the V120 makes a lot more fan noise. The X1 is awesome but for three show-stopping problems: * most NIC drivers do not work well in BSD. They perform badly, or lock up once a day, or panic your machine when they receive a jumbo frame (my current problem with em(4)), or are dishonest about the duplex setting, or some such bullshit. so to get a working system you must swap cards until you find some happy card that works. The X1 has no PCI slot, so if the dc driver doesn't work in whatever version of BSD you're using for whatever network stack features you need, you're SOL. * has IDE only, no SCSI. IDE never performed well, or even stably, on any Sun platform I know of under any OS, especially Solaris but also others. better than digital alpha IDE, but nothing like IDE on a peecee. Even their current machines can't seem to deliver a SATA driver that's fully-working including NCQ, hotplug, not randomly locking up, not missing interrupts and slowing down. Even in their own hardware they can't do this. The chip in the X4500 is years old and is still causing people huge headaches, problems like ``ports 6 and 7 hotplug but all other ports don't work right''. The only card working well now is a SAS card that I expect has really heavyweight firmware and a lot of protocol translation so it's like using your disks through a firewire case where things like smartctl and cdrecord can't be expected to work. that was massively OT, but seriously this company's had decades to get their shit together and still cannot cooperate with the ATA world. * has those stupid hard drive ``sleds''. If you get a machine with one disk it comes with a ``blank sled'' which won't take a drive and really has no reason at all to exist except to make fun of you. I ended up buying two X1's and throwing one out because it was the cheapest way to get two sleds. If you want to drill holes in the case and mount the drive from the bottom it'll work fine, but if you wanted to do such goofy things I think you'd buy an Intel Atom 330 board which is faster and still 64-bit. The SCSI variants (T1 105, T1 200, V120) are hot-swap so you can use Sun SCA drive sleds which are available almost for free with drives already in them. There are different kinds of SCA hotswap drive sled not the same for all three, and sometimes the sled will fit in, but won't snap locked. I minded this less than drilling holes, unless you're mounting it in a rack in an ambulance or a news van or something weird like that. but maybe some won't fit at all. The T1 105 takes weird expensive memory. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20081105/1eaac4a5/attachment.pgp From carton at Ivy.NET Wed Nov 5 10:59:41 2008 From: carton at Ivy.NET (Miles Nordin) Date: Wed Nov 5 10:59:47 2008 Subject: Netra T1-200 debugging In-Reply-To: <20081104.192013.179942973.johan@giantfoo.org> (Johan A. van Zanten's message of "Tue, 04 Nov 2008 19:20:13 -0600 (CST)") References: <20081104115722.GA28394@soaustin.net> <477229.94848.qm@web56805.mail.re3.yahoo.com> <20081104224928.GF31338@alchemy.franken.de> <20081104.192013.179942973.johan@giantfoo.org> Message-ID: >>>>> "javz" == Johan A van Zanten writes: javz> http://www.giantfoo.org/~johan/tech/sun-machine-specs.html the table is wrong or misleading for the type of memory in the T1 105. It's some goofy square stackable mezzanine card. interesting, though, that it's the only one with a big cache. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20081105/7b6a5c35/attachment.pgp From mail25 at bzerk.org Wed Nov 5 11:56:43 2008 From: mail25 at bzerk.org (Ruben de Groot) Date: Wed Nov 5 11:56:50 2008 Subject: kgdb on sparc64 In-Reply-To: <20081103221111.GA8256@alchemy.franken.de> References: <20081103120215.GA32257@ei.bzerk.org> <20081103221111.GA8256@alchemy.franken.de> Message-ID: <20081105195630.GA52831@ei.bzerk.org> On Mon, Nov 03, 2008 at 11:11:11PM +0100, Marius Strobl typed: > > After upgrading to 7.1-PRERELEASE last month I'm seeing some > > spontaneous reboots with crash dumps on this Netra X1. How > > can I debug this as kgdb seems not to be working? [...] > I've never had much luck with kgdb(1) on any arch and use > devel/gdb53 which still has '-k' instead (for sparc64 just > remove the BROKEN from the port Makefile; the problem > leading to that one being added was fixed some time a go). The installation of gbd53 fails unfortunately with: gmake[1]: Leaving directory `/usr/ports/devel/gdb53/work/gdb-5.3/sparc64-portbld-freebsd7.1/libiberty' gmake[1]: Entering directory `/usr/ports/devel/gdb53/work/gdb-5.3/libiberty' rm -f libiberty.a pic/libiberty.a sparc64-unknown-freebsd7.1-ar rc libiberty.a \ regex.o cplus-dem.o cp-demangle.o md5.o alloca.o argv.o choose-temp.o concat.o dyn-string.o fdmatch.o fibheap.o floatformat.o fnmatch.o getopt.o getopt1.o getpwd.o getruntime.o hashtab.o hex.o lbasename.o make-temp-file.o objalloc.o obstack.o partition.o pexecute.o safe-ctype.o sort.o spaces.o splay-tree.o strerror.o strsignal.o ternary.o xatexit.o xexit.o xmalloc.o xmemdup.o xstrdup.o xstrerror.o gmake[1]: sparc64-unknown-freebsd7.1-ar: Command not found gmake[1]: *** [libiberty.a] Error 127 gmake[1]: Leaving directory `/usr/ports/devel/gdb53/work/gdb-5.3/libiberty' gmake: *** [all-libiberty] Error 2 *** Error code 2 Stop in /usr/ports/devel/gdb53. > For your purposes it's probably simpler to just build a > kernel with debugger by adding "options DDB", "options KDB" > and "makeoptions DEBUG=-g". Then when the kernel panics > just enter "backtrace" on the console. With a X1 you > most likely use serial console anyway so you can easily > capture the output. I'll build a kernel with those options just in case. But would rather not use it on this particular machine, as it is a production server and should not be down for extended periods of time. Meanwhile, moving over websites to another machine (another X1, but running -current) that seems to be more stable ATM. thanks, Ruben From fbsd-sparc64 at bzerk.org Thu Nov 6 00:12:33 2008 From: fbsd-sparc64 at bzerk.org (Ruben de Groot) Date: Thu Nov 6 00:12:40 2008 Subject: kgdb on sparc64 In-Reply-To: <20081103221111.GA8256@alchemy.franken.de> References: <20081103120215.GA32257@ei.bzerk.org> <20081103221111.GA8256@alchemy.franken.de> Message-ID: <20081105195630.GA52831@ei.bzerk.org> On Mon, Nov 03, 2008 at 11:11:11PM +0100, Marius Strobl typed: > > After upgrading to 7.1-PRERELEASE last month I'm seeing some > > spontaneous reboots with crash dumps on this Netra X1. How > > can I debug this as kgdb seems not to be working? [...] > I've never had much luck with kgdb(1) on any arch and use > devel/gdb53 which still has '-k' instead (for sparc64 just > remove the BROKEN from the port Makefile; the problem > leading to that one being added was fixed some time a go). The installation of gbd53 fails unfortunately with: gmake[1]: Leaving directory `/usr/ports/devel/gdb53/work/gdb-5.3/sparc64-portbld-freebsd7.1/libiberty' gmake[1]: Entering directory `/usr/ports/devel/gdb53/work/gdb-5.3/libiberty' rm -f libiberty.a pic/libiberty.a sparc64-unknown-freebsd7.1-ar rc libiberty.a \ regex.o cplus-dem.o cp-demangle.o md5.o alloca.o argv.o choose-temp.o concat.o dyn-string.o fdmatch.o fibheap.o floatformat.o fnmatch.o getopt.o getopt1.o getpwd.o getruntime.o hashtab.o hex.o lbasename.o make-temp-file.o objalloc.o obstack.o partition.o pexecute.o safe-ctype.o sort.o spaces.o splay-tree.o strerror.o strsignal.o ternary.o xatexit.o xexit.o xmalloc.o xmemdup.o xstrdup.o xstrerror.o gmake[1]: sparc64-unknown-freebsd7.1-ar: Command not found gmake[1]: *** [libiberty.a] Error 127 gmake[1]: Leaving directory `/usr/ports/devel/gdb53/work/gdb-5.3/libiberty' gmake: *** [all-libiberty] Error 2 *** Error code 2 Stop in /usr/ports/devel/gdb53. > For your purposes it's probably simpler to just build a > kernel with debugger by adding "options DDB", "options KDB" > and "makeoptions DEBUG=-g". Then when the kernel panics > just enter "backtrace" on the console. With a X1 you > most likely use serial console anyway so you can easily > capture the output. I'll build a kernel with those options just in case. But would rather not use it on this particular machine, as it is a production server and should not be down for extended periods of time. Meanwhile, moving over websites to another machine (another X1, but running -current) that seems to be more stable ATM. thanks, Ruben From mj at mjturner.net Thu Nov 6 10:05:35 2008 From: mj at mjturner.net (Michael-John Turner) Date: Thu Nov 6 10:05:41 2008 Subject: Netra T1-200 debugging In-Reply-To: References: <20081104115722.GA28394@soaustin.net> <477229.94848.qm@web56805.mail.re3.yahoo.com> <20081104224928.GF31338@alchemy.franken.de> <20081104.192013.179942973.johan@giantfoo.org> Message-ID: <20081106173311.GH25025@aurora.pimp.org.za> On Wed, Nov 05, 2008 at 01:59:39PM -0500, Miles Nordin wrote: > interesting, though, that it's the only one with a big cache. There may also be the odd mistake in the cache info - My T1 AC200 has 1024KiB cache, not the 256KiB listed in the table. Running NetBSD 4.0: cpu0 at mainbus0: SUNW,UltraSPARC-IIe @ 500 MHz, UPA id 0 cpu0: 32K instruction (32 b/l), 16K data (32 b/l), 1024K external (64 b/l) -mj -- Michael-John Turner mj@mjturner.net <> http://mjturner.net/ From johan at giantfoo.org Thu Nov 6 10:17:44 2008 From: johan at giantfoo.org (Johan A. van Zanten) Date: Thu Nov 6 10:17:49 2008 Subject: Netra T1-200 debugging In-Reply-To: <20081106173311.GH25025@aurora.pimp.org.za> References: <20081104.192013.179942973.johan@giantfoo.org> <20081106173311.GH25025@aurora.pimp.org.za> Message-ID: <20081106.121741.1300526614.johan@giantfoo.org> Michael-John Turner wrote: > On Wed, Nov 05, 2008 at 01:59:39PM -0500, Miles Nordin wrote: > > interesting, though, that it's the only one with a big cache. > > There may also be the odd mistake in the cache info - My T1 AC200 has > 1024KiB cache, not the 256KiB listed in the table. > > Running NetBSD 4.0: > cpu0 at mainbus0: SUNW,UltraSPARC-IIe @ 500 MHz, UPA id 0 > cpu0: 32K instruction (32 b/l), 16K data (32 b/l), 1024K external (64 > b/l) I think i based my info on this: http://sunsolve.sun.com/handbook_pub/validateUser.do?target=Systems/Netra_T1_AC200_shared/spec I'll add your info. -johan From scaron at umich.edu Thu Nov 6 10:43:17 2008 From: scaron at umich.edu (Sean Thomas Caron) Date: Thu Nov 6 10:43:23 2008 Subject: Occasional kernel panic + reboot on 7.0-RELEASE with fatm driver. Message-ID: <20081106131717.331718q66y289lgk@web.mail.umich.edu> Hi folks, I'm using fatm on FreeBSD/sparc64 7.0-RELEASE; it generally works well but every couple of weeks the system will kernel panic and reboot. I switched on kernel dumps on panic and here's what I got (this time): sonnet.diablonet.net> kgdb kernel.debug /var/crash/vmcore.0 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-marcel-freebsd". Unread portion of the kernel message buffer: panic: trap: fast data access mmu miss Uptime: 16d13h9m7s Dumping 1024 MB (2 chunks) chunk at 0: 536870912 bytes | #0 0x00000000c0280cd8 in doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 savectx(&dumppcb); (kgdb) backtrace #0 0x00000000c0280cd8 in doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0x00000000c0281608 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0x00000000c0281860 in panic (fmt=0xc066c6e0 "trap: %s") at /usr/src/sys/kern/kern_shutdown.c:563 #3 0x00000000c0541de4 in trap (tf=0xe5390e50) at /usr/src/sys/sparc64/sparc64/trap.c:378 #4 0x00000000c0070fe0 in tl1_trap () #5 0x00000000c02dd1d0 in sbsndptr (sb=0xfffff800014be6f0, off=0, len=1390, moff=0xe5391064) at /usr/src/sys/kern/uipc_sockbuf.c:939 #6 0x00000000c03edac4 in tcp_output (tp=0xfffff800014be6f0) at /usr/src/sys/netinet/tcp_output.c:802 #7 0x00000000c03edac4 in tcp_output (tp=0xfffff800014fce38) at /usr/src/sys/netinet/tcp_output.c:802 #8 0x00000000c03eaf98 in tcp_do_segment (m=0xfffff8005b354000, th=0xfffff8000133283c, so=0xfffff800014be570, tp=0xfffff800014fce38, drop_hdrlen=52, tlen=0) at /usr/src/sys/netinet/tcp_input.c:2347 #9 0x00000000c03ec214 in tcp_input (m=0xfffff8005b354000, off0=Variable "off0" is not available. ) at /usr/src/sys/netinet/tcp_input.c:845 #10 0x00000000c0381128 in ip_input (m=0xfffff8005b354000) at /usr/src/sys/netinet/ip_input.c:665 #11 0x00000000c0339cd0 in netisr_dispatch (num=2, m=0xfffff8005b354000) at /usr/src/sys/net/netisr.c:185 #12 0x00000000c032a930 in atm_input (ifp=0xfffff8000103c000, ah=0xe539162c, m=0xfffff8005b354000, rxhand=0x0) at /usr/src/sys/net/if_atmsubr.c:347 #13 0x00000000c013d410 in fatm_intr (p=0xfffff80001173c00) at /usr/src/sys/dev/fatm/if_fatm.c:1573 #14 0x00000000c02615ec in ithread_loop (arg=0xfffff800011ce760) at /usr/src/sys/kern/kern_intr.c:1036 #15 0x00000000c025dd54 in fork_exit (callout=0xc0261420 , arg=0xfffff800011ce760, frame=0xe5391880) at /usr/src/sys/kern/kern_fork.c:781 #16 0x00000000c00711d0 in fork_trampoline () #17 0x00000000c00711d0 in fork_trampoline () Previous frame identical to this frame (corrupt stack?) (kgdb) up 15 #15 0x00000000c025dd54 in fork_exit (callout=0xc0261420 , arg=0xfffff800011ce760, frame=0xe5391880) at /usr/src/sys/kern/kern_fork.c:781 781 callout(arg, frame); (kgdb) list 776 * cpu_set_fork_handler intercepts this function call to 777 * have this call a non-return function to stay in kernel mode. 778 * initproc has its own fork handler, but it does return. 779 */ 780 KASSERT(callout != NULL, ("NULL callout in fork_exit")); 781 callout(arg, frame); 782 783 /* 784 * Check if a kernel thread misbehaved and returned from its main 785 * function. (kgdb) down #14 0x00000000c02615ec in ithread_loop (arg=0xfffff800011ce760) at /usr/src/sys/kern/kern_intr.c:1036 1036 ih->ih_handler(ih->ih_argument); (kgdb) list 1031 __func__, p->p_pid, (void *)ih->ih_handler, 1032 ih->ih_argument, ih->ih_name, ih->ih_flags); 1033 1034 if (!(ih->ih_flags & IH_MPSAFE)) 1035 mtx_lock(&Giant); 1036 ih->ih_handler(ih->ih_argument); 1037 if (!(ih->ih_flags & IH_MPSAFE)) 1038 mtx_unlock(&Giant); 1039 } 1040 if (!(ie->ie_flags & IE_SOFT)) (kgdb) down #13 0x00000000c013d410 in fatm_intr (p=0xfffff80001173c00) at /usr/src/sys/dev/fatm/if_fatm.c:1573 1573 atm_input(ifp, &aph, m0, vc->rxhand); (kgdb) list 1568 ifp->if_ipackets++; 1569 1570 vc->ipackets++; 1571 vc->ibytes += m0->m_pkthdr.len; 1572 1573 atm_input(ifp, &aph, m0, vc->rxhand); 1574 } 1575 1576 H_SETSTAT(q->q.statp, FATM_STAT_FREE); 1577 H_SYNCSTAT_PREWRITE(sc, q->q.statp); (kgdb) down #12 0x00000000c032a930 in atm_input (ifp=0xfffff8000103c000, ah=0xe539162c, m=0xfffff8005b354000, rxhand=0x0) at /usr/src/sys/net/if_atmsubr.c:347 347 netisr_dispatch(isr, m); (kgdb) list 342 else 343 m_freem(m); 344 return; 345 } 346 } 347 netisr_dispatch(isr, m); 348 } 349 350 /* 351 * Perform common duties while attaching to interface list. (kgdb) down #11 0x00000000c0339cd0 in netisr_dispatch (num=2, m=0xfffff8005b354000) at /usr/src/sys/net/netisr.c:185 185 ni->ni_handler(m); (kgdb) list 180 * the packet but now do not. Doing so here will 181 * not preserve ordering so instead we fallback to 182 * guaranteeing order only from dispatch points 183 * in the system (see above). 184 */ 185 ni->ni_handler(m); 186 } else { 187 isrstat.isrs_deferred++; 188 if (IF_HANDOFF(ni->ni_queue, m, NULL)) 189 schednetisr(num); (kgdb) down #10 0x00000000c0381128 in ip_input (m=0xfffff8005b354000) at /usr/src/sys/netinet/ip_input.c:665 665 (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen); (kgdb) list 660 /* 661 * Switch out to protocol's input routine. 662 */ 663 ipstat.ips_delivered++; 664 665 (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen); 666 return; 667 bad: 668 m_freem(m); 669 } (kgdb) down #9 0x00000000c03ec214 in tcp_input (m=0xfffff8005b354000, off0=Variable "off0" is not available. ) at /usr/src/sys/netinet/tcp_input.c:845 845 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen); (kgdb) list 840 /* 841 * Segment belongs to a connection in SYN_SENT, ESTABLISHED or later 842 * state. tcp_do_segment() always consumes the mbuf chain, unlocks 843 * the inpcb, and unlocks pcbinfo. 844 */ 845 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen); 846 INP_INFO_UNLOCK_ASSERT(&tcbinfo); 847 return; 848 849 dropwithreset: (kgdb) down #8 0x00000000c03eaf98 in tcp_do_segment (m=0xfffff8005b354000, th=0xfffff8000133283c, so=0xfffff800014be570, tp=0xfffff800014fce38, drop_hdrlen=52, tlen=0) at /usr/src/sys/netinet/tcp_input.c:2347 2347 (void) tcp_output(tp); (kgdb) list 2342 2343 /* 2344 * Return any desired output. 2345 */ 2346 if (needoutput || (tp->t_flags & TF_ACKNOW)) 2347 (void) tcp_output(tp); 2348 2349 check_delack: 2350 KASSERT(headlocked == 0, ("%s: check_delack: head locked", 2351 __func__)); (kgdb) down #7 0x00000000c03edac4 in tcp_output (tp=0xfffff800014fce38) at /usr/src/sys/netinet/tcp_output.c:802 802 mb = sbsndptr(&so->so_snd, off, len, &moff); (kgdb) list 797 798 /* 799 * Start the m_copy functions from the closest mbuf 800 * to the offset in the socket buffer chain. 801 */ 802 mb = sbsndptr(&so->so_snd, off, len, &moff); 803 804 if (len <= MHLEN - hdrlen - max_linkhdr) { 805 m_copydata(mb, moff, (int)len, 806 mtod(m, caddr_t) + hdrlen); (kgdb) down #6 0x00000000c03edac4 in tcp_output (tp=0xfffff800014be6f0) at /usr/src/sys/netinet/tcp_output.c:802 802 mb = sbsndptr(&so->so_snd, off, len, &moff); (kgdb) list 797 798 /* 799 * Start the m_copy functions from the closest mbuf 800 * to the offset in the socket buffer chain. 801 */ 802 mb = sbsndptr(&so->so_snd, off, len, &moff); 803 804 if (len <= MHLEN - hdrlen - max_linkhdr) { 805 m_copydata(mb, moff, (int)len, 806 mtod(m, caddr_t) + hdrlen); (kgdb) down #5 0x00000000c02dd1d0 in sbsndptr (sb=0xfffff800014be6f0, off=0, len=1390, moff=0xe5391064) at /usr/src/sys/kern/uipc_sockbuf.c:939 939 off > 0 && off >= m->m_len; (kgdb) list 934 *moff = off - sb->sb_sndptroff; 935 m = ret = sb->sb_sndptr ? sb->sb_sndptr : sb->sb_mb; 936 937 /* Advance by len to be as close as possible for the next transmit. */ 938 for (off = off - sb->sb_sndptroff + len - 1; 939 off > 0 && off >= m->m_len; 940 m = m->m_next) { 941 sb->sb_sndptroff += m->m_len; 942 off -= m->m_len; 943 } (kgdb) down #4 0x00000000c0070fe0 in tl1_trap () (kgdb) list 944 sb->sb_sndptr = m; 945 946 return (ret); 947 } 948 949 /* 950 * Drop a record off the front of a sockbuf and move the next record to the 951 * front. 952 */ 953 void (kgdb) quit sonnet.diablonet.net> Please let me know if further information is required and I will furnish, no problem. Thanks, -Sean From mj at mjturner.net Thu Nov 6 14:54:30 2008 From: mj at mjturner.net (Michael-John Turner) Date: Thu Nov 6 14:54:36 2008 Subject: Netra T1-200 debugging In-Reply-To: <20081106.121741.1300526614.johan@giantfoo.org> References: <20081104.192013.179942973.johan@giantfoo.org> <20081106173311.GH25025@aurora.pimp.org.za> <20081106.121741.1300526614.johan@giantfoo.org> Message-ID: <20081106225422.GD4262@aurora.pimp.org.za> On Thu, Nov 06, 2008 at 12:17:41PM -0600, Johan A. van Zanten wrote: > I think i based my info on this: > > http://sunsolve.sun.com/handbook_pub/validateUser.do?target=Systems/Netra_T1_AC200_shared/spec Odd that there's a discrepancy. Unfortunately my system doesn't have a model number on the front - it only says 'Netra T1' and the platform is 'SUNW,UltraAX-i2'. According to this list[1] it's definitely a T1 AC200 though. [1] http://www.sunshack.org/data/sh/2.1.8/infoserver.central/data/syshbk/General/S10_Platform_Names.html -mj -- Michael-John Turner mj@mjturner.net <> http://mjturner.net/ From mj at mjturner.net Thu Nov 6 15:02:22 2008 From: mj at mjturner.net (Michael-John Turner) Date: Thu Nov 6 15:02:27 2008 Subject: Netra T1-200 debugging In-Reply-To: <20081106225422.GD4262@aurora.pimp.org.za> References: <20081104.192013.179942973.johan@giantfoo.org> <20081106173311.GH25025@aurora.pimp.org.za> <20081106.121741.1300526614.johan@giantfoo.org> <20081106225422.GD4262@aurora.pimp.org.za> Message-ID: <20081106230200.GE4262@aurora.pimp.org.za> On Thu, Nov 06, 2008 at 10:54:22PM +0000, Michael-John Turner wrote: > Odd that there's a discrepancy. Unfortunately my system doesn't have a > model number on the front - it only says 'Netra T1' and the platform is > 'SUNW,UltraAX-i2'. According to this list[1] it's definitely a T1 AC200 > though. > > [1] http://www.sunshack.org/data/sh/2.1.8/infoserver.central/data/syshbk/General/S10_Platform_Names.html Ok, I should investigate things _first_. Apparently the cache size is 256KiB - NetBSD just reports it incorrectly [2]. Apologies for the noise. [2] http://archive.netbsd.se/?ml=port-sparc64&a=2007-11&m=5782771 -mj -- Michael-John Turner mj@mjturner.net <> http://mjturner.net/ From tinderbox at freebsd.org Thu Nov 6 15:34:11 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Nov 6 15:34:39 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081106233408.326F773039@freebsd-current.sentex.ca> TB --- 2008-11-06 22:31:38 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-11-06 22:31:38 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-06 22:31:38 - cleaning the object tree TB --- 2008-11-06 22:32:13 - cvsupping the source tree TB --- 2008-11-06 22:32:13 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-06 22:32:21 - building world (CFLAGS=-O -pipe) TB --- 2008-11-06 22:32:21 - cd /src TB --- 2008-11-06 22:32:21 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 6 22:32:23 UTC 2008 >>> 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 [...] ===> usr.bin/dirname (all) cc -O -pipe -fstack-protector -c /src/usr.bin/dirname/dirname.c cc -O -pipe -fstack-protector -o dirname dirname.o ===> usr.bin/du (all) cc -O -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/du/du.c cc1: warnings being treated as errors /src/usr.bin/du/du.c: In function 'main': /src/usr.bin/du/du.c:276: warning: format '%jd' expects type 'intmax_t', but argument 2 has type 'long long int' *** Error code 1 Stop in /src/usr.bin/du. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-06 23:34:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-06 23:34:07 - ERROR: failed to build world TB --- 2008-11-06 23:34:07 - tinderbox aborted TB --- 2657.12 user 339.60 system 3749.73 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From max at love2party.net Thu Nov 6 16:02:19 2008 From: max at love2party.net (Max Laier) Date: Thu Nov 6 16:02:35 2008 Subject: [head tinderbox] failure on sparc64/sparc64 In-Reply-To: <20081106233408.326F773039@freebsd-current.sentex.ca> References: <20081106233408.326F773039@freebsd-current.sentex.ca> Message-ID: <200811070049.40852.max@love2party.net> On Friday 07 November 2008 00:34:08 FreeBSD Tinderbox wrote: > TB --- 2008-11-06 22:31:38 - tinderbox 2.3 running on > freebsd-current.sentex.ca TB --- 2008-11-06 22:31:38 - starting HEAD > tinderbox run for sparc64/sparc64 TB --- 2008-11-06 22:31:38 - cleaning the > object tree > TB --- 2008-11-06 22:32:13 - cvsupping the source tree > TB --- 2008-11-06 22:32:13 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s > /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-06 22:32:21 - > building world (CFLAGS=-O -pipe) > TB --- 2008-11-06 22:32:21 - cd /src > TB --- 2008-11-06 22:32:21 - /usr/bin/make -B buildworld > > >>> World build started on Thu Nov 6 22:32:23 UTC 2008 > >>> 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 > > [...] > ===> usr.bin/dirname (all) > cc -O -pipe -fstack-protector -c /src/usr.bin/dirname/dirname.c > cc -O -pipe -fstack-protector -o dirname dirname.o > ===> usr.bin/du (all) > cc -O -pipe -fstack-protector -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wno-pointer-sign -c /src/usr.bin/du/du.c cc1: warnings being treated as > errors > /src/usr.bin/du/du.c: In function 'main': > /src/usr.bin/du/du.c:276: warning: format '%jd' expects type 'intmax_t', > but argument 2 has type 'long long int' *** Error code 1 ups ... my bad, I'll fix it. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From tinderbox at freebsd.org Thu Nov 6 16:07:38 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Nov 6 16:07:49 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20081107000735.2B4E573039@freebsd-current.sentex.ca> TB --- 2008-11-06 23:11:44 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-11-06 23:11:44 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-11-06 23:11:44 - cleaning the object tree TB --- 2008-11-06 23:12:11 - cvsupping the source tree TB --- 2008-11-06 23:12:11 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-11-06 23:12:18 - building world (CFLAGS=-O -pipe) TB --- 2008-11-06 23:12:18 - cd /src TB --- 2008-11-06 23:12:18 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 6 23:12:20 UTC 2008 >>> 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 [...] ===> usr.bin/dirname (all) cc -O -pipe -fstack-protector -c /src/usr.bin/dirname/dirname.c cc -O -pipe -fstack-protector -o dirname dirname.o ===> usr.bin/du (all) cc -O -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/du/du.c cc1: warnings being treated as errors /src/usr.bin/du/du.c: In function 'main': /src/usr.bin/du/du.c:276: warning: format '%jd' expects type 'intmax_t', but argument 2 has type 'long long int' *** Error code 1 Stop in /src/usr.bin/du. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-07 00:07:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-07 00:07:35 - ERROR: failed to build world TB --- 2008-11-07 00:07:35 - tinderbox aborted TB --- 2631.84 user 332.70 system 3350.66 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Thu Nov 6 19:50:08 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Nov 6 19:50:15 2008 Subject: [releng_7 tinderbox] failure on sparc64/sparc64 Message-ID: <20081107035005.825A21B5078@freebsd-stable.sentex.ca> TB --- 2008-11-07 02:39:08 - tinderbox 2.4 running on freebsd-stable.sentex.ca TB --- 2008-11-07 02:39:08 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2008-11-07 02:39:08 - cleaning the object tree TB --- 2008-11-07 02:39:22 - cvsupping the source tree TB --- 2008-11-07 02:39:22 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2008-11-07 02:39:30 - building world (CFLAGS=-O2 -pipe) TB --- 2008-11-07 02:39:30 - cd /src TB --- 2008-11-07 02:39:30 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 7 02:39:31 UTC 2008 >>> 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 Nov 7 03:42:34 UTC 2008 TB --- 2008-11-07 03:42:34 - generating LINT kernel config TB --- 2008-11-07 03:42:34 - cd /src/sys/sparc64/conf TB --- 2008-11-07 03:42:34 - /usr/bin/make -B LINT TB --- 2008-11-07 03:42:34 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-11-07 03:42:34 - cd /src TB --- 2008-11-07 03:42:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 7 03:42:34 UTC 2008 >>> 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 -Werror /src/sys/kern/kern_mutex.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 -Werror /src/sys/kern/kern_ntptime.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 -Werror /src/sys/kern/kern_physio.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 -Werror /src/sys/kern/kern_pmc.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 -Werror /src/sys/kern/kern_priv.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 -Werror /src/sys/kern/kern_proc.c /src/sys/kern/kern_proc.c: In function 'sysctl_kern_proc_vmmap': /src/sys/kern/kern_proc.c:1454: error: too few arguments to function 'VOP_GETATTR' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-07 03:50:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-07 03:50:05 - ERROR: failed to build lint kernel TB --- 2008-11-07 03:50:05 - tinderbox aborted TB --- 3572.13 user 364.69 system 4256.62 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full From yraffah at sadeem.net Fri Nov 7 23:23:47 2008 From: yraffah at sadeem.net (Yousef Raffah) Date: Fri Nov 7 23:23:54 2008 Subject: getty or X problem on Ultra 10 Message-ID: <562D44D4-A834-43AA-AC2D-3A13D1B366FB@sadeem.net> Hello Everyone, This is the first time for me to play with FreeBSD on a SPARC64 machine. I have Ultra 10 box sitting next to me doing nothing so I figured why not make use of that machine. The installation of 7- RELEASE went fine and everything seems to be normal on the Sun monitor connected to it through that "strange" cable. However, I want to hook it up to a bigger screen through the VGA card available on the same box and here starts my problem. When I connect the cable to any monitor from that VGA card (ATI Rage 3D) it shows nothing (white screen). I thought maybe I need to change some parameters with vidcontrol but I couldn't figure out how. Later on I decided to install X and give it a shot but that still didn't help. I tried different X configurations (Dual monitors as well as a simple single vga screen) but without any luck. However, there is one thing I noticed, whenever the machine boots, I get some getty messages on the console complaining as: open /dev/screen: No such file or directory open /dev/ttya: No such file or directory open /dev/ttyu2: No such file or directory When I start X it spits out: xf86MapVidMem: could not mmap screen [s=2000, a=e2000000] (Invalid argument). Unfortunately googling that statement does bring out much of helpful threads, therefore, I thought of joining the team here to check if there is anything I can try or if any of you had such a problem and how it was solved, if it ever was :) From marius at alchemy.franken.de Sun Nov 9 10:12:06 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Sun Nov 9 10:12:14 2008 Subject: getty or X problem on Ultra 10 In-Reply-To: <562D44D4-A834-43AA-AC2D-3A13D1B366FB@sadeem.net> References: <562D44D4-A834-43AA-AC2D-3A13D1B366FB@sadeem.net> Message-ID: <20081109181204.GA76319@alchemy.franken.de> On Sat, Nov 08, 2008 at 10:02:39AM +0300, Yousef Raffah wrote: > Hello Everyone, > > This is the first time for me to play with FreeBSD on a SPARC64 > machine. I have Ultra 10 box sitting next to me doing nothing so I > figured why not make use of that machine. The installation of 7- > RELEASE went fine and everything seems to be normal on the Sun monitor > connected to it through that "strange" cable. However, I want to hook > it up to a bigger screen through the VGA card available on the same > box and here starts my problem. When I connect the cable to any > monitor from that VGA card (ATI Rage 3D) it shows nothing (white > screen). I thought maybe I need to change some parameters with > vidcontrol but I couldn't figure out how. Later on I decided to > install X and give it a shot but that still didn't help. I tried > different X configurations (Dual monitors as well as a simple single > vga screen) but without any luck. > > However, there is one thing I noticed, whenever the machine boots, I > get some getty messages on the console complaining as: > open /dev/screen: No such file or directory > open /dev/ttya: No such file or directory > open /dev/ttyu2: No such file or directory This is nothing to worry about, /dev/screen and /dev/ttya are disabled in /etc/ttys by default though. > > When I start X it spits out: xf86MapVidMem: could not mmap screen > [s=2000, a=e2000000] (Invalid argument). Unfortunately googling that > statement does bring out much of helpful threads, therefore, I thought > of joining the team here to check if there is anything I can try or if > any of you had such a problem and how it was solved, if it ever was :) > For machfb0 (the on-board ATI Rage 3D) to be usable by X it must be the primary framebuffer, with an AFB or FFB card (the card with the "strange" 13W3 connector) present in a U5/U10 the firmware automatically assigns the "screen" alias to the AFB/FFB though, thus making the AFB/FFB the primary one. Similarly, syscons(4) also will only use the primary one for output. So in order to make the on-board ATI Rage 3D work you need to either pull the AFB/FFB card or set the Open Firmware environment variable "output-device" to the full path of the ATI Rage 3D instead of the "screen" alias. If you want to run X with that setup, make sure there's no "BusID" option in the section for the "ati" driver left from when using "sunffb". I'm not sure whether it's currently possible to run a dual-monitor setup with this and X.org as I had no machine where the firmware would allow a combination of AFB/FFB card and a MACHFB back when I tried to test that. In theory it should work though but would also require the MACHFB to be the primary framebuffer and the "BusID" set to "SBUS:fb0" for the "sunffb" driver. Marius From marius at alchemy.franken.de Sun Nov 9 10:20:19 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Sun Nov 9 10:20:25 2008 Subject: Occasional kernel panic + reboot on 7.0-RELEASE with fatm driver. In-Reply-To: <20081106131717.331718q66y289lgk@web.mail.umich.edu> References: <20081106131717.331718q66y289lgk@web.mail.umich.edu> Message-ID: <20081109182017.GB76319@alchemy.franken.de> On Thu, Nov 06, 2008 at 01:17:17PM -0500, Sean Thomas Caron wrote: > Hi folks, > > I'm using fatm on FreeBSD/sparc64 7.0-RELEASE; it generally works well > but every couple of weeks the system will kernel panic and reboot. I > switched on kernel dumps on panic and here's what I got (this time): > > sonnet.diablonet.net> kgdb kernel.debug /var/crash/vmcore.0 > kgdb: kvm_nlist(_stopped_cpus): > kgdb: kvm_nlist(_stoppcbs): > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "sparc64-marcel-freebsd". > > Unread portion of the kernel message buffer: > panic: trap: fast data access mmu miss <...> This apparently is a NULL-pointer dereference (probably "m" in sbsndptr()), with the cause being in one of the stacks involved. I'd suggest to report this backtrace to the atm@ and net@ lists. Marius From marius at alchemy.franken.de Sun Nov 9 10:32:36 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Sun Nov 9 10:32:42 2008 Subject: kgdb on sparc64 In-Reply-To: <20081105195630.GA52831@ei.bzerk.org> References: <20081103120215.GA32257@ei.bzerk.org> <20081103221111.GA8256@alchemy.franken.de> <20081105195630.GA52831@ei.bzerk.org> Message-ID: <20081109183232.GC76319@alchemy.franken.de> On Wed, Nov 05, 2008 at 08:56:30PM +0100, Ruben de Groot wrote: > On Mon, Nov 03, 2008 at 11:11:11PM +0100, Marius Strobl typed: > > > > After upgrading to 7.1-PRERELEASE last month I'm seeing some > > > spontaneous reboots with crash dumps on this Netra X1. How > > > can I debug this as kgdb seems not to be working? > > [...] > > > I've never had much luck with kgdb(1) on any arch and use > > devel/gdb53 which still has '-k' instead (for sparc64 just > > remove the BROKEN from the port Makefile; the problem > > leading to that one being added was fixed some time a go). > > The installation of gbd53 fails unfortunately with: > > gmake[1]: Leaving directory `/usr/ports/devel/gdb53/work/gdb-5.3/sparc64-portbld-freebsd7.1/libiberty' > gmake[1]: Entering directory `/usr/ports/devel/gdb53/work/gdb-5.3/libiberty' > rm -f libiberty.a pic/libiberty.a > sparc64-unknown-freebsd7.1-ar rc libiberty.a \ > regex.o cplus-dem.o cp-demangle.o md5.o alloca.o argv.o choose-temp.o concat.o dyn-string.o fdmatch.o fibheap.o floatformat.o fnmatch.o getopt.o getopt1.o getpwd.o getruntime.o hashtab.o hex.o lbasename.o make-temp-file.o objalloc.o obstack.o partition.o pexecute.o safe-ctype.o sort.o spaces.o splay-tree.o strerror.o strsignal.o ternary.o xatexit.o xexit.o xmalloc.o xmemdup.o xstrdup.o xstrerror.o > gmake[1]: sparc64-unknown-freebsd7.1-ar: Command not found > gmake[1]: *** [libiberty.a] Error 127 > gmake[1]: Leaving directory `/usr/ports/devel/gdb53/work/gdb-5.3/libiberty' > gmake: *** [all-libiberty] Error 2 > *** Error code 2 > > Stop in /usr/ports/devel/gdb53. Oh, apparently it has developed a new problem since the gcc34 problem was fixed in February, sorry... > > > For your purposes it's probably simpler to just build a > > kernel with debugger by adding "options DDB", "options KDB" > > and "makeoptions DEBUG=-g". Then when the kernel panics > > just enter "backtrace" on the console. With a X1 you > > most likely use serial console anyway so you can easily > > capture the output. > > I'll build a kernel with those options just in case. But > would rather not use it on this particular machine, as it is > a production server and should not be down for extended periods > of time. If you additionally either also add "options KDB_TRACE" and "options KDB_UNATTENDED" or set "debug.trace_on_panic=1" and "debug.debugger_on_panic=0" via sysctl(8) with a debugger-enabled kernel, the debugger will automatically print a backtrace to the console and then reboot the machine and thus minimizing downtime. Printing the backtrace might require the latest 7-STABLE though. > Meanwhile, moving over websites to another machine (another X1, > but running -current) that seems to be more stable ATM. > That's what puzzles me as every sparc64-specific change in 7-STABLE since 7.0-RELEASE also is in -current except for one stricter check in -current. So I guess you're hitting one of the MI stability issues people are reporting for 7.1-PRERELEASE. Marius From bugmaster at FreeBSD.org Mon Nov 10 03:06:58 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 10 03:09:08 2008 Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org Message-ID: <200811101106.mAAB6vUu049857@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 7.0 Beta won't install on U60 o sparc/118932 sparc64 7.0-BETA4/sparc-64 kernel panic in rip_output o sparc/113556 sparc64 panic: trap: memory address not aligned; Rebooting... o sparc/109908 sparc64 apache22 mod_perl issue on sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 s sparc/107087 sparc64 system is hinged 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 17 problems total. From marius at alchemy.franken.de Mon Nov 10 14:27:47 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Mon Nov 10 14:27:57 2008 Subject: Booting of snapshot-iso on SUN Fire V280R In-Reply-To: <20081029140204.GS5156@darkthrone.kvedulv.de> References: <20081028172823.GO5156@darkthrone.kvedulv.de> <20081028221321.GA32214@alchemy.franken.de> <20081029001112.GR5156@darkthrone.kvedulv.de> <20081029081558.GB31338@alchemy.franken.de> <20081029140204.GS5156@darkthrone.kvedulv.de> Message-ID: <20081110222744.GA64456@alchemy.franken.de> On Wed, Oct 29, 2008 at 03:02:04PM +0100, Michael Moll wrote: > Hi Marius, > > On Wed, Oct 29, 2008 at 09:15:58AM +0100, Marius Strobl wrote: > > > I'm uploading a new one at: > > http://people.freebsd.org/~marius/8.0-20081028-SNAP-sparc64-disc1.iso.gz > > Besides one LOR everything seems fine now, thanks a lot! :) > > Sun Fire 280R (2 X UltraSPARC-III+) , No Keyboard > Copyright 1998-2004 Sun Microsystems, Inc. All rights reserved. > OpenBoot 4.16.4, 8192 MB memory installed, Serial #53054758. > Ethernet address 0:3:ba:29:8d:26, Host ID: 83298d26. > Could you please give the patch at: http://people.freebsd.org/~marius/schizo_cdma.diff a try with that machine? The patch implements the consistent DMA syncing required for devices behind PCI-PCI, f.e. your HMEs, for Schizo version >= 5. I.e. please test, whether the machine still boots with the patch in place and using a HME just works and increases the vec566: pcib0 counter (I hope I got the numbers right; well, see `vmstat -i` for pcib interrupts). Thanks, Marius From yraffah at sadeem.net Tue Nov 11 02:53:02 2008 From: yraffah at sadeem.net (Yousef Raffah) Date: Tue Nov 11 02:53:09 2008 Subject: getty or X problem on Ultra 10 In-Reply-To: <20081109181204.GA76319@alchemy.franken.de> References: <562D44D4-A834-43AA-AC2D-3A13D1B366FB@sadeem.net> <20081109181204.GA76319@alchemy.franken.de> Message-ID: <137CB3D0-F0B5-4092-B352-EBE7B2946346@sadeem.net> On Nov 9, 2008, at 9:12 PM, Marius Strobl wrote: > On Sat, Nov 08, 2008 at 10:02:39AM +0300, Yousef Raffah wrote: >> Hello Everyone, >> >> This is the first time for me to play with FreeBSD on a SPARC64 >> machine. I have Ultra 10 box sitting next to me doing nothing so I >> figured why not make use of that machine. The installation of 7- >> RELEASE went fine and everything seems to be normal on the Sun >> monitor >> connected to it through that "strange" cable. However, I want to hook >> it up to a bigger screen through the VGA card available on the same >> box and here starts my problem. When I connect the cable to any >> monitor from that VGA card (ATI Rage 3D) it shows nothing (white >> screen). I thought maybe I need to change some parameters with >> vidcontrol but I couldn't figure out how. Later on I decided to >> install X and give it a shot but that still didn't help. I tried >> different X configurations (Dual monitors as well as a simple single >> vga screen) but without any luck. >> >> However, there is one thing I noticed, whenever the machine boots, I >> get some getty messages on the console complaining as: >> open /dev/screen: No such file or directory >> open /dev/ttya: No such file or directory >> open /dev/ttyu2: No such file or directory > > This is nothing to worry about, /dev/screen and /dev/ttya > are disabled in /etc/ttys by default though. > OK :) >> >> When I start X it spits out: xf86MapVidMem: could not mmap screen >> [s=2000, a=e2000000] (Invalid argument). Unfortunately googling that >> statement does bring out much of helpful threads, therefore, I >> thought >> of joining the team here to check if there is anything I can try or >> if >> any of you had such a problem and how it was solved, if it ever >> was :) >> > > For machfb0 (the on-board ATI Rage 3D) to be usable by > X it must be the primary framebuffer, with an AFB or FFB > card (the card with the "strange" 13W3 connector) present > in a U5/U10 the firmware automatically assigns the "screen" > alias to the AFB/FFB though, thus making the AFB/FFB the > primary one. Similarly, syscons(4) also will only use the > primary one for output. So in order to make the on-board > ATI Rage 3D work you need to either pull the AFB/FFB card > or set the Open Firmware environment variable "output-device" > to the full path of the ATI Rage 3D instead of the "screen" > alias. If you want to run X with that setup, make sure > there's no "BusID" option in the section for the "ati" > driver left from when using "sunffb". I'm not sure whether > it's currently possible to run a dual-monitor setup with > this and X.org as I had no machine where the firmware would > allow a combination of AFB/FFB card and a MACHFB back when > I tried to test that. In theory it should work though but > would also require the MACHFB to be the primary framebuffer > and the "BusID" set to "SBUS:fb0" for the "sunffb" driver. This solved my problem, thanks a lot Marius. From kvedulv at kvedulv.de Tue Nov 11 09:04:13 2008 From: kvedulv at kvedulv.de (Michael Moll) Date: Tue Nov 11 09:04:20 2008 Subject: Booting of snapshot-iso on SUN Fire V280R In-Reply-To: <20081110222744.GA64456@alchemy.franken.de> References: <20081028172823.GO5156@darkthrone.kvedulv.de> <20081028221321.GA32214@alchemy.franken.de> <20081029001112.GR5156@darkthrone.kvedulv.de> <20081029081558.GB31338@alchemy.franken.de> <20081029140204.GS5156@darkthrone.kvedulv.de> <20081110222744.GA64456@alchemy.franken.de> Message-ID: <20081111170407.GS5156@darkthrone.kvedulv.de> Hi Marius, On Mon, Nov 10, 2008 at 11:27:44PM +0100, Marius Strobl wrote: > Could you please give the patch at: > http://people.freebsd.org/~marius/schizo_cdma.diff > a try with that machine? The patch implements the consistent > DMA syncing required for devices behind PCI-PCI, f.e. your > HMEs, for Schizo version >= 5. I.e. please test, whether > the machine still boots with the patch in place and using > a HME just works and increases the vec566: pcib0 counter > (I hope I got the numbers right; well, see `vmstat -i` > for pcib interrupts). Seems all fine, I attached verbose bootmessages. I tried one HME interface and it seems to work, counters increase also: server01# vmstat -i interrupt total rate pil4: ast 51249 67 pil13: fast 38 0 vec566: pcib0 38 0 pil12: filter 243 0 vec557: uart1 234 0 vec546: scc0 9 0 pil2: ithrd 28443 37 vec541: gem0 28048 36 vec536: sym0 72 0 vec537: sym1 30 0 vec532: hme3 38 0 vec516: isp0 255 0 pil14: tick 1516484 1987 Total 1625181 2129 [ping the machine's hme3 a while] server01# vmstat -i interrupt total rate pil4: ast 51707 66 pil13: fast 58 0 vec566: pcib0 58 0 pil12: filter 243 0 vec557: uart1 234 0 vec546: scc0 9 0 pil2: ithrd 28540 36 vec541: gem0 28125 36 vec536: sym0 72 0 vec537: sym1 30 0 vec532: hme3 58 0 vec516: isp0 255 0 pil14: tick 1535350 1986 Total 1644739 2127 Best Regards -- Michael Moll e-mail : kvedulv@kvedulv.de WWW : http://www.kvedulv.de/ GSM : +49 175 606 7861 -------------- next part -------------- GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Tue Nov 11 13:22:46 UTC 2008 root@flame.kvedulv.de:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b40000. real memory = 8589934592 (8192 MB) avail memory = 8385699840 (7997 MB) machine: SUNW,Sun-Fire-280R cpu0: Sun Microsystems UltraSparc-III+ Processor (900.00 MHz CPU) mask=0x22 maxtl=5 maxwin=7 initalizing intr_countp cpu1: Sun Microsystems UltraSparc-III+ Processor (900.00 MHz CPU) mask=0x22 maxtl=5 maxwin=7 INTR: Adding CPU 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs wlan: <802.11 Link Layer> ath_rate: version 1.2 firmware: 'isp_1000' version 1: 20142 bytes loaded at 0xc0618758 ispfw: registered firmware firmware: 'isp_1040' version 1: 22944 bytes loaded at 0xc061d606 ispfw: registered firmware firmware: 'isp_1040_it' version 1: 32942 bytes loaded at 0xc0622fa6 ispfw: registered firmware firmware: 'isp_1080' version 1: 31350 bytes loaded at 0xc062b054 ispfw: registered firmware firmware: 'isp_1080_it' version 1: 40644 bytes loaded at 0xc0632aca ispfw: registered firmware firmware: 'isp_12160' version 1: 28050 bytes loaded at 0xc063c98e ispfw: registered firmware firmware: 'isp_12160_it' version 1: 40604 bytes loaded at 0xc0643720 ispfw: registered firmware firmware: 'isp_2100' version 1: 76770 bytes loaded at 0xc064d5bc ispfw: registered firmware firmware: 'isp_2200' version 1: 77214 bytes loaded at 0xc066019e ispfw: registered firmware firmware: 'isp_2300' version 1: 105078 bytes loaded at 0xc0672f3c ispfw: registered firmware firmware: 'isp_2322' version 1: 108856 bytes loaded at 0xc068c9b2 ispfw: registered firmware firmware: 'isp_2400' version 1: 172952 bytes loaded at 0xc06aa56c ispfw: registered firmware random: nfslock: pseudo-device kbd0 at kbdmux0 mem: null: openfirm: ath_hal: 0.10.5.10 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417, REGOPS_FUNC) nexus0: nexus0: mem 0x40000400000-0x40000400047 type memory-controller (no driver attached) nexus0: mem 0x40000c00000-0x40000c00047 type memory-controller (no driver attached) pcib0: mem 0x40004700000-0x40004717fff,0x40004410000-0x4000441004f,0x7ffee000000-0x7ffee0000ff irq 563,560,561,564,550 on nexus0 pcib0: Schizo, version 5, IGN 0x8, bus B, 33MHz pcib0: DVMA map: 0xc0000000 to 0xffffffff pcib0: bus range 0 to 1; PCI bus 0 pcib0: [FILTER] pcib0: [FILTER] pcib0: [FILTER] pcib0: [FILTER] pcib0: [FILTER] pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x108e, dev=0x8001, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x108e, dev=0x1100, revid=0x01 domain=0, bus=0, slot=5, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0146, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x50 (2400 ns), mingnt=0x0a (2500 ns), maxlat=0x19 (6250 ns) map[10]: type Memory, range 32, base 0x7d000000, size 24, enabled map[14]: type Memory, range 32, base 0x7e000000, size 23, enabled found-> vendor=0x108e, dev=0x1101, revid=0x01 domain=0, bus=0, slot=5, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0146, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x50 (2400 ns), mingnt=0x0a (2500 ns), maxlat=0x05 (1250 ns) map[10]: type Memory, range 32, base 0x100000, size 17, enabled found-> vendor=0x108e, dev=0x1103, revid=0x01 domain=0, bus=0, slot=5, func=3 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x50 (2400 ns), mingnt=0x0a (2500 ns), maxlat=0x05 (1250 ns) map[10]: type Memory, range 32, base 0x1000000, size 15, memory disabled found-> vendor=0x1000, dev=0x000f, revid=0x37 domain=0, bus=0, slot=6, func=0 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0146, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x88 (4080 ns), mingnt=0x11 (4250 ns), maxlat=0x40 (16000 ns) intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0x300, size 8, port disabled map[14]: type Memory, range 32, base 0x124000, size 8, enabled map[18]: type Memory, range 32, base 0x126000, size 12, enabled found-> vendor=0x1000, dev=0x000f, revid=0x37 domain=0, bus=0, slot=6, func=1 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0146, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x88 (4080 ns), mingnt=0x11 (4250 ns), maxlat=0x40 (16000 ns) intpin=b, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0x400, size 8, port disabled map[14]: type Memory, range 32, base 0x128000, size 8, enabled map[18]: type Memory, range 32, base 0x12a000, size 12, enabled found-> vendor=0x8086, dev=0xb154, revid=0x00 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x23 (8750 ns), maxlat=0x00 (0 ns) powerspec 1 supports D0 D3 current D0 ebus0: mem 0x7d000000-0x7dffffff,0x7e000000-0x7e7fffff at device 5.0 on pci0 ebus0: Reserved 0x1000000 bytes for rid 0x10 type 3 at 0x7d000000 ebus0: Reserved 0x800000 bytes for rid 0x14 type 3 at 0x7e000000 ebus0: addr 0-0x1fffff (no driver attached) ebus0: addr 0x10000002e-0x10000002f,0x10000002d irq 35 (no driver attached) ebus0: addr 0x100000000-0x1000fffff (no driver attached) ebus0: addr 0x10030002e-0x10030002f,0x100300600-0x100300607 (no driver attached) ebus0: addr 0x100000030-0x100000031 irq 35 (no driver attached) ebus0: addr 0x100000032-0x100000037 (no driver attached) rtc0: addr 0x100300070-0x100300071 irq 36 on ebus0 rtc0: registered as a time-of-day clock (resolution 1000000us) ct_to_ts([2008-11-11 16:38:47]) = 1226421527.000000000 rtc0: current time: 1226421527.000000000 ebus0: addr 0x100300600-0x100300607 (no driver attached) ebus0: addr 0x100300700-0x100300701 (no driver attached) ebus0: addr 0x100300278-0x100300287,0x10030002e-0x10030002f,0x100700000-0x10070000f irq 28 (no driver attached) uart0: <16550 or compatible> addr 0x1003062f8-0x1003062ff irq 46 on ebus0 uart0: [FILTER] uart0: fast interrupt uart1: <16550 or compatible> addr 0x1003083f8-0x1003083ff irq 45 on ebus0 uart1: [FILTER] uart1: fast interrupt uart1: console (115200,n,8,1) scc0: addr 0x100400000-0x10040007f irq 34 on ebus0 scc0: resetting hardware scc0: [FILTER] uart2: on scc0 uart2: [FILTER] uart2: CTS oflow uart2: fast interrupt uart3: on scc0 uart3: [FILTER] uart3: CTS oflow uart3: fast interrupt scc0: fast interrupt gem0: mem 0x100000-0x11ffff at device 5.1 on pci0 gem0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0x100000 miibus0: on gem0 ukphy0: PHY 1 on miibus0 ukphy0: OUI 0x00601d, model 0x000c, rev. 1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto gem0: 2kB RX FIFO, 2kB TX FIFO gem0: bpf attached gem0: Ethernet address: 00:03:ba:29:8d:26 gem0: [MPSAFE] gem0: [ITHREAD] ohci0: mem 0x1000000-0x1007fff at device 5.3 on pci0 ohci0: Reserved 0x8000 bytes for rid 0x10 type 3 at 0x1000000 ohci0: (New OHCI DeviceId=0x1103108e) ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: <(0x108e) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0 uhub0: 4 ports with 4 removable, self powered sym0: <875> port 0x300-0x3ff mem 0x124000-0x1240ff,0x126000-0x126fff at device 6.0 on pci0 sym0: Reserved 0x100 bytes for rid 0x14 type 3 at 0x124000 sym0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0x126000 sym0: chip clock is 40218KHz sym0: No NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: [MPSAFE] sym0: [ITHREAD] sym1: <875> port 0x400-0x4ff mem 0x128000-0x1280ff,0x12a000-0x12afff at device 6.1 on pci0 sym1: Reserved 0x100 bytes for rid 0x14 type 3 at 0x128000 sym1: Reserved 0x1000 bytes for rid 0x18 type 3 at 0x12a000 sym1: chip clock is 40218KHz sym1: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: [MPSAFE] sym1: [ITHREAD] pcib1: at device 3.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x1000-0xfff pcib1: memory decode 0x2000000-0x10ffffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x108e, dev=0x1000, revid=0x01 domain=0, bus=1, slot=0, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x50 (2400 ns), mingnt=0x0a (2500 ns), maxlat=0x19 (6250 ns) intpin=a, irq=255 map[10]: type Memory, range 32, base 0x2000000, size 24, enabled pcib1: requested memory range 0x2000000-0x2ffffff: good map[14]: type Memory, range 32, base 0x3000000, size 23, enabled pcib1: requested memory range 0x3000000-0x37fffff: good found-> vendor=0x108e, dev=0x1001, revid=0x01 domain=0, bus=1, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x50 (2400 ns), mingnt=0x0a (2500 ns), maxlat=0x05 (1250 ns) intpin=b, irq=255 map[10]: type Memory, range 32, base 0x3800000, size 15, enabled pcib1: requested memory range 0x3800000-0x3807fff: good found-> vendor=0x108e, dev=0x1000, revid=0x01 domain=0, bus=1, slot=1, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x50 (2400 ns), mingnt=0x0a (2500 ns), maxlat=0x19 (6250 ns) intpin=a, irq=255 map[10]: type Memory, range 32, base 0x6000000, size 24, enabled pcib1: requested memory range 0x6000000-0x6ffffff: good map[14]: type Memory, range 32, base 0x7000000, size 23, enabled pcib1: requested memory range 0x7000000-0x77fffff: good found-> vendor=0x108e, dev=0x1001, revid=0x01 domain=0, bus=1, slot=1, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x50 (2400 ns), mingnt=0x0a (2500 ns), maxlat=0x05 (1250 ns) intpin=b, irq=255 map[10]: type Memory, range 32, base 0x3808000, size 15, enabled pcib1: requested memory range 0x3808000-0x380ffff: good found-> vendor=0x108e, dev=0x1000, revid=0x01 domain=0, bus=1, slot=2, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x50 (2400 ns), mingnt=0x0a (2500 ns), maxlat=0x19 (6250 ns) intpin=a, irq=255 map[10]: type Memory, range 32, base 0xa000000, size 24, enabled pcib1: requested memory range 0xa000000-0xaffffff: good map[14]: type Memory, range 32, base 0x7800000, size 23, enabled pcib1: requested memory range 0x7800000-0x7ffffff: good found-> vendor=0x108e, dev=0x1001, revid=0x01 domain=0, bus=1, slot=2, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x50 (2400 ns), mingnt=0x0a (2500 ns), maxlat=0x05 (1250 ns) intpin=b, irq=255 map[10]: type Memory, range 32, base 0x3810000, size 15, enabled pcib1: requested memory range 0x3810000-0x3817fff: good found-> vendor=0x108e, dev=0x1000, revid=0x01 domain=0, bus=1, slot=3, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x50 (2400 ns), mingnt=0x0a (2500 ns), maxlat=0x19 (6250 ns) intpin=a, irq=255 map[10]: type Memory, range 32, base 0xd000000, size 24, enabled pcib1: requested memory range 0xd000000-0xdffffff: good map[14]: type Memory, range 32, base 0xe000000, size 23, enabled pcib1: requested memory range 0xe000000-0xe7fffff: good found-> vendor=0x108e, dev=0x1001, revid=0x01 domain=0, bus=1, slot=3, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x50 (2400 ns), mingnt=0x0a (2500 ns), maxlat=0x05 (1250 ns) intpin=b, irq=255 map[10]: type Memory, range 32, base 0x3818000, size 15, enabled pcib1: requested memory range 0x3818000-0x381ffff: good pci1: at device 0.0 (no driver attached) hme0: mem 0x3800000-0x3807fff at device 0.1 on pci1 hme0: Reserved 0x8000 bytes for rid 0x10 type 3 at 0x3800000 pcib1: slot 0 INTB is routed to irq 21 miibus1: on hme0 ukphy1: PHY 1 on miibus1 ukphy1: OUI 0x00601d, model 0x000c, rev. 1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hme0: bpf attached hme0: Ethernet address: 00:03:ba:1f:72:39 pcib0: installed DMA sync wrapper for device 0.1 on bus 1 hme0: [MPSAFE] hme0: [ITHREAD] pci1: at device 1.0 (no driver attached) hme1: mem 0x3808000-0x380ffff at device 1.1 on pci1 hme1: Reserved 0x8000 bytes for rid 0x10 type 3 at 0x3808000 pcib1: slot 1 INTB is routed to irq 22 miibus2: on hme1 ukphy2: PHY 1 on miibus2 ukphy2: OUI 0x00601d, model 0x000c, rev. 1 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hme1: bpf attached hme1: Ethernet address: 00:03:ba:1f:72:3a pcib0: installed DMA sync wrapper for device 1.1 on bus 1 hme1: [MPSAFE] hme1: [ITHREAD] pci1: at device 2.0 (no driver attached) hme2: mem 0x3810000-0x3817fff at device 2.1 on pci1 hme2: Reserved 0x8000 bytes for rid 0x10 type 3 at 0x3810000 pcib1: slot 2 INTB is routed to irq 23 miibus3: on hme2 ukphy3: PHY 1 on miibus3 ukphy3: OUI 0x00601d, model 0x000c, rev. 1 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hme2: bpf attached hme2: Ethernet address: 00:03:ba:1f:72:3b pcib0: installed DMA sync wrapper for device 2.1 on bus 1 hme2: [MPSAFE] hme2: [ITHREAD] pci1: at device 3.0 (no driver attached) hme3: mem 0x3818000-0x381ffff at device 3.1 on pci1 hme3: Reserved 0x8000 bytes for rid 0x10 type 3 at 0x3818000 pcib1: slot 3 INTB is routed to irq 20 miibus4: on hme3 ukphy4: PHY 1 on miibus4 ukphy4: OUI 0x00601d, model 0x000c, rev. 1 ukphy4: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hme3: bpf attached hme3: Ethernet address: 00:03:ba:1f:72:3c pcib0: installed DMA sync wrapper for device 3.1 on bus 1 hme3: [MPSAFE] hme3: [ITHREAD] pcib2: mem 0x40004600000-0x40004617fff,0x40004410000-0x4000441004f,0x7ffec000000-0x7ffec0000ff irq 562,560,561,564 on nexus0 pcib2: Schizo, version 5, IGN 0x8, bus A, 66MHz Timecounter "pcib2" frequency 150000000 Hz quality 100 pcib2: DVMA map: 0xc0000000 to 0xffffffff pcib2: bus range 0 to 0; PCI bus 0 pcib2: [FILTER] pcib2: [FILTER] pci2: on pcib2 pci2: domain=2, physical bus=0 found-> vendor=0x108e, dev=0x8001, revid=0x00 domain=2, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1077, dev=0x2200, revid=0x05 domain=2, bus=0, slot=4, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0xf8 (7440 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 1 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x300, size 8, port disabled map[14]: type Memory, range 32, base 0x100000, size 12, memory disabled Qlogic ISP Driver, FreeBSD Version 5.9, Core Version 3.0 isp0: port 0x300-0x3ff mem 0x100000-0x100fff at device 4.0 on pci2 isp0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0x100000 isp0: using Memory space register mapping isp0: [MPSAFE] isp0: [ITHREAD] isp0: Board Type 2200, Chip Revision 0x5, loaded F/W Revision 2.2.6 isp0: 309 max I/O command limit set isp0: invalid NVRAM header isp0: invalid NVRAM header isp0: Using Node WWN 0x400000007f000009 isp0: Using Port WWN 0x400000007f000009 syscons0: no video adapter found. nexus0: type unknown (no driver attached) Reducing kern.maxvnodes 262513 -> 100000 procfs registered Timecounter "tick" frequency 900000000 Hz quality 10 Timecounters tick every 1.000 msec lo0: bpf attached Waiting 5 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. isp0: LIP Received isp0: Loop UP isp0: Port Database Changed isp0: Firmware State Ready> isp0: HBA PortID 0x000029 N-Port Handle 109, Connection Topology 'Private Loop' isp0: HBA WWNN 0x400000007f000009 HBA WWPN 0x400000007f000009 (probe6:sym0:0:6:0): Retrying Command (probe6:sym0:0:6:0): error 22 (probe6:sym0:0:6:0): Unretryable Error pass0 at sym0 bus 0 target 6 lun 0 pass0: Removable CD-ROM SCSI-2 device pass0: 3.300MB/s transfers GEOM: new disk cd0 SMP: AP CPU #1 Launched! (cd0:WsAyRmN0I:N0G::6 :W0I)T:N EeSrSr oorp t6i o(nc de0n:asbylme0d:,0 :e6x:p0e)c:t Urnerdeutcreyda bpleer fEorrrmoarn cced.0 at sym0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present (cd0:sym0:0:6:0): error 6 (cd0:sym0:0:6:0): Unretryable Error (cd0:sym0:0:6:0): error 6 (cd0:sym0:0:6:0): Unretryable Error (cd0:sym0:0:6:0): error 6 (cd0:sym0:0:6:0): Unretryable Error (cd0:sym0:0:6:0): error 6 (cd0:sym0:0:6:0): Unretryable Error Trying to mount root from nfs:192.168.42.48:/install/fbsds64 NFS ROOT: 192.168.42.48:/install/fbsds64 ct_to_ts([2008-11-11 16:39:07]) = 1226421547.000000000 ct_to_ts([2008-11-11 16:39:07]) = 1226421547.000000000 start_init: trying /sbin/init lock order reversal: 1st 0xfffff8000309e070 user map (user map) @ /usr/src/sys/vm/vm_map.c:3115 2nd 0xfffff800035cd890 nfs (nfs) @ /usr/src/sys/kern/vfs_subr.c:2047 KDB: stack backtrace: _witness_debugger() at _witness_debugger+0x38 witness_checkorder() at witness_checkorder+0xcf8 __lockmgr_args() at __lockmgr_args+0x2d0 vop_stdlock() at vop_stdlock+0x38 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x110 _vn_lock() at _vn_lock+0x80 vget() at vget+0x120 vnode_pager_lock() at vnode_pager_lock+0x240 vm_fault() at vm_fault+0x208 trap_pfault() at trap_pfault+0x198 trap() at trap+0xd0 -- fast data access mmu miss tar=0x2a2001 %o7=0xc0080e00 -- userland() at 0x10015c user trace: trap %o7=0xc0080e00 pc 0x10015c, sp 0x7fdffffe531 pc 0, sp 0x7fdffffe5f1 done hme3: link state changed to UP From marius at alchemy.franken.de Wed Nov 12 11:44:46 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Wed Nov 12 11:44:52 2008 Subject: Booting of snapshot-iso on SUN Fire V280R In-Reply-To: <20081111170407.GS5156@darkthrone.kvedulv.de> References: <20081028172823.GO5156@darkthrone.kvedulv.de> <20081028221321.GA32214@alchemy.franken.de> <20081029001112.GR5156@darkthrone.kvedulv.de> <20081029081558.GB31338@alchemy.franken.de> <20081029140204.GS5156@darkthrone.kvedulv.de> <20081110222744.GA64456@alchemy.franken.de> <20081111170407.GS5156@darkthrone.kvedulv.de> Message-ID: <20081112194444.GD64456@alchemy.franken.de> On Tue, Nov 11, 2008 at 06:04:07PM +0100, Michael Moll wrote: > Hi Marius, > > On Mon, Nov 10, 2008 at 11:27:44PM +0100, Marius Strobl wrote: > > Could you please give the patch at: > > http://people.freebsd.org/~marius/schizo_cdma.diff > > a try with that machine? The patch implements the consistent > > DMA syncing required for devices behind PCI-PCI, f.e. your > > HMEs, for Schizo version >= 5. I.e. please test, whether > > the machine still boots with the patch in place and using > > a HME just works and increases the vec566: pcib0 counter > > (I hope I got the numbers right; well, see `vmstat -i` > > for pcib interrupts). > > Seems all fine, I attached verbose bootmessages. I tried one HME > interface and it seems to work, counters increase also: Thanks you very much for testing! How annoying is testing patches on this machine for you? At some point in time I'll have another one to try with a version >= 5 Schizo, which won't require additional hardware like your QFE card though, so I could also bug someone else then... Marius From marius at alchemy.franken.de Wed Nov 12 12:10:31 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Wed Nov 12 12:10:37 2008 Subject: Free Ultra2 in Silicon Valley, USA In-Reply-To: <20081105184746.GA26875@soaustin.net> References: <20081031124442.GB9102@soaustin.net> <183638.12752.qm@web56802.mail.re3.yahoo.com> <20081031131827.GA9613@soaustin.net> <20081103223042.GB8256@alchemy.franken.de> <20081104115722.GA28394@soaustin.net> <20081104221003.GE31338@alchemy.franken.de> <20081105184746.GA26875@soaustin.net> Message-ID: <20081112201029.GE64456@alchemy.franken.de> On Wed, Nov 05, 2008 at 12:47:46PM -0600, Mark Linimon wrote: > On Tue, Nov 04, 2008 at 11:10:03PM +0100, Marius Strobl wrote: > > I've planned to give that configuration a try but I need to fetch > > mine from the datacenter in order to do so. > > No rush, I'm still traveling. > Well, mine "just works": http://people.freebsd.org/~marius/t1-200.txt I've also tried some combinations of variations like w/ and w/o ATAPI DMA, w/ and w/o a CD, w/ and w/o a HD (one strange thing is that yours probes for SCSI devices before attaching acd0 while mine does that afterwards) but none made a difference. So either the problem was temporary (the preallocation of DMA related things in ata(4) being switched back and force comes to my mind) or it's truly specific to your machine. The bad news it I couldn't get the firmware of mine to netboot. Marius From carton at Ivy.NET Wed Nov 12 12:38:54 2008 From: carton at Ivy.NET (Miles Nordin) Date: Wed Nov 12 12:38:59 2008 Subject: Free Ultra2 in Silicon Valley, USA In-Reply-To: <20081112201029.GE64456@alchemy.franken.de> (Marius Strobl's message of "Wed, 12 Nov 2008 21:10:29 +0100") References: <20081031124442.GB9102@soaustin.net> <183638.12752.qm@web56802.mail.re3.yahoo.com> <20081031131827.GA9613@soaustin.net> <20081103223042.GB8256@alchemy.franken.de> <20081104115722.GA28394@soaustin.net> <20081104221003.GE31338@alchemy.franken.de> <20081105184746.GA26875@soaustin.net> <20081112201029.GE64456@alchemy.franken.de> Message-ID: >>>>> "ms" == Marius Strobl writes: ms> I couldn't get the firmware of mine to netboot. 'boot net:dhcp' that you're often advised to type silently tries to boot by RARP without complaining about the :dhcp. I gave up trying to boot with DHCP. meh. of course freebsd 'loader' will still want dhcp, so you need to have rarp + tftp running on the same machine to provide 'loader' to the firmware, and also a dhcp server running somewhere. you do not need a bootparams server. iirc 'loader' will quietly use either tftp or nfs to load all it's config and forth bootstrap and kernel and modules. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20081112/486b3103/attachment.pgp From marius at alchemy.franken.de Wed Nov 12 13:35:44 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Wed Nov 12 13:35:50 2008 Subject: Free Ultra2 in Silicon Valley, USA In-Reply-To: References: <20081031124442.GB9102@soaustin.net> <183638.12752.qm@web56802.mail.re3.yahoo.com> <20081031131827.GA9613@soaustin.net> <20081103223042.GB8256@alchemy.franken.de> <20081104115722.GA28394@soaustin.net> <20081104221003.GE31338@alchemy.franken.de> <20081105184746.GA26875@soaustin.net> <20081112201029.GE64456@alchemy.franken.de> Message-ID: <20081112213543.GA71577@alchemy.franken.de> On Wed, Nov 12, 2008 at 03:38:48PM -0500, Miles Nordin wrote: > >>>>> "ms" == Marius Strobl writes: > > ms> I couldn't get the firmware of mine to netboot. > > 'boot net:dhcp' that you're often advised to type silently tries to > boot by RARP without complaining about the :dhcp. I gave up trying to > boot with DHCP. meh. > > of course freebsd 'loader' will still want dhcp, so you need to have > rarp + tftp running on the same machine to provide 'loader' to the > firmware, and also a dhcp server running somewhere. you do not need a > bootparams server. iirc 'loader' will quietly use either tftp or nfs > to load all it's config and forth bootstrap and kernel and modules. I've tried with both dhcpd and rarpd in place. I have other sun4u machines that only boot using RARP so I know my setup works. Marius From mcdouga9 at egr.msu.edu Wed Nov 12 22:19:20 2008 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Wed Nov 12 22:19:27 2008 Subject: Booting of snapshot-iso on SUN Fire V280R In-Reply-To: <20081028221321.GA32214@alchemy.franken.de> References: <20081028172823.GO5156@darkthrone.kvedulv.de> <20081028221321.GA32214@alchemy.franken.de> Message-ID: <491BC348.7070408@egr.msu.edu> Marius Strobl wrote: > On Tue, Oct 28, 2008 at 06:28:23PM +0100, Michael Moll wrote: > >> Hello, >> >> I'm trying to boot the 8.0-20081011-SNAP-sparc64-disc1.iso an a SUN Fire 280R, see the output below. >> pcib0: mem 0x40004700000-0x40004717fff,0x40004410000-0x4000441004f,0x7ffee000000-0x7ffee0000ff irq 563,560,561,564,550 on nexus0 >> pcib0: Schizo, version 5, IGN 0x8, bus B, 33MHz >> > Unfortunately, you're the first person to give it a try with > a Schizo version > 4 bridge. I think this should be gone with > r184428, though stay away from add-on cards with PCI-PCI- > bridges for now. Do you have a way to make use of that > revision or do you need a new ISO image? > > Marius > > > Is there a way to check this version from Solaris, out of curiosity? Does this from prtdiag relate? We have four 280R at work and I could probably experiment with FreeBSD on one soon, but I haven't even had time to boot the ISO yet. Port Model ID Status Version -------- ---- ------ ------- Schizo 8 ok 7 From kvedulv at kvedulv.de Thu Nov 13 04:02:55 2008 From: kvedulv at kvedulv.de (Michael Moll) Date: Thu Nov 13 04:03:02 2008 Subject: Booting of snapshot-iso on SUN Fire V280R In-Reply-To: <20081112194444.GD64456@alchemy.franken.de> References: <20081028172823.GO5156@darkthrone.kvedulv.de> <20081028221321.GA32214@alchemy.franken.de> <20081029001112.GR5156@darkthrone.kvedulv.de> <20081029081558.GB31338@alchemy.franken.de> <20081029140204.GS5156@darkthrone.kvedulv.de> <20081110222744.GA64456@alchemy.franken.de> <20081111170407.GS5156@darkthrone.kvedulv.de> <20081112194444.GD64456@alchemy.franken.de> Message-ID: <20081113120252.GT5156@darkthrone.kvedulv.de> Hi Marius, On Wed, Nov 12, 2008 at 08:44:44PM +0100, Marius Strobl wrote: > Thanks you very much for testing! How annoying is testing > patches on this machine for you? It's no problem at all, just send more patches if they are ready :) -- Michael Moll e-mail : kvedulv@kvedulv.de WWW : http://www.kvedulv.de/ GSM : +49 175 606 7861 From marius at alchemy.franken.de Thu Nov 13 14:26:03 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Thu Nov 13 14:26:10 2008 Subject: Booting of snapshot-iso on SUN Fire V280R In-Reply-To: <491BC348.7070408@egr.msu.edu> References: <20081028172823.GO5156@darkthrone.kvedulv.de> <20081028221321.GA32214@alchemy.franken.de> <491BC348.7070408@egr.msu.edu> Message-ID: <20081113222559.GF64456@alchemy.franken.de> On Thu, Nov 13, 2008 at 01:03:52AM -0500, Adam McDougall wrote: > > Is there a way to check this version from Solaris, out of curiosity? > Does this from prtdiag relate? We have four 280R at work and I could > probably experiment with FreeBSD on one soon, but I haven't even had > time to boot the ISO yet. > > Port > Model ID Status Version > -------- ---- ------ ------- > Schizo 8 ok 7 I'd assume that this is the version info in question. If you want to be absolutely sure, get the OFW device tree in more or less raw form by runnning `prtconf -Ppv` and look at the "version#" property of a node having a "compatible" property of "pci108e,8001". Marius From mcdouga9 at egr.msu.edu Thu Nov 13 15:42:42 2008 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Thu Nov 13 15:42:48 2008 Subject: Booting of snapshot-iso on SUN Fire V280R In-Reply-To: <20081113222559.GF64456@alchemy.franken.de> References: <20081028172823.GO5156@darkthrone.kvedulv.de> <20081028221321.GA32214@alchemy.franken.de> <491BC348.7070408@egr.msu.edu> <20081113222559.GF64456@alchemy.franken.de> Message-ID: <20081113234240.GT40736@egr.msu.edu> On Thu, Nov 13, 2008 at 11:25:59PM +0100, Marius Strobl wrote: On Thu, Nov 13, 2008 at 01:03:52AM -0500, Adam McDougall wrote: > > Is there a way to check this version from Solaris, out of curiosity? > Does this from prtdiag relate? We have four 280R at work and I could > probably experiment with FreeBSD on one soon, but I haven't even had > time to boot the ISO yet. > > Port > Model ID Status Version > -------- ---- ------ ------- > Schizo 8 ok 7 I'd assume that this is the version info in question. If you want to be absolutely sure, get the OFW device tree in more or less raw form by runnning `prtconf -Ppv` and look at the "version#" property of a node having a "compatible" property of "pci108e,8001". Marius Thanks, looks like it: compatible: 'pci108e,8001' clock-frequency: 01f78a40 bus-range: 00000000.00000000 bus-parity-generated: no-probe-list: '0' name: 'pci' device_type: 'pci' #address-cells: 00000003 #size-cells: 00000002 implementation#: 0000002a version#: 00000007 portid: 00000008 From linimon at lonesome.com Fri Nov 14 08:19:33 2008 From: linimon at lonesome.com (Mark Linimon) Date: Fri Nov 14 08:19:40 2008 Subject: Free Ultra2 in Silicon Valley, USA In-Reply-To: <20081112213543.GA71577@alchemy.franken.de> References: <20081031124442.GB9102@soaustin.net> <183638.12752.qm@web56802.mail.re3.yahoo.com> <20081031131827.GA9613@soaustin.net> <20081103223042.GB8256@alchemy.franken.de> <20081104115722.GA28394@soaustin.net> <20081104221003.GE31338@alchemy.franken.de> <20081105184746.GA26875@soaustin.net> <20081112201029.GE64456@alchemy.franken.de> <20081112213543.GA71577@alchemy.franken.de> Message-ID: <20081114161933.GA24688@soaustin.net> It turns out the T1-200s are much happier to boot if you actually include the gem(4) driver in the kernel. Sigh. Anyways, thanks for the help investigating. mcl From marius at alchemy.franken.de Fri Nov 14 13:11:21 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Fri Nov 14 13:11:28 2008 Subject: Free Ultra2 in Silicon Valley, USA In-Reply-To: <20081114161933.GA24688@soaustin.net> References: <183638.12752.qm@web56802.mail.re3.yahoo.com> <20081031131827.GA9613@soaustin.net> <20081103223042.GB8256@alchemy.franken.de> <20081104115722.GA28394@soaustin.net> <20081104221003.GE31338@alchemy.franken.de> <20081105184746.GA26875@soaustin.net> <20081112201029.GE64456@alchemy.franken.de> <20081112213543.GA71577@alchemy.franken.de> <20081114161933.GA24688@soaustin.net> Message-ID: <20081114211118.GG64456@alchemy.franken.de> On Fri, Nov 14, 2008 at 10:19:33AM -0600, Mark Linimon wrote: > It turns out the T1-200s are much happier to boot if you actually > include the gem(4) driver in the kernel. > > Sigh. > > Anyways, thanks for the help investigating. > Ah, the problem then likely is that the GEMs are left initialized and running by the firmware; at some point, probably when some packet is received, the GEM DMAs something to a mapping the IOMMU no longer knows about since the kernel has taken it over and thus triggers a DMA error interrupt. If this happens when netbooting then it's probably time to fix libstand to no longer open and close the network device for every file access so we can remove the hack form the loader which just keeps the device open forever. On the other hand, it's probably beneficial in general to not remove the driver for the device one wants to netboot with :) Marius From nwhitehorn at freebsd.org Fri Nov 14 14:16:23 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Fri Nov 14 14:16:54 2008 Subject: Free Ultra2 in Silicon Valley, USA In-Reply-To: <20081114211118.GG64456@alchemy.franken.de> References: <183638.12752.qm@web56802.mail.re3.yahoo.com> <20081031131827.GA9613@soaustin.net> <20081103223042.GB8256@alchemy.franken.de> <20081104115722.GA28394@soaustin.net> <20081104221003.GE31338@alchemy.franken.de> <20081105184746.GA26875@soaustin.net> <20081112201029.GE64456@alchemy.franken.de> <20081112213543.GA71577@alchemy.franken.de> <20081114161933.GA24688@soaustin.net> <20081114211118.GG64456@alchemy.franken.de> Message-ID: <491DEC35.7060203@freebsd.org> Marius Strobl wrote: > On Fri, Nov 14, 2008 at 10:19:33AM -0600, Mark Linimon wrote: > >> It turns out the T1-200s are much happier to boot if you actually >> include the gem(4) driver in the kernel. >> >> Sigh. >> >> Anyways, thanks for the help investigating. >> >> > > Ah, the problem then likely is that the GEMs are left initialized > and running by the firmware; at some point, probably when some > packet is received, the GEM DMAs something to a mapping the > IOMMU no longer knows about since the kernel has taken it over > and thus triggers a DMA error interrupt. > If this happens when netbooting then it's probably time to > fix libstand to no longer open and close the network device > for every file access so we can remove the hack form the > loader which just keeps the device open forever. On the other > hand, it's probably beneficial in general to not remove the > driver for the device one wants to netboot with :) > This opening and closing for each file access breaks netbooting on a wide range of PowerPC systems as well (ones with gem interfaces, for instance). So it would be nice if you could fix loader in an MI way... -Nathan From linimon at lonesome.com Sat Nov 15 03:42:59 2008 From: linimon at lonesome.com (Mark Linimon) Date: Sat Nov 15 03:43:05 2008 Subject: Free Ultra2 in Silicon Valley, USA In-Reply-To: <20081114211118.GG64456@alchemy.franken.de> References: <20081031131827.GA9613@soaustin.net> <20081103223042.GB8256@alchemy.franken.de> <20081104115722.GA28394@soaustin.net> <20081104221003.GE31338@alchemy.franken.de> <20081105184746.GA26875@soaustin.net> <20081112201029.GE64456@alchemy.franken.de> <20081112213543.GA71577@alchemy.franken.de> <20081114161933.GA24688@soaustin.net> <20081114211118.GG64456@alchemy.franken.de> Message-ID: <20081115114258.GA5532@soaustin.net> On Fri, Nov 14, 2008 at 10:11:19PM +0100, Marius Strobl wrote: > If this happens when netbooting then it's probably time to > fix libstand to no longer open and close the network device > for every file access Yes, it happens when netbooting. When I first installed onto the hard drives, I installed a GENERIC 7.0R, so the machines worked then. Therefore, I can't tell you if a gem-less kernel installed to disk fails or works. mcl From bugmaster at FreeBSD.org Mon Nov 17 03:06:57 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 17 03:09:11 2008 Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org Message-ID: <200811171106.mAHB6vB0082663@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 7.0 Beta won't install on U60 o sparc/118932 sparc64 7.0-BETA4/sparc-64 kernel panic in rip_output o sparc/113556 sparc64 panic: trap: memory address not aligned; Rebooting... o sparc/109908 sparc64 apache22 mod_perl issue on sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 s sparc/107087 sparc64 system is hinged 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 17 problems total. From mail25 at bzerk.org Wed Nov 19 00:03:56 2008 From: mail25 at bzerk.org (Ruben de Groot) Date: Wed Nov 19 00:04:03 2008 Subject: Panic in 7.1-PRERELEASE (was: Re: kgdb on sparc64) In-Reply-To: <20081109183232.GC76319@alchemy.franken.de> References: <20081103120215.GA32257@ei.bzerk.org> <20081103221111.GA8256@alchemy.franken.de> <20081105195630.GA52831@ei.bzerk.org> <20081109183232.GC76319@alchemy.franken.de> Message-ID: <20081119080344.GA96293@ei.bzerk.org> On Sun, Nov 09, 2008 at 07:32:32PM +0100, Marius Strobl typed: > On Wed, Nov 05, 2008 at 08:56:30PM +0100, Ruben de Groot wrote: > > > > For your purposes it's probably simpler to just build a > > > kernel with debugger by adding "options DDB", "options KDB" > > > and "makeoptions DEBUG=-g". Then when the kernel panics > > > just enter "backtrace" on the console. With a X1 you > > > most likely use serial console anyway so you can easily > > > capture the output. > > > > I'll build a kernel with those options just in case. But > > would rather not use it on this particular machine, as it is > > a production server and should not be down for extended periods > > of time. > > If you additionally either also add "options KDB_TRACE" and > "options KDB_UNATTENDED" or set "debug.trace_on_panic=1" > and "debug.debugger_on_panic=0" via sysctl(8) with a > debugger-enabled kernel, the debugger will automatically > print a backtrace to the console and then reboot the > machine and thus minimizing downtime. Printing the > backtrace might require the latest 7-STABLE though. > > > Meanwhile, moving over websites to another machine (another X1, > > but running -current) that seems to be more stable ATM. > > > > That's what puzzles me as every sparc64-specific change > in 7-STABLE since 7.0-RELEASE also is in -current except > for one stricter check in -current. So I guess you're > hitting one of the MI stability issues people are > reporting for 7.1-PRERELEASE. It took some time, but I finally managed to get a backtrace today, with a newly compiled 7-stable kernel: FreeBSD nostalgia4infinity.bzerk.org 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #5: Mon Nov 10 21:25:55 CET 2008 root@nostalgia4infinity.bzerk.org:/usr/obj/usr/src/sys/N4I sparc64 panic: trap: data access error cpuid = 0 KDB: stack backtrace: panic() at panic+0x1c8 trap() at trap+0x4d0 -- data access error %o7=0xc00bac60 -- dc_mii_writebit() at dc_mii_writebit+0xd8 dc_miibus_writereg() at dc_miibus_writereg+0x2a0 miibus_writereg() at miibus_writereg+0x64 mii_phy_reset() at mii_phy_reset+0x7c mii_phy_tick() at mii_phy_tick+0x154 amphy_service() at amphy_service+0x164 mii_tick() at mii_tick+0x1c dc_tick() at dc_tick+0x1ec softclock() at softclock+0x3c4 ithread_loop() at ithread_loop+0x21c fork_exit() at fork_exit+0x88 fork_trampoline() at fork_trampoline+0x8 Uptime: 4d22h16m5s Dumping 1024 MB (4 chunks) chunk at 0: 268435456 bytes ... ok chunk at 0x20000000: 268435456 bytes ... ok chunk at 0x40000000: 268435456 bytes ... ok chunk at 0x60000000: 268435456 bytes ... ok Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... LOM event: +65d+13h48m37s host reset Resetting ... From marius at alchemy.franken.de Wed Nov 19 14:03:23 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Wed Nov 19 14:03:30 2008 Subject: Panic in 7.1-PRERELEASE (was: Re: kgdb on sparc64) In-Reply-To: <20081119080344.GA96293@ei.bzerk.org> References: <20081103120215.GA32257@ei.bzerk.org> <20081103221111.GA8256@alchemy.franken.de> <20081105195630.GA52831@ei.bzerk.org> <20081109183232.GC76319@alchemy.franken.de> <20081119080344.GA96293@ei.bzerk.org> Message-ID: <20081119220317.GP64456@alchemy.franken.de> On Wed, Nov 19, 2008 at 09:03:44AM +0100, Ruben de Groot wrote: > > FreeBSD nostalgia4infinity.bzerk.org 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #5: Mon Nov 10 21:25:55 CET 2008 root@nostalgia4infinity.bzerk.org:/usr/obj/usr/src/sys/N4I sparc64 > > panic: trap: data access error > cpuid = 0 > KDB: stack backtrace: > panic() at panic+0x1c8 > trap() at trap+0x4d0 > -- data access error %o7=0xc00bac60 -- > dc_mii_writebit() at dc_mii_writebit+0xd8 > dc_miibus_writereg() at dc_miibus_writereg+0x2a0 > miibus_writereg() at miibus_writereg+0x64 > mii_phy_reset() at mii_phy_reset+0x7c > mii_phy_tick() at mii_phy_tick+0x154 > amphy_service() at amphy_service+0x164 > mii_tick() at mii_tick+0x1c > dc_tick() at dc_tick+0x1ec > softclock() at softclock+0x3c4 > ithread_loop() at ithread_loop+0x21c > fork_exit() at fork_exit+0x88 > fork_trampoline() at fork_trampoline+0x8 > Uptime: 4d22h16m5s > Dumping 1024 MB (4 chunks) > chunk at 0: 268435456 bytes ... ok > chunk at 0x20000000: 268435456 bytes ... ok > chunk at 0x40000000: 268435456 bytes ... ok > chunk at 0x60000000: 268435456 bytes ... ok > Could you please run gdb on the corresponding kernel.debug and report the output of the following commands? l*(0xc00bac60) l*(dc_mii_writebit+0xd8) If you need a quick workaround I think that locally reverting src/sys/dev/dc/if_dc.c r182461/1.192.2.5 will get you rid of this problem, this will also make dc(4) again no longer check the link state of this interface once it's up though, so this is no real solution. Marius From mail25 at bzerk.org Wed Nov 19 21:47:23 2008 From: mail25 at bzerk.org (Ruben de Groot) Date: Wed Nov 19 21:47:29 2008 Subject: Panic in 7.1-PRERELEASE (was: Re: kgdb on sparc64) In-Reply-To: <20081119220317.GP64456@alchemy.franken.de> References: <20081103120215.GA32257@ei.bzerk.org> <20081103221111.GA8256@alchemy.franken.de> <20081105195630.GA52831@ei.bzerk.org> <20081109183232.GC76319@alchemy.franken.de> <20081119080344.GA96293@ei.bzerk.org> <20081119220317.GP64456@alchemy.franken.de> Message-ID: <20081120054711.GA11035@ei.bzerk.org> On Wed, Nov 19, 2008 at 11:03:17PM +0100, Marius Strobl typed: > On Wed, Nov 19, 2008 at 09:03:44AM +0100, Ruben de Groot wrote: > > > > FreeBSD nostalgia4infinity.bzerk.org 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #5: Mon Nov 10 21:25:55 CET 2008 root@nostalgia4infinity.bzerk.org:/usr/obj/usr/src/sys/N4I sparc64 > > > > panic: trap: data access error > > cpuid = 0 > > KDB: stack backtrace: > > panic() at panic+0x1c8 > > trap() at trap+0x4d0 > > -- data access error %o7=0xc00bac60 -- > > dc_mii_writebit() at dc_mii_writebit+0xd8 > > dc_miibus_writereg() at dc_miibus_writereg+0x2a0 > > miibus_writereg() at miibus_writereg+0x64 > > mii_phy_reset() at mii_phy_reset+0x7c > > mii_phy_tick() at mii_phy_tick+0x154 > > amphy_service() at amphy_service+0x164 > > mii_tick() at mii_tick+0x1c > > dc_tick() at dc_tick+0x1ec > > softclock() at softclock+0x3c4 > > ithread_loop() at ithread_loop+0x21c > > fork_exit() at fork_exit+0x88 > > fork_trampoline() at fork_trampoline+0x8 > > Uptime: 4d22h16m5s > > Dumping 1024 MB (4 chunks) > > chunk at 0: 268435456 bytes ... ok > > chunk at 0x20000000: 268435456 bytes ... ok > > chunk at 0x40000000: 268435456 bytes ... ok > > chunk at 0x60000000: 268435456 bytes ... ok > > > > Could you please run gdb on the corresponding kernel.debug > and report the output of the following commands? > l*(0xc00bac60) > l*(dc_mii_writebit+0xd8) (gdb) l*(0xc00bac60) 0xc00bac60 is in dc_mii_send (/usr/src/sys/dev/dc/if_dc.c:661). 656 dc_mii_send(struct dc_softc *sc, u_int32_t bits, int cnt) 657 { 658 int i; 659 660 for (i = (0x1 << (cnt - 1)); i; i >>= 1) 661 dc_mii_writebit(sc, bits & i); 662 } 663 664 /* 665 * Read an PHY register through the MII. (gdb) l*(dc_mii_writebit+0xd8) 0xc00baaf8 is in dc_mii_writebit (cpufunc.h:129). 124 : : "r" (val), "r" (va), "r" (asi)); \ 125 } 126 127 STNC_GEN(u_char, stba); 128 STNC_GEN(u_short, stha); 129 STNC_GEN(u_int, stwa); 130 STNC_GEN(u_long, stxa); 131 132 #define ST_GENERIC(va, asi, val, op) \ 133 __asm __volatile(#op " %0, [%1] %2" \ > If you need a quick workaround I think that locally reverting > src/sys/dev/dc/if_dc.c r182461/1.192.2.5 will get you rid of > this problem, this will also make dc(4) again no longer check > the link state of this interface once it's up though, so this > is no real solution. Thanks. I've moved all websites away from this machine, so it's available for any further tests to help find a solution. Ruben From tinderbox at freebsd.org Thu Nov 20 13:24:47 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Nov 20 13:24:59 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081120212444.D17FE73039@freebsd-current.sentex.ca> TB --- 2008-11-20 19:47:45 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-20 19:47:45 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-20 19:47:45 - cleaning the object tree TB --- 2008-11-20 19:48:18 - cvsupping the source tree TB --- 2008-11-20 19:48:18 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-20 19:48:25 - building world TB --- 2008-11-20 19:48:25 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-20 19:48:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-20 19:48:25 - TARGET=sparc64 TB --- 2008-11-20 19:48:25 - TARGET_ARCH=sparc64 TB --- 2008-11-20 19:48:25 - TZ=UTC TB --- 2008-11-20 19:48:25 - __MAKE_CONF=/dev/null TB --- 2008-11-20 19:48:25 - cd /src TB --- 2008-11-20 19:48:25 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 20 19:48:27 UTC 2008 >>> 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 Nov 20 21:08:28 UTC 2008 TB --- 2008-11-20 21:08:28 - generating LINT kernel config TB --- 2008-11-20 21:08:28 - cd /src/sys/sparc64/conf TB --- 2008-11-20 21:08:28 - /usr/bin/make -B LINT TB --- 2008-11-20 21:08:28 - building LINT kernel TB --- 2008-11-20 21:08:28 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-20 21:08:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-20 21:08:28 - TARGET=sparc64 TB --- 2008-11-20 21:08:28 - TARGET_ARCH=sparc64 TB --- 2008-11-20 21:08:28 - TZ=UTC TB --- 2008-11-20 21:08:28 - __MAKE_CONF=/dev/null TB --- 2008-11-20 21:08:28 - cd /src TB --- 2008-11-20 21:08:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Nov 20 21:08:28 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0x6308): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-20 21:24:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-20 21:24:44 - ERROR: failed to build lint kernel TB --- 2008-11-20 21:24:44 - 4576.20 user 414.31 system 5818.68 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Thu Nov 20 20:46:28 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Nov 20 20:46:40 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081121044624.A8BDB73039@freebsd-current.sentex.ca> TB --- 2008-11-21 03:10:22 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-21 03:10:22 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-21 03:10:22 - cleaning the object tree TB --- 2008-11-21 03:10:45 - cvsupping the source tree TB --- 2008-11-21 03:10:45 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-21 03:10:52 - building world TB --- 2008-11-21 03:10:52 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 03:10:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 03:10:52 - TARGET=sparc64 TB --- 2008-11-21 03:10:52 - TARGET_ARCH=sparc64 TB --- 2008-11-21 03:10:52 - TZ=UTC TB --- 2008-11-21 03:10:52 - __MAKE_CONF=/dev/null TB --- 2008-11-21 03:10:52 - cd /src TB --- 2008-11-21 03:10:52 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 21 03:10:53 UTC 2008 >>> 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 Nov 21 04:30:10 UTC 2008 TB --- 2008-11-21 04:30:10 - generating LINT kernel config TB --- 2008-11-21 04:30:10 - cd /src/sys/sparc64/conf TB --- 2008-11-21 04:30:10 - /usr/bin/make -B LINT TB --- 2008-11-21 04:30:10 - building LINT kernel TB --- 2008-11-21 04:30:10 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 04:30:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 04:30:10 - TARGET=sparc64 TB --- 2008-11-21 04:30:10 - TARGET_ARCH=sparc64 TB --- 2008-11-21 04:30:10 - TZ=UTC TB --- 2008-11-21 04:30:10 - __MAKE_CONF=/dev/null TB --- 2008-11-21 04:30:10 - cd /src TB --- 2008-11-21 04:30:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 21 04:30:10 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0x6308): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-21 04:46:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-21 04:46:24 - ERROR: failed to build lint kernel TB --- 2008-11-21 04:46:24 - 4577.45 user 411.22 system 5761.91 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Fri Nov 21 04:31:42 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Nov 21 04:31:47 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081121123138.B208373039@freebsd-current.sentex.ca> TB --- 2008-11-21 10:55:44 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-21 10:55:44 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-21 10:55:44 - cleaning the object tree TB --- 2008-11-21 10:56:11 - cvsupping the source tree TB --- 2008-11-21 10:56:11 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-21 10:56:18 - building world TB --- 2008-11-21 10:56:18 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 10:56:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 10:56:18 - TARGET=sparc64 TB --- 2008-11-21 10:56:18 - TARGET_ARCH=sparc64 TB --- 2008-11-21 10:56:18 - TZ=UTC TB --- 2008-11-21 10:56:18 - __MAKE_CONF=/dev/null TB --- 2008-11-21 10:56:18 - cd /src TB --- 2008-11-21 10:56:18 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 21 10:56:20 UTC 2008 >>> 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 Nov 21 12:15:25 UTC 2008 TB --- 2008-11-21 12:15:25 - generating LINT kernel config TB --- 2008-11-21 12:15:25 - cd /src/sys/sparc64/conf TB --- 2008-11-21 12:15:25 - /usr/bin/make -B LINT TB --- 2008-11-21 12:15:25 - building LINT kernel TB --- 2008-11-21 12:15:25 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 12:15:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 12:15:25 - TARGET=sparc64 TB --- 2008-11-21 12:15:25 - TARGET_ARCH=sparc64 TB --- 2008-11-21 12:15:25 - TZ=UTC TB --- 2008-11-21 12:15:25 - __MAKE_CONF=/dev/null TB --- 2008-11-21 12:15:25 - cd /src TB --- 2008-11-21 12:15:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 21 12:15:25 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0x6308): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-21 12:31:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-21 12:31:38 - ERROR: failed to build lint kernel TB --- 2008-11-21 12:31:38 - 4574.70 user 413.04 system 5754.28 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Fri Nov 21 12:37:23 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Nov 21 12:37:40 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081121203718.C637073039@freebsd-current.sentex.ca> TB --- 2008-11-21 19:01:16 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-21 19:01:16 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-21 19:01:16 - cleaning the object tree TB --- 2008-11-21 19:01:37 - cvsupping the source tree TB --- 2008-11-21 19:01:37 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-21 19:01:44 - building world TB --- 2008-11-21 19:01:44 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 19:01:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 19:01:44 - TARGET=sparc64 TB --- 2008-11-21 19:01:44 - TARGET_ARCH=sparc64 TB --- 2008-11-21 19:01:44 - TZ=UTC TB --- 2008-11-21 19:01:44 - __MAKE_CONF=/dev/null TB --- 2008-11-21 19:01:44 - cd /src TB --- 2008-11-21 19:01:44 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 21 19:01:46 UTC 2008 >>> 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 Nov 21 20:21:25 UTC 2008 TB --- 2008-11-21 20:21:25 - generating LINT kernel config TB --- 2008-11-21 20:21:25 - cd /src/sys/sparc64/conf TB --- 2008-11-21 20:21:25 - /usr/bin/make -B LINT TB --- 2008-11-21 20:21:25 - building LINT kernel TB --- 2008-11-21 20:21:25 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-21 20:21:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-21 20:21:25 - TARGET=sparc64 TB --- 2008-11-21 20:21:25 - TARGET_ARCH=sparc64 TB --- 2008-11-21 20:21:25 - TZ=UTC TB --- 2008-11-21 20:21:25 - __MAKE_CONF=/dev/null TB --- 2008-11-21 20:21:25 - cd /src TB --- 2008-11-21 20:21:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 21 20:21:25 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0x6308): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-21 20:37:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-21 20:37:18 - ERROR: failed to build lint kernel TB --- 2008-11-21 20:37:18 - 4579.52 user 410.76 system 5762.69 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Fri Nov 21 21:16:59 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Nov 21 21:17:11 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081122051656.1C90673039@freebsd-current.sentex.ca> TB --- 2008-11-22 03:40:38 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-22 03:40:38 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-22 03:40:38 - cleaning the object tree TB --- 2008-11-22 03:41:06 - cvsupping the source tree TB --- 2008-11-22 03:41:06 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-22 03:41:14 - building world TB --- 2008-11-22 03:41:14 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 03:41:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 03:41:14 - TARGET=sparc64 TB --- 2008-11-22 03:41:14 - TARGET_ARCH=sparc64 TB --- 2008-11-22 03:41:14 - TZ=UTC TB --- 2008-11-22 03:41:14 - __MAKE_CONF=/dev/null TB --- 2008-11-22 03:41:14 - cd /src TB --- 2008-11-22 03:41:14 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 22 03:41:16 UTC 2008 >>> 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 Sat Nov 22 05:00:56 UTC 2008 TB --- 2008-11-22 05:00:56 - generating LINT kernel config TB --- 2008-11-22 05:00:56 - cd /src/sys/sparc64/conf TB --- 2008-11-22 05:00:56 - /usr/bin/make -B LINT TB --- 2008-11-22 05:00:56 - building LINT kernel TB --- 2008-11-22 05:00:56 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 05:00:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 05:00:56 - TARGET=sparc64 TB --- 2008-11-22 05:00:56 - TARGET_ARCH=sparc64 TB --- 2008-11-22 05:00:56 - TZ=UTC TB --- 2008-11-22 05:00:56 - __MAKE_CONF=/dev/null TB --- 2008-11-22 05:00:56 - cd /src TB --- 2008-11-22 05:00:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 22 05:00:56 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0x6308): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-22 05:16:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-22 05:16:56 - ERROR: failed to build lint kernel TB --- 2008-11-22 05:16:56 - 4577.24 user 410.80 system 5777.43 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Sat Nov 22 05:47:59 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat Nov 22 05:48:16 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081122134755.948C273039@freebsd-current.sentex.ca> TB --- 2008-11-22 12:10:54 - tinderbox 2.5 running on freebsd-current.sentex.ca TB --- 2008-11-22 12:10:54 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-11-22 12:10:55 - cleaning the object tree TB --- 2008-11-22 12:11:22 - cvsupping the source tree TB --- 2008-11-22 12:11:22 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-11-22 12:11:30 - building world TB --- 2008-11-22 12:11:30 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 12:11:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 12:11:30 - TARGET=sparc64 TB --- 2008-11-22 12:11:30 - TARGET_ARCH=sparc64 TB --- 2008-11-22 12:11:30 - TZ=UTC TB --- 2008-11-22 12:11:30 - __MAKE_CONF=/dev/null TB --- 2008-11-22 12:11:30 - cd /src TB --- 2008-11-22 12:11:30 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 22 12:11:31 UTC 2008 >>> 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 Sat Nov 22 13:31:40 UTC 2008 TB --- 2008-11-22 13:31:40 - generating LINT kernel config TB --- 2008-11-22 13:31:40 - cd /src/sys/sparc64/conf TB --- 2008-11-22 13:31:40 - /usr/bin/make -B LINT TB --- 2008-11-22 13:31:40 - building LINT kernel TB --- 2008-11-22 13:31:40 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-22 13:31:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-22 13:31:40 - TARGET=sparc64 TB --- 2008-11-22 13:31:40 - TARGET_ARCH=sparc64 TB --- 2008-11-22 13:31:40 - TZ=UTC TB --- 2008-11-22 13:31:40 - __MAKE_CONF=/dev/null TB --- 2008-11-22 13:31:40 - cd /src TB --- 2008-11-22 13:31:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 22 13:31:40 UTC 2008 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT 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 vers.c linking kernel hwpmc_mod.o(.text+0x6308): In function `load': : undefined reference to `pmc_md_finalize' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-22 13:47:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-22 13:47:55 - ERROR: failed to build lint kernel TB --- 2008-11-22 13:47:55 - 4575.52 user 418.46 system 5820.49 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From joseph.koshy at gmail.com Sat Nov 22 06:03:38 2008 From: joseph.koshy at gmail.com (Joseph Koshy) Date: Sat Nov 22 06:03:44 2008 Subject: [head tinderbox] failure on sparc64/sparc64 In-Reply-To: <20081122051656.1C90673039@freebsd-current.sentex.ca> References: <20081122051656.1C90673039@freebsd-current.sentex.ca> Message-ID: <84dead720811220531r56fd1a91x91962a926dcb2a03@mail.gmail.com> > linking kernel > hwpmc_mod.o(.text+0x6308): In function `load': > : undefined reference to `pmc_md_finalize' > *** Error code 1 Uh-oh, I get to wear the pointy hat. Should be fixed in #185168. Koshy From bugmaster at FreeBSD.org Mon Nov 24 03:07:23 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 24 03:09:10 2008 Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org Message-ID: <200811241107.mAOB7Mlx020042@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 7.0 Beta won't install on U60 o sparc/118932 sparc64 7.0-BETA4/sparc-64 kernel panic in rip_output o sparc/113556 sparc64 panic: trap: memory address not aligned; Rebooting... o sparc/109908 sparc64 apache22 mod_perl issue on sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 s sparc/107087 sparc64 system is hinged 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 17 problems total. From des at des.no Mon Nov 24 04:29:49 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Nov 24 04:29:55 2008 Subject: [head tinderbox] failure on sparc64/sparc64 In-Reply-To: <84dead720811220531r56fd1a91x91962a926dcb2a03@mail.gmail.com> (Joseph Koshy's message of "Sat, 22 Nov 2008 13:31:04 +0000") References: <20081122051656.1C90673039@freebsd-current.sentex.ca> <84dead720811220531r56fd1a91x91962a926dcb2a03@mail.gmail.com> Message-ID: <861vx1gw22.fsf@ds4.des.no> "Joseph Koshy" writes: > Uh-oh, I get to wear the pointy hat. > > Should be fixed in #185168. Thank you! DES -- Dag-Erling Sm?rgrav - des@des.no From PublicServicePartnershipLtd_769894 at dotmailer.co.uk Tue Nov 25 02:27:16 2008 From: PublicServicePartnershipLtd_769894 at dotmailer.co.uk (Mike Cross) Date: Tue Nov 25 02:27:22 2008 Subject: Emailing to the Public Sector Made Easy Message-ID: From tinderbox at freebsd.org Sun Nov 30 13:45:18 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Nov 30 13:45:36 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20081130214515.939FA73039@freebsd-current.sentex.ca> TB --- 2008-11-30 20:10:47 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-11-30 20:10:47 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-11-30 20:10:47 - cleaning the object tree TB --- 2008-11-30 20:11:10 - cvsupping the source tree TB --- 2008-11-30 20:11:10 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-11-30 20:11:18 - building world TB --- 2008-11-30 20:11:18 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-30 20:11:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-30 20:11:18 - TARGET=sun4v TB --- 2008-11-30 20:11:18 - TARGET_ARCH=sparc64 TB --- 2008-11-30 20:11:18 - TZ=UTC TB --- 2008-11-30 20:11:18 - __MAKE_CONF=/dev/null TB --- 2008-11-30 20:11:18 - cd /src TB --- 2008-11-30 20:11:18 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 30 20:11:19 UTC 2008 >>> 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 Sun Nov 30 21:29:59 UTC 2008 TB --- 2008-11-30 21:29:59 - generating LINT kernel config TB --- 2008-11-30 21:29:59 - cd /src/sys/sun4v/conf TB --- 2008-11-30 21:29:59 - /usr/bin/make -B LINT TB --- 2008-11-30 21:29:59 - building LINT kernel TB --- 2008-11-30 21:29:59 - MAKEOBJDIRPREFIX=/obj TB --- 2008-11-30 21:29:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-11-30 21:29:59 - TARGET=sun4v TB --- 2008-11-30 21:29:59 - TARGET_ARCH=sparc64 TB --- 2008-11-30 21:29:59 - TZ=UTC TB --- 2008-11-30 21:29:59 - __MAKE_CONF=/dev/null TB --- 2008-11-30 21:29:59 - cd /src TB --- 2008-11-30 21:29:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 30 21:29:59 UTC 2008 >>> 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 [...] ===> ath_rate_sample (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I. -I/src/sys/modules/ath_rate_sample/../../dev/ath -I/src/sys/modules/ath_rate_sample/../../contrib/dev/ath -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sun4v/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sun4v/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/ath_rate_sample/../../dev/ath/ath_rate/sample/sample.c /src/sys/modules/ath_rate_sample/../../dev/ath/ath_rate/sample/sample.c:408:1: error: "Q" redefined In file included from ./machine/cpufunc.h:32, from ./machine/atomic.h:34, from @/sys/systm.h:41, from /src/sys/modules/ath_rate_sample/../../dev/ath/ath_rate/sample/sample.c:48: ./machine/asi.h:151:1: error: this is the location of the previous definition *** Error code 1 Stop in /src/sys/modules/ath_rate_sample. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-11-30 21:45:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-11-30 21:45:15 - ERROR: failed to build lint kernel TB --- 2008-11-30 21:45:15 - 4611.20 user 412.70 system 5668.14 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full