Home of the Squeezebox™ & Transporter® network music players.
Page 4 of 12 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 120
  1. #31
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    801
    Quote Originally Posted by Steevee28 View Post
    Oh, note that _insertTimer is buggy in the same way: the condition if self.expires < timer.expires is also wrong in the wrapping-case and will temporarily put timer events into wrong order then.
    I would think that all these values are going to be lua "numbers", and, if I'm right that they are double floats, then they would not be subject to any wrapping in this context. Condition checking, of course, would give somewhat curious results after the jiffy timer wraps around.

    Subject to checking the detail, of course.

    Amusingly, as I was sitting next to my radio an hour and a half ago, it spontaneously rebooted. Unusually it was running on battery. I am not sure exactly when it was started, but not before 3 February. Running time could not have exceeded 2,140,560 seconds, or thereabouts.
    Last edited by mrw; 2020-02-28 at 10:17.

  2. #32
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    801
    I suppose that periodically rebooting itself might be a useful "designed in" feature. Not that I've come across it in the code.

    I used to ensure that my LMS restarted itself at reasonably regular intervals, to overcome apparent memory leakage and the like. Doesn't seem to be needed at present.

  3. #33
    Senior Member Steevee28's Avatar
    Join Date
    Feb 2010
    Location
    Mannheim, Germany
    Posts
    103
    Quote Originally Posted by mrw View Post
    I would think that all these values are going to be lua "numbers"
    This is irrelevant, since the source of the timer values is a 32bit integer. The problem is that the timer itself wraps around. See my post #26.
    1x Squeezebox Classic, 3x Radio, 1x Touch, LMS 7.9.1 running on ODROID-U3, Ubuntu 16.04 and I'm happy with it! :)

  4. #34
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    801
    Quote Originally Posted by Steevee28 View Post
    This is irrelevant, since the source of the timer values is a 32bit integer. The problem is that the timer itself wraps around. See my post #26.
    I am really rather aware of that. My comments were directed towards one test that might be undertaken in an attempt to initiate a "survey" of the issue. I'll not comment further.
    Last edited by mrw; 2020-02-28 at 10:59.

  5. #35
    Senior Member Steevee28's Avatar
    Join Date
    Feb 2010
    Location
    Mannheim, Germany
    Posts
    103
    Quote Originally Posted by mrw View Post
    I am really rather aware of that. My comments were directed towards one test that might be undertaken in an attempt to initiate a "survey" of the issue. I'll not comment further.
    Then I'm sorry. I got you wrong and I just saw that I accidentally skipped your sentence about the jiffy timer wrapping when I read your post. Of course, you're perfectly right.
    Last edited by Steevee28; 2020-02-28 at 11:54.
    1x Squeezebox Classic, 3x Radio, 1x Touch, LMS 7.9.1 running on ODROID-U3, Ubuntu 16.04 and I'm happy with it! :)

  6. #36
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    801
    Quote Originally Posted by Steevee28 View Post
    Then I'm sorry. I got you wrong
    And I posted at the end of a cranky day, and should have kept my keyboard silent. Apologies.

    Here is a point in the code at which Squeezeplay might "naturally" terminate itself:
    https://github.com/Logitech/squeezep...ework.lua#L350

    That might be good start point, survey-wise. I haven't looked further, but finding out if eventTask:resume() is returning false may throw some light.

  7. #37
    Senior Member Steevee28's Avatar
    Join Date
    Feb 2010
    Location
    Mannheim, Germany
    Posts
    103
    Quote Originally Posted by mrw View Post
    Here is a point in the code at which Squeezeplay might "naturally" terminate itself:
    https://github.com/Logitech/squeezep...ework.lua#L350
    That's also an interesting point and should be further investigated, but I still suppose the Watchdog to reset the device if it detects that the Jive UI is no longer alive.
    In fact, the UI main event loop you pointed to may completely cease to work in case of a wrapping of the timer.
    Let's imagine this:

    1. In Line 307, the "now" value received from the timer is shortly before the wrap.
    2. In Line 308, the calculated "framedue" is thus beyond the possible range of timer values (because, as you pointed out, Lua numbers can represent much bigger values than 32bit ints).
    3. Or, as an alternative, in Line 338, the "now" value received from the timer is after the wrap, thus a very small value.
    4. In Line 339, as a result, the condition "framedue <= now" can no longer become true!
    5. Thus, Line 353 is never reached and the "framedue" value will no longer be updated.
    6. As a result, no more UI events will be processed at all.

    Is it possible that this causes a Watchdog reset? How does the Watchdog process detect that the UI is still alive?


    Btw. I'm not 100% sure, but I also suppose that the tick timer (which is not based on a RTC), but instead on some high-performance timer, is not running at precise 1000Hz, thus there may be some minor discrepancies from the overflow interval of 24.855 days (or 49.71 days, respectively).
    Last edited by Steevee28; 2021-03-10 at 10:42. Reason: fixed syntax error
    1x Squeezebox Classic, 3x Radio, 1x Touch, LMS 7.9.1 running on ODROID-U3, Ubuntu 16.04 and I'm happy with it! :)

  8. #38
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    801
    Quote Originally Posted by Steevee28 View Post
    That's also an interesting point and should be further investigated, but I still suppose the Watchdog to reset the device if it detects that the Jive UI is no longer alive.
    The flow of control would take us here, which looks very much like a "quit" to me:
    https://github.com/Logitech/squeezep...eMain.lua#L422

    The consequence of that would be that Squeezeplay terminates. The watchdog will notice that and restart the device.

    There are, as you point out, many other possibilities that might occur.

    Both myself (and my Radios) are somewhat preoccupied with other matters at present. If I were investigating, I might be tempted to start by looking for a 'not running' state, and dumping relevant data to a persistent log file before the system restarts. Probably including a dump of the timer table. This could all be done within the existing lua script. I don't know that this approach would yield a result, certainly some patience would be required.
    Last edited by mrw; 2020-03-01 at 14:45.

  9. #39
    Senior Member Steevee28's Avatar
    Join Date
    Feb 2010
    Location
    Mannheim, Germany
    Posts
    103

    PROOF!!!! Timer overflow *IS* root cause of spontaneous reboots!

    Today, by chance, I experienced the proof:

    I logged into one of my Radios via SSH and queried the device uptime. The device uptime showed 24 days +19:15. It was 7:00pm.

    Some hours later, I noticed that the Radio was rebooted, because it showed the main menu instead of the clock.
    Again, I logged into the device and again queried the device uptime. The uptime now showed that the device must have rebooted at 8:16pm!

    This means that the reboot occured at a device uptime of 24 days +20:31. This is 24.855 days, corresponding to 2^31/1000/3600/24, thus corresponding to an overflow of a signed 32bit timer running at 1000Hz.

    So, as previously suspected, the Radios really perform 'spontaneous' reboots at a well-defined interval of 24.855 days, caused by wrapping of the jiffy timer.
    Please note that this timer is not based on a real-time clock, thus it is probably not running at precisely 1000Hz. This means that the reboot interval might be slightly different from device to device.
    Last edited by Steevee28; 2020-03-02 at 15:34.
    1x Squeezebox Classic, 3x Radio, 1x Touch, LMS 7.9.1 running on ODROID-U3, Ubuntu 16.04 and I'm happy with it! :)

  10. #40
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    6,778
    Quote Originally Posted by Steevee28 View Post
    Today, by chance, I experienced the proof:

    I logged into one of my Radios via SSH and queried the device uptime. The device uptime showed 24 days +19:15. It was 7:00pm.

    Some hours later, I noticed that the Radio was rebooted, because it showed the main menu instead of the clock.
    Again, I logged into the device and again queried the device uptime. The uptime now showed that the device must have rebooted at 8:16pm!

    This means that the reboot occured at a device uptime of 24 days +20:31. This is 24.855 days, corresponding to 2^31/1000/3600/24, thus corresponding to an overflow of a signed 32bit timer running at 1000Hz.

    So, as previously suspected, the Radios really perform 'spontaneous' reboots at a well-defined interval of 24.855 days, caused by wrapping of the jiffy timer.
    Please note that this timer is not based on a real-time clock, thus it is probably not running at precisely 1000Hz. This means that the reboot interval might be slightly different from device to device.
    Interesting. How do you query the uptime? I'll check mine.

    Sent from my Pixel 3a using Tapatalk

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •