from:"Neel Natu"

Re: [PATCH] uart_core: start countdown for non-interrupt mode

2015-07-15 Thread Neel Natu

Thanks for the patch.

Committed as r285619:
https://svnweb.freebsd.org/changeset/base/285619

best
Neel

On Thu, Jul 9, 2015 at 12:15 PM, Simon J. Gerraty s...@juniper.net wrote:
 Aleksey Kuleshov rnd...@yandex.ru wrote:

 The uart_intr will never be called if interrupts are not available.
 Start counter with callout_reset call.

 FWIW this fixed an issue we were investgating.

 ___
 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: [CFR] Replacing while loops with proper division and multiplication

2015-06-05 Thread Neel Natu

Hi Hans,

On Fri, Jun 5, 2015 at 12:09 AM, Hans Petter Selasky h...@selasky.org wrote:
 Hi,

 I was going through some timer code and found some unnecessary while loops
 in kern/kern_clocksource.c .

 I added some prints and found that during boot, runs can exceed 2000,
 while during regular usage runs is typically 1. Do you think it is worth to
 convert these loops into division and multiplications? It might make the CPU
 pipeline a tiny bit faster, having to skip some conditionals? And also
 possibly improve readability?

 What do you think?

 --HPS

 Index: kern/kern_clocksource.c
 ===
 --- kern/kern_clocksource.c (revision 283606)
 +++ kern/kern_clocksource.c (working copy)
 @@ -155,10 +155,11 @@
  handleevents(sbintime_t now, int fake)
  {
 sbintime_t t, *hct;
 +   sbintime_t runs;
 struct trapframe *frame;
 struct pcpu_state *state;
 int usermode;
 -   int done, runs;
 +   int done;

 CTR3(KTR_SPARE2, handle at %d:  now  %d.%08x,
 curcpu, (int)(now  32), (u_int)(now  0x));
 @@ -173,12 +174,10 @@

 state = DPCPU_PTR(timerstate);

 -   runs = 0;
 -   while (now = state-nexthard) {
 -   state-nexthard += tick_sbt;
 -   runs++;
 -   }
 -   if (runs) {
 +   runs = (now - state-nexthard) / tick_sbt;
 +   if (runs  0) {
 +   printf(R%d , (int)runs);
 +   state-nexthard += tick_sbt * runs;
 hct = DPCPU_PTR(hardclocktime);
 *hct = state-nexthard - tick_sbt;
 if (fake  2) {

There is a difference in behavior in the two implementations when 'now
== state-nexthard'. In the loop-based implementation this would end
up with 'runs = 1' whereas in the division-based implementation it
would end up with 'runs = 0'.

I am not sure if this is intentional or just an oversight.

best
Neel

 @@ -186,25 +185,25 @@
 done = 1;
 }
 }
 -   runs = 0;
 -   while (now = state-nextstat) {
 -   state-nextstat += statperiod;
 -   runs++;
 +   runs = (now - state-nextstat) / statperiod;
 +   if (runs  0) {
 +   printf(S%d , (int)runs);
 +   state-nextstat += statperiod * runs;
 +   if (fake  2) {
 +   statclock_cnt(runs, usermode);
 +   done = 1;
 +   }
 }
 -   if (runs  fake  2) {
 -   statclock_cnt(runs, usermode);
 -   done = 1;
 -   }
 if (profiling) {
 -   runs = 0;
 -   while (now = state-nextprof) {
 -   state-nextprof += profperiod;
 -   runs++;
 +   runs = (now - state-nextprof) / profperiod;
 +   if (runs  0) {
 +   printf(T%d , (int)runs);
 +   state-nextprof += profperiod * runs;
 +   if (!fake) {
 +   profclock_cnt(runs, usermode,
 TRAPF_PC(frame));
 +   done = 1;
 +   }
 }
 -   if (runs  !fake) {
 -   profclock_cnt(runs, usermode, TRAPF_PC(frame));
 -   done = 1;
 -   }
 } else
 state-nextprof = state-nextstat;
 if (now = state-nextcallopt) {

 ___
 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: [CFR] Replacing while loops with proper division and multiplication

2015-06-05 Thread Neel Natu

Hi Hans,

On Fri, Jun 5, 2015 at 11:53 AM, Hans Petter Selasky h...@selasky.org wrote:
 On 06/05/15 20:31, Neel Natu wrote:

 -   runs = 0;
 -   while (now = state-nexthard) {
 -   state-nexthard += tick_sbt;
 -   runs++;
 -   }
 -   if (runs) {
 +   runs = (now - state-nexthard) / tick_sbt;
 +   if (runs  0) {
 +   printf(R%d , (int)runs);
 +   state-nexthard += tick_sbt * runs;
  hct = DPCPU_PTR(hardclocktime);
  *hct = state-nexthard - tick_sbt;
  if (fake  2) {

 There is a difference in behavior in the two implementations when 'now
 == state-nexthard'. In the loop-based implementation this would end
 up with 'runs = 1' whereas in the division-based implementation it
 would end up with 'runs = 0'.

 I am not sure if this is intentional or just an oversight.


 Hi Neel,

 The nexthard is mainly updated in this piece of code. We can assume that
 state-nexthard is aligned to ticks_sbt. If state-nexthard % ticks_sbt
 == 0, is that still an issue?


I am not very familiar with this subsystem to make the call (mav@ or
davide@ would know for sure though).

I just noticed a discrepancy in the patch and wanted to highlight that
in case it might be an issue.

best
Neel

 --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: cam(4) timeouts in bhyve/kyua runs up on Jenkins?

2015-05-26 Thread Neel Natu

Hi NGie,

On Mon, May 25, 2015 at 1:40 PM, Garrett Cooper yaneurab...@gmail.com wrote:
 On Apr 28, 2015, at 0:54, Alexander Motin m...@freebsd.org wrote:

 Hi.

 On 27.04.2015 21:17, Garrett Cooper wrote:
 On Apr 27, 2015, at 11:16, Garrett Cooper yaneurab...@gmail.com
 wrote:

 I was looking at the console log for the latest kyua run and I’ve
 noticed that it’s timing out a bit more [1] than it was
 previously [2]. I’ve seen some of your commits recently to cam(4)
 dealing with bhyve — has there been a performance regression
 there? Thanks! -NGie

 1.
 https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/940/console
 2.
 https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/983/console

 (Sorry for not being more explicit for the archives) These are the
 timeouts I’m referring to:

 ahcich0: is  cs  ss 1f00 rs 1f00 tfd 50
 serr  cmd 1000dc17 (ada0:ahcich0:0:0:0):
 WRITE_FPDMA_QUEUED. ACB: 61 08 a8 54 1e 40 00 00 00 00 00 00
 (ada0:ahcich0:0:0:0): CAM status: Command timeout
 (ada0:ahcich0:0:0:0): Retrying command

Can you try to reproduce with a virtio-blk instead of ahci-hd?

It will help narrow down the problem because both ahci-hd and
virtio-blk emulations share a common backend to read/write to the
disk.

best
Neel


 Last time I was more working on bhyve host disk emulation, rather then
 on cam(4) running on guest. Considering that, what guest and what host
 versions are you running? Is there any other load on host except this VM
 that could cause I/O delays high enough to trigger timeouts? What are
 you using to back the virtual disk (file, zvol, ...)?

 I have no idea what the Jenkins slaves are running in terms of 
 configuration/version/etc. You’ll have to ask jenkins-admin@…
 Thanks!
 -NGie
___
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: Panic on 11.0-CURRENT when trying kldload vmm

2015-04-16 Thread Neel Natu

Hi Markiyan,

On Thu, Apr 16, 2015 at 1:30 PM, Markiyan Kushnir
markiyan.kush...@gmail.com wrote:
 2015-04-16 23:20 GMT+03:00 Neel Natu neeln...@gmail.com:
 Hi Markiyan,

 On Thu, Apr 16, 2015 at 1:01 PM, Markiyan Kushnir
 markiyan.kush...@gmail.com wrote:
 22:13:~$ uname -a
 FreeBSD mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #3
 r281432: Sun Apr 12 01:35:34 EEST 2015
 root@:/work/obj/work/src.svn/sys/MAREK  amd64


 Went kernel panic twice today when trying to load vmm.  Never seen
 this before (the previous kernel was built out of r278973, Feb 19
 2015, was doing well).  The panic is not reliable in the sense I could
 not reproduce it at will just loading/unloading vmm.

 I regularly work in my bhyve guests, sometimes swap between vmm and
 vboxdrv, all my scenarios haven't changed from the previous Feb
 kernel.  Except that I re-built my today panicking kernel extending
 the MINIMAL config (including what I need) as opposed to the previous
 one reducing GENERIC (excluding what I don't need).

 Both today panic's back traces look identical. Attaching core.txt.1
 (the latter one) and the output of sysctl kern.conftxt. Let me know
 if someone wants to debug it.


 I don't think that 'core.txt.1' made it through.

 Regardless, can you try to reproduce after applying r281559. I think
 it should fix the panic.

 https://svnweb.freebsd.org/changeset/base/281559


 ah ok. Saved on google drive:
 https://drive.google.com/file/d/0B9Q-zpUXxqCnam0zNjFRcF9XMHc/view?usp=sharing


Yup, its the one that is fixed in r281559.

best
Neel

 and yes, will shift to r281559, and see if it's ok.

 Thanks,
 Markiyan.

 best
 Neel

 Thanks,
 Markiyan.

 ___
 freebsd-virtualizat...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
 To unsubscribe, send any mail to 
 freebsd-virtualization-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: Panic on 11.0-CURRENT when trying kldload vmm

2015-04-16 Thread Neel Natu

Hi Markiyan,

On Thu, Apr 16, 2015 at 1:01 PM, Markiyan Kushnir
markiyan.kush...@gmail.com wrote:
 22:13:~$ uname -a
 FreeBSD mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #3
 r281432: Sun Apr 12 01:35:34 EEST 2015
 root@:/work/obj/work/src.svn/sys/MAREK  amd64


 Went kernel panic twice today when trying to load vmm.  Never seen
 this before (the previous kernel was built out of r278973, Feb 19
 2015, was doing well).  The panic is not reliable in the sense I could
 not reproduce it at will just loading/unloading vmm.

 I regularly work in my bhyve guests, sometimes swap between vmm and
 vboxdrv, all my scenarios haven't changed from the previous Feb
 kernel.  Except that I re-built my today panicking kernel extending
 the MINIMAL config (including what I need) as opposed to the previous
 one reducing GENERIC (excluding what I don't need).

 Both today panic's back traces look identical. Attaching core.txt.1
 (the latter one) and the output of sysctl kern.conftxt. Let me know
 if someone wants to debug it.


I don't think that 'core.txt.1' made it through.

Regardless, can you try to reproduce after applying r281559. I think
it should fix the panic.

https://svnweb.freebsd.org/changeset/base/281559

best
Neel

 Thanks,
 Markiyan.

 ___
 freebsd-virtualizat...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
 To unsubscribe, send any mail to 
 freebsd-virtualization-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: Xen HVM Panic, HEAD

2015-02-19 Thread Neel Natu

Hi Adrian,

On Wed, Feb 18, 2015 at 10:09 PM, Adrian Chadd adr...@freebsd.org wrote:
 Hi,

 Since this is the (at least) second round of x2apic support broke me
 changes, can we please either back them out or set it to default to
 '0' for now?


I don't think that is necessary.

This is -current and there is a tunable to disable x2apic on platforms
that are experiencing issues. More importantly the issues that have
been reported are being resolved in a timely manner (for e.g.,
suspend/resume).

best
Neel

 Thanks,


 -adrian
 ___
 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: panic in softdep_slowdown()

2015-02-09 Thread Neel Natu

A fix for this panic was submitted by kib@ as r277922:
https://svnweb.freebsd.org/base?view=revisionrevision=277922

best
Neel

On Wed, Jan 28, 2015 at 11:54 AM, Neel Natu neeln...@gmail.com wrote:
 Hi Gleb,

 On Wed, Jan 28, 2015 at 11:33 AM, Gleb Smirnoff gleb...@freebsd.org wrote:
 On Wed, Jan 28, 2015 at 09:04:42PM +0200, Konstantin Belousov wrote:
 K  I can't see where integer divide fault can happen with 
 stat_flush_threads=1 :(
 K
 K Look at the exact asm instruction which faulted, also look at the 
 registers
 K content.
 K
 K It might be hypervisor bug, after all.

 Yes, for me it looks like it. %edx should be one as well as -0x44(%rbp).

 0x80895d43 softdep_slowdown+435:  mov-0x20(%rbp),%ecx
 0x80895d46 softdep_slowdown+438:  mov%ecx,%edx
 0x80895d48 softdep_slowdown+440:  shr$0x1f,%edx
 0x80895d4b softdep_slowdown+443:  add%edx,%ecx
 0x80895d4d softdep_slowdown+445:  sar%ecx
 0x80895d4f softdep_slowdown+447:  mov
 0x80ee24c8,%edx
 0x80895d56 softdep_slowdown+454:  mov%rax,-0x40(%rbp)
 0x80895d5a softdep_slowdown+458:  mov%ecx,%eax
 0x80895d5c softdep_slowdown+460:  mov%edx,-0x44(%rbp)
 0x80895d5f softdep_slowdown+463:  cltd
 0x80895d60 softdep_slowdown+464:  mov-0x44(%rbp),%ecx
 0x80895d63 softdep_slowdown+467:  idiv   %ecx

 (kgdb) p stat_flush_threads
 $5 = (int *) 0x80ee24c8
 (kgdb) info registers
 rax0x12b86  76678
 rbx0x4  4
 rcx0x0  0
 rdx0x0  0
 rsi0x3e81000
 rdi0x99 153
 rbp0xfe001eb5f2b0   0xfe001eb5f2b0
 ...
 (kgdb) p *(int *)($rbp - 0x44)
 $4 = 0
 (kgdb) p *(int *)($rbp - 0x40)
 $8 = 0
 (kgdb) p max_softdeps_hard
 $11 = (int *) 0xfe001eb5f290
 (kgdb) p (int *)($rbp - 0x20)
 $12 = (int *) 0xfe001eb5f290
 (kgdb) p max_softdeps_hard
 $10 = 153357


 Can you upload the core file and the kernel someplace that I can access?

 best
 Neel

 --
 Totus tuus, Glebius.
 ___
 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: panic in softdep_slowdown()

2015-01-28 Thread Neel Natu

Hi Gleb,

On Wed, Jan 28, 2015 at 11:33 AM, Gleb Smirnoff gleb...@freebsd.org wrote:
 On Wed, Jan 28, 2015 at 09:04:42PM +0200, Konstantin Belousov wrote:
 K  I can't see where integer divide fault can happen with 
 stat_flush_threads=1 :(
 K
 K Look at the exact asm instruction which faulted, also look at the registers
 K content.
 K
 K It might be hypervisor bug, after all.

 Yes, for me it looks like it. %edx should be one as well as -0x44(%rbp).

 0x80895d43 softdep_slowdown+435:  mov-0x20(%rbp),%ecx
 0x80895d46 softdep_slowdown+438:  mov%ecx,%edx
 0x80895d48 softdep_slowdown+440:  shr$0x1f,%edx
 0x80895d4b softdep_slowdown+443:  add%edx,%ecx
 0x80895d4d softdep_slowdown+445:  sar%ecx
 0x80895d4f softdep_slowdown+447:  mov0x80ee24c8,%edx
 0x80895d56 softdep_slowdown+454:  mov%rax,-0x40(%rbp)
 0x80895d5a softdep_slowdown+458:  mov%ecx,%eax
 0x80895d5c softdep_slowdown+460:  mov%edx,-0x44(%rbp)
 0x80895d5f softdep_slowdown+463:  cltd
 0x80895d60 softdep_slowdown+464:  mov-0x44(%rbp),%ecx
 0x80895d63 softdep_slowdown+467:  idiv   %ecx

 (kgdb) p stat_flush_threads
 $5 = (int *) 0x80ee24c8
 (kgdb) info registers
 rax0x12b86  76678
 rbx0x4  4
 rcx0x0  0
 rdx0x0  0
 rsi0x3e81000
 rdi0x99 153
 rbp0xfe001eb5f2b0   0xfe001eb5f2b0
 ...
 (kgdb) p *(int *)($rbp - 0x44)
 $4 = 0
 (kgdb) p *(int *)($rbp - 0x40)
 $8 = 0
 (kgdb) p max_softdeps_hard
 $11 = (int *) 0xfe001eb5f290
 (kgdb) p (int *)($rbp - 0x20)
 $12 = (int *) 0xfe001eb5f290
 (kgdb) p max_softdeps_hard
 $10 = 153357


Can you upload the core file and the kernel someplace that I can access?

best
Neel

 --
 Totus tuus, Glebius.
 ___
 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: Haswell CPU Feature

2015-01-05 Thread Neel Natu

Hi Sean,

On Mon, Jan 5, 2015 at 4:46 PM, Sean Bruno sbr...@ignoranthack.me wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

   \014b11


 I don't know what this cpu feature2 flag means, but my x240 haswell
 laptop has a b11 feature2 set.

 sean

 dmesg | grep -i features

 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE

 Features2=0x7ffafbbfSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,b11,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND

Congratulations, you have the ability to debug the Haswell silicon :-)

From the Intel SDM, Table 3-20. Feature Information Returned in the
ECX Register

11 | SDBG | A value of 1 indicates the processor supports
IA32_DEBUG_INTERFACE MSR for silicon debug.

best
Neel

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQF8BAEBCgBmBQJUqzBsXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx
 MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5ktYUH/A/2P6aNyBfBMhM7pRThx/DC
 kulQbmHCuqOFwzJnE8qI/1YTvItNFG2sAsspd0iT2FmC2oEY/z6+j2ba2UizMJmH
 +ppjseAzs4+GY2N6cxT0BHf1yNoMDqlwdeWVeSODCn2HCc9Cc9Wz0e0RUOpwQ4zx
 Hmm1zI0Rla1izMIm437Lv38RFP1q/KaNLailcwgYrjvd90RaqobDeE2If3BYe8uv
 qvYUeap3hRk0EOrjMRBuGyMSIGkssHa1NyfQFYEmzg3F9F8lgTnCBYlspovjacoy
 I+LRWBUpOGS89vBxCjnLuBZO9fFajSJ0b6X8K8Cw4QWZmefPZWutujgf5ObzBhI=
 =oXdb
 -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
___
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

2015-01-05 Thread Neel Natu

Hi Sean,

On Mon, Jan 5, 2015 at 6:34 PM, Sean Bruno sbr...@ignoranthack.me wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 On 01/05/15 17:50, Andrey Fesenko wrote:
 On Tue, Jan 6, 2015 at 4:24 AM, Sean Bruno sbr...@ignoranthack.me
 wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512

 On 01/05/15 16:57, Neel Natu wrote:
 Congratulations, you have the ability to debug the Haswell
 silicon

 HA!

 Is this turned on purposefully (its a feature of the CPU) or is
 this turned on unintentionally and is a bug in manufacturing?

 sean

 My desktop i5-4570 contain this flag too

 Origin=GenuineIntel  Id=0x306c3  Family=0x6  Model=0x3c
 Stepping=3
 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE


 Features2=0x7ffafbffSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,b11,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND


 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.

best
Neel

 sean
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQF8BAEBCgBmBQJUq0m+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx
 MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kigkIAI2Naiv2TENl+1SFAQ5oHTUu
 HR+sbz3o7p71W8/9WhdkiMhHLwpF5ZGrpqh9Jc4CYuyNax4OvzD9du8b1RFVVBtx
 AR6K+zFE1/wHC8S+iEB2QsWLWjd6Y0NbZL1MvgEQTybFwLzdtEXafOi2gSsa2lK0
 RFMd0VbE2xn2q9mp5GuTnR8fvqWGPSJLEtWTpEZri8vFnBIMC+kocb//kOhY6JsF
 SNcpJ2RfhXiQyOOZT/ETe47s7A29R9VW5u/+Hg8VnNuq5rV5o2PXa68VvSmAu4gr
 IxPMoodFUITXTpS/lfmkOf4W+uTSqUji+Y/u1yjNzS4MgodoEh6mc7gDuH9Xoj0=
 =j1kZ
 -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
___
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 ?

2015-01-03 Thread Neel Natu

Hi Luigi,

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


You can use the -h option to bhyveload(8) to do this.

For e.g., bhyveload -h / vmx will load the kernel from
/boot/kernel/kernel and use the loader configuration from /boot.

 - how to pass the necessary config (rootpath) to the client
   without having to rely on a specialized dhcp server


You can set environment variables using the -e option:
bhyveload -e boot.nfsroot.server=1.2.3.4 -e
boot.nfsroot.path=/exports/guest1

There are a number of other environment variables set by the PXE
loader - see sys/boot/i386/libi386/pxe.c. I haven't done this myself
therefore not sure if this would work.

best
Neel

 I used to be familiar with diskless configs, so i can probably sort
 out the server side myself.

 cheers
 luigi
___
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: HEADS UP: Merging projects/bhyve_svm to HEAD

2014-12-30 Thread Neel Natu

Hi,

On Tue, Dec 9, 2014 at 10:37 AM, Neel Natu neeln...@gmail.com wrote:
 Hi Matthew,

 On Tue, Dec 9, 2014 at 9:45 AM, Matthew Grooms mgro...@shrew.net wrote:
 On 12/9/2014 11:03 AM, John Nielsen wrote:

 On Oct 26, 2014, at 4:40 PM, Zaphod Beeblebrox zbee...@gmail.com wrote:

 On Sat, Oct 25, 2014 at 8:20 PM, Neel Natu neeln...@gmail.com wrote:

 On Sat, Oct 25, 2014 at 3:50 PM, Zaphod Beeblebrox zbee...@gmail.com
 wrote:

 I tried to integrate this patch into 10.1_RC3 and I failed.  Is there a
 timeframe to MFC this to 10.1 or 10-STABLE?


 It will be MFCed to 10-STABLE but I don't have a specific time frame in
 mind.

 I'll guess that it'll be towards the end of November but can be
 accelerated if someone has a need for this in 10-STABLE sooner.


 I would be using such a patch as soon as it was available.  On a friend's
 advice, I upgraded a ZFS server here at home with an AMD 9590 and 32Gig
 of
 RAM.  I'd dearly like to use it to track down the netgraph bug (see my
 other recent posts), but it doesn't currently qualify.


 Ping? I'm also waiting with bated breath for this to be MFCed. :) Thanks
 for the great work!


 Message received: loud and clear :-)


It took longer than anticipated but AMD/SVM support is now in stable/10.

Please sync to r276447 before testing.

best
Neel


 +1. And on a somewhat related note, does the SVM port have equivalent to
 Intel Unrestricted Guest support? From what I understand, that will be
 required for the forthcoming UEFI/CSM ( Legacy BIOS ) as well as other bhyve
 features.

 Yes, it does.

 best
 Neel


 Thanks,

 -Matthew

 ___
 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: HEADS UP: Merging projects/bhyve_svm to HEAD

2014-12-09 Thread Neel Natu

Hi Matthew,

On Tue, Dec 9, 2014 at 9:45 AM, Matthew Grooms mgro...@shrew.net wrote:
 On 12/9/2014 11:03 AM, John Nielsen wrote:

 On Oct 26, 2014, at 4:40 PM, Zaphod Beeblebrox zbee...@gmail.com wrote:

 On Sat, Oct 25, 2014 at 8:20 PM, Neel Natu neeln...@gmail.com wrote:

 On Sat, Oct 25, 2014 at 3:50 PM, Zaphod Beeblebrox zbee...@gmail.com
 wrote:

 I tried to integrate this patch into 10.1_RC3 and I failed.  Is there a
 timeframe to MFC this to 10.1 or 10-STABLE?


 It will be MFCed to 10-STABLE but I don't have a specific time frame in
 mind.

 I'll guess that it'll be towards the end of November but can be
 accelerated if someone has a need for this in 10-STABLE sooner.


 I would be using such a patch as soon as it was available.  On a friend's
 advice, I upgraded a ZFS server here at home with an AMD 9590 and 32Gig
 of
 RAM.  I'd dearly like to use it to track down the netgraph bug (see my
 other recent posts), but it doesn't currently qualify.


 Ping? I'm also waiting with bated breath for this to be MFCed. :) Thanks
 for the great work!


Message received: loud and clear :-)


 +1. And on a somewhat related note, does the SVM port have equivalent to
 Intel Unrestricted Guest support? From what I understand, that will be
 required for the forthcoming UEFI/CSM ( Legacy BIOS ) as well as other bhyve
 features.

Yes, it does.

best
Neel


 Thanks,

 -Matthew

 ___
 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: HEADS UP: Merging projects/bhyve_svm to HEAD

2014-10-25 Thread Neel Natu

Hi,

On Sat, Oct 25, 2014 at 3:50 PM, Zaphod Beeblebrox zbee...@gmail.com wrote:
 I tried to integrate this patch into 10.1_RC3 and I failed.  Is there a
 timeframe to MFC this to 10.1 or 10-STABLE?


It will be MFCed to 10-STABLE but I don't have a specific time frame in mind.

I'll guess that it'll be towards the end of November but can be
accelerated if someone has a need for this in 10-STABLE sooner.

best
Neel

 On Sun, Oct 19, 2014 at 4:04 PM, Benjamin Perrault ben.perra...@gmail.com
 wrote:

 After a few days of extensive testing and abuse, i’ve run into no new
 issues or unknowns what so ever. Everything that worked before still works
 now ( and a few bugs from fixed from HEAD ).

 Thus, I have gone ahead and pushed r273182 w/ Neel’s patch out to about 80
 of the assorted AMD boxes in the production and dev pods that I care for. If
 end users see something, I’ll let you know, but I have a feeling they won’t.

 Again - Excellent work.

 cheers,
 -bp

  On Oct 19, 2014, at 5:03 AM, Willem Jan Withagen w...@digiware.nl
  wrote:
 
  On 16-10-2014 5:00, Anish Gupta wrote:
  Hi all,
 
  The projects/bhyve_svm branch is ready to be merged to HEAD.
 
  This branch contains patches to bhyve to enable it to work on AMD
  processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD
  processor since 2010 will have the features required by bhyve.
 
  bhyve on AMD supports (almost) all the features available with Intel
  [2]. All guest OSes supported on Intel are supported on AMD. All the
  bhyve-related utilities function similarly on both Intel and AMD
  platforms [3].
 
  The patch against HEAD revision 273066 is available for review and
  testing:
  https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel’s web
  directory]
 
  [1]: http://en.wikipedia.org/wiki/X86_virtualization
  [2]: bhyve doesn't support PCI passthru on AMD at this time
  [3]: bhyvectl has grown some processor-specific options
 
  Fetched the patch and compiled.
  Now running: HEAD r273066M and I was able to throw at it all the tests
  and images that in the past works. And perhaps even better.
 
  Great work.
  --WjW
 
 
  ___
  freebsd-virtualizat...@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
  To unsubscribe, send any mail to
  freebsd-virtualization-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


___
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: tmpfs panic

2014-07-06 Thread Neel Natu

Hi Steve,

On Sun, Jul 6, 2014 at 8:46 AM, Steve Wills swi...@freebsd.org wrote:
 I should have noted this system is running in bhyve. Also I'm told this panic
 may be related to the fact that the system is running in bhyve.

 Looking at it a little more closely:

 (kgdb) list *__mtx_lock_sleep+0xb1
 0x809638d1 is in __mtx_lock_sleep 
 (/usr/src/sys/kern/kern_mutex.c:431).
 426  * owner stops running or the state of the lock 
 changes.
 427  */
 428 v = m-mtx_lock;
 429 if (v != MTX_UNOWNED) {
 430 owner = (struct thread *)(v  ~MTX_FLAGMASK);
 431 if (TD_IS_RUNNING(owner)) {
 432 if (LOCK_LOG_TEST(m-lock_object, 0))
 433 CTR3(KTR_LOCK,
 434 %s: spinning on %p held 
 by %p,
 435 __func__, m, owner);
 (kgdb)

 I'm told that MTX_CONTESTED was set on the unlocked mtx and that MTX_CONTENDED
 is spuriously left behind, and to ask how lock prefix is handled in bhyve. Any
 of that make sense to anyone?


Regarding the lock prefix: since bhyve only supports hardware that has
nested paging, the hypervisor doesn't get in the way of instructions
that access memory. This includes instructions with lock prefixes or
any other prefixes for that matter. If there is a VM exit due to a
nested page fault then the faulting instruction is restarted after
resolving the fault.

Having said that, there are more plausible explanations that might
implicate bhyve: incorrect translations in the nested page tables,
stale translations in the TLB etc.

Do you have a core file for the panic? It would be very useful to
debug this further.

 Thanks,
 Steve

 On Sun, Jul 06, 2014 at 01:53:37PM +, Steve Wills wrote:
 Hi,

 Just experienced this tmpfs panic on r268160:

 Freed UMA keg (TMPFS node) was not empty (16 items).  Lost 1 pages of memory.


 Fatal trap 12: page fault while in kernel mode
 cpuid = 12; apic id = 0c
 fault virtual address   = 0x378
 fault code  = supervisor read data, page not present
 instruction pointer = 0x20:0x809638d1
 stack pointer   = 0x28:0xfe07243800a0
 frame pointer   = 0x28:0xfe0724380120
 code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 65339 (pkg-static)
 [ thread pid 65339 tid 101641 ]
 Stopped at  __mtx_lock_sleep+0xb1:  movl0x378(%rax),%ecx
 db bt
 Tracing pid 65339 tid 101641 td 0xf80286b2e490
 __mtx_lock_sleep() at __mtx_lock_sleep+0xb1/frame 0xfe0724380120
 free_unr() at free_unr+0x9d/frame 0xfe0724380160
 tmpfs_free_node() at tmpfs_free_node+0xf2/frame 0xfe07243801a0
 tmpfs_reclaim() at tmpfs_reclaim+0xdc/frame 0xfe07243801d0
 VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xa7/frame 0xfe0724380200
 vgonel() at vgonel+0x24c/frame 0xfe0724380280
 vrecycle() at vrecycle+0x84/frame 0xfe07243802c0
 tmpfs_inactive() at tmpfs_inactive+0x18/frame 0xfe07243802d0
 VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xa7/frame 0xfe0724380300
 vinactive() at vinactive+0x181/frame 0xfe0724380360
 vputx() at vputx+0x30d/frame 0xfe07243803d0
 vn_close() at vn_close+0x13e/frame 0xfe0724380450
 vn_closefile() at vn_closefile+0x48/frame 0xfe07243804d0
 _fdrop() at _fdrop+0x29/frame 0xfe07243804f0
 closef() at closef+0x2ae/frame 0xfe0724380580
 fdescfree() at fdescfree+0x64c/frame 0xfe0724380630
 exit1() at exit1+0x682/frame 0xfe07243806c0
 sigexit() at sigexit+0x929/frame 0xfe0724380980
 postsig() at postsig+0x3c4/frame 0xfe0724380a70
 ast() at ast+0x487/frame 0xfe0724380ab0
 doreti_ast() at doreti_ast+0x1f/frame 0x7fffc6e0
 db

 Any further debugging I can do?

 Thanks,
 Steve


___
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: [head tinderbox] failure on amd64/amd64

2014-01-11 Thread Neel Natu

Sorry, my bad. Fixed in  r260550.

best
Neel

On Sat, Jan 11, 2014 at 8:06 AM, FreeBSD Tinderbox
tinder...@freebsd.org wrote:
 TB --- 2014-01-11 13:00:17 - tinderbox 2.20 running on 
 freebsd-current.sentex.ca
 TB --- 2014-01-11 13:00:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
 FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
 TB --- 2014-01-11 13:00:17 - starting HEAD tinderbox run for amd64/amd64
 TB --- 2014-01-11 13:00:17 - cleaning the object tree
 TB --- 2014-01-11 13:00:17 - /usr/local/bin/svn stat /src
 TB --- 2014-01-11 13:00:22 - At svn revision 260540
 TB --- 2014-01-11 13:00:23 - building world
 TB --- 2014-01-11 13:00:23 - CROSS_BUILD_TESTING=YES
 TB --- 2014-01-11 13:00:23 - MAKEOBJDIRPREFIX=/obj
 TB --- 2014-01-11 13:00:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
 TB --- 2014-01-11 13:00:23 - SRCCONF=/dev/null
 TB --- 2014-01-11 13:00:23 - TARGET=amd64
 TB --- 2014-01-11 13:00:23 - TARGET_ARCH=amd64
 TB --- 2014-01-11 13:00:23 - TZ=UTC
 TB --- 2014-01-11 13:00:23 - __MAKE_CONF=/dev/null
 TB --- 2014-01-11 13:00:23 - cd /src
 TB --- 2014-01-11 13:00:23 - /usr/bin/make -B buildworld
 Building an up-to-date make(1)
 World build started on Sat Jan 11 13:00:29 UTC 2014
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything
 [...]
   SET_VMCS_ENTRY_INTERRUPTION_INFO
 /src/usr.sbin/bhyvectl/bhyvectl.c:382:2: note: 
 'SET_VMCS_ENTRY_INTERRUPTION_INFO' declared here
 SET_VMCS_ENTRY_INTERRUPTION_INFO,
 ^
 /src/usr.sbin/bhyvectl/bhyvectl.c:1466:8: error: use of undeclared identifier 
 'VMCS_EXIT_INTERRUPTION_ERROR'
   VMCS_EXIT_INTERRUPTION_ERROR, u64);
   ^
 2 errors generated.
 *** Error code 1

 Stop.
 bmake[3]: stopped in /src/usr.sbin/bhyvectl
 *** Error code 1

 Stop.
 bmake[2]: stopped in /src/usr.sbin
 *** Error code 1

 Stop.
 bmake[1]: stopped in /src
 *** Error code 1

 Stop.
 bmake: stopped in /src
 *** Error code 1

 Stop in /src.
 TB --- 2014-01-11 16:06:09 - WARNING: /usr/bin/make returned exit code  1
 TB --- 2014-01-11 16:06:09 - ERROR: failed to build world
 TB --- 2014-01-11 16:06:09 - 9129.05 user 1558.62 system 11151.55 real


 http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full
 ___
 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: CURRENT: build world failure: /usr/src/usr.sbin/bhyvectl/bhyvectl.c:1466:8: error: use of undeclared identifier 'VMCS_EXIT_INTERRUPTION_ERROR' VMCS_EXIT_INTERRUPTION_ERROR, u64);

2014-01-11 Thread Neel Natu

Hi Marcus,

On Sat, Jan 11, 2014 at 4:52 AM, Marcus Karlsson m...@acc.umu.se wrote:
 On Sat, Jan 11, 2014 at 12:34:44PM +0100, Marcus Karlsson wrote:
 On Sat, Jan 11, 2014 at 11:32:06AM +0100, O. Hartmann wrote:
  Recent sources (revision 260540) fail to build:
 
  cc  -O2 -pipe -O3 -march=native
  -I/usr/src/usr.sbin/bhyvectl/../../sys/amd64/vmm -pipe -O3 -std=gnu99
  -Qunused-arguments  -fstack-protector -Wsystem-headers -Werror -Wall
  -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
  -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
  -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
  -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
  -Wno-unused-function -Wno-enum-conversion
  -c /usr/src/usr.sbin/bhyvectl/bhyvectl.c 
  /usr/src/usr.sbin/bhyvectl/bhyvectl.c:1457:8:
  error: use of undeclared identifier 'VMCS_EXIT_INTERRUPTION_INFO'; did
  you mean 'SET_VMCS_ENTRY_INTERRUPTION_INFO'?
  VMCS_EXIT_INTERRUPTION_INFO, u64); ^~~
  SET_VMCS_ENTRY_INTERRUPTION_INFO 
  /usr/src/usr.sbin/bhyvectl/bhyvectl.c:382:2:
  note: 'SET_VMCS_ENTRY_INTERRUPTION_INFO' declared here
  SET_VMCS_ENTRY_INTERRUPTION_INFO,
  ^ /usr/src/usr.sbin/bhyvectl/bhyvectl.c:1466:8: error: use of
  undeclared identifier 'VMCS_EXIT_INTERRUPTION_ERROR'
  VMCS_EXIT_INTERRUPTION_ERROR, u64);

 I see the same thing. It appears that the definition of
 VMCS_EXIT_INTERRUPTION_INFO and VMCS_EXIT_INTERRUPTION_ERROR changed in
 r260531 to VMC_EXIT_INT_INFO and VMCS_EXIT_INTR_ERRCODE respectively.

 This patch was enough for the build to complete successfully in case
 anyone else wants it. The old macros are not used anywhere else in the
 source tree apart from bhyvectl.


Sorry about the breakage and thanks for the patch. Submitted as  r260550.

best
Neel

 ___
 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: 11.0-CURRENT panic while running a bhyve instance

2013-12-23 Thread Neel Natu

Hi Markiyan,

Fixed in r259737:
http://svnweb.freebsd.org/changeset/base/259737

best
Neel

On Fri, Dec 13, 2013 at 2:35 PM, Markiyan Kushnir
markiyan.kush...@gmail.com wrote:
 2013/12/13 John Baldwin j...@freebsd.org:
 On Friday, December 13, 2013 5:46:20 am Markiyan Kushnir wrote:
 Forgot to fill the Subject: header, re-posting it fixed.

 The mailing lists strips attachments, can you post it at a URL?


 Shared here:

 https://drive.google.com/file/d/0B9Q-zpUXxqCnem5iYTVqLUxrcWo4cmlhdkM1c2lJa2dKak5R/edit?usp=sharing

 --
 Markiyan.

 --
 Markiyan


 -- Forwarded message --
 From: Markiyan Kushnir markiyan.kush...@gmail.com
 Date: 2013/12/13
 Subject:
 To: freebsd-current@freebsd.org, freebsd-virtualizat...@freebsd.org


 I started some ports to compile inside a bhyve instance:

 root@vm:~ # uname -a
 FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0
 r259250: Thu Dec 12 14:17:32 EET 2013
 r...@vm.mkushnir.zapto.org:/
 usr/obj/usr/src.svnup/sys/MAREK  amd64

 and left it running unattended. Approx. 2 hours later the host went to
 panic. The bhyve instance survived after the panic and I could be able
 to complete my ports compilation.

 core.txt attached (gzipped)
 ___
 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


 --
 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
___
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: 11.0-CURRENT panic while running a bhyve instance

2013-12-14 Thread Neel Natu

Hi Markiyan,

On Sat, Dec 14, 2013 at 6:00 AM, Markiyan Kushnir
markiyan.kush...@gmail.com wrote:
2013/12/14 Markiyan Kushnir markiyan.kush...@gmail.com:
2013/12/14 Markiyan Kushnir markiyan.kush...@gmail.com:
2013/12/14 Neel Natu neeln...@gmail.com:
Hi Markiyan,

On Fri, Dec 13, 2013 at 2:35 PM, Markiyan Kushnir
markiyan.kush...@gmail.com wrote:
2013/12/13 John Baldwin j...@freebsd.org:
On Friday, December 13, 2013 5:46:20 am Markiyan Kushnir wrote:
Forgot to fill the Subject: header, re-posting it fixed.

The mailing lists strips attachments, can you post it at a URL?

Shared here:

https://drive.google.com/file/d/0B9Q-zpUXxqCnem5iYTVqLUxrcWo4cmlhdkM1c2lJa2dKak5R/edit?usp=sharing

Thanks.

It looks like something funky going on with the vcpu state. Do you
know if there was any access to the VM via 'bhyvectl' close to the
time of the panic?

Well, I don't know if there was. I would set up the same scenario
again + a script running on the host querying bhyvectl. May be I would
catch it again. Please let me know if all it makes sense, and if so,
how it can be made better.

To make it clear -- I didn't run bhyvectl when the VM was running, so
I can tell for sure that nobody was trying to interact with the VM
during its run. My first thought was that it would make sense to
(periodically) query state of the VM using bhyvectl to get info about
what was going on when it comes close to the crash...

--
Markiyan.

Ok, I was able to hit a similarly looking panic exactly when trying to
run bhyvectl --vm=altroot-bhyve --get-all while the VM was busy with
its own pkg delete -af. When the VM is mostly idle, bhyvectl
--get-all goes smoothly.

Now I'm thinking I might inadvertently run bhyvectl over my heavily
running VM once when I was not at the desktop and wanted to see how
things were going remotely from my office…

Thanks, that helps a lot because I can see how bhyvectl could perturb
the state of the vcpu and eventually lead to a panic.

I'll submit a fix for this ASAP.

best
Neel

Here are core.txt of the two panics in a row:

https://drive.google.com/file/d/0B9Q-zpUXxqCnMUxVdGwxSEs1dE0/edit?usp=sharing

https://drive.google.com/file/d/0B9Q-zpUXxqCnREtuTXpabnQ5QXM/edit?usp=sharing

--
Markiyan.

best
Neel

--
Markiyan.

--
Markiyan

-- Forwarded message --
From: Markiyan Kushnir markiyan.kush...@gmail.com
Date: 2013/12/13
Subject:
To: freebsd-current@freebsd.org, freebsd-virtualizat...@freebsd.org

I started some ports to compile inside a bhyve instance:

root@vm:~ # uname -a
FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0
r259250: Thu Dec 12 14:17:32 EET 2013
r...@vm.mkushnir.zapto.org:/
usr/obj/usr/src.svnup/sys/MAREK amd64

and left it running unattended. Approx. 2 hours later the host went to
panic. The bhyve instance survived after the panic and I could be able
to complete my ports compilation.

core.txt attached (gzipped)
___
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

--
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
___
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: 11.0-CURRENT panic while running a bhyve instance

2013-12-13 Thread Neel Natu

Hi Markiyan,

On Fri, Dec 13, 2013 at 2:35 PM, Markiyan Kushnir
markiyan.kush...@gmail.com wrote:
 2013/12/13 John Baldwin j...@freebsd.org:
 On Friday, December 13, 2013 5:46:20 am Markiyan Kushnir wrote:
 Forgot to fill the Subject: header, re-posting it fixed.

 The mailing lists strips attachments, can you post it at a URL?


 Shared here:

 https://drive.google.com/file/d/0B9Q-zpUXxqCnem5iYTVqLUxrcWo4cmlhdkM1c2lJa2dKak5R/edit?usp=sharing


Thanks.

It looks like something funky going on with the vcpu state. Do you
know if there was any access to the VM via 'bhyvectl' close to the
time of the panic?

best
Neel

 --
 Markiyan.

 --
 Markiyan


 -- Forwarded message --
 From: Markiyan Kushnir markiyan.kush...@gmail.com
 Date: 2013/12/13
 Subject:
 To: freebsd-current@freebsd.org, freebsd-virtualizat...@freebsd.org


 I started some ports to compile inside a bhyve instance:

 root@vm:~ # uname -a
 FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0
 r259250: Thu Dec 12 14:17:32 EET 2013
 r...@vm.mkushnir.zapto.org:/
 usr/obj/usr/src.svnup/sys/MAREK  amd64

 and left it running unattended. Approx. 2 hours later the host went to
 panic. The bhyve instance survived after the panic and I could be able
 to complete my ports compilation.

 core.txt attached (gzipped)
 ___
 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


 --
 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
___
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: expanding past 1 TB on amd64

2013-08-16 Thread Neel Natu

Hi Chris, Alan:

On Sun, Jul 21, 2013 at 1:19 AM, Chris Torek chris.to...@gmail.com wrote:

 (Apologies for delay in reply, family issues)

 I'd be fine with 4 TB instead of 16; and, at this point, with the latest
 patches, it's easily tuned.  The auto-sizing of the direct map is not
 affected by sparse space as it keys off Maxmem, which is not actually
 physical size, but rather one past last valid physical page.


Here is the patch that I intend to commit:
http://people.freebsd.org/~neel/patches/amd64_pmap_4TB.patch

This patch bumps up the direct map to 4TB and the KVA to 2TB.

It is identical to the patch you posted on hackers except for changing the
limits:
http://lists.freebsd.org/pipermail/freebsd-hackers/2013-July/043139.html

Tested inside a bhyve virtual machine with a *very* sparse memory layout
with a memory segment that cuddles up with the 4TB limit.

best
Neel



 The direct map limit might not need to be twice kernel virtual size but
 on Intel memory-controller systems needs to be greater than KVM size due
 to moving DRAM up past the PCI hole.  Unless the restriction that the
 direct-map area be a power of two size is removed, that winds up meaning
 twice.  (Removing the restriction seems easy enough—instead of pa |
 highbits to obtain VA and va ~ highbits to obtain PA, just use phys +
 offset and virt - offset.  I didn't see a reason to bother with the
 effort, though.)

 Chris

___
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: Panic when starting X with Intel KMS

2013-07-29 Thread Neel Natu

Hi Michael,

On Mon, Jul 29, 2013 at 7:05 AM, Michael Butler
i...@protected-networks.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 I wrote:

 Post SVN r252653, I have experienced a similar problem but I'm not sure
 it's related ..

 This is related to SVN r252653 - reverting it solves the instances of
 the panic detailed below.

 The recent modification to amd64 addresses the issue but does nothing to
 help this CPU ..

 CPU: Genuine Intel(R) CPU   T2300  @ 1.66GHz (1662.53-MHz
 686-class CPU)
   Origin = GenuineIntel  Id = 0x6e8  Family = 0x6  Model = 0xe
 Stepping = 8

 Features=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
   Features2=0xc1a9SSE3,MON,VMX,EST,TM2,xTPR,PDCM
   TSC: P-state invariant, performance statistics

  .. which claims to have ..

 imb@toshi:/home/imb sysctl vm.pmap
 vm.pmap.pv_entry_count: 627756
 vm.pmap.pde.promotions: 20165
 vm.pmap.pde.p_failures: 44416
 vm.pmap.pde.mappings: 0
 vm.pmap.pde.demotions: 19659
 vm.pmap.shpgperproc: 200
 vm.pmap.pv_entry_max: 2000208
 vm.pmap.pg_ps_enabled: 1
 vm.pmap.pat_works: 1

 Perhaps an equivalent patch to i386/pmap.c is appropriate here?


Let me take a look at the i386/pmap and get back to you.

best
Neel

 root@toshi:/var/crash # less info.1
 Dump header from device /dev/ada0s3b
   Architecture: i386
   Architecture Version: 2
   Dump Length: 205541376B (196 MB)
   Blocksize: 512
   Dumptime: Sat Jul 20 15:21:39 2013
   Hostname: toshi.auburn.protected-networks.net
   Magic: FreeBSD Kernel Dump
   Version String: FreeBSD 10.0-CURRENT #5 r253505M: Sat Jul 20 14:48:32
 EDT 2013
 i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI
   Panic String: bad pte
   Dump Parity: 854235148
   Bounds: 1
   Dump Status: good

 root@toshi:/var/crash # kgdb /boot/kernel.old/kernel vmcore.1

  [ snip ]

 #0  0xc07b814c in doadump ()
 (kgdb) bt
 #0  0xc07b814c in doadump ()
 #1  0xc07b86ec in kern_reboot ()
 #2  0xc07b8b68 in panic ()
 #3  0xc0b20b1d in pmap_remove_pages ()
 #4  0xc0aa43dd in vmspace_exit ()
 #5  0xc07814bf in exit1 ()
 #6  0xc07ba5d5 in sigexit ()
 #7  0xc07bd35f in postsig ()
 #8  0xc0804e1b in ast ()
 #9  0xc0b132b7 in doreti_ast ()
 #10 0xf1633d08 in ?? ()
 #11 0x2c3b in ?? ()
 #
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.14 (FreeBSD)

 iEYEARECAAYFAlH2dpQACgkQQv9rrgRC1JKpagCfUTQI8XJigFB9OFWxk05oLnnA
 onIAoJkBE0O5JoPx+Mz40JBCquBSfthD
 =w566
 -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
___
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: Panic when starting X with Intel KMS

2013-07-22 Thread Neel Natu

Hi Gustau,

On Mon, Jul 22, 2013 at 12:38 PM, Gustau Pérez i Querol
gpe...@entel.upc.edu wrote:
 Al 22/07/2013 13:19, En/na Konstantin Belousov ha escrit:

 On Mon, Jul 22, 2013 at 12:43:56PM +0200, Gustau P??rez i Querol wrote:

 As a blind shot, try to
 revert r252653.

  r252652 works OK. r252653 panics.

 What if, instead of reverting r252653, apply the following:

 diff --git a/sys/vm/vm_phys.c b/sys/vm/vm_phys.c
 index 66f3b0c..78f07f7 100644
 --- a/sys/vm/vm_phys.c
 +++ b/sys/vm/vm_phys.c
 @@ -547,6 +547,8 @@ vm_phys_fictitious_reg_range(vm_paddr_t start,
 vm_paddr_t end,
 pi = atop(start);
 if (pi = first_page  atop(end)  vm_page_array_size) {
 fp = vm_page_array[pi - first_page];
 +   for (i = 0; i  page_count; i++)
 +   fp[i].flags = 0;
 malloced = FALSE;
 } else
   #endif

 ?


After applying the patch the system panics for the same reason and the
 KASSERT didn't evaluate like before. The count now when the system panics
 seem to have been overflowed again, you can find the core at:

  https://dl.dropboxusercontent.com/u/2094962/core.txt.6


Could you apply the following patch to amd64/amd64/pmap.c and see if
it fixes the problem:

http://people.freebsd.org/~neel/patches/pmap_remove_pages.patch

best
Neel








 --
Salut i força,

Gustau

 ---
 Prou top-posting :  http://ca.wikipedia.org/wiki/Top-posting
 Stop top-posting :  http://en.wikipedia.org/wiki/Posting_style

 O O O Gustau Pérez i Querol
 O O O Unitat de Gestió dels departaments
 O O O Matemàtica Aplicada IV i Enginyeria Telemàtica

   Universitat Politècnica de Catalunya
   Edifici C3 - Despatx S101-B
  UPC  Campus Nord UPC
   C/ Jordi Girona, 1-3
   08034 - Barcelona

 ___
 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: Lenovo x220 - hangs on shutdown

2013-07-22 Thread Neel Natu

Hi Joel,

On Mon, Jul 22, 2013 at 1:36 PM, Konstantin Belousov
kostik...@gmail.com wrote:
 On Mon, Jul 22, 2013 at 10:52:55AM -0700, Adrian Chadd wrote:
 Hi kib,

 Is there a wiki page or some other kind of documentation descibing how
 AMT works?
 It is Intel documentation for vPro. Setting up AMT on the motherboard
 is specific to the motherboard BIOS, you should look at the hardware
 vendor documentation.

 Random googling for you revealed e.g. http://wiki.debian.org/AMT
 which is actually good introduction (i.e. there is not much to say
 about AMT usage in fact).


 I'd like to set this up at home on some newer machines (read: buy
 machines that have this) but I don't know what/where to start.
 For the controlling side of things, I use amttools, available in
 ports collection as comms/amtterm.  The manual pages are brief
 but useful.

 Amttools provide amttool(1) for power control, and amtterm/gamt for console.

Could you apply the following patch to amd64/amd64/pmap.c and see if it helps?
http://people.freebsd.org/~neel/patches/pmap_remove_pages.patch

best
Neel
___
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

pkg_add not working

2013-04-17 Thread Neel Natu

Hi,

I am running HEAD and recently started getting errors on pkg_add.

uname: 10.0-CURRENT FreeBSD 10.0-CURRENT #103 r249396M: Thu Apr 11 23:25:06
PDT 2013

 pkg_add -r sudo
Error: Unable to get
ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-10-current/Latest/sudo.tbz:
File unavailable (e.g., file not found, no access)
pkg_add: unable to fetch '
ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-10-current/Latest/sudo.tbz'
by URL

This used to work pretty well until a few days ago. Any clues?

best
Neel
___
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

PATCH: display MSI-X table and pba offsets from pciconf -c

2013-01-31 Thread Neel Natu

Hi,

The following patch teaches pciconf(8) to display the table and pba
offsets when it displays the MSI-X capability.

The new output format will look like:

cap 11[70] = MSI-X supports 10 messages in map 0x1c[0x0][0x2000] enabled
OR
cap 11[70] = MSI-X supports 10 messages in maps 0x10[0x0] and
0x14[0x1000] enabled

Any objections to committing the patch?

best
Neel

Index: usr.sbin/pciconf/cap.c
===
--- cap.c   (revision 246087)
+++ cap.c   (working copy)
@@ -449,22 +449,30 @@
 static void
 cap_msix(int fd, struct pci_conf *p, uint8_t ptr)
 {
-   uint32_t val;
+   uint32_t val, table_offset, pba_offset;
uint16_t ctrl;
int msgnum, table_bar, pba_bar;

ctrl = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_CTRL, 2);
msgnum = (ctrl  PCIM_MSIXCTRL_TABLE_SIZE) + 1;
+
val = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_TABLE, 4);
table_bar = PCIR_BAR(val  PCIM_MSIX_BIR_MASK);
+   table_offset = val  ~PCIM_MSIX_BIR_MASK;
+
val = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_PBA, 4);
-   pba_bar = PCIR_BAR(val  PCIM_MSIX_BIR_MASK);   
+   pba_bar = PCIR_BAR(val  PCIM_MSIX_BIR_MASK);
+   pba_offset = val  ~PCIM_MSIX_BIR_MASK;
+
printf(MSI-X supports %d message%s , msgnum,
(msgnum == 1) ?  : s);
-   if (table_bar == pba_bar)
-   printf(in map 0x%x, table_bar);
-   else
-   printf(in maps 0x%x and 0x%x, table_bar, pba_bar);
+   if (table_bar == pba_bar) {
+   printf(in map 0x%x[0x%x][0x%x],
+   table_bar, table_offset, pba_offset);
+   } else {
+   printf(in maps 0x%x[0x%x] and 0x%x[0x%x],
+   table_bar, table_offset, pba_bar, pba_offset);
+   }
if (ctrl  PCIM_MSIXCTRL_MSIX_ENABLE)
printf( enabled);
 }
___
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: PATCH: display MSI-X table and pba offsets from pciconf -c

2013-01-31 Thread Neel Natu

Hi Jim,

On Thu, Jan 31, 2013 at 3:13 PM, Jim Harris jim.har...@gmail.com wrote:


 On Thu, Jan 31, 2013 at 3:52 PM, Neel Natu neeln...@gmail.com wrote:

 Hi,

 The following patch teaches pciconf(8) to display the table and pba
 offsets when it displays the MSI-X capability.

 The new output format will look like:

 cap 11[70] = MSI-X supports 10 messages in map 0x1c[0x0][0x2000] enabled
 OR
 cap 11[70] = MSI-X supports 10 messages in maps 0x10[0x0] and
 0x14[0x1000] enabled

 Any objections to committing the patch?


 Functionally I think this is a good addition.  More information from pciconf
 the better.

 Other comments below.


 best
 Neel

 Index: usr.sbin/pciconf/cap.c
 ===
 --- cap.c   (revision 246087)
 +++ cap.c   (working copy)
 @@ -449,22 +449,30 @@
  static void
  cap_msix(int fd, struct pci_conf *p, uint8_t ptr)
  {
 -   uint32_t val;
 +   uint32_t val, table_offset, pba_offset;


 Variables should be in alphabetical order.


Ok.


 uint16_t ctrl;
 int msgnum, table_bar, pba_bar;

 ctrl = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_CTRL, 2);
 msgnum = (ctrl  PCIM_MSIXCTRL_TABLE_SIZE) + 1;
 +


 Newline added intentionally?


Yes.


 val = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_TABLE, 4);
 table_bar = PCIR_BAR(val  PCIM_MSIX_BIR_MASK);
 +   table_offset = val  ~PCIM_MSIX_BIR_MASK;
 +
 val = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_PBA, 4);
 -   pba_bar = PCIR_BAR(val  PCIM_MSIX_BIR_MASK);
 +   pba_bar = PCIR_BAR(val  PCIM_MSIX_BIR_MASK);


 Looks like these two lines only have whitespace difference.


Yes, there was trailing whitespace there previously.


 +   pba_offset = val  ~PCIM_MSIX_BIR_MASK;
 +
 printf(MSI-X supports %d message%s , msgnum,
 (msgnum == 1) ?  : s);
 -   if (table_bar == pba_bar)
 -   printf(in map 0x%x, table_bar);
 -   else
 -   printf(in maps 0x%x and 0x%x, table_bar, pba_bar);
 +   if (table_bar == pba_bar) {
 +   printf(in map 0x%x[0x%x][0x%x],
 +   table_bar, table_offset, pba_offset);
 +   } else {
 +   printf(in maps 0x%x[0x%x] and 0x%x[0x%x],
 +   table_bar, table_offset, pba_bar, pba_offset);
 +   }


 Seems like at least for the case where the table and pba are behind
 different BARs, this will exceed 80 characters.  So maybe the maps always go
 on a new line?  Similar to what's done at the end of cap_express for
 printing the link speed.


Ok, the new format will look like:

cap 11[70] = MSI-X supports 10 messages, enabled
 Table in map 0x1c[0x0], PBA in map 0x1c[0x2000]

Updated patch at the end of the email.

best
Neel


 if (ctrl  PCIM_MSIXCTRL_MSIX_ENABLE)
 printf( enabled);
  }


Index: usr.sbin/pciconf/cap.c
===
--- usr.sbin/pciconf/cap.c  (revision 246087)
+++ usr.sbin/pciconf/cap.c  (working copy)
@@ -449,24 +449,28 @@
 static void
 cap_msix(int fd, struct pci_conf *p, uint8_t ptr)
 {
-   uint32_t val;
+   uint32_t pba_offset, table_offset, val;
+   int msgnum, pba_bar, table_bar;
uint16_t ctrl;
-   int msgnum, table_bar, pba_bar;

ctrl = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_CTRL, 2);
msgnum = (ctrl  PCIM_MSIXCTRL_TABLE_SIZE) + 1;
+
val = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_TABLE, 4);
table_bar = PCIR_BAR(val  PCIM_MSIX_BIR_MASK);
+   table_offset = val  ~PCIM_MSIX_BIR_MASK;
+
val = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_PBA, 4);
-   pba_bar = PCIR_BAR(val  PCIM_MSIX_BIR_MASK);   
-   printf(MSI-X supports %d message%s , msgnum,
-   (msgnum == 1) ?  : s);
-   if (table_bar == pba_bar)
-   printf(in map 0x%x, table_bar);
-   else
-   printf(in maps 0x%x and 0x%x, table_bar, pba_bar);
-   if (ctrl  PCIM_MSIXCTRL_MSIX_ENABLE)
-   printf( enabled);
+   pba_bar = PCIR_BAR(val  PCIM_MSIX_BIR_MASK);
+   pba_offset = val  ~PCIM_MSIX_BIR_MASK;
+
+   printf(MSI-X supports %d message%s%s\n, msgnum,
+   (msgnum == 1) ?  : s,
+   (ctrl  PCIM_MSIXCTRL_MSIX_ENABLE) ? , enabled : );
+
+   printf( );
+   printf(Table in map 0x%x[0x%x], PBA in map 0x%x[0x%x],
+   table_bar, table_offset, pba_bar, pba_offset);
 }

 static void
___
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: BHyVe on 10-Current r245673

2013-01-29 Thread Neel Natu

Hi Gary,

On Tue, Jan 29, 2013 at 6:15 AM, G B g_patri...@yahoo.com wrote:
 I am using FreeBSD 10-Current r245673 as a host on an HP p2-1394.  I have the 
 host OS installed on 1 drive using UFS and a second drive using ZFS with a 
 pool named 'tank.'  They layout for zfs for my guest install is /tank/guest01.

 When using the command:
 # bhyveload -d /tmp/FreeBSD-9.1-RELEASE-amd64-disk1.iso -m 512 -h 
 /tank/guest01 guest01  bhyve -c 2 -a -A -m 512 -g 0 -P -H -s 
 1,virtio-net,tap0 -s 2,virtio-blk,diskdev guest01  sleep 20  ifconfig 
 tap0 up

 I get the boot screen for FreeBSD 9.1 and after the timed pause it fails with:
 Could not open backing file: No such file or directory
 ACPI tables require and ioapic
 Assertion failed: (error == 0), function main, file 
 /usr/src/usr.sbin/bhyve/bhyverun.c, line 774.
 Abort (core dumped)
 root@localhost:/tmp#

 I am using the bhyveload comamnd from a PDF I found from BSDCan but when I 
 used the -m 768 -M 1024 as used in the doc it failed with a syntax error, so 
 I switched to using just -m 512.  My .iso is in /tmp as indicated in my 
 command with '-d'.

 I'm guessing my command is wrong, but not sure where.  Any help would be 
 appreciated.


Can you try out the following instructions to get you started?
http://people.freebsd.org/~neel/bhyve/bhyve_instructions.txt

The script that I use is pretty basic and has less bells and whistles
than other howto guides out there. But that makes it easier to figure
out what is happening under the hood.

best
Neel

 Thanks,
 Gary
 ___
 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: [PATCH] uart_core: start countdown for non-interrupt mode

Re: [CFR] Replacing while loops with proper division and multiplication

Re: [CFR] Replacing while loops with proper division and multiplication

Re: cam(4) timeouts in bhyve/kyua runs up on Jenkins?

Re: Panic on 11.0-CURRENT when trying kldload vmm

Re: Panic on 11.0-CURRENT when trying kldload vmm

Re: Xen HVM Panic, HEAD

Re: panic in softdep_slowdown()

Re: panic in softdep_slowdown()

Re: Haswell CPU Feature

Re: Haswell CPU Feature

Re: any primer on running bhyve guests sharing disk with host ?

Re: HEADS UP: Merging projects/bhyve_svm to HEAD

Re: HEADS UP: Merging projects/bhyve_svm to HEAD

Re: HEADS UP: Merging projects/bhyve_svm to HEAD

Re: tmpfs panic

Re: [head tinderbox] failure on amd64/amd64

Re: CURRENT: build world failure: /usr/src/usr.sbin/bhyvectl/bhyvectl.c:1466:8: error: use of undeclared identifier 'VMCS_EXIT_INTERRUPTION_ERROR' VMCS_EXIT_INTERRUPTION_ERROR, u64);

Re: 11.0-CURRENT panic while running a bhyve instance

Re: 11.0-CURRENT panic while running a bhyve instance

Re: 11.0-CURRENT panic while running a bhyve instance

Re: expanding past 1 TB on amd64

Re: Panic when starting X with Intel KMS

Re: Panic when starting X with Intel KMS

Re: Lenovo x220 - hangs on shutdown

pkg_add not working

PATCH: display MSI-X table and pba offsets from pciconf -c

Re: PATCH: display MSI-X table and pba offsets from pciconf -c

Re: BHyVe on 10-Current r245673

29 matches

Site Navigation

Mail list logo

Footer information