Sound/Sleep Bug Fixed
November 03, 2005
I mentioned in my first post that my brand new G5 running Tiger has a bug that manifests itself after a few hours or days of ordinary use. The symptoms are that all user interface sounds stop playing, and the machine will not go to sleep automatically. Since then, I have received a few emails here and there from people who have encountered the same problem and wondered if I had found a solution. So, I thought I'd post this update to say that I have not encountered the bug since adding more RAM to my machine a couple of weeks ago.
The machine came with 512 MB of RAM, and I knew I would eventually want to increase this. When I finally got around to doing so, I added a full 1 GB, for a total of 1.5 GB. Why do I need so much memory? Well, I probably don't. But this machine is one of those where RAM has to be installed in pairs, and it only has 4 DIMM slots total, two of which were taken up by the pre-installed RAM. I probably don't need more than 1 GB total, so I would have just bought an additional 512 MB, but whatever I bought was going to take up the only two free slots I had. So if I want to add more RAM again in the future, I will have to replace an existing DIMM pair with a larger set anyway. I figured it's better in the long run to buy that larger set now, and not waste the money on a set that will be eventually replaced. 1.5 GB is probably more than I will ever need, so I doubt I'll ever upgrade the RAM on this machine again.
So, the question is, why did increasing the machine's RAM fix the bug? Is this bug triggered by a low memory environment, and Tiger considers 512 MB low? Would adding only 256 MB of RAM have also fixed the bug? Or is it only fixed by adding so much RAM that the OS never even needs to use a swap file? If so, then this is not necessarily an optimal solution. The whole point of virtual memory is so that you don't need to have so much RAM, and a bug that consistently manifests its symptoms when virtual memory is used is thus a rather nasty bug indeed.
Anyway, I guess the point here is that if you've been thinking about increasing your computer's RAM, and you've been bitten by this bug as well, that's probably a good enough excuse to go ahead and do the upgrade.
The machine came with 512 MB of RAM, and I knew I would eventually want to increase this. When I finally got around to doing so, I added a full 1 GB, for a total of 1.5 GB. Why do I need so much memory? Well, I probably don't. But this machine is one of those where RAM has to be installed in pairs, and it only has 4 DIMM slots total, two of which were taken up by the pre-installed RAM. I probably don't need more than 1 GB total, so I would have just bought an additional 512 MB, but whatever I bought was going to take up the only two free slots I had. So if I want to add more RAM again in the future, I will have to replace an existing DIMM pair with a larger set anyway. I figured it's better in the long run to buy that larger set now, and not waste the money on a set that will be eventually replaced. 1.5 GB is probably more than I will ever need, so I doubt I'll ever upgrade the RAM on this machine again.
So, the question is, why did increasing the machine's RAM fix the bug? Is this bug triggered by a low memory environment, and Tiger considers 512 MB low? Would adding only 256 MB of RAM have also fixed the bug? Or is it only fixed by adding so much RAM that the OS never even needs to use a swap file? If so, then this is not necessarily an optimal solution. The whole point of virtual memory is so that you don't need to have so much RAM, and a bug that consistently manifests its symptoms when virtual memory is used is thus a rather nasty bug indeed.
Anyway, I guess the point here is that if you've been thinking about increasing your computer's RAM, and you've been bitten by this bug as well, that's probably a good enough excuse to go ahead and do the upgrade.
Posted by Karl von Laudermann at 10:33 PM
0 comments
