Suspend and resume on Dell E6520

[Ian Smith]

On Mon, 7 Nov 2011, Sebastian Chmielewski wrote:
 > On Thu, 3 Nov 2011 15:54:59 +1100 (EST)
 > Ian Smith <smithi at nimnet.asn.au> wrote:
 > 
 > > Just checking: this is with a kernel built without uhci, ohci and ehci?
 > 
 > 8.2-STABLE configured with:
 > #device ehci
 > #device ohci
 > #device ohci
 > in my kernel config.
 > {ehci,ohci,uhci}_load="YES" in loader.conf

Thanks for confirmation.

 > the same symptoms are for 9.0-BETA2 (official memstick)

GENERIC or kernel configured as above?

 > > The beep is generated by programming the good old-fashioned timer chip; 
 > > if the laptop normally beeps on boot or error it should beep on resume. 
 > > With this, my Thinkpad T23 (piercingly) beeped for a full 60 seconds on 
 > > resume for months, until learning it was (here) uhci causing that hang.
 > 
 > My laptop is able to beep - echo -e "\007" does a short beep, but there is no
 > beep on resume.

Ok, well I haven't looked at that code in a year or so, but I recall 
the asm code starting the beep was right at the start of resume, so I 
guess it's just not getting that far - but I don't claim to follow the 
suspend/resume code well in general, way too many layers and busses ..

 > > You could try setting sysctl hw.acpi.verbose=1 from /etc/sysctl.conf and 
 > > then booting with verbose messages, which logs a lot more detail around 
 > > suspend and resume, which may provide clues (though some of that logging 
 > > obviously occurs after resume succeeds).  Worth also maybe trying sysctl 
 > > hw.syscons.sc_no_suspend_vtswitch=1 which has helped on some laptops.
 > 
 > I did the following:
 > 
 > boot -s (all modules)
 > 
 > kldunload ehci
 > kldunload ohci
 > kldunload uhci
 > kldunload firewire
 > kldunload nvidia
 > sysctl hw.acpi.verbose=1
 > sysctl debug.acpi.resume_beep=1
 > sysctl hw.syscons.sc_no_suspend_vtswitch=1 (also tried without it)

 > zzz
 > (had to press Ctrl-C to go to sleep)

That must be a clue.  Same result if you use 'acpiconf -s3' instead?

 > press power button
 > - cpu fan goes on, screen is blank, no beep
 > - wait for 3 minutes, nothing changed
 > 
 > next I tried:
 > - at bootloader: unload, load /boot/kernel/kernel, load
 > /boot/kernel/{ahci.ko,zfs.ko}
 > - boot -s
 > - all sysctl's as above
 > - zzz (no Ctrl-C needed)
 > - pressed power button for resume
 > - nothing happens - no beep, no resume, screen is blank
 > 
 > so ehci,ohci are not the problem here.

Yes, seems likely something else.  I guess boot -s gives a non-verbose 
dmesg? Adding -v (or choose 'boot with verbose messages" into multiuser) 
prints a fair bit of info going into suspend, so even with it not 
resuming there may be some indications of any problems suspending?

(I've posted a verbose suspend/resume cycle below for an idea of what 
you might see.  This one was a year ago tomorrow at 8.1-STABLE when I 
was still trying to figure out the uhci-caused 60 second stall.  You 
should maybe get messages up to the first 'acpi_printcpu() debug dump')

 > This laptop has: 
 > - core i7 processor
 > - nvidia card (tried to suspend&resume without nvidia.ko, no luck)
 > - encrypted hard drive (tried to suspend&resume without it, still no luck)

Apart from the extra logging I can't think of anything else, sorry.

 > best regards,
 > -- 
 > Sebastian Chmielewski * jid:chmielsster at gmail.com * gg:3336919 * icq:224161389

(BTW excuse my spamblock on o2.pl, I've whitelisted your address now :)

cheers, Ian

acpi_button0: sleep button pressed
acpi_lid0: wake_prep enabled for \\_SB_.LID_ (S3)
acpi_button0: wake_prep enabled for \\_SB_.SLPB (S3)
vga0: saving 68 bytes of video state
vga0: saving color palette
pci0:1:0:0: Transition from D0 to D3
pci0:2:8:0: Transition from D0 to D3
ct_to_ts([2010-10-10 02:23:57]) = 1286677437.000000000
======== acpi_printcpu() debug dump ========
gdt[0097:c0e471a0] idt[07ff:c0e4f800] ldt[0050] tr[0048] efl[00080006]
eax[0141e000] ebx[00000000] ecx[c141e000] edx[0141e000]
esi[c4197b00] edi[00080202] ebp[df787b4c] esp[df787b2c]
cr0[8005003b] cr2[28162280] cr3[0141e000] cr4[000006d1]
cs[0020] ds[0028] es[0028] fs[0008] gs[001b] ss[0028]
======== acpi_printcpu() debug dump ========
gdt[0097:c0e471a0] idt[07ff:c0e4f800] ldt[0050] tr[0048] efl[00000002]
eax[c4930001] ebx[00000000] ecx[00000004] edx[c4930000]
esi[c4197b00] edi[00080202] ebp[df787b4c] esp[df787b2c]
cr0[8005003b] cr2[28162280] cr3[0141e000] cr4[000006d1]
cs[0020] ds[0028] es[0028] fs[0008] gs[001b] ss[0028]
acpi_lid0: run_prep cleaned up for \\_SB_.LID_
acpi_button0: run_prep cleaned up for \\_SB_.SLPB
pci0:1:0:0: Transition from D3 to D0
t_delta 15.fbb94811f04ece80 too short
t_delta 15.fbb95171aab13180 too short
t_delta 15.fbb9d4addc129b80 too short
ct_to_ts([2010-10-13 22:13:32]) = 1287008012.000000000
wakeup from sleeping state (slept 91:49:35)
ata0: reiniting channel ..
ata0: reset tp1 mask=03 ostat0=50 ostat1=00
ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00
ata0: reset tp2 stat0=50 stat1=00 devices=0x1
ad0: setting UDMA100
ata0: reinit done ..
ata1: reiniting channel ..
ata1: reset tp1 mask=03 ostat0=00 ostat1=00
ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00
ata1: reset tp2 stat0=00 stat1=00 devices=0x10000
acd0: setting UDMA33
ata1: reinit done ..
atkbd: the current kbd controller command byte 0047
atkbd: keyboard ID 0x54ab (2)
kbdc: RESET_KBD return code:00fa
kbdc: RESET_KBD status:00aa
kbdc: TEST_AUX_PORT status:0000
kbdc: RESET_AUX return code:00fa
kbdc: RESET_AUX status:00aa
kbdc: RESET_AUX ID:0000
battery0: battery initialization start
battery0: battery initialization done, tried 1 times
ts_to_ct(1287008356.707738396) = [2010-10-13 22:19:16]