 |
Red Hat 7.2 vs. Dell Latitude C800 |
 |
|
|
Red Hat 7.2 vs. Dell Latitude C800 |
|
| |
|
Right from the outset, let me say that this page is not intended as a "HOW-TO" on installing R-H 7.2 on the Dell. Better people than me have done that I'm sure. Not only that, but there shouldn't be any need to do so. If my experiences are typical it should be easy. I just ran the initial install from the R-H 7.2 Cd, selected a LAPTOP installation, provided all the right answers to the questions, and when it was done, I installed all the additional RPMs which were not included in the basic install. It went on like a charm, and didn't break once (and hasn't during the many months since then - despite considerable maltreatment, from me, several upgrades, and a lot of software installation). However ... all good things come with a price ... and the "almost perfect" install was no exception. There were a few things I needed to sort out or customise, and many good web sites helped me with that. Two sites I used a lot are Linux on Laptops , and the comp.os.linux.portable newsgroup. What I wanted to do on these pages was to identify some of the more frustrating aspects of the post-install process, (i.e. Those for which I couldn't find a simple or accessible answer) and to make public what I eventually did to resolve them. There are only three at present, but if/as I find them (and the time), I will publish more. Problem
1 - XF86Config vs. The External Monitor
Problem 1 - XF86Config vs. The External Monitor The Situation ... After the basic installation, everything worked fine with that lovely, whizz-bang 15.1" TFT Flat Panel display, but I'm not just a road-warrior, and I use my laptop as the workstation to my server network as well. At rest I prefer to use a big CRT and a nice, old-fashioned, clicky keyboard. I always use the best resolution I can get, but I find 1280x1024 is a workable compromise in most cases. With the laptop docked in the Dell Advanced Port Replicator, everything went well in text mode, but as soon as Xfree86 started up, the monitor just went blank and switched to standby mode. When I opened the lid of the laptop, the TFT screen was glowing, but no X display. Hitting <Fn-F8> once brought up X on the TFT, and hitting it two more times got the display up on the CRT. So X was working, and it could display on the CRT, but just wasn't making the right selection on startup. What
to do about it ... N.B. - DON'T FORGET that version-4 of Xfree86 uses XF86Config-4, pre version-4 it's XF86Config. I used Xconfigurator to generate a new XF86Config-4 file, setting up the monitor, adaptor definition, and screen resolutions manually, but it still didn't work. X stubbornly refused to start up using the CRT. However it did provide me with a clean starting point. Yes ... thats right ... Before you actually go off and do any modifications, DOCK YOUR LAPTOP... OK ... now it's snug in it's port replicator, run Xconfigurator and set up the display parameters to match the CRT. DO NOT use the original setup, which probably used the TFT display. If you cannot get a display on your CRT, either re-read the second paragraph of "The Situation" above, or work on the docked laptop with the lid open and use the TFT display for now. (My thanks to Markus Rueger from Germany for bringing that little quirk to my attention). Here are abstracts from our e-mail chain which explain the issue.
The man pages related to Xfree86 configuration are pretty cryptic, and a bit of a maze, but eventually they lead you to the fact that there are options which can be set for any device driver, and that the options are specific to the driver used ... so ... Find the Device section relating to the display driver (in this case the ATI Rage Mobility chipset) and from that, get the name of the driver which XFree86 is using for your chipset. ... vis ... Section
"Device" ... man <drivername> will provide you with the available options for that driver, and the settings which can be used with this option. . In the case of most Video Devices, one of the options is "Display" and for the r128 the settings are ...
"FP" - enables the Flat Panel only - this is the default I played with each of the setings, but finally settled for using the "BIOS" setting (after making sure my Laptop BIOS was set to the default of "Dock Video Card"). So my Device section now looked like ... Section
"Device" ... and now ... The TFT display works on the road, the CRT works at home, and it selects the correct mode fully automatically. Problem 2 - NTPD vs. The Wandering Clock The Situation ... I love order in the universe, for many reasons, and one thing I can't stand is when all my clocks tell me different times. Not only is it wrong, it can lead to some pretty nasty situations if you use time-dependant applications (e.g. Conditional linking depending on last update time, or taking file-system snapshots). However, the clock in the average PC is pretty erratic, and in a lot of laptops it can be downright terrible. My Dell is no different. On the fixed network I have one of my servers retrieving the time from a few local reference clocks, and it stays in sync pretty well. All my other servers and windows machines set up as clients to this server (broadcast receivers or polling - it made no difference). The black sheep of the family was my laptop. No matter what I tried, it would catch the time, sync for a moment, but then at the next poll it would be so far out of whack that it lost sync again. This would cycle around and around and result in the following type of entries in /var/messages... Mar 8 06:58:24 xxxxx ntpd[2623]: synchronisation lost The Solution ... I couldn't find any way to get ntp to work properly, so I had to think around it. In fact, the good old Linux community had already come up with an answer ... tickadj ... Tickadj is one of those programs which people warn you about, but never say why. In fact it's a great tool if you're careful, and if you're not you can screw things up badly. Here's what I did. The values will be different in every case, but the principle is always the same. NTPd is set by default to poll the server every 64 sec approximately, but it will automatically un-sync if the time discrepancy is too large between the server and the client. If I remember correctly, the maximum allowed discrepancy is something in the order of 125 ms. In 64 secs, my clock could run well outside that. Looking at the messages in the snippet above shows that there is approximately a 9.5 second, correction every 16.5 mins, and it seemed to be fairly consistent. I reasoned that if the oscillator was slow, then I needed to adjust the Linux tick size to compensate ... The standard tick is given by tickadj as 10000, so I reset it to 10000 * (1+(9.5/(16.5*60)) or about 10096. (In the real case I averaged the resets and time intervals over 200 entries, and the numbers were slightly different, but for illustration purposes the above is OK). Since the clock was losing, the 9.5 seconds was a positive correction,. For a clock which gains, you would use a negative corrction. I then tried out the new drift using clockdiff -o localserver (multiple times) where localserver was my local network's reference clock server, and then twiddled it a bit by adding/subtracting small numbers from the calculated tick value until the accuracy was down (up?) to an acceptable discrepancy. Once an acceptable number had been worked out (10101 in my case), I included tickadj 10101 as a command in my /etc/rc.local file, to make the fix permanent. Now, at the end of my efforts, I have it running to a variable discrepancy within +- 20 ms of my reference clock server, and ntpd rarely loses sync. As a side effect, not only has it fixed my lost sync problem, but I can also use the fudge server 127.127.1.1 when I am off the network and on the road, and when I return to a stable (heh!) environment I have only lost/gained a second or two ..... to find out about 127.127.1.1 you need to read up on reference clocks and the local oscillator fudge option in the NTPD documentation. You can also find an interesting discussion of a different clock sync problem on Matthew Dixon's Linux on a Thinkpad 240X page. Addendum - 23 April, 2002 ... I used to use Gnome/Enlightenment as the preferred environment on my workstations (including the Dell Laptop) but recently, just to see how it felt, I reinstalled my system with KDE (first v 2.2 and now v 3.0). The only difference between the current system, and the previous one, is the GUI. Now I discover that my clock seems to be working perfectly, and I have been able to drop the tickadj back to its default setting of 10000. I have absolutely no idea as to why this should be the case. I would appreciate any feedback from anyone who has tried the same. Addendum - 23 October, 2002 ... I have finally found out where the problem lies. It would seem that the Gnome Battery monitor applet interferes with the system clock, causing it to stall for a few millisecond each time the APM BIOS is polled for the battery status. Over the period of an hour or two, this skew becomes very noticable ... hence the reason why I lost the problem when I switched to KDE. If you must use Gnome, disable the battery state applet and it works fine. (Thanks to David A. Cafaro for bringing this to my notice) Problem 3 - Dell's Internal Modem I will write more about this, including references to relevant articles and web pages, as and when I find time amongst all the other things I keep promising myself I will complete. In brief, I will just say that it doesn't work, and it won't work. For the moment, here is an abstract of an e-mail I sent in reply to someone's query about the internal modem ...
UPDATE - 7 March, 2003 Well here we are, almost a year further down the road, older, wiser and poorer, and suddenly I get an e-mail asking if there have been any changes in the 3C556 saga since I last updated this page. I have to admit to not following up on my original research, so I started again with checking out the places I looked last year ... and as far as I can see, things are looking rosier. Taka a good look at ... http://www.scyld.com/network/vortex.html That looks promising ... If anyone has any information they want to share with me on these, or any other tips to make a Dell C800 run better as a Linux workstation, please write to me using the link below. I will gladly incorporate any useful contributions into this page, and (of course) contributors will be acknowledged, and a link added.Have fun ..... Kevin Salt |
| Page Last Modified - 22 April, 2002 | This site is sponsored, maintained and hosted by  |
Trib Design - Site Stats |