Re: regression in ktime.h circa 3.16.0-rc5+ breaks lirc irsend, bad commit 166afb64511

2015-05-01 Thread John Stultz
On Fri, May 1, 2015 at 11:29 AM, Nicolas Pitre wrote: > On Fri, 1 May 2015, John Stultz wrote: > >> So yea. I see the issue now. The ktime_divns() function uses do_div >> which is an unsigned divide. So negative numbers look like large >> numbers, and it doesn't do sign-extension, so when it divid

Re: regression in ktime.h circa 3.16.0-rc5+ breaks lirc irsend, bad commit 166afb64511

2015-05-01 Thread Nicolas Pitre
On Fri, 1 May 2015, John Stultz wrote: > So yea. I see the issue now. The ktime_divns() function uses do_div > which is an unsigned divide. So negative numbers look like large > numbers, and it doesn't do sign-extension, so when it divides we lose > the sign bit. That doesn't stop there. On 32-bi

Re: regression in ktime.h circa 3.16.0-rc5+ breaks lirc irsend, bad commit 166afb64511

2015-05-01 Thread John Stultz
On Fri, May 1, 2015 at 3:02 AM, Trevor Cordes wrote: > May 1 04:46:12 piles kernel: [ 356.838029] JDB: ktime_to_us: -20157485 -> > divns 18446744073689394 != old method: -20158 > > The last 2-3 or 3 groups of output I could produce on demand by stopping > mythbackend and running: > systemctl r

Re: regression in ktime.h circa 3.16.0-rc5+ breaks lirc irsend, bad commit 166afb64511

2015-05-01 Thread Trevor Cordes
On 2015-04-30 John Stultz wrote: > >From your description it does seem like some sort of edge case > >problem > w/ the 32bit ktime_divns(), but I don't see it right off, and I agree > with Alan to do both calculations and print out warn when that > happens. > > There's also not a ton of users of t

Re: regression in ktime.h circa 3.16.0-rc5+ breaks lirc irsend, bad commit 166afb64511

2015-04-30 Thread John Stultz
On Wed, Apr 29, 2015 at 9:27 PM, Trevor Cordes wrote: > Sorry for the top-posting; Josh Boyer suggested I re-mail this mail > from last month which didn't get any replies. I'm still having this > weird kernel bug affecting me and I've bisected it down to like 2-4 > lines of code. (I've thought m

Re: regression in ktime.h circa 3.16.0-rc5+ breaks lirc irsend, bad commit 166afb64511

2015-04-30 Thread One Thousand Gnomes
> > Obviously my patch isn't the real solution, the real solution is to > > make the new function calls use a consistent 64-bit type, or figure > > out what in my code path is calling these functions and check it for > > value sanity. I would be tempted to do both computations and print then input

Re: regression in ktime.h circa 3.16.0-rc5+ breaks lirc irsend, bad commit 166afb64511

2015-04-29 Thread Trevor Cordes
Sorry for the top-posting; Josh Boyer suggested I re-mail this mail from last month which didn't get any replies. I'm still having this weird kernel bug affecting me and I've bisected it down to like 2-4 lines of code. (I've thought more about my theory regarding unsigned/signed below and it's pr