• Paul Menzel's avatar
    x86/PCI: use host bridge _CRS info on ASUS M2V-MX SE · 29cf7a30
    Paul Menzel authored
    In summary, this DMI quirk uses the _CRS info by default for the ASUS
    M2V-MX SE by turning on `pci=use_crs` and is similar to the quirk
    added by commit 2491762c ("x86/PCI: use host bridge _CRS info on
    ASRock ALiveSATA2-GLAN") whose commit message should be read for further
    information.
    
    Since commit 3e3da00c ("x86/pci: AMD one chain system to use pci
    read out res") Linux gives the following oops:
    
        parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
        HDA Intel 0000:20:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
        HDA Intel 0000:20:01.0: setting latency timer to 64
        BUG: unable to handle kernel paging request at ffffc90011c08000
        IP: [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
        PGD 13781a067 PUD 13781b067 PMD 1300ba067 PTE 800000fd00000173
        Oops: 0009 [#1] SMP
        last sysfs file: /sys/module/snd_pcm/initstate
        CPU 0
        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]
        Pid: 1153, comm: work_for_cpu Not tainted 2.6.37-1-amd64 #1 M2V-MX SE/System Product Name
        RIP: 0010:[<ffffffffa0578402>]  [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
        RSP: 0018:ffff88013153fe50  EFLAGS: 00010286
        RAX: ffffc90011c08000 RBX: ffff88013029ec00 RCX: 0000000000000006
        RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
        RBP: ffff88013341d000 R08: 0000000000000000 R09: 0000000000000040
        R10: 0000000000000286 R11: 0000000000003731 R12: ffff88013029c400
        R13: 0000000000000000 R14: 0000000000000000 R15: ffff88013341d090
        FS:  0000000000000000(0000) GS:ffff8800bfc00000(0000) knlGS:00000000f7610ab0
        CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
        CR2: ffffc90011c08000 CR3: 0000000132f57000 CR4: 00000000000006f0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
        Process work_for_cpu (pid: 1153, threadinfo ffff88013153e000, task ffff8801303c86c0)
        Stack:
         0000000000000005 ffffffff8123ad65 00000000000136c0 ffff88013029c400
         ffff8801303c8998 ffff88013341d000 ffff88013341d090 ffff8801322d9dc8
         ffff88013341d208 0000000000000000 0000000000000000 ffffffff811ad232
        Call Trace:
         [<ffffffff8123ad65>] ? __pm_runtime_set_status+0x162/0x186
         [<ffffffff811ad232>] ? local_pci_probe+0x49/0x92
         [<ffffffff8105afc5>] ? do_work_for_cpu+0x0/0x1b
         [<ffffffff8105afc5>] ? do_work_for_cpu+0x0/0x1b
         [<ffffffff8105afd0>] ? do_work_for_cpu+0xb/0x1b
         [<ffffffff8105fd3f>] ? kthread+0x7a/0x82
         [<ffffffff8100a824>] ? kernel_thread_helper+0x4/0x10
         [<ffffffff8105fcc5>] ? kthread+0x0/0x82
         [<ffffffff8100a820>] ? kernel_thread_helper+0x0/0x10
        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
        RIP  [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
         RSP <ffff88013153fe50>
        CR2: ffffc90011c08000
        ---[ end trace 8d1f3ebc136437fd ]---
    
    Trusting the ACPI _CRS information (`pci=use_crs`) fixes this problem.
    
        $ dmesg | grep -i crs # with the quirk
        PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
    
    The match has to be against the DMI board entries though since the vendor entries are not populated.
    
        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 or some other solution is implemented.
    
    Using coreboot [1] with this board the problem does not exist but this
    quirk also does not affect it either. To be safe though the check is
    tightened to only take effect when the BIOS from American Megatrends is
    used.
    
            15:13 < ruik> but coreboot does not need that
            15:13 < ruik> because i have there only one root bus
            15:13 < ruik> the audio is behind a bridge
    
            $ sudo dmidecode
            BIOS Information
                    Vendor: American Megatrends Inc.
                    Version: 0304
                    Release Date: 10/30/2007
    
    [1] http://www.coreboot.org/
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=30552
    
    Cc: stable@kernel.org (2.6.34)
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: x86@kernel.org
    Signed-off-by: default avatarPaul Menzel <paulepanter@users.sourceforge.net>
    Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
    Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    29cf7a30
acpi.c 10.5 KB