Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Feb 2011 13:40:54 -0500
From:      Jung-uk Kim <jkim@FreeBSD.org>
To:        freebsd-current@FreeBSD.org
Cc:        Michael Butler <imb@protected-networks.net>, Matthew Fleming <mdf356@gmail.com>
Subject:   Re: acpi_resource bug?
Message-ID:  <201102141340.56392.jkim@FreeBSD.org>
In-Reply-To: <4D594C54.5000801@protected-networks.net>
References:  <AANLkTi=C31iGJMonj7E3DGLWhx0cSKQR=b7ZHTv9CdmA@mail.gmail.com> <AANLkTimKJnyFQgTgtLTOFvmcY4fbK5gdT6mwt9zB=%2BRY@mail.gmail.com> <4D594C54.5000801@protected-networks.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 14 February 2011 10:37 am, Michael Butler wrote:
> On 02/14/11 10:29, Matthew Fleming wrote:
> >>> 1) should the length of the bcopy() be changed to either
> >>> respect res->Length or the actual length of the
> >>> ACPI_RESOURCE_DATA for the type?
> >>
> >> It should just use res->Length:
> >
> > Is there a guarantee that res->Length is <= sizeof(ACPI_RESOURCE)
> > ?
>
> I don't know if it's related or a different bug ..
>
> If I run 'acpidump -t', I get a core-dump and ..
>
>  [ .. snip .. ]
>
> /*
>   MCFG: Length=60, Revision=1, Checksum=74,
>         OEMID=INTEL, OEM Table ID=CALISTGA, OEM Revision=0x6040000,
>         Creator ID=LOHR, Creator Revision=0x5a
>
>         Base Address=0x00000000e0000000
>         Segment Group=0x0000
>         Start Bus=0
>         End Bus=255
>  */
> /*
>   TCPA: Length=50, Revision=1, Checksum=153,
>         OEMID=PTLTD, OEM Table ID=CALISTGA, OEM Revision=0x6040000,
>         Creator ID= PTL, Creator Revision=0x1
>         Class 0 Base Address 0x0 Length 65536
>
>         -268370093 0xc3e200f053ff00f053ff00f054ff00f0de9100f0
> [<unknown 0xf000ff53>]

No, I don't think it is not related.  Our acpidump(8) has its own 
table parser.

Jung-uk Kim



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201102141340.56392.jkim>