make clean failure on 10-stable amd64
Hi,
I get the following error in /usr/src when trying to upgrade my system.
In part of this process, I usually run make clean in /usr/src then go
on to running buildworld.
The installed system is 10.3-PRERELEASE #0 r294087
The sources I'm building from is 295045
Working Copy Root Path: /usr/src
URL: https://svn0.eu.freebsd.org/base/stable/10
Relative URL: ^/stable/10
Repository Root: https://svn0.eu.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 295045
Here is the error:
[...lots of output...]
rm -rf builddir
===> sys (clean)
===> sys/boot (clean)
===> sys/boot/ficl (clean)
rm -f softcore.c testmain testmain.o
rm -f a.out dict.o ficl.o fileaccess.o float.o loader.o math64.o
prefix.o search.o stack.o tools.o vm.o words.o sysdep.o softcore.o
dict.o.tmp ficl.o.tmp fileaccess.o.tmp float.o.tmp loader.o.tmp
math64.o.tmp prefix.o.tmp search.o.tmp stack.o.tmp tools.o.tmp
vm.o.tmp words.o.tmp sysdep.o.tmp softcore.o.tmp
rm -f libficl.a
===> sys/boot/forth (clean)
rm -f beastie.4th.8.gz brand.4th.8.gz check-password.4th.8.gz
color.4th.8.gz delay.4th.8.gz loader.conf.5.gz loader.4th.8.gz
menu.4th.8.gz menusets.4th.8.gz version.4th.8.gz beastie.4th.8.cat.gz
brand.4th.8.cat.gz check-password.4th.8.cat.gz color.4th.8.cat.gz
delay.4th.8.cat.gz loader.conf.5.cat.gz loader.4th.8.cat.gz
menu.4th.8.cat.gz menusets.4th.8.cat.gz version.4th.8.cat.gz
===> sys/boot/efi (clean)
make[4]: "/usr/src/sys/boot/efi/Makefile" line 4: Malformed
conditional (${COMPILER_TYPE} != "gcc")
make[4]: Fatal errors encountered -- cannot continue
make[4]: stopped in /usr/src/sys/boot/efi
*** Error code 1
Stop.
make[3]: stopped in /usr/src/sys/boot
*** Error code 1
Stop.
make[2]: stopped in /usr/src/sys
*** Error code 1
Stop.
make[1]: stopped in /usr/src
*** Error code 1
Stop.
make: stopped in /usr/src
many thanks,
--
John
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
make clean failure on 10-stable amd64]
Hi,
I get the following error in /usr/src when trying to upgrade my system.
In part of this process, I usually run make clean in /usr/src then go
on to running buildworld.
The installed system is 10.3-PRERELEASE #0 r294087
The sources I'm building from is 295045
Working Copy Root Path: /usr/src
URL: https://svn0.eu.freebsd.org/base/stable/10
Relative URL: ^/stable/10
Repository Root: https://svn0.eu.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 295045
Here is the error:
[...lots of output...]
rm -rf builddir
===> sys (clean)
===> sys/boot (clean)
===> sys/boot/ficl (clean)
rm -f softcore.c testmain testmain.o
rm -f a.out dict.o ficl.o fileaccess.o float.o loader.o math64.o
prefix.o search.o stack.o tools.o vm.o words.o sysdep.o softcore.o
dict.o.tmp ficl.o.tmp fileaccess.o.tmp float.o.tmp loader.o.tmp
math64.o.tmp prefix.o.tmp search.o.tmp stack.o.tmp tools.o.tmp
vm.o.tmp words.o.tmp sysdep.o.tmp softcore.o.tmp rm -f libficl.a
===> sys/boot/forth (clean)
rm -f beastie.4th.8.gz brand.4th.8.gz check-password.4th.8.gz
color.4th.8.gz delay.4th.8.gz loader.conf.5.gz loader.4th.8.gz
menu.4th.8.gz menusets.4th.8.gz version.4th.8.gz beastie.4th.8.cat.gz
brand.4th.8.cat.gz check-password.4th.8.cat.gz color.4th.8.cat.gz
delay.4th.8.cat.gz loader.conf.5.cat.gz loader.4th.8.cat.gz
menu.4th.8.cat.gz menusets.4th.8.cat.gz version.4th.8.cat.gz
===> sys/boot/efi (clean)
make[4]: "/usr/src/sys/boot/efi/Makefile" line 4: Malformed
conditional (${COMPILER_TYPE} != "gcc")
make[4]: Fatal errors encountered -- cannot continue
make[4]: stopped in /usr/src/sys/boot/efi
*** Error code 1
Stop.
make[3]: stopped in /usr/src/sys/boot
*** Error code 1
Stop.
make[2]: stopped in /usr/src/sys
*** Error code 1
Stop.
make[1]: stopped in /usr/src
*** Error code 1
Stop.
make: stopped in /usr/src
many thanks,
--
John
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: make clean failure on 10-stable amd64
On Fri, Jan 29, 2016 at 05:40:05PM +, John wrote: > Hi, > > I get the following error in /usr/src when trying to upgrade my system. > In part of this process, I usually run make clean in /usr/src then go > on to running buildworld. > > The installed system is 10.3-PRERELEASE #0 r294087 > The sources I'm building from is 295045 > You'll probably want to follow-up, specifying: * Contents (if any) of /etc/src.conf * Contents (if any) of /etc/make.conf * The full path of the "make" executable you're using. Peace, david -- David H. Wolfskill da...@catwhisker.org Those who would murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: make clean failure on 10-stable amd64]
CC'd smh, who committed an update recently in this file. I have
confirmed the failure (but do not understand why I did not see it when
testing the patch...).
Steven, can you please take a look at this?
Glen
On Fri, Jan 29, 2016 at 05:42:10PM +, John wrote:
> Hi,
>
> I get the following error in /usr/src when trying to upgrade my system.
> In part of this process, I usually run make clean in /usr/src then go
> on to running buildworld.
>
> The installed system is 10.3-PRERELEASE #0 r294087
> The sources I'm building from is 295045
>
> Working Copy Root Path: /usr/src
> URL: https://svn0.eu.freebsd.org/base/stable/10
> Relative URL: ^/stable/10
> Repository Root: https://svn0.eu.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 295045
>
> Here is the error:
>
> [...lots of output...]
>
> rm -rf builddir
> ===> sys (clean)
> ===> sys/boot (clean)
> ===> sys/boot/ficl (clean)
> rm -f softcore.c testmain testmain.o
> rm -f a.out dict.o ficl.o fileaccess.o float.o loader.o math64.o
> prefix.o search.o stack.o tools.o vm.o words.o sysdep.o softcore.o
> dict.o.tmp ficl.o.tmp fileaccess.o.tmp float.o.tmp loader.o.tmp
> math64.o.tmp prefix.o.tmp search.o.tmp stack.o.tmp tools.o.tmp
> vm.o.tmp words.o.tmp sysdep.o.tmp softcore.o.tmp rm -f libficl.a
> ===> sys/boot/forth (clean)
> rm -f beastie.4th.8.gz brand.4th.8.gz check-password.4th.8.gz
> color.4th.8.gz delay.4th.8.gz loader.conf.5.gz loader.4th.8.gz
> menu.4th.8.gz menusets.4th.8.gz version.4th.8.gz beastie.4th.8.cat.gz
> brand.4th.8.cat.gz check-password.4th.8.cat.gz color.4th.8.cat.gz
> delay.4th.8.cat.gz loader.conf.5.cat.gz loader.4th.8.cat.gz
> menu.4th.8.cat.gz menusets.4th.8.cat.gz version.4th.8.cat.gz
> ===> sys/boot/efi (clean)
> make[4]: "/usr/src/sys/boot/efi/Makefile" line 4: Malformed
> conditional (${COMPILER_TYPE} != "gcc")
> make[4]: Fatal errors encountered -- cannot continue
> make[4]: stopped in /usr/src/sys/boot/efi
> *** Error code 1
>
> Stop.
> make[3]: stopped in /usr/src/sys/boot
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/src/sys
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make: stopped in /usr/src
>
> many thanks,
> --
> John
>
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
signature.asc
Description: PGP signature
Re: make clean failure on 10-stable amd64]
Investigating, strangely enough this builds and cleans just fine from
buildenv.
On 29/01/2016 17:47, Glen Barber wrote:
CC'd smh, who committed an update recently in this file. I have
confirmed the failure (but do not understand why I did not see it when
testing the patch...).
Steven, can you please take a look at this?
Glen
On Fri, Jan 29, 2016 at 05:42:10PM +, John wrote:
Hi,
I get the following error in /usr/src when trying to upgrade my system.
In part of this process, I usually run make clean in /usr/src then go
on to running buildworld.
The installed system is 10.3-PRERELEASE #0 r294087
The sources I'm building from is 295045
Working Copy Root Path: /usr/src
URL: https://svn0.eu.freebsd.org/base/stable/10
Relative URL: ^/stable/10
Repository Root: https://svn0.eu.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 295045
Here is the error:
[...lots of output...]
rm -rf builddir
===> sys (clean)
===> sys/boot (clean)
===> sys/boot/ficl (clean)
rm -f softcore.c testmain testmain.o
rm -f a.out dict.o ficl.o fileaccess.o float.o loader.o math64.o
prefix.o search.o stack.o tools.o vm.o words.o sysdep.o softcore.o
dict.o.tmp ficl.o.tmp fileaccess.o.tmp float.o.tmp loader.o.tmp
math64.o.tmp prefix.o.tmp search.o.tmp stack.o.tmp tools.o.tmp
vm.o.tmp words.o.tmp sysdep.o.tmp softcore.o.tmp rm -f libficl.a
===> sys/boot/forth (clean)
rm -f beastie.4th.8.gz brand.4th.8.gz check-password.4th.8.gz
color.4th.8.gz delay.4th.8.gz loader.conf.5.gz loader.4th.8.gz
menu.4th.8.gz menusets.4th.8.gz version.4th.8.gz beastie.4th.8.cat.gz
brand.4th.8.cat.gz check-password.4th.8.cat.gz color.4th.8.cat.gz
delay.4th.8.cat.gz loader.conf.5.cat.gz loader.4th.8.cat.gz
menu.4th.8.cat.gz menusets.4th.8.cat.gz version.4th.8.cat.gz
===> sys/boot/efi (clean)
make[4]: "/usr/src/sys/boot/efi/Makefile" line 4: Malformed
conditional (${COMPILER_TYPE} != "gcc")
make[4]: Fatal errors encountered -- cannot continue
make[4]: stopped in /usr/src/sys/boot/efi
*** Error code 1
Stop.
make[3]: stopped in /usr/src/sys/boot
*** Error code 1
Stop.
make[2]: stopped in /usr/src/sys
*** Error code 1
Stop.
make[1]: stopped in /usr/src
*** Error code 1
Stop.
make: stopped in /usr/src
many thanks,
--
John
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap
On 1/27/2016 5:31 PM, Marius Strobl wrote: > Author: marius > Date: Wed Jan 27 22:31:08 2016 > New Revision: 294958 > URL: https://svnweb.freebsd.org/changeset/base/294958 > > Log: > Sync the e1000 drivers with what's in head as of r294327, modulo parts > that don't apply to stable/10 (driver API, if_inc_counter(), RSS changes Hi, I am seeing some timeouts since upgrading to this rev. I am running r295008, i386. onboard NIC Manufacturer: Supermicro Product Name: PDSMi em0: Watchdog timeout Queue[0]-- resetting Interface is RUNNING and ACTIVE em0: TX Queue 0 -- em0: hw tdh = 946, hw tdt = 159 em0: Tx Queue Status = -2147483648 em0: TX descriptors avail = 786 em0: Tx Descriptors avail failure = 0 em0: RX Queue 0 -- em0: hw rdh = 401, hw rdt = 400 em0: RX discarded packets = 0 em0: RX Next to Check = 401 em0: RX Next to Refresh = 400 em0: link state changed to DOWN em0: link state changed to UP em0: Watchdog timeout Queue[0]-- resetting Interface is RUNNING and ACTIVE em0: TX Queue 0 -- em0: hw tdh = 87, hw tdt = 378 em0: Tx Queue Status = -2147483648 em0: TX descriptors avail = 720 em0: Tx Descriptors avail failure = 0 em0: RX Queue 0 -- em0: hw rdh = 740, hw rdt = 739 em0: RX discarded packets = 0 em0: RX Next to Check = 741 em0: RX Next to Refresh = 740 em0: link state changed to DOWN em0: link state changed to UP Limiting open port RST response from 292 to 200 packets/sec em0: Watchdog timeout Queue[0]-- resetting Interface is RUNNING and ACTIVE em0: TX Queue 0 -- em0: hw tdh = 611, hw tdt = 840 em0: Tx Queue Status = -2147483648 em0: TX descriptors avail = 773 em0: Tx Descriptors avail failure = 0 em0: RX Queue 0 -- em0: hw rdh = 660, hw rdt = 659 em0: RX discarded packets = 0 em0: RX Next to Check = 660 em0: RX Next to Refresh = 659 em0: link state changed to DOWN em0: link state changed to UP # pciconf -lBvcb em0 em0@pci0:13:0:0:class=0x02 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xe8a0, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x5000, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) RO NS link x1(x1) speed 2.5(2.5) ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] = Serial 1 0030489c59f0 -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[no subject]
Bcc: Subject: Re: make clean failure on 10-stable amd64 Reply-To: j...@potato.growveg.org In-Reply-To: <20160129174514.gj1...@albert.catwhisker.org> On Fri, Jan 29, 2016 at 09:45:14AM -0800, David Wolfskill wrote: On Fri, Jan 29, 2016 at 05:40:05PM +, John wrote: Hi, I get the following error in /usr/src when trying to upgrade my system. In part of this process, I usually run make clean in /usr/src then go on to running buildworld. The installed system is 10.3-PRERELEASE #0 r294087 The sources I'm building from is 295045 You'll probably want to follow-up, specifying: * Contents (if any) of /etc/src.conf * Contents (if any) of /etc/make.conf * The full path of the "make" executable you're using. root@potato:/usr/src # less /etc/make.conf MAKE_JOBS_NUMBER=6 #WITH_CCACHE_BUILD=yes root@potato:/usr/src # less /etc/src.conf /etc/src.conf: No such file or directory root@potato:/usr/src # root@potato:/usr/src # which make /usr/bin/make root@potato:/usr/src # make -V MAKE_VERSION 20151220 root@potato:/usr/src # thanks, -- John ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: make clean failure on 10-stable amd64]
On Fri, Jan 29, 2016 at 05:47:46PM +, Glen Barber wrote:
> CC'd smh, who committed an update recently in this file. I have
> confirmed the failure (but do not understand why I did not see it when
> testing the patch...).
>
> Steven, can you please take a look at this?
>
John, can you please try the attached patch?
Glen
Index: sys/boot/efi/Makefile
===
--- sys/boot/efi/Makefile (revision 295049)
+++ sys/boot/efi/Makefile (working copy)
@@ -1,5 +1,7 @@
# $FreeBSD$
+.include
+
# In-tree GCC does not support __attribute__((ms_abi)).
.if ${COMPILER_TYPE} != "gcc"
signature.asc
Description: PGP signature
Re: make clean failure on 10-stable amd64]
On Fri, Jan 29, 2016 at 06:10:26PM +, Glen Barber wrote:
On Fri, Jan 29, 2016 at 05:47:46PM +, Glen Barber wrote:
CC'd smh, who committed an update recently in this file. I have
confirmed the failure (but do not understand why I did not see it when
testing the patch...).
Steven, can you please take a look at this?
John, can you please try the attached patch?
Glen
Index: sys/boot/efi/Makefile
===
--- sys/boot/efi/Makefile (revision 295049)
+++ sys/boot/efi/Makefile (working copy)
@@ -1,5 +1,7 @@
# $FreeBSD$
+.include
+
# In-tree GCC does not support __attribute__((ms_abi)).
.if ${COMPILER_TYPE} != "gcc"
yay! that works
many thanks,
--
John
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap
Bezüglich Mike Tancsa's Nachricht vom 29.01.2016 19:08 (localtime): > On 1/27/2016 5:31 PM, Marius Strobl wrote: >> Author: marius >> Date: Wed Jan 27 22:31:08 2016 >> New Revision: 294958 >> URL: https://svnweb.freebsd.org/changeset/base/294958 >> >> Log: >> Sync the e1000 drivers with what's in head as of r294327, modulo parts >> that don't apply to stable/10 (driver API, if_inc_counter(), RSS changes > > Hi, > I am seeing some timeouts since upgrading to this rev. I am running > r295008, i386. onboard NIC > > Manufacturer: Supermicro > Product Name: PDSMi > > > em0: Watchdog timeout Queue[0]-- resetting > Interface is RUNNING and ACTIVE > em0: TX Queue 0 -- > em0: hw tdh = 946, hw tdt = 159 > em0: Tx Queue Status = -2147483648 > em0: TX descriptors avail = 786 > em0: Tx Descriptors avail failure = 0 > em0: RX Queue 0 -- > em0: hw rdh = 401, hw rdt = 400 > em0: RX discarded packets = 0 > em0: RX Next to Check = 401 > em0: RX Next to Refresh = 400 > em0: link state changed to DOWN > em0: link state changed to UP > em0: Watchdog timeout Queue[0]-- resetting > Interface is RUNNING and ACTIVE > em0: TX Queue 0 -- > em0: hw tdh = 87, hw tdt = 378 > em0: Tx Queue Status = -2147483648 > em0: TX descriptors avail = 720 > em0: Tx Descriptors avail failure = 0 > em0: RX Queue 0 -- > em0: hw rdh = 740, hw rdt = 739 > em0: RX discarded packets = 0 > em0: RX Next to Check = 741 > em0: RX Next to Refresh = 740 > em0: link state changed to DOWN > em0: link state changed to UP > Limiting open port RST response from 292 to 200 packets/sec > em0: Watchdog timeout Queue[0]-- resetting > Interface is RUNNING and ACTIVE > em0: TX Queue 0 -- > em0: hw tdh = 611, hw tdt = 840 > em0: Tx Queue Status = -2147483648 > em0: TX descriptors avail = 773 > em0: Tx Descriptors avail failure = 0 > em0: RX Queue 0 -- > em0: hw rdh = 660, hw rdt = 659 > em0: RX discarded packets = 0 > em0: RX Next to Check = 660 > em0: RX Next to Refresh = 659 > em0: link state changed to DOWN > em0: link state changed to UP > > > > # pciconf -lBvcb em0 > em0@pci0:13:0:0:class=0x02 card=0x108c15d9 chip=0x108c8086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82573E Gigabit Ethernet Controller (Copper)' I guess you haven't compiled the kernel with EM_MULTIQUEUE. I can't remember if 82573 is supposed to be able to handle 2 queues. I couldn't help solving your problem anyways, but I found default number of rx/tx descriptors somewhen increased from 1024 to 4096 for my 82574. What does hw.em.txd read with your 82573? Before my EM-MULTIQUEUE problem vanished, reducing hw.em.txd (and rxd) to 256 relaxed the timeout problem a lot. Seems your interface is recovering after watchdog-reset? Mine stayed unusable unitl I triggered ifconfig down/up. Have you checked if disabling TSO changes anything? Probably checking if hw.em.enable_msix changes symptoms could also narrow down the root cause. Hope your problem also vanishes soon :-) -Harry ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)
On 1/29/2016 1:42 PM, Harry Schmalzbauer wrote: >> # pciconf -lBvcb em0 >> em0@pci0:13:0:0:class=0x02 card=0x108c15d9 chip=0x108c8086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82573E Gigabit Ethernet Controller (Copper)' > > I guess you haven't compiled the kernel with EM_MULTIQUEUE. I can't > remember if 82573 is supposed to be able to handle 2 queues. I couldn't > help solving your problem anyways, but I found default number of rx/tx > descriptors somewhen increased from 1024 to 4096 for my 82574. > What does hw.em.txd read with your 82573? > Before my EM-MULTIQUEUE problem vanished, reducing hw.em.txd (and rxd) > to 256 relaxed the timeout problem a lot. > Seems your interface is recovering after watchdog-reset? Mine stayed > unusable unitl I triggered ifconfig down/up. > Have you checked if disabling TSO changes anything? > Probably checking if hw.em.enable_msix changes symptoms could also > narrow down the root cause. > No multi queue. Stock GENERIC kernel with a couple of things removed. hw.em are just the defaults. I will try without TSO % ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=4209b 21,22c21,22 < cpu I486_CPU < cpu I586_CPU --- > #cpu I486_CPU > #cpu I586_CPU 24c24 < ident GENERIC --- > ident vinyl 34c34 < options SCTP# Stream Control Transmission Protocol --- > #options SCTP# Stream Control Transmission Protocol 375a376,383 > > device pf > device pflog > options QUOTA > > options ACCEPT_FILTER_HTTP > options ACCEPT_FILTER_DATA > % sysctl -a dev.em.0 dev.em.0.interrupts.rx_overrun: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.tx_queue_min_thresh: 2 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_abs_timer: 371 dev.em.0.interrupts.tx_pkt_timer: 359 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.rx_pkt_timer: 299 dev.em.0.interrupts.asserts: 9741226 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.mac_stats.tso_txd: 854147 dev.em.0.mac_stats.tx_frames_1024_1522: 4927464 dev.em.0.mac_stats.tx_frames_512_1023: 127639 dev.em.0.mac_stats.tx_frames_256_511: 1116852 dev.em.0.mac_stats.tx_frames_128_255: 133036 dev.em.0.mac_stats.tx_frames_65_127: 4915970 dev.em.0.mac_stats.tx_frames_64: 110245 dev.em.0.mac_stats.mcast_pkts_txd: 10 dev.em.0.mac_stats.bcast_pkts_txd: 17 dev.em.0.mac_stats.good_pkts_txd: 11331206 dev.em.0.mac_stats.total_pkts_txd: 11331206 dev.em.0.mac_stats.good_octets_txd: 8363930804 dev.em.0.mac_stats.good_octets_recvd: 2034174419 dev.em.0.mac_stats.rx_frames_1024_1522: 773394 dev.em.0.mac_stats.rx_frames_512_1023: 113644 dev.em.0.mac_stats.rx_frames_256_511: 1702858 dev.em.0.mac_stats.rx_frames_128_255: 78132 dev.em.0.mac_stats.rx_frames_65_127: 4889577 dev.em.0.mac_stats.rx_frames_64: 1334131 dev.em.0.mac_stats.mcast_pkts_recvd: 0 dev.em.0.mac_stats.bcast_pkts_recvd: 26788 dev.em.0.mac_stats.good_pkts_recvd: 8891736 dev.em.0.mac_stats.total_pkts_recvd: 8891736 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.missed_packets: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.queue_rx_0.rx_irq: 0 dev.em.0.queue_rx_0.rxd_tail: 76 dev.em.0.queue_rx_0.rxd_head: 77 dev.em.0.queue_tx_0.no_desc_avail: 0 dev.em.0.queue_tx_0.tx_irq: 0 dev.em.0.queue_tx_0.txd_tail: 493 dev.em.0.queue_tx_0.txd_head: 493 dev.em.0.fc_low_water: 8740 dev.em.0.fc_high_water: 10240 dev.em.0.rx_control: 67141634 dev.em.0.device_control: 1075053128 dev.em.0.watchdog_timeouts: 3 dev.em.0.rx_overruns: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.mbuf_defrag_fail: 0 dev.em.0.link_irq: 0 dev.em.0.dropped: 0 dev.em.0.eee_control: 1 dev.em.0.rx_processing_limit: 100 dev.em.0.itr: 488 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_int_delay: 66 dev.em.0.rx_int_delay: 0 dev.em.0.fc: 3 dev.em.0.debug: -1 dev.em.0.nvm: -1 dev.em.0.%parent: pci13 dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x02 dev.em.0.%location: slot=0 function=0 dev.em.0.%driver: em dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.4.2 % sysctl -A hw.em hw.em.eee_setting: 1 hw.em.rx_process_limit: 100 hw.em.enable_msix: 1 hw.em.sbp: 0 hw.em.smart_pwr_down: 0 hw.em.txd: 1024 hw.em.rxd: 1024 hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66
Re: ia64 10-stable about r292594: rescue crunchide *.lo unknown executable format
On Wednesday, January 27, 2016 12:32:39 AM Anton Shterenlikht wrote: > I asked about this already in stable@ and ia64@. > Got no reply. Perhaps ia64 has been abandoned in > 10-stable too? If so, I'd like to know. > > If not, I'm getting: > > # pwd > /usr/obj/usr/src/rescue/rescue > # crunchide -k _crunched_chio_stub cat.lo > cat.lo: unknown executable format > # crunchide -k _crunched_chio_stub chflags.lo > chflags.lo: unknown executable format > # crunchide -k _crunched_chio_stub chio.lo > chio.lo: unknown executable format > # file *lo > cat.lo: ELF 64-bit LSB relocatable, IA-64, version 1 (FreeBSD), not > stripped > chflags.lo: ELF 64-bit LSB relocatable, IA-64, version 1 (FreeBSD), not > stripped > chio.lo:ELF 64-bit LSB relocatable, IA-64, version 1 (FreeBSD), not > stripped > # file /usr/bin/crunchide > /usr/bin/crunchide: ELF 64-bit LSB executable, IA-64, version 1 (FreeBSD), > dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 10.2 > (1002504), stripped > # > > This is on 10.2-STABLE #20 r292594. > > I tried to buildworld up to r294823, > and back to r291000, all with the same > error. I cannot even build the same > revision as the one I'm running now. > > I've deleted /usr/obj completely,- still > the same. > > Please advise > > Thanks While ia64 is mostly abandoned, this build failure was fixed a few weeks ago: r292885 | emaste | 2015-12-29 12:36:11 -0800 (Tue, 29 Dec 2015) | 4 lines crunchide: Restore IA-64 support accidentally lost in r292421 mismerge Reported by:ngie -- John Baldwin ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)
On Fri, Jan 29, 2016 at 03:41:57PM -0500, Mike Tancsa wrote: > > No multi queue. Stock GENERIC kernel with a couple of things removed. > hw.em are just the defaults. I will try without TSO > > % ifconfig em0 > em0: flags=8843 metric 0 mtu 1500 > > options=4209b > Hrm, that's strange, TSO4 should be enabled by default so apparently you are already disabling it; what is the behavior if you turn it on? Do you use a < Gigabit link? Marius ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: make clean failure on 10-stable amd64]
On 29/01/2016 18:24, John wrote:
On Fri, Jan 29, 2016 at 06:10:26PM +, Glen Barber wrote:
On Fri, Jan 29, 2016 at 05:47:46PM +, Glen Barber wrote:
CC'd smh, who committed an update recently in this file. I have
confirmed the failure (but do not understand why I did not see it when
testing the patch...).
Steven, can you please take a look at this?
John, can you please try the attached patch?
Glen
Index: sys/boot/efi/Makefile
===
--- sys/boot/efi/Makefile(revision 295049)
+++ sys/boot/efi/Makefile(working copy)
@@ -1,5 +1,7 @@
# $FreeBSD$
+.include
+
# In-tree GCC does not support __attribute__((ms_abi)).
.if ${COMPILER_TYPE} != "gcc"
yay! that works
many thanks,
Thanks for initial report John, this is now fixed as of: r295057
Regards
Steve
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
