Bug#647858: loading kernel module viafb blacks out Sylvania G netbook
On Mon, Aug 12, 2013 at 05:39:28PM +0200, Moritz Muehlenhoff wrote: reassign 647858 src:linux thanks On Sun, Dec 04, 2011 at 05:49:57AM +, Tzafrir Cohen wrote: Hi, Thanks for the detailed reply. Trying to speed things up, in the mean while, On Sat, Dec 03, 2011 at 04:05:06PM -0600, Jonathan Nieder wrote: Tzafrir Cohen wrote: [...] ACPI: Actual Package length (8) is larger than NumElements field (5), truncated [3x] Doesn't look frightening, but please attach acpidump output for reference anyway. Attached. That reminds me: is X running when the hangs happen? It also happened without X running. It takes a while for it to hang (occasionally 10 hours or even more). So it will take a while for me even to check if something has worked. What's the status? Does this system work with Wheezy or later? Sadly I don't think I have that system around anymore. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130813100909.gz14...@lemon.cohens.org.il
Bug#647858: loading kernel module viafb blacks out Sylvania G netbook
reassign 647858 src:linux thanks On Sun, Dec 04, 2011 at 05:49:57AM +, Tzafrir Cohen wrote: Hi, Thanks for the detailed reply. Trying to speed things up, in the mean while, On Sat, Dec 03, 2011 at 04:05:06PM -0600, Jonathan Nieder wrote: Tzafrir Cohen wrote: [...] ACPI: Actual Package length (8) is larger than NumElements field (5), truncated [3x] Doesn't look frightening, but please attach acpidump output for reference anyway. Attached. That reminds me: is X running when the hangs happen? It also happened without X running. It takes a while for it to hang (occasionally 10 hours or even more). So it will take a while for me even to check if something has worked. What's the status? Does this system work with Wheezy or later? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130812153928.gc10...@inutil.org
Bug#647858: loading kernel module viafb blacks out Sylvania G netbook
On Fri, Dec 02, 2011 at 06:33:31PM -0600, Jonathan Nieder wrote: Tzafrir Cohen wrote: The system does not freeze on a 'modprobe viafb'. It merely blanks the screen. If I disable loading this module, I will basically load. The system will still hang at random a while later (several hours? more?). Odd. The viafb problem is probably worth investigating, but let's take care of the hangs first. Please attach full dmesg output from booting without the viafb module. Attached. There fas an fsck which has delayed the boot. sdb is a card readers, and is empty. Not sure what else to suggest. Does the nosmp (i.e., the -486) kernel behave differently? Did this system work well with lenny before? If so, could you try e.g. a lenny live cd to check if it still does? I built custom kernels with SMP disabled and CPU set to VIA C7 and they did not work any better. I'm not exactly sure what would upstream be. Here's what I tried: http://wiki.openchrome.org/pipermail/openchrome-users/2011-November/006799.html http://wiki.openchrome.org/pipermail/openchrome-users/2011-December/thread.html#6809 -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.1.0-1-686-pae (Debian 3.1.1-1) (b...@decadent.org.uk) (gcc version 4.6.2 (Debian 4.6.2-4) ) #1 SMP Mon Nov 14 08:24:20 UTC 2011 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009dc00 (usable) [0.00] BIOS-e820: 0009dc00 - 000a (reserved) [0.00] BIOS-e820: 000dc000 - 000e (reserved) [0.00] BIOS-e820: 000e8000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3bee (usable) [0.00] BIOS-e820: 3bee - 3beea000 (ACPI data) [0.00] BIOS-e820: 3beea000 - 3bf0 (ACPI NVS) [0.00] BIOS-e820: 3bf0 - 4000 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - fec1 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] NX (Execute Disable) protection: active [0.00] DMI present. [0.00] DMI: VIA/Phoenix CX700/VIA Demo Board, BIOS 6.00 06/13/2008 [0.00] e820 update range: - 0001 (usable) == (reserved) [0.00] e820 remove range: 000a - 0010 (usable) [0.00] last_pfn = 0x3bee0 max_arch_pfn = 0x100 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C7FFF write-protect [0.00] C8000-D uncachable [0.00] E-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask FC000 write-back [0.00] 1 base 03BF0 mask 0 uncachable [0.00] 2 base 03C00 mask FFC00 uncachable [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] found SMP MP-table at [c00f84b0] f84b0 [0.00] initial memory mapped : 0 - 01a0 [0.00] Base memory trampoline at [c0099000] 99000 size 16384 [0.00] init_memory_mapping: -379fe000 [0.00] 00 - 20 page 4k [0.00] 20 - 003780 page 2M [0.00] 003780 - 00379fe000 page 4k [0.00] kernel direct mapping tables up to 379fe000 @ 19fa000-1a0 [0.00] RAMDISK: 36c9 - 3764 [0.00] ACPI: RSDP 000f8470 00014 (v00 PTLTD ) [0.00] ACPI: RSDT 3bee56a8 00034 (v01 PTLTDRSDT 0604 LTP ) [0.00] ACPI: FACP 3bee9a46 00074 (v01 CX700 PTLTW0604 PTL_ 000F4240) [0.00] ACPI: DSDT 3bee56dc 0436A (v01 VIA PTL_ACPI 0604 MSFT 010E) [0.00] ACPI: FACS 3beeafc0 00040 [0.00] ACPI: SSDT 3bee9aba 004BA (v01 PPmmRe PPm 0604 INTL 20030224) [0.00] ACPI: APIC 3bee9f74 00050 (v01 PTLTD ? APIC 0604 LTP ) [0.00] ACPI: MCFG 3bee9fc4 0003C (v01 PTLTDMCFG 0604 LTP ) [0.00] ACPI: Local APIC address 0xfee0 [0.00] 68MB HIGHMEM available. [0.00] 889MB LOWMEM available. [0.00] mapped low ram: 0 - 379fe000 [0.00] low ram: 0 - 379fe000 [
Bug#647858: loading kernel module viafb blacks out Sylvania G netbook
Tzafrir Cohen wrote: Attached. There fas an fsck which has delayed the boot. sdb is a card readers, and is empty. Thanks. [...] I'm not exactly sure what would upstream be. That's exactly the right line of reasoning. It sounds like preventing viafb from loading does not avoid trouble, so the trick would be to find some driver or facility to disable that _does_ avoid trouble. Then we can punt to the person responsible for that subsystem. :) [...] ACPI: Actual Package length (8) is larger than NumElements field (5), truncated [3x] Doesn't look frightening, but please attach acpidump output for reference anyway. [...] PCI: Using host bridge windows from ACPI; if necessary, use pci=nocrs and report a bug I doubt this is the cause; still, it's worth a try, too. [...] pci :02:01.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' [...] ACPI _OSC control for PCIe not granted, disabling ASPM There's a recent patch in the PCI tree (but not in mainline yet) that might change this behavior and which I am rather fond of (7f92c4f7d92a, PCI: Rework ASPM disable code, 2011-11-10). Attaching it in case you want to try it. [...] usb 1-4: New USB device found, idVendor=0bda, idProduct=8187 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4: Product: RTL8187_Wireless I assume the same symptoms are present even when the wireless card is not attached. Worth checking if you haven't tried already. [...] viafb: Unknown parameter `bogusarg' Cute. That reminds me: is X running when the hangs happen? [...] sd 2:0:0:0: [sdb] Test WP failed, assume Write Enabled sd 2:0:0:0: [sdb] Asking for cache data failed sd 2:0:0:0: [sdb] Assuming drive cache: write through (many times) Can you blacklist the ums-realtek driver? Output from booting with the CONFIG_USB_STORAGE_DEBUG compile-time configuration option enabled (make nconfig → Device Drivers → USB support → USB Mass Storage support → USB Mass Storage verbose debug) would also be interesting. [...] I was not able to get anyt sort of error trace of message from the hung system, even when it was on the console. I assume this means the magic sysrq key wasn't working in that state. Alas. Thanks for the quick feedback. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111203220506.gb31...@elie.hsd1.il.comcast.net
Bug#647858: loading kernel module viafb blacks out Sylvania G netbook
Jonathan Nieder wrote:
There's a recent patch in the PCI tree (but not in mainline yet) that
might change this behavior and which I am rather fond of (7f92c4f7d92a,
PCI: Rework ASPM disable code, 2011-11-10). Attaching it in case
you want to try it.
Actually attaching this time.
commit 7f92c4f7d92a
Author: Matthew Garrett m...@redhat.com
Date: Thu Nov 10 16:38:33 2011 -0500
PCI: Rework ASPM disable code
Right now we forcibly clear ASPM state on all devices if the BIOS indicates
that the feature isn't supported. Based on the Microsoft presentation
PCI Express In Depth for Windows Vista and Beyond, I'm starting to think
that this may be an error. The implication is that unless the platform
grants full control via _OSC, Windows will not touch any PCIe features -
including ASPM. In that case clearing ASPM state would be an error unless
the platform has granted us that control.
This patch reworks the ASPM disabling code such that the actual clearing
of state is triggered by a successful handoff of PCIe control to the OS.
The general ASPM code undergoes some changes in order to ensure that the
ability to clear the bits isn't overridden by ASPM having already been
disabled. Further, this theoretically now allows for situations where
only a subset of PCIe roots hand over control, leaving the others in the
BIOS state.
It's difficult to know for sure that this is the right thing to do -
there's zero public documentation on the interaction between all of these
components. But enough vendors enable ASPM on platforms and then set this
bit that it seems likely that they're expecting the OS to leave them alone.
Measured to save around 5W on an idle Thinkpad X220.
Signed-off-by: Matthew Garrett m...@redhat.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 2672c798272f..7aff6312ce7c 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -596,6 +596,13 @@ static int __devinit acpi_pci_root_add(struct acpi_device
*device)
if (ACPI_SUCCESS(status)) {
dev_info(root-bus-bridge,
ACPI _OSC control (0x%02x) granted\n, flags);
+ if (acpi_gbl_FADT.boot_flags ACPI_FADT_NO_ASPM) {
+ /*
+* We have ASPM control, but the FADT indicates
+* that it's unsupported. Clear it.
+*/
+ pcie_clear_aspm(root-bus);
+ }
} else {
dev_info(root-bus-bridge,
ACPI _OSC request failed (%s),
diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index 4ecb6408b0d6..c8e75851a314 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -395,7 +395,6 @@ static int __init acpi_pci_init(void)
if (acpi_gbl_FADT.boot_flags ACPI_FADT_NO_ASPM) {
printk(KERN_INFOACPI FADT declares the system doesn't support
PCIe ASPM, so disable it\n);
- pcie_clear_aspm();
pcie_no_aspm();
}
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index cbfbab18be91..1cfbf228fbb1 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -68,7 +68,7 @@ struct pcie_link_state {
struct aspm_latency acceptable[8];
};
-static int aspm_disabled, aspm_force, aspm_clear_state;
+static int aspm_disabled, aspm_force;
static bool aspm_support_enabled = true;
static DEFINE_MUTEX(aspm_lock);
static LIST_HEAD(link_list);
@@ -500,9 +500,6 @@ static int pcie_aspm_sanity_check(struct pci_dev *pdev)
int pos;
u32 reg32;
- if (aspm_clear_state)
- return -EINVAL;
-
/*
* Some functions in a slot might not all be PCIe functions,
* very strange. Disable ASPM for the whole slot
@@ -574,9 +571,6 @@ void pcie_aspm_init_link_state(struct pci_dev *pdev)
pdev-pcie_type != PCI_EXP_TYPE_DOWNSTREAM)
return;
- if (aspm_disabled !aspm_clear_state)
- return;
-
/* VIA has a strange chipset, root port is under a bridge */
if (pdev-pcie_type == PCI_EXP_TYPE_ROOT_PORT
pdev-bus-self)
@@ -608,7 +602,7 @@ void pcie_aspm_init_link_state(struct pci_dev *pdev)
* the BIOS's expectation, we'll do so once pci_enable_device() is
* called.
*/
- if (aspm_policy != POLICY_POWERSAVE || aspm_clear_state) {
+ if (aspm_policy != POLICY_POWERSAVE) {
pcie_config_aspm_path(link);
pcie_set_clkpm(link, policy_to_clkpm_state(link));
}
@@ -649,8 +643,7 @@ void pcie_aspm_exit_link_state(struct pci_dev *pdev)
struct pci_dev *parent = pdev-bus-self;
Bug#647858: loading kernel module viafb blacks out Sylvania G netbook
# Tzafrir Cohen wrote: # # I also tried a self-compiled 3.2.0-rc2 with the same results. tags 647858 = upstream quit Tzafrir Cohen wrote: The system does not freeze on a 'modprobe viafb'. It merely blanks the screen. If I disable loading this module, I will basically load. The system will still hang at random a while later (several hours? more?). Odd. The viafb problem is probably worth investigating, but let's take care of the hangs first. Please attach full dmesg output from booting without the viafb module. Not sure what else to suggest. Does the nosmp (i.e., the -486) kernel behave differently? Did this system work well with lenny before? If so, could you try e.g. a lenny live cd to check if it still does? Thanks for writing, and hope that helps. Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111203003331.ga8...@elie.hsd1.il.comcast.net
