Bug#600846: Suspend-To-RAM not works for some months, Suspend-To-Disk not works since last update
On 26.11.2011 14:30, Jonathan Nieder wrote: hu...@online.de wrote: Loading all other modules except radeon works fine, loading radeon causes a system hangup on suspend to disk. Loading the radeon module also gives the following error messages: [ 270.715016] radeon_cp: Failed to load firmware radeon/R300_cp.bin [ 270.715045] [drm: r100_cp.init] *ERROR* Failed to load firmware! [ 270.715061] radeon :01:05:0: failed initializing CP (-2) . [ 270.715072] radeon :01:05:0:Disabling GPU acceleration Running out of time now, think I'll search the web for this error on monday. Please let me know how to continue. It expects to find firmware under /lib/firmware/radeon/. A mount -o bind /mnt/lib /lib should do the trick. There's very little left to do now. Please report this athttp://bugs.freedesktop.org, product DRI, component DRM/Radeon, and let us know the bug number so we can track it. Upstream will probably have some questions involving booting with drm.debug=0x6 no_console_suspend on the kernel command line and finding out what the machine says in its last gasp when it fails to hibernate. Or there may be patches to test. Thanks again for the quick feedback so far. 'night, Jonathan [1] http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree;f=radeon Reported the bug to freedesktop now, bug id is 43278 . Thank you very much for your help and best regards Rolf https://bugs.freedesktop.org/show_bug.cgi?id=43278 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600846: Suspend-To-RAM not works for some months, Suspend-To-Disk not works since last update
On 25.11.2011 21:49, Jonathan Nieder wrote: hu...@online.de wrote: When entering swapon -a the message swapon: /etc/fstab : No such file or directory was shown, so I used swapon /dev/sda5 instead. Thanks. Unfortunately I was not able to identify the culprit , after loading all modules step by step the hibernation check stilled worked fine. The only error message that came up was on loading module snd : FATAL: error running install command for snd with return code 1 . Hmm. Can you reproduce the trouble with break=mountroot instead of break=modules? Hi, yesterday I missed to check the return code of modprobe, so I didn't notice that nearly all of the modules were not (!) loaded because they are located on the hard disk and the disk was not mounted. Today I tried the break=modules again with mounting the disk (mkdir mnt ; mount -t ext4 /dev/sda8 /mnt) and loading the modules with modprobe -d /mnt module. This way the module causing the problem could be definitely identified as the radeon module. Loading all other modules except radeon works fine, loading radeon causes a system hangup on suspend to disk. Loading the radeon module also gives the following error messages: [ 270.715016] radeon_cp: Failed to load firmware radeon/R300_cp.bin [ 270.715045] [drm: r100_cp.init] *ERROR* Failed to load firmware! [ 270.715061] radeon :01:05:0: failed initializing CP (-2) . [ 270.715072] radeon :01:05:0:Disabling GPU acceleration Running out of time now, think I'll search the web for this error on monday. Please let me know how to continue. Thank you and have a nice weekend Rolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600846: Suspend-To-RAM not works for some months, Suspend-To-Disk not works since last update
On 24.11.2011 21:02, Jonathan Nieder wrote: hu...@online.de wrote: So the problem module should be one of the remaining 60 modules attached as lsmod21.txt . But now I do not know how to unload them cause I always get the message module is in use - even when system is started in recovery mode. Especially the radeon module which might be a good candidate cannot be unloaded. Could you please give me some instructions how to do this? The radeon module seems like a good place to start. I would suggest trying hibernation from the minimal recovery shell provided by the initramfs, as described in the initramfs-tools(8) manpage. It works roughly like this: 1. Pass break=modules on the kernel command line. 2. From the initramfs shell, load enough modules to have a usable swap partition (that means modprobe sata_sil and modprobe sd_mod, at least. Enable swap with swapon -a. 3. Load whatever set of modules you want to try (i.e., none, for the first try). 4. Hibernate (twice, I guess?). Let me know if you have any questions. What I would like to mention again (as earlier in bugzilla) is the strange behaviour that the first suspend to ram always works perfectly fine and the second one always causes a system hangup Yes, that is weird but definitely believable. Does suspend to disk behave the same way? Thanks, these test results are great. Looking forward to learning the culprit. Regards, Jonathan Hi, followed your suggestions now. When entering swapon -a the message swapon: /etc/fstab : No such file or directory was shown, so I used swapon /dev/sda5 instead. Unfortunately I was not able to identify the culprit , after loading all modules step by step the hibernation check stilled worked fine. The only error message that came up was on loading module snd : FATAL: error running install command for snd with return code 1 . Regards Rolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600846: Kernel failure in new 2.6.32.28 kernel
Hi, after a system upgrade to the current state of Debian Testing - which included an upgrade of the linux-image-2.6.32-5-amd64 package to the version 2.6.32.28 - a kernel failure occured. The failure message has been sent to kerneloops.com and is also shown below. Don't know if this has to do with the suspend to ram problem. At least the suspend to ram problem still exists in this kernel version as I tried and was able to reproduce it. If I should add this info to bugzilla.kernel.org - please let me know. Regards Kernel failure message 1: ] EDAC amd64: WARNING: ECC is NOT currently enabled by the BIOS. Module will NOT be loaded. Either Enable ECC in the BIOS, or use the 'ecc_enable_override' parameter. Might be a BIOS bug, if BIOS says ECC is enabled Use of the override can cause unknown side effects. amd64_edac: probe of :00:18.2 failed with error -22 tifm_7xx1 :02:04.2: PCI INT A - GSI 20 (level, low) - IRQ 20 cfg80211: Using static regulatory domain info cfg80211: Regulatory domain: US (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) (2402000 KHz - 2472000 KHz @ 4 KHz), (600 mBi, 2700 mBm) (517 KHz - 519 KHz @ 4 KHz), (600 mBi, 2300 mBm) (519 KHz - 521 KHz @ 4 KHz), (600 mBi, 2300 mBm) (521 KHz - 523 KHz @ 4 KHz), (600 mBi, 2300 mBm) (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm) (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm) cfg80211: Calling CRDA for country: US b43-phy0: Broadcom 4311 WLAN found (core revision 10) HDA Intel :00:14.2: PCI INT A - GSI 16 (level, low) - IRQ 16 phy0: Selected rate control algorithm 'minstrel' Broadcom 43xx driver loaded [ Features: PML, Firmware-ID: FW13 ] input: HDA Digital PCBeep as /devices/pci:00/:00:14.2/input/input11 Adding 3148700k swap on /dev/sda5. Priority:-1 extents:1 across:3148700k EXT4-fs (sda7): internal journal on sda7:8 loop: module loaded kjournald starting. Commit interval 5 seconds EXT3 FS on sda6, internal journal EXT3-fs: mounted filesystem with ordered data mode. tg3 :02:01.0: firmware: requesting tigon/tg3_tso5.bin tg3 :02:01.0: PME# disabled ADDRCONF(NETDEV_UP): eth0: link is not ready fuse init (API version 7.12) tg3: eth0: Link is up at 100 Mbps, full duplex. tg3: eth0: Flow control is on for TX and on for RX. ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready input: ACPI Virtual Keyboard Device as /devices/virtual/input/input12 Bluetooth: Core ver 2.15 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP ver 2.13 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM ver 1.11 Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Bluetooth: BNEP filters: protocol multicast Bridge firewalling registered Bluetooth: SCO (Voice Link) ver 0.6 Bluetooth: SCO socket layer initialized lp0: using parport0 (interrupt-driven). ppdev: user-space parallel port driver alloc irq_desc for 17 on node 0 alloc kstat_irqs on node 0 pci :01:05.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [drm] Initialized drm 1.1.0 20060810 radeon: Unknown parameter `modeset' powernow-k8: Found 1 AMD Turion(tm) 64 X2 Mobile Technology TL-52 processors (2 cpu cores) (version 2.20.00) powernow-k8:0 : fid 0x8 (1600 MHz), vid 0x13 powernow-k8:1 : fid 0x0 (800 MHz), vid 0x1e Clocksource tsc unstable (delta = -122312474 ns) eth0: no IPv6 routers present -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600846: The problem not exists in 2.6.31-1 and first comes up in 2.6.32-1
The problem not exists in the one and only 2.6.31 kernel linux-image-2.6.31-1-amd64_2.6.31-1_amd64.deb and comes up in the first 2.6.32 kernel linux-image-2.6.32-1-amd64_2.6.32-6_amd64.deb . I have also filed a bug report to bugzilla.kernel.org, bug id is 22022 . Thanks and regards Rolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600846: The problem also exists with linux-image-2.6.36-rc6-amd64 and xserver.xorg 7.5+8
The problem also exists with linux-image-2.6.36-rc6-amd64 and xserver.xorg 7.5+8 . -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600846: Problem also with linux-image-2.6.36-trunk-amd64, but another interesting detection
As expected, the problem also exists with linux-image-2.6.36-trunk-amd64 . But before putting something into bugzilla I'd like to tell you about another interesting detection I made now during testing: For 6 times in follow the system showed the following absolute constant behavior: After booting, the first Suspend-To-RAM allways worked very fine and the second Suspend-To-RAM allways constantly hung. And after the first Suspend-To-RAM there existed some additional processes in the process list that did not exist after booting: root 3105 2 0 11:40 ?00:00:00 [migration/1] root 3106 2 0 11:40 ?00:00:00 [ksoftirqd/1] root 3107 2 0 11:40 ?00:00:00 [watchdog/1] root 3108 2 0 11:40 ?00:00:00 [kconservative/1] root 3109 2 0 11:40 ?00:00:00 [radeon/1] root 3110 2 0 11:40 ?00:00:00 [ext4-dio-unwrit] root 3111 2 0 11:40 ?00:00:00 [ata/1] root 3112 2 0 11:40 ?00:00:00 [crypto/1] root 3113 2 0 11:40 ?00:00:00 [aio/1] root 3114 2 0 11:40 ?00:00:00 [kondemand/1] root 3115 2 0 11:40 ?00:00:00 [kblockd/1] root 3116 2 0 11:40 ?00:00:00 [kintegrityd/1] root 3117 2 0 11:40 ?00:00:00 [events/1] root 3119 500 0 11:40 ?00:00:00 udevd --daemon root 3120 500 0 11:40 ?00:00:00 udevd --daemon For me it now looks like one (or some) of them might cause the problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600846: Different additional processes sometimes
Sometimes there existed different additional processes like these after the first Suspend-To-RAM, but the result was the same: hanging second Suspend-To-RAM root 2932 2 0 11:33 ?00:00:00 [kworker/u:1] root 2933 2 0 11:33 ?00:00:00 [kworker/u:2] root 2934 2 0 11:33 ?00:00:00 [kworker/u:4] root 2935 2 0 11:33 ?00:00:00 [kworker/u:5] root 2936 2 0 11:33 ?00:00:00 [kworker/u:6] root 2937 2 0 11:33 ?00:00:00 [kworker/u:7] root 2938 2 0 11:33 ?00:00:00 [kworker/u:8] root 2939 2 0 11:33 ?00:00:00 [kworker/u:9] root 2940 2 0 11:33 ?00:00:00 [kworker/u:10] root 2941 2 0 11:33 ?00:00:00 [kworker/u:11] root 2942 2 0 11:33 ?00:00:00 [kworker/u:12] root 2943 2 0 11:33 ?00:00:00 [kworker/u:13] root 2946 2 0 11:33 ?00:00:00 [migration/1] root 2947 2 0 11:33 ?00:00:00 [kworker/1:3] root 2948 2 0 11:33 ?00:00:00 [ksoftirqd/1] root 2949 2 0 11:33 ?00:00:00 [watchdog/1] root 2950 2 0 11:33 ?00:00:00 [kworker/u:14] root 2951 2 0 11:33 ?00:00:00 [kworker/u:15] root 2952 2 0 11:33 ?00:00:00 [kworker/u:16] root 2953 2 0 11:33 ?00:00:00 [kworker/u:17] root 2954 2 0 11:33 ?00:00:00 [kworker/u:18] root 2955 2 0 11:33 ?00:00:00 [kworker/u:19] root 2956 2 0 11:33 ?00:00:00 [kworker/u:20] root 2957 2 0 11:33 ?00:00:00 [kworker/u:21] root 2958 2 0 11:33 ?00:00:00 [kworker/u:22] root 2959 2 0 11:33 ?00:00:00 [kworker/u:23] root 2960 2 0 11:33 ?00:00:00 [kworker/1:0] root 2961 2 0 11:33 ?00:00:00 [kworker/0:2] root 2962 2 0 11:33 ?00:00:00 [kworker/1:1] root 2963 2 0 11:33 ?00:00:00 [kworker/1:2] root 2965 495 0 11:33 ?00:00:00 udevd --daemon root 2966 495 0 11:33 ?00:00:00 udevd --daemon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600846: Definitely: The problem started with kernel 2.6.32
I downloaded three versions of the 2.6.30 kernel from snapshot.debian.org and installed them on my notebook - without doing any other changes to the system. And the Suspend-To-RAM of all of the three 2.6.30 kernels worked perfectly well ! So from my point of view the problem started definitely with the 2.6.32 kernel version. The 2.6.30 kernel packages were: linux-image-2.6.30-1-amd64_2.6.30-1_amd64.deb linux-image-2.6.30-2-amd64_2.6.30-7_amd64.deb linux-image-2.6.30-2-amd64_2.6.30-8squeeze1_amd64.deb (the latest I found) With the 2.6.30 kernel there is the same effect of additional processes coming up after the first Suspend-To-RAM . These are: root 3092 2 0 20:22 ?00:00:00 [migration/1] root 3093 2 0 20:22 ?00:00:00 [ksoftirqd/1] root 3094 2 0 20:22 ?00:00:00 [watchdog/1] root 3095 2 0 20:22 ?00:00:00 [kconservative/1] root 3096 2 0 20:22 ?00:00:00 [ata/1] root 3097 2 0 20:22 ?00:00:00 [crypto/1] root 3098 2 0 20:22 ?00:00:00 [aio/1] root 3099 2 0 20:22 ?00:00:00 [kondemand/1] root 3100 2 0 20:22 ?00:00:00 [kblockd/1] root 3101 2 0 20:22 ?00:00:00 [kintegrityd/1] root 3102 2 0 20:22 ?00:00:00 [events/1] root 3103 718 0 20:22 ?00:00:00 udevd --daemon root 3104 718 0 20:22 ?00:00:00 udevd --daemon As can be seen the 2 processes root 3109 2 0 11:40 ?00:00:00 [radeon/1] root 3110 2 0 11:40 ?00:00:00 [ext4-dio-unwrit] coming up in kernel 2.6.32 are missing. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600846: The problem also exists in 2.6.32-27 version of linux-image-2.6.32-5-amd64 package.
The problem also exists in 2.6.32-27 version of linux-image-2.6.32-5-amd64 package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600846: Strange background behind login window.
I remember another item: At the time when the Suspend-To-RAM worked fine the login window always occurred in front of an empty clean black background. But now the background behind the login window has a strange colored look and seems to be a shattered and unrecognizable picture - maybe taken from an Xserver screen saver or a KDE desktop style or something like that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600846: In Kubuntu 10.10 with kernel version 2.6.35 bug also exists.
What I forgot to mention: I tried the new Kubuntu 10.10 with kernel 2.6.35 and the bug there also exists. Immediately after the installation without any configuration I tried the Suspend-To-RAM 5 times and it seemed to work fine. After doing some configurations (e.g. mounting two additional drives) the Suspend-To-RAM stopped working again. The only notable change to the system that I remember was changing the Java system default to the Sun JRE. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600846: In Kubuntu 10.10 installation also the linux kernel was updated.
What I also forgot and remember now: After installing and configuring Kubuntu 10.10, later on I did also a small system update where roundabout 20 packages were replaced by newer versions - and one of them was the linux kernel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
