[PATCH] x86/PCI: use host bridge _CRS info on ASUS M2V-MX SE

From: Paul Menzel
Date: Thu Sep 01 2011 - 14:38:24 EST

Date: Wed, 31 Aug 2011 17:07:10 +0200

Following commit 3e3da00c

commit 3e3da00c01d050307e753fb7b3e84aefc16da0d0
Author: Yinghai Lu <yinghai@xxxxxxxxxx>
Date: Wed Feb 10 01:20:09 2010 -0800

x86/pci: AMD one chain system to use pci read out res

Linux gives the following oops.

[â]
[ 41.265636] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
[ 41.680357] HDA Intel 0000:20:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 41.680444] HDA Intel 0000:20:01.0: setting latency timer to 64
[ 41.680462] BUG: unable to handle kernel paging request at ffffc90011c08000
[ 41.680617] IP: [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
[ 41.680728] PGD 13781a067 PUD 13781b067 PMD 1300ba067 PTE 800000fd00000173
[ 41.680956] Oops: 0009 [#1] SMP
[ 41.681098] last sysfs file: /sys/module/snd_pcm/initstate
[ 41.681159] CPU 0
[ 41.681203] Modules linked in: snd_hda_intel(+) snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event tpm_tis tpm snd_seq tpm_bios psmouse parport_pc snd_timer snd_seq_device parport processor evdev snd i2c_viapro thermal_sys amd64_edac_mod k8temp i2c_core soundcore shpchp pcspkr serio_raw asus_atk0110 pci_hotplug edac_core button snd_page_alloc edac_mce_amd ext3 jbd mbcache sha256_generic cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod raid1 md_mod usbhid hid sg sd_mod crc_t10dif sr_mod cdrom ata_generic uhci_hcd sata_via pata_via libata ehci_hcd usbcore scsi_mod via_rhine mii nls_base [last unloaded: scsi_wait_scan]
[ 41.684180]
[ 41.684180] Pid: 1153, comm: work_for_cpu Not tainted 2.6.37-1-amd64 #1 M2V-MX SE/System Product Name
[ 41.684180] RIP: 0010:[<ffffffffa0578402>] [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
[ 41.684180] RSP: 0018:ffff88013153fe50 EFLAGS: 00010286
[ 41.684180] RAX: ffffc90011c08000 RBX: ffff88013029ec00 RCX: 0000000000000006
[ 41.684180] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
[ 41.684180] RBP: ffff88013341d000 R08: 0000000000000000 R09: 0000000000000040
[ 41.684180] R10: 0000000000000286 R11: 0000000000003731 R12: ffff88013029c400
[ 41.684180] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88013341d090
[ 41.684180] FS: 0000000000000000(0000) GS:ffff8800bfc00000(0000) knlGS:00000000f7610ab0
[ 41.684180] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 41.684180] CR2: ffffc90011c08000 CR3: 0000000132f57000 CR4: 00000000000006f0
[ 41.684180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 41.684180] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 41.684180] Process work_for_cpu (pid: 1153, threadinfo ffff88013153e000, task ffff8801303c86c0)
[ 41.684180] Stack:
[ 41.684180] 0000000000000005 ffffffff8123ad65 00000000000136c0 ffff88013029c400
[ 41.684180] ffff8801303c8998 ffff88013341d000 ffff88013341d090 ffff8801322d9dc8
[ 41.684180] ffff88013341d208 0000000000000000 0000000000000000 ffffffff811ad232
[ 41.684180] Call Trace:
[ 41.684180] [<ffffffff8123ad65>] ? __pm_runtime_set_status+0x162/0x186
[ 41.684180] [<ffffffff811ad232>] ? local_pci_probe+0x49/0x92
[ 41.684180] [<ffffffff8105afc5>] ? do_work_for_cpu+0x0/0x1b
[ 41.684180] [<ffffffff8105afc5>] ? do_work_for_cpu+0x0/0x1b
[ 41.684180] [<ffffffff8105afd0>] ? do_work_for_cpu+0xb/0x1b
[ 41.684180] [<ffffffff8105fd3f>] ? kthread+0x7a/0x82
[ 41.684180] [<ffffffff8100a824>] ? kernel_thread_helper+0x4/0x10
[ 41.684180] [<ffffffff8105fcc5>] ? kthread+0x0/0x82
[ 41.684180] [<ffffffff8100a820>] ? kernel_thread_helper+0x0/0x10
[ 41.684180] Code: f4 01 00 00 ef 31 f6 48 89 df e8 29 dd ff ff 85 c0 0f 88 2b 03 00 00 48 89 ef e8 b4 39 c3 e0 8b 7b 40 e8 fc 9d b1 e0 48 8b 43 38 <66> 8b 10 66 89 14 24 8b 43 14 83 e8 03 83 f8 01 77 32 31 d2 be
[ 41.684180] RIP [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
[ 41.684180] RSP <ffff88013153fe50>
[ 41.684180] CR2: ffffc90011c08000
[ 41.684180] ---[ end trace 8d1f3ebc136437fd ]---
[â]

Trusting the ACPI _CRS information (`pci=use_crs`) fixes this problem. The match has to be against the DMI board entries though.

[ 0.000000] DMI: System manufacturer System Product Name/M2V-MX SE, BIOS 0304 10/30/2007

This quirk should be removed when `pci=use_crs` is enabled for machines from 2006 or earlier.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=30552

CC: stable@xxxxxxxxxx (â 2.6.34)
CC: Bjorn Helgaas <bjorn.helgaas@xxxxxx>
Signed-off-by: Paul Menzel <paulepanter@xxxxxxxxxxxxxxxxxxxxx>
---
Bjorn is working on a real fix. But until he has time and this gets in it would be great to get this quirk in.
---
arch/x86/pci/acpi.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index ae3cb23..8bdad33 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -43,6 +43,16 @@ static const struct dmi_system_id pci_use_crs_table[] __initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "ALiveSATA2-GLAN"),
},
},
+ /* https://bugzilla.kernel.org/show_bug.cgi?id=30552 */
+ /* 2006 AMD HT/VIA system with two host bridges */
+ {
+ .callback = set_use_crs,
+ .ident = "ASUS M2V-MX SE",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
+ DMI_MATCH(DMI_BOARD_NAME, "M2V-MX SE"),
+ },
+ },
{}
};

--
1.7.5.4

Attachment: signature.asc
Description: This is a digitally signed message part