Bug#812746: linux-image-4.3.0-0.bpo.1-amd64: r8169 suspend to ram regression: rtl_counters_cond == 1
Package: src:linux Version: 4.3.3-7~bpo8+1 Severity: normal Dear Maintainer, after suspend to ram there are lots of error messages from the r8169 module and there are some strange side-effects (multiload_applet produces 100% cpu load trying to read network interface statistics ...) as workaround one can ifdown eth0 ; ifup eth0 This did not happen with debian kernels 3.16 and 4.2 -- Package-specific info: ** Version: Linux version 4.3.0-0.bpo.1-amd64 (debian-kernel@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.3.3-7~bpo8+1 (2016-01-19) ** Command line: BOOT_IMAGE=/vmlinuz-4.3.0-0.bpo.1-amd64 root=/dev/mapper/vgcrypt-root ro quiet ** Not tainted ** Kernel log: [87191.684889] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87191.711031] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87191.737560] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87191.764204] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87191.790541] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87191.817158] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87191.844254] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87191.871205] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87191.898666] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87192.607134] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87192.633512] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87192.659716] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87192.685914] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87192.712076] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87192.738680] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87192.765161] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87192.791691] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87192.818177] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87192.844925] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87192.871450] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87192.898064] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87193.056904] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87193.654671] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87193.731372] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87193.809806] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87193.890007] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87193.960441] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87193.998441] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.026292] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.052599] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.079552] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.107711] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.134736] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.161505] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.607960] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.63] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.660696] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.686992] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.713216] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.739487] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.766093] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.792401] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.818772] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.845632] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.873207] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87194.899828] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87195.609418] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87195.636005] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [87195.662384] r8169
Bug#812746: linux-image-4.3.0-0.bpo.1-amd64: r8169 misbehaves if shut down
looks like this is in fact somehow related to laptop-mode-tools / r8169 misbehaves if shut down. In the end it is enough to shut down the interface via: ip link set dev eth0 down to produce the errors messages: [90830.764253] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [90830.840253] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [90830.915939] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [90830.991631] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [90831.068731] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [90831.135730] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [90831.211712] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [90831.286904] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [90831.459953] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [90831.535702] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [90831.611131] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). ... but in this case the errors stop if one brings up the interface again via: ip link set dev eth0 up Jan 26 11:02:00 amalthea kernel: [90937.282145] r8169 :02:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). Jan 26 11:02:00 amalthea avahi-daemon[2719]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.5.2. Jan 26 11:02:00 amalthea kernel: [90937.349408] r8169 :02:00.0 eth0: link down Jan 26 11:02:00 amalthea kernel: [90937.350428] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready Jan 26 11:02:00 amalthea avahi-daemon[2719]: New relevant interface eth0.IPv4 for mDNS. Jan 26 11:02:00 amalthea avahi-daemon[2719]: Registering new address record for 192.168.5.2 on eth0.IPv4. Jan 26 11:02:01 amalthea ntpd[2861]: Listen normally on 61 eth0 192.168.5.2 UDP 123 Jan 26 11:02:01 amalthea ntpd[2861]: peers refreshed don't know what exactly happens in the suspend case but maybe the interface is shut down and never brought back up again because no cable is connected
Bug#781576: linux: linux-image-3.16.0-4-armmp(-lpae): A20-OLinuXino-* power off doesn't work, please enable CONFIG_MFD_AXP20X and CONFIG_REGULATOR_AXP20X
Package: src:linux
Version: 3.16.7-ckt7-1
Severity: normal
Dear Maintainer,
On A20-OLinuXino-{MICRO,LIME,LIME2,...?} power off doesn't work.
after enabling
CONFIG_MFD_AXP20X=y
CONFIG_REGULATOR_AXP20X=y
in
debian/config/armhf/config.armmp
power off works for me on A20-OLinuXino-LIME2
s.a.
Message-ID: 87bnjeh7po@karme.de
on debian-...@lists.debian.org
note:
i am not sure wether CONFIG_REGULATOR_AXP20X=m would be good enough
and didn't test that!
For the test I used a dtb from 3.19 (didn't check wether some
backporting is needed for the dts files)
** Model information
Hardware: Allwinner sun7i (A20) Family
Revision:
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (900, 'testing')
Architecture: armhf (armv7l)
Kernel: Linux 3.16.0-4-armmp-lpae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87pp7p38aa@karme.de
Bug#775178: Suspend failing after update of kernel to 3.2.65-1 (amd64)
Jens Thiele ka...@karme.de writes: Don't have the time to test this now and will wait for the security update. (downgraded to 3.2.63-2+deb7u2 for now now) For the archive: After updating to 3.2.65-1+deb7u1 suspend works for me again. Thanks, jens -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k30o2vqw@karme.de
Bug#775178: Suspend failing after update of kernel to 3.2.65-1 (amd64)
Nathan Wallach taniwall...@gmail.com writes: Jens - I found your bug-report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775178 I also had a problem with resume from suspend failing after the update to kernel 3.2.65-1, and found a number of other similar bug-reports. Many pointed to the patched kernel Ben Hutchings prepared, see below. His patched kernel solved the problem on my laptop. Thanks! = very likely #775178 could be merged with #774461 Don't have the time to test this now and will wait for the security update. (downgraded to 3.2.63-2+deb7u2 for now now) Greetings, jens -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zj9nkt09@karme.de
Bug#775178: linux-image-3.2.0-4-amd64: linux-image-3.2.0-4-amd64: regression: suspend/resume not working after update (again)
Package: src:linux Version: 3.2.65-1 Severity: normal Dear Maintainer, suspend/resume not working after update from 3.2.63-2+deb7u2 to 3.2.65-1. maybe this is related to #746411? Maybe the same code got in again? Suspend itself seems to work. On a resume a reboot happens (this is different from #746411). Nothing in the logs. Greetings, jens -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.65-1 ** Not tainted ** Model information sys_vendor: LENOVO product_name: 2545A26 product_version: ThinkPad Edge chassis_vendor: LENOVO chassis_version: Not Available bios_vendor: LENOVO bios_version: 87ET44WW (1.18 ) board_vendor: LENOVO board_name: 2545A26 board_version: Not Available ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] RS880 Host Bridge [1022:9601] Subsystem: Lenovo Device [17aa:21ca] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Capabilities: access denied 00:01.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (int gfx) [1022:9602] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 9000-9fff Memory behind bridge: d040-d05f Prefetchable memory behind bridge: c000-cfff Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied 00:04.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 0) [1022:9604] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=02, subordinate=07, sec-latency=0 I/O behind bridge: a000-bfff Memory behind bridge: d070-d07f Prefetchable memory behind bridge: d000-d03f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:05.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 1) [1022:9605] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=08, subordinate=08, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: d060-d06f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (prog-if 01 [AHCI 1.0]) Subsystem: Lenovo Device [17aa:21ca] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 Interrupt: pin A routed to IRQ 43 Region 0: I/O ports at 8440 [size=8] Region 1: I/O ports at 8430 [size=4] Region 2: I/O ports at 8420 [size=8] Region 3: I/O ports at 8410 [size=4] Region 4: I/O ports at 8400 [size=16] Region 5: Memory at d0906800 (32-bit, non-prefetchable) [size=1K] Capabilities: access denied Kernel driver in use: ahci 00:12.0 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] (prog-if 10 [OHCI]) Subsystem: Lenovo Device [17aa:21ca] Control:
Bug#775178: linux-image-3.2.0-4-amd64: linux-image-3.2.0-4-amd64: regression: suspend/resume not working after update (again)
Jens Thiele ka...@karme.de writes: maybe this is related to #746411? Maybe the same code got in again? unfortunately not that simple. The patch for #746411 is still there: karme@amalthea:/tmp/linux-3.2.65$ find -iname *revert-perf-x86-amd-ibs-fix* ./debian/patches/bugfix/x86/revert-perf-x86-amd-ibs-fix-waking-up-from-s3-for-amd-family-10h.patch ./.pc/bugfix/x86/revert-perf-x86-amd-ibs-fix-waking-up-from-s3-for-amd-family-10h.patch karme@amalthea:/tmp/linux-3.2.65$ grep revert-perf-x86-amd-ibs-fix /tmp/linux-3.2.65/debian/patches/series bugfix/x86/revert-perf-x86-amd-ibs-fix-waking-up-from-s3-for-amd-family-10h.patch -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871tn0fijd@karme.de
Bug#746411: linux-image-3.2.0-4-amd64: regression: suspend/resume not working after update
Ben Hutchings b...@decadent.org.uk writes: Thanks a lot. This should be reverted in the next security update. (Yes, even though it is not a security issue.) looking forward for the update, thanks! greetings, jens PS: i could imagine the revert will break stuff for other machines and likely a fixed version of e07518e9ce84547ef7a81478dbd3fed1539726da will be needed? if i can be of help by testing a possible new version, feel free to contact me pgpTYpS8qUPeB.pgp Description: PGP signature
Bug#746411: linux-image-3.2.0-4-amd64: regression: suspend/resume not working after update
Jens Thiele ka...@karme.de writes: Ben Hutchings b...@decadent.org.uk writes: How is it 'not working'? didn't have time to inspect the details yet did some more tests - it doesn't matter wether i am on power or battery - I have a reproducible crash on every second resume (first resume works / second crashes without any output :( ) - tried to debug using netconsole, but unfortunately i don't get any netconsole output on the second resume - unfortunately i didn't find a linux-image-3.2.0-4-amd64_3.2.54-2.deb anymore, but using linux-image-3.2.0-4-amd64_3.2.46-1+deb7u1_amd64.deb from debian security suspend/resume works jens pgp5tYvZswoPT.pgp Description: PGP signature
Bug#746411: linux-image-3.2.0-4-amd64: regression: suspend/resume not working after update
if i revert the commit:
commit e07518e9ce84547ef7a81478dbd3fed1539726da
Author: Robert Richter r...@kernel.org
Date: Wed Jan 15 15:57:29 2014 +0100
perf/x86/amd/ibs: Fix waking up from S3 for AMD family 10h
suspend/resume works for me again
$ git branch -v
* linux-3.2.y f453538 Linux 3.2.58
$ git diff-tree -R -p e07518e9ce84547ef7a81478dbd3fed1539726da
(patch attached)
diff --git a/arch/x86/kernel/cpu/perf_event_amd_ibs.c b/arch/x86/kernel/cpu/perf_event_amd_ibs.c
index ea34253..3b8a2d3 100644
--- a/arch/x86/kernel/cpu/perf_event_amd_ibs.c
+++ b/arch/x86/kernel/cpu/perf_event_amd_ibs.c
@@ -9,7 +9,6 @@
#include linux/perf_event.h
#include linux/module.h
#include linux/pci.h
-#include linux/syscore_ops.h
#include asm/apic.h
@@ -210,18 +209,6 @@ out:
return ret;
}
-static void ibs_eilvt_setup(void)
-{
- /*
- * Force LVT offset assignment for family 10h: The offsets are
- * not assigned by the BIOS for this family, so the OS is
- * responsible for doing it. If the OS assignment fails, fall
- * back to BIOS settings and try to setup this.
- */
- if (boot_cpu_data.x86 == 0x10)
- force_ibs_eilvt_setup();
-}
-
static inline int get_ibs_lvt_offset(void)
{
u64 val;
@@ -257,36 +244,6 @@ static void clear_APIC_ibs(void *dummy)
setup_APIC_eilvt(offset, 0, APIC_EILVT_MSG_FIX, 1);
}
-#ifdef CONFIG_PM
-
-static int perf_ibs_suspend(void)
-{
- clear_APIC_ibs(NULL);
- return 0;
-}
-
-static void perf_ibs_resume(void)
-{
- ibs_eilvt_setup();
- setup_APIC_ibs(NULL);
-}
-
-static struct syscore_ops perf_ibs_syscore_ops = {
- .resume = perf_ibs_resume,
- .suspend = perf_ibs_suspend,
-};
-
-static void perf_ibs_pm_init(void)
-{
- register_syscore_ops(perf_ibs_syscore_ops);
-}
-
-#else
-
-static inline void perf_ibs_pm_init(void) { }
-
-#endif
-
static int __cpuinit
perf_ibs_cpu_notifier(struct notifier_block *self, unsigned long action, void *hcpu)
{
@@ -313,12 +270,18 @@ static __init int amd_ibs_init(void)
if (!caps)
return -ENODEV; /* ibs not supported by the cpu */
- ibs_eilvt_setup();
+ /*
+ * Force LVT offset assignment for family 10h: The offsets are
+ * not assigned by the BIOS for this family, so the OS is
+ * responsible for doing it. If the OS assignment fails, fall
+ * back to BIOS settings and try to setup this.
+ */
+ if (boot_cpu_data.x86 == 0x10)
+ force_ibs_eilvt_setup();
if (!ibs_eilvt_valid())
goto out;
- perf_ibs_pm_init();
get_online_cpus();
ibs_caps = caps;
/* make ibs_caps visible to other cpus: */
pgpW03HeRGKNp.pgp
Description: PGP signature
Bug#746411: linux-image-3.2.0-4-amd64: regression: suspend/resume not working after update
Ben Hutchings b...@decadent.org.uk writes: How is it 'not working'? didn't have time to inspect the details yet - Crash/hang when trying to suspend? suspend itself seems to work - Immediate resume after suspending? no - Unresponsive when trying to resume? - Crash/hang after resuming? looks like a complete crash on resume nothing in the logs have to power down to get the device working again jens pgpurW0rB98kr.pgp Description: PGP signature
Bug#746411: linux-image-3.2.0-4-amd64: regression: suspend/resume not working after update
can't reproduce at the moment :( maybe this bug report is invalid/can be closed -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ioprcj76@karme.de
Bug#746411: linux-image-3.2.0-4-amd64: regression: suspend/resume not working after update
Jens Thiele ka...@karme.de writes: can't reproduce at the moment :( maybe this bug report is invalid/can be closed now it happened again looks like it only happens on suspend to ram on battery device is a thinkpad edge 11 (amd version) ** Model information sys_vendor: LENOVO product_name: 2545A26 product_version: ThinkPad Edge chassis_vendor: LENOVO chassis_version: Not Available bios_vendor: LENOVO bios_version: 87ET44WW (1.18 ) board_vendor: LENOVO board_name: 2545A26 board_version: Not Available -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87eh0fnmgl@karme.de
Bug#746411: linux-image-3.2.0-4-amd64: regression: suspend/resume not working after update
Package: src:linux Version: 3.2.57-3 Severity: normal suspend/resume not working after update from 3.2.54-2 to 3.2.57-3 maybe this is caused by the change: - perf/x86/amd/ibs: Fix waking up from S3 for AMD family 10h introduced in 3.2.57-1 cpu family : 16 model : 6 model name : AMD Athlon(tm) II Neo K345 Dual-Core Processor -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87iopsc68r@karme.de
Bug#442103: initramfs-tools: update-initramfs fails with lilo and a degraded raid1 array
maximilian attems [EMAIL PROTECTED] writes: as debian supports partial upgrades and initramfs-tools is not gonna start depend on lilo this inocation can only be used after Lenny release. marking as wontfix. Let me see if I got you right: You want to mark it as wontfix because older versions of lilo do not provide -H = if one adds -H to the lilo invocations in update-initramfs there might be problems during update from etch? Maybe we could test the lilo version and add -H if version some version? But in the end this is not really a good solution because maybe not everyone wants to use -H. Hmm. I think the only sensible solution would be to provide an option in the lilo.conf Sorry for the noise. Greetings Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442103: initramfs-tools: update-initramfs fails with lilo and a degraded raid1 array
maximilian attems [EMAIL PROTECTED] writes: i fail to find the mentioned lilo -H mention in the lilo manpage. dpkg -l lilo | grep ^ii ii lilo 22.6.1-9.3 LInux LOader - The Classic OS loader can loa a lilo -H invocation leads into usage() message. what are you guys using? $ LC_ALL=C dpkg -l lilo; man lilo|grep -n -- -H Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++--- ii lilo 1:22.8-3.1 LInux LOader - The Classic OS loader can load Linux and others 108: -H Override fatal halt when a RAID array does not have all disks Greetings Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442103: initramfs-tools: update-initramfs fails with lilo and a degraded raid1 array
On 17 Sep 2007, [EMAIL PROTECTED] wrote: hey guys sorry if you still use lilo, you need to do manual intervence, i see no other way. unless a real strong argument comes up, i'll close that bug in a month. AFAIK grub does not support LVM on top of md raid1 whereas lilo does? The installer allows to setup LVM on top of raid and as far as I remember then suggests usage of lilo. Just as explanation / usage scenario: I use lvm on top of raid1 on a laptop and run the raid in degraded state most of the time. From time to time I attach an external usb disk and resync it. (incremental resync that is) IMHO lilo should provide an option in lilo.conf corresponding -H. See also bug: #278373 Greetings Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
