From info at videobrokers.com Mon Feb 2 04:40:59 2009 From: info at videobrokers.com (Video Brokers) Date: Mon Feb 2 04:41:07 2009 Subject: Second hand video equipment for sale. Message-ID: [1]WWW.VIDEOBROKERS.COM WE BUY & SALE USED VIDEO/BROADCAST EQUIPMENTS! Hello, Please find bellow some details regarding the equipment we have for sale at the moment. Do not hesitate to get in touch with us if what you are looking for is not listed here, let us know as well what you have for sale. VISION MIXER's : Sony DVS2000, 10 SDI inputs @ 5.000 Euros Sony DVS2000, 16 SDI inputs @ 7.000 Euros Abekas A8150, SDI @ 3.000 Euros BTS DD20, specs on request @ 8.000 Euros BTS DD30, specs on request @ 10.000 Euros BTS DD35, specs on request @ 14.000 Euros GVG 1200, SDI @ 5.000 Euros GVG 4000, specs on request @ 4.000 Euros GVG Kayak DD1, full options @21.000 Euros GVG Kayak HD200 & HD300, specs on request @ contact us for a quote Sony DVS7250 & 7350, specs on request @ contact us for a quote VTR's : Panasonic AJ-D230H, 200 original drum hours @ 1.100 Euros Panasonic AJ-D650E, 2400 original drum hours @ 1.000 Euros Panasonic AJ-D650E, with SDI, new drum "0hrs" @ 2.500 Euros Panasonic AJ-D950E, 2500 original drum hours @ 6.000 Euros Panasonic AJ-D960E, 1000 drum hours @ 7.000 Euros Panasonic AJLT-75E, 1500 original drum hours @5.500 Euros Panasonic AJLT95, new drum "0hrs" @ 9.000 Euros Panasonic AJHD1200E, 1200 original drum hours @ 9.000 Euros Panasonic AJHD1400E, 280 original drum hours @ 16.500 Euros Sony UVW1200P, details on request @ from 400 Euros Sony UVW1600P, details on request @ from 700 Euros Sony UVW1800P, details on request @ from 1.000 Euros Sony PVW2600P, details on request @ from 800 Euros Sony PVW2650P, new drum "0hrs" @ 1.500 Euros Sony PVW2800P, serviced @ 2.000 Euros Sony BVW60P, details on request @ from 400 Euros Sony BVW65P, details on request @ from 400 Euros Sony BVW70P, details on request @ from 2.000 Euros Sony BVW70P with SDI, 800 drum hours @ 2.800 Euros Sony BVW75P, details on request @ from 2.000 Euros Sony BVWD75P, 310 drum hours @ 2.800 Euros Sony DSR1P, 59 original drum hours @ 1.900 Euros Sony DSR40P, 680 original drum hours @ 1.900 Euros Sony DSR45P, 800 original drum hours @ 2.500 Euros Sony DSR60P, 900 drum hours @ 600 Euros Sony DSR80P, with SDI, 2600 original drum hours @ 2.200 Euros Sony DSR85P, with SDI, new drum "0hrs" @ 3.500 Euros Sony DSR1500AP, with fire wire and YUV, 680 original drum hours @ 3.500 Euros Sony DSR1500AP, with SDI& fire wire, 400 original drum hours @ 4.000 Euros Sony DSR2000P, 2600 original drum hours @ 5.500 Euros Sony DSR2000P, new drum "hrs" @ 7.000 Euros Sony DNWA30P, 2000 original drum hours @ 1.500 Euros Sony DNWA65P, 3000 drum hours @ 1.800 Euros Sony DNWA75P, 3500 original drum hours @ 4.500 Euros Sony DNWA220P, 2500 drum hours @ 4.000 Euros Sony DNWA225P, 2200 drum hours @ 7.000 Euros Sony J1, betacam SP and SX player, low hours @ 1.200 Euros Sony J3A, 1200 original drum hours @ 3.900 Euros Sony DVW522P, low original drum hours @ 2.500 Euros Sony DVW510P S/N 11198, 3278 drum hours @ 4.500 Euros Sony DVWA510P, 2500 drum hours @ 6.000 Euros Sony DVW500P S/N 16243, 3587 drum hours @ 15.000 Euros Sony DVWA500P S/N 10520, fully serviced, new drum "0hrs" @ 19.000 Euros Sony DVWM2000P, 300 original drum hours @ 23.000 Euros Sony JH3, 150 original drum hours, with fire wire @ 13.000 Euros Sony HDWM2000P S/N 49298, EX-DEMO, 390 original drum hours @ 33.000 Euros Sony HDWM2000P, NEW IN THE BOX @ 36.000 Euros CAMERA's & CAMCORDER's : Sony HDC1500, complete camera chain, specs on request, 16 units available @ 50.000 Euros/ unit Thomson LDK8000, complete camera chain, specs on request, 6 units available @ make an offer Sony DXCD30P, camera head @ 1.600 Euros Sony DXCD35P, camera head @ 2.000 Euros Thomson TTV1657D (4/3-16:9) complete triax chain @ 16.000 Euros Thomson LDK23HS MKII complete chain @ 38.000 Euros Panasonic AJD800P, 1400 drum hours @ 1.600 Euros Panasonic AJD610WAE, 700 drum hours @ 3.600 Euros Panasonic AJ-SDC615E, 1300 original drum hours @ 4.500 Euros Panasonic AJD910WAE, low hours @ 5.000 Euros Panasonic AGHVX200, ex-demo, 0hrs @ 3.300 Euros Panasonic AJSDX900, with AJ-VF20WE, 2550 original drum hours @ 7.000 Euros Panasonic AJHDX900, with AJ-HVF21, 1150 original drum hours @13.000 Euros Panasonic HPX-2100E, ex-demo, 4 years warranty, with view finder and microphone @ 18.700 Euros Panasonic AJ-HDC27 (varicam), 800 original drum hours @ 15.000 Euros Sony BVWD600P S/N 40358, 233 drum hours @ 2.000 Euros Sony HVR-Z1E, around 700 original drum hours @ 2.000 Euros Sony HVR-Z5E, NEW @ 3.740 Euros Sony HVR-Z7E, NEW @ 4.680 Euros Sony PMW-EX3, NEW @ 6.870 Euros Sony PMW-700, NEW @ 21.840 Euros Sony DSRPD150P, battery charger @ 1.200 Euros Sony DSRPD170P, battery charger, wide angle converter @ 1.600 Euros Sony DSR370P S/N 42129, 383 original drum hours, including Canon YH19x6.7KRS @ 3.500 Euros Sony DSR400P S/N 43512, 50 original drum hours @ 4.000 Euros Sony DSR500WSP S/N 42925, 800 original drum hours @ 3.000 Euros Sony DSR570WSP S/N 46925, 1200 original drum hours @ 4.500 Euros Sony DSR450WSP S/N 42790, 550 original drum hours @ 7.500 Euros Sony DVW700P, details on request @ from 2.000 Euros Sony DVW707P, details on request @ from 2.500 Euros Sony DNW7P, details on request @ from 2.000 Euros Sony DNW9WSP, details on request @ from 4.000 Euros Sony DNW90WSP, details on request @ from 6.000 Euros Sony DVW709WSP S/N 40090, 1317 original drum hours @ 9.000 Euros Sony DVW709WSP S/N 40011, 399 original drum hours @ 10.000 Euros Sony DVW790WS S/N 40330, 55 drum hours @ 13.500 Euros Sony DVW790WSP S/N 41929, 516 drum hours @ 15.000 Euros Sony DVW790WSP S/N 42199, 601 original drum hours @ 17.000 Euros Sony PDW530P S/N 40538, 40 original lazer hours @ 14.000 Euros Sony PDW530P S/N 60394, 18 original lazer hours @ 15.000 Euros Sony HDW730S S/N 10192, 551 original drum hours, like new ! @ 16.000 Euros Sony HDW750P S/N 40113, 1513 original drum hours, with down converter @ 17.000 Euros Sony HDW750P S/N 40112, 1521 original drum hours, with down converter @ 17.000 Euros Sony HDW790P, 70 original drum hours @ 23.000 Euros Sony HDWF900/3 S/N 12474, 1519 original drum hours @ 20.000 Euros LENSES : Canon ZSD300 & FPD400, ex-demo @ 1.500 Euros Fujinon A16x9BERM @ 800 Euros Canon J15x8BIRS @ 1.500 Euros Fujinon A15x8BEVM @ 1.500 Euros Fujinon A8.5x5.5BEVM @ 3.000 Euros Canon YJ19x9KRS @ 1.000 Euros Canon YJ12x6.5IRS @ 3.000 Euros Canon J16x8BIRS @ 2.500 Euros Canon J8x6BKRS @ 1.800 Euros Canon J8x6BIRS @ 2.500 Euros Canon J9x5.2BIRS @ 5.000 Euros Canon J11x4.5BIRS @ 7.000 Euros Canon J22x7.6IAS @ 6.000 Euros Canon J33x15IRS with lens support + remotes @ 17.000 Euros Fujinon A10x4.8BEVM @ 6.000 Euros Fujinon A13x4.5BERD @ 8.000 Euros Fujinon HA13x4.5BERM, @ 12.000 Euros Fujinon HA13x4.5BERM, EX-DEMO @ 13.000 Euros Fujinon HA20x7.8BM10 @ 13.000 Euros Fujinon HA10x5BM10 @ 13.000 Euros Canon HJ11x4.7BIRSE, NEW @ 13.000 Euros Canon HJ21x7.8BIRSD @ 11.000 Euros Canon HJ22x7.6BIRSE, EX-DEMO @ 13.000 Euros Canon HJ22x7.6BIASE, NEW @ 14.000 Euros Fujinon HA42x , perfect condition @ contact us Canon J55super, with zoom and focus + lens support @ 19.000 Euros Canon PJ70 MK1 with zoom and focus + lens support @ 24.000 Euros Canon PJ70 MKII with zoom and focus + lens support @ 34.000 Euros Canon DIGI SUPER 86 XS with zoom and focus @ 78.000 Euros Fujinon HAe 10x10 M T1.8 @ 45.000 Euros Fujinon Super prime set @ 14.000 Euros, including : HAe F5-M10 T1.5 and HAe F8-M10 T1.5 and HAe F20-M10 T1.5 VARIOUS : Sony DME3000 @ 3.000 Euros Sony DME7000 @ 6.000 Euros Sony CA701 @ 2.000 Euros Sony RMM7G @ 700 Euros Sony CCUM5P @ 900 Euros Sony CCUM7P @ 1.000 Euros Sony CA537P @ 700 Euros Snell & Wilcox TBS24D @ 2.000 Euros Pinnacle DEKO 500 @ 3.000 Euros Pinnacle DEKO 2000 @ 9.000 Euros Sony DSC1024 @ 1.000 Euros Panasonic BTLH900E @ 2.350 Euros Panasonic BTLH1700E @ 1.480 Euros Sony BVF-VC10W @ 1.700 Euros Sony LMD 1420 @ 500 Euros Sony LMD 2020 @ 600 Euros Sony PVM9L2 @ 500 Euros Sony PVM20M2, ex-demo @ 600 Euros Sony PVM20M4 SDI @ 1.600 Euros Sony BVM2016P with SDI @ 1.500 Euros Sony BVM20G1E with SDI & BKM10R @ 4.000 Euros Sony BVMD20F1E with BKM11RR & BKM21D & BKM14L @ 6.000 Euros Sony BVM-F24E, HD/SDI, 4000 operation hours @ 19.000 Euros Sony RM450 @ 600 Euros Sony PVE500 @ 900 Euros Sony BVE9100 @ 1.500 Euros Sony BVE2000 @ 1.500 Euros Tektronix 1721/1731 @ 600 Euros Tektronix SPG110 @ 400 Euros Tektronix SPG271 @ 1.000 Euros Tektronix TSG111 @ 500 Euros Fora FA320, TBC @ 500 Euros Fora FA330, TBC @ 600 Euros Vinten Vision 10 @ 1.300 Euros Vinten Vision 11, carbon fiber @ 2.000 Euros Sachtler S18+ SBMLCF @ 3.900 Euros Tektronix WFM300 @ 800 Euros Tektronix WFM601A @ 2.500 Euros Tektronix WFM5000, ex-demo @ 4.250 Euros Sony DMXE2000 @ 1.500 Euros Sony DMXE3000 @ 2.500 Euros Sony PCM7030 @ 600 Euros Sony PCM7040 @ 1.200 Euros Yamaha 03D @ 800 Euros DK AUDIO PT5210, Vari Time Digital Sync Generator @ 2.000 Euros IDX video wireless system SDI, Model: WIVI @ 2.700 Euros AccuScene VF 1280S HD view finder with zebra Black & White, compatible for F23/F35/Genesis/RED @ 9.000 Euros FOUCUS FS-100, fire store HD multiformat DVCPRO HD, 100Go @ 400 Euros Snell & Wilcox IQ MODULAR with IQADBBG and 2x IQAVDA @ 2.000 Euros EVS XT2 6 channels SD, 5x 73GO, audio analo, AES, 2x PSU cool swap, open code, multicam LSM, super motion, FX split screen, network SDTI 1.5, protocol VDCP/DD35/ODETICS/LOUTH, protocol AVSP @ 72.000 Euros Video Brokers [2]www.videobrokers.com Alexandre Villegoureix Tel : +33 (0)6.09.84.13.86 Email : [3]alex@videobrokers.fr [4]If you wish not to receive anyfirther offer from us please follow this link References 1. http://url.videobrokers.com/id.asp?l=51090-4030682-388174-966-0 2. http://url.videobrokers.com/id.asp?l=51090-4030682-388174-966-0 3. mailto:alex@videobrokers.fr 4. http://url.videobrokers.com/id.asp?l=51089-4030682-388174-966-0&id=388174-966-4030682-fa98eab2&res=fr From tinderbox at freebsd.org Tue Feb 17 19:03:05 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Feb 17 19:03:11 2009 Subject: [head tinderbox] failure on mips/mips Message-ID: <20090218023328.227617302F@freebsd-current.sentex.ca> TB --- 2009-02-18 01:17:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-18 01:17:56 - starting HEAD tinderbox run for mips/mips TB --- 2009-02-18 01:17:56 - mkdir /tinderbox/HEAD/mips TB --- 2009-02-18 01:17:56 - mkdir /tinderbox/HEAD/mips/mips TB --- 2009-02-18 01:17:56 - cleaning the object tree TB --- 2009-02-18 01:17:56 - cvsupping the source tree TB --- 2009-02-18 01:17:56 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-02-18 01:32:55 - building world TB --- 2009-02-18 01:32:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-18 01:32:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-18 01:32:55 - TARGET=mips TB --- 2009-02-18 01:32:55 - TARGET_ARCH=mips TB --- 2009-02-18 01:32:55 - TZ=UTC TB --- 2009-02-18 01:32:55 - __MAKE_CONF=/dev/null TB --- 2009-02-18 01:32:55 - cd /src TB --- 2009-02-18 01:32:55 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 18 01:32:56 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -DNDEBUG -I/src/usr.sbin/bsnmpd/modules/snmp_hostres/../../../lpr/common_source -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c hostres_tree.c -o hostres_tree.So building shared library snmp_hostres.so.5 sed -e 's%@MODPATH@%/usr/lib/%g' -e 's%@DEFPATH@%/usr/share/snmp/defs/%g' -e 's%@MIBSPATH@%/usr/share/snmp/mibs/%g' < /src/usr.sbin/bsnmpd/modules/snmp_hostres/snmp_hostres.3 | gzip -cn > snmp_hostres.3.gz ===> usr.sbin/bsnmpd/modules/snmp_mibII (all) cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/lib -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmpd -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_SYS_TREE_H -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c -o mibII.So cc1: warnings being treated as errors /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c: In function 'handle_rtmsg': /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules/snmp_mibII. *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules. *** Error code 1 Stop in /src/usr.sbin/bsnmpd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-18 02:33:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-18 02:33:27 - ERROR: failed to build world TB --- 2009-02-18 02:33:27 - 2896.77 user 337.68 system 4531.49 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From imp at bsdimp.com Tue Feb 17 19:39:42 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Feb 17 19:39:49 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <20090218023328.227617302F@freebsd-current.sentex.ca> References: <20090218023328.227617302F@freebsd-current.sentex.ca> Message-ID: <20090217.203647.-1518647466.imp@bsdimp.com> In message: <20090218023328.227617302F@freebsd-current.sentex.ca> FreeBSD Tinderbox writes: : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type there's still 3 or 4 of these in the tree that I'm trying to track back to root cause. A simple (void *) fixes the problem, but I want to understand the issues before I slap that bad-boy in there... Warner From xcllnt at mac.com Tue Feb 17 21:06:09 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Feb 17 21:06:21 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <20090217.203647.-1518647466.imp@bsdimp.com> References: <20090218023328.227617302F@freebsd-current.sentex.ca> <20090217.203647.-1518647466.imp@bsdimp.com> Message-ID: <302F9BB0-AF38-422C-86DB-96FCF47C2168@mac.com> On Feb 17, 2009, at 7:36 PM, M. Warner Losh wrote: > In message: <20090218023328.227617302F@freebsd-current.sentex.ca> > FreeBSD Tinderbox writes: > : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/ > snmp_mibII/mibII.c:1016: warning: cast increases required alignment > of target type > > there's still 3 or 4 of these in the tree that I'm trying to track > back to root cause. A simple (void *) fixes the problem, but I want > to understand the issues before I slap that bad-boy in there... I think the warning simply means that you cast from pointer to type A with alignment requirement P to pointer to type B with alignment requirement Q, and with P < Q. This doesn't necessary mean there's a problem (i.e that you have a misaligned dereference), but there's a potential. A case by case analysis is called for... -- Marcel Moolenaar xcllnt@mac.com From imp at bsdimp.com Tue Feb 17 21:24:49 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Feb 17 21:25:04 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <20090217.203647.-1518647466.imp@bsdimp.com> References: <20090218023328.227617302F@freebsd-current.sentex.ca> <20090217.203647.-1518647466.imp@bsdimp.com> Message-ID: <20090217.222152.-109416210.imp@bsdimp.com> In message: <20090217.203647.-1518647466.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <20090218023328.227617302F@freebsd-current.sentex.ca> : FreeBSD Tinderbox writes: : : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type : : there's still 3 or 4 of these in the tree that I'm trying to track : back to root cause. A simple (void *) fixes the problem, but I want : to understand the issues before I slap that bad-boy in there... The first one is: case RTM_IFINFO: ifm = (struct if_msghdr *)rtm; mib_extract_addrs(ifm->ifm_addrs, (u_char *)(ifm + 1), addrs); if ((ifp = mib_find_if_sys(ifm->ifm_index)) == NULL) break; rtm is of type struct rt_msghdr. This has an alignment requirement of 4 on mips, at least on 32-bit mips (the biggest data element is a u_long). struct if_msghdr has an alignment requirement of 8, because time_t is int64_t on MIPS, which is 8-bytes in size. One way to fix this is to add __aligned(8) to struct rt_msghdr to compensate for this. Otherwise, if the time_t element is referenced in ifm_data we'll core dump. But that doesn't seem very portable and seems like a hack. Adding (void *) to "fix" the warning would be even worse... Anybody else have any ideas? Warner From xcllnt at mac.com Tue Feb 17 22:26:11 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Feb 17 22:26:23 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <20090217.222152.-109416210.imp@bsdimp.com> References: <20090218023328.227617302F@freebsd-current.sentex.ca> <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> Message-ID: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> On Feb 17, 2009, at 9:21 PM, M. Warner Losh wrote: > In message: <20090217.203647.-1518647466.imp@bsdimp.com> > "M. Warner Losh" writes: > : In message: <20090218023328.227617302F@freebsd-current.sentex.ca> > : FreeBSD Tinderbox writes: > : : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/ > bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required > alignment of target type > : > : there's still 3 or 4 of these in the tree that I'm trying to track > : back to root cause. A simple (void *) fixes the problem, but I want > : to understand the issues before I slap that bad-boy in there... > > The first one is: > > case RTM_IFINFO: > ifm = (struct if_msghdr *)rtm; > mib_extract_addrs(ifm->ifm_addrs, (u_char *)(ifm + 1), addrs); > if ((ifp = mib_find_if_sys(ifm->ifm_index)) == NULL) > break; > > rtm is of type struct rt_msghdr. This has an alignment requirement of > 4 on mips, at least on 32-bit mips (the biggest data element is a > u_long). struct if_msghdr has an alignment requirement of 8, because > time_t is int64_t on MIPS, which is 8-bytes in size. Normally on 32-bit architectures, 64-bit data types have a 32-bit alignment requirement by virtue of needing 2 32-bit loads/stores to read/write them. Does 32-bit MIPS use 64-bit wide registers? > One way to fix this is to add __aligned(8) to struct rt_msghdr to > compensate for this. Otherwise, if the time_t element is referenced > in ifm_data we'll core dump. A safer approach is to mark ifi_epoch as packed or put differently, define time_t as a 64-bit integral with 32-bit alignment. This can avoid a lot of unexpected internal padding as well (e.g. struct timeval). Just a thought. -- Marcel Moolenaar xcllnt@mac.com From imp at bsdimp.com Tue Feb 17 22:42:21 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Feb 17 22:42:39 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> References: <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> Message-ID: <20090217.234216.1276682135.imp@bsdimp.com> In message: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> Marcel Moolenaar writes: : : On Feb 17, 2009, at 9:21 PM, M. Warner Losh wrote: : : > In message: <20090217.203647.-1518647466.imp@bsdimp.com> : > "M. Warner Losh" writes: : > : In message: <20090218023328.227617302F@freebsd-current.sentex.ca> : > : FreeBSD Tinderbox writes: : > : : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/ : > bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required : > alignment of target type : > : : > : there's still 3 or 4 of these in the tree that I'm trying to track : > : back to root cause. A simple (void *) fixes the problem, but I want : > : to understand the issues before I slap that bad-boy in there... : > : > The first one is: : > : > case RTM_IFINFO: : > ifm = (struct if_msghdr *)rtm; : > mib_extract_addrs(ifm->ifm_addrs, (u_char *)(ifm + 1), addrs); : > if ((ifp = mib_find_if_sys(ifm->ifm_index)) == NULL) : > break; : > : > rtm is of type struct rt_msghdr. This has an alignment requirement of : > 4 on mips, at least on 32-bit mips (the biggest data element is a : > u_long). struct if_msghdr has an alignment requirement of 8, because : > time_t is int64_t on MIPS, which is 8-bytes in size. : : Normally on 32-bit architectures, 64-bit data types have a 32-bit : alignment requirement by virtue of needing 2 32-bit loads/stores : to read/write them. Does 32-bit MIPS use 64-bit wide registers? MIPS isn't normal :). MIPS really is a 64-bit architecture. The only way to make the warning go away would be to build -mmips32r2 or something like that. But since we're going to be supporting n32 ABI (which really is a 64-bit ABI despite its name) and n64, the issue won't be going away. This is desirable for the Octeon support that I hope to commit soon. : > One way to fix this is to add __aligned(8) to struct rt_msghdr to : > compensate for this. Otherwise, if the time_t element is referenced : > in ifm_data we'll core dump. : : A safer approach is to mark ifi_epoch as packed or put differently, : define time_t as a 64-bit integral with 32-bit alignment. This can : avoid a lot of unexpected internal padding as well (e.g. struct : timeval). Marking it as packed won't help. If the elements aren't properly aligned, gcc won't access multi-word entities properly. It might eliminate the warning, but it will break at runtime. Warner From xcllnt at mac.com Tue Feb 17 22:51:13 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Feb 17 22:51:30 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <20090217.234216.1276682135.imp@bsdimp.com> References: <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> <20090217.234216.1276682135.imp@bsdimp.com> Message-ID: On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: > : A safer approach is to mark ifi_epoch as packed or put differently, > : define time_t as a 64-bit integral with 32-bit alignment. This can > : avoid a lot of unexpected internal padding as well (e.g. struct > : timeval). > > Marking it as packed won't help. If the elements aren't properly > aligned, gcc won't access multi-word entities properly. It might > eliminate the warning, but it will break at runtime. But GCC will use a pair of 32-bit loads and/or stores to access the 64-bit integral in that case. There should be no runtime breakage. You only do this for n32 of course. -- Marcel Moolenaar xcllnt@mac.com From imp at bsdimp.com Tue Feb 17 23:00:55 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Feb 17 23:01:13 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: References: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> <20090217.234216.1276682135.imp@bsdimp.com> Message-ID: <20090217.235826.-1697751865.imp@bsdimp.com> In message: Marcel Moolenaar writes: : : On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: : : > : A safer approach is to mark ifi_epoch as packed or put differently, : > : define time_t as a 64-bit integral with 32-bit alignment. This can : > : avoid a lot of unexpected internal padding as well (e.g. struct : > : timeval). : > : > Marking it as packed won't help. If the elements aren't properly : > aligned, gcc won't access multi-word entities properly. It might : > eliminate the warning, but it will break at runtime. : : But GCC will use a pair of 32-bit loads and/or stores to : access the 64-bit integral in that case. There should be : no runtime breakage. You only do this for n32 of course. Why only n32? Registers are still 64-bit in n32. Warner From tinderbox at freebsd.org Wed Feb 18 04:49:17 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Feb 18 04:49:24 2009 Subject: [head tinderbox] failure on mips/mips Message-ID: <20090218124913.EF54F7302F@freebsd-current.sentex.ca> TB --- 2009-02-18 11:47:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-18 11:47:46 - starting HEAD tinderbox run for mips/mips TB --- 2009-02-18 11:47:46 - cleaning the object tree TB --- 2009-02-18 11:47:57 - cvsupping the source tree TB --- 2009-02-18 11:47:57 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-02-18 11:48:05 - building world TB --- 2009-02-18 11:48:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-18 11:48:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-18 11:48:05 - TARGET=mips TB --- 2009-02-18 11:48:05 - TARGET_ARCH=mips TB --- 2009-02-18 11:48:05 - TZ=UTC TB --- 2009-02-18 11:48:05 - __MAKE_CONF=/dev/null TB --- 2009-02-18 11:48:05 - cd /src TB --- 2009-02-18 11:48:05 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 18 11:48:06 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -DNDEBUG -I/src/usr.sbin/bsnmpd/modules/snmp_hostres/../../../lpr/common_source -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c hostres_tree.c -o hostres_tree.So building shared library snmp_hostres.so.5 sed -e 's%@MODPATH@%/usr/lib/%g' -e 's%@DEFPATH@%/usr/share/snmp/defs/%g' -e 's%@MIBSPATH@%/usr/share/snmp/mibs/%g' < /src/usr.sbin/bsnmpd/modules/snmp_hostres/snmp_hostres.3 | gzip -cn > snmp_hostres.3.gz ===> usr.sbin/bsnmpd/modules/snmp_mibII (all) cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/lib -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmpd -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_SYS_TREE_H -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c -o mibII.So cc1: warnings being treated as errors /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c: In function 'handle_rtmsg': /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules/snmp_mibII. *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules. *** Error code 1 Stop in /src/usr.sbin/bsnmpd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-18 12:49:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-18 12:49:13 - ERROR: failed to build world TB --- 2009-02-18 12:49:13 - 2882.20 user 323.10 system 3687.23 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From andrew-freebsd at areilly.bpc-users.org Wed Feb 18 06:14:05 2009 From: andrew-freebsd at areilly.bpc-users.org (Andrew Reilly) Date: Wed Feb 18 06:14:16 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <20090217.222152.-109416210.imp@bsdimp.com> References: <20090218023328.227617302F@freebsd-current.sentex.ca> <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> Message-ID: <20090218110402.GA13040@duncan.reilly.home> On Tue, Feb 17, 2009 at 10:21:52PM -0700, M. Warner Losh wrote: > In message: <20090217.203647.-1518647466.imp@bsdimp.com> > "M. Warner Losh" writes: > : In message: <20090218023328.227617302F@freebsd-current.sentex.ca> > : FreeBSD Tinderbox writes: > : : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type > The first one is: > > case RTM_IFINFO: > ifm = (struct if_msghdr *)rtm; > mib_extract_addrs(ifm->ifm_addrs, (u_char *)(ifm + 1), addrs); > if ((ifp = mib_find_if_sys(ifm->ifm_index)) == NULL) > break; > > rtm is of type struct rt_msghdr. This has an alignment requirement of > 4 on mips, at least on 32-bit mips (the biggest data element is a > u_long). struct if_msghdr has an alignment requirement of 8, because > time_t is int64_t on MIPS, which is 8-bytes in size. If the memory that rtm can be pointing to can be either a struct rt_msghdr or a struct if_msghdr, then shouldn't it really be pointing to a union of those two, and then the alignment will sort itself out? (As far as I know, that's the only way that C99 will guarantee that the right thing happens anyway, otherwise strict aliasing analysis would allow much worse badness to happen, potentially.) Not looked at the code myself. Perhaps there's a reason why that would be unworkable. Cheers, Andrew From imp at bsdimp.com Wed Feb 18 07:22:21 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Feb 18 07:22:32 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <20090218110402.GA13040@duncan.reilly.home> References: <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> <20090218110402.GA13040@duncan.reilly.home> Message-ID: <20090218.082103.-761055997.imp@bsdimp.com> In message: <20090218110402.GA13040@duncan.reilly.home> Andrew Reilly writes: : On Tue, Feb 17, 2009 at 10:21:52PM -0700, M. Warner Losh wrote: : > In message: <20090217.203647.-1518647466.imp@bsdimp.com> : > "M. Warner Losh" writes: : > : In message: <20090218023328.227617302F@freebsd-current.sentex.ca> : > : FreeBSD Tinderbox writes: : > : : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type : > The first one is: : > : > case RTM_IFINFO: : > ifm = (struct if_msghdr *)rtm; : > mib_extract_addrs(ifm->ifm_addrs, (u_char *)(ifm + 1), addrs); : > if ((ifp = mib_find_if_sys(ifm->ifm_index)) == NULL) : > break; : > : > rtm is of type struct rt_msghdr. This has an alignment requirement of : > 4 on mips, at least on 32-bit mips (the biggest data element is a : > u_long). struct if_msghdr has an alignment requirement of 8, because : > time_t is int64_t on MIPS, which is 8-bytes in size. : : If the memory that rtm can be pointing to can be either a struct : rt_msghdr or a struct if_msghdr, then shouldn't it really be : pointing to a union of those two, and then the alignment will : sort itself out? (As far as I know, that's the only way that : C99 will guarantee that the right thing happens anyway, : otherwise strict aliasing analysis would allow much worse : badness to happen, potentially.) This is a stream of data from the kernel, multiple messages, so making it be a union wouldn't force the proper alignment from the kernel... : Not looked at the code myself. Perhaps there's a reason why : that would be unworkable. Yes. There is. Warner From imp at bsdimp.com Wed Feb 18 07:28:19 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Feb 18 07:28:36 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <20090218110402.GA13040@duncan.reilly.home> References: <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> <20090218110402.GA13040@duncan.reilly.home> Message-ID: <20090218.082559.-1112729020.imp@bsdimp.com> In message: <20090218110402.GA13040@duncan.reilly.home> Andrew Reilly writes: : On Tue, Feb 17, 2009 at 10:21:52PM -0700, M. Warner Losh wrote: : > In message: <20090217.203647.-1518647466.imp@bsdimp.com> : > "M. Warner Losh" writes: : > : In message: <20090218023328.227617302F@freebsd-current.sentex.ca> : > : FreeBSD Tinderbox writes: : > : : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type : > The first one is: : > : > case RTM_IFINFO: : > ifm = (struct if_msghdr *)rtm; : > mib_extract_addrs(ifm->ifm_addrs, (u_char *)(ifm + 1), addrs); : > if ((ifp = mib_find_if_sys(ifm->ifm_index)) == NULL) : > break; : > : > rtm is of type struct rt_msghdr. This has an alignment requirement of : > 4 on mips, at least on 32-bit mips (the biggest data element is a : > u_long). struct if_msghdr has an alignment requirement of 8, because : > time_t is int64_t on MIPS, which is 8-bytes in size. : : If the memory that rtm can be pointing to can be either a struct : rt_msghdr or a struct if_msghdr, then shouldn't it really be : pointing to a union of those two, and then the alignment will : sort itself out? (As far as I know, that's the only way that : C99 will guarantee that the right thing happens anyway, : otherwise strict aliasing analysis would allow much worse : badness to happen, potentially.) : : Not looked at the code myself. Perhaps there's a reason why : that would be unworkable. There's a second issue. There's a number of different structures that are type punned to rt_msghdr. I'm worried it would be an ABI change to do that as well. In this case, code inspection shows the code to be fine since the dangerous element isn't touched. Warner From xcllnt at mac.com Wed Feb 18 10:19:38 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Feb 18 10:19:55 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <20090217.235826.-1697751865.imp@bsdimp.com> References: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> <20090217.234216.1276682135.imp@bsdimp.com> <20090217.235826.-1697751865.imp@bsdimp.com> Message-ID: On Feb 17, 2009, at 10:58 PM, M. Warner Losh wrote: > In message: > Marcel Moolenaar writes: > : > : On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: > : > : > : A safer approach is to mark ifi_epoch as packed or put > differently, > : > : define time_t as a 64-bit integral with 32-bit alignment. This > can > : > : avoid a lot of unexpected internal padding as well (e.g. struct > : > : timeval). > : > > : > Marking it as packed won't help. If the elements aren't properly > : > aligned, gcc won't access multi-word entities properly. It might > : > eliminate the warning, but it will break at runtime. > : > : But GCC will use a pair of 32-bit loads and/or stores to > : access the 64-bit integral in that case. There should be > : no runtime breakage. You only do this for n32 of course. > > Why only n32? Registers are still 64-bit in n32. I think that's the problem. With registers still 64-bit, MIPS n32 isn't really behaving like a 32-bit machine in the case of 64-bit accesses. It's that aspect you want to tweak. So, if you give all 64-bit integrals an alignment of 4 bytes, then GCC will use a pair of 32-bit loads and stores (just like, say, powerpc) and you don't run into the alignment problems where all of a sudden a data structure gets 8-byte alignment, triggers warnings, and we try to correct it with kluges. For MIPS n64 things are like any other LP64 architecture, so you don't have to tweak anything. In other words: by tweaking the alignment of 64-bit types in n32, you prohibit GCC from using the 64-bit capabilities of the processor and MIPS isn't so weird anymore. NOTE: On ARM, GCC aligns structures to a 4-byte boundary by default. This has caused us problems and instead of fixing the default behaviour of the compiler, we slammed __packed onto structures. If we had changed the default behaviour of the compiler, then all structures would be naturally aligned and we would be able to use the half-word memory accesses that newer ARM processors have. No, we __packed the lot and created a big performance bottleneck because now we can only use byte-wise memory accesses. What was done for performance (default alignment of 4-bytes for structures), was turned into a huge pessimisation by us compensating with __packed. We have more optimal code if the compiler aligns structures on their natural boundary! The point being that programmers *do* code with certain assumptions and as soon as those assumptions don't hold on a platform, you end up worse off. My thoughts for MIPS n32 are to make it behave like any "normal" 32-bit strong- alignment platform to avoid 1) a large number of runtime alignment faults -- which are a bigger performance bottleneck than forcing 64-bit integrals to be accessed with 2 32-bit accesses and 2) avoid further abuse of __packed, which turns all accesses in a series of byte-wise accesses. At Juniper I changed the ARM compiler default by adding: -mstructure-size-boundary=8 That made life a *lot* simpler and performance hasn't been sacrificed. Just an explanation of where I'm coming from... -- Marcel Moolenaar xcllnt@mac.com From imp at bsdimp.com Wed Feb 18 11:07:20 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Feb 18 11:07:26 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: References: <20090217.235826.-1697751865.imp@bsdimp.com> Message-ID: <20090218.120514.831271136.imp@bsdimp.com> In message: Marcel Moolenaar writes: : : On Feb 17, 2009, at 10:58 PM, M. Warner Losh wrote: : : > In message: : > Marcel Moolenaar writes: : > : : > : On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: : > : : > : > : A safer approach is to mark ifi_epoch as packed or put : > differently, : > : > : define time_t as a 64-bit integral with 32-bit alignment. This : > can : > : > : avoid a lot of unexpected internal padding as well (e.g. struct : > : > : timeval). : > : > : > : > Marking it as packed won't help. If the elements aren't properly : > : > aligned, gcc won't access multi-word entities properly. It might : > : > eliminate the warning, but it will break at runtime. : > : : > : But GCC will use a pair of 32-bit loads and/or stores to : > : access the 64-bit integral in that case. There should be : > : no runtime breakage. You only do this for n32 of course. : > : > Why only n32? Registers are still 64-bit in n32. : : I think that's the problem. With registers still 64-bit, MIPS : n32 isn't really behaving like a 32-bit machine in the case of : 64-bit accesses. It's that aspect you want to tweak. So, if : you give all 64-bit integrals an alignment of 4 bytes, then : GCC will use a pair of 32-bit loads and stores (just like, : say, powerpc) and you don't run into the alignment problems : where all of a sudden a data structure gets 8-byte alignment, : triggers warnings, and we try to correct it with kluges. MIPS n32 is a 64-bit ABI in many ways, but 32-bit in others. Its data-types are 32-bit, but the compiler is free to leverage the underlying 64-bit machine to implement it. So for 64-bit quantities, is uses the ld/sd op codes. : For MIPS n64 things are like any other LP64 architecture, so : you don't have to tweak anything. I think so. : In other words: by tweaking the alignment of 64-bit types in : n32, you prohibit GCC from using the 64-bit capabilities of : the processor and MIPS isn't so weird anymore. I think so, but there's a twist. On MIPS, one kernel supports multiple ABIs at the same time. I'm not entirely sure how the routing interface would cope with this sort of thing because the size of u_long changes. I need to do some more research to see what's going on there... : NOTE: On ARM, GCC aligns structures to a 4-byte boundary by : default. This has caused us problems and instead of fixing : the default behaviour of the compiler, we slammed __packed : onto structures. If we had changed the default behaviour of : the compiler, then all structures would be naturally aligned : and we would be able to use the half-word memory accesses : that newer ARM processors have. No, we __packed the lot and : created a big performance bottleneck because now we can only : use byte-wise memory accesses. : What was done for performance (default alignment of 4-bytes : for structures), was turned into a huge pessimisation by us : compensating with __packed. We have more optimal code if : the compiler aligns structures on their natural boundary! The reason we have the compiler doing this on ARM is for ABI conformance. There are other ABIs on ARM that don't suffer from these problems. We should investigate using them. : The point being that programmers *do* code with certain : assumptions and as soon as those assumptions don't hold on : a platform, you end up worse off. My thoughts for MIPS n32 : are to make it behave like any "normal" 32-bit strong- : alignment platform to avoid 1) a large number of runtime : alignment faults -- which are a bigger performance bottleneck : than forcing 64-bit integrals to be accessed with 2 32-bit : accesses Run time faults aren't a bottleneck. They are a core dump, which is why I'm looking at this in the first place. :) : and 2) avoid further abuse of __packed, which turns : all accesses in a series of byte-wise accesses. We haven't really abused __packed. The items we have as '__packed' really are packed data structures for the wire. We have also added some __aligned() flag as well which help to mitigate the performance penalties because the compiler can unpack the items. : At Juniper I changed the ARM compiler default by adding: : -mstructure-size-boundary=8 : : That made life a *lot* simpler and performance hasn't been : sacrificed. Except you've invented a new ABI by doing that... I think that the project should look at transitioning to a different ABI that works better. ARM has several to choose from... : Just an explanation of where I'm coming from... Yes. Unfortunately, those kinds of hacks take us further away form the standard environment for these platforms. There are many dark corners of the current MIPS code that knows all the alignment and layout issues and changing the compiler to force a different alignment will break that code... Anyway, since we are a little ways away from having to cope with all the ABI issues for MIPS... It also turns out that in this case, a simple (void *) is safe and causes no issues because that time_t isn't accessed... It does give one time to pause and think about it. Warner From xcllnt at mac.com Wed Feb 18 11:36:33 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Feb 18 11:36:50 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <20090218.120514.831271136.imp@bsdimp.com> References: <20090217.235826.-1697751865.imp@bsdimp.com> <20090218.120514.831271136.imp@bsdimp.com> Message-ID: <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com> On Feb 18, 2009, at 11:05 AM, M. Warner Losh wrote: > : In other words: by tweaking the alignment of 64-bit types in > : n32, you prohibit GCC from using the 64-bit capabilities of > : the processor and MIPS isn't so weird anymore. > > I think so, but there's a twist. > > On MIPS, one kernel supports multiple ABIs at the same time. I'm not > entirely sure how the routing interface would cope with this sort of > thing because the size of u_long changes. I need to do some more > research to see what's going on there... Hmm... My first reaction is not to go there right away. It's probably safer or go the amd64 route: keep ILP32 and LP64 distinct. We have the infrastructure in place and we can always optimize and blend once things are working. > There are other ABIs on ARM that don't suffer from these problems. We > should investigate using them. I agree. It's better for FreeBSD/arm in particular if it's more like FreeBSD/i386. It may not be best for the ARM port in absolute sense, but we only have a few developers working on non-i386 hardware and a whole lot of developers who don't care about non-i386... > : The point being that programmers *do* code with certain > : assumptions and as soon as those assumptions don't hold on > : a platform, you end up worse off. My thoughts for MIPS n32 > : are to make it behave like any "normal" 32-bit strong- > : alignment platform to avoid 1) a large number of runtime > : alignment faults -- which are a bigger performance bottleneck > : than forcing 64-bit integrals to be accessed with 2 32-bit > : accesses > > Run time faults aren't a bottleneck. They are a core dump, which is > why I'm looking at this in the first place. :) :-) > : At Juniper I changed the ARM compiler default by adding: > : -mstructure-size-boundary=8 > : > : That made life a *lot* simpler and performance hasn't been > : sacrificed. > > Except you've invented a new ABI by doing that... We have a products to make and a source base to work with. Swimming upstream is best left to salmons :-) > I think that the > project should look at transitioning to a different ABI that works > better. ARM has several to choose from... I tend to agree. > It also turns out that in this case, a simple (void *) is safe and > causes no issues because that time_t isn't accessed... It does give > one time to pause and think about it. Fair enough. Misalignment in process space can easily be made non-fatal, in which case it's mostly a performance problem. That makes the problem space much more contained and therefore easier to deal with... -- Marcel Moolenaar xcllnt@mac.com From kostikbel at gmail.com Wed Feb 18 12:45:23 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Feb 18 12:45:35 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: References: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> <20090217.234216.1276682135.imp@bsdimp.com> <20090217.235826.-1697751865.imp@bsdimp.com> Message-ID: <20090218200023.GU41617@deviant.kiev.zoral.com.ua> On Wed, Feb 18, 2009 at 10:19:34AM -0800, Marcel Moolenaar wrote: > > On Feb 17, 2009, at 10:58 PM, M. Warner Losh wrote: > > >In message: > > Marcel Moolenaar writes: > >: > >: On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: > >: > >: > : A safer approach is to mark ifi_epoch as packed or put > >differently, > >: > : define time_t as a 64-bit integral with 32-bit alignment. This > >can > >: > : avoid a lot of unexpected internal padding as well (e.g. struct > >: > : timeval). > >: > > >: > Marking it as packed won't help. If the elements aren't properly > >: > aligned, gcc won't access multi-word entities properly. It might > >: > eliminate the warning, but it will break at runtime. > >: > >: But GCC will use a pair of 32-bit loads and/or stores to > >: access the 64-bit integral in that case. There should be > >: no runtime breakage. You only do this for n32 of course. > > > >Why only n32? Registers are still 64-bit in n32. > > I think that's the problem. With registers still 64-bit, MIPS > n32 isn't really behaving like a 32-bit machine in the case of > 64-bit accesses. It's that aspect you want to tweak. So, if > you give all 64-bit integrals an alignment of 4 bytes, then > GCC will use a pair of 32-bit loads and stores (just like, > say, powerpc) and you don't run into the alignment problems > where all of a sudden a data structure gets 8-byte alignment, > triggers warnings, and we try to correct it with kluges. > > For MIPS n64 things are like any other LP64 architecture, so > you don't have to tweak anything. > > In other words: by tweaking the alignment of 64-bit types in > n32, you prohibit GCC from using the 64-bit capabilities of > the processor and MIPS isn't so weird anymore. > > NOTE: On ARM, GCC aligns structures to a 4-byte boundary by > default. This has caused us problems and instead of fixing > the default behaviour of the compiler, we slammed __packed > onto structures. If we had changed the default behaviour of > the compiler, then all structures would be naturally aligned > and we would be able to use the half-word memory accesses > that newer ARM processors have. No, we __packed the lot and > created a big performance bottleneck because now we can only > use byte-wise memory accesses. > What was done for performance (default alignment of 4-bytes > for structures), was turned into a huge pessimisation by us > compensating with __packed. We have more optimal code if > the compiler aligns structures on their natural boundary! > > The point being that programmers *do* code with certain > assumptions and as soon as those assumptions don't hold on > a platform, you end up worse off. My thoughts for MIPS n32 > are to make it behave like any "normal" 32-bit strong- > alignment platform to avoid 1) a large number of runtime > alignment faults -- which are a bigger performance bottleneck > than forcing 64-bit integrals to be accessed with 2 32-bit > accesses and 2) avoid further abuse of __packed, which turns > all accesses in a series of byte-wise accesses. > > At Juniper I changed the ARM compiler default by adding: > -mstructure-size-boundary=8 > > That made life a *lot* simpler and performance hasn't been > sacrificed. > > Just an explanation of where I'm coming from... I have a question. All architectures I had a slightest interest in, included the required alignment of types into the ABI specification. This is true at least for i386. amd64, sparc v8 and v9, and HP-PA 1.1 and 2.0. Is MIPS different in this aspect ? -------------- 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-mips/attachments/20090218/444251f9/attachment.pgp From imp at bsdimp.com Wed Feb 18 14:11:44 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Feb 18 14:12:02 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <20090218200023.GU41617@deviant.kiev.zoral.com.ua> References: <20090217.235826.-1697751865.imp@bsdimp.com> <20090218200023.GU41617@deviant.kiev.zoral.com.ua> Message-ID: <20090218.143638.-1025539642.imp@bsdimp.com> In message: <20090218200023.GU41617@deviant.kiev.zoral.com.ua> Kostik Belousov writes: : I have a question. All architectures I had a slightest interest in, : included the required alignment of types into the ABI specification. : This is true at least for i386. amd64, sparc v8 and v9, and HP-PA 1.1 : and 2.0. : : Is MIPS different in this aspect ? MIPS does define it as well. I have all the old o32 docs, but have had trouble locating the n32/n64 docs since they were done by SGI and SGI is now defunct. I know MIPS Technologies has information on nubi, which is yet another ABI family aimed more at the embedded platforms, but it hasn't had much traction. Warner From imp at bsdimp.com Wed Feb 18 14:11:44 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Feb 18 14:12:13 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com> References: <20090218.120514.831271136.imp@bsdimp.com> <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com> Message-ID: <20090218.143347.466770936.imp@bsdimp.com> In message: <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com> Marcel Moolenaar writes: : : On Feb 18, 2009, at 11:05 AM, M. Warner Losh wrote: : > : In other words: by tweaking the alignment of 64-bit types in : > : n32, you prohibit GCC from using the 64-bit capabilities of : > : the processor and MIPS isn't so weird anymore. : > : > I think so, but there's a twist. : > : > On MIPS, one kernel supports multiple ABIs at the same time. I'm not : > entirely sure how the routing interface would cope with this sort of : > thing because the size of u_long changes. I need to do some more : > research to see what's going on there... : : Hmm... My first reaction is not to go there right away. It's : probably safer or go the amd64 route: keep ILP32 and LP64 : distinct. We have the infrastructure in place and we can : always optimize and blend once things are working. I don't think that's a viable option. MIPS doesn't have a 64-bit mode, but rather is always 64-bit. Or rather right now even in the port we have that supports n32 and n64 along side of o32, it is A or B or C. : > There are other ABIs on ARM that don't suffer from these problems. We : > should investigate using them. : : I agree. It's better for FreeBSD/arm in particular if it's : more like FreeBSD/i386. It may not be best for the ARM : port in absolute sense, but we only have a few developers : working on non-i386 hardware and a whole lot of developers : who don't care about non-i386... So far the number of places we've had to change in the kernel is minimal for the current ABI. The newer ABI is indeed targeted more at software that's been traditionally developed for x86 hardware. : > : At Juniper I changed the ARM compiler default by adding: : > : -mstructure-size-boundary=8 : > : : > : That made life a *lot* simpler and performance hasn't been : > : sacrificed. : > : > Except you've invented a new ABI by doing that... : : We have a products to make and a source base to work : with. Swimming upstream is best left to salmons :-) Yes. In a closed environment, you have that option. : > I think that the : > project should look at transitioning to a different ABI that works : > better. ARM has several to choose from... : : I tend to agree. : : : > It also turns out that in this case, a simple (void *) is safe and : > causes no issues because that time_t isn't accessed... It does give : > one time to pause and think about it. : : Fair enough. Misalignment in process space can easily be : made non-fatal, in which case it's mostly a performance : problem. That makes the problem space much more contained : and therefore easier to deal with... Other systems on mips are a mixed bag. Some allow user land fixup, while others abort the application... I think we need more real-world experience for which one is the best approach... Warner From bms at incunabulum.net Wed Feb 18 14:12:50 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Feb 18 14:13:02 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <20090218.120514.831271136.imp@bsdimp.com> References: <20090217.235826.-1697751865.imp@bsdimp.com> <20090218.120514.831271136.imp@bsdimp.com> Message-ID: <499C8396.2020000@incunabulum.net> M. Warner Losh wrote: > ... > : The point being that programmers *do* code with certain > : assumptions and as soon as those assumptions don't hold on > : a platform, you end up worse off. My thoughts for MIPS n32 > : are to make it behave like any "normal" 32-bit strong- > : alignment platform to avoid 1) a large number of runtime > : alignment faults -- which are a bigger performance bottleneck > : than forcing 64-bit integrals to be accessed with 2 32-bit > : accesses > FWIW, Linux use a type-length-value protocol for the netlink routing socket, so alignment issues of this kind are shifted around (forgive the pun). > It also turns out that in this case, a simple (void *) is safe and > causes no issues because that time_t isn't accessed... It does give > one time to pause and think about it. > Yes, the void * cast works around the issue for now, but doesn't offer any guarantees that we are doing the right thing on strict alignment architectures. If the alignment *is* invalid, then we take the hit. cheers BMS From imp at bsdimp.com Wed Feb 18 14:46:01 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Feb 18 14:46:18 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <499C8396.2020000@incunabulum.net> References: <20090218.120514.831271136.imp@bsdimp.com> <499C8396.2020000@incunabulum.net> Message-ID: <20090218.154414.-1283372409.imp@bsdimp.com> In message: <499C8396.2020000@incunabulum.net> Bruce Simpson writes: : M. Warner Losh wrote: : > ... : > : The point being that programmers *do* code with certain : > : assumptions and as soon as those assumptions don't hold on : > : a platform, you end up worse off. My thoughts for MIPS n32 : > : are to make it behave like any "normal" 32-bit strong- : > : alignment platform to avoid 1) a large number of runtime : > : alignment faults -- which are a bigger performance bottleneck : > : than forcing 64-bit integrals to be accessed with 2 32-bit : > : accesses : > : : FWIW, Linux use a type-length-value protocol for the netlink routing : socket, so alignment issues of this kind are shifted around (forgive the : pun). FreeBSD does too for the most part, but it is only at the inter-message level, not intra-message. : > It also turns out that in this case, a simple (void *) is safe and : > causes no issues because that time_t isn't accessed... It does give : > one time to pause and think about it. : > : : Yes, the void * cast works around the issue for now, but doesn't offer : any guarantees that we are doing the right thing on strict alignment : architectures. : If the alignment *is* invalid, then we take the hit. Right. The compiler doesn't check it, but I just did and things are fine given the fields accessed. But its that last bit that's the problem... I also have changed the offending line in my tree to be u_long instead of time_t since that is a better match to the protocol, and also gives us 168 years of uptime before there's an issue. Warner From tinderbox at freebsd.org Wed Feb 18 14:49:36 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Feb 18 14:49:48 2009 Subject: [head tinderbox] failure on mips/mips Message-ID: <20090218224933.1A16A7302F@freebsd-current.sentex.ca> TB --- 2009-02-18 21:45:55 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-18 21:45:55 - starting HEAD tinderbox run for mips/mips TB --- 2009-02-18 21:45:55 - cleaning the object tree TB --- 2009-02-18 21:46:17 - cvsupping the source tree TB --- 2009-02-18 21:46:17 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-02-18 21:46:27 - building world TB --- 2009-02-18 21:46:27 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-18 21:46:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-18 21:46:27 - TARGET=mips TB --- 2009-02-18 21:46:27 - TARGET_ARCH=mips TB --- 2009-02-18 21:46:27 - TZ=UTC TB --- 2009-02-18 21:46:27 - __MAKE_CONF=/dev/null TB --- 2009-02-18 21:46:27 - cd /src TB --- 2009-02-18 21:46:27 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 18 21:46:29 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-strict-aliasing -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/vipw -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv -I/src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr -I/src/usr.sbin/rpc.yppasswdd -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr/yp_dbwrite.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-strict-aliasing -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/vipw -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv -I/src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr -I/src/usr.sbin/rpc.yppasswdd -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv/yp_error.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-strict-aliasing -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/vipw -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv -I/src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr -I/src/usr.sbin/rpc.yppasswdd -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/rpc.yppasswdd/yppasswdd_main.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-strict-aliasing -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/vipw -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv -I/src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr -I/src/usr.sbin/rpc.yppasswdd -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/rpc.yppasswdd/yppasswdd_server.c cc1: warnings being treated as errors /src/usr.sbin/rpc.yppasswdd/yppasswdd_server.c: In function 'yppasswdproc_update_master_1_svc': /src/usr.sbin/rpc.yppasswdd/yppasswdd_server.c:823: warning: cast increases required alignment of target type /src/usr.sbin/rpc.yppasswdd/yppasswdd_server.c:861: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/rpc.yppasswdd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-18 22:49:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-18 22:49:32 - ERROR: failed to build world TB --- 2009-02-18 22:49:32 - 2988.00 user 333.27 system 3817.88 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From xcllnt at mac.com Wed Feb 18 14:54:13 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Feb 18 14:54:19 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: <20090218.143638.-1025539642.imp@bsdimp.com> References: <20090217.235826.-1697751865.imp@bsdimp.com> <20090218200023.GU41617@deviant.kiev.zoral.com.ua> <20090218.143638.-1025539642.imp@bsdimp.com> Message-ID: On Feb 18, 2009, at 1:36 PM, M. Warner Losh wrote: > MIPS does define it as well. I have all the old o32 docs, but have > had trouble locating the n32/n64 docs since they were done by SGI and > SGI is now defunct. http://wwweic.eri.u-tokyo.ac.jp/computer/manual/lx/SGI_Developer/books/Mpro_n32_ABI/sgi_html/index.html -- Marcel Moolenaar xcllnt@mac.com From imp at bsdimp.com Wed Feb 18 17:24:42 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Feb 18 17:24:49 2009 Subject: [head tinderbox] failure on mips/mips In-Reply-To: References: <20090218200023.GU41617@deviant.kiev.zoral.com.ua> <20090218.143638.-1025539642.imp@bsdimp.com> Message-ID: <20090218.182301.112148095.imp@bsdimp.com> In message: Marcel Moolenaar writes: : : On Feb 18, 2009, at 1:36 PM, M. Warner Losh wrote: : > MIPS does define it as well. I have all the old o32 docs, but have : > had trouble locating the n32/n64 docs since they were done by SGI and : > SGI is now defunct. : : http://wwweic.eri.u-tokyo.ac.jp/computer/manual/lx/SGI_Developer/books/Mpro_n32_ABI/sgi_html/index.html Excellent! Thanks! It actually is still at techpubs.sgi.com too... I could have sworn I looked there a while ago only to find nothing running... Warner From tinderbox at freebsd.org Fri Feb 27 16:14:28 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Feb 27 16:14:49 2009 Subject: [head tinderbox] failure on mips/mips Message-ID: <20090228001424.88A307302F@freebsd-current.sentex.ca> TB --- 2009-02-27 23:15:33 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-27 23:15:33 - starting HEAD tinderbox run for mips/mips TB --- 2009-02-27 23:15:33 - cleaning the object tree TB --- 2009-02-27 23:15:48 - cvsupping the source tree TB --- 2009-02-27 23:15:48 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-02-27 23:15:58 - building world TB --- 2009-02-27 23:15:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-27 23:15:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-27 23:15:58 - TARGET=mips TB --- 2009-02-27 23:15:58 - TARGET_ARCH=mips TB --- 2009-02-27 23:15:58 - TZ=UTC TB --- 2009-02-27 23:15:58 - __MAKE_CONF=/dev/null TB --- 2009-02-27 23:15:58 - cd /src TB --- 2009-02-27 23:15:58 - /usr/bin/make -B buildworld >>> World build started on Fri Feb 27 23:15:59 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.bin/from/from.1 > from.1.gz ===> usr.bin/fstat (all) cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.bin/fstat/zfs/../../../sys/cddl/compat/opensolaris -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/include -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/head -I/src/usr.bin/fstat/zfs/.. -DNEED_SOLARIS_BOOLEAN -Wsystem-headers -Werror -Wno-pointer-sign -c /src/usr.bin/fstat/zfs/../zfs.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -D_KVM_VNODE -DZFS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/cd9660.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -D_KVM_VNODE -DZFS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/fstat.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -D_KVM_VNODE -DZFS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/msdosfs.c /src/usr.bin/fstat/msdosfs.c: In function 'msdosfs_filestat': /src/usr.bin/fstat/msdosfs.c:113: error: 'struct denode' has no member named 'de_dev' *** Error code 1 Stop in /src/usr.bin/fstat. *** 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 --- 2009-02-28 00:14:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-28 00:14:24 - ERROR: failed to build world TB --- 2009-02-28 00:14:24 - 2757.22 user 313.93 system 3530.70 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From tinderbox at freebsd.org Fri Feb 27 22:09:03 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Feb 27 22:09:14 2009 Subject: [head tinderbox] failure on mips/mips Message-ID: <20090228060859.6F0887302F@freebsd-current.sentex.ca> TB --- 2009-02-28 05:10:18 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-28 05:10:18 - starting HEAD tinderbox run for mips/mips TB --- 2009-02-28 05:10:18 - cleaning the object tree TB --- 2009-02-28 05:10:30 - cvsupping the source tree TB --- 2009-02-28 05:10:30 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-02-28 05:10:37 - building world TB --- 2009-02-28 05:10:37 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-28 05:10:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-28 05:10:37 - TARGET=mips TB --- 2009-02-28 05:10:37 - TARGET_ARCH=mips TB --- 2009-02-28 05:10:37 - TZ=UTC TB --- 2009-02-28 05:10:37 - __MAKE_CONF=/dev/null TB --- 2009-02-28 05:10:37 - cd /src TB --- 2009-02-28 05:10:37 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 28 05:10:39 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.bin/from/from.1 > from.1.gz ===> usr.bin/fstat (all) cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.bin/fstat/zfs/../../../sys/cddl/compat/opensolaris -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/include -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/head -I/src/usr.bin/fstat/zfs/.. -DNEED_SOLARIS_BOOLEAN -Wsystem-headers -Werror -Wno-pointer-sign -c /src/usr.bin/fstat/zfs/../zfs.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -D_KVM_VNODE -DZFS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/cd9660.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -D_KVM_VNODE -DZFS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/fstat.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -D_KVM_VNODE -DZFS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/msdosfs.c /src/usr.bin/fstat/msdosfs.c: In function 'msdosfs_filestat': /src/usr.bin/fstat/msdosfs.c:113: error: 'struct denode' has no member named 'de_dev' *** Error code 1 Stop in /src/usr.bin/fstat. *** 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 --- 2009-02-28 06:08:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-28 06:08:59 - ERROR: failed to build world TB --- 2009-02-28 06:08:59 - 2755.41 user 317.13 system 3521.05 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full