Bugzilla – Bug 10296
SBC will reboot randomly
Last modified: 2009-09-08 09:32:17 UTC
On occasion, watchdog will kick in on the Controller, causing it to reboot. Logs do not show any event data that would precipitate an error to cause watchdog to reboot the controller. This happens most often when coming out of 'sleep' state. Started happening in r3191; more noticeable in r3476 Steps to reproduce: load r3476 to a controller place SBC on the desk and observe it. occasionally it will just reboot, or reboot when coming out of sleep
We need to look at getting this out as a hotfix. Dan: Please update the bug with feedback from support contacts.
Does this happen if the Audio Playback is enabled or disabled. Customer having this issue, have you EVER enabled the Audio Playback then disabled it.
James, As discussed in the bug meeting please test with: 1) Audio playback disabled (and reboot the controller after disabling) 2) Longer watchdog timer You can modify the watchdog timer value by editing SqueezeboxJiveApplet.lua. Using: vi /usr/share/jive/applets/SqueezeboxJive/SqueezeboxJiveApplet.lua Look for this block: -- watchdog timer self.watchdog = Watchdog:open() if self.watchdog then -- allow 30 seconds to boot self.watchdog:setTimeout(30) local timer = Timer(2000, -- 2 seconds function() -- 10 second when running if not self.watchdogRunning then self.watchdog:setTimeout(10) self.watchdogRunning = true end self.watchdog:keepAlive() end) timer:start() else log:warn("Watchdog timer is disabled") end And change the setTimeout(10) to setTimeout(30). This will length the watchdog timeout from 10 to 30 seconds. You can easily verify if the Controller has rebooted while your not watching by using 'uptime' in the serial console.
Memory is a frail thing - but I'm pretty sure this happened soon after 7.3 upgrade, and before playing with the audio. I have since played with audio, and recently have not had a reboot. I have had two total, not a major issue for me.
While I listen to Internet Radio, my controller reboots about 4 times when it was connected to SN did it all within 2 hours. I didn't use Audio Playback on my Controller when it reboots! I leaved it in the charge-cradle. Logs where empty Later on my Controller connected to my NAS and listen to Internet Radio and it never reboots (uptime 10 hours). Controller: Jive 7.3r3437 Player: Transporter FW 69 In my situation it's look like somewhere related to SN!
So far I have only seen this with a controller connected to SN. Changing the watchdog timer does not change the behavior. Audio Playback on or off does not change the behavior. The type of stream does not change the behavior, I had it happen when streaming WMA or MP3 content. Sleep is not a factor, as I have seen it in and out of the charging stand. Attached player does not matter, this has happened with SBR and Classic as player. What logs on the Controller should I turn on and monitor?
I don't know if this is useful because it only happened to me twice when 7.3 was still beta and it hasn't happened (that I have seen) in a couple of weeks. I was not connected to SN when it happened to me and the Controller was out of the cradle both times, sitting idle. The Boom it was controlling was playing local MP3 files. I heard the startup sounds and noticed it was rebooting. When it happened the second night in a row, I updated to the latest nightly and it didn't happen again. It was probably around the first few days of Decemeber.
Changing target to next release
I am experiencing what is probably a variant of this problem. For some time I have occasionally noticed that my SBC has been spontaneously restarting when it was left by itself (e.g. on a table - not in cradle) for an extended period of time. When I was close by, the situation was pretty obvious, because I could hear its little startup jingle. Now I have found out that what actually seems to happen is that the SBC, after having been idle for an extended period of time, prepares to go into sleep mode, but instead of entering sleep mode, it performs a complete restart! I have confirmed this by commanding it into sleep mode by activating the /Settings/Advanced/Turn Off/Sleep function, and this causes exactly the same restart to happen, instead of sleep mode. I have two SB Duets, and both Controllers do this in identical fashion. I have recently updated to the latest version 7.3 (r.3476), but the spontaneous SBC restarts also happened with version 7.2.1, although maybe not as consistenly as with v.7.3. However, for v.7.2.1 I did not attempt to command it into sleep mode, so I dont know whether it was exactly the same. I have tried to enable and use (and then disable again!) player mode on one of my two SBCs, but not for the other, and the two SBCs both have the same restart problem, so I can't confirm any connection with enabling player mode. For v.7.3 (r.3476) this spontaneous restart problem means that the SBC never reaches sleep mode, so this also affects the battery power consumption. The SBC with v.7.3 can now only survive approx 10 hours outside the cradle in idle state, whereas earlier versions could survive at least a couple of days with occasional use, because these versions actually reached sleep mode. I have not noticed the reduced idle survival time in v.7.2.1. Whereas the spontanous restarts is a nuisance, the reduced idle lifetime is a severe nuisance, and I am considering falling back to the earlier version 7.2.1.
James & Ross: Can you please verify the battery life issue and open a separate bug for it?
My controller just rebooted spontaneously. I had paused a track a few minutes before. I do NOT have audio enabled. Running latest 7.3.1.
A possibly unrelated anomaly in the above. I noticed that the restarted controller had an empty extras menu. Completely blank - nothing at all. Reboot restored the extras menu.
I've found that my SBC reboots itself if I attempt to play an internet radio stream after the SBC hasn't been used for an extended time (roughly 24 hours). This has happened when the SBC has been left in the charging cradle and when I've left it out of the cradle and it's been in sleep mode. When I play the stream the SBC seems to hang for a few seconds, reboots itself and then attempts to play the stream immediately on reconnection to my server. The stream then appears to be choppy and I have to stop and restart it. After that it's fine.
I was using the audio playback on the Controller with SC7.3 beta, and Internet radios were working fine. Now that I use it with the stable SC7.3 it reboots every time I want to play a radio. It'll go up to "getting stream info" and reboots. Playing local music, mp3 mainly, works fine. It does this with the 2 Controllers I have at home.
My Controller also rebooted randomly last night (I installed 7.3.1 yesterday). I'd been using it before I went to bed and left it next to the bed when I'd finished (not in the charging cradle) for it to go into sleep mode. About 45 minutes to an hour later, while I was trying to fall asleep, I heard its startup jingle, looked across and saw that it had just rebooted itself.
I also have this problem; consistently, whenever the device tries to sleep (either automatically, or when I instruct it to), it reboots itself. - Tim
1) I have now updated to SC 7.3.1, but after the update I can see that the controller still indicates version 7.3r3476 (unchanged from SC 7.3), so I assume there has not been any changes to the Controller this time. I checked, and the problem I reported in comment #9 is indeed still present. (Incidentally, even though the Controller firmware was unchanged version, it still performed a firmware update - Strange! So were there any changes or not?) 2) But after the update to SC 7.3.1, I soon noticed the Controller had now gained a new restart problem (despite unchanged Controller firmware version): Now the Controller also consistently reboots after it has completed playing a playlist - but again only when the controller is left outside its cradle, not when placed in the cradle. This also happens if the playlist only contains one single track, so it is easily reproduced. Since this new problem relates to playing the actual music, the Squeezecenter is also involved, and it may be a timing issue (allowing the Watchdog to kick in) so some mere info about my system is warranted: - Squeezecenter runs on a 3 year old AMD-based laptop with WinXP SP3 and with the music placed on a separate USB2 harddisk. So timing or race-condition issues could be a potential cause, I guess. - I have two SB Duets, but I don't run them synchronized, so it does not seem related to player synchronization. And only one of the players were being actively playing at the time.
I have now found out that the Controller reboot (after completing playlist) problem I reported in my comment #17 apparently only happens when the Controller has (completely) dimmed its screen. I kept the Controller from dimming by moving it occasionally, and then it survived without rebooting after completing playing a playlist!!! I then again tried with the same playlist but allowing its screen to dim completely => again it reboots after completing the playlist. This is consistently reproducable (at least on my own SB Duet's). I also tried with different "now playing" screen saver art sizes (normally I use large size), but changing the artwork size makes no difference.
I tried this on 7.3.2. I added a single track to the playlist, skipped to near the end, and let it play. Controller dimmed, track ended, NO reboot. So there's something more to reproduce this. But then, I haven't seen reboots at all in a while. Can't correlate that to any particular change.
This happened to me to now, i'll vote for it, only happened twice.
This is not random anymoore. It's happens almost everytime it should have woken up from it's most sleepy state ? I pick up my SBC the circles starts to spin, display freezes turns black bingo! reboot ! my sbc is on 7.4r3592 there is no log ? that i can find i put in an SD card with an log dir on it but i seldom gets anything at all and noting in this case.
Created attachment 4559 [details] messages I manually copied my messages file from /var/log in the SBC Hopefully its something in it
Richard: Have we just upped the watchdog timeout in the current release so that we can see if this is the problem? It wont' fix the root issue, but may treat the symptom...
I am having trouble recreating this one. I have increased the stack size of the threads and increased the watchdog timer interval in 7.3.2 r3728/r3729. These were both changes made for 7.3 that may have triggered this problem. Please report back if this problem is fixed after upgrading to this firmware.
(In reply to comment #17) > 2) But after the update to SC 7.3.1, I soon noticed the Controller had now > gained a new restart problem (despite unchanged Controller firmware version): > Now the Controller also consistently reboots after it has completed playing a > playlist - but again only when the controller is left outside its cradle, not > when placed in the cradle. This also happens if the playlist only contains one > single track, so it is easily reproduced. > FWIW I just watched my Controller reboot while sitting in the cradle. I will try to read up on capturing log files and bumping the firmware tomorrow.
(In reply to comment #21) > This is not random anymoore. > > It's happens almost everytime it should have woken up from it's most sleepy > state ? > I pick up my SBC > the circles starts to spin, display freezes turns black bingo! reboot ! > > my sbc is on 7.4r3592 > > there is no log ? that i can find i put in an SD card with an log dir on it but > i seldom gets anything at all and noting in this case. > I think this may be the key, I put my SBC into sleep mode: Settings > Advanced > Turn Off > Sleep -- leave SBC off for >5 minutes When coming out of sleep mode, CPU usages is very high, controller is very lagged, attempting to play a stream will cause this player (and all others attached to the same SN account) to force reconnect.
I can still consistently cause a reboot simply by telling the SBC to sleep. This is in the very latest firmware (as of January 12th, 2009 - I don't have the device at hand, so I can't name the firmware version; however, the controller asked to be updated on that date, and did so).
Back-ported timer changes from squeezeplay 7.4 in 7.3 r3852. This may help address the random reboots. I am still investigating another possible problem.
Hmm i got it to reebot just now. Actually after the server restarted after an upgrade ? and SBC was sleeping before that, could be coincident. but is audio playback involved ? iI reenabled this feature and now i had another reboot ?
(In reply to comment #29) > Hmm i got it to reebot just now. > > but is audio playback involved ? I reenabled this feature and now i had > another reboot ? > What firmware version is on your SBC?
7.4 r3822
3476 continues to reboot with audio disabled. It was once enabled, but not for a long time.
Richard - where is this backported firmware kept? It is not in the usual place.
All i can say is that i had no reboots with 3665 where the option to choose audio (beta) was missing and it had no effect sound Either. Somehow the "defects" in 3665 must have done something.
QA to retest with r3856 & 7.3.2
(In reply to comment #26) > > When coming out of sleep mode, CPU usages is very high, controller is very > lagged, attempting to play a stream will cause this player (and all others > attached to the same SN account) to force reconnect. > This is a different error, please reference bug 10774
Created attachment 4678 [details] serial error log Just had a reboot on 7.3 r3856 - see attached log, near the end of the log. SBC attached to SBR, SC 7.3.2 r24695, out of cradle, no playlist, appears to have gone to sleep, then BusyBox kicked in and rebooted.
I noticed that the watchdog timer was back to 10, not 30 (r3856) I'll repeat the test with watchdog at 30
Would anyone having this issue please try out SC 7.3.3, it will include a new Jive Firmware which should hopefully address this issue. Please visit http://downloads.slimdevices.com/nightly/latest/7.3/ then download build 24731 or later. Report back to this bug if you still see the issue. Include the steps to reproduce the error, what the controller was doing before the reboot. Were you connected to SqueezeCenter or SqueezeNetwork What player was your SBC controlling Did you have Audio Playback enabled at the time of the reboot Did you have Audio Playback enabled or disabled at any time Provide a map of your network topology. I.E. router/hub/switch, make/model/revision Thank you
for audio, does enabled any time mean anytime since the last firmware install, anytime since the last complete reset, or anytime period?
Anytime after the upgrade of firmware for this test cycle
I just installed debian testing, which is 7.3.3 24731. In cache I see jive_7.3_r3476.bin which has been current for a while, and jive_7.3_r3856.bin.tmp My controller is at 3476 and is not offering an upgrade.
Ignore last - it just took SC a while to get its act together.
So... how did you get the SBC to update its firmware? I installed the new SqueezeCenter build as directed, the SqueezeBox required a new firmware and got it, but the SBC has yet to say it needs to update, and it's been on for awhile now. Anyone? Where is the firmware so I can update it manually? Current firmware version is: 7.3.r3698 - Tim
Ah wait, I see it in the cache there. SC still isn't providing it to the SBC, however. I'll take the manual route, if a reboot of the server doesn't fix it. - Tim
Huh. Okay, even though I had installed the new SC, and it had started, I had to stop it and start it again to get the SBC to be told to update its firmware. Tweaky tweaky tweaky. - Tim
Okay, I tried the new SBC firmware, SB firmware and SC version you pointed to in this thread. After everything was updated, I told the SBC to sleep (ie. Turn Off->Sleep). The SBC said "Sleeping" with the circles going around, then "Please Wait", and it immediately shut down, and then reboot itself. The difference with THIS firmware is, instead of rebooting after the above messages (or at least, I remembered the cirles going around, not the particular messages displayed), is that it shut down, stayed shut down for some seconds, and THEN rebooted. Here's the info you requested: -------------------------- What the controller was doing before the reboot: Nothing at all, it was in a quiescent state. Were you connected to SqueezeCenter or SqueezeNetwork: SqueezeCenter What player was your SBC controlling: SB3 Did you have Audio Playback enabled at the time of the reboot: No Did you have Audio Playback enabled or disabled at any time: No Network Topology: DSL->Wireless Router (DLink DIR-655; Hardware rev. A3, Firmware 1.21; contains gigabit switch) Router->Separate Gigabit Switch (DLink DGS-2208, unknown hardware/firmware rev - it doesn't say on it) Router via WiFi->(SB3, SBC, sometimes laptop) Switch->(SC Server Machine, Duet, QNAP NAS (usually off), Desktop, Laptop Dock)
By the way, addendum to the above - when I say the controller was in a quiescent state, I mean, it wasn't in the middle of some complex process when I put it to sleep. I'm not sure what you mean "what it was doing"... it had been told to go to sleep. - Tim
Sorry, another addendum. Switch hardware rev is "C1". I hadn't known where to look. :-) - Tim
Tim, could you try a factory reset. Does that make things better?
Richard... Do you mean to try a factory reset to test if that fixes the reboots? - Tim
Okay Richard, I did a factory reset on the SBC. Same behavior, reboot upon sleep as just described. - Tim
Thanks, that rules out one possibility. I'll be working with James on this later today.
I just tried the same, and it works for me. turnoff->sleep causes the sleeping circles, and then the screen goes dark. I think there is a slight sound, like when an amp turns off, just after the screen goes dark. It stays dark until I pick the unit up. Then the please wait circles, and eventually I'm back in the turnoff screen with sleep selected. My controller is associated with a netgear wpn824v3 which is also the router. There is a second switch/access point in my house, a Linksys WRT54GV2 New news. I woke the controller, brought it into the area of my house where the second AP is strong, and went to wireless network to get it to reassociate. It did associate, according to the AP, but rather than bring up the network choice screen, it spontaneously rebooted! After the reboot, wireless network brings up the choice screen. I can't reproduce this. Except for the above, sleep has worked about 10 tries in both locations. I HAVE experienced random reboots in the past, but I don't use the sleep function, so I don't know if that ever would have failed. None yet with the new firmware, but I've hardly used it.
http://forums.slimdevices.com/showthread.php?t=52702 Garym999 from the forums is seeing this with r3856.
By the way, after I installed the new firmware (or possibly only after I restored to factory defaults), the unit no longer responds to movement. If the screen goes blank when left alone for awhile, when I pick it up and shake it, for example, it does nothing. I have to move the scroll wheel or press a button for the screen to come up again. - Tim
(In reply to comment #56) > By the way, after I installed the new firmware (or possibly only after I > restored to factory defaults), the unit no longer responds to movement. If the > screen goes blank when left alone for awhile, when I pick it up and shake it, > for example, it does nothing. I have to move the scroll wheel or press a > button for the screen to come up again. > > - Tim > It should display what ever you have chosen in: Settings > Screen > Screensavers > When Stopped I.E. Analog Clock (default) Shaking it will wake up the player, then display what you have set there. Pressing a Key will take you out of that screen and back to the previous menu item, before the controller went to sleep.
Created attachment 4696 [details] Random reboots Suffering random reboots some times right the way thru to a working system in this case to a white logitech logo on a black screen at which point we see a lock up which has to be reset with a battery removal.
(In reply to comment #58) > Created an attachment (id=4696) [details] > Random reboots > > Suffering random reboots some times right the way thru to a working system in > this case to a white logitech logo on a black screen at which point we see a > lock up which has to be reset with a battery removal. > Gary: thank you for the log, it show a kernel error which I think needs further investigation
Tim can you provide a similar log please?
Would that just be /var/log/syslog (I'm guessing, I don't have my controller with me at the moment). - Tim
Create a directory 'log' on an SD card and put it in the Controller, the logs will be in there.
Created attachment 4703 [details] SBC system log for developers to look into sleep-triggered reboot The included log file was from my SBC when I: 1. Started the SBC with no SqueezeCenter available (didn't bother to turn it on, as the SBC reboot happened anyway) 2. Told the SBC to stop trying to connect to SB3 3. Told the SBC to sleep 4. SBC rebooted itself spontaneously 5. I turned SBC off Reboot appears to happen immediately after this block of the log: Jan 1 00:01:00 SqueezeboxController user.info jive: (SqueezeboxJiveApplet.lua:626) - setPowerState=dimmed acpower=false Jan 1 00:01:00 SqueezeboxController user.info jive: (SqueezeboxJiveApplet.lua:1055) - Set CPU speed 200000 Jan 1 00:01:01 SqueezeboxController user.info jive: (SqueezeboxJiveApplet.lua:1213) - Sleep begin Jan 1 00:01:01 SqueezeboxController user.info jive: (SqueezeboxJiveApplet.lua:626) - setPowerState=suspend acpower=false Jan 1 00:01:01 SqueezeboxController user.info jive: (SqueezeboxJiveApplet.lua:1055) - Set CPU speed 50000 Jan 1 00:01:01 SqueezeboxController user.info jive: (SqueezeboxJiveApplet.lua:706) - Store effect volume 33 Jan 1 00:01:01 SqueezeboxController user.info jive: (SqueezeboxJiveApplet.lua:1177) - Suspend ... Jan 1 00:01:01 SqueezeboxController user.info jive: (SqueezeboxJiveApplet.lua:1055) - Set CPU speed 200000 Jan 1 00:01:01 SqueezeboxController user.info jive: (Wireless.lua:636) - REQUEST: STATUS Jan 1 00:01:01 SqueezeboxController user.info jive: (Wireless.lua:666) - REPLY:bssid=00:1c:f0:f1:c6:da ssid=bessie id=0 pairwise_cipher=CCMP group_cipher=CCMP key_mgmt=WPA2-PSK wpa_state=COMPLETED ip_address=192.168.0.141 Jan 1 00:01:01 SqueezeboxController user.info jive: (SqueezeboxJiveApplet.lua:1126) - server=SqueezeNetwork connected=false Jan 1 00:01:02 SqueezeboxController daemon.notice wpa_supplicant[289]: CTRL-EVENT-TERMINATING - signal 15 received
I tried build 24744, the reboots persist. I was connected to SqueezeCentre, controlling a Receiver. After installing the new firmware, I did a factory reset of the controller. Audio playback was not enabled. The Controller is wireless to a single D-Link DIR-655 router which is connected via cat5 to the SqueezeCentre. The Receiver is one wired hop over on a NetGear GS108 switch. (In reply to comment #39) > Would anyone having this issue please try out SC 7.3.3, it will include a new > Jive Firmware which should hopefully address this issue. > > Please visit http://downloads.slimdevices.com/nightly/latest/7.3/ then download > build 24731 or later. > > Report back to this bug if you still see the issue. Include the steps to > reproduce the error, what the controller was doing before the reboot. > > Were you connected to SqueezeCenter or SqueezeNetwork > What player was your SBC controlling > Did you have Audio Playback enabled at the time of the reboot > Did you have Audio Playback enabled or disabled at any time > > Provide a map of your network topology. I.E. router/hub/switch, > make/model/revision > > Thank you >
Created attachment 4709 [details] log of build 24744
(In reply to comment #65) > log of build 24744 > Thank you for the log. Can you please verify the firmware build on your controller for me.
(In reply to comment #66) > (In reply to comment #65) > > log of build 24744 > > > > Thank you for the log. Can you please verify the firmware build on your > controller for me. > It says 7.3 r3856 in the about box on the Controller.
http://forums.slimdevices.com/showthread.php?t=56218 http://forums.slimdevices.com/showthread.php?t=52702
Customer experience with FW 3856: 1. Jive reboots less often with r3856, but still occurs. Instead of every 20 minutes, it happens every hour or two. 2. Jive never goes in to Sleep Mode (issue came about at the same time as the reboot issue according to customer). Customer set the sleep timer to 10 minutes, but still will not sleep.
We are having difficulty recreating the remaining reboot problems. James has found that at least one Controller he has for testing reboots due to a hardware (or device driver) fault. He is sending this to me for further investigation. So the remaining reboots I think are caused by one of: 1) hardware fault 2) application crash 3) watchdog timer problem To help diagnose this further I have created a special firmware that is avilable at http://eng.slimdevices.com/~richard/jive_7.3_r3952.bin. Put this firmware on an SD card, then upgrade from the Settings > Advanced > Software Update menu. Please also capture the logs on the SD card. With this firmware I think you'll see one of: 1) it still reboots, this may be a hardware fault. 2) it stops working, but does not crash. this is probably an application bug. 3) it keeps working, this is probably a watchdog timer problem. Please report what you see and post any logs you capture. Thanks, Richard
Created attachment 4715 [details] log of jive 7.3 r3952 (In reply to comment #70) > We are having difficulty recreating the remaining reboot problems. James has > found that at least one Controller he has for testing reboots due to a hardware > (or device driver) fault. He is sending this to me for further investigation. > > So the remaining reboots I think are caused by one of: > 1) hardware fault > 2) application crash > 3) watchdog timer problem > > To help diagnose this further I have created a special firmware that is > avilable at http://eng.slimdevices.com/~richard/jive_7.3_r3952.bin. > > Put this firmware on an SD card, then upgrade from the Settings > Advanced > > Software Update menu. Please also capture the logs on the SD card. > > With this firmware I think you'll see one of: > 1) it still reboots, this may be a hardware fault. > 2) it stops working, but does not crash. this is probably an application bug. > 3) it keeps working, this is probably a watchdog timer problem. > > Please report what you see and post any logs you capture. > > Thanks, > Richard > With your firmware r3952, my Controller now goes to "sleep" and stays asleep instead of rebooting immediately. I put the sleep in quotes because it actually seems like it has shut off instead. It is quite difficult to get it to wake up again, I found I had to hold the power button for quite a while, then tap power (or something, I haven't figured out a concise way to get it to come back). At that point, it boots up, rather than waking up. It's been a long time since this controller actually slept, so I don't remember what actions are supposed to wake it- I thought movement was enough?
Ritchie... Your experiences with this test firmware is making me quite lothe to try it myself. Were you able to reflash it with the older firmware? Richard... Do you have enough info from Ritchie so that I need not risk this, or does every datapoint help? - Tim
(In reply to comment #72) > Ritchie... > > Your experiences with this test firmware is making me quite lothe to try it > myself. Were you able to reflash it with the older firmware? > Tim, I had no problem flashing back to a prior firmware. I just elected to update from the SqueezeCenter rather than the SD card, and am back to normal.
Ritchie, thanks for the log. It confirms that the watchdog is not causing your rebooting problems, so I believe our problem is a different from the cause of the random reboots. The symptoms you describe are now most similar to Bug 10744. Unfortunately I am still unsure what is causing the reboots on sleep. It might be environmental (eg some configuration in your network) or specific to your Controller (eg a hardware or timing problem). I need to discuss this with James to work out what the next steps are. Can you post the MAC address and PID from the label under your battery.
(In reply to comment #74) > Ritchie, thanks for the log. It confirms that the watchdog is not causing your > rebooting problems, so I believe our problem is a different from the cause of > the random reboots. The symptoms you describe are now most similar to Bug > 10744. > > Unfortunately I am still unsure what is causing the reboots on sleep. It might > be environmental (eg some configuration in your network) or specific to your > Controller (eg a hardware or timing problem). I need to discuss this with James > to work out what the next steps are. > > Can you post the MAC address and PID from the label under your battery. > Richard, I have been corresponding with Daniel Evans to have my Controller replaced and returned to you for further testing at your office. When the replacement arrives it should be straightforward to confirm or rule out environmental aspects. The MAC is 00:04:20:1A:42:D6, and the PID is LZ811AB.
(In reply to comment #74) > Ritchie, thanks for the log. It confirms that the watchdog is not causing your > rebooting problems, so I believe our problem is a different from the cause of > the random reboots. The symptoms you describe are now most similar to Bug > 10744. > > Unfortunately I am still unsure what is causing the reboots on sleep. It might > be environmental (eg some configuration in your network) or specific to your > Controller (eg a hardware or timing problem). I need to discuss this with James > to work out what the next steps are. > > Can you post the MAC address and PID from the label under your battery. > Richard, I have been corresponding with Daniel Evans to have my Controller replaced and returned to you for further testing at your office. When the replacement arrives it should be straightforward to confirm or rule out environmental aspects. The MAC is 00:04:20:1A:42:D6, and the PID is LZ811AB. Bug 10744 doesn't seem related to this problem.
Richard... Should I, also, apply for a return/exchange of my controller to help in your debugging? Or try that test firmware you last posted? What would help the most? - Tim
(In reply to comment #77) > Richard... > > Should I, also, apply for a return/exchange of my controller to help in your > debugging? Or try that test firmware you last posted? What would help the > most? > > - Tim > Tim: Since you are in the UK, I would like to have you try the firmware first, then attach your log file to this bug. Also provide your MAC / PID please You can very easily go back to r3476 after testing r3952 ---------- Correction to Richard's POST: BUG 10774 is the related bug not 10744
Richard... Where does it say I'm in the UK? I'm in San Francisco! :-D - Tim
fromSlimDevicesBugzilla@apeshit.com(In reply to comment #79) > Richard... > > Where does it say I'm in the UK? I'm in San Francisco! :-D > > - Tim > Tim: I apologize.. I got you confused with another user. If you could provide a fresh log file first, I'll see what if any errors your unit is producing. James
Created attachment 4735 [details] Log created when put SBC to sleep, using jive_7.3_r3952.bin This log was created during the period where I: 1. Started the SBC with an SD card in it, with the new firmware 2. Installed the new firmware 3. The SBC rebooted 4. After it started, I told it to sleep The SBC hung at "Please wait..." and would do nothing else. I shut it off by holding down the Home key for awhile, and removed the SD card.
By the way, I hadn't associated the SBC with a player/server at the time I put it to sleep. So... James/Richard, what do you mean by "an application bug"? Which application? - Tim
We have released a new firmware for the SBC 7.3 r3993 which should address the Random Reboot issue. Please update your controller to this version and test again. IF you are still seeing a RANDOM reboot, please comment in this bug. IF you are seeing a Reboot when the controller is woken up from SLEEP or SUSPEND, please post to bug 10774 We will need to get a log file from your controller to properly diagnose the issue. Instructions on getting the log file can be found here: http://wiki.slimdevices.com/index.php/Squeezebox_Controller_Messages_File
James... Will this possibly fix my issue? I had an email from Daniel Evans about sending you my Controller for a replacement... is your latest firmware something that will obviate the need for that, supposedly? - Tim
Tim: It may, please give it a try and let me know if it does or not. However, I think your controller is one that suffers from bug 10774.
Well James, it didn't work. Log enclosed. Hopefully the new controller y'all are sending me will fix the problem. :-) - Tim
Created attachment 4771 [details] Another log created, using firmware 7.3 r3993, "sleep" caused reboot
Mine still was rebooting throughout the night when trying to sleep as well. I will create a log after work today if more logs are needed.
I am now using firmware 7.3 r3993, but all my different SBC spontaneous reboot problems are still present, so this bug is definately not fixed/resolved by firmware 7.3 r3993. These three scenarios still consistently cause a spontaneous reboot regardless which of my two SBCs I use: 1) Every time the SBC tries to go to sleep, it reboots instead - this happens after about an hour of idle time. 2) When I command the SBC to go into sleep mode (by activating the /Settings/Advanced/Turn Off/Sleep function), it reboots instead. 3) When the SC/SBR/SBC system has finished playing a playlist (and the screen is still dimmed to black), the SBC reboots spontaneously Tim's SBC reboot has been suggested caused by a hardware problem. I grant that the very different behaviour apparently observed by different users count point to some systematic problem with hardware, or maybe with the specific configuration or network environment. But if the problems with both my two SBCs are also alleged caused by a hardware issue then I would think (hypothesis) that it is most likely a systematic hardware issue. So, regarding possible hardware differences: are there any systematic hardware differences in the SBCs that have been shipped? Can this be checked by serial numbers?
John... I just posted in bug 10774 on this, as I was told that was the place to do it (since this bug has been set as fixed). In any case, the nice folks at Slim Devices sent me a replacement Controller, thinking that was the cause. As mention in the other bug, I tried this new Controller, and had the exact same problems as before. To quote myself: "Well, I received the replacement Controller you folks sent me. It started up, I connected it to my network, it upgraded itself to firmware r3993, everything looked ok. Then I turn it off, then turned it back on. Then I told it to "Sleep"... and guess what? It rebooted itself again, as my old one did. Could this possibly be connected to my network settings? I'm using WPA2 Personal on a hidden 802.11g-only network."
Created attachment 4780 [details] Jon's reboot bug - two instances of sleep reboot. I attached my log file as well - there are at least two instances of reboots, one on Feb 6 and one Feb 7. If you need any other files/logs let me know.
Is this bug going to be re-opened? It appears as though people are still having problems where their controllers can not go to sleep. To me this is a bigger issue than 10774 since this kills battery life.
Firmware 5225 and higher fix's the issue. Reopen if you still see the issue.
(In reply to comment #93) > Firmware 5225 and higher fix's the issue. Reopen if you still see the issue. Thanks for reminding me to look at this. I had bought another Duet recently and was experiencing the same issue (rebooting, unable to sleep), but had not had time to look up this ticket and post a new comment. After installing a newer firmware last night things seem good, even though it is an older HW revision. Thanks again.
This bug has been fixed in the 7.3.3 release version of SqueezeCenter! If you haven't already. please download the new version from http://www.logitechsqueezebox.com/support/download-squeezecenter.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.