Google the SiteQuicksearchCategoriesSyndicate This BlogCreative CommonsBlog Administration |
Monday, January 15. 2007Cursor Artifacts Using nv nVidia drivers on X
Just come across an annoying problem whilst using a GeForce 6200 in X - in Firefox, scrolling around inside form fields or the URL bar with the arrow keys results in a number of cursor artifacts left behind making reading or editing anything in those areas impossible. Switching focus away and then back to the Firefox window removes the artifacts, but this isn't very practical.
After some digging around to confirm the bug is with the 'nv' driver (the problem disappears when running with just the vesa driver), I scanned the bugs listed for the nv driver and thankfully found the bug listed already here. The bug report also thankfully had a simple workaround to the problem - adding: CODE: Option "XaaNoSolidFillRect" in the card's device section. No idea what the drawbacks are to using this option, searching for the term "XaaNoSolidFillRect" just comes up with a list of other nv bug reports citing the above as a solution. From those results, the same problem is described in more detail also at this URL by another nv user with an ascii art representation of the problem (woot!): http://lists.debian.org/debian-x/2006/01/msg00056.html Friday, January 5. 2007FreeBSD installation problems with Maxtor DiamondMax 10 250 Gb HDD 6L250R0
As I mentioned in another post, I recently got a new Maxtor DiamondMax 10 250Gb HDD - model is 6L250R0 - and decided to install FreeBSD 6.1 on it. I downloaded and burnt a copy of the distribution to disc, booted from the installer OK and everything went well until it got to the installation commit part where I received a number of errors like this:
CODE: ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad0: FAILURE - READ_DMA status=51<READY,DSC,ERROR> error=84<ICRC,ABORTED> LBA=0 The short version of the solution is to either use an 80 conductor IDE cable to allow correct Ultra DMA transfers OR run the FreeBSD installation in safe mode. The first option is much prefered, even if only to increase the transfer speed used by the HDD. Installing in safe mode might work ok, but the underlying issues with UDMA may still persist after the installation when the operating system is in use, which is obviously not a good thing. If possible go for upgrading the IDE cable to 80 conductor. More details of the problem are detailed below: The problem occurs at the point where the installer attempts to write the disk labels. The disk appears to be formatted ok and the FreeBSD slices (DOS 'partitions') are created ok, the errors occur when the FreeBSD partitions inside each slice are created (ad0s1a-h). (Incidentally I found that I could only assign a maximum of 7 partitions per slice which seems to contradict what I read somewhere else about this saying that you could create up to 8 partitions per slice. Perhaps this is to do with swap partition creation though, I'm not sure, the 7 does include one swap partition - ie not 7 regular parts plus the swap...) Anyway back to the problem. After a quick search I found this post which almost exactly describes my problem along with a much appreciated reply - qutoe from that post: QUOTE: Finally I got things working! First I tried several other IDE cables, which did not help. Then I tried Carl's advice and bought a 80-connector cable. And amazingly enough... It worked! From what I can gather the problem seems to be that the FreeBSD installer doesn't detect the DMA mode correctly and tries to use the faster UDMA mode (Ultra DMA) regardless of whether a compatible 80 conductor IDE cable is in use or not (an 80 conductor cable is required to make use of the extra speed of UDMA (see here for a good description of 80 conductor IDE cables) and attempting to use UDMA without an 80 conductor cable causes problems *from what little I understand of the thing*). Why this is missing on FreeBSD I don't know - it seems to be detected OK on Windows XP and from what I read, OpenBSD works fine around this problem too. Anyway, I ordered an 80 conductor IDE cable from ebay so hopefully that will make installation easier and generally increase speed as well for the HDD. Of course by sod's law, as soon as I'd done this I found a way to get around the problem... Out of curiousity I decided to try and use the FreeBSD installer's 'Safe Mode' to see if it would fall back to using a safer DMA mode. I had to use a standard PS/2 keyboard instead of my USB one - presumably because USB support isn't included in safe mode - but the installer actually managed to write to the disk properly this time which is good. The caveat, as mentioned above, is that the problems may still persist after the installation, I've not tested this out as yet so don't know but would be surprised if the problems magically dissappeared without using an 80 conductor cable. End of the day, make sure to use an 80 conductor IDE cable if you run across this kind of problem on FreeBSD. Moving munk.me.uk to a new HDD - filesystem layout
Well after having been on FreeBSD 4.x for as long as I can remember (4years now I guess), it's finally time to move to FreeBSD 6.x! For ages I've been saying as soon as I get a larger HDD I'd upgrade the system and santa kindly delivered a shiny new 250Gb Maxtor DiamondMax 10, so it's time to sort it out and make the move.
Funny now I think about it, for me upgrading to a larger capacity HDD has always been a fairly rare occasion. Back in 2000 or so I remember moving from a measily 1.6Gb to a whopping 20Gb HDD and thinking that was way too much. In a way it's a good thing to not have a lot of space - it makes you more tidy and less likely to spam crap all over the filesystem. Of course on the other hand not having a lot of space also sucks if you want to store a lot of stuff (duh). This is kind of how it's been with my FreeBSD server for the last 4yrs or so - I've only had a 40Gb drive and in that time I've hosted over 100 users at the same time, dozens of domains, ran a load of services, and never really had a lot to complain about re lack of space. The main reason for the change I guess is the increased use of broadband/bittorrent which I really need more space to save files to disk for. I'm gonna document the filesystem layout of the new HDD here, no doubt it'll only be me that ever reads this again (and you if you're reading this heh :o). File System Layout I spent quite a while thinking about how best to partition/slice up the new 250Gb disk, mainly because my server is running 24/7 and various applications really do kane the filesystem when accessing data (ie apache and mysql for two). I want to try and partition the disk so that it's more efficient for apache and mysql to read/write from/to the disks. The other deliberation I went through whilst thinking about the file system layout was where to mount partitions for backups, music, videos and windows application installers. Of course this could be anywhere really - /backups /music /videos /windows for example - but I don't really like spamming the root level filesystem with lots of folders that only add clutter. I had a quick look at the Filesystem Hierarchy Standard which is a standard aimed at encouraging clean and consistent filesystem layouts on Unix type OSs and eventually ended up with the following layout: CODE: G=Gigabytes
fdisk: ====== Name Size Partition Type ==== ==== ============== ad1s1 59G freebsd ad1s2 89G freebsd ad1s3 49G freebsd ad1s4 33G freebsd disklabel: ========== Partition Mount Size (approx.) ========= ===== ============== ad1s1: ------ ad1s1a / 0.5G ad1s1b swap 2G ad1s1d /tmp 1G ad1s1e /var/db/mysql 20G ad1s1f /var/www 10G ad1s1g /var/ 10G ad1s1h /usr 20G ad1s2: ------ ad1s2d /home 40G ad1s2e /var/backups 50G ad1s3: ------ ad1s3d /var/media 50G ad1s4: ------ ad2s4d /var/win32 35G Tuesday, June 29. 2004PSU Failing On Server
The power supply unit on the server is just starting to fail. Nothing major, just one of the fans starting to make a racket after being on a long time. To be expected I suppose given that it's a fairly cheap and cheerful PSU and it has been running constantly for a couple of years.
I swapped it out anyway with one of the machines I don't use so much - one that isn't on 24/7. Seems to be fine - the noise only gets incessant after the PSU is on for a few hours or so and that machine won't be on for that long. Monday, December 8. 2003mini-itx rocks
I've just discovered the mini-itx motherboards that are reaching the market now and all I can say is I'm well impressed :) Very close to purchasing one for living room.
Continue reading "mini-itx rocks"
(Page 1 of 1, totaling 5 entries)
|

