This has been reported by others on different hardware, so I'm beginning
to think this is a problem in the driver.
-corey
On 02/09/2011 07:48 AM, mika.lansiri...@stonesoft.com wrote:
> Hello,
>
> We noticed recently that ipmitool started randomly having problems when we
> upgraded the kernel from 2.6.32.(28) to 2.6.37. For example:
>
> # ipmitool sdr
> Unable to obtain SDR reservation
> Unable to open SDR for reading
>
> And at the same time dmesg was populated with these kinds of messages:
> [ 1248.568274] IPMI message handler: BMC returned incorrect response,
> expected netfn b cmd 22, got netfn b cmd 20
> [ 1248.570735] IPMI message handler: BMC returned incorrect response,
> expected netfn 7 cmd 35, got netfn b cmd 22
> [ 2035.155582] IPMI message handler: BMC returned incorrect response,
> expected netfn b cmd 22, got netfn b cmd 20
> [ 2459.722198] IPMI message handler: BMC returned incorrect response,
> expected netfn b cmd 22, got netfn b cmd 20
>
> The command was many times successful without any problems, but every now
> and then (quite often) the above problems were seen. The ipmitool used is
> from debian lenny: ipmitool version 1.8.9 and the motherboard of the
> machine is Supermicro X8DTI-F.
>
>
> As it looked like the problem is in the kernel, I started to revert
> possible commits concerning ipmi, and indeed find out that this is the one
> after which it started to fail:
>
> commit 3326f4f2276791561af1fd5f2020be0186459813
> Author: Matthew Garrett<m...@redhat.com>
> Date: Wed May 26 14:43:49 2010 -0700
>
> ipmi: reduce polling
>
> We can reasonably alter the poll rate depending on whether we're
> performing a transaction or merely waiting for an event.
>
>
>
> And the parts in that commit, which should be reverted to make it stable
> again are:
>
> @@ -899,13 +899,10 @@ static void sender(void *send_info,
> printk("**Enqueue: %d.%9.9d\n", t.tv_sec, t.tv_usec);
> #endif
>
> mod_timer(&smi_info->si_timer, jiffies + SI_TIMEOUT_JIFFIES);
>
> - if (smi_info->thread)
> - wake_up_process(smi_info->thread);
> -
> if (smi_info->run_to_completion) {
> /*
> * If we are running to completion, then throw it in
> * the list and run transactions until everything is
> * clear. Priority doesn't matter here.
> @@ -1022,12 +1019,10 @@ static int ipmi_thread(void *data)
> &busy_until);
> if (smi_result == SI_SM_CALL_WITHOUT_DELAY)
> ; /* do nothing */
> else if (smi_result == SI_SM_CALL_WITH_DELAY&& busy_wait)
> schedule();
> - else if (smi_result == SI_SM_IDLE)
> - schedule_timeout_interruptible(100);
> else
> schedule_timeout_interruptible(1);
> }
> return 0;
> }
>
>
>
>
> Please, let me know if you need any additional assistance regarding the
> problem.
>
>
>
> Best regards,
> Mika Länsirinne
>
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Ipmitool-devel mailing list
> Ipmitool-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
