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/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/171110 amd64 Upgrade 9.1-BETA1 RC1 issue 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 amd64/155135 amd64 [boot] Does Not Boot On a Very Standard Hardware o amd64/154957
amd64/178792: -march=native fails with clang on certain CPU's
Number: 178792 Category: amd64 Synopsis: -march=native fails with clang on certain CPU's Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Mon May 20 16:30:00 UTC 2013 Closed-Date: Last-Modified: Originator: Bert Regeer Release:FreeBSD 9.1-RELEASE Organization: Absio Corporation Environment: FreeBSD TestVM.absio.local 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Description: When compiling with clang passing the flag -march=native causes clang to fail with the following error message: touch test.c clang -march=native test.c error: unknown target CPU 'i686' This is an issue when the Python has also been installed with clang as the compiler, as all of the python packages from pypi that require a c compiler will invoke clang with the -march=native and fail. It is only on certain CPU's that I am able to replicate the issue, see the following output from dmesg: FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz (2294.19-MHz K8-class CPU) Origin = GenuineIntel Id = 0x306a9 Family = 6 Model = 3a Stepping = 9 Features=0xfa3fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,DTS,MMX,FXSR,SSE,SSE2,SS Features2=0x9e982203SSE3,PCLMULQDQ,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,HV AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant How-To-Repeat: touch test.c clang -march=native test.c Fix: Release-Note: Audit-Trail: Unformatted: ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/178671: snd_hda stops working as soon as X starts
On Wednesday, May 15, 2013 3:35:01 pm Anton Shterenlikht wrote: Number: 178671 Category: amd64 Synopsis: snd_hda stops working as soon as X starts Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed May 15 19:40:02 UTC 2013 Closed-Date: Last-Modified: Originator: Anton Shterenlikht Release:FreeBSD 10.0-CURRENT amd64 Organization: University of Bristol Environment: System: FreeBSD mech-aslap239.men.bris.ac.uk 10.0-CURRENT FreeBSD 10.0- CURRENT #33 r250633: Tue May 14 20:11:05 BST 2013 root@mech- aslap239.men.bris.ac.uk:/usr/obj/usr/src/sys/BUZI amd64 Description: This is HP Compaq 6715s laptop. The sound card is: hdac0@pci0:0:20:2: class=0x040300 card=0x30c2103c chip=0x43831002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SBx00 Azalia (Intel HDA)' class = multimedia subclass = HDA I have in the kernel: device sound # Generic sound driver (required) device snd_hda # Intel High Definition Audio In dmesg: hdac0: ATI SB600 HDA Controller mem 0xc000-0xc0003fff irq 16 at device 20.2 on pci0 Before X starts I can get sound via /dev/dsp, or play CDs with dd if=/dev/cd0 of=/dev/dspcd bs=2352 HOwever, as soon I start X, e.g. with xdm, or simply X -config /root/xorg.conf.new -retro I cannot get any sound anymore until a reboot. On the console I see lots of messages: hdac0: Unexpected unsolicited response from address 0: 0040 hdac0: Unexpected unsolicited response from address 0: 00400104 hdac0: Unexpected unsolicited response from address 0: 0001 hdac0: Unexpected unsolicited response from address 0: 000f hdac0: Unexpected unsolicited response from address 0: 410710f0 hdac0: Unexpected unsolicited response from address 0: 0010 hdac0: Unexpected unsolicited response from address 0: 0040 hdac0: Unexpected unsolicited response from address 0: 00400083 hdac0: Unexpected unsolicited response from address 0: hdac0: Unexpected unsolicited response from address 0: 04a12020 hdac0: Unexpected unsolicited response from address 0: 1727 hdac0: Unexpected unsolicited response from address 0: 0020 hdac0: Unexpected unsolicited response from address 0: 00400187 hdac0: Unexpected unsolicited response from address 0: 0002 hdac0: Unexpected unsolicited response from address 0: 0e03 hdac0: Unexpected unsolicited response from address 0: 0181302e hdac0: Unexpected unsolicited response from address 0: 1737 hdac0: Unexpected unsolicited response from address 0: 0020 hdac0: Unexpected unsolicited response from address 0: 00400301 hdac0: Unexpected unsolicited response from address 0: 0001 hdac0: Unexpected unsolicited response from address 0: 0002 hdac0: Unexpected unsolicited response from address 0: 4145f0f0 hdac0: Unexpected unsolicited response from address 0: 0010 hdac0: Unexpected unsolicited response from address 0: 0040 This sounds like the display driver is DMA'ing to the wrong place or writing to the wrong registers. Can you check the output of pciconf -lcb to make sure there are no collisions between BARs? Also, which GPU hardware/driver is in your laptop? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/178357: [patch] export CPU physical and virtual address sizes in sysctl oids using do_cpuid
On Sunday, May 05, 2013 6:43:54 pm Sofian Brabez wrote:
Number: 178357
Category: amd64
Synopsis: [patch] export CPU physical and virtual address sizes in
sysctl oids using do_cpuid
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: Sun May 05 22:50:00 UTC 2013
Closed-Date:
Last-Modified:
Originator: Sofian Brabez
Release:FreeBSD 10.0-CURRENT amd64
Organization:
Environment:
System: FreeBSD ogoshi.lan 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r250287M:
Sun May 5 21:59:15 CEST 2013
r...@ogoshi.lan:/usr/obj/usr/home/sbz/freebsd/svn/src/sys/GENERIC amd64
Description:
This patch export CPU Physical and Virtual address sizes through the sysctl
interface
using do_cpuid function.
It also patch the sys/modules/linprocfs module add this information in the
/usr/compat/linux/proc/cpuinfo output like it's done in Linux /proc/cpuinfo.
More details can be found here: http://people.freebsd.org/~sbz/cpu/
How-To-Repeat:
Fix:
Apply the given patch.
--- address_sizes.diff begins here ---
Index: amd64/amd64/identcpu.c
===
--- amd64/amd64/identcpu.c(revision 250287)
+++ amd64/amd64/identcpu.c(working copy)
@@ -109,6 +109,12 @@
SYSCTL_INT(_hw, OID_AUTO, clockrate, CTLFLAG_RD,
hw_clockrate, 0, CPU instruction clock rate);
+SYSCTL_UINT(_machdep, OID_AUTO, cpu_physical_address_bits, CTLFLAG_RD,
+cpu_pma_bits, 0, CPU physical address bits);
+
+SYSCTL_UINT(_machdep, OID_AUTO, cpu_virtual_address_bits, CTLFLAG_RD,
+cpu_vma_bits, 0, CPU virtual address bits);
+
static eventhandler_tag tsc_post_tag;
static char cpu_brand[48];
@@ -516,6 +522,16 @@
cpu_feature = regs[3];
cpu_feature2 = regs[2];
+ /* Intel CPUID Specification chapter 5.2.7
+ * eax=0x8008
+ * */
+ do_cpuid(0x8008, regs);
+
+ /* upper bits are virtual size */
+ cpu_vma_bits = ((regs[0] 8) 0xFF);
+ /* lower bits are physical size */
+ cpu_pma_bits = (regs[0] 0xFF);
+
/*
* Clear Limit CPUID Maxval bit and get the largest standard CPUID
* function number again if it is set from BIOS. It is necessary
Index: amd64/amd64/initcpu.c
===
--- amd64/amd64/initcpu.c (revision 250287)
+++ amd64/amd64/initcpu.c (working copy)
@@ -66,10 +66,12 @@
u_intcpu_high; /* Highest arg to CPUID */
u_intcpu_exthigh;/* Highest arg to extended CPUID */
u_intcpu_id; /* Stepping ID */
+u_intcpu_pma_bits; /* CPU physical address bits */
u_intcpu_procinfo; /* HyperThreading Info / Brand Index /
CLFUSH
*/
u_intcpu_procinfo2; /* Multicore info */
char cpu_vendor[20]; /* CPU Origin code */
u_intcpu_vendor_id; /* CPU vendor ID */
+u_intcpu_vma_bits; /* CPU virtual address bits */
u_intcpu_fxsr; /* SSE enabled */
u_intcpu_mxcsr_mask; /* Valid bits in mxcsr */
u_intcpu_clflush_line_size = 32;
Index: amd64/include/md_var.h
===
--- amd64/include/md_var.h(revision 250287)
+++ amd64/include/md_var.h(working copy)
@@ -54,10 +54,12 @@
extern u_int cpu_id;
extern u_int cpu_max_ext_state_size;
extern u_int cpu_mxcsr_mask;
+extern u_int cpu_pma_bits;
extern u_int cpu_procinfo;
extern u_int cpu_procinfo2;
extern charcpu_vendor[];
extern u_int cpu_vendor_id;
+extern u_int cpu_vma_bits;
extern charctx_switch_xsave[];
extern charkstack[];
extern charsigcode[];
Index: compat/linprocfs/linprocfs.c
===
--- compat/linprocfs/linprocfs.c (revision 250287)
+++ compat/linprocfs/linprocfs.c (working copy)
@@ -310,6 +310,12 @@
fqmhz, fqkhz, fqmhz, fqkhz);
}
+ if (cpu_vma_bits != 0 cpu_vma_bits != 0) {
I think you want s/vma/pma/ here for the first check.
+ sbuf_printf(sb,
+ address sizes\t: %u bits physical, %u bits virtual\n,
+ cpu_pma_bits, cpu_vma_bits);
+ }
+
return (0);
}
#endif /* __i386__ || __amd64__ */
I don't know that we need to create new sysctls for this since userland
processes can just run cpuid directly. I would be fine adding this to
linprocfs however.
I think if we want to start exporting cpuid info via sysctl we should think
about designing a consistent interface for doing so
Re: Fix amd64 ddb hardware watchpoints for SMP
On Thursday, May 16, 2013 2:41:27 am Konstantin Belousov wrote: The ddb use of hardware watchpoints on the x86 architectures is known to be lacking. There are at least two known problems. One is the improper interaction with the user-mode debuggers which use debug registers. Another is that ddb only loads the debug registers for the watchpoint into the CPU which is executing ddb code, not setting up non-current processors. Not touching the first problem for now, I want to fix the second issue, since as is, hardware watchpoints are useless on SMP. Patch below makes the stopped processors to load the debug registers after resuming from the stop handler, if directed by ddb. Also the patch contains two other commands for ddb which made my exprerience with debugger on amd64 better. The 'show pginfo[/p] addr' command dumps the vm_page_t information, either by vm_page address, or, if the /p modifier is specified, by the physical page address. The 'show phys2dmap addr' command translates physical address into the directly mapped address, which can be accessed from ddb then. This looks fine to me. It would be nice to fix i386 as well to be consistent. I would commit the new DDB commands as a separate patch from the watchpoint fixes. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
