https://bugzilla.kernel.org/show_bug.cgi?id=14998


Vegard Nossum <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]




--- Comment #34 from Vegard Nossum <[email protected]>  2010-04-22 
20:20:43 ---
(In reply to comment #4)
> I've forgotten to say: I confirm I get this warning only by closing the lid. 
> No
> other operation seem to produce it, however I don't do many thinks while
> testing kernels: kmemcheck is slow and I'm not too confident with it.
> 
> I still have it with 2.6.33-rc4, the warning is the first thing that appears 
> in
> dmesg when I close the lid, then it is followed by the suspension code:
> 
> 
> WARNING: kmemcheck: Caught 32-bit read from uninitialized memory
> (ffff88004bfd3b5c)
> 000110000000adde000220000000adde627574746f6e2f6c6964000000000000
>  i i i i i i i i i i i i i i i i i i i i i i i i i i i u u u u u
>                                                          ^
> 
> Pid: 3396, comm: acpid Not tainted 2.6.33-rc4 #3 Aspire 1510/Aspire 1510
> RIP: 0010:[<ffffffff812694f5>]  [<ffffffff812694f5>]
> acpi_bus_receive_event+0xf5/0x119
> RSP: 0018:ffff88004cd79dd8  EFLAGS: 00010282
> RAX: 0000000000000038 RBX: ffff88004bfd3b40 RCX: 0000000000000007
> RDX: 00000000ffffffed RSI: ffff88004bfd3b5c RDI: ffff88004cd79e64
> RBP: ffff88004cd79e28 R08: 0000000000000000 R09: 0000000000000001
> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000282
> R13: ffff88004cd79e48 R14: ffff88004cd79f48 R15: 00000000009e0420
> FS:  00007fa9666316f0(0000) GS:ffffffff81a1c000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: ffff88004f810c48 CR3: 00000000419ce000 CR4: 00000000000006f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
>  [<ffffffff8126fb9e>] acpi_system_read_event+0x6b/0x115
>  [<ffffffff810fd3f9>] proc_reg_read+0x79/0xb0
>  [<ffffffff810b1917>] vfs_read+0xc7/0x160
>  [<ffffffff810b1aa0>] sys_read+0x50/0x90
>  [<ffffffff81002468>] system_call_fastpath+0x16/0x1b
>  [<ffffffffffffffff>] 0xffffffffffffffff
> eth1: deauthenticated from 00:07:cb:55:12:b0 (Reason: 7)
> PM: Syncing filesystems ... done.
> PM: Preparing system for mem sleep
> Freezing user space processes ... (elapsed 0.01 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> PM: Entering mem sleep
> Suspending console(s) (use no_console_suspend to debug)
> 
> The faulty line is:
> christ...@athor:~$ addr2line -e /usr/src/linux-2.6.33/vmlinux -i
> ffffffff8126fb9e
> /usr/src/linux-2.6.33/drivers/acpi/event.c:64
> 
> That is:
> 
> static ssize_t
> acpi_system_read_event(struct file *file, char __user * buffer, size_t count,
>                        loff_t * ppos)
> {
>         int result = 0;
>         struct acpi_bus_event event;
>         static char str[ACPI_MAX_STRING];
>         static int chars_remaining = 0;
>         static char *ptr;
> 
>         if (!chars_remaining) {
>                 memset(&event, 0, sizeof(struct acpi_bus_event));
> 
>                 if ((file->f_flags & O_NONBLOCK)
>                     && (list_empty(&acpi_bus_event_list)))
>                         return -EAGAIN;
> 
>                 result = acpi_bus_receive_event(&event);
> --->                if (result)
>                         return result;
> 
>                 chars_remaining = sprintf(str, "%s %s %08x %08x\n",
>                                           event.device_class ? event.
>                                           device_class : "<unknown>",
>                                           event.bus_id ? event.
>                                           bus_id : "<unknown>", event.type,
>                                           event.data);
> 
> One more time, I don't understand what can trigger this, since result is
> assigned just the preceding line. Maybe acpi_bus_receive_events is inlined?

I can explain why. You ran addr2line on the address of the first stack entry:

>  [<ffffffff8126fb9e>] acpi_system_read_event+0x6b/0x115
>  [<ffffffff810fd3f9>] proc_reg_read+0x79/0xb0

> christ...@athor:~$ addr2line -e /usr/src/linux-2.6.33/vmlinux -i
> ffffffff8126fb9e
> /usr/src/linux-2.6.33/drivers/acpi/event.c:64

It would have been more appropriate to run addr2line on the RIP value, i.e.
ffffffff812694f5:

> RIP: 0010:[<ffffffff812694f5>]  [<ffffffff812694f5>]

Additionally, since the stack entries are essentially return addresses, they
generally refer to the instruction just after the CALL instruction, not the
CALL itself.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

------------------------------------------------------------------------------
_______________________________________________
acpi-bugzilla mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla

Reply via email to