Re: Thinkpad X61s cannot boot 9.1-BETA1
On Thu, 19 Jul 2012, 11:14 +0200, Per olof Ljungmark wrote: Did anyone else experience this? With 9.1-BETA1 the boot process freezes, among the last lines with verbose boot are acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times after this, dead. What is supposed to happen in the next stage? This laptop worked fine with 9-STABLE to at least february. This morning I csup'd RELENG_9, built, and upgraded my ThinkPad T43 from 9.0-RELEASE-p3 with no problem. See dmesg output below. I do realize that a ThinkPad T43 is not a ThinkPad X61 but, not knowing how similar or different they may be, I thought I'd post a reply anyway. My kernel config includes the following two drivers which may be relevant (particularly acpi_ibm): they have been in the config for a number of years. device acpi_ibm device acpi_video Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-PRERELEASE #0: Fri Jul 20 11:55:58 AEST 2012 root@rwpc08:/usr/obj/build/src/sys/RWPC08 i386 CPU: Intel(R) Pentium(R) M processor 1.73GHz (1729.21-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6d8 Family = 6 Model = d Stepping = 8 Features=0xafe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE Features2=0x180EST,TM2 AMD Features=0x10NX real memory = 1610612736 (1536 MB) avail memory = 1555107840 (1483 MB) Event timer LAPIC quality 400 ACPI APIC Table: IBMTP-70 ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20110527/tbfadt-556) ACPI Warning: Optional field Gpe1Block has zero address or length: 0x102C/0x0 (20110527/tbfadt-586) ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 ctl: CAM Target Layer loaded cryptosoft0: software crypto on motherboard acpi0: IBM TP-70 on motherboard acpi_ec0: Embedded Controller: GPE 0x1c, ECDT port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 5ff0 (3) failed cpu0: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0x1800-0x1807 mem 0x9008-0x900f,0xb000-0xbfff,0x9000-0x9003 irq 16 at device 2.0 on pci0 acpi_video0: ACPI video extension on vgapci0 agp0: Intel 82915GM (915GM GMCH) SVGA controller on vgapci0 agp0: aperture size is 256M, detected 7932k stolen memory drm0: Intel i915GM on vgapci0 info: [drm] AGP at 0xb000 256MB info: [drm] Initialized i915 1.6.0 20080730 vgapci1: VGA-compatible display at device 2.1 on pci0 pcib1: ACPI PCI-PCI bridge irq 20 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib1 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x004101 mem 0x9010-0x9010 irq 16 at device 0.0 on pci2 bge0: CHIP ID 0x4101; ASIC REV 0x04; CHIP REV 0x41; PCI-E miibus0: MII bus on bge0 brgphy0: BCM5750 1000BASE-T media interface PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:11:25:d2:38:06 pcib2: ACPI PCI-PCI bridge irq 22 at device 28.2 on pci0 pci3: ACPI PCI bus on pcib2 uhci0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A port 0x1820-0x183f irq 16 at device 29.0 on pci0 usbus0 on uhci0 uhci1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B port 0x1840-0x185f irq 17 at device 29.1 on pci0 usbus1 on uhci1 uhci2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C port 0x1860-0x187f irq 18 at device 29.2 on pci0 usbus2 on uhci2 uhci3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D port 0x1880-0x189f irq 19 at device 29.3 on pci0 usbus3 on uhci3 ehci0: Intel 82801FB (ICH6) USB 2.0 controller mem 0x9004-0x900403ff irq 19 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci0 pcib3: ACPI PCI-PCI bridge at device 30.0 on pci0 pci4: ACPI PCI bus on pcib3 cbb0: TI1510 PCI-CardBus Bridge mem 0x9030-0x90300fff irq 16 at device 0.0 on pci4 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 iwi0: Intel(R) PRO/Wireless 2200BG mem 0x90301000-0x90301fff irq 21 at device 2.0 on pci4 pcm0: Intel ICH6 (82801FB) port 0x1c00-0x1cff,0x18c0-0x18ff mem
Re: Thinkpad X61s cannot boot 9.1-BETA1
On 20/07/2012 16:02, John Marshall wrote: On Thu, 19 Jul 2012, 11:14 +0200, Per olof Ljungmark wrote: Did anyone else experience this? With 9.1-BETA1 the boot process freezes, among the last lines with verbose boot are acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times after this, dead. What is supposed to happen in the next stage? This laptop worked fine with 9-STABLE to at least february. This morning I csup'd RELENG_9, built, and upgraded my ThinkPad T43 from 9.0-RELEASE-p3 with no problem. See dmesg output below. I do realize that a ThinkPad T43 is not a ThinkPad X61 but, not knowing how similar or different they may be, I thought I'd post a reply anyway. My kernel config includes the following two drivers which may be relevant (particularly acpi_ibm): they have been in the config for a number of years. deviceacpi_ibm deviceacpi_video Please also note that I do *not* have the apm driver included in my kernel config. -- John Marshall signature.asc Description: OpenPGP digital signature
9.1-PRERELEASE and ntpd problem
my console is filling up with: Jul 20 11:08:18 pundit ntpd[1075]: bind() fd 27, family AF_INET6, port 123, scope 2, addr fe80::f66d:4ff:fee1:f7ba, mcast=0 flags=0x11 fails: Can't assign requested address Jul 20 11:08:18 pundit ntpd[1075]: unable to create socket on re0 (8) for fe80::f66d:4ff:fee1:f7ba#123 Jul 20 11:13:18 pundit ntpd[1075]: bind() fd 27, family AF_INET6, port 123, scope 2, addr fe80::f66d:4ff:fee1:f7ba, mcast=0 flags=0x11 fails: Can't assign requested address Jul 20 11:13:18 pundit ntpd[1075]: unable to create socket on re0 (9) for fe80::f66d:4ff:fee1:f7ba#123 any ideas? thanks, danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1-PRERELEASE and ntpd problem
On 07/20/2012 10:18 AM, Daniel Braniss wrote: my console is filling up with: Jul 20 11:08:18 pundit ntpd[1075]: bind() fd 27, family AF_INET6, port 123, scope 2, addr fe80::f66d:4ff:fee1:f7ba, mcast=0 flags=0x11 fails: Can't assign requested address Jul 20 11:08:18 pundit ntpd[1075]: unable to create socket on re0 (8) for fe80::f66d:4ff:fee1:f7ba#123 Jul 20 11:13:18 pundit ntpd[1075]: bind() fd 27, family AF_INET6, port 123, scope 2, addr fe80::f66d:4ff:fee1:f7ba, mcast=0 flags=0x11 fails: Can't assign requested address Jul 20 11:13:18 pundit ntpd[1075]: unable to create socket on re0 (9) for fe80::f66d:4ff:fee1:f7ba#123 any ideas? thanks, danny Hi Danny I don't see this problem here with a GENERIC kernel and unmodified ntp.conf Are you using IPv6 ? Do you have an unmodified ntp.conf ? What does /var/log/messages give when you do a service ntpd restart ? Here it is: Jul 20 10:40:49 dd ntpd[1030]: ntpd exiting on signal 15 Jul 20 10:40:49 dd ntpd[1390]: ntpd 4.2.4p5-a (1) Jul 20 10:40:56 dd ntpd[1391]: kernel time sync status change 2001 on a uname -a FreeBSD dd.ose.nl 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #6: Fri Jul 20 09:04:04 CEST 2012 r...@dd.ose.nl:/usr/obj/usr/src/sys/GENERIC amd64 I have ssh bound to tcp4 and tcp6 and ntpd is bound to udp4 and udp6 tcp4 0 0 *.ssh *.* LISTEN udp4 0 0 *.ntp tcp6 0 0 *.ssh *.* LISTEN udp6 0 0 *.ntp *.* Disclaimer: http://www.ose.nl/email ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1-PRERELEASE and ntpd problem
On 07/20/2012 10:18 AM, Daniel Braniss wrote: my console is filling up with: Jul 20 11:08:18 pundit ntpd[1075]: bind() fd 27, family AF_INET6, port 123, scope 2, addr fe80::f66d:4ff:fee1:f7ba, mcast=0 flags=0x11 fails: Can't assign requested address Jul 20 11:08:18 pundit ntpd[1075]: unable to create socket on re0 (8) for fe80::f66d:4ff:fee1:f7ba#123 Jul 20 11:13:18 pundit ntpd[1075]: bind() fd 27, family AF_INET6, port 123, scope 2, addr fe80::f66d:4ff:fee1:f7ba, mcast=0 flags=0x11 fails: Can't assign requested address Jul 20 11:13:18 pundit ntpd[1075]: unable to create socket on re0 (9) for fe80::f66d:4ff:fee1:f7ba#123 any ideas? thanks, danny Hi Danny I don't see this problem here with a GENERIC kernel and unmodified ntp.conf Are you using IPv6 ? no Do you have an unmodified ntp.conf ? my ntp.conf: server ntp (the same on all freebsds's) What does /var/log/messages give when you do a service ntpd restart ? Jul 20 10:56:11 pundit kernel: Starting powerd. Jul 20 10:56:11 pundit kernel: Jul 20 10:56:11 pundit ntpd[1075]: bind() fd 23, family AF_INET6, port 123, scope 2, addr fe80::f66d:4ff:fee1:f7ba, mcast=0 flags=0x11 fails: Can't assign requested address Jul 20 10:56:11 pundit kernel: Jul 20 10:56:11 pundit ntpd[1075]: unable to create socket on re0 (3) for fe80::f66d:4ff:fee1:f7ba#123 Jul 20 10:56:12 pundit kernel: Starting snmpd. ifconfig seem ok: re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAG IC,LINKSTATE ether f4:6d:04:e1:f7:ba inet 132.65.80.126 netmask 0xf000 broadcast 132.65.95.255 inet6 fe80::f66d:4ff:fee1:f7ba%re0 prefixlen 64 tentative scopeid 0x2 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active Here it is: Jul 20 10:40:49 dd ntpd[1030]: ntpd exiting on signal 15 Jul 20 10:40:49 dd ntpd[1390]: ntpd 4.2.4p5-a (1) Jul 20 10:40:56 dd ntpd[1391]: kernel time sync status change 2001 on a uname -a FreeBSD dd.ose.nl 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #6: Fri Jul 20 09:04:04 CEST 2012 r...@dd.ose.nl:/usr/obj/usr/src/sys/GENERIC amd64 I have ssh bound to tcp4 and tcp6 and ntpd is bound to udp4 and udp6 tcp4 0 0 *.ssh *.* LISTEN udp4 0 0 *.ntp tcp6 0 0 *.ssh *.* LISTEN udp6 0 0 *.ntp *.* I have: udp4 0 0 localhost.ntp *.* udp6 0 0 fe80:5::1.ntp *.* udp6 0 0 ::1.ntp*.* udp4 0 0 pundit.cs.huji.a.ntp *.* I'm runing almost a GENERIC kernel: include GENERIC ident HUJI options SCSI_DELAY=500 # Delay (in ms) before probing SCSI options BOOTP_NFSV3 # Use NFS v3 to NFS mount root # sequence CR ~ ^b which is similar to a familiar pattern used on Sun options ALT_BREAK_TO_DEBUGGER options CONSPEED=115200 # speed for serial console options KDB_UNATTENDED options PANIC_REBOOT_WAIT_TIME=160 options DEVICE_POLLING options ALTQ options ALTQ_CBQ# Class Bases Queueing options ALTQ_PRIQ # Priority Queueing options ALTQ_HFSC # Hierarchical Packet Scheduler #optionsSW_WATCHDOG options PRINTF_BUFR_SIZE=256 and finaly, the host is dataless, i.e it boots via PXE. thanks, danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: branch 9 and uefi
On Thu, Jul 19, 2012 at 06:08:31PM +0200 I heard the voice of Zoran Kolic, and lo! it spake thus: It took me by surprise. The mobo I have on my mind for new desktop has uefi instead of bios. It is asus m5a97, with 970 chipset, well priced among users on the net. How would it behave with 9.1? I'm running a M5A97 Evo just fine on -CURRENT, and I'd be shocked it it had any problem with 9 (or 8 or 7, for that matter). -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: branch 9 and uefi
Hi, On Friday 20 July 2012 17:43:34 Matthew D. Fuller wrote: On Thu, Jul 19, 2012 at 06:08:31PM +0200 I heard the voice of Zoran Kolic, and lo! it spake thus: It took me by surprise. The mobo I have on my mind for new desktop has uefi instead of bios. It is asus m5a97, with 970 chipset, well priced among users on the net. How would it behave with 9.1? I'm running a M5A97 Evo just fine on -CURRENT, and I'd be shocked it it had any problem with 9 (or 8 or 7, for that matter). this could be true. My X220 was also reported to have these problems with 8. But at least 9 booted on mine with UEFi without problems. Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mfi(4) IO performance regression, post 8.1
Hi Adrian, I've submitted the PR as kern/170021. Thanks! On 7/19/12 11:29 AM, Adrian Chadd wrote: Oh, and would you please file a PR for this? I've been looking into ACPI related slowdowns for a while and I'm glad you found a culprit. Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mfi(4) IO performance regression, post 8.1
On 7/19/12 10:12 AM, Eric van Gyzen wrote: You might simply try a different idle function. See these sysctls: machdep.idle: acpi machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, Eric I've tried your suggestion (with mwait) and the problem went away. Thanks a lot! This seems like a good workaround, but I am worried about whether it could negatively affect something that I don't know about which also depends on this sysctl. If you have any ideas on other areas I could test, I'd greatly appreciate the info. Thanks again! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Thinkpad X61s cannot boot 9.1-BETA1
On 2012-07-20 08:02, John Marshall wrote: On Thu, 19 Jul 2012, 11:14 +0200, Per olof Ljungmark wrote: Did anyone else experience this? With 9.1-BETA1 the boot process freezes, among the last lines with verbose boot are acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times after this, dead. What is supposed to happen in the next stage? This laptop worked fine with 9-STABLE to at least february. This morning I csup'd RELENG_9, built, and upgraded my ThinkPad T43 from 9.0-RELEASE-p3 with no problem. See dmesg output below. I do realize that a ThinkPad T43 is not a ThinkPad X61 but, not knowing how similar or different they may be, I thought I'd post a reply anyway. My kernel config includes the following two drivers which may be relevant (particularly acpi_ibm): they have been in the config for a number of years. device acpi_ibm device acpi_video snip X61s is rather different from T43 so that might explain why. I have tried various variations of modules but there is no difference. RELENG-9 boots fine 9-BETA1 not 10-CURRENT not I'll stay at RELENG-9 for the time being and see if anything comes up that sheds light on this. Thanks, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mfi(4) IO performance regression, post 8.1
On 19.07.2012 18:28, Adrian Chadd wrote:
Hm! A timer related bug?
I'll CC mav@ on this, as it was his commit (and work in his general area.)
I wonder what's going on - is it something to do with the two ACPI
calls inserted there, or is it something to do with the change in
event timer values?
mav? Any ideas?
I can just agree with earlier made guess that for some reason ACPI timer
on that system is very slow. Unless user explicitly enabled deeper
C-states, values returned by the timer are not really used for anything,
so there is just no place for other bug.
When doing this change I was expecting that it may have cost, but on
most systems that cost makes effect only during high interrupt rates,
where it is covered by automatic fallback to using faster MWAIT as idle
method. Unluckily, that code still was not merged to 8-STABLE (only 9).
I will recheck is there problem to merge it now.
Manual switching to MWAIT via sysctl is correct workaround for this
situation. It may give slightly higher power consumption, but for this
workload with many interrupts probably the best possible performance.
On 17 July 2012 13:39, Steve McCoy smc...@greatbaysoftware.com wrote:
Alright, I've finally narrowed it down to r209897, which only affects
acpi_cpu_idle():
--- stable/8/sys/dev/acpica/acpi_cpu.c 2010/06/23 17:04:42 209471
+++ stable/8/sys/dev/acpica/acpi_cpu.c 2010/07/11 11:58:46 209897
@@ -930,12 +930,16 @@
/*
* Execute HLT (or equivalent) and wait for an interrupt. We can't
- * calculate the time spent in C1 since the place we wake up is an
- * ISR. Assume we slept half of quantum and return.
+ * precisely calculate the time spent in C1 since the place we wake up
+ * is an ISR. Assume we slept no more then half of quantum.
*/
if (cx_next-type == ACPI_STATE_C1) {
- sc-cpu_prev_sleep = (sc-cpu_prev_sleep * 3 + 50 / hz) / 4;
+ AcpiHwRead(start_time, AcpiGbl_FADT.XPmTimerBlock);
acpi_cpu_c1();
+ AcpiHwRead(end_time, AcpiGbl_FADT.XPmTimerBlock);
+end_time = acpi_TimerDelta(end_time, start_time);
+ sc-cpu_prev_sleep = (sc-cpu_prev_sleep * 3 +
+ min(PM_USEC(end_time), 50 / hz)) / 4;
return;
}
My current guess is that AcpiHwRead() is a problem on our hardware. It's an
isolated change and, to my desperate eyes, the commit message implies that
it isn't critical — Do you think we could buy ourselves some time by pulling
it out of our version of the kernel? Or is this essential for correctness?
Any thoughts are appreciated, thanks!
--
Alexander Motin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Thinkpad X61s cannot boot 9.1-BETA1
Per olof Ljungmark peo at intersonic.se writes: ... Did anyone else experience this? With 9.1-BETA1 the boot process freezes, among the last lines with verbose boot are acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times after this, dead. ... Tried ALL boot options, none worked. For example, if I try disable acpi it will stop at no event timer available. Here is something similar ... http://forums.freebsd.org/archive/index.php/t-32423.html ... When I enabled verbose boot logging, the boot seems to hang up just after the kernel load. I have tried disabling ACPI and APIC with the same results. Here is where the news starts to turn good. I tried a FreeBSD 9 disk and got much further. Then, I was either getting a page fault or panic: no usable event timer found depending on boot options. The release errata then set me straight. With debug.acpi.disabled=hostres I was able to boot! ... Here is the related errata: http://www.freebsd.org/releases/9.0R/errata.html ... [amd64, i386] FreeBSD 9.0-RELEASE includes several changes to improve resource management of PCI devices. Some x86 machines may not boot or may have devices that no longer attach when using ACPI as a result of these changes. This can be worked around by setting a loader(8) tunable debug.acpi.disabled to hostres. To do this, enter the following lines at the loader prompt: set debug.acpi.disabled=hostres boot Or, put the following line into /boot/loader.conf: debug.acpi.disabled=hostres ... Anyway, regardless of this attempt, file a PR# for 9.1-BETA1. jb ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[stable 9] panic on reboot: ipmi_wd_event()
Working on the Dell R420 today, got most of it working, even the broadcom ethernet cards! However, I get the following when I reboot the system: Syncing disks, vnodes remaining...4 Sleeping thread (tid 100107, pid 9) owns a non-sleepable lock KDB: stack backtrace of thread 100107: sched_switch() at sched_switch+0x19f mi_switch() at mi_switch+0x208 sleepq_switch() at sleepq_switch+0xfc sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x3f6 ipmi_submit_driver_request() at ipmi_submit_driver_request+0x97 ipmi_set_watchdog() at ipmi_set_watchdog+0xb1 ipmi_wd_event() at ipmi_wd_event+0x8f kern_do_pat() at kern_do_pat+0x10f sched_sync() at sched_sync+0x1ea fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff869b172bb0, rbp = 0 --- panic: sleeping thread cpuid = 26 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 propagate_priority() at propagate_priority+0x223 turnstile_wait() at turnstile_wait+0x252 _mtx_lock_sleep() at _mtx_lock_sleep+0x124 _mtx_lock_flags() at _mtx_lock_flags+0xae vn_syncer_add_to_worklist() at vn_syncer_add_to_worklist+0x3d reassignbuf() at reassignbuf+0x12c bdirty() at bdirty+0x50 softdep_disk_write_complete() at softdep_disk_write_complete+0x19f bufdone_finish() at bufdone_finish+0x2d bufdone() at bufdone+0x6c g_io_schedule_up() at g_io_schedule_up+0xce g_up_procbody() at g_up_procbody+0x72 fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff85d8a93bb0, rbp = 0 --- Uptime: 1m59s Dumping 1219 out of 24477 MB:panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep Fatal double fault rip = 0x807ac9d5 rsp = 0xff85d8a9 rbp = 0xff85d8a90020 cpuid = 26; apic id = 2a panic: double fault cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s panic: msleep cpuid = 26 Uptime: 1m59s Rebooting... cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 26 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: branch 9 and uefi
Thanks all for respond! I'd try to mix answers and not bother you with no reason. You don't say how big your hard drive is, and if you want to run any OS besides FreeBSD. It shall be ssd drive of 64 gb. Freebsd only, as about 10 years long. You can go into the guided installer to see what it wants to do but are better off selecting partition sizes outside the guided installer. I suspect it has to go the way sysinstall takes. In fact, I never went over borders partitions made. I was able to boot the FreeBSD installer USB stick using the memstick image, and am able to boot the USB-stick FreeBSD installations I've created. I will install on ssd. Plan is not to have dvd/cd at all. UEFI worked for me during my first installation on a UEFI machine. I moved then to 10 and still have no problems. Great! Just what I want to hear! Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: branch 9 and uefi
I'm running a M5A97 Evo just fine on -CURRENT, and I'd be shocked it it had any problem with 9 (or 8 or 7, for that matter). Hurrah! I shall get a bit cheaper version, plain m5a97 or pro. Let me ask you further. What option you chose during install? Guided or manual (and what if manual)? Further, what ram did you put on the board? It proved to be picky regarding memory. Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mfi(4) IO performance regression, post 8.1
Hi Alexander, I'm worried that this won't be the only source of freebsd is slower than linux issues. What can we add to the timer path to make identifying and root causing this issue easy? I'd just like to be absolutely sure that we're not only doing the best job possible, but we can provide some tools and statistics to the user/administrator so as to make debugging much easier. Thanks, Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mfi(4) IO performance regression, post 8.1
On 20.07.2012 16:38, Alexander Motin wrote:
On 19.07.2012 18:28, Adrian Chadd wrote:
Hm! A timer related bug?
I'll CC mav@ on this, as it was his commit (and work in his general
area.)
I wonder what's going on - is it something to do with the two ACPI
calls inserted there, or is it something to do with the change in
event timer values?
mav? Any ideas?
I can just agree with earlier made guess that for some reason ACPI timer
on that system is very slow. Unless user explicitly enabled deeper
C-states, values returned by the timer are not really used for anything,
so there is just no place for other bug.
When doing this change I was expecting that it may have cost, but on
most systems that cost makes effect only during high interrupt rates,
where it is covered by automatic fallback to using faster MWAIT as idle
method. Unluckily, that code still was not merged to 8-STABLE (only 9).
I will recheck is there problem to merge it now.
I've just merged that to 8-STABLE at r238658. Testers are welcome.
Manual switching to MWAIT via sysctl is correct workaround for this
situation. It may give slightly higher power consumption, but for this
workload with many interrupts probably the best possible performance.
On 17 July 2012 13:39, Steve McCoy smc...@greatbaysoftware.com wrote:
Alright, I've finally narrowed it down to r209897, which only affects
acpi_cpu_idle():
--- stable/8/sys/dev/acpica/acpi_cpu.c 2010/06/23 17:04:42 209471
+++ stable/8/sys/dev/acpica/acpi_cpu.c 2010/07/11 11:58:46 209897
@@ -930,12 +930,16 @@
/*
* Execute HLT (or equivalent) and wait for an interrupt. We
can't
- * calculate the time spent in C1 since the place we wake up is an
- * ISR. Assume we slept half of quantum and return.
+ * precisely calculate the time spent in C1 since the place we
wake up
+ * is an ISR. Assume we slept no more then half of quantum.
*/
if (cx_next-type == ACPI_STATE_C1) {
- sc-cpu_prev_sleep = (sc-cpu_prev_sleep * 3 + 50 / hz) / 4;
+ AcpiHwRead(start_time, AcpiGbl_FADT.XPmTimerBlock);
acpi_cpu_c1();
+ AcpiHwRead(end_time, AcpiGbl_FADT.XPmTimerBlock);
+end_time = acpi_TimerDelta(end_time, start_time);
+ sc-cpu_prev_sleep = (sc-cpu_prev_sleep * 3 +
+ min(PM_USEC(end_time), 50 / hz)) / 4;
return;
}
My current guess is that AcpiHwRead() is a problem on our hardware.
It's an
isolated change and, to my desperate eyes, the commit message implies
that
it isn't critical — Do you think we could buy ourselves some time by
pulling
it out of our version of the kernel? Or is this essential for
correctness?
Any thoughts are appreciated, thanks!
--
Alexander Motin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mfi(4) IO performance regression, post 8.1
Hi. On 20.07.2012 22:38, Adrian Chadd wrote: I'm worried that this won't be the only source of freebsd is slower than linux issues. What can we add to the timer path to make identifying and root causing this issue easy? I'd just like to be absolutely sure that we're not only doing the best job possible, but we can provide some tools and statistics to the user/administrator so as to make debugging much easier. The only instrument to diagnose this problem without provided input I could propose is hwpmc profiling. It should be able to show that we are spending much time in those timer routines. If we guessed somehow that reason is in slow ACPI timer, it is easy to write respective benchmark, but we can't write tests for everything, and even if we could, users won't be able to run/analyze output of them without some level of knowledge. I've spent much time profiling that on hardware I have, but the only way to be sure in general case I see is more testing and feedbacks. For this specific area I am using very simple test, that effectively depends on interrupt latency and CPUs wakeup times: `dd if=/dev/ada0 of=/dev/null bs=512`. Depending on device, controller and other factors, gives me about 20-30K IOPS. If you have some ideas what and how could we test automatically -- welcome. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Checksum errors across ZFS array
On 19 Jul 2012, at 18:15, James Snow wrote: On Thu, Jul 19, 2012 at 06:05:32PM +0100, Dr Joe Karthauser wrote: Hi James, It's almost definitely a memory problem. I'd change it ASAP if I were you. I lost about 70mb from my zfs pool for this very reason just a few weeks ago. Luckily I had enough snapshots from before the rot set in to recover most of what I lost. Thanks for the input. I will run a memory test against it. If I may, why almost definitely a memory problem and not an issue with the controller? (Or did you mean the controller memory?) Hey Snow, Ok, it's not definitely. Of course, it could be anything. But, memory is where I'd look first. Take care though, my system which had been working fine for about a year when I noticed the ZFS rot (which all appears to be recent in time). I ran memcheck+ on it for 8 hours or so, and it showed no errors at all. However, when I replaced the memory with a different vendor the problems went away. (Reboots and power off/on restarts hadn't fixed the problem before!). So, take care if the memory doesn't report any failures, it might still be faulty. Joe p.s. It was my fault that I wasn't running ECC memory on the system! :/. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Checksum errors across ZFS array
On Fri, Jul 20, 2012 at 04:09:28PM +0100, Dr Josef Karthauser wrote: Take care though, my system which had been working fine for about a year when I noticed the ZFS rot (which all appears to be recent in time). I ran memcheck+ on it for 8 hours or so, and it showed no errors at all. However, when I replaced the memory with a different vendor the problems went away. (Reboots and power off/on restarts hadn't fixed the problem before!). So, take care if the memory doesn't report any failures, it might still be faulty. I've run memtest for about 20 hours now (13 hours in one pass, 7 and counting on the second) and seen no errors. Hrm. p.s. It was my fault that I wasn't running ECC memory on the system! I am running ECC memory though. If you'd had ECC memory to start do you think you might have seen a different result? In my case, replacing all the RAM and getting a 2nd controller are almost the same cost. Since a second controller will give me the best visibility - or long-term expandability if it turns out not to be the controller - I've gone ahead and ordered one. If I move half the disks to the new controller and continue to see the problems only on the old controller, I know it's the controller or the slot on the motherboard. If the problem continues without any change, I can replace RAM, and then the motherboard. -Snow ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD 9.1 Beta 1 fails to install in qemu-kvm on Gentoo Linux
Dear FreeBSD Developers, Trying to install FreeBSD 9.1 Beta 1 in qemu-kvm on Gentoo Linux fails before the kernel dmesg with 'kernel trap 9 with interrupts disabled'. I am running the following command: qemu-system-x86_64 -drive file=/dev/zvol/rpool/KVM/freebsd,if=scsi-bootorder=c -cdrom/mnt/backup/isos/FreeBSD-9.1-BETA1-amd64-disc1.iso -m2048 -smp 6,cores=6,threads=1,sockets=1 -curses -net nic,model=e1000,macaddr=52:54:00:00:ee:04 -cpu host If I use FreeBSD-9.0-RELEASE-amd64-dvd1.iso, I can do an install without any problems. Yours truly, Richard Yao signature.asc Description: OpenPGP digital signature
Re: Checksum errors across ZFS array
On 07/20/2012 15:22, James Snow wrote: I've run memtest for about 20 hours now (13 hours in one pass, 7 and counting on the second) and seen no errors. Hrm. You probably know this already, but just in case ... Software memory tests cannot tell you conclusively that memory is good, only that it's bad. To make sure it's good you need a hardware tester. hth, Doug -- Change is hard. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Checksum errors across ZFS array
On Fri, Jul 20, 2012 at 03:46:21PM -0700, Doug Barton wrote: You probably know this already, but just in case ... Software memory tests cannot tell you conclusively that memory is good, only that it's bad. I may have known that in a past life but certainly wasn't thinking about it now. To make sure it's good you need a hardware tester. Is there one you'd recommend? -Snow ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Checksum errors across ZFS array
- Original Message - From: Dr Josef Karthauser j...@tao.org.uk So, take care if the memory doesn't report any failures, it might still be faulty. p.s. It was my fault that I wasn't running ECC memory on the system! :/. We've even seen this with ECC memory. Running the memory in a different machine for 96 hours found a fault though. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.1 Beta 1 fails to install in qemu-kvm on Gentoo Linux
On 07/20/2012 06:23 PM, Richard Yao wrote: Dear FreeBSD Developers, Trying to install FreeBSD 9.1 Beta 1 in qemu-kvm on Gentoo Linux fails before the kernel dmesg with 'kernel trap 9 with interrupts disabled'. I am running the following command: qemu-system-x86_64 -drive file=/dev/zvol/rpool/KVM/freebsd,if=scsi-bootorder=c -cdrom/mnt/backup/isos/FreeBSD-9.1-BETA1-amd64-disc1.iso -m2048 -smp 6,cores=6,threads=1,sockets=1 -curses -net nic,model=e1000,macaddr=52:54:00:00:ee:04 -cpu host If I use FreeBSD-9.0-RELEASE-amd64-dvd1.iso, I can do an install without any problems. Yours truly, Richard Yao I have an update. 1. There is no backtrace. The only thing that I see printed after the boot screen with beastie is a single line: 'kernel trap 9 with interrupts disabled' 2. Verbose mode does not change it. 3. Removing `-cpu host` fixes it. Here is an excerpt of the host's /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 10 model name : AMD Phenom(tm) II X6 1090T Processor stepping: 0 microcode : 0x1dc cpu MHz : 1600.000 cache size : 512 KB physical id : 0 siblings: 6 core id : 0 cpu cores : 6 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_l m cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb npt lbrv svm_lock nrip_save pausefilter bogomips: 6421.39 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate [9] FreeBSD 9.0 had no problems in KVM with `-cpu host` on this system, so this would seem to be a regression. signature.asc Description: OpenPGP digital signature
Re: stable/9 panic Bad tailq NEXT(0xffffffff80e52660-tqh_last) != NULL
On Mon, 2012-07-16 at 02:39 -0700, Andriy Gapon wrote: on 13/07/2012 19:31 Sean Bruno said the following: Well this is new. I haven't a clue what Dell has done on this R620, but this popped up today after I did a boat load of BIOS updates and tried to install stable/9 from our yahoo tree. If anyone sees the obvious solution here, I'd love to figure it out. found- vendor=0x14e4, dev=0x165f, revid=0x00 domain=0, bus=2, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=6 powerspec 3 supports D0 D3 current D0 MSI supports 8 messages, 64 bit MSI-X supports 17 messages in map 0x20 map[10]: type Prefetchable Memory, range 64, base 0xd50d, size 16, enabled pcib1: allocated prefetch range (0xd50d-0xd50d) for rid 10 of pci0:2:0:1 map[18]: type Prefetchable Memory, range 64, base 0xd50e, size 16, enabled pcib1: allocated prefetch range (0xd50e-0xd50e) for rid 18 of pci0:2:0:1 map[20]: type Prefetchable Memory, range 64, base 0xd50f, size 16, enabled pcib1: allocated prefetch range (0xd50f-0xd50f) for rid 20 of pci0:2:0:1 pcib1: matched entry for 2.0.INTB pcib1: slot 0 INTB hardwired to IRQ 36 bge0: Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572 mem 0xd50a-0xd50a,0xd50b-0xd50b,0xd50c-0xd50c irq 34 at device 0.0 on pci2 bge0: APE FW version: NCSI v1.0.80.0 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 bge0: using IRQ 264 for MSI bge0: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: MII bus on bge0 brgphy0: BCM5720C 1000BASE-T media interface PHY 1 on miibus0 brgphy0: OUI 0x001be9, model 0x0036, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: 18:03:73:fd:9e:36 bge1: Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572 mem 0xd50d-0xd50d,0xd50e-0xd50e,0xd50f-0xd50f irq 36 at device 0.1 on pci2 bge1: APE FW version: NCSI v1.0.80.0 bge1: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 60 bge1: using IRQ 265 for MSI bge1: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E bge1: Disabling fastboot bge1: Disabling fastboot miibus1: MII bus on bge1 brgphy1: BCM5720C 1000BASE-T media interface PHY 2 on miibus1 brgphy1: OUI 0x001be9, model 0x0036, rev. 0 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: bpf attached bge1: Ethernet address: 18:03:73:fd:9e:37 pcib2: ACPI PCI-PCI bridge irq 53 at device 1.1 on pci0 pcib0: allocated type 3 (0xd880-0xd8ff) for rid 20 of pcib2 pcib0: allocated type 3 (0xd510-0xd51f) for rid 24 of pcib2 pcib2: domain0 pcib2: secondary bus 1 pcib2: subordinate bus 1 pcib2: memory decode 0xd880-0xd8ff pcib2: prefetched decode 0xd510-0xd51f pci1: ACPI PCI bus on pcib2 pci1: domain=0, physical bus=1 found- vendor=0x14e4, dev=0x165f, revid=0x00 domain=0, bus=1, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 powerspec 3 supports D0 D3 current D0 MSI supports 8 messages, 64 bit MSI-X supports 17 messages in map 0x20 map[10]: type Prefetchable Memory, range 64, base 0xd51a, size 16, enabled pcib2: allocated prefetch range (0xd51a-0xd51a) for rid 10 of pci0:1:0:0 map[18]: type Prefetchable Memory, range 64, base 0xd51b, size 16, enabled pcib2: allocated prefetch range (0xd51b-0xd51b) for rid 18 of pci0:1:0:0 map[20]: type Prefetchable Memory, range 64, base 0xd51c, size 16, enabled pcib2: allocated prefetch range (0xd51c-0xd51c) for rid 20 of pci0:1:0:0 pcib2: matched entry for 1.0.INTA pcib2: slot 0 INTA hardwired to IRQ 35 found- vendor=0x14e4, dev=0x165f, revid=0x00 domain=0, bus=1, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=6 powerspec 3 supports D0 D3 current D0 MSI supports 8 messages, 64 bit MSI-X supports 17 messages in map 0x20
Re: FreeBSD 9.1 Beta 1 fails to install in qemu-kvm on Gentoo Linux
On Fri, Jul 20, 2012 at 08:40:30PM -0400, Richard Yao wrote: On 07/20/2012 06:23 PM, Richard Yao wrote: Dear FreeBSD Developers, Trying to install FreeBSD 9.1 Beta 1 in qemu-kvm on Gentoo Linux fails before the kernel dmesg with 'kernel trap 9 with interrupts disabled'. I am running the following command: qemu-system-x86_64 -drive file=/dev/zvol/rpool/KVM/freebsd,if=scsi-bootorder=c -cdrom/mnt/backup/isos/FreeBSD-9.1-BETA1-amd64-disc1.iso -m2048 -smp 6,cores=6,threads=1,sockets=1 -curses -net nic,model=e1000,macaddr=52:54:00:00:ee:04 -cpu host If I use FreeBSD-9.0-RELEASE-amd64-dvd1.iso, I can do an install without any problems. Yours truly, Richard Yao I have an update. 1. There is no backtrace. The only thing that I see printed after the boot screen with beastie is a single line: 'kernel trap 9 with interrupts disabled' This line is probably printed after the banner and might be CPU features line. Is this true ? If so, show it. 2. Verbose mode does not change it. 3. Removing `-cpu host` fixes it. Here is an excerpt of the host's /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 10 model name : AMD Phenom(tm) II X6 1090T Processor stepping: 0 microcode : 0x1dc cpu MHz : 1600.000 cache size : 512 KB physical id : 0 siblings: 6 core id : 0 cpu cores : 6 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_l m cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb npt lbrv svm_lock nrip_save pausefilter bogomips: 6421.39 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate [9] FreeBSD 9.0 had no problems in KVM with `-cpu host` on this system, so this would seem to be a regression. Can you boot FreeBSD kernel on this machine bare ? Also it could be useful to show the CPU features lines from FreeBSD 9.0, or just full verbose dmesgs of the boots in KVM with and without -cpu host. pgpsuVKrx50lf.pgp Description: PGP signature
Re: Recommendation for Hyervisor to host FreeBSD
On Thu, Jul 5, 2012 at 10:43 PM, Rainer Duffner rai...@ultra-secure.de wrote: Am Thu, 05 Jul 2012 12:43:06 +0100 schrieb Pete French petefre...@ingresso.co.uk: So, my work surprise for a Thursday morning is an urgent requirement to see if we can run a set of FreeBSD machines under virtualised servers. I have not done this before personally, but I notice from post here that it doesnt seem uncommon, and I see Xen related commits flowing past, so I am guessing it is doable. So, for running 8 or 9 STABLE can anyone recommend which hypervisor works best, and is 8 or 9 better as the OS to run ? Am doing a bit of research myself, but nothing beats persoanl experience in these matters! AFAIK, there are no VMware-tools for FreeBSD9 (yet). So, if you need to use ESXi/vSphere, then stay with 8.3 for the time being. We have had a lot of success and good performance deploying under ESXi - often without the VM tools package installed. Also, full, native support for MSFT-HyperV is coming to FreeBSD9. Isn't this supposed to be on 8.2 and 8.3 as well (per the official announcement)? I am awaiting further announcement on this as I have a lot of our clients / prospective clients who run HyperV environments who want to deploy on this. Last time we tried on 8.1 the OS would crash with memory corruption errors, which happened across multiple test systems... http://blogs.technet.com/b/openness/archive/2012/05/10/freebsd-support-on-windows-server-hyper-v.aspx -- Antony ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.1 Beta 1 fails to install in qemu-kvm on Gentoo Linux
On 07/20/2012 08:56 PM, Konstantin Belousov wrote: On Fri, Jul 20, 2012 at 08:40:30PM -0400, Richard Yao wrote: On 07/20/2012 06:23 PM, Richard Yao wrote: Dear FreeBSD Developers, Trying to install FreeBSD 9.1 Beta 1 in qemu-kvm on Gentoo Linux fails before the kernel dmesg with 'kernel trap 9 with interrupts disabled'. I am running the following command: qemu-system-x86_64 -drive file=/dev/zvol/rpool/KVM/freebsd,if=scsi-bootorder=c -cdrom/mnt/backup/isos/FreeBSD-9.1-BETA1-amd64-disc1.iso -m2048 -smp 6,cores=6,threads=1,sockets=1 -curses -net nic,model=e1000,macaddr=52:54:00:00:ee:04 -cpu host If I use FreeBSD-9.0-RELEASE-amd64-dvd1.iso, I can do an install without any problems. Yours truly, Richard Yao I have an update. 1. There is no backtrace. The only thing that I see printed after the boot screen with beastie is a single line: 'kernel trap 9 with interrupts disabled' This line is probably printed after the banner and might be CPU features line. Is this true ? If so, show it. I do not know what the banner is. However, that line is printed immediately after the boot2 menu with Beastie. It occurs when I would expect to see Copyright (c) 1992-2012 The FreeBSD Project.. I see no other visible characters aside from those from the boot2 menu with Beastie. 2. Verbose mode does not change it. 3. Removing `-cpu host` fixes it. Here is an excerpt of the host's /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 10 model name : AMD Phenom(tm) II X6 1090T Processor stepping: 0 microcode : 0x1dc cpu MHz : 1600.000 cache size : 512 KB physical id : 0 siblings: 6 core id : 0 cpu cores : 6 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_l m cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb npt lbrv svm_lock nrip_save pausefilter bogomips: 6421.39 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate [9] FreeBSD 9.0 had no problems in KVM with `-cpu host` on this system, so this would seem to be a regression. Can you boot FreeBSD kernel on this machine bare ? This machine is headless. It would be difficult for me to boot FreeBSD on it. Also it could be useful to show the CPU features lines from FreeBSD 9.0, or just full verbose dmesgs of the boots in KVM with and without -cpu host. Here is the dmesg output from FreeBSD 9.0-RELEASE with -cpu host: Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: AMD Phenom(tm) II X6 1090T Processor (3210.86-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100fa0 Family = 10 Model = a Stepping = 0 Features=0x1783fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT Features2=0x80802001SSE3,CX16,POPCNT,HV AMD Features=0xe6500800SYSCALL,NX,MMX+,FFXSR,Page1GB,LM,3DNow!+,3DNow! AMD Features2=0x1f7LAHF,CMP,SVM,CR8,ABM,SSE4A,MAS,Prefetch real memory = 2147483648 (2048 MB) avail memory = 2045132800 (1950 MB) Event timer LAPIC quality 400 ACPI APIC Table: BOCHS BXPCAPIC FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs FreeBSD/SMP: 1 package(s) x 6 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 ioapic0: Changing APIC ID to 6 ioapic0 Version 1.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: BOCHS BXPCRSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0xb008-0xb00b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 cpu4: ACPI CPU on acpi0 cpu5: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci_link4: Unable to route IRQs: AE_NOT_FOUND isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX3 WDMA2 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc140-0xc14f at device 1.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 pci0: bridge at device
