Re: Install FreeBSD from source into VM image
Error return from kevent monitor: Not permitted in capability mode ... This sounds like an issue with the bhyve capsicum work. I've cc'd Allan and Peter who might be able to help track that down. It might be useful if you can run bhyve under ktrace, e.g.: sudo ktrace -i -t p sh /usr/share/examples/bhyve/vmrun.sh -d .raw vm- And then post the output of 'sudo kdump' I think this is the error now returned when a file doesn't exist or can't be accessed - the code probably needs to be reworked to test for existence before entering capability mode to make the error more meaningful. later, Peter. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Bug in virtio-net
Hi Shawn, I doubt this has anything to do with vtnet. My guess is that netisr_proto[NETISR_ETHER].np_handler(m) is NULL for some reason. Do you have a dump? core.txt is attached. I've also uploaded it to the link below in case the attachment is scrubbed. http://0xfeedface.org/~shawn/2014-12-08_2028_core.txt Is the core dump available ? As Bryan mentioned, this is a NULL function pointer deref and not a data access so is possibly related to corruption of data structures rather than a bug in the virtio driver. The core dump would be able to point to what went wrong. later, Peter. ___ 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] bind per-cpu timeout threads to each CPU
Yup. I've just done that. http://people.freebsd.org/~adrian/norse/20140509-swi-pin-1.diff Thanks, that'll work. Which workloads are you thinking about? Maybe we could introduce some higher level description of which CPU(s) at boot time to do "freebsd stuff" on, and then don't start things like pcpu swi's and NIC threads on those CPUs. A classic case is partitioning cores into control and data plane groups. I'm sure there are lots more. What's nice about cpuset is that the choice and change can be dynamic, so long as there aren't pinned threads in the default set. An option to restrict FreeBSD pCPU threads to a subset could be useful. Can you think of situations where we'd want to have per-cpu swi's even _running_ for CPUs that you want to dedicate to other things? There's nothing stopping you from scheduling a callout on a different target CPU. At least for the uses I know, it's complete isolation from other processing, kernel threads included. The 'freebsd stuff' info you mentioned should be sufficient. later, Peter. ___ 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] bind per-cpu timeout threads to each CPU
How about i instead do the comprimise: * i'll pin all other swi's * default swi isn't pinned by default, but one can flip on a sysctl at boot time to pin it How's that sound? And also please a sysctl that disables any swi pinning. It is sometimes useful to change the default cpuset, for instance to allocate a subset of CPUs to some particular applications and not FreeBSD. Having kernel threads pinned prevents this from happening since they are in the default set. (Note that some network drivers are also culprits here, though disabling MSI-x in them is a workaround). later, Peter. ___ 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: Automatic enabling of serial console
Hi Michael, I am curious if any progress has been made with regard to the automatic enabling of serial consoles? Nathan W checked in the base code for this in r260913. I'll make the change to the amd64/i386 ttys file after some more testing. later, Peter. ___ 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: [CFT] bsdinstall and zfsboot enhancements
Hi Devin, When boot is executed, I know I can see "kenv console", but hadn't realized that there were/are a host of others that are slurped into the kernel for later (very purposeful) fetching. So when you say that bhyve requests a serial console... I assume now it's setting variables... but via raw Forth? C code? loader.conf(5)? I've seen my menu come up under bhyve, and I noticed that it only has a 5-second count- down instead of the usual 9 -- but I'm curious how you're exporting the variables. bhyve uses the loader facility to set env variables directly from loader code. This is no different than other arch ports of the loader that set env variables. The forced setting of boot_serial is just a convenience for users since that is the only supported console type. It doesn't touch the timeout code - should be whatever FreeBSD loader forth scripts tell it to do. later, Peter. ___ 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: [CFT] bsdinstall and zfsboot enhancements
Hi Devin, Question: Does bhyve set kern.console irrespective of loader.conf values? The kernel sets it based on what it determines the console to be. Bhyve influences that by requesting a serial console. This is no different than booting on a headless machine with a serial console. later, Peter. ___ 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: [CFT] bsdinstall and zfsboot enhancements
Hi Nathan,
I think modifying init is the way to go -- it keeps the install system
from interfering with the installed one, as well as fixing this kind of
issue with moved hard drives or PXE booting or what have you.
I now agree with this :) Modifying /etc/ttys at install time doesn't
work for a lot of cases, LiveCD being the most obvious.
I would propose one of the following (and volunteer to write the code):
Option A
1. init checks if there is an entry in /etc/ttys for the terminal[s]
corresponding to the value[s] in kern.console
2. If an entry for each console terminal exists in /etc/ttys, enable it
3. If not, invent one with a terminal type of "ansi"
The one issue here is that someone may want to force a particular entry
to off and still have it be the kernel console. This is tricky. We could
invent a new "status" field that is not "on" or "off" ("auto", maybe, or
"ifconsole"?). Which brings us to:
I'd guess that this mode is really a once-off thing - for a live CD,
init could ask the user if they want a getty spawned on this tty similar
to asking for a shell in single-user mode.
Presumably post-install the user would have edited the ttys file and
init would then be able to locate the entry and not have to prompt.
later,
Peter.
___
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: [CFT] bsdinstall and zfsboot enhancements
Peter, can you restate the problem for Nathan so that we can maybe find a better home for this change? or perhaps more clearly define (than I) how we arrived at the code for the bhyve work? The issue is that /etc/ttys is static. Serial console installs assume that the user knows that the file should be edited manually to enable getty on the serial port. This seems at odds with a server o/s :( The suggestion I brought up with Devin was to see if the install was done on a serial port, and if so, then ask if the user wanted to enable a getty on that terminal. I think the patch might need some work: for instance, a sysctl could be used to see if the console is on a ttyu* device, and only enable for that and not for all ttys. I was going to try it out this weekend but was a bit slow off the mark :) So I guess the real problem here is that init does not know enough to start a login prompt on the console. This has irritated me for a while actually. Maybe that should be fixed? The "console" entry, which would always automatically work, in /etc/ttys is marked off, which apparently happened in the runup to 4.0. It might be time to revisit that. That's also not good :( /dev/console is assumed to be a sink for log messages and not really an interactive tty. later, Peter. ___ 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: [CFT] hwpmc support for Intel Ivy Bridge
Another system: CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (3392.36-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x306a9 Family = 6 Model = 3a Stepping = 9 Features=0xbfebfbff Features2=0x7fbae3ff AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics All pmcstat tests worked. The pmctest.py script failed with SOFT the same way as bapt@'s, but all subsequent tests passed. pmccontrol -L output appended. later, Peter. # ./pmccontrol -L SOFT CLOCK.STAT CLOCK.HARD LOCK.FAILED PAGE_FAULT.WRITE PAGE_FAULT.READ PAGE_FAULT.ALL TSC TSC IAP LD_BLOCKS.STORE_FORWARD MISALIGN_MEM_REF.LOADS MISALIGN_MEM_REF.STORES LD_BLOCKS_PARTIAL.ADDRESS_ALIAS DTLB_LOAD_MISSES.DEMAND_LD_MISS_CAUSES_A_WALK DTLB_LOAD_MISSES.DEMAND_LD_WALK_COMPLETED DTLB_LOAD_MISSES.DEMAND_LD_WALK_DURATION UOPS_ISSUED.ANY UOPS_ISSUED.FLAGS_MERGE UOPS_ISSUED.SLOW_LEA UOPS_ISSUED.SINGLE_MUL ARITH.FPU_DIV_ACTIVE L2_RQSTS.DEMAND_DATA_RD_HIT L2_RQSTS.ALL_DEMAND_DATA_RD L2_RQSTS.RFO_HITS L2_RQSTS.RFO_MISS L2_RQSTS.ALL_RFO L2_RQSTS.CODE_RD_HIT L2_RQSTS.CODE_RD_MISS L2_RQSTS.ALL_CODE_RD L2_RQSTS.PF_HIT L2_RQSTS.PF_MISS L2_RQSTS.ALL_PF L2_STORE_LOCK_RQSTS.MISS L2_STORE_LOCK_RQSTS.HIT_M L2_STORE_LOCK_RQSTS.ALL L2_L1D_WB_RQSTS.MISS L2_L1D_WB_RQSTS.HIT_E L2_L1D_WB_RQSTS.HIT_M L2_L1D_WB_RQSTS.ALL LONGEST_LAT_CACHE.REFERENCE LONGEST_LAT_CACHE.MISS CPU_CLK_UNHALTED.THREAD_P CPU_CLK_THREAD_UNHALTED.REF_XCLK L1D_PEND_MISS.PENDING DTLB_STORE_MISSES.MISS_CAUSES_A_WALK DTLB_STORE_MISSES.WALK_COMPLETED DTLB_STORE_MISSES.WALK_DURATION DTLB_STORE_MISSES.STLB_HIT LOAD_HIT_PRE.SW_PF LOAD_HIT_PRE.HW_PF L1D.REPLACEMENT MOVE_ELIMINATION.INT_NOT_ELIMINATED MOVE_ELIMINATION.SIMD_NOT_ELIMINATED MOVE_ELIMINATION.INT_ELIMINATED MOVE_ELIMINATION.SIMD_ELIMINATED CPL_CYCLES.RING0 CPL_CYCLES.RING123 RS_EVENTS.EMPTY_CYCLES TLB_ACCESS.LOAD_STLB_HIT OFFCORE_REQUESTS_OUTSTANDING.DEMAND_DATA_RD OFFCORE_REQUESTS_OUTSTANDING.DEMAND_CODE_RD OFFCORE_REQUESTS_OUTSTANDING.DEMAND_RFO OFFCORE_REQUESTS_OUTSTANDING.ALL_DATA_RD LOCK_CYCLES.SPLIT_LOCK_UC_LOCK_DURATION LOCK_CYCLES.CACHE_LOCK_DURATION IDQ.EMPTY IDQ.MITE_UOPS IDQ.DSB_UOPS IDQ.MS_DSB_UOPS IDQ.MS_MITE_UOPS IDQ.MS_UOPS IDQ.ALL_DSB_CYCLES_ANY_UOPS IDQ.ALL_DSB_CYCLES_4_UOPS IDQ.ALL_MITE_CYCLES_ANY_UOPS IDQ.ALL_MITE_CYCLES_4_UOPS IDQ.MITE_ALL_UOPS ICACHE.MISSES ITLB_MISSES.MISS_CAUSES_A_WALK ITLB_MISSES.WALK_COMPLETED ITLB_MISSES.WALK_DURATION ITLB_MISSES.STLB_HIT ILD_STALL.LCP ILD_STALL.IQ_FULL BR_INST_EXEC.COND BR_INST_EXEC.DIRECT_JMP BR_INST_EXEC.INDIRECT_JMP_NON_CALL_RET BR_INST_EXEC.RETURN_NEAR BR_INST_EXEC.DIRECT_NEAR_CALL BR_INST_EXEC.INDIRECT_NEAR_CALL BR_INST_EXEC.NONTAKEN BR_INST_EXEC.TAKEN BR_INST_EXEC.ALL_BRANCHES BR_MISP_EXEC.COND BR_MISP_EXEC.INDIRECT_JMP_NON_CALL_RET BR_MISP_EXEC.RETURN_NEAR BR_MISP_EXEC.DIRECT_NEAR_CALL BR_MISP_EXEC.INDIRECT_NEAR_CALL BR_MISP_EXEC.NONTAKEN BR_MISP_EXEC.TAKEN BR_MISP_EXEC.ALL_BRANCHES IDQ_UOPS_NOT_DELIVERED.CORE UOPS_DISPATCHED_PORT.PORT_0 UOPS_DISPATCHED_PORT.PORT_1 UOPS_DISPATCHED_PORT.PORT_2_LD UOPS_DISPATCHED_PORT.PORT_2_STA UOPS_DISPATCHED_PORT.PORT_2 UOPS_DISPATCHED_PORT.PORT_3_LD UOPS_DISPATCHED_PORT.PORT_3_STA UOPS_DISPATCHED_PORT.PORT_3 UOPS_DISPATCHED_PORT.PORT_4 UOPS_DISPATCHED_PORT.PORT_5 RESOURCE_STALLS.ANY RESOURCE_STALLS.RS RESOURCE_STALLS.SB RESOURCE_STALLS.ROB DSB2MITE_SWITCHES.COUNT DSB2MITE_SWITCHES.PENALTY_CYCLES DSB_FILL.EXCEED_DSB_LINES ITLB.ITLB_FLUSH OFFCORE_REQUESTS.DEMAND_DATA_RD OFFCORE_REQUESTS.DEMAND_CODE_RD OFFCORE_REQUESTS.DEMAND_RFO OFFCORE_REQUESTS.ALL_DATA_RD UOPS_EXECUTED.THREAD UOPS_EXECUTED.CORE OFF_CORE_RESPONSE_0 OFF_CORE_RESPONSE_1 TLB_FLUSH.DTLB_THREAD TLB_FLUSH.STLB_ANY INST_RETIRED.ANY_P INST_RETIRED.ALL OTHER_ASSISTS.AVX_STORE OTHER_ASSISTS.AVX_TO_SSE OTHER_ASSISTS.SSE_TO_AVX UOPS_RETIRED.ALL UOPS_RETIRED.RETIRE_SLOTS MACHINE_CLEARS.MEMORY_ORDERING MACHINE_CLEARS.SMC MACHINE_CLEARS.MASKMOV BR_INST_RETIRED.ALL_BRANC
Re: firewire debugging
Hi Julian, does anyone know if there is a limitation on firewire debugging on a machine with > 4GB or memory? I don't know of any Firewire cards that support physical access *above* 4GB. They may exist. For instance, the (last?) Texas Instruments PCIe 1394a/b chip, the XIO2213B, has the following text in it's data sheet - >The physical upper bound register is an optional register and is >not implemented. .. and this is the firewire OHCI register that contains the upper 16 bits of the architected 48-bit physical address. So, you can probably use it for some form of amd64 kernel debug since kernel txt/data/bss is < 4G, but accessing anything above 4G won't work. later, Peter. ___ 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: Current on PPC
Hi Paolo, > What's the status of FreeBSD-CURRENT on PPC (mainly PowerMac stuff)? It's riding out the storm of all the recent -current changes. There should be another snapshot available soon - details will be posted on freebsd-ppc. later, Peter. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cheap power-pc platform on eBay...
> Please be realistic and search the "just ended" acutions to see what the > current market prices are: Expand your search to 'apple g3 desktop', which will pick up the beige desktops. Selective quoting here for sure, but bargains are available to those who go searching. Mabye the price is being driven up by all the sudden demand for low-price FreeBSD boxes :-) $81 http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2057868984 $92 http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2059179867 $79 http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2057659789 later, Peter. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cheap power-pc platform on eBay...
> Where are you finding "Beige" G3's for $35?? I quick eBay search showed > the price to be more in the $200 - $300 price range. That's way too expensive. Search for "apple beige g3". There's one at $41 if you can get hold of a keyboard/mouse: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2061319446 and a slightly better one currently at $71: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2061554015 later, Peter. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cheap power-pc platform on eBay...
> There are quite a number of these gadgets on eBay right now, they would > probably make a cheap entry-level platform for powerpc work: > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2059912083 For the budget-conscious developer, I'd recommend the Apple 'Beige' G3. Not much more expensive than this one on auction sites, and will be supported by FreeBSD/PPC in the near future. later, Peter. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
