Current problem reports assigned to freebsd-amd64@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o amd64/179038 amd64 instant reboot doesnt even try too install o amd64/178792 amd64 -march=native fails with clang on certain CPU's o amd64/178357 amd64 [patch] export CPU physical and virtual address sizes o amd64/178247 amd64 linker.hints erroneously included in 9.1-RELEASE-p3 bi o amd64/176835 amd64 Fatal trap 12: page fault while in kernel mode o amd64/176474 amd64 kernel panic o amd64/175725 amd64 Audio through USB has not as good hi quality as it has o amd64/175655 amd64 When enabled tty console OS hang during boot o amd64/175370 amd64 kernel panic the rebuild kernel with vimage options in o amd64/175282 amd64 Freebsd 9.1 release amd64, mb Intel D525MW, not worked o amd64/175129 amd64 laptop won't suspend on lid close o amd64/174679 amd64 Intel i5 laptop overheats and shuts down [regression] o amd64/173869 amd64 buildworld breaks with clang o amd64/173680 amd64 9.1rc3 installer hangs at rootpass o amd64/173502 amd64 Patch inhibition of warnings that appear in the combin o amd64/173465 amd64 FreeBSD 9.1 restarts in random fashion after upgrade t o amd64/173311 amd64 FreeBSD 9.1 RC2 , 12 servers restart in random fashion o amd64/173235 amd64 Have received two crashes within 1 day after installin o amd64/172926 amd64 [boot] booting hangs after 9.1-RC2 install in 2nd (MBR o amd64/171835 amd64 bsdinstall abort on Dell PowerEdge R420 with PERC H310 o amd64/171814 amd64 [panic] bioq_init or bioq_remove (unsure which) o amd64/171701 amd64 [install] 9.0-rel amd64 installer 'guided' or 'manual' o amd64/171250 amd64 ldd32 cannot find some i386 libraries o amd64/170487 amd64 [boot] Thinkpad X61s cannot boot 9.1-BETA1 o amd64/170351 amd64 [kernel] [patch] amd64: 64-bit process can't always ge o amd64/170115 amd64 Serial boot broken in 9.0 o amd64/168659 amd64 [boot] FreeBSD 9 - Crash upon booting off install CD ( o amd64/167582 amd64 Compile of MySQL NDB Cluster Fails 8.2 AMD64 o amd64/167543 amd64 [kernel] Install FreeBSD can show error message with c o amd64/167393 amd64 [boot] MacBook4,1 hangs on SMP boot o amd64/166639 amd64 [boot] Syscons issue Intel D2700 o amd64/166229 amd64 [boot] Unable to install FreeBSD 9 on Acer Extensa 522 o amd64/165850 amd64 [build] 8.3-RC1 (amd64): world doesn't build with CPUT o amd64/165845 amd64 [build] Unable to build kernel on 8.2-STABLE o amd64/165351 amd64 [boot] Error while installing or booting the freeBSD O o amd64/164773 amd64 [boot] 9.0 amd64 fails to boot on HP DL145 G3 [regress o amd64/164707 amd64 FreeBSD 9 installer does not work with IBM uefi o amd64/164643 amd64 Kernel Panic at 9.0-RELEASE o amd64/164619 amd64 when logged in as root the user and group applications o amd64/164457 amd64 [install] Can't install FreeBSD 9.0 (amd64) on HP Blad o amd64/164301 amd64 [install] 9.0 - Can't install, no DHCP lease o amd64/164136 amd64 after fresh install 8.1 release or 8.2 release the har o amd64/164116 amd64 [boot] FreeBSD 9.0-RELEASE installations mediums fails o amd64/164089 amd64 FreeBSD-9.0-RELEASE-amd64-memstick.img does not boot o amd64/164073 amd64 /etc/rc warning after booting o amd64/164036 amd64 [keyboard] Moused fails on 9_0_RELENG o amd64/163736 amd64 Freebsd 8.2 with MPD5 and about 100 PPPoE clients pani o amd64/163710 amd64 setjump in userboot.so causes stack corruption o amd64/163625 amd64 Install problems of RC3 amd64 on ASRock N68 GE3 UCC o amd64/163568 amd64 hard drive naming o amd64/163285 amd64 when installing gnome2-lite not all dependent packages o amd64/163284 amd64 print manager failed to install correctly o amd64/163114 amd64 no boot on Via Nanao netbook Samsung NC20 o amd64/163092 amd64 FreeBSD 9.0-RC2 fails to boot from raid-z2 if AHCI is o amd64/163048 amd64 normal user cant mount ntfs-3g o amd64/162936 amd64 fails boot and destabilizes other OSes on FreeBSD 9 RC o amd64/162489 amd64 After some time X blanks the screen and does not respo o amd64/162314 amd64 not able to install FreeBSD-8.2-RELEASE-amd64-dvd1 as o amd64/162170 amd64 Unable to install due to freeze at run_interrupt_driv o amd64/161974 amd64 FreeBSD 9 new installer installs succesful, renders ma o kern/160833 amd64 Keyboard USB doesn't work o amd64/157386 amd64 [powerd] Enabling powerd(8) with default settings on I o amd64/156106 amd64 [boot] boot0 fails to start o
Re: idle process keeping cpu 150% busy in freebsd 9.1-amd64 [solved]
Thanks very much to all for your help.
I finally resolved the problem: first, upon logging in, I
changed the window system to fluxbox, instead of my usual
Gnome. The cpu quieted down. This suggested that I had
messed up something having to do with Gnome. So I
adopted the trivial fix: I had done little work on the
system, so I re-installed PC-BSD 9.1. Now I am running Gnome
and both cores are fine.
One small issue remains: the system doesn't suspend
properly. If I suspend it from the Gnome System - Shut
down... menu, it appears to suspend, but the fans keep
running, and it doesn't want to wake up again, even if I
power it off. The only way to wake it up is pull the
power cord and plug it in again, and then it reboots.
Perhaps this is a known ACPI problem?
Excerpt from dmesg:
aesni0: No AESNI support.
acpi0: HPQOEM SLIC-CPC on motherboard
acpi0: Power Button (fixed)
ACPI Error: Field [ASSM] at 524320 exceeds Buffer [BUF0]
size 880 (bits) (20110527/dsopcode-254)
ACPI Error: Method parse/execution failed [\\_SB_.MEM_._CRS]
(Node 0xfe0003cfc380), AE_AML_BUFFER_LIMIT
(20110527/psparse-560)
ACPI Error: Method execution failed [\\_SB_.MEM_._CRS] (Node
0xfe0003cfc380), AE_AML_BUFFER_LIMIT (20110527/uteval-113)
can't fetch resources for \\_SB_.MEM_ - AE_AML_BUFFER_LIMIT
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
Kostas
- Original Message - From: Kostas Oikonomou
k.oikono...@att.net
To: John Baldwin j...@freebsd.org
Cc: freebsd-amd64@freebsd.org
Sent: Friday, May 31, 2013 9:49 PM
Subject: Re: idle process keeping cpu 150% busy in freebsd
9.1-amd64
The core will always look like it is running in top,
even when it is asleep. That is just how FreeBSD accounts
for idle CPU time. The only thing I was hoping would
change is the fan having to run. You can try kldload'ing
coretemp and seeing if the processor temperatures are
different when deeper CX states are enabled (or when
powerd is running) to see if it is having any affect on
the temperatures in your box.
First the good news. It looks like the problem is solved
on the laptop (Core i7). It took one more reboot after I
put performance_cx_lowest=LOW in /etc/rc.conf.
However, the problem is still there on the HP desktop
(AMD 7550). This has only
Cx state, C1, so performance_cx_lowest=LOW had no effect.
The symptoms with this machine are that top does not show
anything running besides idle, and neither does ps -aux.
Yet the Gnome System monitor applet that I have on the
bottom panel shows significant cpu activity.
And the fan starts running within 5 minutes after the
system finishes booting.
Here is what top -S -H says:
last pid: 2645; load averages: 1.14, 0.78,
0.34 up 0+00:02:17 19:31:35
356 processes: 3 running, 338 sleeping, 15 waiting
CPU: 0.2% user, 0.0% nice, 18.9% system, 0.0%
interrupt, 80.9% idle
Mem: 187M Active, 36M Inact, 354M Wired, 13M Cache, 3323M
Free
Swap: 2048M Total, 2048M Free
PID USERNAME PRI NICE SIZERES STATE C
TIME WCPU COMMAND
11 root 155 ki31 0K32K CPU00 1:45
89.99% idle{idle: cpu0}
11 root 155 ki31 0K32K RUN 1 1:40
83.98% idle{idle: cpu1}
0 root -160 0K 2672K sched 0 1:03
0.00% kernel{swapper}
462 root -21 r31 912M 33216K select 0 0:10
0.00% Xorg
1968 ko 520 209M 7144K select 0 0:04
0.00% pulseaudio{pulseaudio}
1968 ko 520 209M 7144K select 1 0:03
0.00% pulseaudio{pulseaudio}
7 root -16- 0K16K ccb_sc 0 0:02
0.00% xpt_thrd
12 root -84- 0K 240K WAIT1 0:01
0.00% intr{irq1: atkbd0}
12 root -60- 0K 240K WAIT0 0:01
0.00% intr{swi4: clock}
1969 ko 200 323M 21968K select 0 0:00
0.00% gnome-panel{gnome-panel}
12 root -96- 0K 240K WAIT1 0:00
0.00% intr{irq16: vgapci0+}
2196 ko 200 294M 18052K select 0 0:00
0.00% gnome-netstatus-app{gnome-
1811 ko 200 320M 19116K select 1 0:00
0.00% gnome-settings-daem{gnome-
15 root -68- 0K 128K - 1 0:00
0.00% usb{usbus0}
2200 ko 200 360M 21808K select 1 0:00
0.00% clock-applet{clock-applet}
1458 root30 10 10376K 3448K select 0 0:00
0.00% devd
2028 ko 200 218M 25652K select 0 0:00
0.00% python
2272 ko 200 280M 20044K select 1 0:00
0.00% gnome-terminal{gnome-termi
2198 ko 200 295M 20552K select 1 0:00
0.00% stickynotes_applet{stickyn
1405 ko 200 156M 13152K select 0 0:00
0.00% gnome-session{gnome-sessio
417 haldaemon 200 56952K 6136K select 0 0:00
0.00% hald{hald}
Assuming this is a dual core machine, your missing ~25% of
your overall
CPU time, identifying where this is
[head tinderbox] failure on amd64/amd64
TB --- 2013-06-03 17:20:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-06-03 17:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-06-03 17:20:17 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-06-03 17:20:17 - cleaning the object tree TB --- 2013-06-03 17:20:17 - /usr/local/bin/svn stat /src TB --- 2013-06-03 17:20:22 - At svn revision 251314 TB --- 2013-06-03 17:20:23 - building world TB --- 2013-06-03 17:20:23 - CROSS_BUILD_TESTING=YES TB --- 2013-06-03 17:20:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-03 17:20:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-03 17:20:23 - SRCCONF=/dev/null TB --- 2013-06-03 17:20:23 - TARGET=amd64 TB --- 2013-06-03 17:20:23 - TARGET_ARCH=amd64 TB --- 2013-06-03 17:20:23 - TZ=UTC TB --- 2013-06-03 17:20:23 - __MAKE_CONF=/dev/null TB --- 2013-06-03 17:20:23 - cd /src TB --- 2013-06-03 17:20:23 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Mon Jun 3 17:20:29 UTC 2013 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 stage 5.1: building 32 bit shim libraries World build completed on Mon Jun 3 21:04:10 UTC 2013 TB --- 2013-06-03 21:04:10 - generating LINT kernel config TB --- 2013-06-03 21:04:10 - cd /src/sys/amd64/conf TB --- 2013-06-03 21:04:10 - /usr/bin/make -B LINT TB --- 2013-06-03 21:04:10 - cd /src/sys/amd64/conf TB --- 2013-06-03 21:04:10 - /usr/sbin/config -m LINT TB --- 2013-06-03 21:04:10 - building LINT kernel TB --- 2013-06-03 21:04:10 - CROSS_BUILD_TESTING=YES TB --- 2013-06-03 21:04:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-03 21:04:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-03 21:04:10 - SRCCONF=/dev/null TB --- 2013-06-03 21:04:10 - TARGET=amd64 TB --- 2013-06-03 21:04:10 - TARGET_ARCH=amd64 TB --- 2013-06-03 21:04:10 - TZ=UTC TB --- 2013-06-03 21:04:10 - __MAKE_CONF=/dev/null TB --- 2013-06-03 21:04:10 - cd /src TB --- 2013-06-03 21:04:10 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Jun 3 21:04:10 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Mon Jun 3 21:35:45 UTC 2013 TB --- 2013-06-03 21:35:45 - cd /src/sys/amd64/conf TB --- 2013-06-03 21:35:45 - /usr/sbin/config -m LINT-NOINET TB --- 2013-06-03 21:35:45 - building LINT-NOINET kernel TB --- 2013-06-03 21:35:45 - CROSS_BUILD_TESTING=YES TB --- 2013-06-03 21:35:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-03 21:35:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-03 21:35:45 - SRCCONF=/dev/null TB --- 2013-06-03 21:35:45 - TARGET=amd64 TB --- 2013-06-03 21:35:45 - TARGET_ARCH=amd64 TB --- 2013-06-03 21:35:45 - TZ=UTC TB --- 2013-06-03 21:35:45 - __MAKE_CONF=/dev/null TB --- 2013-06-03 21:35:45 - cd /src TB --- 2013-06-03 21:35:45 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Mon Jun 3 21:35:45 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Mon Jun 3 22:05:42 UTC 2013 TB --- 2013-06-03 22:05:42 - cd /src/sys/amd64/conf TB --- 2013-06-03 22:05:42 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-06-03 22:05:42 - building LINT-NOINET6 kernel TB --- 2013-06-03 22:05:42 - CROSS_BUILD_TESTING=YES TB --- 2013-06-03 22:05:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-03 22:05:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-03 22:05:42 - SRCCONF=/dev/null TB --- 2013-06-03 22:05:42 - TARGET=amd64 TB --- 2013-06-03 22:05:42 - TARGET_ARCH=amd64 TB --- 2013-06-03 22:05:42 - TZ=UTC TB --- 2013-06-03 22:05:42 - __MAKE_CONF=/dev/null TB --- 2013-06-03 22:05:42 - cd /src TB --- 2013-06-03 22:05:42 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Mon Jun 3 22:05:42 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Mon Jun 3 22:35:40 UTC 2013 TB --- 2013-06-03 22:35:40 - cd /src/sys/amd64/conf TB --- 2013-06-03 22:35:40 - /usr/sbin/config -m LINT-NOIP TB --- 2013-06-03 22:35:40 - building LINT-NOIP kernel TB --- 2013-06-03 22:35:40 -
amd64/179282: [PATCH] Intel SMAP for FreeBSD-CURRENT
Number: 179282 Category: amd64 Synopsis: [PATCH] Intel SMAP for FreeBSD-CURRENT Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: change-request Submitter-Id: current-users Arrival-Date: Mon Jun 03 23:10:01 UTC 2013 Closed-Date: Last-Modified: Originator: Oliver Pinter Release:FreeBSD 10-CURRENT Organization: Environment: Description: As subpart of my thesis, I implemented Intel SMAP[1] support for FreeBSD. The current stable version of patch (attached) have compile time option to enable SMAP.* A feature complete dynamic version is expected by the end of the month, which patched the kernel on boot time, when the feautre presented in CPU. [1] http://lwn.net/Articles/517475/ patches: https://github.com/opntr/freebsd-patches-2013-tavasz smap-test: https://github.com/opntr/freebsd-smap-tester How-To-Repeat: Fix: Patch attached with submission follows: From ae18b374b38401f736e4e13a8ab5fab82985df2b Mon Sep 17 00:00:00 2001 From: Oliver Pinter oliver.p...@gmail.com Date: Tue, 16 Apr 2013 01:32:25 +0200 Subject: [PATCH] added SMAP support for FreeBSD against r250423 This patch implemented support for Intel's new protection technology. Supervisor Mode Access Prevention (SMAP) is newest security feature from Intel, which first appears in the Haswell Line of processors. When SMAP enabled, the kernel cannot access pages that are in userspace. In some cases the kernel does have to access user pages, for this reason the technology provided two instruction, to temporarily disable this protection. When SMAP detect protection violation, the kernel must call panic(). Intel's SMAP documentation: http://software.intel.com/sites/default/files/319433-014.pdf Test case: https://github.com/opntr/freebsd-smap-tester some parts of this patch discussed with kib freebsd org and Hunger Signed-off-by: Oliver Pinter oliver.p...@gmail.com -- * added void clac(void) and void stac(void) to cpufunc.h * added STAC/CLAC instruction and added config options * added basic support for SMAP * added stac/clac in support.S around userspace memory access * added RFLAGS.AC clearing to exception.S related to SMAP * added RFLAGS.AC clearing to ia32_exception.S related to SMAP * added RFLAGS.AC clearing to asmacros.h related to SMAP * clac and stac functions depend on INTEL_SMAP * added trap handler to SMAP For security reason, when PF occured by SMAP, the kernel should paniced. [...] The above items imply that the error code delivered by a page-fault exception due to SMAP is either 1 (for reads) or 3 (for writes). Note that the only page-fault exceptions that deliver an error code of 1 are those induced by SMAP. (If CR0.WP = 1, some page-fault exceptions may deliver an error code of 3 even if CR4.SMAP = 0.) [...] - intel 319433-014.pdf 9.3.3 * Clear the RFLAGS.AC on the start of nmi handler suggested by kib@: I think that NMI handler should have CLAC executed unconditionally and much earlier then it is done in your patch. Since NMI could interrupt the copy*() functions, you would get some kernel code unneccessary executing with SMAP off. * added note to fault handlers related to SMAP suggested by kib@: I believe that exception labels in the support.S, like copyout_fault etc deserve a comment describing that EFLAGS.AC bit gets cleared by the exception entry point before the control reaches the label. * added AC flag checking and factor out SMAP checking in trap_pfault() to make it more readable and partially suggested by kib: The trap_pfault() fragment should check for the error code equal to 1 or 3, as described in the 9.3.3, instead of only checking for the present bit set. More, I suggest you to explicitely check that the #PF exception came from the kernel mode and that EFLAGS.AC was also set, before decidingto panic due to SMAP-detected failure. * build fix, when INTEL_SMAP has not set in kernel config /usr/home/op/git/freebsd-base.git.http/sys/amd64/amd64/trap.c:889:1: error: unused function 'smap_access_violation' [-Werror,-Wunused-function] smap_access_violation(struct trapframe *frame, int usermode) ^ 1 error generated. *** [trap.o] Error code 1 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error * fixed smap_access_violation(...), spotted by Hunger * fix smap_access_violatrion() when the CPU does not support SMAP * use the CLAC and STAC macro, instead of the .byte sequence * added memory clobber to clac and stac inline assembly clac and stac are sensitive instructions, to prevent instruction reordering added memory clobber spotted by Hunger, PaXTeam Signed-off-by: Oliver Pinter oliver.p...@gmail.com --- sys/amd64/amd64/exception.S | 6 ++ sys/amd64/amd64/identcpu.c | 28
