RE: [BUG] ACPI resource validation not working [Was: Re: ITE 8728F]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm going to let Lin Ming respond to this, since the functions in question appear to be Linux extensions to ACPICA.

> -----Original Message-----
> From: Luca Tettamanti [mailto:kronos.it@xxxxxxxxx]
> Sent: Monday, November 28, 2011 12:54 PM
> To: Jean Delvare
> Cc: Nikolay Mikov; Thomas; Moore, Robert; linux-acpi@xxxxxxxxxxxxxxx
> Subject: [BUG] ACPI resource validation not working [Was: Re: ITE
> 8728F]
> 
> To give some context to the newcomers: while helping a user with a new
> hwmon chip we discovered that the native driver is loaded fine even
> though the IO ports are claimed by ACPI (OperationRegion) and
> acpi_enforce_resources is "strict".
> 
> On Mon, Nov 28, 2011 at 4:48 PM, Luca Tettamanti <kronos.it@xxxxxxxxx>
> wrote:
> > On Mon, Nov 28, 2011 at 4:08 PM, Jean Delvare <khali@xxxxxxxxxxxx>
> wrote:
> >> On Mon, 28 Nov 2011 14:02:51 +0100, Luca Tettamanti wrote:
> >>> The DSDT has this:
> >>>
> >>> Name (IOEB, 0x0290)
> >>> OperationRegion (SIOE, SystemIO, IOEB, 0x20)
> >>> Field (SIOE, ByteAcc, NoLock, Preserve)
> >>> {
> >>>     Offset (0x05),
> >>>     GIDX,   8,
> >>>     GDAT,   8
> >>> }
> >>>
> >>> so the requested area is well within what ACPI claims.
> [cut]
> >> A colleague of mine (hi Thomas!) suggests that Nikolay could boot
> with:
> >>
> >> ddebug="file osl.c +p
> >
> > This should be:
> >
> > ddebug_query="file osl.c +p"
> >
> > It should spam the log with all the resources found by ACPI parser,
> > assuming that CONFIG_DYNAMIC_DEBUG is enabled.
> 
> Hum, the call to acpi_os_validate_address was removed between 2.6.38
> and 2.6.39, with this commit by Bob More:
> 
> commit 9ad19ac456a5f097f7cbbfef820b95297d6a934f
> Author: Bob Moore <robert.moore@xxxxxxxxx>
> Date:   Mon Feb 14 16:09:40 2011 +0800
> 
>     ACPICA: Split large dsopcode and dsload.c files.
> 
> which seems to be just moving code around (the culprit here is
> acpi_ds_get_region_arguments). I guess that the removal wasn't
> intentional since the corresponding call to acpi_os_invalidate_address
> was left in place.
> Bob should I put the call back in place? Am I missing something?
> 
> Luca
��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux