1. 01 6月, 2006 1 次提交
  2. 20 4月, 2006 1 次提交
  3. 01 4月, 2006 3 次提交
  4. 28 3月, 2006 1 次提交
    • A
      [PATCH] Notifier chain update: API changes · e041c683
      Alan Stern 提交于
      The kernel's implementation of notifier chains is unsafe.  There is no
      protection against entries being added to or removed from a chain while the
      chain is in use.  The issues were discussed in this thread:
      
          http://marc.theaimsgroup.com/?l=linux-kernel&m=113018709002036&w=2
      
      We noticed that notifier chains in the kernel fall into two basic usage
      classes:
      
      	"Blocking" chains are always called from a process context
      	and the callout routines are allowed to sleep;
      
      	"Atomic" chains can be called from an atomic context and
      	the callout routines are not allowed to sleep.
      
      We decided to codify this distinction and make it part of the API.  Therefore
      this set of patches introduces three new, parallel APIs: one for blocking
      notifiers, one for atomic notifiers, and one for "raw" notifiers (which is
      really just the old API under a new name).  New kinds of data structures are
      used for the heads of the chains, and new routines are defined for
      registration, unregistration, and calling a chain.  The three APIs are
      explained in include/linux/notifier.h and their implementation is in
      kernel/sys.c.
      
      With atomic and blocking chains, the implementation guarantees that the chain
      links will not be corrupted and that chain callers will not get messed up by
      entries being added or removed.  For raw chains the implementation provides no
      guarantees at all; users of this API must provide their own protections.  (The
      idea was that situations may come up where the assumptions of the atomic and
      blocking APIs are not appropriate, so it should be possible for users to
      handle these things in their own way.)
      
      There are some limitations, which should not be too hard to live with.  For
      atomic/blocking chains, registration and unregistration must always be done in
      a process context since the chain is protected by a mutex/rwsem.  Also, a
      callout routine for a non-raw chain must not try to register or unregister
      entries on its own chain.  (This did happen in a couple of places and the code
      had to be changed to avoid it.)
      
      Since atomic chains may be called from within an NMI handler, they cannot use
      spinlocks for synchronization.  Instead we use RCU.  The overhead falls almost
      entirely in the unregister routine, which is okay since unregistration is much
      less frequent that calling a chain.
      
      Here is the list of chains that we adjusted and their classifications.  None
      of them use the raw API, so for the moment it is only a placeholder.
      
        ATOMIC CHAINS
        -------------
      arch/i386/kernel/traps.c:		i386die_chain
      arch/ia64/kernel/traps.c:		ia64die_chain
      arch/powerpc/kernel/traps.c:		powerpc_die_chain
      arch/sparc64/kernel/traps.c:		sparc64die_chain
      arch/x86_64/kernel/traps.c:		die_chain
      drivers/char/ipmi/ipmi_si_intf.c:	xaction_notifier_list
      kernel/panic.c:				panic_notifier_list
      kernel/profile.c:			task_free_notifier
      net/bluetooth/hci_core.c:		hci_notifier
      net/ipv4/netfilter/ip_conntrack_core.c:	ip_conntrack_chain
      net/ipv4/netfilter/ip_conntrack_core.c:	ip_conntrack_expect_chain
      net/ipv6/addrconf.c:			inet6addr_chain
      net/netfilter/nf_conntrack_core.c:	nf_conntrack_chain
      net/netfilter/nf_conntrack_core.c:	nf_conntrack_expect_chain
      net/netlink/af_netlink.c:		netlink_chain
      
        BLOCKING CHAINS
        ---------------
      arch/powerpc/platforms/pseries/reconfig.c:	pSeries_reconfig_chain
      arch/s390/kernel/process.c:		idle_chain
      arch/x86_64/kernel/process.c		idle_notifier
      drivers/base/memory.c:			memory_chain
      drivers/cpufreq/cpufreq.c		cpufreq_policy_notifier_list
      drivers/cpufreq/cpufreq.c		cpufreq_transition_notifier_list
      drivers/macintosh/adb.c:		adb_client_list
      drivers/macintosh/via-pmu.c		sleep_notifier_list
      drivers/macintosh/via-pmu68k.c		sleep_notifier_list
      drivers/macintosh/windfarm_core.c	wf_client_list
      drivers/usb/core/notify.c		usb_notifier_list
      drivers/video/fbmem.c			fb_notifier_list
      kernel/cpu.c				cpu_chain
      kernel/module.c				module_notify_list
      kernel/profile.c			munmap_notifier
      kernel/profile.c			task_exit_notifier
      kernel/sys.c				reboot_notifier_list
      net/core/dev.c				netdev_chain
      net/decnet/dn_dev.c:			dnaddr_chain
      net/ipv4/devinet.c:			inetaddr_chain
      
      It's possible that some of these classifications are wrong.  If they are,
      please let us know or submit a patch to fix them.  Note that any chain that
      gets called very frequently should be atomic, because the rwsem read-locking
      used for blocking chains is very likely to incur cache misses on SMP systems.
      (However, if the chain's callout routines may sleep then the chain cannot be
      atomic.)
      
      The patch set was written by Alan Stern and Chandra Seetharaman, incorporating
      material written by Keith Owens and suggestions from Paul McKenney and Andrew
      Morton.
      
      [jes@sgi.com: restructure the notifier chain initialization macros]
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NChandra Seetharaman <sekharan@us.ibm.com>
      Signed-off-by: NJes Sorensen <jes@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e041c683
  5. 27 3月, 2006 2 次提交
    • C
      [PATCH] ipmi: add full sysfs support · 50c812b2
      Corey Minyard 提交于
      Add full driver model support for the IPMI driver.  It links in the proper
      bus and device support.
      
      It adds an "ipmi" driver interface that has each BMC discovered by the
      driver (as a device).  These BMCs appear in the devices/platform directory.
       If there are multiple interfaces to the same BMC, the driver should
      discover this and will only have one BMC entry.  The BMC entry will have
      pointers to each interface device that connects to it.
      
      The device information (statistics and config information) has not yet been
      ported over to the driver model from proc, that will come later.
      
      This work was based on work by Yani Ioannou.  I basically rewrote it using
      that code as a guide, but he still deserves credit :).
      
      [bunk@stusta.de: make ipmi_find_bmc_guid() static]
      Signed-off-by: NCorey Minyard <minyard@acm.org>
      Signed-off-by: NYani Ioannou <yani.ioannou@gmail.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      50c812b2
    • C
      [PATCH] ipmi: add generic PCI handling · b0defcdb
      Corey Minyard 提交于
      Modify the PCI hanling code for the IPMI driver to use the new method of
      tables and registering, and adds more generic PCI handling for IPMI.
      Unfortunately, this required a rather large rework of the way the driver
      did detection so it would be more event-driven.
      
      [bunk@stusta.de: make a struct static]
      Signed-off-by: NCorey Minyard <minyard@acm.org>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b0defcdb
  6. 04 2月, 2006 1 次提交
  7. 02 2月, 2006 1 次提交
  8. 12 1月, 2006 1 次提交
  9. 16 12月, 2005 1 次提交
  10. 18 11月, 2005 1 次提交
  11. 07 11月, 2005 6 次提交
    • M
      [PATCH] ipmi: use kthread API · e9a705a0
      Matt Domsch 提交于
      Convert ipmi driver thread to kthread API, only sleep when interface is
      idle.
      Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
      Cc: Corey Minyard <minyard@acm.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e9a705a0
    • C
      [PATCH] ipmi: add timer thread · a9a2c44f
      Corey Minyard 提交于
      We must poll for responses to commands when interrupts aren't in use.  The
      default poll interval is based on using a kernel timer, which varies with HZ.
      For character-based interfaces like KCS and SMIC though, that can be way too
      slow (>15 minutes to flash a new firmware with KCS, >20 seconds to retrieve
      the sensor list).
      
      This creates a low-priority kernel thread to poll more often.  If the state
      machine is idle, so is the kernel thread.  But if there's an active command,
      it polls quite rapidly.  This decrease a firmware flash time from 15 minutes
      to 1.5 minutes, and the sensor list time to 4.5 seconds, on a Dell PowerEdge
      x8x system.
      
      The timer-based polling remains, to ensure some amount of responsiveness even
      under high user process CPU load.
      
      Checking for a stopped timer at rmmod now uses atomics and del_timer_sync() to
      ensure safe stoppage.
      Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
      Signed-off-by: NCorey Minyard <minyard@acm.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a9a2c44f
    • C
      [PATCH] ipmi: kcs error0 delay · c3e7e791
      Corey Minyard 提交于
      BMCs can get into ERROR0 state while flashing new firmware, particularly while
      the BMC is erasing the next flash block, which may take a just under 2 seconds
      on a Dell PowerEdge 2800 (1.75 seconds typical), during which time the
      single-threaded firmware may not be able to process new commands.  In
      particular, clearing OBF may not take effect immediately.
      
      We want it to delay in ERROR0 after clearing OBF a bit waiting for OBF to
      actually be clear before proceeding.
      
      This introduces a new return value from the LLDD's event loop,
      SI_SM_CALL_WITH_TICK_DELAY.  This means the calling thread/timer should
      schedule_timeout() at least 1 tick, rather than busy-wait.  This is a longer
      delay than SI_SM_CALL_WITH_DELAY, which is typically a 250us busy-wait.
      Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
      Signed-off-by: NCorey Minyard <minyard@acm.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c3e7e791
    • C
      [PATCH] ipmi: si start transaction hook · ea94027b
      Corey Minyard 提交于
      Some commands, on some system BMCs, don't respond at at all.  This is seen on
      Dell PowerEdge x6xx and x7xx systems with IPMI 1.0 BT controllers when a "Get
      SDR" command is issued, with a length field of 0x3A, which happens to be the
      length of about SDR entries.  If another length is passed, this command
      succeeds.
      
      This patch adds general infrastructure for receiving commands before they're
      passed down to the low-level drivers, such that they can be completed
      immediately, or modified, prior to being sent to ->start_transaction().
      Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
      Signed-off-by: NCorey Minyard <minyard@acm.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ea94027b
    • C
      [PATCH] ipmi: more dell fixes · d5a2b89a
      Corey Minyard 提交于
      Make SMIC driver ignore EVT_AVAIL and SMS_ATN bits in flags register, as
      they're used by systems management interrupts, not the host OS.
      
      Make the OEM0 Data Available handler work for pre-IPMI 1.5 systems from Dell
      too.
      
      Without these two fixes, PowerEdge 2650 and other similar systems with SMIC
      may hang a process (modprobe or anything using /dev/ipmi0).
      Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
      Signed-off-by: NCorey Minyard <minyard@acm.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d5a2b89a
    • C
      [PATCH] ipmi: various si cleanup · c4edff1c
      Corey Minyard 提交于
      A number of small changes for the various system interface drivers,
      consolidated from a number of patches from Matt Domsch.
      
      Clear B2H_ATN and drain the BMC message buffer on command timeout.  This
      prevents further commands from failing after a timeout.
      
      Add bt_debug and smic_debug module parameters, expose them in sysfs.  This
      lets you enable and disable debugging messages at runtime.
      
      Unsigned jiffies math in ipmi_si_intf.c causes a too-large value to be passed
      to ->event() after jiffies wrap-around.  The BT driver had caught this, but
      didn't know how to fix it.  Now all calls to ->event() use a sane value for
      time.
      
      Increase timeout for commands handed to the BT driver from 2 seconds to 5
      seconds.  This is necessary particularly when the previous command was a
      "Clear SEL", as that command completes, yet the BMC isn't really ready to
      handle another command yet.
      
      Silence BT debugging messages which were being printed on the console.
      
      Increase SMIC timeout form 1/10s to 2s.  This is needed on Dell PowerEdge 2650
      and PowerEdge 750 with ERA/O cards to allow commands to complete without
      timing out.
      
      Adds kcs_debug module param, to match behavior of BT and SMIC.  This also
      prevents messages from being sent to the console unless explicitly requested.
      Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
      Signed-off-by: NCorey Minyard <minyard@acm.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c4edff1c
  12. 11 9月, 2005 1 次提交
  13. 08 9月, 2005 5 次提交
  14. 01 9月, 2005 1 次提交
  15. 25 8月, 2005 1 次提交
  16. 28 7月, 2005 1 次提交
  17. 04 5月, 2005 1 次提交
  18. 01 5月, 2005 4 次提交
  19. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4