1. 14 Nov, 2005 10 commits
    • Andi Kleen's avatar
      [PATCH] x86_64: Only use asm/sections.h to declare section symbols · 2bc0414e
      Andi Kleen authored
      
      
      Adding __initdata_* to asm-generic/sections.h
      Replaces a lot of open coded externs in arch/x86_64/*
      I had to change __bss_end to __bss_stop to match the other architectures.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2bc0414e
    • Andi Kleen's avatar
      [PATCH] x86_64: Don't apply __PHYSICAL_MASK to page frame numbers · 6b75aeed
      Andi Kleen authored
      
      
      It is for physical addresses, not for PFNs.
      
      Pointed out by Tejun Heo.
      
      Cc: htejun@gmail.com
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6b75aeed
    • Siddha, Suresh B's avatar
      [PATCH] x86_64: Unmap NULL during early bootup · f6c2e333
      Siddha, Suresh B authored
      
      
      We should zap the low mappings, as soon as possible, so that we can catch
      kernel bugs more effectively. Previously early boot had NULL mapped
      and didn't trap on NULL references.
      
      This patch introduces boot_level4_pgt, which will always have low identity
      addresses mapped.  Druing boot, all the processors will use this as their
      level4 pgt.  On BP, we will switch to init_level4_pgt as soon as we enter C
      code and zap the low mappings as soon as we are done with the usage of
      identity low mapped addresses.  On AP's we will zap the low mappings as
      soon as we jump to C code.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f6c2e333
    • Andi Kleen's avatar
      [PATCH] x86_64: Speed up numa_node_id by putting it directly into the PDA · 69d81fcd
      Andi Kleen authored
      
      
      Not go from the CPU number to an mapping array.
      Mode number is often used now in fast paths.
      
      This also adds a generic numa_node_id to all the topology includes
      
      Suggested by Eric Dumazet
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      69d81fcd
    • Andi Kleen's avatar
      [PATCH] x86_64: Remove obsolete ARCH_HAS_ATOMIC_UNSIGNED and page_flags_t · 07808b74
      Andi Kleen authored
      
      
      Has been introduced for x86-64 at some point to save memory
      in struct page, but has been obsolete for some time. Just
      remove it.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      07808b74
    • Andi Kleen's avatar
      [PATCH] x86_64: Fix up outdated pfn_to_page comment · 1dff7f3d
      Andi Kleen authored
      
      
      pfn_to_page really requires pfn_valid to be true now, no question.
      Some people stumbled over it, but it was misleading and wrong.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1dff7f3d
    • James Cleverdon's avatar
      [PATCH] i386/x86-64: Share interrupt vectors when there is a large number of interrupt sources · 6004e1b7
      James Cleverdon authored
      
      
      Here's a patch that builds on Natalie Protasevich's IRQ compression
      patch and tries to work for MPS boots as well as ACPI.  It is meant for
      a 4-node IBM x460 NUMA box, which was dying because it had interrupt
      pins with GSI numbers > NR_IRQS and thus overflowed irq_desc.
      
      The problem is that this system has 270 GSIs (which are 1:1 mapped with
      I/O APIC RTEs) and an 8-node box would have 540.  This is much bigger
      than NR_IRQS (224 for both i386 and x86_64).  Also, there aren't enough
      vectors to go around.  There are about 190 usable vectors, not counting
      the reserved ones and the unused vectors at 0x20 to 0x2F.  So, my patch
      attempts to compress the GSI range and share vectors by sharing IRQs.
      
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@unisys.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6004e1b7
    • Jacob Shin's avatar
      [PATCH] x86_64: Support for AMD specific MCE Threshold. · 89b831ef
      Jacob Shin authored
      
      
      MC4_MISC - DRAM Errors Threshold Register realized under AMD K8 Rev F.
      This register is used to count correctable and uncorrectable ECC errors that occur during DRAM read operations.
      The user may interface through sysfs files in order to change the threshold configuration.
      
      bank%d/error_count - reads current error count, write to clear.
      bank%d/interrupt_enable - set/clear interrupt enable.
      bank%d/threshold_limit - read/write the threshold limit.
      
      APIC vector 0xF9 in hw_irq.h.
      5 software defined bank ids in mce.h.
      new apic.c function to setup threshold apic lvt.
      defaults to interrupt off, count enabled, and threshold limit max.
      sysfs interface created on /sys/devices/system/threshold.
      
      AK: added some ifdefs to make it compile on UP
      Signed-off-by: default avatarJacob Shin <jacob.shin@amd.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      89b831ef
    • Jan Beulich's avatar
    • Andi Kleen's avatar
      [PATCH] x86_64: Add 4GB DMA32 zone · a2f1b424
      Andi Kleen authored
      
      
      Add a new 4GB GFP_DMA32 zone between the GFP_DMA and GFP_NORMAL zones.
      
      As a bit of historical background: when the x86-64 port
      was originally designed we had some discussion if we should
      use a 16MB DMA zone like i386 or a 4GB DMA zone like IA64 or
      both. Both was ruled out at this point because it was in early
      2.4 when VM is still quite shakey and had bad troubles even
      dealing with one DMA zone.  We settled on the 16MB DMA zone mainly
      because we worried about older soundcards and the floppy.
      
      But this has always caused problems since then because
      device drivers had trouble getting enough DMA able memory. These days
      the VM works much better and the wide use of NUMA has proven
      it can deal with many zones successfully.
      
      So this patch adds both zones.
      
      This helps drivers who need a lot of memory below 4GB because
      their hardware is not accessing more (graphic drivers - proprietary
      and free ones, video frame buffer drivers, sound drivers etc.).
      Previously they could only use IOMMU+16MB GFP_DMA, which
      was not enough memory.
      
      Another common problem is that hardware who has full memory
      addressing for >4GB misses it for some control structures in memory
      (like transmit rings or other metadata).  They tended to allocate memory
      in the 16MB GFP_DMA or the IOMMU/swiotlb then using pci_alloc_consistent,
      but that can tie up a lot of precious 16MB GFPDMA/IOMMU/swiotlb memory
      (even on AMD systems the IOMMU tends to be quite small) especially if you have
      many devices.  With the new zone pci_alloc_consistent can just put
      this stuff into memory below 4GB which works better.
      
      One argument was still if the zone should be 4GB or 2GB. The main
      motivation for 2GB would be an unnamed not so unpopular hardware
      raid controller (mostly found in older machines from a particular four letter
      company) who has a strange 2GB restriction in firmware. But
      that one works ok with swiotlb/IOMMU anyways, so it doesn't really
      need GFP_DMA32. I chose 4GB to be compatible with IA64 and because
      it seems to be the most common restriction.
      
      The new zone is so far added only for x86-64.
      
      For other architectures who don't set up this
      new zone nothing changes. Architectures can set a compatibility
      define in Kconfig CONFIG_DMA_IS_DMA32 that will define GFP_DMA32
      as GFP_DMA. Otherwise it's a nop because on 32bit architectures
      it's normally not needed because GFP_NORMAL (=0) is DMA able
      enough.
      
      One problem is still that GFP_DMA means different things on different
      architectures. e.g. some drivers used to have #ifdef ia64  use GFP_DMA
      (trusting it to be 4GB) #elif __x86_64__ (use other hacks like
      the swiotlb because 16MB is not enough) ... . This was quite
      ugly and is now obsolete.
      
      These should be now converted to use GFP_DMA32 unconditionally. I haven't done
      this yet. Or best only use pci_alloc_consistent/dma_alloc_coherent
      which will use GFP_DMA32 transparently.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a2f1b424
  2. 04 Nov, 2005 6 commits
    • Jeff Garzik's avatar
      [libata] ATAPI pad allocation fixes/cleanup · 6037d6bb
      Jeff Garzik authored
      Use ata_pad_{alloc,free} in two drivers, to factor out common code.
      
      Add ata_pad_{alloc,free} to two other drivers, which needed the padding
      but had not been updated.
      6037d6bb
    • Calin A. Culianu's avatar
      [PATCH] nvidiafb: Geforce 7800 series support added · 7015faa7
      Calin A. Culianu authored
      
      
      This adds support for the Nvidia Geforce 7800 series of cards to the
      nvidiafb framebuffer driver.  All it does is add the PCI device id for
      the 7800, 7800 GTX, 7800 GO, and 7800 GTX GO cards to the module device
      table for the nvidiafb.ko driver, so that nvidiafb.ko will actually work
      on these cards.
      
      I also added the relevant PCI device ids to linux/pci_ids.h
      
      I tested it on my 7800 GTX here and it works like a charm.  I now can
      get framebuffer support on this card! Woo hoo!! Nothing like 200x75 text
      mode to make your eyes BLEED.  ;)
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      7015faa7
    • Paul Mackerras's avatar
      powerpc: Merge smp.c and smp.h · 5ad57078
      Paul Mackerras authored
      
      
      This also moves setup_cpu_maps to setup-common.c (calling it
      smp_setup_cpu_maps) and uses it on both 32-bit and 64-bit.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      5ad57078
    • Trond Myklebust's avatar
      NFSv4: Fix problem with OPEN_DOWNGRADE · d530838b
      Trond Myklebust authored
      
      
       RFC 3530 states that for OPEN_DOWNGRADE "The share_access and share_deny
       bits specified must be exactly equal to the union of the share_access and
       share_deny bits specified for some subset of the OPENs in effect for
       current openowner on the current file.
      
       Setattr is currently violating the NFSv4 rules for OPEN_DOWNGRADE in that
       it may cause a downgrade from OPEN4_SHARE_ACCESS_BOTH to
       OPEN4_SHARE_ACCESS_WRITE despite the fact that there exists no open file
       with O_WRONLY access mode.
      
       Fix the problem by replacing nfs4_find_state() with a modified version of
       nfs_find_open_context().
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      d530838b
    • Russell King's avatar
      [PATCH] ARM: Reverted 2918/1: [update] Base port of Comdial MP1000 platfrom · d56c524a
      Russell King authored
      No longer maintained
      d56c524a
    • Dave Jiang's avatar
      [ARM] 3086/1: ixp2xxx error irq handling · 7866f649
      Dave Jiang authored
      
      
      Patch from Dave Jiang
      
      This provides support for IXP2xxx error interrupt handling. Previously there was a patch to remove this (although the original stuff was broken). Well, now the error bits are needed again. These are used extensively by the micro-engine drivers according to Deepak and also we will need it for the new EDAC code that Alan Cox is trying to push into the main kernel.
      
      Re-submit of 3072/1, generated against git tree pulled today. AFAICT, this git tree pulled in all the ARM changes that's in arm.diff. Please let me know if there are additional changes. Thx!
      Signed-off-by: default avatarDave Jiang <djiang@mvista.com>
      Signed-off-by: default avatarDeepak Saxena <dsaxena@plexity.net>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      7866f649
  3. 03 Nov, 2005 7 commits
  4. 02 Nov, 2005 17 commits