Crossbuild failure on 8-stable
Hi,
Trying to cross build ARM fails in the following way on 8-stable:
8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011
make toolchain TARGET=arm
Is this perhaps also an issue in 9-current?
Any clues?
cc -O -pipe -ffreestanding -Wformat -I/usr/src/lib/libstand -msoft-float -
D_STANDALONE -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -
I/usr/src/lib/libstand/../libz -std=gnu99 -c
/usr/src/lib/libstand/../libc/net/ntoh.c
{standard input}: Assembler messages:
{standard input}:27: Error: bad instruction `bswap r0'
{standard input}:53: Error: bad instruction `bswap r0'
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
AX88772A AX88772B chipset differences?
I have card based on AX88772B. I tried patch axe driver for vendor and device IDs. card detected, set up link, but no data received. What else need for patch in this driver ? Anybody have datasheet ? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
isp(4) timeout
I see in my logs: isp0: Polled Mailbox Command (0x54) Timeout (50us) (started @ isp_plogx:2122) isp0: Mailbox Command 'EXECUTE IOCB A64' failed (TIMEOUT) isp0: Chan 0 PLOGI 0x010500 failed isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: mailbox cmd (0x4000) with no waiters What do these isp messages mean? It seems em0 went down the same time. The serial console was fine, and em1 was fine too. But I had to reboot to get em0 working again. This is on ia64 r221340 After reboot: ZEEV ifconfig -a em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:13:21:5b:05:1c inet 137.222.187.28 netmask 0xff00 broadcast 137.222.187.255 inet6 fe80::213:21ff:fe5b:51c%em0 prefixlen 64 scopeid 0x4 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:13:21:5b:05:1d inet 10.10.10.14 netmask 0xff00 broadcast 10.10.10.255 inet6 fe80::213:21ff:fe5b:51d%em1 prefixlen 64 scopeid 0x5 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL ZEEV Many thanks Anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Crossbuild failure on 8-stable
On Thu, Jun 30, 2011 at 11:22:36AM +0200, Hans Petter Selasky wrote: Hi, Trying to cross build ARM fails in the following way on 8-stable: 8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011 make toolchain TARGET=arm Is this perhaps also an issue in 9-current? Any clues? Hi Hans Peter, Not sure if it is your problem, but I think it should be make toolchain TARGET_ARCH=arm Regards, Olivier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Crossbuild failure on 8-stable
On Thursday 30 June 2011 13:13:48 Olivier Houchard wrote:
On Thu, Jun 30, 2011 at 11:22:36AM +0200, Hans Petter Selasky wrote:
Hi,
Trying to cross build ARM fails in the following way on 8-stable:
8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011
make toolchain TARGET=arm
Is this perhaps also an issue in 9-current?
Any clues?
Hi Hans Peter,
Not sure if it is your problem, but I think it should be
make toolchain TARGET_ARCH=arm
Using make toolchain TARGET_ARCH=arm gives the same error code.
Tracing down the issue:
/usr/include/machine/endian.h
#define __byte_swap_int_var(x) \
__extension__ ({ register __uint32_t __X = (x); \
__asm (bswap %0 : +r (__X)); \
__X; })
r0 looks like an ARM register passed to a non-arm assembler. I'm going to try:
make toolchains
And see how that works out.
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kern/143370: splash_txt ASCII splash screen module
Antony Mawer wrote: Not sure if this is the right place to post it -- about 6 years ago I put together a module which displays an ASCII splash screen on boot (rather than the graphical splash_pcx and splash_bmp modules). As a user, I think this is rather cool; at least it is more useful for me than bmp/pcx splash modules, as I don't want to load vesa. Hm... Can you center the image if the display size is other than 80x25? Or try to temporarily change the video mode? It looks a bit misplaced in 80x50. Also, this would be 2x as cool if you could animate the splash. For example, if the supplied bitmap is 80x50, you could treat that as 2 frames, and cycle through them periodically (I assume that splash modules work the same way as saved modules do: the main function is called a few times per second, so you can update the screen there). BTW, in txt_init you currently check for data_size = 0; you should also check for data_size BIN_IMAGE_WIDTH * BIN_IMAGE_HEIGHT * 2, since if the bitmap is smaller, you'll draw garbage on the screen. I have uploaded two sample boot splash screens at http://www.mawer.org/freebsd/freebsd1.bin and http://www.mawer.org/freebsd/freebsd2.bin . The files can be produced using TheDraw and saving in its Binary file format, which consists of a sequence of 2 byte pairs. The first byte in a pair is the character to draw on the screen, and the second is the colour/display attributes to draw the character with. As a side note, these images can also be made from video buffer dumps that vidcontrol produces like this: vidcontrol -p /dev/ttyv0 | tail -c +13 screenshot.bin (Substitute ttyv0 for the tty you want to take a picture of; the tty should be in 80x25 mode). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: isp(4) timeout
On 6/30/2011 3:25 AM, Anton Shterenlikht wrote: I see in my logs: isp0: Polled Mailbox Command (0x54) Timeout (50us) (started @ isp_plogx:2122) isp0: Mailbox Command 'EXECUTE IOCB A64' failed (TIMEOUT) isp0: Chan 0 PLOGI 0x010500 failed isp0: Polled Mailbox Command (0x64) Timeout (25us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) More details please. These errors indicate failures to execute commands that try and figure out what's on a fabric and then log into devices on the fabric. Knowing what hardware you have (QLogic card version), what FreeBSD release you are running, would help. A verbose dmesg would be useful. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Opinion on using AMD Phenom II x6 1090t with Gigabyte 890BPA-UD3H and 8GB DDR-3 as a WebServer.
Quoting Dennis Glatting d...@penx.com: On Wed, 2011-06-29 at 07:31 -0500, eculp wrote: I just saw this box that is being promoted as a gaming machine at a great price and am considering it as a web-server. In addition to having no information on the CPU as a server lack of comfort with 6 cores and memory 8GB of memory that I am having a problem with. I am not a gamer but I have always assumed that a gaming machine needs the most aggressive hardware. I have also seen this processor with 12 GB rather than 8 which, in my ignorance sounds better. Any opinions and guidance are appreciated. I have been moving away from Gigabyte however I do have a similar board: MB GIGABYTE GA-870A-UD3 RT This one is GA-890BPA-UD3G that also has RealTek 811D 10/100/1000 Mbit that I doubt will be a limitation. I'll stick in another card anyway. I also like that has is sata3 and usb 3 so it seems to be up to date. My key complaint about Gigabyte is the ReatTek Ethernet chips. Realtek doesn't publish chip specs and therefore the drivers under FreeBSD/Linux are so-so (i.e., they work but not performance optimized and forget about anything but the default MTU). On my board I hate the South Bridge chip, which is useless for RAID. I am also unable to install VMWare ESXi, my last ditch attempt to find a use for my board. There appears to be a hardware incompatibility while installing (i.e., not during the probe sequence, rather after that sequence then onto installation). Thanks a lot for your suggestions and point of view. I'm begining to think that this may be too much machine but comming down doesn't save much so I will probably give it a try. ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FreeBSD 9
Hi, I've installed FreeBSD 9 on a new server because 8.2 doesn't have support for the LSI SAS2008 controller. I've also built the system as a ZFS-root box, and I have to say that I'm quite happy with the disk performance: we're getting about 500MB/s write and 675MB/s read. All in all, I'm very happy with FreeBSD 9. I have noticed two snafus that I thought I'd send to the group just as feedback: 1. net-snmp fails to compile with the following error: /bin/sh ../../libtool --mode=compile cc -I../../include -I. -I../../agent -I../../agent/mibgroup -I../../snmplib -I/usr/include -O2 -pipe -fno-strict-aliasing -Ufreebsd9 -Dfreebsd9=freebsd9 -c -o mibII/tcpTable.lo mibII/tcpTable.c libtool: compile: cc -I../../include -I. -I../../agent -I../../agent/mibgroup -I../../snmplib -I/usr/include -O2 -pipe -fno-strict-aliasing -Ufreebsd9 -Dfreebsd9=freebsd9 -c mibII/tcpTable.c -fPIC -DPIC -o mibII/.libs/tcpTable.o mibII/tcpTable.c:94: error: field 'pcb' has incomplete type mibII/tcpTable.c: In function 'tcpTable_load': mibII/tcpTable.c:866: error: dereferencing pointer to incomplete type mibII/tcpTable.c:868: error: dereferencing pointer to incomplete type mibII/tcpTable.c:868: error: invalid application of 'sizeof' to incomplete type 'struct xinpgen' mibII/tcpTable.c:872: error: dereferencing pointer to incomplete type mibII/tcpTable.c:876: error: dereferencing pointer to incomplete type mibII/tcpTable.c:877: error: invalid application of 'sizeof' to incomplete type 'struct inpcb' mibII/tcpTable.c:881: error: dereferencing pointer to incomplete type 2. secondary IP addresses on network interfaces don't seem to be working In my rc.conf, I have: ifconfig_bce0=1.2.3.4 netmask 255.255.252.0 ifconfig_bce0_alias0=1.2.3.5 netmask 255.255.255.255 but when the machine reboots, it only gets its primary IP address. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafsont...@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9
On 2011-06-30 17:26, Tim Gustafson wrote: Hi, I've installed FreeBSD 9 on a new server because 8.2 doesn't have support for the LSI SAS2008 controller. I've also built the system as a ZFS-root box, and I have to say that I'm quite happy with the disk performance: we're getting about 500MB/s write and 675MB/s read. All in all, I'm very happy with FreeBSD 9. I have noticed two snafus that I thought I'd send to the group just as feedback: 2. secondary IP addresses on network interfaces don't seem to be working In my rc.conf, I have: ifconfig_bce0=1.2.3.4 netmask 255.255.252.0 ifconfig_bce0_alias0=1.2.3.5 netmask 255.255.255.255 but when the machine reboots, it only gets its primary IP address. I think you need something along the line of ifconfig_bce0_alias0=inet 1.2.3.5 netmask ..., notice the 'inet', since aliasN can be used for both inet and inet6. HTH! -- Niclas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9
On 30 June 2011 20:11, Niclas Zeising niclas.zeis...@gmail.com wrote: On 2011-06-30 17:26, Tim Gustafson wrote: Hi, I've installed FreeBSD 9 on a new server because 8.2 doesn't have support for the LSI SAS2008 controller. I've also built the system as a ZFS-root box, and I have to say that I'm quite happy with the disk performance: we're getting about 500MB/s write and 675MB/s read. All in all, I'm very happy with FreeBSD 9. I have noticed two snafus that I thought I'd send to the group just as feedback: 2. secondary IP addresses on network interfaces don't seem to be working In my rc.conf, I have: ifconfig_bce0=1.2.3.4 netmask 255.255.252.0 ifconfig_bce0_alias0=1.2.3.5 netmask 255.255.255.255 but when the machine reboots, it only gets its primary IP address. I think you need something along the line of ifconfig_bce0_alias0=inet 1.2.3.5 netmask ..., notice the 'inet', since aliasN can be used for both inet and inet6. HTH! Exactly. Since SVN rev 197139 you need to explicitly specify the protocol family before address in the ifconfig_IF_alias= string. -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Intel GPU kernel driver
[Please remove current@ when replying.] I created the first code drop for the ongoing GEM/KMS project. Please note that this is not an end-user release, and even _not_ a call for testing. The project is not finished yet, and I expect quite more efforts from me even after the scheduled project end, and from ports/x11 people, before the driver and usermode infrastructure will be ready for the general public consumption. That said, the patch is only of use for you now if you want to review, debug or otherwise help the project. The driver is known to be unstable, some parts are missing, some (esp. VM changes) are under the discussion and propably will be changed. If you have fix or useful bug analisys or suggestions for improvements, you are welcome. I will not answer to the support requests for this code now, please do not waste your time asking for it. The pointers to the patches, useful hints for debugging and bug reporting, and some notes are at the http://wiki.freebsd.org/Intel_GPU. I will maintain this page further. Current patch is ~50KLOC, it took quite an efforts to bring the code to the state where there is something to debug. Thanks for everybody who waited for it, and please be patient while the further work is done. pgpFKqtgJ5Gze.pgp Description: PGP signature
Re: Crossbuild failure on 8-stable
On 6/30/2011 4:22 AM, Hans Petter Selasky wrote:
Hi,
Trying to cross build ARM fails in the following way on 8-stable:
8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011
make toolchain TARGET=arm
Is this perhaps also an issue in 9-current?
Any clues?
cc -O -pipe -ffreestanding -Wformat -I/usr/src/lib/libstand -msoft-float -
D_STANDALONE -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -
I/usr/src/lib/libstand/../libz -std=gnu99 -c
/usr/src/lib/libstand/../libc/net/ntoh.c
{standard input}: Assembler messages:
{standard input}:27: Error: bad instruction `bswap r0'
{standard input}:53: Error: bad instruction `bswap r0'
and you also said:
Tracing down the issue:
/usr/include/machine/endian.h
#define __byte_swap_int_var(x) \
__extension__ ({ register __uint32_t __X = (x); \
__asm (bswap %0 : +r (__X)); \
__X; })
r0 looks like an ARM register passed to a non-arm assembler. I'm going to try:
Looks like you have an ARM compiler/assembler because the assembler
rejects the i386/amd64 bswap assembly command.
Does anyone remember if the cross compiler has the cross include paths
compiled into them or should there be a -I in the compile command to
correctly expand the #include machine/endian.h ? I thought the cross
path was compiled into the cross compiler.
You manually test the cc command with the included -I option.
--Mark
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thoughts on TMPFS no longer being considered highly experimental
Maybe i'm missing something but creating/removing large number of files in one directory on tmpfs was very slow for me. That was long ago and ZFS was in so i'll try to retest... I decided to torture test tmpfs with bonnie++ on one of my machines and the machine wedged. I can ping it but that's about it. Originally I was in favor of removing the warning, but now, not so much. -- Sean Collins Core IT Pro, LLC www.coreitpro.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Crossbuild failure on 8-stable
On Thu, Jun 30, 2011 at 9:14 AM, Mark Tinguely marktingu...@gmail.com wrote:
On 6/30/2011 4:22 AM, Hans Petter Selasky wrote:
Hi,
Trying to cross build ARM fails in the following way on 8-stable:
8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011
make toolchain TARGET=arm
Is this perhaps also an issue in 9-current?
Any clues?
cc -O -pipe -ffreestanding -Wformat -I/usr/src/lib/libstand -msoft-float
-
D_STANDALONE -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -
I/usr/src/lib/libstand/../libz -std=gnu99 -c
/usr/src/lib/libstand/../libc/net/ntoh.c
{standard input}: Assembler messages:
{standard input}:27: Error: bad instruction `bswap r0'
{standard input}:53: Error: bad instruction `bswap r0'
and you also said:
Tracing down the issue:
/usr/include/machine/endian.h
#define __byte_swap_int_var(x) \
__extension__ ({ register __uint32_t __X = (x); \
__asm (bswap %0 : +r (__X)); \
__X; })
r0 looks like an ARM register passed to a non-arm assembler. I'm going to
try:
Looks like you have an ARM compiler/assembler because the assembler rejects
the i386/amd64 bswap assembly command.
Does anyone remember if the cross compiler has the cross include paths
compiled into them or should there be a -I in the compile command to
correctly expand the #include machine/endian.h ? I thought the cross
path was compiled into the cross compiler.
You manually test the cc command with the included -I option.
Adding -v to the command line might yield more interesting results in
tracking down the culprit header.
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9
On Thu, Jun 30, 2011 at 8:26 AM, Tim Gustafson t...@soe.ucsc.edu wrote: Hi, I've installed FreeBSD 9 on a new server because 8.2 doesn't have support for the LSI SAS2008 controller. I've also built the system as a ZFS-root box, and I have to say that I'm quite happy with the disk performance: we're getting about 500MB/s write and 675MB/s read. All in all, I'm very happy with FreeBSD 9. I have noticed two snafus that I thought I'd send to the group just as feedback: 1. net-snmp fails to compile with the following error: /bin/sh ../../libtool --mode=compile cc -I../../include -I. -I../../agent -I../../agent/mibgroup -I../../snmplib -I/usr/include -O2 -pipe -fno-strict-aliasing -Ufreebsd9 -Dfreebsd9=freebsd9 -c -o mibII/tcpTable.lo mibII/tcpTable.c libtool: compile: cc -I../../include -I. -I../../agent -I../../agent/mibgroup -I../../snmplib -I/usr/include -O2 -pipe -fno-strict-aliasing -Ufreebsd9 -Dfreebsd9=freebsd9 -c mibII/tcpTable.c -fPIC -DPIC -o mibII/.libs/tcpTable.o mibII/tcpTable.c:94: error: field 'pcb' has incomplete type mibII/tcpTable.c: In function 'tcpTable_load': mibII/tcpTable.c:866: error: dereferencing pointer to incomplete type mibII/tcpTable.c:868: error: dereferencing pointer to incomplete type mibII/tcpTable.c:868: error: invalid application of 'sizeof' to incomplete type 'struct xinpgen' mibII/tcpTable.c:872: error: dereferencing pointer to incomplete type mibII/tcpTable.c:876: error: dereferencing pointer to incomplete type mibII/tcpTable.c:877: error: invalid application of 'sizeof' to incomplete type 'struct inpcb' mibII/tcpTable.c:881: error: dereferencing pointer to incomplete type Someone already filed a PR for this ( http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/158266 ) and I'm working on cleaning up the autoconf tests to work properly for $WORK so we can upgrade to 5.6.1.1. The problem is caused by the recent netinet / net content shuffling and the fact that the autoconf tests for net-snmp are broken (and a number of includes on files). Unfortunately the upstream maintainers used a sledgehammer approach for all of the BSDs to detect how headers were supposed to be #include'd, and there's a lot of namespace pollution involved. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: AX88772A AX88772B chipset differences?
On Thu, Jun 30, 2011 at 02:44:48PM +0400, Andrey Smagin wrote: I have card based on AX88772B. I tried patch axe driver for vendor and device IDs. card detected, set up link, but no data received. What else need for patch in this driver ? Anybody have datasheet ? ASIX requires a login account to get the data sheet so it's not publicly available to open source developers. AFAIK the difference between AX88772A and AX88772B is IPv4/IPv6 checksum offloading support of AX88772B. The introduction of checksum offloading means they might have changed its RX header format which in turn makes current RX handler to not work. The other difference would be more advanced power saving used in AX8877B but it wouldn't be much difference to axe(4) driver once PHY is correctly woken in initialization phase. Could you show me your diff and verbose boot output to know PHY model and EEPROM data? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: isp(4) timeout
On Jun 30, 2011, at 3:25 AM, Anton Shterenlikht wrote: I see in my logs: isp0: Polled Mailbox Command (0x54) Timeout (50us) (started @ isp_plogx:2122) isp0: Mailbox Command 'EXECUTE IOCB A64' failed (TIMEOUT) This is most likely caused by a loss of interrupt handling. Be it masked interrupts or the inability to have the interrupt thread running. I have some important improvements in the pipeline that significantly improve stability. I'm doing a final test and then I'll commit. It may address the issue as a side-effect. FYI, -- Marcel Moolenaar mar...@xcllnt.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9
I think you need something along the line of ifconfig_bce0_alias0=inet 1.2.3.5 netmask ..., notice the 'inet', since aliasN can be used for both inet and inet6. Got it, thanks! I assume that's also recommended for the primary interface as well? I've added the inet prefix to both lines and it is working. Thanks! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafsont...@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9
On 2011-06-30 19:40, Tim Gustafson wrote: I think you need something along the line of ifconfig_bce0_alias0=inet 1.2.3.5 netmask ..., notice the 'inet', since aliasN can be used for both inet and inet6. Got it, thanks! I assume that's also recommended for the primary interface as well? I've added the inet prefix to both lines and it is working. Thanks! I don't know if it's recommended or not, there's a ifconfig_ifN_ipv6, at least in current, as well. But it definitely does not hurt. :) Glad to be able to help! -- Niclas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9
Someone already filed a PR for this ( http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/158266 ) and I'm working on cleaning up the autoconf tests to work properly for $WORK so we can upgrade to 5.6.1.1. The problem is caused by the recent netinet / net content shuffling and the fact that the autoconf tests for net-snmp are broken (and a number of includes on files). Unfortunately the upstream maintainers used a sledgehammer approach for all of the BSDs to detect how headers were supposed to be #include'd, and there's a lot of namespace pollution involved. Thanks! I've just installed the binary package for now which is working. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafsont...@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Opinion on using AMD Phenom II x6 1090t with Gigabyte 890BPA-UD3H and 8GB DDR-3 as a WebServer.
On 06/30/11 07:43, eculp wrote: Quoting Dennis Glatting d...@penx.com: On Wed, 2011-06-29 at 07:31 -0500, eculp wrote: I just saw this box that is being promoted as a gaming machine at a great price and am considering it as a web-server. In addition to having no information on the CPU as a server lack of comfort with 6 cores and memory 8GB of memory that I am having a problem with. I am not a gamer but I have always assumed that a gaming machine needs the most aggressive hardware. I have also seen this processor with 12 GB rather than 8 which, in my ignorance sounds better. Any opinions and guidance are appreciated. I have been moving away from Gigabyte however I do have a similar board: MB GIGABYTE GA-870A-UD3 RT This one is GA-890BPA-UD3G that also has RealTek 811D 10/100/1000 Mbit that I doubt will be a limitation. I'll stick in another card anyway. I also like that has is sata3 and usb 3 so it seems to be up to date. My key complaint about Gigabyte is the ReatTek Ethernet chips. Realtek doesn't publish chip specs and therefore the drivers under FreeBSD/Linux are so-so (i.e., they work but not performance optimized and forget about anything but the default MTU). On my board I hate the South Bridge chip, which is useless for RAID. I am also unable to install VMWare ESXi, my last ditch attempt to find a use for my board. There appears to be a hardware incompatibility while installing (i.e., not during the probe sequence, rather after that sequence then onto installation). Thanks a lot for your suggestions and point of view. I'm begining to think that this may be too much machine but comming down doesn't save much so I will probably give it a try. ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org A gaming machine needs aggressive hardware, yes, but no one *really* cares if it freezes up once a month. You get what you pay for mostly, so beware of RAM quality, disks, obscure and unfixed BIOS issues, power supply woes etc. I'd really recommend running disk redundancy if it's going to be a single webserver. I think the AMD Thubans can do ECC, right? Might be a good idea for reliability. Especially if you run /var/www on a malloc'd md disk. If you have a few of them in failover, these issues are a bit less, so long as they all don't break at once :). For what it's worth, I have a RealTek 8169 that works great on 9-current. Never had issues with performance or mtu. VLANs work fine. Transfer over CIFs is disk limited at 65mb/s. Will it be fine? Yes. Will it buildworld pretty fast? Yes. Could it leave you up a creek at 3 am 2 months after the 1 year warranty expires? Yes. Depends on expectations, of course. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FreeBSD is a summer course in Ain Shams University
Hello FreeBSDers, After the starting of FreeBSD handbook translation, ArabBSD could attract Ain Shams University which is one of the most important universities in Egypt and Arab World to offer Free Summer Course for FreeBSD Administration and FreeBSD development. The course will start by the July 10th. Tutorials about the Course will be uploaded. This course will be instructed by Mohammed Farrag, ArabBSD CEO and FreeBSD Contributor Regards, -- Mohammed * * ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Crossbuild failure on 8-stable
On Thursday 30 June 2011 18:59:04 Garrett Cooper wrote:
On Thu, Jun 30, 2011 at 9:14 AM, Mark Tinguely marktingu...@gmail.com
wrote:
On 6/30/2011 4:22 AM, Hans Petter Selasky wrote:
Hi,
Trying to cross build ARM fails in the following way on 8-stable:
8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011
make toolchain TARGET=arm
Is this perhaps also an issue in 9-current?
Any clues?
cc -O -pipe -ffreestanding -Wformat -I/usr/src/lib/libstand
-msoft-float -
D_STANDALONE -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -
I/usr/src/lib/libstand/../libz -std=gnu99 -c
/usr/src/lib/libstand/../libc/net/ntoh.c
{standard input}: Assembler messages:
{standard input}:27: Error: bad instruction `bswap r0'
{standard input}:53: Error: bad instruction `bswap r0'
and you also said:
Tracing down the issue:
/usr/include/machine/endian.h
#define __byte_swap_int_var(x) \
__extension__ ({ register __uint32_t __X = (x); \
__asm (bswap %0 : +r (__X)); \
__X; })
r0 looks like an ARM register passed to a non-arm assembler. I'm going
to
try:
Looks like you have an ARM compiler/assembler because the assembler
rejects the i386/amd64 bswap assembly command.
Does anyone remember if the cross compiler has the cross include paths
compiled into them or should there be a -I in the compile command to
correctly expand the #include machine/endian.h ? I thought the cross
path was compiled into the cross compiler.
You manually test the cc command with the included -I option.
Adding -v to the command line might yield more interesting results in
tracking down the culprit header.
-Garrett
I can add that:
make toolchains
succeeded.
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Crossbuild failure on 8-stable
Shouldn't that be 'make kernel-toolchain'?
Warner
On Jun 30, 2011, at 10:59 AM, Garrett Cooper wrote:
On Thu, Jun 30, 2011 at 9:14 AM, Mark Tinguely marktingu...@gmail.com wrote:
On 6/30/2011 4:22 AM, Hans Petter Selasky wrote:
Hi,
Trying to cross build ARM fails in the following way on 8-stable:
8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011
make toolchain TARGET=arm
Is this perhaps also an issue in 9-current?
Any clues?
cc -O -pipe -ffreestanding -Wformat -I/usr/src/lib/libstand -msoft-float
-
D_STANDALONE -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -
I/usr/src/lib/libstand/../libz -std=gnu99 -c
/usr/src/lib/libstand/../libc/net/ntoh.c
{standard input}: Assembler messages:
{standard input}:27: Error: bad instruction `bswap r0'
{standard input}:53: Error: bad instruction `bswap r0'
and you also said:
Tracing down the issue:
/usr/include/machine/endian.h
#define __byte_swap_int_var(x) \
__extension__ ({ register __uint32_t __X = (x); \
__asm (bswap %0 : +r (__X)); \
__X; })
r0 looks like an ARM register passed to a non-arm assembler. I'm going to
try:
Looks like you have an ARM compiler/assembler because the assembler rejects
the i386/amd64 bswap assembly command.
Does anyone remember if the cross compiler has the cross include paths
compiled into them or should there be a -I in the compile command to
correctly expand the #include machine/endian.h ? I thought the cross
path was compiled into the cross compiler.
You manually test the cc command with the included -I option.
Adding -v to the command line might yield more interesting results in
tracking down the culprit header.
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang buildworld failure due to multiple definitions of __isnanf
On Sun, Jun 26, 2011, Eric McCorkle wrote: I've both seen reports and experienced make buildworld with clang failing in usr.bin/xlint/lint1 (really, make kernel-toolchain is what fails), because lint1 is statically linked, and there is a definition of __isnanf in both libc and libm. GCC, on the other hand, builds just fine. The file tree.c in usr.bin/xlint/lint1 calls both isnan and finite from math.h. After some investigation, I figured out what's going on. math.h includes a macro version of isnan, which expands out to an expression that calls isnan, __isnanl, and __isnanf. GCC seems to treat all of these as builtin functions, and implements them with its code generator, rather than generating calls. Clang, on the other hand, does not, which leaves calls to __isnanf in the resulting object file, which will result in multiple definitions at link time. __isnanf is in both libraries for compatibility reasons. We can't remove it from libc because some historical programs that don't link against libm expect it to be there. We might be able to remove it from libm, but this would entail introducing a FBSD_1.2 version of the symbol in libc. Does your toolchain support symbol versioning? The libc symbol has version FBSD_1.0, while the libm version is FBSD_1.2. A better solution, I think, is to modify math.h with something like this: #ifdef __clang__ #define isnan(n) __builtin_isnan(n) ... #endif That breaks -fno-builtin, which is helpful sometimes (especially when the compiler builtins are bogus.) It also does nothing but paper over the problem... It would be nice to have a way to let the compiler use the builtin version of isnan() if -fbuiltin is enabled. The macro definitions are needed when the builtin is disabled or doesn't exist, but they have the unfortunate side-effect of preventing the builtin from being used at all, even when it is available. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on sparc64/sparc64
TB --- 2011-06-30 21:40:13 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-30 21:40:13 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-06-30 21:40:13 - cleaning the object tree TB --- 2011-06-30 21:40:31 - cvsupping the source tree TB --- 2011-06-30 21:40:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-06-30 21:40:45 - building world TB --- 2011-06-30 21:40:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-30 21:40:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-30 21:40:45 - TARGET=sparc64 TB --- 2011-06-30 21:40:45 - TARGET_ARCH=sparc64 TB --- 2011-06-30 21:40:45 - TZ=UTC TB --- 2011-06-30 21:40:45 - __MAKE_CONF=/dev/null TB --- 2011-06-30 21:40:45 - cd /src TB --- 2011-06-30 21:40:45 - /usr/bin/make -B buildworld World build started on Thu Jun 30 21:40:45 UTC 2011 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 -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/devopen.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/disk.c /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_openmbr': /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: 'LABELSECTOR' undeclared (first use in this function) /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: (Each undeclared identifier is reported only once /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: for each function it appears in.) /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_printbsdslice': /src/sys/boot/sparc64/loader/../../common/disk.c:376: error: 'LABELSECTOR' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/boot/sparc64/loader. *** Error code 1 Stop in /src/sys/boot/sparc64. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-30 22:34:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-30 22:34:42 - ERROR: failed to build world TB --- 2011-06-30 22:34:42 - 2453.42 user 603.88 system 3268.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on sparc64/sparc64
On Thu, Jun 30, 2011 at 3:34 PM, FreeBSD Tinderbox tinder...@freebsd.org wrote: TB --- 2011-06-30 21:40:13 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-30 21:40:13 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-06-30 21:40:13 - cleaning the object tree TB --- 2011-06-30 21:40:31 - cvsupping the source tree TB --- 2011-06-30 21:40:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-06-30 21:40:45 - building world TB --- 2011-06-30 21:40:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-30 21:40:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-30 21:40:45 - TARGET=sparc64 TB --- 2011-06-30 21:40:45 - TARGET_ARCH=sparc64 TB --- 2011-06-30 21:40:45 - TZ=UTC TB --- 2011-06-30 21:40:45 - __MAKE_CONF=/dev/null TB --- 2011-06-30 21:40:45 - cd /src TB --- 2011-06-30 21:40:45 - /usr/bin/make -B buildworld World build started on Thu Jun 30 21:40:45 UTC 2011 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 -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/devopen.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/disk.c /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_openmbr': /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: 'LABELSECTOR' undeclared (first use in this function) /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: (Each undeclared identifier is reported only once /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: for each function it appears in.) /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_printbsdslice': /src/sys/boot/sparc64/loader/../../common/disk.c:376: error: 'LABELSECTOR' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/boot/sparc64/loader. *** Error code 1 Stop in /src/sys/boot/sparc64. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 It looks like r223695 broke sparc64: $ grep -B 3 -r LABELSECTOR /usr/include/ /usr/include/sys/disklabel.h-/* XXX these should be defined per controller (or drive) elsewhere, not here! */ /usr/include/sys/disklabel.h-#if defined(__i386__) || defined(__amd64__) || defined(__arm__) || \ /usr/include/sys/disklabel.h-defined(__ia64__) || defined(__powerpc__) || defined(__mips__) /usr/include/sys/disklabel.h:#define LABELSECTOR1 /* sector containing label */ Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9
On 30.06.2011 21:40, Tim Gustafson wrote: I think you need something along the line of ifconfig_bce0_alias0=inet 1.2.3.5 netmask ..., notice the 'inet', since aliasN can be used for both inet and inet6. Got it, thanks! I assume that's also recommended for the primary interface as well? I've added the inet prefix to both lines and it is working. Thanks! There is also ipv4_addrs_IF variable, you can use it: ipv4_addrs_bce0=1.2.3.4/22 1.2.3.5/32 -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on sparc64/sparc64
TB --- 2011-07-01 03:30:49 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-01 03:30:49 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-01 03:30:49 - cleaning the object tree TB --- 2011-07-01 03:30:58 - cvsupping the source tree TB --- 2011-07-01 03:30:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-01 03:31:11 - building world TB --- 2011-07-01 03:31:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-01 03:31:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-01 03:31:11 - TARGET=sparc64 TB --- 2011-07-01 03:31:11 - TARGET_ARCH=sparc64 TB --- 2011-07-01 03:31:11 - TZ=UTC TB --- 2011-07-01 03:31:11 - __MAKE_CONF=/dev/null TB --- 2011-07-01 03:31:11 - cd /src TB --- 2011-07-01 03:31:11 - /usr/bin/make -B buildworld World build started on Fri Jul 1 03:31:12 UTC 2011 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 -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/devopen.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/disk.c /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_openmbr': /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: 'LABELSECTOR' undeclared (first use in this function) /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: (Each undeclared identifier is reported only once /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: for each function it appears in.) /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_printbsdslice': /src/sys/boot/sparc64/loader/../../common/disk.c:376: error: 'LABELSECTOR' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/boot/sparc64/loader. *** Error code 1 Stop in /src/sys/boot/sparc64. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-01 04:25:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-01 04:25:58 - ERROR: failed to build world TB --- 2011-07-01 04:25:58 - 2500.08 user 607.30 system 3308.72 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Thoughts on TMPFS no longer being considered highly experimental
Ugh - bonnie++ creates a file that is twice the size of available memory, and I have 16G of swap available. While ZFS already had most of the memory wired for ARC. I shouldn't be surprised that the box was printing swap zone exhausted I'm an idiot. Can we replace the warning message with one about dumb operators? ;) -- Sean Collins Core IT Pro, LLC www.coreitpro.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
