Hardware VM support for Jails

2013-01-14 Thread CeDeROM
Hello :-) I was wondering if there is a hardware accelerated Jail using Virtualization CPU extensions in BSD or everything is done in Kernel by software? SUSE is advertising their light virtualization (no hardware emulation) I was wondering if BSD has this capabilities too ;-) What would be

Re: Hardware VM support for Jails

2013-01-14 Thread Mark Felder
On Mon, 14 Jan 2013 06:18:34 -0600, cede...@tlen.pl wrote: Hello :-) I was wondering if there is a hardware accelerated Jail using Virtualization CPU extensions in BSD or everything is done in Kernel by software? SUSE is advertising their light virtualization (no hardware emulation) I was

Re: Hardware VM support for Jails

2013-01-14 Thread CeDeROM
Good to know thank you! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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: Spurious witness warning when destroying spin mtx

2013-01-14 Thread John Baldwin
On Saturday, November 24, 2012 10:01:39 am Attilio Rao wrote: On Sat, Nov 24, 2012 at 3:08 AM, Ryan Stone ryst...@gmail.com wrote: Today I saw a spurious witness warning for acquiring duplicate lock of same type. The root cause is that when running mtx_destroy on a spinlock that is held by

[PATCH] Add rusage reporting to procstat

2013-01-14 Thread John Baldwin
This patch adds a new -r flag to dump the resource usage information (what you would get from getrusage() or wait()) for a given process. Sample output: % procstat -r $$ PID COMM TYPE VALUE 1428 tcsh user time

Re: [PATCH] Add rusage reporting to procstat

2013-01-14 Thread Konstantin Belousov
On Mon, Jan 14, 2013 at 04:39:17PM -0500, John Baldwin wrote: This patch adds a new -r flag to dump the resource usage information (what you would get from getrusage() or wait()) for a given process. Sample output: % procstat -r $$ PID COMM TYPE

ctfconvert again

2013-01-14 Thread George Mitchell
So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting past the ctfconvert problem that causes a build of 10-CURRENT to say: ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at [dwarf_init_attr(400)] while compiling every kernel source file. Then I checked out

Re: ctfconvert again

2013-01-14 Thread Freddie Cash
The following built without any issues, including GENERIC and a custom kernel. I was pleasantly surprised that it was so easy to update from 9.0-RELEASE to 10.0-CURRENT. I was expecting a lot more manual fiddling and twiddling. [fcash@nexus2 /usr/src]$ uname -a FreeBSD nexus2.sd73.bc.ca

Re: ctfconvert again

2013-01-14 Thread Steven Hartland
- Original Message - From: George Mitchell george+free...@m5p.com To: freebsd-current@freebsd.org Sent: Monday, January 14, 2013 11:57 PM Subject: ctfconvert again So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting past the ctfconvert problem that causes a build

Re: ctfconvert again

2013-01-14 Thread George Mitchell
On 01/14/13 18:57, George Mitchell wrote: So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting past the ctfconvert problem that causes a build of 10-CURRENT to say: ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at [dwarf_init_attr(400)] while compiling

Re: ctfconvert again

2013-01-14 Thread Steven Hartland
- Original Message - From: Freddie Cash fjwc...@gmail.com The following built without any issues, including GENERIC and a custom kernel. I was pleasantly surprised that it was so easy to update from 9.0-RELEASE to 10.0-CURRENT. I was expecting a lot more manual fiddling and

Re: ctfconvert again

2013-01-14 Thread George Mitchell
On 01/14/13 19:21, Steven Hartland wrote: - Original Message - From: George Mitchell george+free...@m5p.com To: freebsd-current@freebsd.org Sent: Monday, January 14, 2013 11:57 PM Subject: ctfconvert again So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting past the

ktrace -d broken on current/stable-9

2013-01-14 Thread Garrett Cooper
I tried using ktrace on a kernel compiled a week ago, and it appears to not be following forks like it should on amd64: # ktrace -d ./regress -l rename_file move_files_into_dir move_file_from_dir_to_file move_file_from_dir_to_existing_file move_file_from_dir_to_existing_dir

Re: ktrace -d broken on current/stable-9

2013-01-14 Thread Garrett Cooper
BTW, the brokenness can be seen in the fact that the PID does not change across execs, but it seems to affect output as well as I was not able to see syscall output from write when it printed out Executing as shown in the snippet below. Thanks, -Garrett On Jan 14, 2013, at 6:48 PM,

Re: ctfconvert again

2013-01-14 Thread Pedro Giffuni
So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting past the ctfconvert problem that causes a build of 10-CURRENT to say: ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at [dwarf_init_attr(400)] while compiling every kernel source file. Then I checked out

Re: ctfconvert again

2013-01-14 Thread Dimitry Andric
On 2013-01-15 00:57, George Mitchell wrote: So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting past the ctfconvert problem that causes a build of 10-CURRENT to say: ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at [dwarf_init_attr(400)] while compiling

Re: ctfconvert again

2013-01-14 Thread Dimitry Andric
On 2013-01-15 04:53, Pedro Giffuni wrote: So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting past the ctfconvert problem that causes a build of 10-CURRENT to say: ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at [dwarf_init_attr(400)] while compiling