Thread (2 messages) 2 messages, 2 authors, 2007-02-28

Re: PROBLEM: "BUG:" when resuming from suspend-to-ram

From: Kristian Grønfeldt Sørensen <hidden>
Date: 2007-02-28 00:28:27
Also in: lkml

On Tue, 2007-02-27 at 23:30 +0100, Rafael J. Wysocki wrote:
On Tuesday, 27 February 2007 23:04, Rafael J. Wysocki wrote:
quoted
Hi,

On Tuesday, 27 February 2007 19:45, Kristian Grønfeldt Sørensen wrote:
quoted
Hi.

PROBLEM: "BUG:" when resumimg from suspend-to-ram 
	
My laptop have a problem with resuming from suspend-to-ram. 
It does not occur every time - most of the time, resume works without
any problem.at all.

After it occurs, the laptop refuses to go into suspend-to-ram mode until
next reboot.
What do you mean by "refuses"?  Are there any suspicious messages in
dmesg?
quoted
The system is a Debian unstable running with a self-compiled 2.6.20
kernel downloaded from kernel.org. 

I've only tried suspend-to-ram on 2.6.20 so I don't know whether or not
other versions might have the same problem.

I'm not subscribed to the list. Please CC me.
I guess one of the drivers you use goes awry at some point.  Please provide
us with more information (like dmesg output after a failing resume).
I'm sorry, I've just been told you sent it. :-)
quoted
CLASS: Unregistering class device. ID = 'event3'
class_uevent - name = event3
class_device_create_uevent called for event3
device class 'event3': release.
class_device_create_release called for event3
BUG: unable to handle kernel paging request at virtual address 6b6b6b6b
 printing eip:
f8825a81
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
Modules linked in: tg3 battery ac thermal fan button i915 drm binfmt_misc
rfcomm l2cap ipv6 fuse capability commoncap cpufreq_performance aoe
af_packet nls_utf8 ntfs nls_iso8859_1 nls_cp437 vfat fat dm_snapshot
dm_mirror dm_mod ieee80211_cr ypt_tkip ieee80211_crypt pd6729 snd_seq_dummy
snd_seq_oss snd_seq_midi snd_rawmi di snd_seq_midi_event snd_seq
snd_seq_device sermouse hci_vhci hci_uart wbsd mmc _block mmc_core tun msr
cpuid cpufreq_stats container video speedstep_lib speeds tep_centrino
processor sr_mod sbp2 scsi_mod ide_cd cdrom eth1394 hci_usb bluetoo th
pcmcia firmware_class irda snd_intel8x0m snd_intel8x0 snd_ac97_codec
crc_ccit t ac97_bus snd_pcm_oss snd_mixer_oss rtc i2c_i801 snd_pcm
snd_timer ohci1394 iee e1394 i2c_core serio_raw intel_agp iTCO_wdt snd
soundcore snd_page_alloc ehci_hc d pcspkr uhci_hcd yenta_socket
rsrc_nonstatic pcmcia_core usbcore agpgart moused ev evdev
CPU:    0
EIP:    0060:[<f8825a81>]    Not tainted VLI
EFLAGS: 00010202   (2.6.20-x300 #1)
EIP is at evdev_disconnect+0xb1/0xe0 [evdev]
This points us to a suspect.  Can you please run "gdb vmlinux" against the
vmlinux in your kernel sources directory and then

gdb> l *evdev_disconnect+0xb1
OK. Recopiled the kernel with CONFIG_DEBUG_INFO=y

This gives: 

(gdb) l *evdev_disconnect+0xb1
No symbol "evdev_disconnect" in current context.

I guess you meant gdb drivers/input/evdev.ko

This gives:

(gdb) l *evdev_disconnect+0xb1
0xa81 is in evdev_disconnect (include/asm/processor.h:716).
711        However we don't do prefetches for pre XP Athlons currently
712        That should be fixed. */
713     #define ARCH_HAS_PREFETCH
714     static inline void prefetch(const void *x)
715     {
716             alternative_input(ASM_NOP4,
717                               "prefetchnta (%1)",
718                               X86_FEATURE_XMM,
719                               "r" (x));
720     }

/Kristian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help