Most recent kernel where this bug did not occur: 2.6.16.19 Distribution: fedora core 5 Hardware Environment: dell e1505 Software Environment: fedore core 5/gnome Problem Description: keyboard does not work after resume from suspend to ram Steps to reproduce: boot kernel 2.6.17-rc5 and try suspend to ram, then resume.
Please post dmesg, interrupts .. after resume.
I can't. I can't do anything.
rc6 has same problem.
how about 2.6.17?
at .17.3, same problem:(
Could you possibly set up an SSH server on your box and log into it from another machine after resume?
no, i had dhcp IP through ethernet for eth0, but after resume, bt blue light comes on, but ssh from other machine to 192.168.0.2 says no route to host.
So it turns out the problem is not only with the keyboard. Still, we need to get _some_ debug information from this box. Please post the output of dmesg and lspci -vv (right after a fresh boot) from the kernel 2.6.18-rc2 as attachements. Also please try if the problem is still present in this kernel, just in case. I'm sorry I don't remember whether you tried the suspend to disk. If not, please do, Is there a serial port in this box? If not, do you have a USB keyboard?
i just tried with usb keyboard, same problem - no input worked, caps lock does not light up, etc. to get suspend to ram, i hit fn + standby fn + hibernate does nothing so you are asking me to try .18-rc2? i am currently at 17.6.
.18-rc2 contains some additional code changes that may fix your problem. Anyway, I think we should try to make the suspend to disk work on your box first. Do you use a swap partition or a swap file?
well, i did have suspend to ram working to an extent with .16 here are my mounts /dev/sda5 on / type ext3 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) automount(pid2154) on /net type autofs (rw,fd=4,pgrp=2154,minproto=2,maxproto=4)
Something broke your suspend to RAM after 2.6.16 and we need to figure out what it was. However, you can't get any relevant information from the box after the resume, so we can't do much with the suspend to RAM alone. The suspend to disk works a bit differently, so there's a chance it will work on your box with a recent kernel and perhaps we'll be able to get some information from it. Swap partitions don't show up in the output of mount. Please post the output of 'cat /proc/swaps'.
cat /proc/swaps Filename Type Size Used Priority/dev/sda6 partition 265032 0 -1
So you use a swap partition. Good. Now, do you use an initrd or are your hard disk-related drivers compiled in?
Created attachment 8610 [details] Kernel config for 2.6.17 I use initrd, because I couldn't get it booting when i tried to do the kernel myself from scratch(config) because it uses sata. Attached is my latest kernel config.
Now I think your box just locks up during resume because of the SATA driver(s). I think you will need some patches that are not yet in the mainline to successfully resume your box, so probably it's better if you wait until these patches get merged (unfortunately it's hard to tell when it will happen). Alternatively, I can help you find these patches, apply them etc., but this will take time too and rather won't be easy.
but why would you think that? i ask because it didn't lock up with 2.6.16 kernel.
IIRC, the SATA code changed between .16 and .17 in such a way that the suspend has stopped working on some configurations and additional patches are needed to make it work again. Hopefully these patches will be merged before .18 or soon after it.
ok. what would you have me do for now, or wait till .18?
I'd wait for .18-rc3 to appear and test the suspend to RAM with it.
Created attachment 8669 [details] lsmod and dmesg on resume on 18rc3
upgraded to 18rc3. same problem. oddly enough, this time I can ssh in, though, and do things, through wireless. Attached is lsmod and dmesg
So we some progress. ;-) Please also attach the output of 'cat /proc/interrupts' (before and after the resume) and 'lspci'. Have you tried to attach a USB keyboard to the box after the resume?
hmm, but it works now, i see! for some reason, it works now! now it goes back to password prompt within gnome. The only other thing, and I don't know if this is due to upgrading to rc3 or what, but now, when I get to X in gdm-binary, since upgrading to rc3, a LOUD pc beep emits when it gets to user prompt in gdm-binary after end of boot. Is that tied to anything? I need to stop it. I did notice one problem on video resume, though. When i set battery applet to initiate suspend after lid is closed and battery is not plugged in, when i open it, keyboard and such works, and i can ssh in, however, video does not display. But I DID try fn esc which initiated a suspend, THEN closed the lid, and after i opened lid it resumed fine.... what does that mean? I just tried, after I could not get video, suspending to ram again and resuming, but no go, still no video. I wonder if it means that the applet is initiating some other kind of suspend that does not deal with resume of video well? It seems that, the suspend that is initiated from fn-esc, i can resume fine from(including video)
I spoke too soon, I just tried suspending again then resuming, and it went back to no keyboard input not showing password prompt like before. it seems to work a LOT Of the time, but not all the time?
I have no idea what the problem may be.
? forget the beeping, that came with pcspkr module in 18rc3. so basically it works often when i evoke it from keystroke, however, when gnome's battery applet evokes it after lid is closed, i cannot get video back on resume. apparently there are still some occasions where it goes back to no input at all(and no video)
When you suspend from the command line, is it from under X? If so, the gnome appled probably does something that prevents the video from waking up, but I don't know what it is. The problem that sometimes there's no keyboard input after the resume seems to be BIOS/ACPI-related and I have only a little experience with these things.
Well, both ways I am suspending from X. but lately I am having problem again of no input at all working on resume. As you requested, I had a usb keyboard plugged in, and no input from it(or lights). I unplugged it then replugged it in, still no input or lights.
ok, I seem to be dealing with the same problem again with rc4. on resume, no real video display and no keyboard input will work.
This is about "after resume from suspend to ram, keyboard does not work" on a very specific machine? I wonder why this is a blocker, IMO this should be normal severity or even low... There may be a reason why it is like that, if not can somebody reduce severity, please.
it works often with 2.6.18 now, however, sometimes i still do not get video on resume and occasionally the lockups remain. it seems almost that it increases my chance of a safe recovery if, on resume, i keep hitting a key, like caps lock.
Can you please test 2.6.22-rc3 or the latest -git ?
I upgraded to f7 and 2.6.21. Keyboard works now, but not video on resume.
The video-related problems are often solved by using s2ram (http://en.opensuse.org/s2ram). Can you please try it?
well, suspend, which has s2ram, won't compile on fedora 7.
First, you need to do 'make s2ram' only, the rest is not needed. Second, you additionally need to download libx86 from http://www.codon.org.uk/~mjg59/libx86/downloads/ and install it (on xi386 run 'make' and 'make install'; on x86_64 you need to run 'make BACKEND=x86emu' and 'make install'). You also need pciutils-devel to be installed.
Yeah, I installed those other things, but s2ram won't compile make s2ram cc -O2 -Wall -g s2ram.c vt.o vbetool/lrmi.o vbetool/x86-common.o vbetool/vbetool.o radeontool.o dmidecode.o -lpci -o s2ram /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `pci_load_name_list': (.text+0x6e8): undefined reference to `gzopen' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `pci_load_name_list': (.text+0x781): undefined reference to `gzgets' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `.L174': (.text+0x886): undefined reference to `gzclose' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `.L174': (.text+0x8a8): undefined reference to `gzeof' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `.L174': (.text+0x945): undefined reference to `gzclose' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `.L174': (.text+0xd74): undefined reference to `gzopen' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `.L177': (.text+0xf17): undefined reference to `gzerror' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libpci.a(names.o): In function `.L177': (.text+0xf3a): undefined reference to `gzclose' collect2: ld returned 1 exit status make: *** [s2ram] Error 1 I am confused. Everything seems to work but video on resume, but I got it working in fc6 after some assistance from pm-utils list. Some config files needed changing or something?
> Yeah, I installed those other things, but s2ram won't compile You need zlib-devel to be installed (can you please read the README from the suspend package, at least?). > I am confused. Everything seems to work but video on resume, but I got it > working in fc6 after some assistance from pm-utils list. Some config files > needed changing or something? Sorry, I know a little about Fedora. You should ask Fedora people about that.
I did read readme:) i have zlib-devel installed zlib-1.2.3-10.fc7 zlib-devel-1.2.3-10.fc7
Created attachment 11639 [details] Current suspend.sf.net CVS, in tar.gz format Sorry. :-) Attached is a tarball with the current suspend.sf.net CVS. Can you try to compile s2ram from it?
Yup, s2ram doesn't bring back video either. Keyboard works fine, though. If I was blind I'd be happy:)
What's your graphics adapter and what s2ram options have you tried?
Sorry, I got it working. Here's my addition to top of dell file for pm-utils hal stuff <match key="system.hardware.product" contains="MM061"> <merge key="power_management.quirk.vbe_post" type="bool">true</merge> <merge key="power_management.quirk.vbestate_restore" type="bool">true</merge> </match>
Good. :-) Can I close this bug, then?
Sure, but I was told this is just a work around and there was still a kernel issue?
No, the kernel doesn't handle the reinitialization of graphics after a resume from RAM.
The original problem is fixed in 2.6.21. The other problem is a duplicate of Bug #7225. Closing, please reopen if necessary.