Bug 4900 - S3 resume oops with irattach - Thinkpad A21m
Summary: S3 resume oops with irattach - Thinkpad A21m
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Serial (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: Russell King
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-16 15:39 UTC by Daniel Smolik
Modified: 2005-11-21 14:26 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.12.1
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
oops on A21m after resume (4.26 KB, text/plain)
2005-08-21 15:43 UTC, Daniel Smolik
Details
patch to fix suspend oops (1005 bytes, patch)
2005-10-31 01:40 UTC, Russell King
Details | Diff
dmesg of suspend and resume (11.28 KB, text/plain)
2005-11-19 14:11 UTC, Daniel Smolik
Details
patch for better identification of ports (490 bytes, patch)
2005-11-19 14:43 UTC, Russell King
Details | Diff
OOPS captured via serial console (6.93 KB, text/plain)
2005-11-20 13:28 UTC, Daniel Smolik
Details
dmesg output (12.00 KB, text/plain)
2005-11-20 14:17 UTC, Daniel Smolik
Details

Description Daniel Smolik 2005-07-16 15:39:46 UTC
Distribution: Debian Sarge
Hardware Environment: Thinkpad A21m
Software Environment: 2.6.12.1
Problem Description: When I try sleep my notebook second time kernel oops.

Steps to reproduce:
Boot kernel and press sleep button under display two times.

ksymoops 2.4.9 on i686 2.6.12.1.  Options used
     -V (default)
     -k /proc/kallsyms (specified)
     -l /proc/modules (default)
     -o /lib/modules/2.6.12.1/ (default)
     -m /boot/System.map-2.6.12.1 (default)

Warning (read_ksyms): no kernel symbols in ksyms, is /proc/kallsyms a valid
ksyms file?
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
eax: 00000000  ebx:c039e5cc ecx: 00000000 edx: 00000003
esi: c039e9f8  edi:c039e9f8 ebp: c0320620 esp: ca803e4c
ds: 007b es:007b ss:0068
Stack: 00000000 00000000 ca802000 cbf8d028 c020c9be c039e9f8 00000000 c039e9f8
       c03a0b08 cbc2eaa8 00000003 c0210658 c03206c0 c039e9f8 cbc2caa8 00000003
       00000003 c0215323 cbc2eaa8 00000003 00000002 cbc2eaa8 00000000 c0216dbf
Call Trace:
[<c020c9be>] uart_suspend_port+0xde/0xf0
[<c0210658>] serial8250_suspend+0x68/0x70
[<c0215323>] paltform_suspend+0x43/0x80
[<c0216dbf>] suspend_device+0xaf/0x0xc0
[<c01bc22a>] kobject_get+0x1a/0x30
[<c0216c3c>] device_suspend+0x6c/0x0x160
[<c0136f47>] suspend_preparde+0x67/0xb0
[<c0137063>] enter_state+0x33/0x70
[<c01e4dff>] acpi_suspend+0x2a/0x3b
[<c01e4ef6>] acpi_system_write_sleept+0x72/0x84
[<c015998e>] vfs_write+0xae/0x130
[<c0159ae1>] sys_write+0x51/0x80
[<c0103185>] sys_call+0x7/0xb
Code: 2a 39 00 74 18 89 74 24 94 89 1c 24 e8 47 fe ff ff 8b 5c 24 08 8b 74 24 0c
Using defaults from ksymoops -t elf32-i386 -a i386



>>>>ebx; c039e5cc <irq_lists+c/380>
>>>>esi; c039e9f8 <serial8250_ports+b8/2280>
>>>>edi; c039e9f8 <serial8250_ports+b8/2280>
>>>>ebp; c0320620 <serial8250_pops+0/50>
>>>>esp; ca803e4c <pg0+a456e4c/3fc51400>


Trace; c020c9be <uart_suspend_port+de/f0>
Trace; c0210658 <serial8250_suspend+68/70>
Trace; c0215323 <platform_suspend+43/80>
Trace; c0216dbf <suspend_device+af/c0>
Trace; c01bc22a <kobject_get+1a/30>
Trace; c0216c3c <device_pm_add+6c/a0>
Trace; c0136f47 <suspend_prepare+67/b0>
Trace; c0137063 <enter_state+33/70>
Trace; c01e4dff <acpi_suspend+2a/3b>
Trace; c01e4ef6 <acpi_system_write_sleep+72/84>
Trace; c015998e <vfs_write+ae/130>
Trace; c0159ae1 <sys_write+51/80>
Trace; c0103185 <syscall_call+7/b>

Code;  00000000 Before first symbol
00000000 <_EIP>:
Code;  00000000 Before first symbol
   0:   2a 39                     sub    (%ecx),%bh
Code;  00000002 Before first symbol
   2:   00 74 18 89               add    %dh,0xffffff89(%eax,%ebx,1)
Code;  00000006 Before first symbol
   6:   74 24                     je     2c <_EIP+0x2c>
Code;  00000008 Before first symbol
   8:   94                        xchg   %eax,%esp
Code;  00000009 Before first symbol
   9:   89 1c 24                  mov    %ebx,(%esp)
Code;  0000000c Before first symbol
   c:   e8 47 fe ff ff            call   fffffe58 <_EIP+0xfffffe58>
Code;  00000011 Before first symbol
  11:   8b 5c 24 08               mov    0x8(%esp),%ebx
Code;  00000015 Before first symbol
  15:   8b 74 24 0c               mov    0xc(%esp),%esi


1 warning issued.  Results may not be reliable.
Comment 1 Daniel Smolik 2005-07-17 15:11:07 UTC
in 2.6.13-rc3 kernel doesn't oops., but system doesn't go to sleep. First time
when  I do echo 3 > /proc/acpi/sleep sytem sleeps but second time not.

Comment 2 Daniel Smolik 2005-07-18 15:12:36 UTC
I compile 2.6.13-rc3 with ACPI debuging and when I do echo 3 > /proc/acpi/sleep
second time system freeze an on console I see this.

Stopping tasks:=======================|
osl-961 [35] os_wait_semaphore : Failed to acquire semaphore[cbfee4e0|1|0],AE_TIME 
Comment 3 Len Brown 2005-08-14 22:35:37 UTC
> Failed to acquire semaphore[cbfee4e0|1|0],AE_TIME

still an issue with 2.6.l3-rc6?
Comment 4 Daniel Smolik 2005-08-15 08:52:32 UTC
> still an issue with 2.6.l3-rc6?
I try to test it today or tommorow. With RC5 problem still exists. But I found
new  details. When I stop irattach and don't insert acpi battery module sleep
working.

Comment 5 Daniel Smolik 2005-08-17 03:39:48 UTC
I today compile and test 2.6.13-rc6 and with stopped irattach all working fine.
Sleep is working !!!! But if I have irattach running after 1 resume from sleep
kernel says LSR safety check engla... I do second sleep and after resume kernel
OOPS. I can connect serial console and use ksymoops.If someone want  :-)

Dan
Comment 6 Len Brown 2005-08-17 12:37:19 UTC
So if you run 2.6.13-rc6 and don't have irattach running,
then you can suspend/resume repeatedly without any problems;
but if irattach is running then you get an oops?

Please attach the oops.  I'm not familiar with irattach, but
this is probably a device driver specific failure -- likely
the serial device.
Comment 7 Daniel Smolik 2005-08-21 15:43:40 UTC
Created attachment 5713 [details]
oops on A21m after resume

OOPS on A21m at ACPI
Comment 8 Daniel Smolik 2005-08-21 15:44:34 UTC
I reproduce oops and attach file with this.
Dan
Comment 9 Shaohua 2005-10-25 20:22:03 UTC
It's more likely a serial driver bug to me. Does latest kernel 2.6.14-rc5 work 
in the system?
Comment 10 Daniel Smolik 2005-10-26 11:07:13 UTC
I will test it in Sunday and give you a result.
Dan
Comment 11 Daniel Smolik 2005-10-29 12:22:25 UTC
I test it with 2.6.14  and still the same. First sleep works, second OOPS.
Kernel still says LSR safety check engla...
Comment 12 Shaohua 2005-10-30 16:59:05 UTC
I'll change the catogary to serial driver. Hopes the serial driver maintainer 
gives an hint.
Comment 13 Russell King 2005-10-31 01:40:44 UTC
Created attachment 6426 [details]
patch to fix suspend oops

This oops is occuring because we didn't reinitialise the port properly on the
previous resume.  It seems that the port is no longer present after the first
resume.

Please check whether this test patch resolves the oops.  Since the "safety
check" message will persist, please followup with the full kernel messages.

Thanks.
Comment 14 Russell King 2005-11-07 14:07:45 UTC
Any news?
Comment 15 Daniel Smolik 2005-11-08 11:25:54 UTC
Sorry I miss your previous email. A test this patch early and send a result.
Comment 16 Daniel Smolik 2005-11-12 13:47:01 UTC
Thanks, with 2.6.14 and this patch, all works without problems.
Comment 17 Russell King 2005-11-13 07:24:46 UTC
Thanks, patch committed as git id ee31b337852ca8a65840702544ff5c64d37740f5.
Comment 18 Russell King 2005-11-13 07:27:57 UTC
Since this bug is only half fixed, I won't close it yet.  However, you haven't
provided the information required to progress this bug further:

> Since the "safety
> check" message will persist, please followup with the full kernel messages.

Thanks.
Comment 19 Daniel Smolik 2005-11-13 08:52:25 UTC
Ok, I can send you kernel output. Which kind of messages are you interested in ?
Want you dmesg output or I must compile ACPI with some debuging ?


Dan
Comment 20 Russell King 2005-11-13 09:07:58 UTC
Please boot, run irattach, then suspend and resume.  Then run log the output
of the "dmesg" program and attach it to this bug.  Thanks.
Comment 21 Daniel Smolik 2005-11-19 14:11:48 UTC
Created attachment 6618 [details]
dmesg of suspend and resume
Comment 22 Russell King 2005-11-19 14:43:17 UTC
Created attachment 6619 [details]
patch for better identification of ports

Unfortunately:

Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

doesn't tell me what I need to know.  Can you apply this patch please?

Alternatively, can you provide the output from:

grep . /sys/bus/pnp/drivers/serial/*/resources

please?
Comment 23 Daniel Smolik 2005-11-19 15:07:49 UTC
Of course, threre it is.
cd /
grep . /sys/bus/pnp/drivers/serial/*/resources

state = active
io 0x3f8-0x3ff
irq 4

Dan
I patch kernel and start compile early.
Comment 24 Russell King 2005-11-20 13:05:51 UTC
Ok, so ttyS1 seems to only exist as an entry in the legacy list of devices.
It does not appear in the PNP system.

The fact that the port vanishes over a suspend/resume cycle is rather worrying.
I'm afraid that I don't have sufficient PC knowledge to work out why that's
happening.  Someone with more PC knowledge needs to be involved in this bug.
Comment 25 Daniel Smolik 2005-11-20 13:07:35 UTC
I need 2.6.15 (MPPE) and I apply patch(1) and latest patch(2). 
Patch(2) already included. But after kernel detects serial ports OOPS.
Comment 26 Russell King 2005-11-20 13:10:54 UTC
Could you attach the oops (if not already doing so) please?
Comment 27 Russell King 2005-11-20 13:15:04 UTC
BTW, both of these patches are already in 2.6.15-rc2.
Comment 28 Daniel Smolik 2005-11-20 13:26:49 UTC
thanks I test rc2
Comment 29 Daniel Smolik 2005-11-20 13:28:41 UTC
Created attachment 6627 [details]
OOPS captured via serial console

This is OOPS which you want
Comment 30 Russell King 2005-11-20 13:32:33 UTC
This oops seems to be unrelated to serial; please report it as a separate problem.
Remaining comments on the serial problem as per comment #24
Comment 31 Daniel Smolik 2005-11-20 13:39:23 UTC
Ok, I now compile rc2 and after I test it send a report.
Comment 32 Daniel Smolik 2005-11-20 14:17:52 UTC
Created attachment 6628 [details]
dmesg output
Comment 33 Daniel Smolik 2005-11-20 14:18:43 UTC
With 2.6.15-rc2 all works. I attach new dmesg output
Comment 34 Russell King 2005-11-20 14:20:18 UTC
Oh, great.  Not sure what changed (maybe something in ACPI?)...

Thanks for testing.
Comment 35 Daniel Smolik 2005-11-21 14:26:11 UTC
I don't know but message LSR safety .. still exists. Is it OK ?
Dan

Note You need to log in before you can comment on or make changes to this bug.