On 06 Nov, Jim Lesurf <jcgl@xxxxxxxxxxxxxxx> wrote: > On 06 Nov, A Rawnsley <rcomp@xxxxxxxxxxx> wrote: I've left the following in full as I've been waiting for a respose to the questions I asked to clarify the situation. I'm reluctant to take the machine apart if in fact this doesn't help, just in case I also accidentally make things worse! I just had to restart my ARMiniX *three* times before it gave me a screen display OK. My strong impression is that something is going wrong at the 'display manager' stage. Two specific question which has occurred to me about the below is as follows: I get the inits of the modules displayed OK, there is then a pause, the screen is wiped and the SDFS and a few other items are (briefly) listed. Then either: A) a short blank, followed by the screen display or B) a blank black screen indefinitely. I'm puzzled by how that an be a power-line problem. The machine has booted up to the point of loading a list of modules. It has also 'found' the screen and lists the init process of them. Yet it then seems to 'lose the plot'. This problem seems different to the one that prevents me connecting the keyboard to the rear USB. Even the green LEDs behave differently. As an interim I'm wondering about using a lower resolution mode as the default set by !Boot for the startup. What mode resolution is used during the listing of the modules being initiated? That looks like it might be a 'safe' choice. Or at least perhaps more likely to be OK. Once booted to the desktop I could then select the mode I actually prefer. This would be awkward but perhaps preferrable pro tem to having to keep repeat the power up. Cheers, Jim > > However, some machines may fail to start due to not getting enough > > power internally. Usually unplugging/reconnecting the molex power > > lead inside and/or reseating the power connection to the internal USB > > hub solves this. Transit can cause this to become loose. For > > example, I have just done such a repair - as supplied to me, the board > > would light up, but never boot (you'd see the lights flash off and > > back on, as if constantly rebooting). After removing the unnecessary > > fan connection, and reconnecting the cables, the last 10 boots have > > been perfect (also updated OS). > > Note that latest OS build, power management ensures that active > > cooling isn't needed, so the fan is not necessary unless you plan on > > overclocking. > That is very interesting/useful to know! I had noticed that the > temperatures shown by the CPU temperature monitor I have on the icon bar > seemed lower than I was used to. This is due to the updated OS? > I have experimented with giving the rear power connector a shuggle > (Scots term) when I first encountered a failure to bootup. At the time > it didn't help. Just to check: the connector I mean is the one that has > its cable/plug stick out of the opening at the back of the case? > I'm attracted by the idea of being able to disconnect the fan if this is > now safe. > Just to make sure: Is it now safe to disconnect the fan? i.e. the power > management will take care of the CPU temperature if I do and all that > will happen if I run some intense CPU processes is that it will slow > down to ensure it remains safe? > If so, I'll disconnect the fan. Having a complete removal of any > mechanical noise is welcome in itself. > If it also removes the problem of having boots fail when the keyboard is > connected at the rear, that would be excellent. Double-win! :-) > To confirm. I'm now using RO5.19 (06-Jul-13) as installed by the > 'official' upgrader. This is the version that provides the CPU > temperature protection? > If removing the fan doesn't solve the behaviour what you say prompts me > to ask if there are test points on the board where I can use a DVM to > check the rail voltages to see if they are too low, etc? > Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html --- To alter your preferences or leave the group, visit //www.freelists.org/list/armini-support List-related queries to info@xxxxxxxxxxxx