Solved: Ubuntu, Acer AL707 and “Input not supported”

After installing Ubuntu 7.10 I could see it was still suffering from the annoying little bug all previous versions have: instead of the neat splash screen during booting, all I got was the LCD’s warning sign saying “Input not supported”.

After finding rest of the shiny new OS very likeable I decided to solve this problem at last. It was safe to proceed on this bold assumption that I could, because in all Ubuntu installations I’ve done the problem has not manifested itself until the first booting into the freshly-installed system. That is to say, the live CD does not have this problem, but displays the splash with no problems, so I knew there must be a way to make it work.

There was a helpful link on the Ubuntu Forums on how to fix a faulty splash screen. In the end, it was simply a matter of finding the right display mode -describing parameters for a couple of config files. As for the parameters, I initially tried to find them from the live CD, but apparently it’s using a different system from the one used by an installed Ubuntu (GRUB), so this path turned out to be harder than a simple trial and error.

First I tried a full-blown 1280×1024 pixels with 16.8M colors, which is the display mode that the desktop starts in and works just fine, but that didn’t work – which I probably could have guessed from the fact that the other config file, usplash.conf, already had this resolution.

Then I thought about the way Windows XP boots on this system: the logo looks a bit crude, as if with a lower resolution and color depth than on the desktop. So I tried 800×600 with a modest 256 colors – and already on the way down Ubuntu now displayed the splash screen! The reboot revealed final success: the splash screen now works.

To be short but exact, what I did to make it work was:

  1. sudo gedit /boot/grub/menu.lst
    so that at the very end of the first kernel line, after “splash” , I added
    – this corresponds to the SVGA mode of 800×600 pixels with 256 colors.
  2. sudo gedit /etc/usplash.conf
    so that
  3. sudo update-initramfs -u -k `uname -r`

Tweaking the FSB of Shuttle SN45G with an Athlon 2600+ (Barton)

Disappointed with the incomprehensibly high prices of used Socket A Athlons at Finnish online auctions, I decided to give overclocking a go in an attempt to squeeze a little more out of my trusty old Barton 2600+ which, by default, operates at 1,90 GHz with a 333 (2 × 166) MHz FSB. As for the other hardware, I’m using a Shuttle XPC model SN45G with stock ICE cooling and the Nforce 2 -entrusted FN45 motherboard, with two 512 MB TwinMOS PC3200 DDR-DIMMs.

Most people who’ve overclocked the Barton 2600+ have reported it doing quite well, so I began by cranking the memory clock straight up to 180 from the default 166. The machine booted fine and after a half-hour of Prime95 running successfully, I went ahead and increased it to 190. With this clockrate Windows wouldn’t boot before I increased Vcore, and I had to go way up to 1,750 to make P95 complete just one cycle of tests. Unfortunately, with the higher voltage and clockspeed, Shuttle’s stock cooling could no longer keep the temperature down: it rose close 70 degrees.

At this point I decided to set myself two goals. The first would be to see how high I could go with the default voltage (1,650), keeping the temperature at bay; this would become my new day-to-day clockrate. The second would be finding a set of aggressive options, or options that would give me everything the hardware has to give without the temperature going beyond 65 degrees – a value I’d still consider being relatively safely below the core’s rated critical temperature of 85, and considering it’s currently winter. I wouldn’t run the CPU with these settings 24/7, but I could turn them on if ever needed to squeeze out more computing speed for, say, a quick-as-possible compression of video.

For the second goal, in my initial tests I found a clockrate of 188 with the core voltage at 1,7 to be relatively stable. I have yet to test this thoroughly, but it’s where I’ll start. The voltage should be increasable to 1,725 with the temperature remaining at 65 or below, should 1,7 prove too unstable.

For the first goal, I found a critical border between 184 and 185. With 185, the machine crashed (or rather, spontaneously re-booted itself) during the first cycle of P95. With 184 it took three and a half hours for P95 to come up with an error. Although much better, this didn’t satisfy me, as I’m aiming for stability beyond reasonable measuring (several hours if not days of successful stress testing), so I’ve gone down to 183 now and am currently in the process of testing its reliability. If successful, this will yield a CPU frequency of about 2,06 GHz, which is about 8 percent up from the default, with FSB up 10 percent from the default (from 333 to 366 MHz). I’ve also enabled aggressive CPU interface and memory settings in the BIOS – they used to be at optimal.

I did try to tweak the CPU multiplier, which could have helped the memory clock up all the way to 200 (which would yield the rated top frequency of 400 MHz from my memory modules), but unfortunately the CPU seems to be locked, since all that trying to change the default (11,5) achieves is BIOS booting in what it calls a Safe mode, and prompting me to re-setting the multiplier [sic]. From what I’ve read, there is a way to unlock Bartons, but I’m not too adept with hardware hacks so I’ve decided not to go there at least for the time being.