Bug 4390 - fujitsu-siemens c-1020 - video issue
Summary: fujitsu-siemens c-1020 - video issue
Status: REJECTED DUPLICATE of bug 2439
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Shaohua
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-23 01:09 UTC by richlv
Modified: 2005-12-22 21:04 UTC (History)
1 user (show)

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


Attachments
2.6.13-rc6 compiling output (5.69 KB, text/plain)
2005-08-18 01:05 UTC, richlv
Details
lspci output (1.15 KB, text/plain)
2005-09-05 01:21 UTC, richlv
Details

Description richlv 2005-03-23 01:09:18 UTC
it's fujitsu siemens c-1020 laptop, running slackware-current
bios version - 1.35

1. echo "standby" > /sys/power/state

screen blanks, but nothing else happens.
syslog contains only :
Mar 23 10:49:59 is kernel: Stopping tasks: ========================|
Mar 23 10:49:59 is kernel: Restarting tasks... done

/var/log/acpid :

[Wed Mar 23 08:39:58 2005] received event "video VGA0 00000080 00000000"
[Wed Mar 23 08:39:58 2005] executing action "/etc/acpi/acpi_handler.sh video 
VGA0 00000080 00000000"
[Wed Mar 23 08:39:58 2005] BEGIN HANDLER MESSAGES
[Wed Mar 23 08:39:58 2005] END HANDLER MESSAGES
[Wed Mar 23 08:39:58 2005] action exited with status 0
[Wed Mar 23 08:39:58 2005] completed event "video VGA0 00000080 00000000"


2. echo "standby" > /sys/power/state

system goes to standby ok, but resuming fails. if i do this from console, it 
contains grey dots. if i do this from x, sometimes session is restored ok, i can 
move my mouse (but nothing i click on opens), sometimes it's the same garbled 
screen. if i do this from console, i can switch virtual consoles (if i do this, 
grey dots disappear) and also ctrl+l removes those dots.
after resuming hdd activity light is permanently on. after some time computer 
shuts down itself.

possibly related line in /var/log/debug :
Mar 23 10:53:30 is kernel: Back to C!

lines in syslog :

Mar 23 10:53:30 is kernel: Stopping tasks: =========================|
Mar 23 10:53:30 is kernel: hub 1-0:1.0: resubmit --> -108
Mar 23 10:53:30 is kernel: ACPI: PCI interrupt 0000:00:11.1[A]: no GSI - using 
IRQ 0
Mar 23 10:53:30 is kernel: uhci_hcd 0000:00:11.2: host system error, PCI 
problems?
Mar 23 10:53:30 is kernel: uhci_hcd 0000:00:11.2: host controller halted, very 
bad!
Mar 23 10:53:30 is kernel: Restarting tasks...<6>usb 1-1: USB disconnect, 
address 2
Mar 23 10:53:30 is kernel:  done
Mar 23 10:53:50 is kernel: hda: dma_timer_expiry: dma status == 0x21
Mar 23 10:54:00 is kernel: hda: DMA timeout error
Mar 23 10:54:00 is kernel: hda: dma timeout error: status=0x58 { DriveReady 
SeekComplete DataRequest }
Mar 23 10:55:30 is kernel:
Mar 23 10:55:30 is kernel: ide: failed opcode was: unknown
Mar 23 10:55:30 is kernel: hda: dma_timer_expiry: dma status == 0x21
Mar 23 10:55:30 is kernel: hda: DMA timeout error
Mar 23 10:55:30 is kernel: hda: dma timeout error: status=0x58 { DriveReady 
SeekComplete DataRequest }
Mar 23 10:55:30 is kernel:
Mar 23 10:55:30 is kernel: ide: failed opcode was: unknown
Mar 23 10:55:30 is kernel: hda: dma_timer_expiry: dma status == 0x21
Mar 23 10:55:30 is kernel: hda: DMA timeout error
Mar 23 10:55:30 is kernel: hda: dma timeout error: status=0x58 { DriveReady 
SeekComplete DataRequest }
Mar 23 10:55:30 is kernel:
Mar 23 10:55:30 is kernel: ide: failed opcode was: unknown
Mar 23 10:55:30 is kernel: hda: dma_timer_expiry: dma status == 0x21
Mar 23 10:55:30 is kernel: hda: DMA timeout error
Mar 23 10:55:30 is kernel: hda: dma timeout error: status=0x58 { DriveReady 
SeekComplete DataRequest }
Mar 23 10:55:30 is kernel:
Mar 23 10:55:30 is kernel: ide: failed opcode was: unknown

i can provide also output from pmtools, dmidecode or other tools, if that would 
help.
Comment 1 richlv 2005-03-23 01:10:42 UTC
forgot to mention - i tried also removing all loaded modules - no difference
Comment 2 Andrew Morton 2005-03-23 01:57:07 UTC
I think this is the USB resume bug.  The USB guys are working on it.
Comment 3 Andrew Morton 2005-03-23 01:58:46 UTC
hmm, or mabye not.  I've asked the USB guys.
Comment 4 richlv 2005-03-23 02:02:13 UTC
in this case an usb mouse was attached to the computer, but symptoms are the 
same without any peripherals attached.
Comment 5 Andrew Morton 2005-05-25 17:10:00 UTC
Is this problem still present in 2.6.12-rc5?
Comment 6 richlv 2005-05-25 23:01:50 UTC
unfortunately i don't have this laptop right now - i'll try to get it and test 
as soon as possible
Comment 7 Shaohua 2005-06-05 20:25:22 UTC
Without USB, does the system work?
I suppose it's an IDE bug. IDE drivers didn't invoke some ACPI methods. IIRC, 
the IDE bug impact many systems.
Comment 8 richlv 2005-06-07 05:26:14 UTC
it still fails with 2.6.11.11;

i tried to patch it up to .12-rc6, but patch failed on a lot of files (detecting 
reversed or previously applied files) and the result did not compile at all.

this might be ide related, as hdd activity light is permanently on after 
attempted resume.

it seems that there is an usb problem, too (though it is not related to the hang 
when resuming) :
after resume attempt mouse works if touchpad is used, but usb mouse doesn't 
work. if it is replugged, it works (for a short while, until hardlock). this 
probably is usb resume problem that andrew mentioned, right ?
Comment 9 richlv 2005-06-20 01:44:29 UTC
still reproducible with 2.6.12 (both with and without usb peripherals)
Comment 10 Len Brown 2005-08-17 08:38:45 UTC
please verify that this is still an issue with 2.6.13
Comment 11 richlv 2005-08-17 08:51:28 UTC
umm, www.kernel.org lists only
2.6.13-rc6	2005-08-07 18:45
i could try patching, but as i was unsuccessful last time, i'm not sure i will 
succeed.

to which kernel am i supposed to apply this one :
http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.13-rc6.bz2 ?
Comment 12 Shaohua 2005-08-17 23:32:32 UTC
It applies to 2.6.12
Did you try sleep to mem ever (echo "mem" > /sys/power/state)?
Comment 13 richlv 2005-08-18 01:04:08 UTC
1. looking at my initial report i wonder wether i have written something wrong - 
maybe first point was issuein "mem" instead of "standby" - but i'm not sure 
anymore.

with 2.6.12, puttin "mem" in states results in same symptoms as standby - at 
resuming initial picture is painted, then screen goes blank with random grey 
circles appearing, then computer shuts down.

2. 2.6.13-rc6 patch applied without any errors, but compiling resulted in an 
error. i'll attach output. should i file this as a separate issue or is this a 
known problem ?
Comment 14 richlv 2005-08-18 01:05:07 UTC
Created attachment 5665 [details]
2.6.13-rc6 compiling output
Comment 15 richlv 2005-08-30 01:43:41 UTC
tested with 2.6.13, results are the same
Comment 16 Shaohua 2005-09-04 23:35:19 UTC
>Mar 23 10:55:30 is kernel: ide: failed opcode was: unknown
Did you still see the ide error with 2.6.13 after resume?
Comment 17 richlv 2005-09-05 01:19:37 UTC
seems that actually behaviour has changed significantly enough - so i'll put 
complete results again here.

--------------
echo "standby" /sys/power/state
--------------
/var/log/syslog

Sep  5 10:45:18 is kernel: Stopping tasks: 
==========================================|
Sep  5 10:45:18 is kernel: acpi_pm_prepare does not support 1
Sep  5 10:45:18 is kernel: Restarting tasks... done

-> basically nothing happens, screen simply refreshes once


--------------
echo "mem" /sys/power/state
--------------
/var/log/debug

Sep  5 10:47:03 is kernel: Back to C!
Sep  5 10:47:03 is kernel: PCI: Setting latency timer of device 0000:00:01.0 to 
64

/var/log/messages

Sep  5 10:47:03 is kernel: ACPI: PCI interrupt for device 0000:00:11.5 disabled
Sep  5 10:47:03 is kernel: ACPI: PCI interrupt for device 0000:00:11.4 disabled
Sep  5 10:47:03 is kernel: ACPI: PCI interrupt for device 0000:00:11.3 disabled
Sep  5 10:47:03 is kernel: ACPI: PCI interrupt for device 0000:00:11.2 disabled
Sep  5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKA] -> 
GSI 9 (level, low) -> IRQ 9
Sep  5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:0a.1[B] -> Link [LNKB] -> 
GSI 9 (level, low) -> IRQ 9
Sep  5 10:47:03 is kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
Sep  5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.2[D] -> Link [LNKD] -> 
GSI 10 (level, low) -> IRQ 10
Sep  5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.2[D] -> Link [LNKD] -> 
GSI 10 (level, low) -> IRQ 10
Sep  5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.3[D] -> Link [LNKD] -> 
GSI 10 (level, low) -> IRQ 10
Sep  5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.3[D] -> Link [LNKD] -> 
GSI 10 (level, low) -> IRQ 10
Sep  5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.4[D] -> Link [LNKD] -> 
GSI 10 (level, low) -> IRQ 10
Sep  5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.4[D] -> Link [LNKD] -> 
GSI 10 (level, low) -> IRQ 10
Sep  5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> 
GSI 10 (level, low) -> IRQ 10
Sep  5 10:47:03 is init: Switching to runlevel: 0
Sep  5 10:47:19 is exiting on signal 15

/var/log/syslog

Sep  5 10:47:03 is kernel: Stopping tasks: 
===========================================|
Sep  5 10:47:03 is kernel: ACPI: PCI Interrupt 0000:00:11.1[A]: no GSI
Sep  5 10:47:04 is kernel: Restarting tasks... done
Sep  5 10:47:11 is nmbd[1685]: [2005/09/05 10:47:11, 0] nmbd/nmbd.c:
terminate(56)
Sep  5 10:47:11 is nmbd[1685]:   Got SIGTERM: going down...
Sep  5 10:47:11 is rpc.statd[1664]: Caught signal 15, un-registering and 
exiting.
Sep  5 10:47:11 is rpc.mountd: Caught signal 15, un-registering and exiting.
Sep  5 10:47:12 is kernel: nfsd: last server has exited
Sep  5 10:47:12 is kernel: nfsd: unexporting all filesystems

--------------------
so, it seemed that the system was shutting down normally, just the screen was 
garbled.
then i modified /etc/acpi/acpi_handler.sh and commented out action for power 
button (runlevel 0) - probably it was receiving event from the power button when 
i tried to resume from sleep state ?

after this modification, computer did not shutdown (though there still bere 
those circles on the screen) and capslock & scrollock leds were flashing 
simultaneously. what seemed strange, there was no indication in any of the 
logfiles about anything related to this action.

i'll attach lspci output as there are a lot of pci references here, maybe that 
helps somehow.
Comment 18 richlv 2005-09-05 01:21:37 UTC
Created attachment 5898 [details]
lspci output
Comment 19 Shaohua 2005-09-05 02:17:48 UTC
>probably it was receiving event from the power button when 
>i tried to resume from sleep state ?
Yes, exactly. This is a good news.
Is there any device working after resume? Such as network card?
Comment 20 Shaohua 2005-09-05 02:21:43 UTC
>Sep  5 10:45:18 is kernel: acpi_pm_prepare does not support 1
This basically means your system doesn't support 'standby'.
Comment 21 richlv 2005-09-05 02:37:04 UTC
heh. it seems that it is working after resume, only screen shows nothing.

i can ssh into it, run commands. if i switch to another local virtual console 
and login, i can see that login has succeeded (in ssh session, of course as 
screen goes blank after console switching).

i can also switch back to original console which still contains circles.

to test this, i had gone into runlevel 3. after resuming i tried going to 
runlevel 4 (x)... it worked and display was resumed. virtual consoles still were 
blank. when i tried to log in kde, it stopped loading at the step "initializing 
system services".

ok. it did not stop. it just took a long time (couple of minutes in this step) 
and now i have a working desktop after resuming from "mem" state. virtual 
consoles still are blank, logfiles contain nothing new.

... mid air collision :)

but it is ok if /sys/power/state lists standby, mem and disk - it just lists 
available states, not the ones available to current hardware, right ?
if so, how can other softare that manages states (for example, klaptopdaemon) 
detect which states are available, so unavailable states are not shown in it's 
menu ?
Comment 22 Shaohua 2005-09-05 19:03:45 UTC
Great, looks you only have video issue.

>so unavailable states are not shown in it's menu ?
I'll look at it.
Comment 23 richlv 2005-10-14 01:28:10 UTC
so, this is a problem with vesa framebuffer driver.
after resuming console is unusable, xwin works ok.
Comment 24 Shaohua 2005-12-22 21:04:28 UTC
>so unavailable states are not shown in it's menu ?
This one has been fixed.

The video issue is duplicate.

*** This bug has been marked as a duplicate of 2439 ***

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