From marius at alchemy.franken.de Tue Jul 1 10:38:33 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Tue Jul 1 10:38:41 2008 Subject: installing freebsd on b100 blade -- STUCK !! In-Reply-To: <1214865429.1501.6.camel@main.lerwick.hopto.org> References: <1214865429.1501.6.camel@main.lerwick.hopto.org> Message-ID: <20080701103830.GA40254@alchemy.franken.de> On Mon, Jun 30, 2008 at 11:37:09PM +0100, Craig Butler wrote: > Hi Guys, > > Am stuck trying to install FreeBSD 7 on a sparc B100 sitting in a B1600 > chassis. > > Any help would be appreciated.... > > b1600-01bootmode bootscript="boot net" s0 > b1600-01reset s0 > Are you sure you want to reset S0 (y/n)? y > Reset of S0 successful > b1600-01console s0 > [Connected with input enabled on fru S0] > Escape Sequence is '#.' > Probing Memory Bank #0 512 Megabytes > Probing Memory Bank #1 512 Megabytes > Probing Memory Bank #2 0 Megabytes > Probing Memory Bank #3 0 Megabytes > No clientid supplied by the BSC. > Sun Serverblade1 (UltraSPARC-IIe 650MHz), No Keyboard > Copyright 1998-2002 Sun Microsystems, Inc. All rights reserved. > OpenBoot 4.7.5, 1024 MB memory installed, Serial #52823543. > Ethernet address 0:3:ba:2a:11:b8, Host ID: 832605f7. > > > > Boot device: /pci@1f,0/network@a File and args: > 1000 Mbps FDXLink up > 36800 > Server IP address: 10.0.0.10 > Client IP address: 10.0.0.20 > Consoles: Open Firmware console > > Booting with sun4u support. > > FreeBSD/sparc64 bootstrap loader, Revision 1.0 > (root@obrian.cse.buffalo.edu, Sun Feb 24 17:36:50 UTC 2008) > bootpath="/pci@1f,0/network@a" > boot: ethernet address: 00:03:ba:2a:11:b8 > 1000 Mbps FDXLink up > net_open: server addr: 10.0.0.10 > net_open: server path: /tftpboot > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x6f0848+0x72c68 syms=[0x8+0x76920+0x8+0x6668e] > \ > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel] in 9 seconds... > > Type '?' for a list of commands, 'help' for more detailed help. > > OK set console > Available consoles: > ofw > operation not permitted > OK help set console > / > set console[=] > > Sets the current console. If is omitted, a list of > valid > - consoles will be displayed. > > OK set console=ofw > OK boot > nothing to autoload yet. > jumping to kernel entry at 0xc0070000. > 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 7.0-RELEASE #0: Mon Feb 25 09:35:41 UTC 2008 > root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > Timecounter "tick" frequency 650000000 Hz quality 1000 > real memory = 1073741824 (1024 MB) > avail memory = 1027727360 (980 MB) > cpu0: Sun Microsystems UltraSparc-IIe Processor (650.00 MHz CPU) > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413, REGOPS_FUNC) > nexus0: > pcib0: mem > 0x1fe00000000-0x1fe0000ffff,0x1fe01000000-0x1fe010000ff irq > 2032,2030,2031,2021 on nexus0 > pcib0: Hummingbird compatible, impl 0, version 0, IGN 0x1f, bus A > pcib0: [FILTER] > pcib0: [FILTER] > pcib0: [GIANT-LOCKED] > pcib0: [ITHREAD] > pcib0 dvma: DVMA map: 0xc0000000 to 0xc3ffffff > pcib0: [FILTER] > pci0: on pcib0 > isab0: at device 7.0 on pci0 > isa_setup_children: no PnP map entry for node 0xf006f7b8: bscbus > isa0: on isab0 > pci0: at device 3.0 (no driver attached) > pci0: at device 10.0 (no driver attached) > pci0: at device 11.0 (no driver attached) > atapci0: port > 0x900-0x907,0x918-0x91b,0x910-0x917,0x908-0x90b,0x920-0x92f at device > 13.0 on pci0 > atapci0: [ITHREAD] > atapci0: using PIO transfers above 137GB as workaround for 48bit DMA > access bug, expect reduced performance > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > nexus0: type unknown (no driver attached) > > At this point it just hangs..... any clues ? > Could you please provide the output of a verbose boot and if possible also the Open Firmware device tree dump done under f.e. Solaris? Marius From hackr_d at yahoo.com Fri Jul 4 02:41:14 2008 From: hackr_d at yahoo.com (Donn Miller) Date: Fri Jul 4 02:41:52 2008 Subject: Ultra Sparc III systems (Blade 1000/2000) Message-ID: <570201.9027.qm@web35706.mail.mud.yahoo.com> Hi, I've got a Blade 2000 coming soon (in a couple of days). It has a single US III, 1.2GHz, 4GB RAM. I'd be willing to do testing if anyone has done an unofficial test release for this. :-) Donn From bugmaster at FreeBSD.org Mon Jul 7 11:07:07 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 7 11:09:15 2008 Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org Message-ID: <200807071107.m67B76GG062178@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC o sparc/80410 sparc64 [netgraph] netgraph is causing crash with mpd on sparc o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/95297 sparc64 vt100 term does not work in install o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 f sparc/105607 sparc64 [modules] modules on sparc64 don't work with >= 4GB f sparc/106251 sparc64 [libmalloc] malloc fails > for large allocations s sparc/107087 sparc64 system is hinged during boot from CD o sparc/109908 sparc64 apache22 mod_perl issue on sparc64 o sparc/113556 sparc64 panic: trap: memory address not aligned; Rebooting... o sparc/118932 sparc64 7.0-BETA4/sparc-64 kernel panic in rip_output o sparc/119017 sparc64 7.0 Beta won't install on U60 s sparc/119239 sparc64 gdb coredumps on sparc64 o sparc/119244 sparc64 X11Forwarding to X11 server on sparc crashes Xorg 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f sparc/105157 sparc64 No reply to ping on Sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 o sparc/119240 sparc64 top has WCPU over 100% on UP system 3 problems total. From bugmaster at FreeBSD.org Mon Jul 14 11:07:06 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 14 11:08:55 2008 Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org Message-ID: <200807141107.m6EB759L014556@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC o sparc/80410 sparc64 [netgraph] netgraph is causing crash with mpd on sparc o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/95297 sparc64 vt100 term does not work in install o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 f sparc/105607 sparc64 [modules] modules on sparc64 don't work with >= 4GB f sparc/106251 sparc64 [libmalloc] malloc fails > for large allocations s sparc/107087 sparc64 system is hinged during boot from CD o sparc/109908 sparc64 apache22 mod_perl issue on sparc64 o sparc/113556 sparc64 panic: trap: memory address not aligned; Rebooting... o sparc/118932 sparc64 7.0-BETA4/sparc-64 kernel panic in rip_output o sparc/119017 sparc64 7.0 Beta won't install on U60 s sparc/119239 sparc64 gdb coredumps on sparc64 o sparc/119244 sparc64 X11Forwarding to X11 server on sparc crashes Xorg 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f sparc/105157 sparc64 No reply to ping on Sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 o sparc/119240 sparc64 top has WCPU over 100% on UP system 3 problems total. From didrik at kth.se Thu Jul 17 17:19:47 2008 From: didrik at kth.se (Didrik Madheden) Date: Thu Jul 17 17:19:54 2008 Subject: Sparc64 partitions compatible with PC? Message-ID: <57797.91.95.8.243.1216313772.squirrel@webmail.sys.kth.se> I have a Sparc box that I use mainly as an FTP server. (SunBlad 100 if it makes a ny difference) What I want to do now is to move that disk to an x86 box. The disk is partitioned in the following way: A single big native partition, with a number of labels. (Or are disklabels the native partitioning on Sparc? I don't remember) Anyway, I have a couple of small labels for the usual system stuff and a big one for storage. What I want to do is wipe the system related labels and only keep the one used for storage. (And consequently do a fresh install on the PC) My concern however is that the Sun partitioning will be incompatible with PC partitioning. If so, can anyone give advice on how to move the disk to a PC? Since it's a big disk, I'd like to avoid mirroring it. /Didrik Madheden From tnelson at fudnet.net Thu Jul 17 17:52:35 2008 From: tnelson at fudnet.net (Tim Nelson) Date: Thu Jul 17 17:52:42 2008 Subject: Sparc64 partitions compatible with PC? In-Reply-To: <8599571.01216315819690.JavaMail.root@zmail.fudnet.net> Message-ID: <23079290.21216315856959.JavaMail.root@zmail.fudnet.net> IIRC... there are some oddities between the disk labels having to do with the big and little "endian-ness" (if that's a word?!?) on each of the architectures. I tried using a SPARC partitioned drive on an x86 machine a while back and never was able to access the data. Hopefully someone else has had a better experience with it... --Tim ----- Original Message ----- From: "Didrik Madheden" To: freebsd-sparc64@FreeBSD.org Sent: Thursday, July 17, 2008 11:56:12 AM GMT -06:00 US/Canada Central Subject: Sparc64 partitions compatible with PC? I have a Sparc box that I use mainly as an FTP server. (SunBlad 100 if it makes a ny difference) What I want to do now is to move that disk to an x86 box. The disk is partitioned in the following way: A single big native partition, with a number of labels. (Or are disklabels the native partitioning on Sparc? I don't remember) Anyway, I have a couple of small labels for the usual system stuff and a big one for storage. What I want to do is wipe the system related labels and only keep the one used for storage. (And consequently do a fresh install on the PC) My concern however is that the Sun partitioning will be incompatible with PC partitioning. If so, can anyone give advice on how to move the disk to a PC? Since it's a big disk, I'd like to avoid mirroring it. /Didrik Madheden _______________________________________________ freebsd-sparc64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" From carton at Ivy.NET Thu Jul 17 18:32:34 2008 From: carton at Ivy.NET (Miles Nordin) Date: Thu Jul 17 18:32:40 2008 Subject: Sparc64 partitions compatible with PC? In-Reply-To: <57797.91.95.8.243.1216313772.squirrel@webmail.sys.kth.se> (Didrik Madheden's message of "Thu, 17 Jul 2008 18:56:12 +0200 (CEST)") References: <57797.91.95.8.243.1216313772.squirrel@webmail.sys.kth.se> Message-ID: >>>>> "dm" == Didrik Madheden writes: dm> I have a Sparc box that I use mainly as an FTP dm> server. (SunBlad 100 if it makes a ny difference) What I want dm> to do now is to move that disk to an x86 box. backup the disk label to a text file on the sparc box, and move it to the PeeCee OOB. then load the label onto the disk on the peecee. this writes to the disk, and may make it unreadable on both machines because it might go wrong, or general compatibility prudery and kludges on the peecee may eat up a larger fixed portion at the beginning of the disk making it impossible to line up the start of your first filesystem properly. It is possible to put plain BSD labels onto FreeBSD/i386 disks: pizarro:~$ uname -a FreeBSD pizarro 6.0-RELEASE FreeBSD 6.0-RELEASE #1: Tue Nov 8 20:23:54 UTC 2005 carton@cortez:/usr/src/sys/i386/compile/CORTEZ i386 pizarro:~$ df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad4a 63214 34552 23606 59% / devfs 1 1 0 100% /dev /dev/ad4e 7615086 2864168 4141712 41% /usr devfs 1 1 0 100% /usr/var/chroot/named/dev see how my devices are ad4a instead of ad4s1a? The missing s1 means no MBR label. this is what you need to do, to make the SMD 'a' slice start in sector 0. (unless you were smart enough not to put your big FTP filesystem into the 'a' slice). The installer won't do this type of raw label, even if you set it to Dangerous Mode, so I expect FreeBSD to try to resist. I don't remember how I did it. definitely ``by hand'' and I remember some obstinance. maybe you should back up the first 1MB of the raw unpartitioned disk before you start. and for the love of god dont make any ``extended'' MBR partitions on the peecee because this scatters tiny labels all over the outer reaches of your disk, so the 1MB backup won't protect you. or, use Linux. it ``just works''. each labeling scheme is a ``kernel module''. You can build all the weird modules on Linux/i386, load them all, and read your Sun disklabel using the Sun disklabel Interpretation Kernel Module. It will print a vanity string in dmesg when it loads: Ability to Read Sun Disklabels translation module loaded. [(c) 1998 by darklightw4rriorz@pheerdoom.net] Then you can download some weird version of fdisk like sunfdisk2-ng or something, that's able to write Sun disklabels---this will let you edit the label on the disk, then call an ioctl to load the new label into the kernel. BSD has the foundations of a better architecture. there are ioctls in bsd to load the in-core disklabel without touching the on-disk label. There are userland programs to read bsd labels, bsd slices, smd labels, and mbr labels in BSD, which could be built on non-native architectures, to read the label and load it into the kernel without touching the disk. There is a whole geom framework for doing things more complicated than simple disklabels. but in my own experience, the right command line flags to do what you want just don't exist. -------------- 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/20080717/fc01e6fe/attachment.pgp From didrik at kth.se Thu Jul 17 19:35:33 2008 From: didrik at kth.se (Didrik Madheden) Date: Thu Jul 17 19:35:41 2008 Subject: Sparc64 partitions compatible with PC? In-Reply-To: References: <57797.91.95.8.243.1216313772.squirrel@webmail.sys.kth.se> Message-ID: <64373.91.95.8.243.1216323299.squirrel@webmail.sys.kth.se> A note to Tim: Endianness (Without the dash) is a word. ;) >>>>>> "dm" == Didrik Madheden writes: > > dm> I have a Sparc box that I use mainly as an FTP > dm> server. (SunBlad 100 if it makes a ny difference) What I want > dm> to do now is to move that disk to an x86 box. > > backup the disk label to a text file on the sparc box, and move it to > the PeeCee OOB. > > then load the label onto the disk on the peecee. this writes to the > disk, and may make it unreadable on both machines because it might go > wrong, or general compatibility prudery and kludges on the peecee may > eat up a larger fixed portion at the beginning of the disk making it > impossible to line up the start of your first filesystem properly. ... > maybe you should back up the first 1MB of the raw unpartitioned disk > before you start. and for the love of god dont make any ``extended'' > MBR partitions on the peecee because this scatters tiny labels all > over the outer reaches of your disk, so the 1MB backup won't protect > you. Could it be that there's some sort of sector offset when reading the disk on the PC compared to when reading on the Sparc? Doesn't sound logical, but you never know? Reason I'm asking is because if possible I'd prefer making the backup on a PC, since I only have one Sparc installation, and it was a hell to get the install CD to boot correctly correctly. (As you might remember from about a year ago) If I'm not totally mistaken, the backup process is as easy cat /dev/ad0 > backupfile and then ^C when backupfile is big enough. Off-topic rant: But something I've been thinking about is that some people seems to prefer something like dd if=/dev/ad0 of=bakfile even for simple stream copying, when it could evidently be done just as easily with cat. Or am I missing something? > > It is possible to put plain BSD labels onto FreeBSD/i386 disks: > > pizarro:~$ uname -a > FreeBSD pizarro 6.0-RELEASE FreeBSD 6.0-RELEASE #1: Tue Nov 8 20:23:54 > UTC 2005 carton@cortez:/usr/src/sys/i386/compile/CORTEZ i386 > pizarro:~$ df -k > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ad4a 63214 34552 23606 59% / > devfs 1 1 0 100% /dev > /dev/ad4e 7615086 2864168 4141712 41% /usr > devfs 1 1 0 100% /usr/var/chroot/named/dev > > see how my devices are ad4a instead of ad4s1a? The missing s1 means > no MBR label. > > this is what you need to do, to make the SMD 'a' slice start in sector > 0. (unless you were smart enough not to put your big FTP filesystem > into the 'a' slice). The installer won't do this type of raw label, > even if you set it to Dangerous Mode, so I expect FreeBSD to try to > resist. I don't remember how I did it. definitely ``by hand'' and I > remember some obstinance. I did disklabel -e ad0 on the Sparc and got this: # size offset # ---------- ---------- a: 20972448 0 b: 2097648 41612 c: 54757584 0 d: 20972448 20806 e: 737378208 43693 Size in sector, Hmm... Do the values > > > or, use Linux. it ``just works''. each labeling scheme is a ``kernel > module''. You can build all the weird modules on Linux/i386, load > them all, and read your Sun disklabel using the Sun disklabel > Interpretation Kernel Module. It will print a vanity string in dmesg > when it loads: > > Ability to Read Sun Disklabels translation module loaded. [(c) 1998 by > darklightw4rriorz@pheerdoom.net] > > Then you can download some weird version of fdisk like sunfdisk2-ng or > something, that's able to write Sun disklabels---this will let you > edit the label on the disk, then call an ioctl to load the new label > into the kernel. > > BSD has the foundations of a better architecture. there are ioctls in > bsd to load the in-core disklabel without touching the on-disk label. > There are userland programs to read bsd labels, bsd slices, smd > labels, and mbr labels in BSD, which could be built on non-native > architectures, to read the label and load it into the kernel without > touching the disk. There is a whole geom framework for doing things > more complicated than simple disklabels. but in my own experience, > the right command line flags to do what you want just don't exist. > From dwiest at vailsys.com Thu Jul 17 19:42:37 2008 From: dwiest at vailsys.com (Damian Wiest) Date: Thu Jul 17 19:42:46 2008 Subject: Sparc64 partitions compatible with PC? In-Reply-To: References: <57797.91.95.8.243.1216313772.squirrel@webmail.sys.kth.se> Message-ID: <20080717192347.GT63814@dfwdamian.vail> On Thu, Jul 17, 2008 at 02:32:28PM -0400, Miles Nordin wrote: [snip] > It is possible to put plain BSD labels onto FreeBSD/i386 disks: > > pizarro:~$ uname -a > FreeBSD pizarro 6.0-RELEASE FreeBSD 6.0-RELEASE #1: Tue Nov 8 20:23:54 UTC 2005 carton@cortez:/usr/src/sys/i386/compile/CORTEZ i386 > pizarro:~$ df -k > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ad4a 63214 34552 23606 59% / > devfs 1 1 0 100% /dev > /dev/ad4e 7615086 2864168 4141712 41% /usr > devfs 1 1 0 100% /usr/var/chroot/named/dev > > see how my devices are ad4a instead of ad4s1a? The missing s1 means > no MBR label. I would be extremely careful when doing this with removable disks (ie. external USB drives) as I've had other systems wipe out my data/label when mounting such a drive. Some time ago I had a USB drive with just a BSD label and ufs filesystems; everything worked fine on my FreeBSD workstation. When I attempted to mount the thing on a box running OS X (Tiger) the system locked up. I moved the disk back to my workstation only to discover that the BSD label had been wiped out. Now, that's not FreeBSD's fault, but I'd be careful when moving such disks between systems. -Damian From carton at Ivy.NET Thu Jul 17 20:17:08 2008 From: carton at Ivy.NET (Miles Nordin) Date: Thu Jul 17 20:17:15 2008 Subject: Sparc64 partitions compatible with PC? In-Reply-To: <64373.91.95.8.243.1216323299.squirrel@webmail.sys.kth.se> (Didrik Madheden's message of "Thu, 17 Jul 2008 21:34:59 +0200 (CEST)") References: <57797.91.95.8.243.1216313772.squirrel@webmail.sys.kth.se> <64373.91.95.8.243.1216323299.squirrel@webmail.sys.kth.se> Message-ID: >>>>> "dm" == Didrik Madheden writes: dm> dd if=/dev/ad0 of=bakfile dd if=/dev/ad0 of=bakfile bs=512 count=$(( 2 * 1024 )) dd if=bakfile of=/dev/ad0 bs=512 conv=notrunc the 'notrunc' is unnecessary for a hard disk 'of' but makes the restore scheme work also if ad0 is an image of a disk as you'd use with vnd instead of a block device. dm> even for simple stream copying, I use dd from habit. For big copies on ATA disks, bs=$(( 56 * 1024 )) makes the copy go faster, so that is merit to 'dd'. For recovering bad disks, 'bs=512 conv=noerror,sync' allows replacing unreadable blocks with zeroes which cat cannot do. For properly working disks I think cat is likely to work fine but...ymmv. I'm not sure why dd is so habitual. For tape, in my experience with ancient DAT, you must always use dd because the ``files'' on tapes are not ordinary ordered-sequence-of-octets files. They have a block size recorded on the tape, and they can only be read with the same block size with which they were written. If you don't know at what block size the tape was written, it can actually be difficult to read the tape, though there is probably some trick to it. If the tape is written like this: tar cf - . | gzip > /dev/nrst0 you may never figure out how to read it because gzip will write blocks of various random sizes, so you need to: tar cf - . | gzip | dd of=/dev/nrst0 bs=5120 or let tar invoke gzip with the z flag which will do this implicitly IIRC. Disks can be read at a variety of block sizes, but depending on the driver some OS's may be more obstinate than others, so I think it might be best to always use dd, and use with a block size that's a multiple of 512 for disks and 2048 for CD's. If you want to use gzip, do it as so: dd if=/dev/ad0a bs= | gzip > file gunzip < file | dd of=/dev/ad0a bs= The last command, I don't fully understand its quirks. I've actually had problems with dd through ssh pipes saying things like gunzip < backup | ssh "dd of=/dev/ad0 bs=$(( 56 * 1024 ))" 2+520894 blocks input 520896+0 blocks output which means I think it may have written garbage all over ad0, by splitting the output stream into 56k chunks arbitrarily depending on how TCP broke up dd's reads of stdin. I would expect this problem to happen with conv=sync, but it might happen other times, depending on your dd version. I think QNX might have been involved which in my experience has a lot of bugs. I forget what I did to fix it. I remember trying things like: gunzip < backup | ssh "dd ibs=1000 obs=$(( 56 * 1024 )) | dd of=/dev/ad0 bs=$(( 56 * 1024 ))" but I don't know what finally got my disk properly restored, nor how much of the problem was my not understanding the ways of dd, how much was getting lucky using one OS improperly while another is less forgiving, and how much was QNX bugs. I was really impatient and didn't fully understand what was going on. If someone knows how to tell dd, ``please keep reading the input file until you get either a full obs block, or an EOF. Do not write anything to the output file until one of those two things, EITHER of those things, has happened,'' I would like to hear it. but in practice, stumbling along seems to work ok, for me, if I go back and check my work with md5sum or 'mount ...; pax -w /mnt > /dev/null' before deleting the backup file. HTH. :( -------------- 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/20080717/4ae51220/attachment.pgp From xcllnt at mac.com Thu Jul 17 20:45:24 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Jul 17 20:45:30 2008 Subject: Sparc64 partitions compatible with PC? In-Reply-To: <57797.91.95.8.243.1216313772.squirrel@webmail.sys.kth.se> References: <57797.91.95.8.243.1216313772.squirrel@webmail.sys.kth.se> Message-ID: <039F6F4D-3758-45A2-9D9C-02562F3EF27D@mac.com> On Jul 17, 2008, at 9:56 AM, Didrik Madheden wrote: > I have a Sparc box that I use mainly as an FTP server. (SunBlad 100 > if it > makes a ny difference) What I want to do now is to move that disk to > an > x86 box. > The disk is partitioned in the following way: A single big native > partition, with a number of labels. (Or are disklabels the native > partitioning on Sparc? I don't remember) > Anyway, I have a couple of small labels for the usual system stuff > and a > big one for storage. What I want to do is wipe the system related > labels > and only keep the one used for storage. (And consequently do a fresh > install on the PC) > My concern however is that the Sun partitioning will be incompatible > with > PC partitioning. If so, can anyone give advice on how to move the > disk to > a PC? > Since it's a big disk, I'd like to avoid mirroring it. FreeBSD 7-STABLE supports sparc64 labeling, aka vtoc8. This is done with gpart. You can build and load the geom_part_vtoc8 kernel module and it'll automatically detect the partitioning of the disk. You can use the gpart(8) tool to look at the partitioning and even relabel the disk. I don't know if UFS is going to give you problems with the endianness though... FYI, -- Marcel Moolenaar xcllnt@mac.com From didrik at kth.se Fri Jul 18 21:34:36 2008 From: didrik at kth.se (Didrik Madheden) Date: Fri Jul 18 21:34:43 2008 Subject: Sparc64 partitions compatible with PC? In-Reply-To: <64373.91.95.8.243.1216323299.squirrel@webmail.sys.kth.se> References: <57797.91.95.8.243.1216313772.squirrel@webmail.sys.kth.se> <64373.91.95.8.243.1216323299.squirrel@webmail.sys.kth.se> Message-ID: <49814.91.95.8.243.1216416842.squirrel@webmail.sys.kth.se> I wish to apologoize for me previous mail. For some reason I pressed some key and managed to send it before I was done with it. Lousy custom university webmail. They're getting rid of it just now in favour for SquirrelMail... Not a day too early. Anuway... > I did disklabel -e ad0 on the Sparc and got this: > > # size offset > # ---------- ---------- > a: 20972448 0 > b: 2097648 41612 > c: 54757584 0 > d: 20972448 20806 > e: 737378208 43693 > This was the output disklabel -e ad0 (On the Sparc, running the existing installation of 6.2) This is where things are starting to get fishy... I noticed the file opened in vi, and to quit, I accidently did :wq instead of :q. The program then complained that the slices reached outside of the partition. (Or something to that effect; don't remember exactly now) Is that a warning sign? I also noticed there's a partition too much. From the sizes, I recognice a and d as my system partitions, b as my swap and e as my big storage drive. But what the heck is c? It's not the sume of the sizes of the other labels either. It just doesn't make sense from any angle. I guess I messed around in the label editor when oing the Sparc installation, but I don't see how I could've ended up with the final result as shown above. I'm currently in 7.0 installation mode on Mr Pee-C. What I've done so far is create a partition covering the whole disk. (DD mode, then no, which covered the same range as teh previously existing partition) I've tried recreating slices a, b, d and then pressing C to see what size the editor would suggest. What it suggested was 737380224, which is exactly 2016 blocks too long. So my dilemma now is this: Where does label really begin? *Is it perhaps so that the FreeBSD style partition used a little more overhead, so I should make the previos partitions 2016 blocks longer to compensate for the offset, and make the label the same length it used to be? *Or is it perhaps so that my PC thinks that the disk is 2 sectors/cylinders (Which unit?) well, 2 somethings longer than the Sparc, and that the spot i hit after creating the three other labels is in fact the right one. *Does it really matter? will FreeBSD perhaps compensate for the offset and still work? How fuzzy is it? And a question of importance! How to make sure the area I want to save doesn't get overwritten? I suppose T for toggle newfs=N will do the job, but I'm paranoid, so I want a second opinion. Anything more I need to do? >> BSD has the foundations of a better architecture. there are ioctls in >> bsd to load the in-core disklabel without touching the on-disk label. >> There are userland programs to read bsd labels, bsd slices, smd >> labels, and mbr labels in BSD, which could be built on non-native >> architectures, to read the label and load it into the kernel without >> touching the disk. There is a whole geom framework for doing things >> more complicated than simple disklabels. but in my own experience, >> the right command line flags to do what you want just don't exist. If I interpret this correctly: There's no good way to pop the disk into a box with an existing installation and type the magic command to mount blocks X to Y on the disk as an imaginary, ro file system? /Didrik Madheden From didrik at kth.se Sat Jul 19 17:45:01 2008 From: didrik at kth.se (Didrik Madheden) Date: Sat Jul 19 17:45:08 2008 Subject: Sparc64 partitions compatible with PC? (Problem solved, sort of) In-Reply-To: <49814.91.95.8.243.1216416842.squirrel@webmail.sys.kth.se> References: <57797.91.95.8.243.1216313772.squirrel@webmail.sys.kth.se> <64373.91.95.8.243.1216323299.squirrel@webmail.sys.kth.se> <49814.91.95.8.243.1216416842.squirrel@webmail.sys.kth.se> Message-ID: <61163.91.95.8.243.1216489465.squirrel@webmail.sys.kth.se> So, I might've reached a solution of sorts. I've swore and torn my hair while trying to get FBSD on the PC to detect my file system. So now I've reinstalled FBSD on the Sparc, where I entered the values from my text file, and instead of saying "Invalid parameter" or whatever it said before, it now started fsck_ffs which finished without errors, and my files seem to be intact, so everything is now fine and dandy. I think I've given up the idea of trying to reuse the same fs, so I'm now going to back up the data over FTP and create a whole new fs on the PC. Among the many things I've done the last 24 hours I've tried a demo version of some recovery software which asked me whether the partition I was looking for was from an x86 or Sparc installation, suggesting there might be differences, most probably endianness. So I guess that's the end of this problem. Oh, and thanks Miles for all the info, especially the response to my mini rant about dd. And all other people as well of course. Here's what I've learned today: (OpenBoot commands) nvalias cdrom /pci@1f,0/ide@cdrom@X,0:f nvramrc (Don't know if this one is actually needed) boot cdrom Where X=0 for pri master up to 3 for sec slave. I always had this idea that cdrom always pointed to an auto-detected cdrom drive. Even so I think the drive that came with my box is a bit shaky. /Didrik Madheden From carton at Ivy.NET Sun Jul 20 11:19:23 2008 From: carton at Ivy.NET (Miles Nordin) Date: Sun Jul 20 11:19:30 2008 Subject: Sparc64 partitions compatible with PC? In-Reply-To: <49814.91.95.8.243.1216416842.squirrel@webmail.sys.kth.se> (Didrik Madheden's message of "Fri, 18 Jul 2008 23:34:02 +0200 (CEST)") References: <57797.91.95.8.243.1216313772.squirrel@webmail.sys.kth.se> <64373.91.95.8.243.1216323299.squirrel@webmail.sys.kth.se> <49814.91.95.8.243.1216416842.squirrel@webmail.sys.kth.se> Message-ID: >>>>> "dm" == Didrik Madheden writes: dm> 2016 blocks too long. possibly the command line tools like fdisk and bsdlabel will let you enter with better resolution? i don't know. dm> *Does it really matter? will FreeBSD perhaps compensate dm> for the offset and still work? How fuzzy is it? It's not at all fuzzy. The start of the partition has to be exactly the same, down to the sector, as when the filesystem was created. The size of the partition has to be at least as big as when the filesystem was created, but may harmlessly be bigger. The geometry (cylinders per disk, heads per cylinder, sectors per track) doesn't matter, only the offset and size in sectors. dm> I suppose T for toggle newfs=N will do the job, but I'm dm> paranoid, so I want a second opinion. second opinion is, don't use the installer at all. Install onto another disk, or use a livecd. but it's just an opinion. Remember not to make any extended MBR partitions, ever. It may actually be a problem just to make an MBR partition with a BSD label inside it, because the label could get written at the beginning of the MBR slice, somewhere in the middle of your sparc partition. # size offset # ---------- ---------- a: 20972448 0 b: 2097648 41612 c: 54757584 0 d: 20972448 20806 e: 737378208 43693 ^^^ this is a crazy disklabel with lots of overlapping partitions. AFAICT it's not right. -------------- 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/20080720/f7c9f370/attachment.pgp From didrik at kth.se Sun Jul 20 22:41:54 2008 From: didrik at kth.se (Didrik Madheden) Date: Sun Jul 20 22:42:01 2008 Subject: Sparc64 partitions compatible with PC? In-Reply-To: References: <57797.91.95.8.243.1216313772.squirrel@webmail.sys.kth.se> <64373.91.95.8.243.1216323299.squirrel@webmail.sys.kth.se> <49814.91.95.8.243.1216416842.squirrel@webmail.sys.kth.se> Message-ID: <28735.80.217.136.213.1216593555.squirrel@webmail.sys.kth.se> >>>>>> "dm" == Didrik Madheden writes: > > dm> 2016 blocks too long. > > possibly the command line tools like fdisk and bsdlabel will let you > enter with better resolution? i don't know. The label editor invoked through sysinstall already let me specify values with higher resolution. The problem is that that yields 2016 possible places where the FS could start. (As you pointed out, and as I suspected, you need to hit the right spot) And that's more manual labour than I'm willing to sacrifice. I tried three values, aligned to 1008 sectors. (1008 is the cylinder size) As I said in my other mail, I've no successfully installed FBSD on the Sparc again and I'm now backing it all up over FTP. > dm> I suppose T for toggle newfs=N will do the job, but I'm > dm> paranoid, so I want a second opinion. > > second opinion is, don't use the installer at all. Install onto > another disk, or use a livecd. but it's just an opinion. > > Remember not to make any extended MBR partitions, ever. > > It may actually be a problem just to make an MBR partition with a BSD > label inside it, because the label could get written at the beginning > of the MBR slice, somewhere in the middle of your sparc partition. Hmm, what I tried, AFAIK, was to make a dd (Dangerously dedicated) partition, ranging from absolute 0-the last sector. Since the relevant label was not the first one, I suppose it would be contained within the dd partition? Not that it really matters now... > # size offset > # ---------- ---------- > a: 20972448 0 > b: 2097648 41612 > c: 54757584 0 > d: 20972448 20806 > e: 737378208 43693 > > ^^^ this is a crazy disklabel with lots of overlapping partitions. > AFAICT it's not right. Actually, the only thing that's downright wrong is C, which overlaps other labels. The other labels add up just fine. Remember that offset and size are in different units. 1 cylinder = 1008 sectors. (Or whatever the units are) If you put the labels in the order a, d, b, e, and you'll see that it all adds up. /Didrik Madheden From didrik at kth.se Sun Jul 20 22:47:29 2008 From: didrik at kth.se (Didrik Madheden) Date: Sun Jul 20 22:47:35 2008 Subject: Dead Sparc Message-ID: <28915.80.217.136.213.1216594016.squirrel@webmail.sys.kth.se> During my experiments I happened to put in other RAM bricks from a PC. And then the Sparc died. (Died as in won't even make the PSU fan start spinning any more) Even if I put back the original RAM. The original RAM was 133 MHz, and the other one was 100 MHz. I don't see how that would kill the computer, probably it was just the PSU that died co-incidentally. (I'll try manually starting the PSU later) Still, it's a strange coincidence. Anyone else had problems when putting in other RAM bricks? /Didrik Madheden From bugmaster at FreeBSD.org Mon Jul 21 11:07:03 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 21 11:08:49 2008 Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org Message-ID: <200807211107.m6LB72sM032011@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC o sparc/80410 sparc64 [netgraph] netgraph is causing crash with mpd on sparc o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/95297 sparc64 vt100 term does not work in install o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 f sparc/105607 sparc64 [modules] modules on sparc64 don't work with >= 4GB f sparc/106251 sparc64 [libmalloc] malloc fails > for large allocations s sparc/107087 sparc64 system is hinged during boot from CD o sparc/109908 sparc64 apache22 mod_perl issue on sparc64 o sparc/113556 sparc64 panic: trap: memory address not aligned; Rebooting... o sparc/118932 sparc64 7.0-BETA4/sparc-64 kernel panic in rip_output o sparc/119017 sparc64 7.0 Beta won't install on U60 s sparc/119239 sparc64 gdb coredumps on sparc64 o sparc/119244 sparc64 X11Forwarding to X11 server on sparc crashes Xorg 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f sparc/105157 sparc64 No reply to ping on Sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 o sparc/119240 sparc64 top has WCPU over 100% on UP system 3 problems total. From tinderbox at freebsd.org Mon Jul 21 22:41:02 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Jul 21 22:41:14 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080721224059.96D1A73039@freebsd-current.sentex.ca> TB --- 2008-07-21 21:33:54 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-21 21:33:54 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-21 21:33:54 - cleaning the object tree TB --- 2008-07-21 21:34:17 - cvsupping the source tree TB --- 2008-07-21 21:34:17 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-21 21:34:24 - building world (CFLAGS=-O -pipe) TB --- 2008-07-21 21:34:24 - cd /src TB --- 2008-07-21 21:34:24 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 21 21:34:25 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 Jul 21 22:39:04 UTC 2008 TB --- 2008-07-21 22:39:04 - generating LINT kernel config TB --- 2008-07-21 22:39:04 - cd /src/sys/sun4v/conf TB --- 2008-07-21 22:39:04 - /usr/bin/make -B LINT TB --- 2008-07-21 22:39:04 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-21 22:39:04 - cd /src TB --- 2008-07-21 22:39:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 21 22:39:04 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 [...] machine -> /src/sys/sun4v/include sparc64 -> /src/sys/sparc64/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/sun4v/src/sys/LINT /src/sys/modules/mem/../../dev/mem/memdev.c /src/sys/modules/mem/../../sparc64/sparc64/mem.c /src/sys/modules/mem/../../sparc64/sparc64/mem.c:73:27: error: machine/cache.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/sys/modules/mem. *** 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-07-21 22:40:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-21 22:40:59 - ERROR: failed to build lint kernel TB --- 2008-07-21 22:40:59 - tinderbox aborted TB --- 2973.72 user 373.52 system 4024.80 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Tue Jul 22 03:53:48 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jul 22 03:54:00 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080722035345.62C0673039@freebsd-current.sentex.ca> TB --- 2008-07-22 02:39:39 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-22 02:39:39 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-07-22 02:39:39 - cleaning the object tree TB --- 2008-07-22 02:40:05 - cvsupping the source tree TB --- 2008-07-22 02:40:05 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-07-22 02:40:11 - building world (CFLAGS=-O -pipe) TB --- 2008-07-22 02:40:11 - cd /src TB --- 2008-07-22 02:40:11 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 22 02:40:13 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 Tue Jul 22 03:46:41 UTC 2008 TB --- 2008-07-22 03:46:41 - generating LINT kernel config TB --- 2008-07-22 03:46:41 - cd /src/sys/sparc64/conf TB --- 2008-07-22 03:46:41 - /usr/bin/make -B LINT TB --- 2008-07-22 03:46:41 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-22 03:46:41 - cd /src TB --- 2008-07-22 03:46:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 22 03:46:41 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netinet/ip_id.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netinet/in_mcast.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netinet/in_pcb.c cc1: warnings being treated as errors /src/sys/netinet/in_pcb.c: In function 'inp_4tuple_get': /src/sys/netinet/in_pcb.c:1306: warning: passing argument 1 of '_rw_assert' discards qualifiers from pointer target type /src/sys/netinet/in_pcb.c:1307: error: incompatible types in assignment /src/sys/netinet/in_pcb.c:1308: error: incompatible types in assignment *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-22 03:53:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-22 03:53:45 - ERROR: failed to build lint kernel TB --- 2008-07-22 03:53:45 - tinderbox aborted TB --- 3168.48 user 401.73 system 4446.16 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Tue Jul 22 04:14:08 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jul 22 04:14:30 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080722041404.6FF0073039@freebsd-current.sentex.ca> TB --- 2008-07-22 03:08:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-22 03:08:46 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-22 03:08:46 - cleaning the object tree TB --- 2008-07-22 03:09:06 - cvsupping the source tree TB --- 2008-07-22 03:09:06 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-22 03:09:13 - building world (CFLAGS=-O -pipe) TB --- 2008-07-22 03:09:13 - cd /src TB --- 2008-07-22 03:09:13 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 22 03:09:14 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 Tue Jul 22 04:12:16 UTC 2008 TB --- 2008-07-22 04:12:16 - generating LINT kernel config TB --- 2008-07-22 04:12:16 - cd /src/sys/sun4v/conf TB --- 2008-07-22 04:12:16 - /usr/bin/make -B LINT TB --- 2008-07-22 04:12:16 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-22 04:12:16 - cd /src TB --- 2008-07-22 04:12:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 22 04:12:16 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 [...] machine -> /src/sys/sun4v/include sparc64 -> /src/sys/sparc64/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/sun4v/src/sys/LINT /src/sys/modules/mem/../../dev/mem/memdev.c /src/sys/modules/mem/../../sparc64/sparc64/mem.c /src/sys/modules/mem/../../sparc64/sparc64/mem.c:73:27: error: machine/cache.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/sys/modules/mem. *** 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-07-22 04:14:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-22 04:14:04 - ERROR: failed to build lint kernel TB --- 2008-07-22 04:14:04 - tinderbox aborted TB --- 2963.52 user 376.44 system 3917.59 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Tue Jul 22 10:35:56 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jul 22 10:36:03 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080722103552.D7F8473039@freebsd-current.sentex.ca> TB --- 2008-07-22 09:27:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-22 09:27:11 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-22 09:27:11 - cleaning the object tree TB --- 2008-07-22 09:27:31 - cvsupping the source tree TB --- 2008-07-22 09:27:31 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-22 09:27:39 - building world (CFLAGS=-O -pipe) TB --- 2008-07-22 09:27:39 - cd /src TB --- 2008-07-22 09:27:39 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 22 09:27:40 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 Tue Jul 22 10:33:29 UTC 2008 TB --- 2008-07-22 10:33:29 - generating LINT kernel config TB --- 2008-07-22 10:33:29 - cd /src/sys/sun4v/conf TB --- 2008-07-22 10:33:29 - /usr/bin/make -B LINT TB --- 2008-07-22 10:33:29 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-22 10:33:29 - cd /src TB --- 2008-07-22 10:33:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 22 10:33:29 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 [...] machine -> /src/sys/sun4v/include sparc64 -> /src/sys/sparc64/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/sun4v/src/sys/LINT /src/sys/modules/mem/../../dev/mem/memdev.c /src/sys/modules/mem/../../sparc64/sparc64/mem.c /src/sys/modules/mem/../../sparc64/sparc64/mem.c:73:27: error: machine/cache.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/sys/modules/mem. *** 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-07-22 10:35:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-22 10:35:52 - ERROR: failed to build lint kernel TB --- 2008-07-22 10:35:52 - tinderbox aborted TB --- 2981.77 user 374.44 system 4121.66 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Wed Jul 23 16:09:09 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Jul 23 16:09:27 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080723160907.3DABB73039@freebsd-current.sentex.ca> TB --- 2008-07-23 15:44:25 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-23 15:44:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-07-23 15:44:25 - cleaning the object tree TB --- 2008-07-23 15:44:50 - cvsupping the source tree TB --- 2008-07-23 15:44:50 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-07-23 15:44:56 - building world (CFLAGS=-O -pipe) TB --- 2008-07-23 15:44:56 - cd /src TB --- 2008-07-23 15:44:56 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 23 15:44:58 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 [...] cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -fstack-protector -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fm.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -fstack-protector -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris/sys/atomic.h:33, from /src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:67, from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/refcount.h:33, from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:54: /obj/sparc64/src/tmp/usr/include/machine/atomic.h:272: error: conflicting types for 'atomic_add_acq_int' /obj/sparc64/src/tmp/usr/include/sys/refcount.h:46: error: previous implicit declaration of 'atomic_add_acq_int' was here *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** 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-07-23 16:09:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-23 16:09:05 - ERROR: failed to build world TB --- 2008-07-23 16:09:05 - tinderbox aborted TB --- 1026.88 user 145.19 system 1480.05 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Wed Jul 23 16:27:11 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Jul 23 16:27:17 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080723162707.8BF2D73039@freebsd-current.sentex.ca> TB --- 2008-07-23 16:05:48 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-23 16:05:48 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-23 16:05:48 - cleaning the object tree TB --- 2008-07-23 16:06:08 - cvsupping the source tree TB --- 2008-07-23 16:06:08 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-23 16:06:14 - building world (CFLAGS=-O -pipe) TB --- 2008-07-23 16:06:14 - cd /src TB --- 2008-07-23 16:06:14 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 23 16:06: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 [...] cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -fstack-protector -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fm.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -fstack-protector -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris/sys/atomic.h:33, from /src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:67, from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/refcount.h:33, from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:54: /obj/sun4v/src/tmp/usr/include/machine/atomic.h:272: error: conflicting types for 'atomic_add_acq_int' /obj/sun4v/src/tmp/usr/include/sys/refcount.h:46: error: previous implicit declaration of 'atomic_add_acq_int' was here *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** 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-07-23 16:27:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-23 16:27:07 - ERROR: failed to build world TB --- 2008-07-23 16:27:07 - tinderbox aborted TB --- 1013.78 user 144.98 system 1278.63 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From hrs at FreeBSD.org Fri Jul 25 07:11:33 2008 From: hrs at FreeBSD.org (Hiroki Sato) Date: Fri Jul 25 07:11:40 2008 Subject: 7.0R panic in nfs_readdirrpc() In-Reply-To: <20080725.142554.124338824.hrs@allbsd.org> References: <20080725.142554.124338824.hrs@allbsd.org> Message-ID: <20080725.161039.177339309.hrs@allbsd.org> Almost the same panic occurred on sparc64, too. Memory alignment issue? ---- Tracing pid 14377 tid 100097 td 0xfffff800019aa340 panic() at panic+0x204 trap() at trap+0x4cc -- memory address not aligned sfar=0xfffff80001229c47 sfsr=0x40029 %o7=0xc045e8d4 -- nfs_readdirplusrpc() at nfs_readdirplusrpc+0x640 nfs_doio() at nfs_doio+0x358 nfs_bioread() at nfs_bioread+0xa78 nfs_readdir() at nfs_readdir+0x19c VOP_READDIR_APV() at VOP_READDIR_APV+0x58 getdirentries() at getdirentries+0x264 syscall() at syscall+0x314 -- syscall (196, FreeBSD ELF64, getdirentries) %o7=0x41117120 -- userland() at 0x41140a68 user trace: trap %o7=0x41117120 ---- Hiroki Sato wrote in <20080725.142554.124338824.hrs@allbsd.org>: hr> This panic seems reproducible when NFS over TCP is used (RELENG_7_0 on hr> HP rx1600, btw): hr> hr> ---- hr> fatal kernel trap (cpu 0): hr> hr> trap vector = 0x1e (Unaligned Reference) hr> cr.iip = 0xe000000004814a60 hr> cr.ipsr = 0x1210080a6010 (mfl,ic,i,dt,dfh,rt,cpl=0,it,ri=1,bn) hr> cr.isr = 0xa0400000000 (code=0,vector=0,r,ei=1,ed) hr> cr.ifa = 0xe00000000e745335 hr> curthread = 0xe0000000119366c0 hr> pid = 13638, comm = cvs hr> hr> [thread pid 13638 tid 100134 ] hr> Stopped at nfs_readdirrpc+0xd11: [M1] (p17) ld4 r49=[r8],0x4 hr> db> bt hr> Tracing pid 13638 tid 100134 td 0xe0000000119366c0 hr> nfs_readdirrpc(0xe0000000279db228, 0xa00000001b2d3178, 0xe00000001078fd00, 0xd, 0x10) at nfs_readdirrpc+0xd11 hr> nfs_doio(0xe000000011596f80, 0xa00000000f5eb4a0, 0xe00000001078fd00, 0xe0000000119366c0) at nfs_doio+0x670 hr> nfs_bioread(0xe000000011596f80, 0xa00000001b2d3378, 0x0, 0xe00000001078fd00) at nfs_bioread+0x10a0 hr> nfs_readdir(0xa00000001b2d33c8, 0xe000000011596f80, 0xa00000001b2d3390) at nfs_readdir+0x290 hr> VOP_READDIR_APV(0xe000000004b16120, 0xa00000001b2d33c8, 0xe0000000119366c0, 0xe000000004637390, 0x13ac) at VOP_READDIR_APV+0x1c0 hr> getdirentries(0xe0000000119366c0, 0xa00000001b2d34e8, 0x0, 0xe000000011596f80) at getdirentries+0x410 hr> syscall(0xa00000001b2d3400, 0xc4, 0x2000, 0xe0000000119366c0, 0xe00000001130ed38, 0xe000000004af3140, 0xc4, 0xa00000001b2d34e8) at syscall+0x410 hr> epc_syscall_return() at epc_syscall_return hr> db> hr> ---- -- | Hiroki SATO -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20080725/a13efad9/attachment.pgp From xcllnt at mac.com Fri Jul 25 16:25:58 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Jul 25 16:26:09 2008 Subject: 7.0R panic in nfs_readdirrpc() In-Reply-To: <20080725.161039.177339309.hrs@allbsd.org> References: <20080725.142554.124338824.hrs@allbsd.org> <20080725.161039.177339309.hrs@allbsd.org> Message-ID: On Jul 25, 2008, at 12:10 AM, Hiroki Sato wrote: > Almost the same panic occurred on sparc64, too. Memory alignment > issue? Yes. The exception is for a 4-byte load on a 1-byte aligned (i.e. odd) address. This is a code bug. I can't remember having these issues with NFS. Can you tell me more about your configuration? -- Marcel Moolenaar xcllnt@mac.com From hrs at FreeBSD.org Sat Jul 26 03:54:15 2008 From: hrs at FreeBSD.org (Hiroki Sato) Date: Sat Jul 26 03:54:22 2008 Subject: 7.0R panic in nfs_readdirrpc() In-Reply-To: References: <20080725.142554.124338824.hrs@allbsd.org> <20080725.161039.177339309.hrs@allbsd.org> Message-ID: <20080726.125342.231202831.hrs@allbsd.org> Marcel Moolenaar wrote in : xc> xc> On Jul 25, 2008, at 12:10 AM, Hiroki Sato wrote: xc> xc> > Almost the same panic occurred on sparc64, too. Memory alignment xc> > issue? xc> xc> Yes. The exception is for a 4-byte load on a 1-byte aligned xc> (i.e. odd) address. This is a code bug. xc> xc> I can't remember having these issues with NFS. Can you tell xc> me more about your configuration? Yes, it was 7.0R/i386 (server)<->7.0R/ia64 (client), mounted over TCP. Doing "cvs co src" from the server triggered the panic. I tried NFS over UDP (default) and one over TCP, the former has no problem under the same load. The mount_nfs options were "-T,ro,bg,intr,noinet6" and the difference was the transport protocol only. Maybe it is because TCP mount uses a larger block size than UDP by default. 7.0R/sparc64 can trigger it with the same configuration as I reported. I am not sure if 7.0R/ppc does, though. In i386<->i386 and i386<->amd64 case, TCP mount seems to work fine, but it is probably because i386 does not throw exception due to misaligned access. -- | Hiroki SATO -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20080726/0f207498/attachment.pgp From xcllnt at mac.com Sat Jul 26 16:06:56 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Jul 26 16:07:03 2008 Subject: 7.0R panic in nfs_readdirrpc() In-Reply-To: <20080726.125342.231202831.hrs@allbsd.org> References: <20080725.142554.124338824.hrs@allbsd.org> <20080725.161039.177339309.hrs@allbsd.org> <20080726.125342.231202831.hrs@allbsd.org> Message-ID: <7DAAC9F7-0827-4D64-B700-F224BBE30849@mac.com> On Jul 25, 2008, at 8:53 PM, Hiroki Sato wrote: > Marcel Moolenaar wrote > in : > > xc> > xc> On Jul 25, 2008, at 12:10 AM, Hiroki Sato wrote: > xc> > xc> > Almost the same panic occurred on sparc64, too. Memory > alignment > xc> > issue? > xc> > xc> Yes. The exception is for a 4-byte load on a 1-byte aligned > xc> (i.e. odd) address. This is a code bug. > xc> > xc> I can't remember having these issues with NFS. Can you tell > xc> me more about your configuration? > > Yes, it was 7.0R/i386 (server)<->7.0R/ia64 (client), mounted over > TCP. Doing "cvs co src" from the server triggered the panic. I > tried NFS over UDP (default) and one over TCP, the former has no > problem under the same load. Similar to me: o i386/7-STABLE server, o ia64/8-CURRENT client (which at the time of 7-release was therefore running 7-release). o I switched from UDP to TCP when TCP became default. I guess if UDP vs TCP is the problem, then it must be fixed already because I don't see the misalignment panics. I just don't know when it was fixed... -- Marcel Moolenaar xcllnt@mac.com From hrs at FreeBSD.org Sun Jul 27 01:29:55 2008 From: hrs at FreeBSD.org (Hiroki Sato) Date: Sun Jul 27 01:30:06 2008 Subject: 7.0R panic in nfs_readdirrpc() In-Reply-To: <7DAAC9F7-0827-4D64-B700-F224BBE30849@mac.com> References: <20080726.125342.231202831.hrs@allbsd.org> <7DAAC9F7-0827-4D64-B700-F224BBE30849@mac.com> Message-ID: <20080727.102915.253177202.hrs@allbsd.org> Marcel Moolenaar wrote in <7DAAC9F7-0827-4D64-B700-F224BBE30849@mac.com>: xc> > Yes, it was 7.0R/i386 (server)<->7.0R/ia64 (client), mounted over xc> > TCP. Doing "cvs co src" from the server triggered the panic. I xc> > tried NFS over UDP (default) and one over TCP, the former has no xc> > problem under the same load. xc> xc> Similar to me: xc> o i386/7-STABLE server, xc> o ia64/8-CURRENT client (which at the time of 7-release was xc> therefore running 7-release). xc> o I switched from UDP to TCP when TCP became default. xc> xc> I guess if UDP vs TCP is the problem, then it must be fixed xc> already because I don't see the misalignment panics. I just xc> don't know when it was fixed... Hmm, I see. I will try to gather more information on the cause. -- | Hiroki SATO -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20080727/3ba78cb0/attachment.pgp From bugmaster at FreeBSD.org Mon Jul 28 11:07:04 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 28 11:08:50 2008 Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org Message-ID: <200807281107.m6SB73tg079048@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC o sparc/80410 sparc64 [netgraph] netgraph is causing crash with mpd on sparc o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/95297 sparc64 vt100 term does not work in install o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 f sparc/105607 sparc64 [modules] modules on sparc64 don't work with >= 4GB f sparc/106251 sparc64 [libmalloc] malloc fails > for large allocations s sparc/107087 sparc64 system is hinged during boot from CD o sparc/109908 sparc64 apache22 mod_perl issue on sparc64 o sparc/113556 sparc64 panic: trap: memory address not aligned; Rebooting... o sparc/118932 sparc64 7.0-BETA4/sparc-64 kernel panic in rip_output o sparc/119017 sparc64 7.0 Beta won't install on U60 s sparc/119239 sparc64 gdb coredumps on sparc64 o sparc/119244 sparc64 X11Forwarding to X11 server on sparc crashes Xorg 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f sparc/105157 sparc64 No reply to ping on Sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 o sparc/119240 sparc64 top has WCPU over 100% on UP system 3 problems total. From tinderbox at freebsd.org Tue Jul 29 02:23:16 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jul 29 02:23:22 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080729022312.8E31373039@freebsd-current.sentex.ca> TB --- 2008-07-29 01:22:58 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-29 01:22:58 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-07-29 01:22:58 - cleaning the object tree TB --- 2008-07-29 01:23:22 - cvsupping the source tree TB --- 2008-07-29 01:23:22 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-07-29 01:23:28 - building world (CFLAGS=-O -pipe) TB --- 2008-07-29 01:23:28 - cd /src TB --- 2008-07-29 01:23:28 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 29 01:23:30 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 [...] grep -v '^#' < /src/share/timedef/lt_LT.ISO8859-4.src > lt_LT.ISO8859-4.out grep -v '^#' < /src/share/timedef/lt_LT.ISO8859-13.src > lt_LT.ISO8859-13.out grep -v '^#' < /src/share/timedef/lt_LT.UTF-8.src > lt_LT.UTF-8.out grep -v '^#' < /src/share/timedef/mn_MN.UTF-8.src > mn_MN.UTF-8.out grep -v '^#' < /src/share/timedef/nl_NL.ISO8859-1.src > nl_NL.ISO8859-1.out grep -v '^#' < /src/share/timedef/nn_NO.ISO8859-1.src > nn_NO.ISO8859-1.out grep -v '^#' < /src/share/timedef/nn_NO.UTF-8.src > nn_NO.UTF-8.out make: don't know how to make no_NO.ISO8859-1.out. Stop *** Error code 2 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-29 02:23:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-29 02:23:12 - ERROR: failed to build world TB --- 2008-07-29 02:23:12 - tinderbox aborted TB --- 2589.16 user 331.05 system 3614.26 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Tue Jul 29 03:03:32 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jul 29 03:03:38 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080729030329.A040473039@freebsd-current.sentex.ca> TB --- 2008-07-29 02:10:44 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-29 02:10:44 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-29 02:10:44 - cleaning the object tree TB --- 2008-07-29 02:11:09 - cvsupping the source tree TB --- 2008-07-29 02:11:10 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-29 02:11:18 - building world (CFLAGS=-O -pipe) TB --- 2008-07-29 02:11:18 - cd /src TB --- 2008-07-29 02:11:18 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 29 02: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 [...] grep -v '^#' < /src/share/timedef/lt_LT.ISO8859-4.src > lt_LT.ISO8859-4.out grep -v '^#' < /src/share/timedef/lt_LT.ISO8859-13.src > lt_LT.ISO8859-13.out grep -v '^#' < /src/share/timedef/lt_LT.UTF-8.src > lt_LT.UTF-8.out grep -v '^#' < /src/share/timedef/mn_MN.UTF-8.src > mn_MN.UTF-8.out grep -v '^#' < /src/share/timedef/nl_NL.ISO8859-1.src > nl_NL.ISO8859-1.out grep -v '^#' < /src/share/timedef/nn_NO.ISO8859-1.src > nn_NO.ISO8859-1.out grep -v '^#' < /src/share/timedef/nn_NO.UTF-8.src > nn_NO.UTF-8.out make: don't know how to make no_NO.ISO8859-1.out. Stop *** Error code 2 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-29 03:03:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-29 03:03:29 - ERROR: failed to build world TB --- 2008-07-29 03:03:29 - tinderbox aborted TB --- 2559.96 user 324.86 system 3164.95 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Tue Jul 29 07:15:56 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jul 29 07:16:08 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080729071552.20C8B73039@freebsd-current.sentex.ca> TB --- 2008-07-29 06:14:36 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-29 06:14:36 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-07-29 06:14:36 - cleaning the object tree TB --- 2008-07-29 06:14:51 - cvsupping the source tree TB --- 2008-07-29 06:14:51 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-07-29 06:14:57 - building world (CFLAGS=-O -pipe) TB --- 2008-07-29 06:14:57 - cd /src TB --- 2008-07-29 06:14:57 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 29 06:14:59 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 [...] grep -v '^#' < /src/share/timedef/lt_LT.ISO8859-4.src > lt_LT.ISO8859-4.out grep -v '^#' < /src/share/timedef/lt_LT.ISO8859-13.src > lt_LT.ISO8859-13.out grep -v '^#' < /src/share/timedef/lt_LT.UTF-8.src > lt_LT.UTF-8.out grep -v '^#' < /src/share/timedef/mn_MN.UTF-8.src > mn_MN.UTF-8.out grep -v '^#' < /src/share/timedef/nl_NL.ISO8859-1.src > nl_NL.ISO8859-1.out grep -v '^#' < /src/share/timedef/nn_NO.ISO8859-1.src > nn_NO.ISO8859-1.out grep -v '^#' < /src/share/timedef/nn_NO.UTF-8.src > nn_NO.UTF-8.out make: don't know how to make no_NO.ISO8859-1.out. Stop *** Error code 2 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-29 07:15:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-29 07:15:52 - ERROR: failed to build world TB --- 2008-07-29 07:15:52 - tinderbox aborted TB --- 2594.97 user 331.21 system 3675.37 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Tue Jul 29 07:16:37 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jul 29 07:16:55 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080729071635.75EBB73039@freebsd-current.sentex.ca> TB --- 2008-07-29 06:16:53 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-29 06:16:53 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-29 06:16:53 - cleaning the object tree TB --- 2008-07-29 06:17:10 - cvsupping the source tree TB --- 2008-07-29 06:17:10 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-29 06:17:18 - building world (CFLAGS=-O -pipe) TB --- 2008-07-29 06:17:18 - cd /src TB --- 2008-07-29 06:17:18 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 29 06:17: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 [...] grep -v '^#' < /src/share/timedef/lt_LT.ISO8859-4.src > lt_LT.ISO8859-4.out grep -v '^#' < /src/share/timedef/lt_LT.ISO8859-13.src > lt_LT.ISO8859-13.out grep -v '^#' < /src/share/timedef/lt_LT.UTF-8.src > lt_LT.UTF-8.out grep -v '^#' < /src/share/timedef/mn_MN.UTF-8.src > mn_MN.UTF-8.out grep -v '^#' < /src/share/timedef/nl_NL.ISO8859-1.src > nl_NL.ISO8859-1.out grep -v '^#' < /src/share/timedef/nn_NO.ISO8859-1.src > nn_NO.ISO8859-1.out grep -v '^#' < /src/share/timedef/nn_NO.UTF-8.src > nn_NO.UTF-8.out make: don't know how to make no_NO.ISO8859-1.out. Stop *** Error code 2 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-29 07:16:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-29 07:16:35 - ERROR: failed to build world TB --- 2008-07-29 07:16:35 - tinderbox aborted TB --- 2591.80 user 333.31 system 3582.05 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Tue Jul 29 09:38:30 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jul 29 09:38:43 2008 Subject: [releng_7 tinderbox] failure on sparc64/sparc64 Message-ID: <20080729093828.83B551B5078@freebsd-stable.sentex.ca> TB --- 2008-07-29 09:37:14 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-07-29 09:37:14 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2008-07-29 09:37:14 - cleaning the object tree TB --- 2008-07-29 09:37:32 - cvsupping the source tree TB --- 2008-07-29 09:37:32 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2008-07-29 09:37:41 - building world (CFLAGS=-O2 -pipe) TB --- 2008-07-29 09:37:41 - cd /src TB --- 2008-07-29 09:37:41 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 29 09:37:43 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 [...] rm -f termcap termcap.db termcap.5.gz termcap.5.cat.gz ===> share/timedef (cleandir) rm -f am_ET.UTF-8.out be_BY.CP1131.out be_BY.CP1251.out be_BY.ISO8859-5.out be_BY.UTF-8.out bg_BG.CP1251.out bg_BG.UTF-8.out ca_ES.ISO8859-1.out ca_ES.UTF-8.out cs_CZ.ISO8859-2.out cs_CZ.UTF-8.out da_DK.ISO8859-1.out da_DK.UTF-8.out de_AT.ISO8859-1.out de_AT.UTF-8.out de_DE.ISO8859-1.out de_DE.UTF-8.out el_GR.ISO8859-7.out el_GR.UTF-8.out en_GB.ISO8859-1.out en_US.ISO8859-1.out es_ES.ISO8859-1.out es_ES.UTF-8.out et_EE.ISO8859-15.out et_EE.UTF-8.out eu_ES.ISO8859-1.out fi_FI.ISO8859-1.out fi_FI.UTF-8.out fr_FR.ISO8859-1.out fr_FR.UTF-8.out he_IL.UTF-8.out hi_IN.ISCII-DEV.out hr_HR.ISO8859-2.out hr_HR.UTF-8.out hu_HU.ISO8859-2.out hu_HU.UTF-8.out hy_AM.ARMSCII-8.out hy_AM.UTF-8.out is_IS.ISO8859-1.out is_IS.UTF-8.out ja_JP.eucJP.out ja_JP.SJIS.out ja_JP.UTF-8.out it_IT.ISO8859-1.out it_IT.UTF-8.out kk_KZ.PT154.out kk_KZ.UTF-8.out ko_KR.eucKR.out ko_KR.UTF-8.out la_LN.ISO8859-1.out lt_LT.ISO8859-4.out lt_LT.ISO8859-13.out lt_LT.UTF-8.out mn_MN.UTF-8.out nl_NL.ISO8859-1.out nn_N O.ISO8859-1.out nn_NO.UTF-8.out no_NO.ISO8859-1.out no_NO.UTF-8.out pl_PL.ISO8859-2.out pl_PL.UTF-8.out pt_BR.ISO8859-1.out pt_BR.UTF-8.out pt_PT.ISO8859-1.out pt_PT.UTF-8.out ro_RO.ISO8859-2.out ro_RO.UTF-8.out ru_RU.CP1251.out ru_RU.CP866.out ru_RU.ISO8859-5.out ru_RU.KOI8-R.out ru_RU.UTF-8.out sk_SK.ISO8859-2.out sk_SK.UTF-8.out sl_SI.ISO8859-2.out sl_SI.UTF-8.out sr_YU.ISO8859-2.out sr_YU.ISO8859-5.out sr_YU.UTF-8.out sv_SE.ISO8859-1.out sv_SE.UTF-8.out tr_TR.ISO8859-9.out tr_TR.UTF-8.out uk_UA.CP1251.out uk_UA.ISO8859-5.out uk_UA.KOI8-U.out uk_UA.UTF-8.out zh_CN.eucCN.out zh_CN.GB18030.out zh_CN.GB2312.out zh_CN.UTF-8.out zh_TW.Big5.out zh_TW.UTF-8.out ===> share/zoneinfo (cleandir) rm -f yearistype ===> sys (cleandir) "Makefile", line 15: Unassociated shell command "sys ufs vm xdr ${ARCHDIR}" make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-29 09:38:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-29 09:38:28 - ERROR: failed to build world TB --- 2008-07-29 09:38:28 - tinderbox aborted TB --- 22.80 user 9.47 system 74.10 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full From tinderbox at freebsd.org Tue Jul 29 11:30:15 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jul 29 11:30:24 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080729113011.D6FAA73039@freebsd-current.sentex.ca> TB --- 2008-07-29 10:30:04 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-29 10:30:04 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-07-29 10:30:04 - cleaning the object tree TB --- 2008-07-29 10:30:20 - cvsupping the source tree TB --- 2008-07-29 10:30:20 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-07-29 10:30:26 - building world (CFLAGS=-O -pipe) TB --- 2008-07-29 10:30:26 - cd /src TB --- 2008-07-29 10:30:26 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 29 10:30:28 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 [...] grep -v '^#' < /src/share/timedef/lt_LT.ISO8859-4.src > lt_LT.ISO8859-4.out grep -v '^#' < /src/share/timedef/lt_LT.ISO8859-13.src > lt_LT.ISO8859-13.out grep -v '^#' < /src/share/timedef/lt_LT.UTF-8.src > lt_LT.UTF-8.out grep -v '^#' < /src/share/timedef/mn_MN.UTF-8.src > mn_MN.UTF-8.out grep -v '^#' < /src/share/timedef/nl_NL.ISO8859-1.src > nl_NL.ISO8859-1.out grep -v '^#' < /src/share/timedef/nn_NO.ISO8859-1.src > nn_NO.ISO8859-1.out grep -v '^#' < /src/share/timedef/nn_NO.UTF-8.src > nn_NO.UTF-8.out make: don't know how to make no_NO.ISO8859-1.out. Stop *** Error code 2 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-29 11:30:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-29 11:30:11 - ERROR: failed to build world TB --- 2008-07-29 11:30:11 - tinderbox aborted TB --- 2588.55 user 332.38 system 3606.74 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Tue Jul 29 11:31:08 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jul 29 11:31:14 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080729113105.DDC3673039@freebsd-current.sentex.ca> TB --- 2008-07-29 10:32:18 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-29 10:32:18 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-29 10:32:18 - cleaning the object tree TB --- 2008-07-29 10:32:32 - cvsupping the source tree TB --- 2008-07-29 10:32:32 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-29 10:32:39 - building world (CFLAGS=-O -pipe) TB --- 2008-07-29 10:32:39 - cd /src TB --- 2008-07-29 10:32:39 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 29 10:32:40 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 [...] grep -v '^#' < /src/share/timedef/lt_LT.ISO8859-4.src > lt_LT.ISO8859-4.out grep -v '^#' < /src/share/timedef/lt_LT.ISO8859-13.src > lt_LT.ISO8859-13.out grep -v '^#' < /src/share/timedef/lt_LT.UTF-8.src > lt_LT.UTF-8.out grep -v '^#' < /src/share/timedef/mn_MN.UTF-8.src > mn_MN.UTF-8.out grep -v '^#' < /src/share/timedef/nl_NL.ISO8859-1.src > nl_NL.ISO8859-1.out grep -v '^#' < /src/share/timedef/nn_NO.ISO8859-1.src > nn_NO.ISO8859-1.out grep -v '^#' < /src/share/timedef/nn_NO.UTF-8.src > nn_NO.UTF-8.out make: don't know how to make no_NO.ISO8859-1.out. Stop *** Error code 2 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-29 11:31:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-29 11:31:05 - ERROR: failed to build world TB --- 2008-07-29 11:31:05 - tinderbox aborted TB --- 2589.10 user 330.66 system 3527.55 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Tue Jul 29 15:45:23 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jul 29 15:45:34 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080729154517.5BFFA73039@freebsd-current.sentex.ca> TB --- 2008-07-29 14:45:08 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-29 14:45:08 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-07-29 14:45:08 - cleaning the object tree TB --- 2008-07-29 14:45:24 - cvsupping the source tree TB --- 2008-07-29 14:45:24 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-07-29 14:45:30 - building world (CFLAGS=-O -pipe) TB --- 2008-07-29 14:45:30 - cd /src TB --- 2008-07-29 14:45:30 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 29 14:45:32 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/bluetooth/btsockstat (all) cc -O -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/bluetooth/btsockstat/btsockstat.c cc1: warnings being treated as errors In file included from /obj/sparc64/src/tmp/usr/include/sys/socketvar.h:42, from /src/usr.bin/bluetooth/btsockstat/btsockstat.c:37: /obj/sparc64/src/tmp/usr/include/sys/sockbuf.h:128: warning: 'struct thread' declared inside parameter list /obj/sparc64/src/tmp/usr/include/sys/sockbuf.h:128: warning: its scope is only this definition or declaration, which is probably not what you want /obj/sparc64/src/tmp/usr/include/sys/sockbuf.h:130: warning: 'struct thread' declared inside parameter list *** Error code 1 Stop in /src/usr.bin/bluetooth/btsockstat. *** Error code 1 Stop in /src/usr.bin/bluetooth. *** 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-07-29 15:45:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-29 15:45:17 - ERROR: failed to build world TB --- 2008-07-29 15:45:17 - tinderbox aborted TB --- 2599.98 user 331.05 system 3608.66 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Tue Jul 29 15:46:05 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jul 29 15:46:35 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080729154603.0EC8173039@freebsd-current.sentex.ca> TB --- 2008-07-29 14:47:16 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-29 14:47:16 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-29 14:47:16 - cleaning the object tree TB --- 2008-07-29 14:47:33 - cvsupping the source tree TB --- 2008-07-29 14:47:33 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-29 14:47:39 - building world (CFLAGS=-O -pipe) TB --- 2008-07-29 14:47:39 - cd /src TB --- 2008-07-29 14:47:39 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 29 14:47:40 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/bluetooth/btsockstat (all) cc -O -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/bluetooth/btsockstat/btsockstat.c cc1: warnings being treated as errors In file included from /obj/sun4v/src/tmp/usr/include/sys/socketvar.h:42, from /src/usr.bin/bluetooth/btsockstat/btsockstat.c:37: /obj/sun4v/src/tmp/usr/include/sys/sockbuf.h:128: warning: 'struct thread' declared inside parameter list /obj/sun4v/src/tmp/usr/include/sys/sockbuf.h:128: warning: its scope is only this definition or declaration, which is probably not what you want /obj/sun4v/src/tmp/usr/include/sys/sockbuf.h:130: warning: 'struct thread' declared inside parameter list *** Error code 1 Stop in /src/usr.bin/bluetooth/btsockstat. *** Error code 1 Stop in /src/usr.bin/bluetooth. *** 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-07-29 15:46:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-29 15:46:03 - ERROR: failed to build world TB --- 2008-07-29 15:46:03 - tinderbox aborted TB --- 2598.66 user 330.60 system 3527.02 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Tue Jul 29 20:03:40 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jul 29 20:03:47 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080729200337.69AEE73039@freebsd-current.sentex.ca> TB --- 2008-07-29 19:02:16 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-29 19:02:16 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-07-29 19:02:16 - cleaning the object tree TB --- 2008-07-29 19:02:35 - cvsupping the source tree TB --- 2008-07-29 19:02:35 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-07-29 19:02:41 - building world (CFLAGS=-O -pipe) TB --- 2008-07-29 19:02:41 - cd /src TB --- 2008-07-29 19:02:41 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 29 19:02:43 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 [...] cc1: warnings being treated as errors In file included from /obj/sparc64/src/tmp/usr/include/sys/socketvar.h:42, from /src/usr.bin/netstat/inet.c:47: /obj/sparc64/src/tmp/usr/include/sys/sockbuf.h:128: warning: 'struct thread' declared inside parameter list /obj/sparc64/src/tmp/usr/include/sys/sockbuf.h:128: warning: its scope is only this definition or declaration, which is probably not what you want /obj/sparc64/src/tmp/usr/include/sys/sockbuf.h:130: warning: 'struct thread' declared inside parameter list /src/usr.bin/netstat/inet.c:141: error: static declaration of 'sbtoxsockbuf' follows non-static declaration /obj/sparc64/src/tmp/usr/include/sys/sockbuf.h:133: error: previous declaration of 'sbtoxsockbuf' was here *** Error code 1 Stop in /src/usr.bin/netstat. *** 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-07-29 20:03:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-29 20:03:37 - ERROR: failed to build world TB --- 2008-07-29 20:03:37 - tinderbox aborted TB --- 2654.20 user 337.00 system 3680.48 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Tue Jul 29 20:04:29 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Jul 29 20:04:36 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080729200427.6E08C73039@freebsd-current.sentex.ca> TB --- 2008-07-29 19:03:57 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-29 19:03:57 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-29 19:03:57 - cleaning the object tree TB --- 2008-07-29 19:04:16 - cvsupping the source tree TB --- 2008-07-29 19:04:16 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-29 19:04:22 - building world (CFLAGS=-O -pipe) TB --- 2008-07-29 19:04:22 - cd /src TB --- 2008-07-29 19:04:22 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 29 19:04: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 [...] cc1: warnings being treated as errors In file included from /obj/sun4v/src/tmp/usr/include/sys/socketvar.h:42, from /src/usr.bin/netstat/inet.c:47: /obj/sun4v/src/tmp/usr/include/sys/sockbuf.h:128: warning: 'struct thread' declared inside parameter list /obj/sun4v/src/tmp/usr/include/sys/sockbuf.h:128: warning: its scope is only this definition or declaration, which is probably not what you want /obj/sun4v/src/tmp/usr/include/sys/sockbuf.h:130: warning: 'struct thread' declared inside parameter list /src/usr.bin/netstat/inet.c:141: error: static declaration of 'sbtoxsockbuf' follows non-static declaration /obj/sun4v/src/tmp/usr/include/sys/sockbuf.h:133: error: previous declaration of 'sbtoxsockbuf' was here *** Error code 1 Stop in /src/usr.bin/netstat. *** 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-07-29 20:04:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-29 20:04:27 - ERROR: failed to build world TB --- 2008-07-29 20:04:27 - tinderbox aborted TB --- 2655.30 user 336.02 system 3629.70 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Wed Jul 30 00:26:37 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Jul 30 00:26:55 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080730002633.DD6AA73039@freebsd-current.sentex.ca> TB --- 2008-07-29 23:19:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-29 23:19:32 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-07-29 23:19:32 - cleaning the object tree TB --- 2008-07-29 23:19:51 - cvsupping the source tree TB --- 2008-07-29 23:19:51 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-07-29 23:19:57 - building world (CFLAGS=-O -pipe) TB --- 2008-07-29 23:19:57 - cd /src TB --- 2008-07-29 23:19:57 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 29 23:19:58 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 Wed Jul 30 00:26:32 UTC 2008 TB --- 2008-07-30 00:26:32 - generating LINT kernel config TB --- 2008-07-30 00:26:32 - cd /src/sys/sparc64/conf TB --- 2008-07-30 00:26:32 - /usr/bin/make -B LINT TB --- 2008-07-30 00:26:33 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-30 00:26:33 - cd /src TB --- 2008-07-30 00:26:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 30 00:26:33 UTC 2008 >>> stage 1: configuring the kernel [...] WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: duplicate option `SUNKBD_EMULATE_ATKBD' encountered. WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated emu10kx headers WARNING: kernel contains GPL contaminated ReiserFS filesystem WARNING: kernel contains GPL contaminated xfs filesystem *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-30 00:26:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-30 00:26:33 - ERROR: failed to build lint kernel TB --- 2008-07-30 00:26:33 - tinderbox aborted TB --- 2919.93 user 358.45 system 4020.77 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Wed Jul 30 00:27:22 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Jul 30 00:27:39 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080730002719.2714073039@freebsd-current.sentex.ca> TB --- 2008-07-29 23:21:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-29 23:21:21 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-29 23:21:21 - cleaning the object tree TB --- 2008-07-29 23:21:38 - cvsupping the source tree TB --- 2008-07-29 23:21:38 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-29 23:21:43 - building world (CFLAGS=-O -pipe) TB --- 2008-07-29 23:21:43 - cd /src TB --- 2008-07-29 23:21:43 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 29 23:21: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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 30 00:27:18 UTC 2008 TB --- 2008-07-30 00:27:18 - generating LINT kernel config TB --- 2008-07-30 00:27:18 - cd /src/sys/sun4v/conf TB --- 2008-07-30 00:27:18 - /usr/bin/make -B LINT TB --- 2008-07-30 00:27:18 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-30 00:27:18 - cd /src TB --- 2008-07-30 00:27:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 30 00:27:18 UTC 2008 >>> stage 1: configuring the kernel [...] config: Error: device "nfe" is unknown config: 1 errors WARNING: duplicate option `GEOM_BSD' encountered. WARNING: duplicate option `GEOM_SUNLABEL' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: kernel contains GPL contaminated ReiserFS filesystem WARNING: kernel contains GPL contaminated xfs filesystem *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-30 00:27:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-30 00:27:19 - ERROR: failed to build lint kernel TB --- 2008-07-30 00:27:19 - tinderbox aborted TB --- 2916.84 user 358.23 system 3957.52 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Wed Jul 30 21:33:13 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Jul 30 21:33:26 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080730213309.00D7E73039@freebsd-current.sentex.ca> TB --- 2008-07-30 20:19:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-30 20:19:45 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-30 20:19:45 - cleaning the object tree TB --- 2008-07-30 20:20:09 - cvsupping the source tree TB --- 2008-07-30 20:20:09 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-30 20:20:16 - building world (CFLAGS=-O -pipe) TB --- 2008-07-30 20:20:16 - cd /src TB --- 2008-07-30 20:20:16 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 30 20:20:18 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 Wed Jul 30 21:25:25 UTC 2008 TB --- 2008-07-30 21:25:25 - generating LINT kernel config TB --- 2008-07-30 21:25:25 - cd /src/sys/sun4v/conf TB --- 2008-07-30 21:25:25 - /usr/bin/make -B LINT TB --- 2008-07-30 21:25:25 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-30 21:25:25 - cd /src TB --- 2008-07-30 21:25:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 30 21:25: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 [...] awk -f /src/sys/modules/cxgb/toecore/../../../conf/kmod_syms.awk toecore.kld export_syms | xargs -J% objcopy % toecore.kld ld -Bshareable -d -warn-common -o toecore.ko toecore.kld objcopy --strip-debug toecore.ko ===> cxgb/tom (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -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/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c In file included from /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:48: @/sys/sockbuf.h:77: error: field 'sb_sel' has incomplete type @/sys/sockbuf.h:79: error: field 'sb_sx' has incomplete type *** Error code 1 Stop in /src/sys/modules/cxgb/tom. *** Error code 1 Stop in /src/sys/modules/cxgb. *** 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-07-30 21:33:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-30 21:33:08 - ERROR: failed to build lint kernel TB --- 2008-07-30 21:33:08 - tinderbox aborted TB --- 3282.02 user 404.15 system 4403.02 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Thu Jul 31 02:32:23 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jul 31 02:32:40 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20080731023220.755A373039@freebsd-current.sentex.ca> TB --- 2008-07-31 01:16:55 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-31 01:16:55 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-07-31 01:16:55 - cleaning the object tree TB --- 2008-07-31 01:17:29 - cvsupping the source tree TB --- 2008-07-31 01:17:29 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-07-31 01:17:39 - building world (CFLAGS=-O -pipe) TB --- 2008-07-31 01:17:39 - cd /src TB --- 2008-07-31 01:17:39 - /usr/bin/make -B buildworld >>> World build started on Thu Jul 31 01:17:41 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 Jul 31 02:24:11 UTC 2008 TB --- 2008-07-31 02:24:11 - generating LINT kernel config TB --- 2008-07-31 02:24:11 - cd /src/sys/sparc64/conf TB --- 2008-07-31 02:24:11 - /usr/bin/make -B LINT TB --- 2008-07-31 02:24:11 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-31 02:24:11 - cd /src TB --- 2008-07-31 02:24:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 31 02:24:12 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 [...] ng_btsocket.o(.data+0x348): undefined reference to `ng_btsocket_sco_disconnect' ng_btsocket.o(.data+0x350): undefined reference to `ng_btsocket_sco_listen' ng_btsocket.o(.data+0x358): undefined reference to `ng_btsocket_sco_peeraddr' ng_btsocket.o(.data+0x370): undefined reference to `ng_btsocket_sco_send' ng_btsocket.o(.data+0x390): undefined reference to `ng_btsocket_sco_sockaddr' ng_btsocket.o(.data+0x3b8): undefined reference to `ng_btsocket_sco_close' ng_btsocket.o(.data+0x590): undefined reference to `ng_btsocket_sco_ctloutput' ng_btsocket.o(.data+0x5a0): undefined reference to `ng_btsocket_sco_init' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-31 02:32:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-31 02:32:20 - ERROR: failed to build lint kernel TB --- 2008-07-31 02:32:20 - tinderbox aborted TB --- 3245.93 user 408.72 system 4525.09 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Thu Jul 31 03:03:57 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jul 31 03:04:04 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20080731030354.BFA2873039@freebsd-current.sentex.ca> TB --- 2008-07-31 01:55:13 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-31 01:55:13 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-31 01:55:13 - cleaning the object tree TB --- 2008-07-31 01:55:35 - cvsupping the source tree TB --- 2008-07-31 01:55:35 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-31 01:55:43 - building world (CFLAGS=-O -pipe) TB --- 2008-07-31 01:55:43 - cd /src TB --- 2008-07-31 01:55:43 - /usr/bin/make -B buildworld >>> World build started on Thu Jul 31 01:55: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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jul 31 02:57:15 UTC 2008 TB --- 2008-07-31 02:57:15 - generating LINT kernel config TB --- 2008-07-31 02:57:15 - cd /src/sys/sun4v/conf TB --- 2008-07-31 02:57:15 - /usr/bin/make -B LINT TB --- 2008-07-31 02:57:15 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-31 02:57:15 - cd /src TB --- 2008-07-31 02:57:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 31 02:57:15 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 [...] ng_btsocket.o(.data+0x348): undefined reference to `ng_btsocket_sco_disconnect' ng_btsocket.o(.data+0x350): undefined reference to `ng_btsocket_sco_listen' ng_btsocket.o(.data+0x358): undefined reference to `ng_btsocket_sco_peeraddr' ng_btsocket.o(.data+0x370): undefined reference to `ng_btsocket_sco_send' ng_btsocket.o(.data+0x390): undefined reference to `ng_btsocket_sco_sockaddr' ng_btsocket.o(.data+0x3b8): undefined reference to `ng_btsocket_sco_close' ng_btsocket.o(.data+0x590): undefined reference to `ng_btsocket_sco_ctloutput' ng_btsocket.o(.data+0x5a0): undefined reference to `ng_btsocket_sco_init' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-31 03:03:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-31 03:03:54 - ERROR: failed to build lint kernel TB --- 2008-07-31 03:03:54 - tinderbox aborted TB --- 3205.67 user 402.66 system 4121.23 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full