similar to: Obscure login problem with samba as PDC

Displaying 5 results from an estimated 5 matches similar to: "Obscure login problem with samba as PDC"

2006 Apr 20
0
Major internal changes, TI DSP build change
>> You found it. The SHL32 (not SHR32) line fixes the problem. It must be >> doing a 16-bit shift, then extending the result (which is reasonable). >> As >> it happens, that it the same macro which gave us trouble last May >> (25th/26th), when the C55 build was more subtlely broken. > > Yes, that's what I finally remembered. I think I've fixed all
2007 Jul 02
3
Walking an HVM''s shadow page tables and other memory management questions.
Hello, I''m new to Xen and especially to the hypervisor code. I''m working off a 3.0.4.1 base and have the following questions regarding the memory management code for an x86, 32-bit platform (capable of supporting PAE). I''m doing some research into providing grant table hypercall support from a Windows 2003 HVM. I have made all the necessary changes to allow the
2007 Jan 12
0
[PATCH] xc_ptrace PAE awareness
Adjustments deemed necessary to properly support PAE (only compile-tested). Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-01-11/tools/libxc/xc_ptrace.c =================================================================== --- 2007-01-11.orig/tools/libxc/xc_ptrace.c 2006-12-14 22:49:56.000000000 +0100 +++ 2007-01-11/tools/libxc/xc_ptrace.c 2007-01-12 14:10:45.000000000 +0100 @@
2012 Jul 26
3
About revoke write access of all the shadows
Hi all, Recently, I read codes about the shadow page table. I''m wondering whether the kernel has provided the function to revoke write access of all the shadows of one domain. If you know one with this function, please tell me about it. Thanks. BTW, I have my own idea to implement this. My idea is as follows: void sh_revoke_write_access_all(struct domain *d) {
2006 Apr 19
2
Major internal changes, TI DSP build change
> You found it. The SHL32 (not SHR32) line fixes the problem. It must be > doing a 16-bit shift, then extending the result (which is reasonable). As > it happens, that it the same macro which gave us trouble last May > (25th/26th), when the C55 build was more subtlely broken. Yes, that's what I finally remembered. I think I've fixed all occurrences (by adding EXTEND32)