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.
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.
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
> Failed to acquire semaphore[cbfee4e0|1|0],AE_TIME still an issue with 2.6.l3-rc6?
> 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.
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
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.
Created attachment 5713 [details] oops on A21m after resume OOPS on A21m at ACPI
I reproduce oops and attach file with this. Dan
It's more likely a serial driver bug to me. Does latest kernel 2.6.14-rc5 work in the system?
I will test it in Sunday and give you a result. Dan
I test it with 2.6.14 and still the same. First sleep works, second OOPS. Kernel still says LSR safety check engla...
I'll change the catogary to serial driver. Hopes the serial driver maintainer gives an hint.
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.
Any news?
Sorry I miss your previous email. A test this patch early and send a result.
Thanks, with 2.6.14 and this patch, all works without problems.
Thanks, patch committed as git id ee31b337852ca8a65840702544ff5c64d37740f5.
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.
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
Please boot, run irattach, then suspend and resume. Then run log the output of the "dmesg" program and attach it to this bug. Thanks.
Created attachment 6618 [details] dmesg of suspend and resume
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?
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.
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.
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.
Could you attach the oops (if not already doing so) please?
BTW, both of these patches are already in 2.6.15-rc2.
thanks I test rc2
Created attachment 6627 [details] OOPS captured via serial console This is OOPS which you want
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
Ok, I now compile rc2 and after I test it send a report.
Created attachment 6628 [details] dmesg output
With 2.6.15-rc2 all works. I attach new dmesg output
Oh, great. Not sure what changed (maybe something in ACPI?)... Thanks for testing.
I don't know but message LSR safety .. still exists. Is it OK ? Dan