[lkml]   [2002]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] resolve ACPI oops on boot
On Tue, Jul 23, 2002 at 05:20:57PM -0400, Bill Davidsen wrote:
> On Thu, 18 Jul 2002, Dominik Brodowski wrote:
> > An u8 was casted into an u32, then all 32 bits were set to zero, this
> > causing another variable - in my case, processor flags - to be corrupted.
> >
> > Dominik
> But that's not what's happening here, the pointer is being cast, if the
> object of the pointer is not u32, then casting the pointer doesn't fix the
> real problem. If the "data" pointer points to a u8, then no casting will
> make it work right when you save 32 bits into an 8 bit space. If this
> changes the problem it's because of alignment, perhaps.
There is the argument "size" to acpi_hw_low_level_read which makes sure that
only the right data is being read. Problem is that a sort of
"segmentation fault" occurs when such a cast allows writing in different
memory than allocated for the value.

> You give neither the kernel version nor the architecture
kernel version 2.5.2[5,6] or 2.4.-kernels with acpi-patch 20020709,
architecture: all architectures that implement Embedded Controllers.

> I think the cast is just to avoid the compiler whining about types, the
> version I have is actually type "(acpi_generic_address*)" not (u32*), I
> would think the compiler would still complain, but maybe only with
> -pedantic or whatever.
The casts were probably introduced for that reason. Per se, they are not
critical - but if there is any assumption later on that the data structure
is indeed of the large size, there is a problem.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.098 / U:0.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site