Re: Problem with commit deda2e81961e96be4f2c09328baca4710a2fd1a0

From: Jason Wessel
Date: Fri Aug 13 2010 - 07:54:14 EST


On 08/13/2010 02:30 AM, john stultz wrote:
> On Thu, 2010-08-12 at 22:17 -0500, Larry Finger wrote:
>
>> On 08/12/2010 03:52 PM, john stultz wrote:
>>
>>> Ugh. I'm surprised it picks *this* loop to optimize instead of the
>>> similar one right above. I'm guessing its the local raw_nsecs value, but
>>> whatever. Also surprised Jason's testing didn't hit this issue, but its
>>> probably a gcc version thing.
>>>
>>> Regardless, I clearly need to give i386 more love in my testing.
>>> My profuse apologies.
>>>
>>> As suggested by Linus, here's the do_div explicit version. It builds ok
>>> on i386 & x86_64, but I have not yet tested it.
>>>
>>> Larry, Jason: Could you verify it works for you (and avoids the original
>>> issue)?
>>>
>> This one builds for me with both compilers. It appears to run OK. As to the
>> original issue - I don't think I ever saw the problem. I'll leave that question
>> for Jason.
>>
>
> Thanks for the testing!
>
> I also managed to trigger the link issue with a 64bit gcc-4.3 cross
> compiling to 32bit. However both 32bit and 64bit gcc-4.4 didn't trigger
> the link issue, so it looks like its fixed in gcc.
>
> Regardless, after my own testing, the change looks good to me. Raw time
> is accumulating properly relative to monotonic time.
>
> Assuming Jason has no complaints it should be able to be pushed in.
>
>

No complaints here. The edge case remains solved on the low MHZ 32 bit
system.

The reason I never saw any problem in all my test configurations was
that gcc 4.4 is the oldest compiler I have in any of the configurations
I am using. I could have been more specific in my original mail on the
subject but it was tested with a 32bit cross compiler as well as a 64bit
cross compiler.

Many thanks to all who helped draw this odd ball case to closure.

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/