1. 22 9月, 2009 1 次提交
    • J
      mm: don't use alloc_bootmem_low() where not strictly needed · 3c1596ef
      Jan Beulich 提交于
      Since alloc_bootmem() will never return inaccessible (via virtual
      addressing) memory anyway, using the ..._low() variant only makes sense
      when the physical address range of the allocated memory must fulfill
      further constraints, espacially since on 64-bits (or more generally in all
      cases where the pools the two variants allocate from are than the full
      available range.
      
      Probably the use in alloc_tce_table() could also be eliminated (based on
      code inspection of pci-calgary_64.c), but that seems too risky given I
      know nothing about that hardware and have no way to test it.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3c1596ef
  2. 16 9月, 2009 1 次提交
  3. 09 9月, 2009 2 次提交
    • T
      dmi: extend dmi_get_year() to dmi_get_date() · 3e5cd1f2
      Tejun Heo 提交于
      There are cases where full date information is required instead of
      just the year.  Add month and day parsing to dmi_get_year() and rename
      it to dmi_get_date().
      
      As the original function only required '/' followed by any number of
      parseable characters at the end of the string, keep that behavior to
      avoid upsetting existing users.
      
      The new function takes dates of format [mm[/dd]]/yy[yy].  Year, month
      and date are checked to be in the ranges of [1-9999], [1-12] and
      [1-31] respectively and any invalid or out-of-range component is
      returned as zero.
      
      The dummy implementation is updated accordingly but the return value
      is updated to indicate field not found which is consistent with how
      other dummy functions behave.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      3e5cd1f2
    • T
      dmi: fix date handling in dmi_get_year() · 02c24fa8
      Tejun Heo 提交于
      Year parsing in dmi_get_year() had the following two bugs.
      
      * "00" is treated as invalid instead of 2000 because zero return from
        simple_strtoul() is treated as error.
      
      * "0N" where N >= 8 is treated as invalid of 200N because the leading
        0 is considered to specify octal.
      
      Fix the above two bugs by using endptr to detect invalid number and
      forcing decimal.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      02c24fa8
  4. 18 6月, 2009 1 次提交
    • M
      [IA64] Convert ia64 to use int-ll64.h · e088a4ad
      Matthew Wilcox 提交于
      It is generally agreed that it would be beneficial for u64 to be an
      unsigned long long on all architectures.  ia64 (in common with several
      other 64-bit architectures) currently uses unsigned long.  Migrating
      piecemeal is too painful; this giant patch fixes all compilation warnings
      and errors that come as a result of switching to use int-ll64.h.
      
      Note that userspace will still see __u64 defined as unsigned long.  This
      is important as it affects C++ name mangling.
      
      [Updated by Tony Luck to change efi.h:efi_freemem_callback_t to use
       u64 for start/end rather than unsigned long]
      Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      e088a4ad
  5. 17 6月, 2009 1 次提交
    • Y
      firmware_map: fix hang with x86/32bit · 3b0fde0f
      Yinghai Lu 提交于
      Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13484
      
      Peer reported:
      | The bug is introduced from kernel 2.6.27, if E820 table reserve the memory
      | above 4G in 32bit OS(BIOS-e820: 00000000fff80000 - 0000000120000000
      | (reserved)), system will report Int 6 error and hang up. The bug is caused by
      | the following code in drivers/firmware/memmap.c, the resource_size_t is 32bit
      | variable in 32bit OS, the BUG_ON() will be invoked to result in the Int 6
      | error. I try the latest 32bit Ubuntu and Fedora distributions, all hit this
      | bug.
      |======
      |static int firmware_map_add_entry(resource_size_t start, resource_size_t end,
      |                  const char *type,
      |                  struct firmware_map_entry *entry)
      
      and it only happen with CONFIG_PHYS_ADDR_T_64BIT is not set.
      
      it turns out we need to pass u64 instead of resource_size_t for that.
      
      [akpm@linux-foundation.org: add comment]
      Reported-and-tested-by: NPeer Chen <pchen@nvidia.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3b0fde0f
  6. 10 6月, 2009 1 次提交
    • S
      [libata] ahci: Restore SB600 SATA controller 64 bit DMA · 58a09b38
      Shane Huang 提交于
      Community reported one SB600 SATA issue(BZ #9412), which led to 64 bit
      DMA disablement for all SB600 revisions by driver maintainers with
      commits c7a42156 and
      4cde32fc.
      
      But the root cause is ASUS M2A-VM system BIOS bug in old revisions
      like 0901, while forcing into 32bit DMA happens to work as workaround.
      Now it's time to withdraw 4cde32fc
      so as to restore the SB600 SATA 64bit DMA capability.
      This patch is also adding the workaround for M2A-VM old BIOS revisions,
      but users are suggested to upgrade their system BIOS to the latest one
      if they meet this issue.
      Signed-off-by: NShane Huang <shane.huang@amd.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      58a09b38
  7. 03 5月, 2009 1 次提交
  8. 07 4月, 2009 1 次提交
  9. 31 3月, 2009 1 次提交
  10. 19 2月, 2009 1 次提交
  11. 12 2月, 2009 1 次提交
  12. 27 1月, 2009 1 次提交
    • R
      DMI: Introduce dmi_first_match to make the interface more flexible · d7b1956f
      Rafael J. Wysocki 提交于
      Some notebooks from HP have the problem that their BIOSes attempt to
      spin down hard drives before entering ACPI system states S4 and S5.
      This leads to a yo-yo effect during system power-off shutdown and the
      last phase of hibernation when the disk is first spun down by the
      kernel and then almost immediately turned on and off by the BIOS.
      This, in turn, may result in shortening the disk's life times.
      
      To prevent this from happening we can blacklist the affected systems
      using DMI information.  However, only the on-board controlles should
      be blacklisted and their PCI slot numbers can be used for this
      purpose.  Unfortunately the existing interface for checking DMI
      information of the system is not very convenient for this purpose,
      because to use it, we would have to define special callback functions
      or create a separate struct dmi_system_id table for each blacklisted
      system.
      
      To overcome this difficulty introduce a new function
      dmi_first_match() returning a pointer to the first entry in an array
      of struct dmi_system_id elements that matches the system DMI
      information.  Then, we can use this pointer to access the entry's
      .driver_data field containing the additional information, such as
      the PCI slot number, allowing us to do the desired blacklisting.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      d7b1956f
  13. 18 1月, 2009 1 次提交
  14. 12 1月, 2009 1 次提交
  15. 09 1月, 2009 2 次提交
  16. 07 1月, 2009 2 次提交
  17. 29 12月, 2008 1 次提交
  18. 08 11月, 2008 1 次提交
  19. 05 11月, 2008 1 次提交
    • A
      x86: vmware: look for DMI string in the product serial key · fd8cd7e1
      Alok Kataria 提交于
      Impact: Should permit VMware detection on older platforms where the
      vendor is changed.  Could theoretically cause a regression if some
      weird serial number scheme contains the string "VMware" by pure
      chance.  Seems unlikely, especially with the mixed case.
      
      In some user configured cases, VMware may choose not to put a VMware specific
      DMI string, but the product serial key is always there and is VMware specific.
      Add a interface to check the serial key, when checking for VMware in the DMI
      information.
      Signed-off-by: NAlok N Kataria <akataria@vmware.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      fd8cd7e1
  20. 31 10月, 2008 1 次提交
  21. 30 10月, 2008 1 次提交
  22. 29 10月, 2008 1 次提交
  23. 20 10月, 2008 1 次提交
    • P
      x86: sysfs: kill owner field from attribute · 01e8ef11
      Parag Warudkar 提交于
      Tejun's commit 7b595756 made sysfs
      attribute->owner unnecessary.  But the field was left in the structure to
      ease the merge.  It's been over a year since that change and it is now
      time to start killing attribute->owner along with its users - one arch at
      a time!
      
      This patch is attempt #1 to get rid of attribute->owner only for
      CONFIG_X86_64 or CONFIG_X86_32 .  We will deal with other arches later on
      as and when possible - avr32 will be the next since that is something I
      can test.  Compile (make allyesconfig / make allmodconfig / custom config)
      and boot tested.
      
      akpm: the idea is that we put the declaration of sttribute.owner inside
      `#ifndef CONFIG_X86'.  But that proved to be too ambitious for now because
      new usages kept on turning up in subsystem trees.
      
      [akpm: remove the ifdef for now]
      Signed-off-by: NParag Warudkar <parag.lkml@gmail.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Tejun Heo <htejun@gmail.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Roland Dreier <rolandd@cisco.com>
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      01e8ef11
  24. 17 10月, 2008 1 次提交
  25. 18 9月, 2008 1 次提交
  26. 03 9月, 2008 1 次提交
    • M
      ibft: fix target info parsing in ibft module · bb8fb4e6
      Mike Christie 提交于
      I got this patch through Red Hat's bugzilla from the bug submitter and
      patch creator.  I have just fixed it up so it applies without fuzz to
      upstream kernels.
      
      Original patch and description from Shyam kumar Iyer:
      
      The issue [ibft module not displaying targets with short names] is because
      of an offset calculatation error in the iscsi_ibft.c code.  Due to this
      error directory structure for the target in /sys/firmware/ibft does not
      get created and so the initiator is unable to connect to the target.
      
      Note that this bug surfaced only with an name that had a short section at
      the end.  eg: "iqn.1984-05.com.dell:dell".  It did not surface when the
      iqn's had a longer section at the end.  eg:
      "iqn.2001-04.com.example:storage.disk2.sys1.xyz"
      
      So, the eot_offset was calculated such that an extra 48 bytes i.e.  the
      size of the ibft_header which has already been accounted was subtracted
      twice.
      
      This was not evident with longer iqn names because they would overshoot
      the total ibft length more than 48 bytes and thus would escape the bug.
      Signed-off-by: NShyam Kumar Iyer <shyam_iyer@dell.com>
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Cc: Konrad Rzeszutek <konrad@virtualiron.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bb8fb4e6
  27. 13 8月, 2008 1 次提交
  28. 31 7月, 2008 1 次提交
  29. 27 7月, 2008 1 次提交
  30. 26 7月, 2008 3 次提交
  31. 19 7月, 2008 1 次提交
    • M
      cpumask: Replace cpumask_of_cpu with cpumask_of_cpu_ptr · 65c01184
      Mike Travis 提交于
        * This patch replaces the dangerous lvalue version of cpumask_of_cpu
          with new cpumask_of_cpu_ptr macros.  These are patterned after the
          node_to_cpumask_ptr macros.
      
          In general terms, if there is a cpumask_of_cpu_map[] then a pointer to
          the cpumask_of_cpu_map[cpu] entry is used.  The cpumask_of_cpu_map
          is provided when there is a large NR_CPUS count, reducing
          greatly the amount of code generated and stack space used for
          cpumask_of_cpu().  The pointer to the cpumask_t value is needed for
          calling set_cpus_allowed_ptr() to reduce the amount of stack space
          needed to pass the cpumask_t value.
      
          If there isn't a cpumask_of_cpu_map[], then a temporary variable is
          declared and filled in with value from cpumask_of_cpu(cpu) as well as
          a pointer variable pointing to this temporary variable.  Afterwards,
          the pointer is used to reference the cpumask value.  The compiler
          will optimize out the extra dereference through the pointer as well
          as the stack space used for the pointer, resulting in identical code.
      
          A good example of the orthogonal usages is in net/sunrpc/svc.c:
      
      	case SVC_POOL_PERCPU:
      	{
      		unsigned int cpu = m->pool_to[pidx];
      		cpumask_of_cpu_ptr(cpumask, cpu);
      
      		*oldmask = current->cpus_allowed;
      		set_cpus_allowed_ptr(current, cpumask);
      		return 1;
      	}
      	case SVC_POOL_PERNODE:
      	{
      		unsigned int node = m->pool_to[pidx];
      		node_to_cpumask_ptr(nodecpumask, node);
      
      		*oldmask = current->cpus_allowed;
      		set_cpus_allowed_ptr(current, nodecpumask);
      		return 1;
      	}
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      65c01184
  32. 10 7月, 2008 1 次提交
  33. 08 7月, 2008 1 次提交
    • B
      sysfs: add /sys/firmware/memmap · 69ac9cd6
      Bernhard Walle 提交于
      This patch adds /sys/firmware/memmap interface that represents the BIOS
      (or Firmware) provided memory map. The tree looks like:
      
          /sys/firmware/memmap/0/start   (hex number)
                                 end     (hex number)
                                 type    (string)
          ...                 /1/start
                                 end
                                 type
      
      With the following shell snippet one can print the memory map in the same form
      the kernel prints itself when booting on x86 (the E820 map).
      
        --------- 8< --------------------------
          #!/bin/sh
          cd /sys/firmware/memmap
          for dir in * ; do
              start=$(cat $dir/start)
              end=$(cat $dir/end)
              type=$(cat $dir/type)
              printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type"
          done
        --------- >8 --------------------------
      
      That patch only provides the needed interface:
      
       1. The sysfs interface.
       2. The structure and enumeration definition.
       3. The function firmware_map_add() and firmware_map_add_early()
          that should be called from architecture code (E820/EFI, for
          example) to add the contents to the interface.
      
      If the kernel is compiled without CONFIG_FIRMWARE_MEMMAP, the interface does
      nothing without cluttering the architecture-specific code with #ifdef's.
      
      The purpose of the new interface is kexec: While /proc/iomem represents
      the *used* memory map (e.g. modified via kernel parameters like 'memmap'
      and 'mem'), the /sys/firmware/memmap tree represents the unmodified memory
      map provided via the firmware. So kexec can:
      
       - use the original memory map for rebooting,
       - use the /proc/iomem for setting up the ELF core headers for kdump
         case that should only represent the memory of the system.
      
      The patch has been tested on i386 and x86_64.
      Signed-off-by: NBernhard Walle <bwalle@suse.de>
      Acked-by: NGreg KH <gregkh@suse.de>
      Acked-by: NVivek Goyal <vgoyal@redhat.com>
      Cc: kexec@lists.infradead.org
      Cc: yhlu.kernel@gmail.com
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      69ac9cd6
  34. 07 6月, 2008 1 次提交
  35. 25 5月, 2008 1 次提交
新手
引导
客服 返回
顶部