Re: Turning TESTS on by default

[Konstantin Belousov]

On Sat, Jun 07, 2014 at 12:31:01PM -0600, Alan Somers wrote:
> On Fri, Jun 6, 2014 at 9:33 PM, Konstantin Belousov  
> wrote:
> > On Fri, Jun 06, 2014 at 03:14:52PM -0400, Julio Merino wrote:
> >> Hello all,
> >>
> >>
> >> TL;DR
> >> -
> >>
> >> I plan to turn the TESTS src.conf knob ON by default on Tuesday once I
> >> have been able to perform enough sanity-checks of the build and all of
> >> them pass.
> >>
> >> The impact of this is that the FreeBSD Test Suite (see tests(7)) will
> >> be built and installed by default under /usr/tests/ along with the
> >> private atf libraries and binaries. There should be no other changes
> >> and this should be transparent to everyone.
> >>
> >> If this happens to break the world in any way, we can trivially roll
> >> the change back to fix the fallout.
> >>
> >>
> >> Some details
> >> 
> >>
> >> TESTS was never intended to be disabled by default. However, the
> >> original patches that were committed months ago related to this
> >> feature broke the build and the easiest way out (instead of reverting
> >> the commits) was to set the knob to disabled. Unfortunately, it stayed
> >> that way even after the discovered problems were fixed.
> >>
> >> I am confident enough now that we have ironed out all major issues
> >> that this might introduce, so it is about time to enable TESTS by
> >> default again in HEAD.
> >>
> >> The benefits of this are that 1) we allow end users (especially
> >> consumers of binary releases!) to run the tests out of the box, as it
> >> has always been intended; and 2) we will be able to run the official
> >> release builds through testing via Jenkins, instead of having to issue
> >> custom builds.
> > This is very weird and unprobable.  Users cannot care less about running
> > the test suite, they use OS to run applications.  IMO enabling installation
> > of the stuff that bloats the system but have no practical use for the
> > system consumer should not be allowed by default.
> 
> I disagree.  Sure, some users won't care.  Probably even most users
> won't care.  But some of our users are active supporters of FreeBSD.
> They evangelize, they file PRs, and they help other users on the
> forums.  Those users will run the tests.  Some of them will find bugs
> that we didn't, because they'll be using different hardware and
> different configurations.  Plus, shipping a test suite exudes an aura
> of quality (if the tests pass, that is).  So I think that we should
> install the tests, but in a separate installation set, just like
> games.

I would agree with your arguments, and in fact not bother with the
proposal at all, if most systems were installed using installer.  I am
very much confident that significant part of the population is installed
or updated using make build/installworld.

If somebody cares to run tests, she certainly cares enough to be able to
turn the knob on.  Otherwise, the tests take sometimes precious space on /
or /usr, for nothing.

Could somebody point out a popular software system that spills the
tests or other developer-only[*] stuff into the production install ? I
immediately remember the perl and its modules which have very extensive
test suite, but the test suite is not installed.

[*] As is, developers of the system, not developers utilizing the product
as the base.


pgpxZPyer6WX4.pgp
Description: PGP signature

Re: Turning TESTS on by default

[Alan Somers]

On Fri, Jun 6, 2014 at 9:33 PM, Konstantin Belousov  wrote:
> On Fri, Jun 06, 2014 at 03:14:52PM -0400, Julio Merino wrote:
>> Hello all,
>>
>>
>> TL;DR
>> -
>>
>> I plan to turn the TESTS src.conf knob ON by default on Tuesday once I
>> have been able to perform enough sanity-checks of the build and all of
>> them pass.
>>
>> The impact of this is that the FreeBSD Test Suite (see tests(7)) will
>> be built and installed by default under /usr/tests/ along with the
>> private atf libraries and binaries. There should be no other changes
>> and this should be transparent to everyone.
>>
>> If this happens to break the world in any way, we can trivially roll
>> the change back to fix the fallout.
>>
>>
>> Some details
>> 
>>
>> TESTS was never intended to be disabled by default. However, the
>> original patches that were committed months ago related to this
>> feature broke the build and the easiest way out (instead of reverting
>> the commits) was to set the knob to disabled. Unfortunately, it stayed
>> that way even after the discovered problems were fixed.
>>
>> I am confident enough now that we have ironed out all major issues
>> that this might introduce, so it is about time to enable TESTS by
>> default again in HEAD.
>>
>> The benefits of this are that 1) we allow end users (especially
>> consumers of binary releases!) to run the tests out of the box, as it
>> has always been intended; and 2) we will be able to run the official
>> release builds through testing via Jenkins, instead of having to issue
>> custom builds.
> This is very weird and unprobable.  Users cannot care less about running
> the test suite, they use OS to run applications.  IMO enabling installation
> of the stuff that bloats the system but have no practical use for the
> system consumer should not be allowed by default.

I disagree.  Sure, some users won't care.  Probably even most users
won't care.  But some of our users are active supporters of FreeBSD.
They evangelize, they file PRs, and they help other users on the
forums.  Those users will run the tests.  Some of them will find bugs
that we didn't, because they'll be using different hardware and
different configurations.  Plus, shipping a test suite exudes an aura
of quality (if the tests pass, that is).  So I think that we should
install the tests, but in a separate installation set, just like
games.

-Alan

>
> It is the same as the debugging kernel. The INVARIANTS, WITNESS, DEBUG
> and DIAGNOSTIC options are not enabled for the user consumption. There
> was a similar argument to disable compiling the profiling static
> libraries, which probably should be reconsidered since lib*_p.a is
> absolutely useless on current toolchain and hardware.
>
>>
>> Actual change: https://phabric.freebsd.org/D188
>>
>>
>> I will update this thread when the change is committed and/or with any 
>> updates.
>>
>> Please let me know if I'm missing anything.
>>
>> Cheers
>> ___
>> 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: wlan0/iwn: no upload statistics

[bycn82]

Hi,

1. I checked the source code of systat, it actually read from the mibdata, so 
the result should be the same as sysctl. 

2. According to David's email, seems the netstat can show the correct output 
octets. 

Sorry I don’t have wireless network interface on my testing environment, but I 
noticed that the mibdta structure was changed recently,  


Best Regards,
bycn82




> -Original Message-
> From: Stefan Ehmann [mailto:shoes...@gmx.net]
> Sent: 07 June, 2014 21:33
> To: bycn82; freebsd-current@freebsd.org
> Subject: Re: wlan0/iwn: no upload statistics
> 
> On 07.06.2014 14:39, bycn82 wrote:
> > Hi,
> 
> Seem it was not clear in my original post: Only the wireless interface
> is affected. lo0 shows upload stats.
> 
> > More information is required. Please provide the output of the two
> > commands below
> >
> > 1.   sysctl -a | grep octets
> 
> iwn0/wlan0 don't appear here:
> dev.em.0.mac_stats.good_octets_recvd: 0
> dev.em.0.mac_stats.good_octets_txd: 0
> 
> 
> > 2.   uname -a
> FreeBSD tomorrow.pepperland 11.0-CURRENT FreeBSD 11.0-CURRENT #8
> r267126: Fri Jun  6 06:14:13 CEST 2014
> stefan@tomorrow.pepperland:/usr/obj/usr/src/sys/TOMORROW  amd64

___
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: wlan0/iwn: no upload statistics

[Stefan Ehmann]

On 07.06.2014 14:39, bycn82 wrote:
> Hi,

Seem it was not clear in my original post: Only the wireless interface
is affected. lo0 shows upload stats.

> More information is required. Please provide the output of the two commands 
> below
> 
> 1. sysctl -a | grep octets

iwn0/wlan0 don't appear here:
dev.em.0.mac_stats.good_octets_recvd: 0
dev.em.0.mac_stats.good_octets_txd: 0


> 2. uname -a
FreeBSD tomorrow.pepperland 11.0-CURRENT FreeBSD 11.0-CURRENT #8
r267126: Fri Jun  6 06:14:13 CEST 2014
stefan@tomorrow.pepperland:/usr/obj/usr/src/sys/TOMORROW  amd64
___
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: wlan0/iwn: no upload statistics

[David Wolfskill]

On Sat, Jun 07, 2014 at 08:39:10PM +0800, bycn82 wrote:
> Hi,
> 
> More information is required. Please provide the output of the two commands 
> below
> 
> 1. sysctl -a | grep octets
> 2. uname -a
> ...

I'm not the OP, but I do (sometimes) run head, and have an iwn(4) NIC on
my laptop, so I checked: I was able to reproduce the cited symptoms:


/0   /1   /2   /3   /4   /5   /6   /7   /8   /9   /10
 Load Average    

  Interface   Traffic   PeakTotal
  wlan0  in  0.400 KB/s 23.553 KB/s1.529 MB
 out 0.000 KB/s  0.000 KB/s0.000 KB


As a reality check:

g1-252(11.0-C)[4] date ; netstat -nibf inet ; sleep 10 ; date ; netstat -nibf 
inet
Sat Jun  7 05:47:02 PDT 2014
NameMtu Network   Address  Ipkts Ierrs Idrop Ibytes
Opkts Oerrs Obytes  Coll
lo0   - 127.0.0.0/8   127.0.0.10 - -  0 
   0 -  0 -
wlan0 - 172.17.0.0/16 172.17.1.252  7023 - -1438387 
4642 - 476288 -
Sat Jun  7 05:47:12 PDT 2014
NameMtu Network   Address  Ipkts Ierrs Idrop Ibytes
Opkts Oerrs Obytes  Coll
lo0   - 127.0.0.0/8   127.0.0.10 - -  0 
   0 -  0 -
wlan0 - 172.17.0.0/16 172.17.1.252  7039 - -1444099 
4658 - 477380 -
g1-252(11.0-C)[5] 

Finally, what you requested:

g1-252(11.0-C)[5] sysctl -a | grep octets
dev.em.0.mac_stats.good_octets_recvd: 0
dev.em.0.mac_stats.good_octets_txd: 0
g1-252(11.0-C)[6] uname -a
FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1268  
r267149M/267149:1100022: Fri Jun  6 06:00:16 PDT 2014 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386
g1-252(11.0-C)[7] 

(The machine is running head because it's in the middle of a
source-based update to r267211.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil cowards with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpOd81q_UxhS.pgp
Description: PGP signature

RE: wlan0/iwn: no upload statistics

[bycn82]

Hi,
As you can see, it is working on my testing machine,
  
/0   /1   /2   /3   /4   /5   /6   /7   /8   /9   /10
 Load Average   |

  Interface   Traffic   PeakTotal
em1  in  0.000 KB/s  0.000 KB/s0.270 KB
 out 0.000 KB/s  0.000 KB/s0.041 KB

em0  in  0.165 KB/s  0.165 KB/s   10.560 MB
 out 0.277 KB/s  0.343 KB/s   30.720 MB

root@FB10Head:~ # sysctl -a | grep octets
dev.em.0.mac_stats.good_octets_recvd: 11575027
dev.em.0.mac_stats.good_octets_txd: 32219968
dev.em.1.mac_stats.good_octets_recvd: 288
dev.em.1.mac_stats.good_octets_txd: 42

root@FB10Head:~ # uname -a
FreeBSD FB10Head 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r266983: Sun Jun  1 
01:57:38 UTC 2014 root@FB10Head:/usr/obj/usr/src/sys/GENERIC  amd64


Regards,
bycn82

> -Original Message-
> From: bycn82 [mailto:byc...@gmail.com]
> Sent: 07 June, 2014 20:39
> To: 'Stefan Ehmann'; 'freebsd-current@freebsd.org'
> Subject: RE: wlan0/iwn: no upload statistics
> 
> Hi,
> 
> More information is required. Please provide the output of the two
> commands below
> 
> 1. sysctl -a | grep octets
> 2. uname -a
> 
> 
> Best Regards,
> bycn82
> 
> 
> 
> > -Original Message-
> > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> > curr...@freebsd.org] On Behalf Of Stefan Ehmann
> > Sent: 07 June, 2014 17:27
> > To: freebsd-current@freebsd.org
> > Subject: wlan0/iwn: no upload statistics
> >
> > Network monitoring tools show download traffic, but no upload data.
> >
> > systat -ifstat output:
> > Interface   Traffic   PeakTotal
> >  wlan0  in  1.066 KB/s 16.155 KB/s  377.757 MB
> > out 0.000 KB/s  0.000 KB/s0.000 KB
> >
> >
> > Tested on amd64 CURRENT from few days ago.
> >
> > netword Card is:
> > iwn0:  mem 0xf200-0xf2001fff irq
> > 17 at device 0.0 on pci3
> > ___
> > 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: wlan0/iwn: no upload statistics

[bycn82]

Hi,

More information is required. Please provide the output of the two commands 
below

1.   sysctl -a | grep octets
2.   uname -a


Best Regards,
bycn82



> -Original Message-
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Stefan Ehmann
> Sent: 07 June, 2014 17:27
> To: freebsd-current@freebsd.org
> Subject: wlan0/iwn: no upload statistics
> 
> Network monitoring tools show download traffic, but no upload data.
> 
> systat -ifstat output:
> Interface   Traffic   PeakTotal
>  wlan0  in  1.066 KB/s 16.155 KB/s  377.757 MB
> out 0.000 KB/s  0.000 KB/s0.000 KB
> 
> 
> Tested on amd64 CURRENT from few days ago.
> 
> netword Card is:
> iwn0:  mem 0xf200-0xf2001fff irq 17
> at device 0.0 on pci3 ___
> 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"

Jenkins build is back to normal : FreeBSD_HEAD #827

[jenkins-admin]

See 

___
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"

wlan0/iwn: no upload statistics

[Stefan Ehmann]

Network monitoring tools show download traffic, but no upload data.

systat -ifstat output:
Interface   Traffic   PeakTotal
 wlan0  in  1.066 KB/s 16.155 KB/s  377.757 MB
out 0.000 KB/s  0.000 KB/s0.000 KB


Tested on amd64 CURRENT from few days ago.

netword Card is:
iwn0:  mem 0xf200-0xf2001fff irq 17
at device 0.0 on pci3
___
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: "CPU0: local APIC error 0x40"

[Edward Tomasz Napierała]

On 0604T1036, John Baldwin wrote:
> On Monday, June 02, 2014 5:32:13 pm Edward Tomasz Napierała wrote:
> > Some machines, including ThinkPad T61, emit the following error message
> > early during boot:
> > 
> > CPU0: local APIC error 0x40
> > 
> > The message itself doesn't seem to be much of a problem.  However,
> > every once in a while booting hangs just before that line.  I've tracked
> > that down to call to AcpiHwWritePort() at
> > sys/contrib/dev/acpica/components/hardware/hwacpi.c:117:
> > 
> > switch (Mode)
> > {
> > case ACPI_SYS_MODE_ACPI:
> > 
> > /* BIOS should have disabled ALL fixed and GP events */
> > 
> > Status = AcpiHwWritePort (AcpiGbl_FADT.SmiCommand,
> > (UINT32) AcpiGbl_FADT.AcpiEnable, 8);
> > 
> > Any idea what might be going on?
> 
> This is probably triggering an SMI# to enter SMM mode where your BIOS does 
> God-knows-what but apparently triggers one of the local APIC local interrupts 
> while it is configured with an invalid vector (e.g. 0).

Is there anything that can be done to fix it?  (Note that fixing the
suspend/resume seems to have also fixed the occasional hang on boot,
but perhaps it's because I don't need to boot this thing so often now.)

___
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"