Re: vt and VirtualBox?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05.01.2015 20:33, Jung-uk Kim wrote: This driver looks empty to me :) I meant: https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux/drm Yes, I understand. I've wrote about this one that it seems empty. No big method tables, no custom vbox-related code, nothing, looks like driver skeleton. - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUq8OcXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP1noQAMT0QQTbT8oBDn1C/AsNH15b fs0vz/BbEkM3KrHSrOYHR1CRmupBCHunzbaIUn0emooSjI4HSHSHLzd6JQ4P6mAw iSs7hmDvu7wJqoQyQpKfh99ZMnSl46PeR7uhlP9yJ8M+nCs5pIJNLVWMc+bclHi2 5Bb0X3K0eChuMP44GqIBBTABejXX+jsE8/0XUAilutLmFbHzdB9Il6YINFb2fb08 yyL4BDqpbiVQT4M4M9tFO88QvBej6lAAnNExAkdJdIj/KBHGsZOz0Ky+IWwQHfIi ErlKr8EcVgxYVBMat1eUQA66uwclr8aJm2mGHXAlDiFSAbi/r17irdjVdgSM9EZ9 Ga7EJ4vLZIpyDvzXmaVqvBXtmaNbqaiOPg6HsXgfkSGt49x8V5Vocw4hqk/R6jDa dhFEUZzvmxkuq70XywoYT1mt1kqzl0h83A5/c8fcPjeoxQMG5cfPl5q5iGiW9DjV 0NBC8nc+Qm1evu9DZO0jz0QCEWmmyUJxLsQjtsJkEpUWGc62TJXE6sz4KyQY9qvW jYVAI9OhQQVwLd7p7LKbRuePb43kNmAvCw6PGIb6r/EhqVurYf/l0zx3uzRkx06D dbg+3OvXa7eq5vkNnJiFslai6DGXbulOpH6ksOuNBKq2Pfw0xu+lilEHtkyEcbJy imtO+NSzbzgAlgS41kN1 =mOlA -END PGP SIGNATURE- ___ 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: [RFC] Start SMP subsystem earlier
On 1/5/15 8:18 AM, Hans Petter Selasky wrote: Hi, There is a limitiation on the number of interrupt vectors available when only a single processor is running. To have more interrupts available we need to start SMP earlier when building a monotolith kernel and not loading drivers as modules. The driver in question is a network driver and because it cannot be started after SI_SUB_ROOT_CONF due to PXE support I see no other option than to move SI_SUB_SMP earlier. Suggested patch: Index: sys/kernel.h === --- sys/kernel.h(revision 276691) +++ sys/kernel.h(working copy) @@ -152,6 +152,7 @@ SI_SUB_KPROF= 0x900,/* kernel profiling*/ SI_SUB_KICK_SCHEDULER= 0xa00,/* start the timeout events*/ SI_SUB_INT_CONFIG_HOOKS= 0xa80,/* Interrupts enabled config */ +SI_SUB_SMP= 0xa85,/* start the APs*/ SI_SUB_ROOT_CONF= 0xb00,/* Find root devices */ SI_SUB_DUMP_CONF= 0xb20,/* Find dump devices */ SI_SUB_RAID= 0xb38,/* Configure GEOM classes */ @@ -165,7 +166,6 @@ SI_SUB_KTHREAD_BUF= 0xea0,/* buffer daemon*/ SI_SUB_KTHREAD_UPDATE= 0xec0,/* update daemon*/ SI_SUB_KTHREAD_IDLE= 0xee0,/* idle procs*/ -SI_SUB_SMP= 0xf00,/* start the APs*/ SI_SUB_RACCTD= 0xf10,/* start racctd*/ SI_SUB_LAST= 0xfff/* final initialization */ }; This fixes a problem for Mellanox drivers in the OFED layer. Possibly we need to move the SMP even earlier to not miss the generic FreeBSD PCI device enumeration or maybe this is not possible. Does anyone know how early we can start SMP? We need a lot more work before this is ready. This is one of the goals of the multipass new-bus stuff. In particular, we have to enumerate enough devices to bring event timer hardware up so that timer interrupts work so that tsleep() will actually sleep. In addition, we also need idle threads created and working before APs are started as otherwise they will have no thread to run initially. This is certainly a desired feature, but it is not as simple as moving the sysinit up I'm afraid. -- John Baldwin ___ 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: Haswell CPU Feature
On 1/6/15 12:44 AM, Jia-Shiun Li wrote: On Tue, Jan 6, 2015 at 1:23 PM, Neel Natu neeln...@gmail.com wrote: Hi Sean, On Mon, Jan 5, 2015 at 6:34 PM, Sean Bruno sbr...@ignoranthack.me wrote: I'm thinking something like this: Index: sys/x86/x86/identcpu.c === - --- sys/x86/x86/identcpu.c(revision 276729) +++ sys/x86/x86/identcpu.c (working copy) @@ -781,7 +781,7 @@ \011TM2 /* Thermal Monitor 2 */ \012SSSE3 /* SSSE3 */ \013CNXT-ID /* L1 context ID available */ - - \014b11 + \014SDBG /* IA32_DEBUG_INTERFACE debug*/ \015FMA /* Fused Multiply Add */ \016CX16 /* CMPXCHG16B Instruction */ \017xTPR /* Send Task Priority Messages*/ Looks good. Maybe also this for completeness? # svnlite diff Index: sys/x86/include/specialreg.h === --- sys/x86/include/specialreg.h(revision 276737) +++ sys/x86/include/specialreg.h(working copy) @@ -154,6 +154,7 @@ #defineCPUID2_TM2 0x0100 #defineCPUID2_SSSE30x0200 #defineCPUID2_CNXTID 0x0400 +#defineCPUID2_SDBG 0x0800 #defineCPUID2_FMA 0x1000 #defineCPUID2_CX16 0x2000 #defineCPUID2_XTPR 0x4000 Yes, please include both. SDBG matches the label in the Intel SDM, so that's the preferred name. -- John Baldwin ___ 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
iwn0: iwn_panicked: controller panicked, iv_state = 5; resetting...
One of the things I've noticed for a bit (but failed ot mention, as it's been something I find difficult to describe adequately) is that when I run head on my laptop -- generally, just to perform a source-based upgrade-in-place (so it tends to be rather busy), the machine acts as if it's failing to pay attention to some of the interrupts sometimes. E.g., moving the mouse is extremely laggy jerky (with a fair amount of overshooting once the position settles). And the wireless NIC (iwn) will often lose ... well, everything it can. And I'm seeing messages such as this in /var/log/messages: ... Jan 6 06:24:12 g1-253 kernel: iwn0: iwn_read_firmware: ucode rev=0x08530501 Jan 6 06:24:14 g1-253 kernel: iwn0: iwn_tx_data: m=0xd2a33c00: seqno (25151) (63) != ring index (0) ! Jan 6 06:24:14 g1-253 kernel: iwn0: iwn_intr: fatal firmware error Jan 6 06:24:14 g1-253 kernel: firmware error log: Jan 6 06:24:14 g1-253 kernel: error type = SYSASSERT (0x0005) Jan 6 06:24:14 g1-253 kernel: program counter = 0xC210 Jan 6 06:24:14 g1-253 kernel: source line = 0x0E4E Jan 6 06:24:14 g1-253 kernel: error data = 0x0E4E Jan 6 06:24:14 g1-253 kernel: branch link = 0xC128C128 Jan 6 06:24:14 g1-253 kernel: interrupt link = 0x0916 Jan 6 06:24:14 g1-253 kernel: time= 1199025467 Jan 6 06:24:14 g1-253 kernel: driver status: Jan 6 06:24:14 g1-253 kernel: tx ring 0: qid=0 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 1: qid=1 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 2: qid=2 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 3: qid=3 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 4: qid=4 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 5: qid=5 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 6: qid=6 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 7: qid=7 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 8: qid=8 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 9: qid=9 cur=28 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 10: qid=10 cur=1 queued=1 Jan 6 06:24:14 g1-253 kernel: tx ring 11: qid=11 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 12: qid=12 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 13: qid=13 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 14: qid=14 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 15: qid=15 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 16: qid=16 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 17: qid=17 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 18: qid=18 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: tx ring 19: qid=19 cur=0 queued=0 Jan 6 06:24:14 g1-253 kernel: rx ring: cur=32 Jan 6 06:24:14 g1-253 kernel: iwn0: iwn_panicked: controller panicked, iv_state = 5; resetting... Jan 6 06:24:14 g1-253 kernel: iwn0: iwn_read_firmware: ucode rev=0x08530501 Jan 6 06:24:16 g1-253 kernel: iwn0: iwn_tx_data: m=0xd2a41500: seqno (25152) (64) != ring index (0) ! Jan 6 06:24:16 g1-253 kernel: iwn0: iwn_intr: fatal firmware error Jan 6 06:24:16 g1-253 kernel: firmware error log: Jan 6 06:24:16 g1-253 kernel: error type = SYSASSERT (0x0005) Jan 6 06:24:16 g1-253 kernel: program counter = 0xC210 Jan 6 06:24:16 g1-253 kernel: source line = 0x0E4E Jan 6 06:24:16 g1-253 kernel: error data = 0x0E4E Jan 6 06:24:16 g1-253 kernel: branch link = 0xC128C128 Jan 6 06:24:16 g1-253 kernel: interrupt link = 0x0916 Jan 6 06:24:16 g1-253 kernel: time= 1201317618 Jan 6 06:24:16 g1-253 kernel: driver status: Jan 6 06:24:16 g1-253 kernel: tx ring 0: qid=0 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 1: qid=1 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 2: qid=2 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 3: qid=3 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 4: qid=4 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 5: qid=5 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 6: qid=6 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 7: qid=7 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 8: qid=8 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 9: qid=9 cur=27 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 10: qid=10 cur=1 queued=1 Jan 6 06:24:16 g1-253 kernel: tx ring 11: qid=11 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 12: qid=12 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 13: qid=13 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 14: qid=14 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 15: qid=15 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 16: qid=16 cur=0 queued=0 Jan 6 06:24:16 g1-253 kernel: tx ring 17: qid=17 cur=0 queued=0 Jan 6 06:24:16 g1-253
Re: any primer on running bhyve guests sharing disk with host ?
On 1/3/15 1:43 PM, Craig Rodrigues wrote:
On Sat, Jan 3, 2015 at 8:15 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
Hi,
in order to do some kernel testing, I would like to run bhyve guests
using (through NFS, probably) the host's file system.
diskless(8) is probably one way to go, i was wondering if
someone has instructions for that.
Specifically:
- how to bhyveload a kernel (rather than the full disk image);
as an alternative, given a kernel, something to build an image
that can be passed to bhyveload
- how to pass the necessary config (rootpath) to the client
without having to rely on a specialized dhcp server
I used to be familiar with diskless configs, so i can probably sort
out the server side myself.
Neel already covered -h with bhyveload which you can also use with -H
to vmrun.sh, though the other way I do this is to NFS export my work
tree from the host to the guest so I can run kgdb on the host but do the
build / install in the guest itself.
I don't think there is a way to do exactly what you want.
I would recommend doing the following:
(1) Enable bvmdebug in your kernel config:
https://wiki.freebsd.org/BHyVe/gdb
This allows you to do kgdb remote debugging into a bhyve VM.
At this point it is probably simpler to use the serial port instead. I
have hacked up vmrun.sh locally to always create a /dev/nmdmvmname2B
device hooked up to com2 and to add 0x80 to the flags for uart1 in
device.hints in all my VMs. You can then use kgdb from the host and
'target remote /dev/nmdmvmname2A'.
--- /usr/share/examples/bhyve/vmrun.sh 2014-11-20 18:38:34.0 -0500
+++ /home/john/bhyve/vmrun.sh 2015-01-06 09:54:47.0 -0500
@@ -230,6 +230,9 @@
nextslot=$(($nextslot + 1))
i=$(($i + 1))
done
+ if kldstat -qm nmdm; then
+ devargs=$devargs -l com2,/dev/nmdm${vmname}2B
+ fi
${FBSDRUN} -c ${cpus} -m ${memsize} ${apic_opt} -A -H -P\
-g ${gdbport} \
--
John Baldwin
___
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: [RFC] Start SMP subsystem earlier
On 01/06/15 15:37, John Baldwin wrote: We need a lot more work before this is ready. This is one of the goals of the multipass new-bus stuff. In particular, we have to enumerate enough devices to bring event timer hardware up so that timer interrupts work so that tsleep() will actually sleep. In addition, we also need idle threads created and working before APs are started as otherwise they will have no thread to run initially. This is certainly a desired feature, but it is not as simple as moving the sysinit up I'm afraid. Got it. Thank you! --HPS ___ 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: [RFC] Start SMP subsystem earlier
On Tue, Jan 06, 2015 at 09:37:30AM -0500, John Baldwin wrote: On 1/5/15 8:18 AM, Hans Petter Selasky wrote: Hi, There is a limitiation on the number of interrupt vectors available when only a single processor is running. To have more interrupts available we need to start SMP earlier when building a monotolith kernel and not loading drivers as modules. The driver in question is a network driver and because it cannot be started after SI_SUB_ROOT_CONF due to PXE support I see no other option than to move SI_SUB_SMP earlier. Suggested patch: Index: sys/kernel.h === --- sys/kernel.h(revision 276691) +++ sys/kernel.h(working copy) @@ -152,6 +152,7 @@ SI_SUB_KPROF= 0x900,/* kernel profiling*/ SI_SUB_KICK_SCHEDULER= 0xa00,/* start the timeout events*/ SI_SUB_INT_CONFIG_HOOKS= 0xa80,/* Interrupts enabled config */ +SI_SUB_SMP= 0xa85,/* start the APs*/ SI_SUB_ROOT_CONF= 0xb00,/* Find root devices */ SI_SUB_DUMP_CONF= 0xb20,/* Find dump devices */ SI_SUB_RAID= 0xb38,/* Configure GEOM classes */ @@ -165,7 +166,6 @@ SI_SUB_KTHREAD_BUF= 0xea0,/* buffer daemon*/ SI_SUB_KTHREAD_UPDATE= 0xec0,/* update daemon*/ SI_SUB_KTHREAD_IDLE= 0xee0,/* idle procs*/ -SI_SUB_SMP= 0xf00,/* start the APs*/ SI_SUB_RACCTD= 0xf10,/* start racctd*/ SI_SUB_LAST= 0xfff/* final initialization */ }; This fixes a problem for Mellanox drivers in the OFED layer. Possibly we need to move the SMP even earlier to not miss the generic FreeBSD PCI device enumeration or maybe this is not possible. Does anyone know how early we can start SMP? We need a lot more work before this is ready. This is one of the goals of the multipass new-bus stuff. In particular, we have to enumerate enough devices to bring event timer hardware up so that timer interrupts work so that tsleep() will actually sleep. In addition, we also need idle threads created and working before APs are started as otherwise they will have no thread to run initially. This is certainly a desired feature, but it is not as simple as moving the sysinit up I'm afraid. I believe that idle threads are still created before the APs start with the patch posted, this was the thing I checked first. It is SUB_SCHED_IDLE, which is done long before even drivers are configured. ___ 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 #2167
See https://jenkins.freebsd.org/job/FreeBSD_HEAD/2167/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
Jenkins build is back to stable : FreeBSD_HEAD-tests2 #521
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/521/ ___ 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: [RFC] kern/kern_timeout.c rewrite in progress
On Sun, Jan 4, 2015 at 1:48 PM, Hans Petter Selasky h...@selasky.org wrote: On 01/04/15 19:58, Adrian Chadd wrote: Hi! Can you throw this into reviews.freebsd.org please? This is something that should be very closely reviewed and tested. (I'm going to go over this quite closely as it related to a lot of the random crap I do ..) Hi Adrian, Here you go: https://reviews.freebsd.org/D1438 Thank you for your time to review this! --HPS Hans, We've been running into 'spin lock held too long' panics in the kernel idle threads on 10-STABLE over the past 6 months, so I was interested to see your work here in the callout code. I went ahead and brought this patch back to a recent 10.1-STABLE base without much issue, kern_timeout.c was actually the only piece with some easily resolvable rejections. I've had a box running stable under load with this patch for a few days, and 10 more have just been added to the rotation. Anyway just figured you might be interested in the some feedback while the changes are reviewed. Thanks! Jason ___ 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: [RFC] Start SMP subsystem earlier
On Tue, 2015-01-06 at 09:37 -0500, John Baldwin wrote: On 1/5/15 8:18 AM, Hans Petter Selasky wrote: Hi, There is a limitiation on the number of interrupt vectors available when only a single processor is running. To have more interrupts available we need to start SMP earlier when building a monotolith kernel and not loading drivers as modules. The driver in question is a network driver and because it cannot be started after SI_SUB_ROOT_CONF due to PXE support I see no other option than to move SI_SUB_SMP earlier. Suggested patch: [...] This fixes a problem for Mellanox drivers in the OFED layer. Possibly we need to move the SMP even earlier to not miss the generic FreeBSD PCI device enumeration or maybe this is not possible. Does anyone know how early we can start SMP? We need a lot more work before this is ready. This is one of the goals of the multipass new-bus stuff. In particular, we have to enumerate enough devices to bring event timer hardware up so that timer interrupts work so that tsleep() will actually sleep. In addition, we also need idle threads created and working before APs are started as otherwise they will have no thread to run initially. This is certainly a desired feature, but it is not as simple as moving the sysinit up I'm afraid. Just an FYI, the ARM world is now using the multipass newbus stuff. It works well, with some quirks... The predefined pass names don't always makes sense for the arm world. There aren't enough predefined pass names and even though the number space for them is 4 billion wide all the predefined names are in the range 100 and separated by only 10 so it's tricky to wedge things between the existing names. The strangest bit is when you have interdependent drivers at different early pass numbers. Sometimes it's necessary to do almost nothing in the attach() routine and do all the real attach-time type stuff in a bus_new_pass() routine after the pass number becomes high enough that your co-dependent driver peers are available. -- Ian ___ 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: [RFC] Start SMP subsystem earlier
On 6 January 2015 at 07:55, Ian Lepore i...@freebsd.org wrote: On Tue, 2015-01-06 at 09:37 -0500, John Baldwin wrote: On 1/5/15 8:18 AM, Hans Petter Selasky wrote: Hi, There is a limitiation on the number of interrupt vectors available when only a single processor is running. To have more interrupts available we need to start SMP earlier when building a monotolith kernel and not loading drivers as modules. The driver in question is a network driver and because it cannot be started after SI_SUB_ROOT_CONF due to PXE support I see no other option than to move SI_SUB_SMP earlier. Suggested patch: [...] This fixes a problem for Mellanox drivers in the OFED layer. Possibly we need to move the SMP even earlier to not miss the generic FreeBSD PCI device enumeration or maybe this is not possible. Does anyone know how early we can start SMP? We need a lot more work before this is ready. This is one of the goals of the multipass new-bus stuff. In particular, we have to enumerate enough devices to bring event timer hardware up so that timer interrupts work so that tsleep() will actually sleep. In addition, we also need idle threads created and working before APs are started as otherwise they will have no thread to run initially. This is certainly a desired feature, but it is not as simple as moving the sysinit up I'm afraid. Just an FYI, the ARM world is now using the multipass newbus stuff. It works well, with some quirks... The predefined pass names don't always makes sense for the arm world. There aren't enough predefined pass names and even though the number space for them is 4 billion wide all the predefined names are in the range 100 and separated by only 10 so it's tricky to wedge things between the existing names. Maybe we need a RENUM script? :) -adrian The strangest bit is when you have interdependent drivers at different early pass numbers. Sometimes it's necessary to do almost nothing in the attach() routine and do all the real attach-time type stuff in a bus_new_pass() routine after the pass number becomes high enough that your co-dependent driver peers are available. -- Ian ___ 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: any primer on running bhyve guests sharing disk with host ?
On 1/6/15 10:55 PM, John Baldwin wrote:
On 1/3/15 1:43 PM, Craig Rodrigues wrote:
On Sat, Jan 3, 2015 at 8:15 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
Hi,
in order to do some kernel testing, I would like to run bhyve guests
using (through NFS, probably) the host's file system.
diskless(8) is probably one way to go, i was wondering if
someone has instructions for that.
Specifically:
- how to bhyveload a kernel (rather than the full disk image);
as an alternative, given a kernel, something to build an image
that can be passed to bhyveload
- how to pass the necessary config (rootpath) to the client
without having to rely on a specialized dhcp server
I used to be familiar with diskless configs, so i can probably sort
out the server side myself.
Neel already covered -h with bhyveload which you can also use with -H
to vmrun.sh, though the other way I do this is to NFS export my work
tree from the host to the guest so I can run kgdb on the host but do the
build / install in the guest itself.
I don't think there is a way to do exactly what you want.
I would recommend doing the following:
(1) Enable bvmdebug in your kernel config:
https://wiki.freebsd.org/BHyVe/gdb
This allows you to do kgdb remote debugging into a bhyve VM.
At this point it is probably simpler to use the serial port instead. I
have hacked up vmrun.sh locally to always create a /dev/nmdmvmname2B
device hooked up to com2 and to add 0x80 to the flags for uart1 in
device.hints in all my VMs. You can then use kgdb from the host and
'target remote /dev/nmdmvmname2A'.
I've found the main good part of using bvmdebug is the ability to
attach to it from a different machine using tcp.
I think bhyve should offer the opportunity to make ALL serial ports or
similar be attached to sockets..
--- /usr/share/examples/bhyve/vmrun.sh 2014-11-20 18:38:34.0 -0500
+++ /home/john/bhyve/vmrun.sh 2015-01-06 09:54:47.0 -0500
@@ -230,6 +230,9 @@
nextslot=$(($nextslot + 1))
i=$(($i + 1))
done
+ if kldstat -qm nmdm; then
+ devargs=$devargs -l com2,/dev/nmdm${vmname}2B
+ fi
${FBSDRUN} -c ${cpus} -m ${memsize} ${apic_opt} -A -H -P\
-g ${gdbport} \
___
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
i915 crash
I grabbed the latest i915.8.patch from kib@'s website and compiled it against r276774 (today) Machine is a Lenovo T530, booted UEFI, with the nvidia GPU disabled. CPU: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz (2594.16-MHz K8-class CPU) It is an Ivy-bridge CPU/GPU I installed xorg and kde, and when I try to start KDE, it loads, and gets so far as showing the FreeBSD wallpaper, then panics: text dump: http://www.allanjude.com/bsd/i915_core.3.txt Full dump: (26mb compressed, 740mb original) http://www.allanjude.com/bsd/i915_vmcore.3.xz Unread portion of the kernel message buffer: panic: In GPU write domain cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe045e52e600 vpanic() at vpanic+0x189/frame 0xfe045e52e680 kassert_panic() at kassert_panic+0x132/frame 0xfe045e52e6f0 i915_gem_pread_ioctl() at i915_gem_pread_ioctl+0x678/frame 0xfe045e52e790 drm_ioctl() at drm_ioctl+0x318/frame 0xfe045e52e800 devfs_ioctl_f() at devfs_ioctl_f+0x122/frame 0xfe045e52e860 kern_ioctl() at kern_ioctl+0x2c0/frame 0xfe045e52e8c0 sys_ioctl() at sys_ioctl+0x153/frame 0xfe045e52e9a0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe045e52eab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe045e52eab0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8022a56fa, rsp = 0x7fffe718, rbp = 0x7fffe740 --- KDB: enter: panic Uptime: 9m19s Dumping 739 out of 16176 MB:..3%..11%..22%..31%..42%..52%..61%..72%..81%..91% Reading symbols from /boot/kernel/i915kms.ko.symbols...done. Loaded symbols for /boot/kernel/i915kms.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols Reading symbols from /boot/kernel/iicbus.ko.symbols...done. Loaded symbols for /boot/kernel/iicbus.ko.symbols Reading symbols from /boot/kernel/iic.ko.symbols...done. Loaded symbols for /boot/kernel/iic.ko.symbols Reading symbols from /boot/kernel/iicbb.ko.symbols...done. Loaded symbols for /boot/kernel/iicbb.ko.symbols #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 ) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 ) at pcpu.h:219 #1 0x80965d27 in kern_reboot (howto=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0x80966318 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:747 #3 0x80966142 in kassert_panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:635 #4 0x81e1de88 in i915_gem_pread_ioctl (dev=0xf8002ffd1000, data=0xfe045e52e8f0, file=value optimized out) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:3010 #5 0x81e9a398 in drm_ioctl (kdev=value optimized out, cmd=2149606492, data=0xfe045e52e8f0 y, flags=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:942 #6 0x80849942 in devfs_ioctl_f (fp=0xf80009c15690, com=2149606492, data=0xfe045e52e8f0, cred=0xfe045e52e8f0, td=0xf80009c74000) at /usr/src/sys/fs/devfs/devfs_vnops.c:775 #7 0x809c3ad0 in kern_ioctl (td=0xf80009c74000, fd=value optimized out, com=0, data=value optimized out) at file.h:318 #8 0x809c3763 in sys_ioctl (td=0xf80009c74000, uap=0xfe045e52ea40) at /usr/src/sys/kern/sys_generic.c:718 #9 0x80d8590a in amd64_syscall (td=0xf80009c74000, traced=0) at subr_syscall.c:133 #10 0x80d632ab in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:395 #11 0x0008022a56fa in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: [RFC] Start SMP subsystem earlier
On Tue, 2015-01-06 at 07:57 -0800, Adrian Chadd wrote: On 6 January 2015 at 07:55, Ian Lepore i...@freebsd.org wrote: On Tue, 2015-01-06 at 09:37 -0500, John Baldwin wrote: On 1/5/15 8:18 AM, Hans Petter Selasky wrote: Hi, There is a limitiation on the number of interrupt vectors available when only a single processor is running. To have more interrupts available we need to start SMP earlier when building a monotolith kernel and not loading drivers as modules. The driver in question is a network driver and because it cannot be started after SI_SUB_ROOT_CONF due to PXE support I see no other option than to move SI_SUB_SMP earlier. Suggested patch: [...] This fixes a problem for Mellanox drivers in the OFED layer. Possibly we need to move the SMP even earlier to not miss the generic FreeBSD PCI device enumeration or maybe this is not possible. Does anyone know how early we can start SMP? We need a lot more work before this is ready. This is one of the goals of the multipass new-bus stuff. In particular, we have to enumerate enough devices to bring event timer hardware up so that timer interrupts work so that tsleep() will actually sleep. In addition, we also need idle threads created and working before APs are started as otherwise they will have no thread to run initially. This is certainly a desired feature, but it is not as simple as moving the sysinit up I'm afraid. Just an FYI, the ARM world is now using the multipass newbus stuff. It works well, with some quirks... The predefined pass names don't always makes sense for the arm world. There aren't enough predefined pass names and even though the number space for them is 4 billion wide all the predefined names are in the range 100 and separated by only 10 so it's tricky to wedge things between the existing names. Maybe we need a RENUM script? :) I wanted to renumber them but it was pointed out to me that the existing names and numbers are part of the ABI and we're not free to do so except on -current, and that would make all related work going forward ineligible for MFC. (Personally, I'm a bit skeptical that there's any big out-of-tree use of the existing names/numbers.) -- Ian ___ 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: [RFC] Start SMP subsystem earlier
On 1/6/15 10:55 AM, Ian Lepore wrote: On Tue, 2015-01-06 at 09:37 -0500, John Baldwin wrote: On 1/5/15 8:18 AM, Hans Petter Selasky wrote: Hi, There is a limitiation on the number of interrupt vectors available when only a single processor is running. To have more interrupts available we need to start SMP earlier when building a monotolith kernel and not loading drivers as modules. The driver in question is a network driver and because it cannot be started after SI_SUB_ROOT_CONF due to PXE support I see no other option than to move SI_SUB_SMP earlier. Suggested patch: [...] This fixes a problem for Mellanox drivers in the OFED layer. Possibly we need to move the SMP even earlier to not miss the generic FreeBSD PCI device enumeration or maybe this is not possible. Does anyone know how early we can start SMP? We need a lot more work before this is ready. This is one of the goals of the multipass new-bus stuff. In particular, we have to enumerate enough devices to bring event timer hardware up so that timer interrupts work so that tsleep() will actually sleep. In addition, we also need idle threads created and working before APs are started as otherwise they will have no thread to run initially. This is certainly a desired feature, but it is not as simple as moving the sysinit up I'm afraid. Just an FYI, the ARM world is now using the multipass newbus stuff. It works well, with some quirks... The predefined pass names don't always makes sense for the arm world. There aren't enough predefined pass names and even though the number space for them is 4 billion wide all the predefined names are in the range 100 and separated by only 10 so it's tricky to wedge things between the existing names. The strangest bit is when you have interdependent drivers at different early pass numbers. Sometimes it's necessary to do almost nothing in the attach() routine and do all the real attach-time type stuff in a bus_new_pass() routine after the pass number becomes high enough that your co-dependent driver peers are available. Yes, I almost want another downcall through the tree that is something like 'bus_pass_completed', though the original design was to override bus_new_pass as you have done. And yes, in many cases the logic needs to move out of attach. The pci bus will end up only doing enumeration but no resource assignment in its attach routine once things are fleshed out more for example. However, for now I've found that even on x86 I've had to add a new pass level for ACPI and some other things like acpi_sysresource. :( It almost wants more of a provides-requires setup than hardcoded pass levels, but that's more complicated to implement. -- John Baldwin ___ 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
