search for: blerk

Displaying 5 results from an estimated 5 matches for "blerk".

Did you mean: bleak
2007 May 01
9
Trying to fix "Unsupported combination of battery voltage / nr. of batteries" error
Hi, everyone, I've recently bought a UPS from Mecer. This is a South African brand that basically resells Mustek hardware, and this UPS is no exception; it's a Mustek product. It does come with software for Linux, but that is terrible (the background process that monitors the UPS is written in Java and needs a terminal to start properly, so you can't run it from a startup script...
2007 May 01
9
Trying to fix "Unsupported combination of battery voltage / nr. of batteries" error
Hi, everyone, I've recently bought a UPS from Mecer. This is a South African brand that basically resells Mustek hardware, and this UPS is no exception; it's a Mustek product. It does come with software for Linux, but that is terrible (the background process that monitors the UPS is written in Java and needs a terminal to start properly, so you can't run it from a startup script...
2013 Jul 14
0
[LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix
> And that is why I think you should just consider "bt $x,y" to be > trivially the same thing and not at all ambiguous. Because there is > ABSOLUTELY ZERO ambiguity when people write > > bt $63, mem > > Zero. Nada. None. The semantics are *exactly* the same for btl and btq > in this case, so why would you want the user to specify one or the > other? I
2013 Jul 14
2
[LLVMdev] [PATCH] x86/asm: avoid mnemonics without type suffix
On Sun, Jul 14, 2013 at 11:35 AM, Tim Northover <t.p.northover at gmail.com> wrote: > > I'm coming at this from the compiler side, where the register form is > unambiguous and not questioned. The discussion we're having involves > only the immediate form of the instruction. GNU as interprets: > > bt $63, mem > > as > btl $63, mem > > which may
2008 Nov 13
69
[PATCH 00 of 38] xen: add more Xen dom0 support
Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine