Re: Somewhat important ACPI diff

2013-05-20 Thread Vadim Zhukov
2013/5/20 Mark Kettenis > As diagnosed by some other people (armani@, jcs@?) a while ago, our > code to deal with IndexField() operators in our AML interpreter is > quite broken. It works for fields that are less than a byte in size, > but anything else is pretty much completely busted. I would

Re: Somewhat important ACPI diff

2013-05-20 Thread Kyle Milz
On Mon, May 20, 2013 at 06:57:56PM +0200, Mark Kettenis wrote: > As diagnosed by some other people (armani@, jcs@?) a while ago, our > code to deal with IndexField() operators in our AML interpreter is > quite broken. It works for fields that are less than a byte in size, > but anything else is pr

Re: Somewhat important ACPI diff

2013-05-20 Thread Kenneth R Westerback
On Mon, May 20, 2013 at 06:57:56PM +0200, Mark Kettenis wrote: > As diagnosed by some other people (armani@, jcs@?) a while ago, our > code to deal with IndexField() operators in our AML interpreter is > quite broken. It works for fields that are less than a byte in size, > but anything else is pr

Re: Somewhat important ACPI diff

2013-05-20 Thread James Turner
On Mon, May 20, 2013 at 06:57:56PM +0200, Mark Kettenis wrote: > As diagnosed by some other people (armani@, jcs@?) a while ago, our > code to deal with IndexField() operators in our AML interpreter is > quite broken. It works for fields that are less than a byte in size, > but anything else is pr

amd64errata.c,v 1.4

2013-05-20 Thread Alexey Suslikov
For our crash, v 1.4 of amd64errata.c is no-op unless we de-static functions' prototypes. acpiprt0 at acpi0: bus 0 (PCI0) mpbios0 at bios0: Intel MP Specification 1.4 cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Phenom(tm) 9550 Quad-Core Processor, 3600.54 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,P

Re: iked(8) and GCM

2013-05-20 Thread Stuart Henderson
On 2013/05/20 10:56, Aaron Stellman wrote: > On Sat, May 18, 2013 at 04:30:43AM +0200, Reyk Floeter wrote: > > You're mixing up GCM and GMAC. You have to update your config to use > > aes-256-gcm instead of aes-256-gmac! The GMAC is actually only the > > authentication part and it is not encrypti

Re: Somewhat important ACPI diff

2013-05-20 Thread Timo Myyrä
Mark Kettenis writes: > As diagnosed by some other people (armani@, jcs@?) a while ago, our > code to deal with IndexField() operators in our AML interpreter is > quite broken. It works for fields that are less than a byte in size, > but anything else is pretty much completely busted. I wouldn'

Re: UPDATE: xf86-input-synaptics 1.7.0

2013-05-20 Thread Alexandr Shadchin
On Thu, May 02, 2013 at 10:11:23PM +0600, Alexandr Shadchin wrote: > Hi, > > This update xf86-input-synaptics to the latest release 1.7.0. > http://koba.devio.us/distfiles/xf86-input-synaptics-1.7.0.diff > > Tested on amd64 and i386. > > Comments ? OK ? > > -- > Alexandr Shadchin > Prepare d

Re: iked(8) and GCM

2013-05-20 Thread Aaron Stellman
On Sat, May 18, 2013 at 04:30:43AM +0200, Reyk Floeter wrote: > You're mixing up GCM and GMAC. You have to update your config to use > aes-256-gcm instead of aes-256-gmac! The GMAC is actually only the > authentication part and it is not encrypting the payload. You can > see it as "childsa enc n

Somewhat important ACPI diff

2013-05-20 Thread Mark Kettenis
As diagnosed by some other people (armani@, jcs@?) a while ago, our code to deal with IndexField() operators in our AML interpreter is quite broken. It works for fields that are less than a byte in size, but anything else is pretty much completely busted. I wouldn't be surprised if this is the ca

Re: add nl(1)

2013-05-20 Thread Todd C. Miller
On Mon, 20 May 2013 12:43:19 +0300, Arto Jonsson wrote: > Updated diff. I removed the int width handling and modified the > separator printing based on your comment. That looks good to me. - todd

Re: add nl(1)

2013-05-20 Thread Arto Jonsson
On Wed, May 15, 2013 at 06:16:55AM -0600, Todd C. Miller wrote: > I've taken your diff and merged some useful bits from FreeBSD. > Specifically, the use of getline() and multibyte support for the > -d option. > > I also made the functions non-static (though I don't think that is > such a big deal)