Wednesday, 21 April 2010

Ubuntu Screen Saver Redux

IMPORTANT UPDATE: There is a solution here. Well, it worked for me anyway.

There is quite clearly some sort of bizarre fetishist working at Canonical. This individual gets their rocks off by entering into a cat and mouse game with Ubuntu users who do not want their fucking screens to go blank every 10 minutes.

The user starts by thinking that the screen is being turned off to save it from burning in. Realising that CRT's went out with Prince's last chance of decent royalties from "Let's party like it is 1999", the user will turn this option off. Especially if the user has a laptop which very rarely have a CRT displays - even in the second millennium.

(Although I did once encounter one. Some stupid bugger had bought a "Laptop" off some bloke down the pub for his child for Christmas. Turned up at my house at about 8pm on Christmas eve with something that looked like a double sized oscilloscope. You could only accurately describe this as a Laptop if you were a T100. He wanted some games for the vessel of his genes to play on their new computer of Christmas morning. I found some mouldy 5 1/4 inch disks (!) with some shareware on them and sent the man home, with a tear in my eye at the thought of the agonised disappointment that was going to be etched into the face of the little cherub that has been expecting a Sega Mega Drive from Santa and instead got a shitbox that could barely play monochrome pong. Oh, and I missed most of Hunt for Red October which was on TV trying to get the fucking thing to work).

So you turn off the screen saver and wait the requisite 10 minutes. Blank screen. Oh for fucks sake. You then think "A Ha!", maybe this is a POWER saving not a SCREEN saving option. After all I am running a Netbook where battery life is at a premium. The OS may be cutting the power to the screen not just saving it! So - into Power Management and select 'never' for "put display to sleep when inactive for" when running on AC power. Wait 10 minutes, blank screen. Oh for fuck's sake.

If you used previous versions of Ubuntu, then you have fought this battle before. You will recall that what you need to do, after HOURS of googling, is use your friendly neighbourhood gconf-editor to change the /apps/gnome-screensaver/idle_activation_enabled setting to false by unchecking it. So, using Karmic you uncheck this.

At this point the aforementioned fetishist giggles with glee and starts to touch themselves inappropriately.

You wait 10 minutes, and ......

Blank screen!

Fucking bastards. This worked in the previous version of Ubuntu and now you have fucked it up you bastards. Where, WHERE FOR FUCK'S SAKE, is the god damned setting which stops the fucking display going blank after 10 minutes. And why if you uncheck Activate Screensaver AND set turn off display to never does the fucking display keep going blank?

If this is not fixed in Lucid, I am going to hunt down the little pervert who is toying with me, and I am going to perform activities on them that would sicken Dr Mengele EVERY 10 MINUTES until they fix this.

Intermittent Problems

You know what I really fucking hate? If you read the post title you do. Intermittent problems. I have a logical rational and determinative approach to problem solving PC's.

Step One. Discover Something is not working.
Step Two. Make an educated guess as to the cause.
Step Three. Come up with a way to find out if that cause is actually the cause.
Step Four. Use that way to test.
Step Five. Check if the problem remains.
Step Six. If the problem remains go back to Step Two. If the problem is gone, Congratulations you have solved the problem.

Say the display shows a blank screen only. Guess it is the video card. Reason that if the video card is swapped and another one works it is the video card. Swap the video card. Display active? Yes? Then it is the video card.

This is brilliant. However, I really fucking hate it when you cannot rely on Step Five. This is the crappy situation where, for example, the VGA connector on the motherboard or the cable to the monitor has a wire or pin on the verge of breaking. Hence the simple act of jiggling all the connectors by removing one card and replacing it with another can, temporarily, solve the problem of a blank display despite the fact that the problem really was not caused by the card.

You think you have solved the problem, but give it a few hours, days or weeks, and it will reoccur. You are now back to Step One, but you now cannot rely on Step Five. Or in other words, you are fucked.

This is extremely annoying, and it turns problem diagnosis into an exercise in statistics. I feel a bit like Einstein, complaining loudly and longly about the unfairness of a universe in which matters cannot be predicted by a study of cause and effect. Instead you are left floundering in a sea of random chances and statistics.

I have an intermittent problem at the moment - a 750GB SATA HDD keeps disappearing. Not literally, obviously, but Windows from time to time just forgets it is there. I lose all my desktop shortcuts to that disk and it does not show up in My Computer. A swift restart fixes this, and the disk comes back. I have no idea why this is happening. It could be the disk on the way out. It could be a dodgy SATA cable. It could be the SATA controller on the motherboard. It could be the drivers for the SATA controller on the motherboard.

The Step 3 plan is to swap the cable, and use a different SATA port on the motherboard. I will be unable to rely on Step Five though, because the fucking thing may keep working for a week or two before the problem re-occurs.

Pain in the arse.

Something that Works

While most of what passes for intelligent comment on this blog is in the nature of complaints about the stupid way that some things seem to be designed not to work, it seems only fair that I record a recent positive experience.

I have commented on the spectacular hardware failure saga below. What I was left with during the repair period was a hard disk with the OS installed, and a video card.

Ordinarily with microsoft operating systems if you swap a hard disk from one machine to another, windows, to put it politely, shits itself. If it boots at all you get regular blue screens and no peripherals will work.

However, this hard disk had windows 7 installed on it. I thought to myself, what the hell I'll try and plug it into another motherboard. I already had a spare machine so I dragged the new machine's case over to the old machine. I ran the power cables from the new machine to the motherboard on the old machine. The SATA data cables were run between the motherboard in the old case to the disks bolted into the new case.

On firing the machine up I was stunned, nay astonished, to discover that against all previous experience windows did not shit itself.

Instead the OS loaded up drivers for the changed wireless card, and sound card and started working perfectly well.

The only problem was with fucking stupid DRM in iTunes. Despite purchasing upgrades to DRM free mp3 files as and when they become available I still have several protected files in my iTunes database. Of course iTunes thinks I have copied the files to a shiny new machine. This is despite the actual physical files on the disk being identical. iTunes says new motherboard and CPU = new machine so you have to re-authorise the files. Of course because of the catastrophic failure of the new board, that means I have to use up one of my 5 authorised machines.

All my other software, including Steam games, worked fine.

So, thumbs up to windows 7. It doesn't shit itself if you swap motherboards. They can put that on the box.

Of course, linux is perfectly happy to run on whatever machines you throw it at (even from a USB key) as long as you enable the appropriate kernel parameters. Which stuff like Ubuntu does by default.

Wednesday, 31 March 2010

Hardware Fuckup

Most of the grumbling herein refers to software not acting the way it should. Of course, computer fuck ups are not solely related to software. I therefore take this opportunity to present the saga that was my recent hardware failure fuck up.

There comes a time in a PC owner's life when the game plays like a slide show, video takes an age to encode and Windows takes about three ice ages to boot. It is the time of an upgrade. This year, I reached such a time. My general rule is that if it doesn't double performance, it's not worth buying. I was running a 2.2Ghz Athlon X2, with 2Gb of RAM and a 9600GT graphics card. I was also using a 750Gb HDD.

When I purchased my last motherboard I wanted to keep the RAM I had so I went for the socket 939 chipset instead of the newer AM2. This was, ultimately a mistake, because it meant that this time around I could not just buy a brand new AM2/AM3 Athlon/Phenom. The only 939 chips still on sale are only marginally faster than the chip that I had. So, new platform then.

At the time of writing there is a clear leader in home PC enthusiast CPU's. It is the Intel i5 750. This is a Quad core processor running at 2.66Ghz. It has a nifty facility whereby one can reduce the number of cores in use and boost the speed up to a max of 3.2Ghz. You get the best of both single/multi core worlds in other words.

The motherboard I went for is the Gigabyte GA-P55M-UD2. It comes highly recommended for the i5 750. To this I added 4Gb of G.Skill 12800 DDR3 RAM. All that guff means that it is rated to run at (12800/8(bits)) or 1600Mhz.

My biggest decision was whether to get a new graphics card (specifically the ATI 5770) or a Solid State Disk. A 64Gb SSD is about the same price as that graphics card. It is also the first size of SSD that actually makes sense. You can install Windows and a couple of games in 64Gb. Large video files, iTunes libraries and so forth, do not require a speedy SSD, so that can happily still take up room on the 750Gb HDD.

In the end I went for the SDD. I picked up a OCZ Agility drive. I have to say it is not a decision I have regretted. The drive has the fancy new 'Trim' enabled firmware and has performed flawlessly. Until you have actually used an SSD based PC you do not really have an appreciation for how much of a speed increase you get.

As for the graphics, it turns out that the CPU was something of a bottleneck in my old system because the new platform gets much more out of the 9600GT. I can now run the games which really tested my previous set up (Crysis, GTA IV, World in Conflict and Assassin's Creed) on mostly full settings. Bear in mind that my monitor is a 19" 1440x900 job, so the 9600GT does not have to pump around too many pixels.

Anyway, the system ran perfectly sensibly for a month. Then, all of a sudden, it just stopped. As in power off, no start up when button pressed. Now, I admit I had applied a modest overclock to the CPU. If I recall it was running about 3.3Ghz instead of 2.66Ghz. You will find plenty of reports about the chip running at 4Ghz, so I thought I was a-ok.

I am no stranger to overclocking failures, so I tried the usual method of restoring the machine. Step one, wait for the system to cool down. Nothing. Step two, clear the CMOS chip. Nothing. Ah. Something bad has happened. Try another power supply. Oh - lights and the CPU fan spins! For 500 milliseconds. Bad. However the other power supply only had the 20 pin power cable, not the beefier 24 pin. Plus it only had a 4 pin 12v cable and the motherboard needs an 8 pin connection. So, test the first power supply on another machine. Nothing - A HA! Dead power supply. Odd, but not impossible. You see I did not change power supplies when I upgraded the kit. The existing one was a beefy 500W Enermax unit, with all the necessary connections. However it looked like it just wasn't up to the job of overclocking the new kit. So, I order a new 600W power supply. It arrived next day and I fired it up. It behaved in exactly the same way as the older PSU - lights, brief fan spin. Oh bollocks.

I now have RAM, a CPU and a Motherboard. All could be faulty. I have no other machines which use this platform so I cannot test any of them. On balance, and because it is the cheapest to replace I opt to send back the motherboard first. I bought the stuff from ebuyer.com. Their policy is not to accept any returns if you have had the kit for more than 30 days. They just direct you to the manufacturer. This is extremely frustrating. And not entirely legal. There is nothing in the Sale of Goods Act which allows them to adopt this rigid attitude. However, when you have been overclocking you cannot really complain too much. So I emailed Gigabyte. I have not used a manufacturers RMA system before, but I have to say that Gigabyte were excellent. Highly recommended. They asked for some details, and gave me an address and reference number. I boxed up the board and sent it recorded delivery to Gigabyte. Cost was £5.

I sent it to them on a Monday, and by Friday it was back in my hands. They had identified some components on the board which had failed and they had replaced them. Good stuff think I - problem found and fixed. The components were the VRMs which also explained why the PSU had failed.

So, I install the board back into the machine, hook up the new PSU and let rip - and it works. Brilliant. I get all my stupid DRM licences re-activated and get back to the video encoding I was doing when it all went south the first time. I do not, however, overclock the machine. I installed Speedfan to monitor the CPU temperature. I had set the alarm temperature in the BIOS to 60C. I noted that Speedfan seemed to be reporting a temperature of 80C which was a little alarming. I left it encoding for a while, and came back to find Speedfan's graphs showing a temperature under load of more than 100C had been recorded. However, no alarms were going off, and the system seemed find. So I ran another encoding task. This time when I returned, however, the system was dead again. Exactly the same symptoms as the first time. Dead power supply, brief fan spin up. Oh, fuck.

I had had the PSU for less than 30 days, so I got straight on to ebuyer and reported it had failed. They asked me to return it to them, and it was picked up on the following Monday morning. I also went back to Gigabyte and reported a further failure with the board. I have to say at this stage that I had no idea what the problem was. I asked Gigabyte to carry out more detailed burn in checks with the board. I sent it back to them the same Monday.

My concern at this point was that the CPU has been fundamentally damaged by the original overclock - and that to the point where it was killing other components. Gigabyte actually asked me to send them the CPU but said they could take no responsibility for its safety. On balance I wasn't prepared to risk it - it could still be the board after all.

I spent some time researching the operating temperatures of the i5 750 and found out that 80C and 100C were way beyond what it should have been running at. My suspicions turned to the cooling system. I was using the reference intel heat sync and fan that had come with the chip. It uses this plastic push pin system to attach it to the motherboard. It struck me as badly designed and flimsy when I was installing it, but what do I know about heat sync design. I formed the view that this was the problem and needed replaced asap. The biggest and baddest heat sync and fan for the i5 750 is the Titan Fenrir. This is a frankly ludicrous 120mm fan and heat sync. So I ordered one while the board and PSU were away.

Both ebuyer.com and Gigabyte technical support had the components back in my hands by the Friday, which I do consider to be excellent service. In particular Gigabyte sent me photographs of the board being thoroughly tested and remaining stable.

I got all the components back and reassembled the machine with the Titan Fenrir. I was extremely apprehensive but fired it up. It happily loaded windows, and I checked the temperatures asap. 25C. Not 80C - 25C. The new fan had made a significant difference. Since then I have had no further failures.

So what was the actual problem with this? I put it down to the stupid Intel Cooler design. It is too easy not to get a decent fit to the motherboard. The Titan Fenrir, by contrast, has a backing plate and bolts, meaning that when it is fixed, you know it is fixed.

There is another possibility though. Remember the memory I got was rated to run at 1600Mhz? Well, the bus speed of the i5 750 is 133Mhz. The memory runs at 10x the bus speed. So how does the 1600Mhz work? It uses a system called XMP - which has a particular profile built into the memory chip which the BIOS on the motherboard can read. I had activated this (before each failure) without thinking too much about it. I looked more closely at it after the second failure. It turns out that what it does is raise the CPU bus speed to 160Mhz which then allows the memory to run at 1600Mhz. This means that if you then further over clock the chip you are going way beyond the original settings. This meant that when I did the first, modest over clock, I was actually stressing the system more that I had thought. This time around I have not activated the XMP. So far, so good.

Lessons learned? Intel heat syncs and fans are crap on the i5 750. XMP memory profiles may not be good.

Oh, and my i5 chip must be made out of asbestos. It's max temperature is 72C. It went way beyond that to the point where the power draw was enough to (presumably) fry the motherboard (twice) and 2 power supplys. At no point did it shutdown to protect itself - or the other components.

Finally it turned out my case did not have a speaker, so the BIOS was probably beeping away its warnings to no avail because no speaker was attached to the jumper. I have now attached a small stand alone speaker which should mean I get the warnings in the future.

Friday, 22 January 2010

Command Line Compression

In Microsoft centric operating systems compressing files is reasonable straightforwards. The software used is fairly mature, and the task is usually as simple as right clicking on a folder or file and choosing the relevant compression task from the context menu. You then end up with a file containing your compressed data, with a file extension that tells you what the compression type is (.rar, .zip, .7z, etc etc).

Perhaps unsurprisingly by now, Linux is a little more complicated. You will usually encounter a compressed file you want to uncompress before you find the need to start compressing your own data. You will probably download this file. It's name will be something like:

[name of archive].tar.bz2
or
[name of archive].tar.gz
So what is going on here then? Well in Linux first you have a bunch of files which you 'tar' and then compress. Or, the other way around, first you have a compressed file which you uncompress, then un-'tar' into your bunch of files.

A tar file is, as far as I can gather, a file created using the tar command which contains other files. There is something deeply unsatisfying about that explanation, but it is the best I have. For our present purpose, it is also the only explanation you need. To unpack a tar file you run the following command in the directory where the tar file is:

tar -xf [name of tar file]

The 'x' means e[x]tract, and the 'f' means the [f]ile name follows immediately. That won't work for our files though, because they are not just tarred, they are feathered as well. Sorry, not feathered, compressed. The last section of the extension tells you about the type of compression used. If it says .gz that means it has been zipped. If it says bz2, it has been bzipped with version 2 of that software. Generally speaking bz2 files are smaller than the equivalent gz file, take less time to download and take up less space. Why ALL files are not compressed using bzip2 I have no idea. It is bizarre. Anyway, to uncompress at the same time as unpacking from the 'tar' file, you add 'g' for a gz file and 'b' for a bz2 file. Its obviously isn't it? No, sorry it is 'z' for a gz file (which makes sense … just) and for bz2, 'j' for some unfathomable reason. So:

tar -zxf [name of tar].gz
tar -jxf [name of tar].bz2

You may want to throw in a 'v' for [v]erify into the command which will print the name of each file it extracts. This way you can check the system is actually doing something and has not crashed. The command ends up as:

tar -zxvf [name of tar].gz
tar -jxvf [name of tar].bz2
Now, when it comes to compressing your files, it is just a matter of tweaking the command. You use 'c' for 'c'reate instead of 'x' for e'x'tract. Other than that, after the name of the archive you want to compress into, you list the filenames or directories you want to add. Hence:
tar -zcvf [name of archive].tar.gz [list of files or folders to compress and add]
tar -jcvf [name of archive].tar.bz2 [list of files or folders to compress and add]
All in all, not as painful as it first appears. Having said that, I had to go through a lot of logical deduction to work out all of the above. As I have discovered previously the actual manual page for the tar command is strong stuff. The opening paragraph, for instance, is:

     The first argument to should be a function; either one of the letters
Acdrtux, or one of the long function names. A function letter need not
be prefixed with ``-'', and may be combined with other single-letter
options. A long function name must be prefixed with --. Some options
take a parameter; with the single-letter form these must be given as sep‐
arate arguments. With the long form, they may be given by appending
=value to the option.


Which is clear as mud to some one who just wants to open a compressed file.

Friday, 15 January 2010

Network Disconnection

Right. So you are using ubuntu and your get heartily pissed off with Network Manager, so you switch to Wicd. All fun and games until you try to assign a manual IP address and then go back to DHCP. Then, for reasons which I will set out below, evolution starts prompting you for your password constantly. The internet works, but you cannot browse your local network shares.

Oh joy.

Now, this type of problem screams DNS error. You can test this by alternately pinging the IP address of your server, and then the Name of your server. If the former works but not the latter you have a DNS lookup problem.

It turns out that when Wicd gets a hold of the DNS settings for Ubuntu it fubars them and doesn't put them back the way they ought to be. In ubuntu the DNS settings are stored in the file:

/etc/resolv.conf
In order to work properly this needs to have the following lines above the nameserver line comme ca:

domain mylocaldomain.local
search mylocaldomain.local
nameserver [IP of DNS server]

Wednesday, 16 December 2009

Karmic Sound

The Intel ICH7 southbridge with AC'97 audio is hardly what I would call rare. And yet, somehow Ubuntu Karmic conspires to screw around with the audio settings for this device.

Apparently, the only sure fire way to get sounds from the integrated speaker is to inadvertently browse to a website with garish embedded sound. If you actually want sound to emanate from the speaker though, you are stuffed.

Y'see there are settings and there are settings. The Sound Preferences program (which is run by the command gnome-sound-control, which in turns runs a program with the name gnome-volume-manager) has no setting for changing the source for the external speaker. So if it gets stuck on "Mic" you get no sound at all. You then have to drop to a terminal and run:
alsamixer

To get to the setting for "Mono Out". You want to use Page Up and Page Down to change between Mic and Mix. Mix being the one you want.

There is of course a separate question of who in their right mind would want to direct the Mic input straight to the Mono Speaker output. A nutter is the answer to that question.

BUT WAIT!

Not content with one way to screw up your day, Ubuntu is ready with yet another. Pulseaudio is a part of Ubuntu that does ... I have no idea what. Pisses me off I suppose.

When this little gem swings into action (which appears from my extensive research to be whenever it fucking feels like it), the aforementioned Sound Preferences Program declares that you have NO OUTPUTS for sound. Alsamixer, gnome-alsamixer, and kmix can all happily see the proper sound outputs, but can you get any sound? No.

So, what you can do then is run:
ps aux | grep pulseaudio

from a terminal. That looks fairly nightmarish, so lets break it down. 'ps' means show me details of running processes. 'aux' is just a series of settings which make 'ps' show you a information about as many processes as possible. The '|' symbol means take the output of the left hand side of the line and 'pipe' it to the command on the right hand side of the line. The command 'grep' means search for, and the 'pulseaudio' is what we are searching for.

So, the command as a whole searches all running processes for pulseaudio and reports back information on it. The key piece of information you need is the 'pid' or program ID. This should be a 4 digit number. It uniquely identifies the program on the machine. The next step is the satisfying:
kill [pid of pusleaudio you found in the last step], e.g.
kill 1234

That should terminate pulseaudio, so when you go back to Sound Preferences, your output devices are back!