1. 25 1月, 2008 26 次提交
  2. 24 1月, 2008 3 次提交
    • L
      ACPI: make _OSI(Linux) console messages smarter · d4b7dc49
      Len Brown 提交于
      If BIOS invokes _OSI(Linux), the kernel response
      depends on what the ACPI DMI list knows about the system,
      and that is reflectd in dmesg:
      
      1) System unknown to DMI:
      
      ACPI: BIOS _OSI(Linux) query ignored
      ACPI: DMI System Vendor: LENOVO
      ACPI: DMI Product Name: 7661W1P
      ACPI: DMI Product Version: ThinkPad T61
      ACPI: DMI Board Name: 7661W1P
      ACPI: DMI BIOS Vendor: LENOVO
      ACPI: DMI BIOS Date: 10/18/2007
      ACPI: Please send DMI info above to linux-acpi@vger.kernel.org
      ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org
      
      2) System known to DMI, but effect of OSI(Linux) unknown:
      
      ACPI: DMI detected: Lenovo ThinkPad T61
      ...
      ACPI: BIOS _OSI(Linux) query ignored via DMI
      ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org
      
      3) System known to DMI, which disables _OSI(Linux):
      
      ACPI: DMI detected: Lenovo ThinkPad T61
      ...
      ACPI: BIOS _OSI(Linux) query ignored via DMI
      
      4) System known to DMI, which enable _OSI(Linux):
      
      ACPI: DMI detected: Lenovo ThinkPad T61
      ACPI: Added _OSI(Linux)
      ...
      ACPI: BIOS _OSI(Linux) query honored via DMI
      
      cmdline overrides take precidence over the built-in
      default and the DMI prescribed default.
      cmdline "acpi_osi=Linux" results in:
      
      ACPI: BIOS _OSI(Linux) query honored via cmdline
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d4b7dc49
    • L
      DMI: create dmi_get_slot() · f89e3b06
      Len Brown 提交于
      This simply allows other sub-systems (such as ACPI)
      to access and print out slots in static dmi_ident[].
      Signed-off-by: NLen Brown <len.brown@intel.com>
      f89e3b06
    • L
      81b4e1f6
  3. 16 1月, 2008 2 次提交
  4. 15 1月, 2008 2 次提交
  5. 14 1月, 2008 1 次提交
    • R
      remove task_ppid_nr_ns · 84427eae
      Roland McGrath 提交于
      task_ppid_nr_ns is called in three places.  One of these should never
      have called it.  In the other two, using it broke the existing
      semantics.  This was presumably accidental.  If the function had not
      been there, it would have been much more obvious to the eye that those
      patches were changing the behavior.  We don't need this function.
      
      In task_state, the pid of the ptracer is not the ppid of the ptracer.
      
      In do_task_stat, ppid is the tgid of the real_parent, not its pid.
      I also moved the call outside of lock_task_sighand, since it doesn't
      need it.
      
      In sys_getppid, ppid is the tgid of the real_parent, not its pid.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      84427eae
  6. 12 1月, 2008 1 次提交
  7. 11 1月, 2008 2 次提交
  8. 09 1月, 2008 3 次提交
    • D
      [NET]: Add NAPI_STATE_DISABLE. · a0a46196
      David S. Miller 提交于
      Create a bit to signal that a napi_disable() is in progress.
      
      This sets up infrastructure such that net_rx_action() can generically
      break out of the ->poll() loop on a NAPI context that has a pending
      napi_disable() yet is being bombed with packets (and thus would
      otherwise poll endlessly and not allow the napi_disable() to finish).
      
      Now, what napi_disable() does is first set the NAPI_STATE_DISABLE bit
      (to indicate that a disable is pending), then it polls for the
      NAPI_STATE_SCHED bit, and once the NAPI_STATE_SCHED bit is acquired
      the NAPI_STATE_DISABLE bit is cleared.  Here, the test_and_set_bit()
      provides the necessary memory barrier between the various bitops.
      
      napi_schedule_prep() now tests for a pending disable as it's first
      action and won't try to obtain the NAPI_STATE_SCHED bit if a disable
      is pending.
      
      As a result, we can remove the netif_running() check in
      netif_rx_schedule_prep() because the NAPI disable pending state serves
      this purpose.  And, it does so in a NAPI centric manner which is what
      we really want.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0a46196
    • D
      [NET]: Do not grab device reference when scheduling a NAPI poll. · bdb95b17
      David S. Miller 提交于
      It is pointless, because everything that can make a device go away
      will do a napi_disable() first.
      
      The main impetus behind this is that now we can legally do a NAPI
      completion in generic code like net_rx_action() which a following
      changeset needs to do.  net_rx_action() can only perform actions
      in NAPI centric ways, because there may be a one to many mapping
      between NAPI contexts and network devices (SKY2 is one example).
      
      We also want to get rid of this because it's an extra atomic in the
      NAPI paths, and also because it is one of the last instances where the
      NAPI interfaces care about net devices.
      
      The one remaining netdev detail the NAPI stuff cares about is the
      netif_running() check which will be killed off in a subsequent
      changeset.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bdb95b17
    • A
      pl2303: Fix mode switching regression · bf5e5834
      Alan Cox 提交于
      Cleaning out all the incorrect 'no change made' checks for termios
      settings showed up a problem with the PL2303. The hardware here seems to
      lose sync and bits if you tell it to make no changes. This shows up with
      a real world application.
      
      To fix this the driver check for meaningful hardware changes is restored
      but doing the tests correctly and as a tty layer function so it doesn't
      get duplicated wrongly everywhere if other drivers turn out to need it.
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Tested-by: NMirko Parthey <mirko.parthey@informatik.tu-chemnitz.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bf5e5834
新手
引导
客服 返回
顶部