Re: HEADS UP: Merging projects/bhyve_svm to HEAD
Hi, On Sat, Oct 25, 2014 at 3:50 PM, Zaphod Beeblebrox 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 > 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 >> > 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: HEADS UP: Merging projects/bhyve_svm to HEAD
Hi Matthew, On Tue, Dec 9, 2014 at 9:45 AM, Matthew Grooms wrote: > On 12/9/2014 11:03 AM, John Nielsen wrote: >> >> On Oct 26, 2014, at 4:40 PM, Zaphod Beeblebrox wrote: >> >>> On Sat, Oct 25, 2014 at 8:20 PM, Neel Natu wrote: >>> >>>> On Sat, Oct 25, 2014 at 3:50 PM, Zaphod Beeblebrox >>>> 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
Hi, On Tue, Dec 9, 2014 at 10:37 AM, Neel Natu wrote: > Hi Matthew, > > On Tue, Dec 9, 2014 at 9:45 AM, Matthew Grooms wrote: >> On 12/9/2014 11:03 AM, John Nielsen wrote: >>> >>> On Oct 26, 2014, at 4:40 PM, Zaphod Beeblebrox wrote: >>> >>>> On Sat, Oct 25, 2014 at 8:20 PM, Neel Natu wrote: >>>> >>>>> On Sat, Oct 25, 2014 at 3:50 PM, Zaphod Beeblebrox >>>>> 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: any primer on running bhyve guests sharing disk with host ?
Hi Luigi, On Sat, Jan 3, 2015 at 8:15 AM, Luigi Rizzo 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: Haswell CPU Feature
Hi Sean, On Mon, Jan 5, 2015 at 4:46 PM, Sean Bruno wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > "\014" > > > 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=0xbfebfbff > > Features2=0x7ffafbbf,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
Hi Sean, On Mon, Jan 5, 2015 at 6:34 PM, Sean Bruno 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 >> 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=0xbfebfbff >> >> > Features2=0x7ffafbff,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 */ > - - "\014" > + "\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: panic in softdep_slowdown()
Hi Gleb, On Wed, Jan 28, 2015 at 11:33 AM, Gleb Smirnoff 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 : mov-0x20(%rbp),%ecx > 0x80895d46 : mov%ecx,%edx > 0x80895d48 : shr$0x1f,%edx > 0x80895d4b : add%edx,%ecx > 0x80895d4d : sar%ecx > 0x80895d4f : mov0x80ee24c8,%edx > 0x80895d56 : mov%rax,-0x40(%rbp) > 0x80895d5a : mov%ecx,%eax > 0x80895d5c : mov%edx,-0x44(%rbp) > 0x80895d5f : cltd > 0x80895d60 : mov-0x44(%rbp),%ecx > 0x80895d63 : 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()
A fix for this panic was submitted by kib@ as r277922: https://svnweb.freebsd.org/base?view=revision&revision=277922 best Neel On Wed, Jan 28, 2015 at 11:54 AM, Neel Natu wrote: > Hi Gleb, > > On Wed, Jan 28, 2015 at 11:33 AM, Gleb Smirnoff 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 : mov-0x20(%rbp),%ecx >> 0x80895d46 : mov%ecx,%edx >> 0x80895d48 : shr$0x1f,%edx >> 0x80895d4b : add%edx,%ecx >> 0x80895d4d : sar%ecx >> 0x80895d4f : mov >> 0x80ee24c8,%edx >> 0x80895d56 : mov%rax,-0x40(%rbp) >> 0x80895d5a : mov%ecx,%eax >> 0x80895d5c : mov%edx,-0x44(%rbp) >> 0x80895d5f : cltd >> 0x80895d60 : mov-0x44(%rbp),%ecx >> 0x80895d63 : 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: Xen HVM Panic, HEAD
Hi Adrian, On Wed, Feb 18, 2015 at 10:09 PM, Adrian Chadd 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 on 11.0-CURRENT when trying "kldload vmm"
Hi Markiyan, On Thu, Apr 16, 2015 at 1:01 PM, Markiyan Kushnir 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: Panic on 11.0-CURRENT when trying "kldload vmm"
Hi Markiyan, On Thu, Apr 16, 2015 at 1:30 PM, Markiyan Kushnir wrote: > 2015-04-16 23:20 GMT+03:00 Neel Natu : >> Hi Markiyan, >> >> On Thu, Apr 16, 2015 at 1:01 PM, Markiyan Kushnir >> 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: cam(4) timeouts in bhyve/kyua runs up on Jenkins?
Hi NGie, On Mon, May 25, 2015 at 1:40 PM, Garrett Cooper wrote: > On Apr 28, 2015, at 0:54, Alexander Motin wrote: > >> Hi. >> >> On 27.04.2015 21:17, Garrett Cooper wrote: >>> On Apr 27, 2015, at 11:16, Garrett Cooper >>> 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: [CFR] Replacing while loops with proper division and multiplication
Hi Hans,
On Fri, Jun 5, 2015 at 12:09 AM, Hans Petter Selasky 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
Hi Hans,
On Fri, Jun 5, 2015 at 11:53 AM, Hans Petter Selasky 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: [PATCH] uart_core: start countdown for non-interrupt mode
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 wrote: > Aleksey Kuleshov 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: BHyVe on 10-Current r245673
Hi Gary, On Tue, Jan 29, 2013 at 6:15 AM, G B 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"
PATCH: display MSI-X table and pba offsets from "pciconf -c"
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"
Hi Jim,
On Thu, Jan 31, 2013 at 3:13 PM, Jim Harris wrote:
>
>
> On Thu, Jan 31, 2013 at 3:52 PM, Neel Natu 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: 11.0-CURRENT panic while running a bhyve instance
Hi Markiyan, On Fri, Dec 13, 2013 at 2:35 PM, Markiyan Kushnir wrote: > 2013/12/13 John Baldwin : >> 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 >>> 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
Hi Markiyan, On Sat, Dec 14, 2013 at 6:00 AM, Markiyan Kushnir wrote: > 2013/12/14 Markiyan Kushnir : >> 2013/12/14 Markiyan Kushnir : >>> 2013/12/14 Neel Natu : >>>> Hi Markiyan, >>>> >>>> On Fri, Dec 13, 2013 at 2:35 PM, Markiyan Kushnir >>>> wrote: >>>>> 2013/12/13 John Baldwin : >>>>>> 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. > >> >>> -- >>> Markiyan. >>> >>>> best >>>> Neel >>>> >>>>> -- >>>>> Markiyan. >>>>> >>>>>>> -- >>>>>>> Markiyan >>>>>>> >>>>>>> >>>>>>> -- Forwarded message -- >>>>>>> From: Markiyan Kushnir >>>>>>> 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
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 wrote: > 2013/12/13 John Baldwin : >> 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 >>> 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: [head tinderbox] failure on amd64/amd64
Sorry, my bad. Fixed in r260550. best Neel On Sat, Jan 11, 2014 at 8:06 AM, FreeBSD Tinderbox 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);
Hi Marcus, On Sat, Jan 11, 2014 at 4:52 AM, Marcus Karlsson 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: tmpfs panic
Hi Steve,
On Sun, Jul 6, 2014 at 8:46 AM, Steve Wills 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"
pkg_add not working
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"
Re: Panic when starting X with Intel KMS
Hi Gustau,
On Mon, Jul 22, 2013 at 12:38 PM, Gustau Pérez i Querol
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
Hi Joel, On Mon, Jul 22, 2013 at 1:36 PM, Konstantin Belousov 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"
Re: Panic when starting X with Intel KMS
Hi Michael, On Mon, Jul 29, 2013 at 7:05 AM, Michael Butler 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=0xbfe9fbff > Features2=0xc1a9 > 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: expanding past 1 TB on amd64
Hi Chris, Alan: On Sun, Jul 21, 2013 at 1:19 AM, Chris Torek 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"
