Re: CPU0: local APIC error 0x40
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
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: Intel Centrino Ultimate-N 6300 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
Jenkins build is back to normal : FreeBSD_HEAD #827
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/827/changes ___ 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
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: Intel Centrino Ultimate-N 6300 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
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: Intel Centrino Ultimate-N 6300 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
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
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
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: Turning TESTS on by default
On Fri, Jun 6, 2014 at 9:33 PM, Konstantin Belousov kostik...@gmail.com 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: Turning TESTS on by default
On Sat, Jun 07, 2014 at 12:31:01PM -0600, Alan Somers wrote: On Fri, Jun 6, 2014 at 9:33 PM, Konstantin Belousov kostik...@gmail.com 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
