Bug 6653

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.