1. 07 10月, 2011 1 次提交
    • P
      x86/PCI: use host bridge _CRS info on ASUS M2V-MX SE · 29cf7a30
      Paul Menzel 提交于
      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: NPaul Menzel <paulepanter@users.sourceforge.net>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      29cf7a30
  2. 02 10月, 2011 1 次提交
  3. 30 9月, 2011 2 次提交
    • B
      powerpc: Fix device-tree matching for Apple U4 bridge · 16fa42af
      Benjamin Herrenschmidt 提交于
      Apple Quad G5 has some oddity in it's device-tree which causes the new
      generic matching code to fail to relate nodes for PCI-E devices below U4
      with their respective struct pci_dev.  This breaks graphics on those
      machines among others.
      
      This fixes it using a quirk which copies the node pointer from the host
      bridge for the root complex, which makes the generic code work for the
      children afterward.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      16fa42af
    • D
      sparc64: Force the execute bit in OpenFirmware's translation entries. · f4142cba
      David S. Miller 提交于
      In the OF 'translations' property, the template TTEs in the mappings
      never specify the executable bit.  This is the case even though some
      of these mappings are for OF's code segment.
      
      Therefore, we need to force the execute bit on in every mapping.
      
      This problem can only really trigger on Niagara/sun4v machines and the
      history behind this is a little complicated.
      
      Previous to sun4v, the sun4u TTE entries lacked a hardware execute
      permission bit.  So OF didn't have to ever worry about setting
      anything to handle executable pages.  Any valid TTE loaded into the
      I-TLB would be respected by the chip.
      
      But sun4v Niagara chips have a real hardware enforced executable bit
      in their TTEs.  So it has to be set or else the I-TLB throws an
      instruction access exception with type code 6 (protection violation).
      
      We've been extremely fortunate to not get bitten by this in the past.
      
      The best I can tell is that the OF's mappings for it's executable code
      were mapped using permanent locked mappings on sun4v in the past.
      Therefore, the fact that we didn't have the exec bit set in the OF
      translations we would use did not matter in practice.
      
      Thanks to Greg Onufer for helping me track this down.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f4142cba
  4. 27 9月, 2011 2 次提交
  5. 26 9月, 2011 8 次提交
  6. 24 9月, 2011 1 次提交
  7. 22 9月, 2011 1 次提交
    • D
      sparc: Make '-p' boot option meaningful again. · 11032c17
      David S. Miller 提交于
      If "-p" is given on the command line, clear the CON_BOOT
      flag for the initial early boot PROM console.
      
      This is necessary to try and see crash messages that occur
      between the registry of the VT console and the probing of
      the first framebuffer or serial console.  During this time
      no console messages are emitted because the VT console
      registry (even if no backend is registered to it) removes
      the early console if CON_BOOT is set.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11032c17
  8. 21 9月, 2011 24 次提交