1. 24 5月, 2008 2 次提交
  2. 20 5月, 2008 1 次提交
  3. 18 5月, 2008 6 次提交
  4. 17 5月, 2008 1 次提交
  5. 14 5月, 2008 7 次提交
    • R
      x86: user_regset_view table fix for ia32 on 64-bit · 1f465f4e
      Roland McGrath 提交于
      The user_regset_view table for the 32-bit regsets on the 64-bit build had
      the wrong sizes for the FP regsets.  This bug had no user-visible effect
      (just on kernel modules using the user_regset interfaces and the like).
      But the fix is trivial and risk-free.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1f465f4e
    • P
      x86: arch/x86/mm/pat.c - fix warning · afc85343
      Pranith Kumar 提交于
      fix this warning:
      
       arch/x86/mm/pat.c: In function `phys_mem_access_prot_allowed':
       arch/x86/mm/pat.c:558: warning: long long unsigned int format, long
       unsigned int arg (arg 6)
       arch/x86/mm/pat.c: In function `map_devmem':
       arch/x86/mm/pat.c:580: warning: long long unsigned int format, long
       unsigned int arg (arg 6)
      Signed-off-by: ND Pranith Kumar <bobby.prani@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      afc85343
    • I
      x86: fix csum_partial() export · 89804c02
      Ingo Molnar 提交于
      Fix this symbol export problem:
      
          Building modules, stage 2.
          MODPOST 193 modules
          ERROR: "csum_partial" [fs/reiserfs/reiserfs.ko] undefined!
          make[1]: *** [__modpost] Error 1
          make: *** [modules] Error 2
      
      This is due to a known weakness of symbol exports: if a symbol's
      only in-core user is an EXPORT_SYMBOL from a lib-y section, the
      symbol is not linked in.
      
      The solution is to move the export to x8664_ksyms_64.c - but the real
      solution would be to fix kbuild.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      89804c02
    • A
      x86: early_init_centaur(): use set_cpu_cap() · 8c45a4e4
      Andrew Morton 提交于
      arch/x86/kernel/setup_64.c:954: warning: passing argument 2 of 'set_bit' from incompatible pointer type
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8c45a4e4
    • H
      x86: fix app crashes after SMP resume · 61165d7a
      Hugh Dickins 提交于
      After resume on a 2cpu laptop, kernel builds collapse with a sed hang,
      sh or make segfault (often on 20295564), real-time signal to cc1 etc.
      
      Several hurdles to jump, but a manually-assisted bisect led to -rc1's
      d2bcbad5 x86: do not zap_low_mappings
      in __smp_prepare_cpus.  Though the low mappings were removed at bootup,
      they were left behind (with Global flags helping to keep them in TLB)
      after resume or cpu online, causing the crashes seen.
      
      Reinstate zap_low_mappings (with local __flush_tlb_all) for each cpu_up
      on x86_32.  This used to be serialized by smp_commenced_mask: that's now
      gone, but a low_mappings flag will do.  No need for native_smp_cpus_done
      to repeat the zap: let mem_init zap BSP's low mappings just like on UP.
      
      (In passing, fix error code from native_cpu_up: do_boot_cpu returns a
      variety of diagnostic values, Dprintk what it says but convert to -EIO.
      And save_pg_dir separately before zap_low_mappings: doesn't matter now,
      but zapping twice in succession wiped out resume's swsusp_pg_dir.)
      
      That worked well on the duo and one quad, but wouldn't boot 3rd or 4th
      cpu on P4 Xeon, oopsing just after unlock_ipi_call_lock.  The TLB flush
      IPI now being sent reveals a long-standing bug: the booting cpu has its
      APIC readied in smp_callin at the top of start_secondary, but isn't put
      into the cpu_online_map until just before that unlock_ipi_call_lock.
      
      So native_smp_call_function_mask to online cpus would send_IPI_allbutself,
      including the cpu just coming up, though it has been excluded from the
      count to wait for: by the time it handles the IPI, the call data on
      native_smp_call_function_mask's stack may well have been overwritten.
      
      So fall back to send_IPI_mask while cpu_online_map does not match
      cpu_callout_map: perhaps there's a better APICological fix to be
      made at the start_secondary end, but I wouldn't know that.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      61165d7a
    • V
      x86/PCI: X86_PAT & mprotect · 77db9885
      Venki Pallipadi 提交于
      Some versions of X used the mprotect workaround to change caching type from UC
      to WB, so that it can then use mtrr to program WC for that region [1].  Change
      the mmap of pci space through /sys or /proc interfaces from UC to UC_MINUS.
      With this change, X will not need to use mprotect workaround to get WC type
      since the MTRR mapping type will be honored.
      
      The bug in mprotect that clobbers PAT bits is fixed in a follow on patch. So,
      this X workaround will stop working as well.
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      77db9885
    • T
      x86/PCI: fix broken ISA DMA · 4a367f3a
      Takashi Iwai 提交于
      Rene Herman reported:
      
      > commit 8779f2fc
      >
      > "x86: don't try to allocate from DMA zone at first"
      >
      > breaks all of ISA DMA. Or all of ALSA ISA DMA at least. All
      > ISA soundcards are silent following that commit -- no error
      > messages, everything appears fine, just silence.
      
      That patch is buggy. We had an implicit assumption that
      dev = NULL for ISA devices that require 24bit DMA.
      
      The recent work on x86 dma_alloc_coherent() breaks the ISA DMA buffer
      allocation, which is represented by "dev = NULL" and requires 24bit
      DMA implicitly.
      Bisected-by: NRene Herman <rene.herman@keyaccess.nl>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      4a367f3a
  6. 13 5月, 2008 3 次提交
  7. 11 5月, 2008 5 次提交
  8. 09 5月, 2008 1 次提交
  9. 08 5月, 2008 3 次提交
  10. 07 5月, 2008 2 次提交
    • S
      pcspkr: fix dependancies · e5e1d3cb
      Stas Sergeev 提交于
      fix pcspkr dependancies: make the pcspkr platform
      drivers to depend on a platform device, and
      not the other way around.
      Signed-off-by: NStas Sergeev <stsp@aknet.ru>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NDmitry Torokhov <dtor@mail.ru>
      CC: Vojtech Pavlik <vojtech@suse.cz>
      CC: Michael Opdenacker <michael-lists@free-electrons.com>
      [fixed for 2.6.26-rc1 by tiwai]
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      e5e1d3cb
    • H
      x86: fix PAE pmd_bad bootup warning · aeed5fce
      Hugh Dickins 提交于
      Fix warning from pmd_bad() at bootup on a HIGHMEM64G HIGHPTE x86_32.
      
      That came from 9fc34113 x86: debug pmd_bad();
      but we understand now that the typecasting was wrong for PAE in the previous
      version: pagetable pages above 4GB looked bad and stopped Arjan from booting.
      
      And revert that cded932b x86: fix pmd_bad
      and pud_bad to support huge pages.  It was the wrong way round: we shouldn't
      weaken every pmd_bad and pud_bad check to let huge pages slip through - in
      part they check that we _don't_ have a huge page where it's not expected.
      
      Put the x86 pmd_bad() and pud_bad() definitions back to what they have long
      been: they can be improved (x86_32 should use PTE_MASK, to stop PAE thinking
      junk in the upper word is good; and x86_64 should follow x86_32's stricter
      comparison, to stop thinking any subset of required bits is good); but that
      should be a later patch.
      
      Fix Hans' good observation that follow_page() will never find pmd_huge()
      because that would have already failed the pmd_bad test: test pmd_huge in
      between the pmd_none and pmd_bad tests.  Tighten x86's pmd_huge() check?
      No, once it's a hugepage entry, it can get quite far from a good pmd: for
      example, PROT_NONE leaves it with only ACCESSED of the KERN_PGTABLE bits.
      
      However... though follow_page() contains this and another test for huge
      pages, so it's nice to keep it working on them, where does it actually get
      called on a huge page?  get_user_pages() checks is_vm_hugetlb_page(vma) to
      to call alternative hugetlb processing, as does unmap_vmas() and others.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Earlier-version-tested-by: NIngo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jeff Chua <jeff.chua.linux@gmail.com>
      Cc: Hans Rosenfeld <hans.rosenfeld@amd.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      aeed5fce
  11. 06 5月, 2008 3 次提交
  12. 05 5月, 2008 6 次提交