Bugzilla – Bug 7315
Upgrading FW 18 on SN causes reboot
Last modified: 2009-09-08 09:25:53 UTC
If I understood Felix and Andy's conversation during the call this morning, Felix was going to try this with a debug build of FW18 and let Andy know if incorrect messages are being sent from SN.
I tried the following 10 times (5 times wired, 5 times wireless) and unfortunately I cannot yet provide any debug information as it always worked fine (i.e. no purple blinks). - Local SC7 offering SBR fw 18 (not login data or SN) - Factory reset SBR - Use SBC to setup SBR to connect to SC7 - SBR downgrades to fw 18 - Factory reset SBR - Use SBC to setup SBR to connect to SN - SBR upgrades to fw 22 Is there anything special you guys did to provoke the purple flashes? Does it only happen when connecting to SN or also when connecting to SC7? Do I need to use a certain SBC fw (I am using r2013)? Does it happen more likely if SBR is connected wired or wireless? Does it also happen with a SB or TR where the specific error message could be seen? I will continue to try to reproduce the error later today.
Ok, I got it to break, at least once so far. I've seen four purple blinks right when the download should start. From the ip3k log file it looks like there is more than one 'ureq' command coming in and the second one causes the purple blinks, meaning 'bad state: 1'. Log (failed): 0: 00029.925: Info: slimproto_recv.c[281]: Server would like to update 0: 00029.926: Info: update.c[38]: update_begin() 0: 00029.926: Info: slimproto_send.c[284]: slimproto_request_update() 0: 00029.938: Info: slimproto_recv.c[281]: Server would like to update 0: 00029.938: Info: update.c[38]: update_begin() 0: 00029.938: Info: update.c[41]: bad state: 00000001 0: 00033.939: Info: utils.c[46]: Panic: error 116 I am trying to also get a wireshark log, but so far it didn't happen again. What I found however, looking at a wireshark log of a successful upgrade is this sequence: ureq, upda, upda, ... , upda, updn, ureq, ureq So I am wondering where the extra two 'ureq' commands are coming from and if when it fails one of them arrives earlier for some reason.
OK, that's helpful. I tried reproducing locally last night and couldn't get it to happen either. It's definitely an SN bug then.
I think this has been fixed by r17708.
This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1 Please try that version, if you still see the error, then reopen this bug. To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html