similar to: VMX on Lenovo R61, disabled bi BIOS ?

Hi listmembers, not a really urgent question, but i''m just curious about it: Is it advised to use an irqbalanced on dom0 when running domU''s pinned to particular cores? as an example, i''ve got a dual quadcore xen system running with domU pinned to cores 1-3 (CPU#0) domU pinned to cores 4-5 (CPU#1) domU pinned to cores 6-7 (CPU#1) so dom0 should have 100% time on

Hi, does somebody know, if there is any documentation available on how to set mac addresses on virtual bridges / virtual interfaces? Keeping track of every mac in the particular segments is really impractical. Thanks for any suggestions! -- Stephan Seitz Senior System Administrator *netz-haut* e.K. multimediale kommunikation zweierweg 22 97074 würzburg fon: +49 931 2876247 fax: +49 931

Hi there, just a short question: Does someone know if it''s possible to use an USB HDD in one HVM domU? It doesn''t need to be the particular USB device, deligating the whole USB controller to this single domU wouldn''t hurt either. Also reconfiguration isn''t an issue, as - if it''s possible - USB devices would only be used by one domU. Thanks in

Hi there, Due to http://lwn.net/Articles/347006/ or http://lists.grok.org.uk/pipermail/full-disclosure/2009-August/070197.html virtually all x86 and x86_64 kernels are vulnerable. I patched and build a 2.6.29-xen-r4 kernel which has been posted on this list a few weeks ago. I''m using this kernel after a lot of testing productive. D/L here:

Hi there, during peak load on some running domU, I noticed random iSCSI "Reported LUNs data has changed" which forced me to shutdown the respective domU, re-login the target and do a fsck before starting domU again. This occurred on a 16 core machine, having only about 14 domUs running. Spare memory has been occupied by dom0 (about 40G). Each domU has it''s own iSCSI target.

Hi, I''ve recently setup a few machines with 3.2 64bit without any unresolvable problem. These machines all run pv domU''s and a view "basic" hvm domUs. As I''ve got one machine left for internal use and testing, I would like to take a look at pciback with VT-d support (bios screen shows a VT-d [enable|disable]). My question is, do I need to add patches, or use

Hi, I''ve recently setup a few machines with 3.2 64bit without any unresolvable problem. These machines all run pv domU''s and a view "basic" hvm domUs. As I''ve got one machine left for internal use and testing, I would like to take a look at pciback with VT-d support (bios screen shows a VT-d [enable|disable]). My question is, do I need to add patches, or use

While researching Areski's new Web-MeetMe management gui, I found some odd (from what I expected) behaviour). Using the CLI to set un/mute status works but does not update the flags, or so it appears. Starting with a fresh conference (1 user) *CLI> meetme list 3456 User #: 1 Channel: OH323/R61 Using the CLI to mute the caller (no change in the user status0 *CLI> meetme mute 3456 1

On Friday 04 April 2008 13:07, Chris Lattner wrote: > > So how does the undef store to null appear in the IR when it isn't > > attached anywhere and how can I get rid of it? > > Don't do undefined behavior? :) I don't think it's undefined behavior. Right before instcombine, we have this: %r60 = load <2 x i64>* %"$LCS_1", align 16 ; <<2

On Friday 04 April 2008 13:42, David Greene wrote: > On Friday 04 April 2008 13:07, Chris Lattner wrote: > > > So how does the undef store to null appear in the IR when it isn't > > > attached anywhere and how can I get rid of it? > > > > Don't do undefined behavior? :) > > I don't think it's undefined behavior. Right before instcombine, we

Dear R helpers   Following is a part of R code.   data_lab <- expand.grid(c("R11", "R12", "R13"), c("R21", "R22", "R23"), c("R31", "R32", "R33"), c("R41", "R42", "R43"), c("R51", "R52", "R53"), c("R61", "R62", "R63"),

Hello list, I have performed a fresh install (fully updated) of squeeze amd64 and installed the xen-linux-system-2.6.32-5-xen-amd64 package with all its dependencies. When I restart and tried to boot the linux-image-2.6.32-5-xen-amd64 (pvops style) kernel on bare-metal my laptop boots fine. When I use the hyper-visor on the system with the same linux-image-2.6.32-5-xen-amd64 kernel, it hangs

Hello list, I have performed a fresh install (fully updated) of squeeze amd64 and installed the xen-linux-system-2.6.32-5-xen-amd64 package with all its dependencies. When I restart and tried to boot the linux-image-2.6.32-5-xen-amd64 (pvops style) kernel on bare-metal my laptop boots fine. When I use the hyper-visor on the system with the same linux-image-2.6.32-5-xen-amd64 kernel, it hangs

Hi all, All of the data types are 32 bits and the pointer is 32 bit. Therefore, I need word adressing instead of byte adressing to use 8 GB memory. I was told that R600 uses word adressing and I looked at its codes but I could not find where the backends handles word adressing. Do you have any ideas about it? Thanks in advance. -------------- next part -------------- An HTML attachment was

Hello list, I cannot get make-kpkg to build a Xenlinux type kernel into a Debian kernel binary on my Debian Squeeze x86_64 system. I am using GNU/Linux kernel sources tree (2.6.34.4) with Xen patches for this custom kernel. I am trying to use the make-kpkg command to build a working linux-image-2.6.34.4-xen-amd64 package for my system. The sources are vanilla (available from kernel.org) with

On Fri, 4 Apr 2008, David Greene wrote: > I am confused by this bit of code in instcombine: > > 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { > 09790 const Value *GEPI0 = GEPI->getOperand(0); > 09791 // TODO: Consider a target hook for valid address spaces for this > xform. > 09792 if (isa<ConstantPointerNull>(GEPI0)

I am confused by this bit of code in instcombine: 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { 09790 const Value *GEPI0 = GEPI->getOperand(0); 09791 // TODO: Consider a target hook for valid address spaces for this xform. 09792 if (isa<ConstantPointerNull>(GEPI0) && 09793

Thanks Cristoph, I have that code in my backend, but unless I do the following, the registers are never considered 'live' into the call. / Handle a function call let isCall = 1, Defs = [ R0, R1, R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, R13, R14, R15, R16, R17, R18, R19, R20, R21, R22, R23, R24, R25, R26, R27, R28, R29, R30, R31, R32, R33, R34, R35, R36, R37, R38, R39, R40, R41,

Hi Micah, > In X86InstrInfo.td for Call Instructions, it mentions that Uses for > argument registers are added manually. Can someone point me to the > location where they are added as the comment doesn't reference a > where or how? the register uses are added by the function X86TargetLowering::LowerCall() during the DAG Lowering phase. This is the relevant code segment: // Add

Hi, On 23-03-16 23:10, Samuel Pitoiset wrote: > Are you sure this won't break compute shaders on fermi? > Could you please double-check that? I just checked: lspci: 01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1) Before this patch-set: [hans at plank piglit]$ ./piglit run -o shader -t '.*arb_shader_storage_buffer_object.*' results/shader