Actually, I was thinking more of a change in the way a kernel function behaves. However, never having looked at the NUT code, I defer to anyone who has. I agree that the -D flag on the kernel routine "should" only affect timing.<br>
<br>FWIW, the discussion at:<br><br> <a href="http://osdir.com/ml/monitoring.nut.devel/2008-01/msg00038.html">http://osdir.com/ml/monitoring.nut.devel/2008-01/msg00038.html</a><br><br>may be relevant.<br><br>Dave<br><br>
<div class="gmail_quote">On Wed, Jan 12, 2011 at 10:13 PM, Charles Lepple <span dir="ltr"><<a href="mailto:clepple@gmail.com">clepple@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Jan 12, 2011, at 11:16 AM, Knight, Dave wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
My guess would be that there is some miscommunication between driver levels, perhaps a result of running a new nut with an old kernel (latest is 2.6-37)?<br>
</blockquote>
<br></div>
There is not much in NUT which would depend on new kernel features, especially when the problem is masked by enabling debug output on that same kernel version. (The debug flag shouldn't affect anything but timing, as far as USB is concerned.)<br>
</blockquote></div><br><br clear="all"><br>-- <br>"Ridicule is man's most potent weapon. <span> It’s hard to counterattack ridicule, and it infuriates<br> the opposition, which then reacts to your advantage.</span>"<br>
<br> Saul Alinsky, Marxist, Obama mentor<br><br>