linux.git/drivers/char/ipmi, branch v2.6.15

[PATCH] IPMI oops fix

2005-12-15T22:22:45+00:00

While doing some testing I discovered that if the BIOS on a board does not
properly setup the DMI information it leads to a panic in the IPMI code.

The panic is due to dereferencing a pointer which is not initialized.  The
pointer is initialized in port_setup() and/or mem_setup() and used in
init_one_smi() and cleanup_one_si(), however if either port_setup() or
mem_setup() return ENODEV the pointer does not get initialized.

Signed-off-by: Paolo Galtieri 
Acked-by: Corey Minyard 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ipmi: fix panic generator ID

2005-12-12T16:57:45+00:00

The IPMI specifcation says the generator ID is 0x20, but that is for bits
7-1.  Bit 0 is set to specify it is a software event.  The correct value is
0x41.  Without this fix, panic events written into the System Event Log
appear to come from an "unknown" generator, rather than from the kernel.

Signed-off-by: Jordan Hargrave 
Signed-off-by: Matt Domsch 
Acked-by: Corey Minyard 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ipmi: missing NULL test for kthread

2005-11-18T15:49:45+00:00

On IPMI systems with BT interfaces, we don't start the kernel thread, so
smi_info->thread is NULL.  Test for NULL when stopping the thread, because
kthread_stop() doesn't, and an oops ensues otherwise.

Signed-off-by: Matt Domsch 
Acked-by: Corey Minyard 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ipmi: bump-driver-version

2005-11-15T16:59:19+00:00

Lots of good changes to the driver lately that userspace will care about
the version of the driver.  Bump the version from 36.0 to 38.0 to be higher
than 37 that the 2.4 driver came out with a few weeks ago which doesn't
have all the same changes.

Signed-off-by: Matt Domsch 
Signed-off-by: Corey Minyard 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ipmi: fix inconsistent spinlock usage

2005-11-11T17:23:31+00:00

Part of a patch was accidentally reverted, this corrects an
inconsistent spinlock use in the IPMI message handler.

Signed-off-by: Hironobu Ishii 
Signed-off-by: Corey Minyard 
Signed-off-by: Linus Torvalds

[PATCH] ipmi: fix watchdog timeout panic handling

2005-11-07T15:53:45+00:00

If a panic came from the IPMI watchdog pretimeout and that was reported via
an NMI, it would also be reported via the standard IPMI flags, which would
get picked up when reporting panic events and cause another panic.  This
adds an atomic to avoid calling panic twice.

Signed-off-by: Corey Minyard 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ipmi: use rcu lock for using command receivers

2005-11-07T15:53:45+00:00

Use rcu_read_lock for the cmd_rcvrs list, since that was what what
intended, anyway.  This means that all the users of the cmd_rcvrs_lock are
tasks, so the irq disables are no longer required for that lock and it can
become a semaphore.

Signed-off-by: Corey Minyard 
Acked-by: "Paul E. McKenney" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ipmi: use kthread API

2005-11-07T15:53:45+00:00

Convert ipmi driver thread to kthread API, only sleep when interface is
idle.

Signed-off-by: Matt Domsch 
Cc: Corey Minyard 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ipmi: add timer thread

2005-11-07T15:53:44+00:00

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: Matt Domsch 
Signed-off-by: Corey Minyard 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ipmi: kcs error0 delay

2005-11-07T15:53:44+00:00

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: Matt Domsch 
Signed-off-by: Corey Minyard 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds