search for: inial

...password for NSS User Private Key and Certificate Services / NSS Certificate DB: password configured Aug 31 22:00:29 pve upsd[20522]: Intend to retrieve password for NSS User Private Key and Certificate Services / NSS Certificate DB: password configured Aug 31 22:00:29 pve upsd[20522]: Can not inialize SSL connection Aug 31 22:00:34 pve upsd[20522]: Intend to retrieve password for NSS User Private Key and Certificate Services / NSS Certificate DB: password configured Aug 31 22:00:34 pve upsd[20522]: Intend to retrieve password for NSS User Private Key and Certificate Services / NSS Certific...

...am following homework problem 4, Chapter 5, page 268 of Pinheiro and Bates book on mixed effect. I'm up to point where I've created a new class using an existing variance function class, varExp as a template. Next I need to write an initialize method. The book suggests that I use the inialize method for one of the exisiting variance functions for lme(), eg varExp. What I want is the syntax of the initialize.varExp method so that I can edit it to create an initialize method for my newly constructed class. So - I tried to get the text of this method, called initialize.varExp by usi...

...ecision to be made (reads a custom configuration file that answers the question: can $user redirect through $hostname). But I can't figure out the exact place to insertit in the OpenSSH source code. Could someone point me to the source file and line that is responsible for the server side inialization of a client local forward? I tried connecting in serverloop.c function: static void server_input_global_request(int type, u_int32_t seq, void *ctxt); which by its comment says it deals with "-R" style forwarding but this doesn't seem to be the correct place for "-L&quo...

Hi all, I just noticed this: https://sourceforge.net/p/flac/feature-requests/91/ a request for support of 32 bit audio data. The request has been around since 2008. Had two inial impressions: * Would adding this break brackwards compatibility too badly? Obviously decoding of 32 bit encoded data would not work with older versions of flac. * This is nuts. 24 bits has a dynamic range of ~140dB which is roughly the difference between a quiet whisper in a quiet room, to t...

...rspace, then tell the driver about that range and have the driver initialize the GPU and use that chunk for kernel private structure allocation. Issue is that it is kind of a API violation for nouveau kernel driver. Thought i am not familiar enough, maybe you can do ioctl to nouveau before nouveau inialize and allocate the kernel private buffer (gr and other stuff). If so then problem solve i guess. Process that want to use CUDA will need to do the mmap dance and early ioctl. Hope this helps, cheers Jérôme

Op 26-09-15 om 09:22 schreef Erik de Castro Lopo: > Had two inial impressions: > > * Would adding this break brackwards compatibility too badly? Obviously > decoding of 32 bit encoded data would not work with older versions of > flac. Probably not. I know that Josh at some point added a second residual coding method (rice2) to support 24-bit,...

Hi folks, After some time away from it, and a big rebase as a consequence, here is the updated version of paravirt_ops for x86_64, heading to inclusion. Your criticism is of course, very welcome. Have fun -- arch/x86_64/Kconfig | 11 arch/x86_64/ia32/syscall32.c | 2 arch/x86_64/kernel/Makefile | 1 arch/x86_64/kernel/apic.c | 2

Hi folks, After some time away from it, and a big rebase as a consequence, here is the updated version of paravirt_ops for x86_64, heading to inclusion. Your criticism is of course, very welcome. Have fun -- arch/x86_64/Kconfig | 11 arch/x86_64/ia32/syscall32.c | 2 arch/x86_64/kernel/Makefile | 1 arch/x86_64/kernel/apic.c | 2

Hi, This series corresponds do older patches in the paravirt series that was neither already applied, nor I will touch again. In general, they do not touch code that can be unified (at least, without being the unification a big problem on its own). They passed through this list a lot of times, so I feel them ready for inclusion, unless someone opposes. As with the other patches, they apply to

Hi, This series corresponds do older patches in the paravirt series that was neither already applied, nor I will touch again. In general, they do not touch code that can be unified (at least, without being the unification a big problem on its own). They passed through this list a lot of times, so I feel them ready for inclusion, unless someone opposes. As with the other patches, they apply to

On Wed, Jul 08, 2015 at 10:37:34AM +1000, Ben Skeggs wrote: > On 8 July 2015 at 10:31, Andrew Chew <achew at nvidia.com> wrote: > > On Wed, Jul 08, 2015 at 10:18:36AM +1000, Ben Skeggs wrote: > >> > There's some minimal state that needs to be mapped into GPU address space. > >> > One thing that comes to mind are pushbuffers, which are needed to submit

Here is an slightly updated version of the paravirt_ops patch. If your comments and criticism were welcome before, now it's even more! There are some issues that are _not_ addressed in this revision, and here are the causes: * split debugreg into multiple functions, suggested by Andi: - Me and jsfg agree that introducing more pvops (specially 14!) is not worthwhile. So, although we do

Here is an slightly updated version of the paravirt_ops patch. If your comments and criticism were welcome before, now it's even more! There are some issues that are _not_ addressed in this revision, and here are the causes: * split debugreg into multiple functions, suggested by Andi: - Me and jsfg agree that introducing more pvops (specially 14!) is not worthwhile. So, although we do

Hey folks, Here's a new spin of the pvops64 patch series. We didn't get that many comments from the last time, so it should be probably almost ready to get in. Heya! >From the last version, the most notable changes are: * consolidation of system.h, merging jeremy's comments about ordering concerns * consolidation of smp functions that goes through smp_ops. They're sharing

Hey folks, Here's a new spin of the pvops64 patch series. We didn't get that many comments from the last time, so it should be probably almost ready to get in. Heya! >From the last version, the most notable changes are: * consolidation of system.h, merging jeremy's comments about ordering concerns * consolidation of smp functions that goes through smp_ops. They're sharing

This is hopefully the last iteration of the pvops64 patch. >From the last version, we have only one change, which is include/asm-x86_64/processor.h: There were still one survivor in raw asm. Also, git screwed me up for some reason, and the 25th patch was missing the new files, paravirt.{c,h}. (although I do remember having git-add'ed it, but who knows...) Andrew, could you please push it

This is hopefully the last iteration of the pvops64 patch. >From the last version, we have only one change, which is include/asm-x86_64/processor.h: There were still one survivor in raw asm. Also, git screwed me up for some reason, and the 25th patch was missing the new files, paravirt.{c,h}. (although I do remember having git-add'ed it, but who knows...) Andrew, could you please push it

I've taken the liberty of starting a new thread to discuss the design of the Asterisk CDR mechanism. The discussion has been kindly initiated by murf putting together a proposal: http://svn.digium.com/svn/asterisk/team/murf/RFCs. After reading the proposal I still don't think it's the right way to go. To my mind adding more channel variables increases the complexity in a situation