Re: [Ipmitool-devel] ipmitool breakage with kernel 2.6.37

[Corey M. <mi...@ac...>]

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, Mik...@st... 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<mj...@re...>
> 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
> Ipm...@li...
> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel