Bugzilla – Bug 8879
update_begin: bad state shows during upgrades
Last modified: 2009-10-05 14:30:39 UTC
I've seen this too, but I assumed it had to do with my debug builds. It seems to happen more often when I'm at the edge of wifi reception, though I have not reproduced it reliably. On Fri, Jul 25, 2008 at 2:59 PM, max.spicer <max.spicer.3d4jhz1217023202@no-mx.forums.slimdevices.com> wrote: I just updated to the latest on the boom branch and saw some odd behaviour when I restarted the server. Both my boom and my transporter went through the fw upgrade process at least three times, failing each time. On my boom, I saw the error 'update_begin: bad state' in the middle of the progress bar stage. I saw the transporter flash up an error too, but sadly wasn't close enough to the display to read it. After the third (ish) attempt, the updates completed successfully. At the same time as this, my wireless network appeared to go screwy - my open ssh session dropped and I couldn't contact external web pages. Now obviously, the fw failures could have been simply due to my wireless network going odd. But it's normally very stable. In fact, I can't remember it behaving like that before. Could the wireless oddness have been caused by the fw updates doing nasty packet storm things or something? Thought it was worth posting here in case there is a problem with the update. Max -- max.spicer
QA to try upgrading multiple players, on congested networks, and at limits of range. Customer comments would be welcome as well.
I have been unable to reproduce this either at MV or on my home / other networks I have access to. Bumping this to 7.3
I'm still seeing this occasionally - it happened just now, for example. I didn't notice if an error was displayed on the screens, but my wireless network went offline for a short period when I restarted squeezecenter having just updated to the latest svn that included fw upgrades.
This happened again with all the fw updates included with Boom v30/31. This time I was deliberately watching the Boom. The fw update stage began and the bar got to approx 1/3 full. It then hung for a while and afterwards the screen went blank. My wireless network hung at this point, causing my ssh session to my server to be dropped. Boom displayed the update_begin: bad state message. I think at this point my Transporter restarted as I heard it click (audio outs turning on/off, probably). The transporter could then be turned on and was connected to sc. My boom was at the fw's select source menu and I had to make it connect to sc manually. It then did another fw update, then displayed Software Update. This completed and it did another fw update. My wireless network isn't the fastest, but it's normally stable. I've currently got two Booms (pqp3 and a pqp1), a Transporter, a SB2, a SBR and a SBC powered on and connected to SC. In the past I've probably had other devices connected as well when I've seen this bug, but they are currently physically powered off. It could well be that this happens every time I get a fw update as I often update and restart remotely or simply don't pay that much attention. Worth reconsidering for 7.2?
I've just done the latest fw upgrade - transporter 62 and boom 32 etc. The same happened as before, but this time I noticed that the transporter failed first and displayed an error message ending with 'slimproto'. I would bet it was probably 'nb alloc failed in slimproto', which has been reported on the forums. The transporter rebooted, at which point the boom displayed the 'update begin: bad state' message. As before, my wireless network hung during this process. It's possible that this only happens when the transporter is in the equation.
From what I read here I start to believe it has to do with multiple players requesting firmware upgrades at the same time, which is something that probably did not happen that often before SBR / Boom and before we had SBR / Boom set to do auto-upgrade without manual interaction. A player shows this error message if there is some packet arriving in the wrong order. Could it be that SC / SN gets confused about what player is in what upgrade stage if multiple players are upgrading at the same time? Did QA already try this with let's say multiple Booms connected to one SC? BTW: I am not sure it is a major bug as it actually prevents player firmware from getting corrupt. Maybe we just need a better wording for the error message? Sean: What do you think? You are more familiar with the upgrade process. Thanks.
Maybe not major, but it's pretty annoying every time it takes out my wireless network. I have all my players set to auto-upgrade fw.
Ok, I didn't realize the firmware upgrade process is actually killing your wireless network which seems really strange. I thought because of your wireless going down you are seeing the error message on the player. Sorry about that. I don't think it is player type related then as SB3, TR, SBR and SBB use the same mechanism / code to download new firmware. Could it be that the load on a (weak) wireless network is too high if a bunch of players start downloading firmware at the same time? If this is the case then there isn't much firmware could do I think, but maybe SC / SN could 'schedule' firmware upgrades and ensure not all happen at the same time? QA: I would like to change the test then to multiple Booms connected wireless to one SC.
My wireless network isn't _that_ bad - it can sustain some pretty large transfers without ever freezing. It only freezes when this fw upgrade error occurs. No idea why. I guess I should try eliminating devices, but time is pretty limited at the moment unfortunately.
Moving out bug that won't make it for 7.3
Doh, there will be no 7.4 - moving it to 8.0
Maybe related. Seems like the users player had its MAC address reverted to the factory MAC address and after correcting the MAC address the firmware update worked again.
It's a long shot, but the recently fixed TCP reassembly bug might explain this. If we have a test case it would be good to try it with that change.
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.