Core 7 on Dell
( f.welland at verizon dot net )
Last update on: Saturday, November, 17 2007
Once again, I have moved to the latest and greatest from Fedora. Here is my Fedora 8 page.
- Disc Prep
- Hardware Matrix
- The Install
- Wireless (with monitor mode support)
- Some Annoyances
(e.g. System Beep -- again!!!)
- Links & Links
- (Warning) USB
& Flashdrives -- FIXED with UDEV updates
- Big YUM update on 8/2/2007
NVS 110M |
out of the
box with x.org 'nv' driver. Graphical installer works well
required tweaks |
|CPU || Intel CPU
T2500 @ 2.00GHz ||Works
1920 x 1200
|Works out of
box at 1920x1200 resolution |
Drive ||Hitachi HTS721010G9SA00 |
Corporation 82801G (ICH7 Family) High Definition
Audio Controller |
out of the
PRO/Wireless 3945ABG ||works
poorly to get
better operation tweaks are needed |
Corporation NetXtreme |
BCM5752 Gigabit Ethernet PCI Express
|Works out of
||NEC DVD +/- RW ND-6650A ||CD
seems OK --
DVD & Write tests still pending |
|IRDA || ||Do not know
(not sure I care) |
|| ||Do not Know (not sure I care)
ALPS GlidePoint ||Works
out of the
of the box |
again, I 'upgraded'
perfectly good linux laptop to the latest and greatest from Fedora:
Fedora 7. If you poke around,
you'll see that
I have been through FC5
with this laptop. I have had pretty good luck with FC and RH
so why not upgrade?
you see, much of this page is a copy-n-paste job from my FC5 and FC6
pages. In fact much of what was done for FC5 and/or FC6
still applies to FC7. Reading those pages
of things maybe omitted from this page, but mentioned on the other
was 'just stick in the DVD and
let it rip', I am going to highlight some stuff that may not be
related to installing F7 on my Dell D820 but might be helpful
this 'howto' or 'my experiences'
page, was started about 4-6 weeks after
I installed F7. I think becuase, I waited to write this, it
covers somethings that I did after the initial install that I otherwise
may not have documented.
Since I already sliced up this disk for the FC5
install and for
least from a WinXP vs FC perspective, I didn't need to do
here (already had a place for Fedora and WinXP). But then
again, why did I have all these partitions under FC5
don't recall utilizing my FS in such a fashion that lots
provided some 'advantage'. Since I like to start with a fresh
install, I decided to collapse the partitions
into one root, and of course one for swap (and leave the WinXP
step I took
before the repartition, was to back up my FC6 stuff to my
home-grown NAS thing. Once again, I didn't back up anything
WinXP partition -- there really wasn't anything of value to loose there
if things went wrong (they didn't).
is how the partitions turned out:
Basically, I stuck the F7, DVD in and rebooted into the installer
and let it rip. Like I did for FC6, I used my desktop FC6
BT grab the DVD ISO. The ISO was burned
to a DVDr via a LG DVD burner in a USB enclosure. I just
the gnome burner widget to make the DVD. It seems that F7
officially comes as a DVD. This didn't pose any problems for
D820, but did for the desktop I made the DVD on when I went to
install F7 on that box. See here
not much to add; I just
followed the intaller making my selections and then let the install 'do
boot I did do the
I have no reason to do this other than I don't know if
brings me anything. My assumption is no. Please
forget the name of the option on the set time step - but F7 added a
comment about what set the check box too if you dual boot into a
Windows -- I followed its recomendations FC6 didn't such a
comment (that I recall), and I guessed wrong. My
time was always
after booting back into FC6 from my infrequent visits into Win XP.
FC5 and FC6, F7 has lots of beebs.
I turned a bunch of them off doing the following.
Here is how
I killed most of them:
select the 'System Beep' tab
- uncheck 'Enable
- get rid of beeps in a console
(<ctl><alt>F1 and other
/etc/inputrc and make sure 'set bell-style' is set to
I use the NVIDIA proprietary driver on my D820. In general, I
am frustratingly pleased with this driver and NVIDIA graphics hardware
under Linux/Fedora. For details on how I install the driver,
refer to the FC5 and FC6 pages. BUT, here are
things (as of July
2007), that may
not be unique to F7 or a D820, but I
encountered while installing F7 on my D820:
use the NVIDIA 'run' installers. I do not use the RPM/YUM
stuff that is out there for the NVIDIA drivers. There is
lots of 'talk' that says you should use the RPMs not the installer.
I haven't had too many problems with the NVIDIA installer and
see no reason to switch from something that is working to something
that probably works (but I don't know). YMMV...
Shutdown Hangs with Compiz
will hangup when you logoff or shutdown if you have had having
compiz/metacity running and using one of the 100.14.* series drivers.
The slightly older versions, 1.0-9755 and 1.0-9762, do not
have this problem. I also experienced the same
exact problem with my desktop
It seems to be a fairly prevelant problem; this
one of many forum threads on this. Rolling back to
whatever reason, if you install one the the 100.14.* series drivers,
under F7 rolling back to a 1.0-97xx driver doesn't work just right.
The 1.0.-97xx doesn't really complain about anything unusual
(that I saw). But when you restart your X, you will get a
'nvidia' module not found in the XOrg log file in /var/log.
After scraping through NVNEWS forums some (especially the shutdown
thread from above), I found the following command line used to start
installer resolves the problem (so maybe I should use the RPMs...).
-showDefaultModulePath 2>&1 | cut -d, -f1`
--x-library-path=`X -showDefaultLibPath 2>&1`
(GPU Temp and GNOME sensors)
gnome-sensors applet has the ability monitor NVIDA GPU temps.
In order do this you need libXNVCtrl.a. The lib is
part of the NVidia settings package; it also maybe part of or is linked
the NVIDIA Server settings application that gets installed with the
driver. However, gnome-sensors will need the .h files; so I
found that the NVIDIA settings package is needed even if the lib is
hanging around somewhere. Here is a
play by play on how I compiled libXNVCtrl.a
NVIDIA settings (ftp://download.nvidia.com/XFree86/nvidia-settings/nvidia-settings-1.0.tar.gz)
don't need to build all of it
(you already have the application if you installed the NVIDIA driver),
just the lib part. So untar it and cd to
nvidia-settings-1.0/src/libXNVCtrl and read the file
- Do what the directions
in README.LIBXNVCTRL say. Notice that those directions and
build do not
read this thread
(if you want).
- In the
nvidia-settings-1.0/src/libXNVCtrl directory make a new makefile with
the following contents (call it whatever you want):
NVCtrl.o : NVCtrl.h nv_control.h
rm -f libXNVCtrl.a *.o
- Run the makefile you made in step 5.
(use something like 'make -f mymakefile').
'install' this lib and .h files, I copied libXNVCtrl.a to
/usr/local/lib and copy nvidia-settings-1.0/src/libXNVCtrl
to /usr/local/include/NVCtrl (you will probably need
to create /usr/local/include/NVCtrl).
Do somthing useful with libXNVCtrl.a such as use it by lm_sensors and
COMPIZ Works Nicely
at least a bit nicer than under FC6. I don't recall all the
tweaks I did to get it to work, but here is my xorg.conf
there, I wanted to get some feed back from hardware temperature
sensors. I actually don't have any reason to believe that I
heat problems or stuff like that; I just wanted to get them to work.
There are a few tools for monitoring the sensors;
to just use gnome-sensors.
seems to able to get
sensor data from several places. The two (or three) that are
interest (at this moment) are GPU and CPU core temperatures (the 3rd is
ACPI which will expose some temperture to gnome-sensors w/o doing
anything -- but is not clear what this temperature is). The
easiest way to get lm_sensors working is: http://www.lm-sensors.org/wiki/iwizard/1
kernel contains 'coretemp' driver; older F7 kernels didn't seem to have
it. coretemp is a needed piece of the puzzel; it provide
temperture data for core duo processors. sensors-detect
will/may generate modprobe commands for it; but clearly that won't work
if you don't have the driver.
- to get GPU
gnome-sensors you need the libXNVCtrl.a as discussed above.
additions to the above here is a 'HackTo' I dumped to NVNews about
my final product:
- Somewhere around 8/10/2007, a lm_sensors and gnome-sensors updates came thru. The updated gnome-sensors now seems to support libXNVCtrl.
So you may not need to do all the stuff I mentioned to get NVIDIA
GPU temps from gnome-sensors (you'll still need libXNVCtrl).
F7 installer did find my
Intel 3945 card and installed a driver. With minimal
was able to use it! Also, since it wasn't easily obvious how
turn on/off (i.e. load/unload) this driver
like I had done with ipw3945 under FC6, I started using NetworkManager.
Once I got used to it, NetworkManager works well.
much more gooder/friendlier to tinker with NetworkManager's
little applet for futzing with wireless settings than it is to fiddle with
the scripts that I used to use.
All is not
F7 uses the new iwlwifi drivers. Go here for more
about this driver. I think is supposed to replace the older
ipw3945 drivers, in the near future. One positive
about this driver is there is no need run the regulatory deamon like is
needed by ipw3945. However, I think the driver is a bit
cooked and seems sluggish:
browsing seemed 'slower' than with ipw3945
no problems using Cisco VPN and rdesktop via ipw3945, but
iwl3945 really struggled to adequately do rdesktop via vpn.
ignored these for about 4 weeks (well I resorted to wired ethernet with
VPNing), untill kernel 18.104.22.168-27.fc7 came out and I upgraded:
iwl3945 stop working.
update with a
day or two of the .22 kernel, which I presume fixed the problem - but I
switched (back) to
ipw3945. For me ipw3945 just works better:
faster browsing and no problems VPNing and rdesktoping.
I mostly followed these http://forums.fedoraforum.org/forum/showthread.php?t=157205
directions to set up my ipw3945. Here is what I
did to install ipw3945 under with F7 that it will
load at startup and NetworkManager behaves nicely with it:
ipw3945 source code (I am using ipw3945-1.2.1 -- http://prdownloads.sourceforge.net/ipw3945/ipw3945-1.2.1.tgz?download)
ipw3945 regulartory deamon (I am using
ipw3945d-1.7.22 -- http://bughost.org/ipw3945/daemon/ipw3945d-1.7.22.tgz)
- get ipw3945 firmware
(I am using ipw3945-ucode-1.14.2 -- http://bughost.org/ipw3945/ucode/ipw3945-ucode-1.14.2.tgz)
that your ieee80211 is OK. It needs to be version 1.1.11 or
newer. Kernel 22.214.171.124-27.fc7 appears to
have git-1.1.13 of ieee80211.
ipw3945 (a simple 'make' should do it)
all the ipw3945 parts to the correct places:
ipw3945-ucode-1.14.2/ipw3945-ucode /lib/firmware && cp
- 'make install' in
the ipw3945 intall directory seemed to copy the dirver into the correct
list the iwl3945 stuff by adding
blacklist iwl3945 blacklist mac80211,
to the /etc/modprobe.d/blacklist file. Are there
other ways to tell Fedora to not load a driver?
or make a ipw3945 startup script and put it in
/etc/rc.d/init.d. As per the link above, I got one from:
(make sure it is executable)
this ipw3945 start up script with something like: chkconfig
ipw3945 && chkconfig ipw3945 on (not
entirely sure what
these two commands do - but it will make ipw3945 show up in the
doesn't appear to have support for assigning static IPs to network
connections (for example, on wireless network A, I want DHCP; but on
network B, I want this IP, gateway etc). Yes, you
can use some of the fedora and command line tools, such as
system-config-network and ifconfig to handle static IPs for the
interface. BUT does anybody know of any other ways to trick NM to maybe run a chuck of script or something when bringing an if up?
I had been using iwl3945 there was already a device 'wlan0' registered
on my system. So I didn't need to add one, ipw3945 just 'took
over' that device.
- On my D820 under iwl3945 the
wifi led never
lit up - which I was mostly ok with -- I could see it working via
NetworkManager. With, ipw3945 it lights up: It
while scanning and not associated with an AP & is solid while
associated (or so it seems to me). Why didn't iwl3945 light
the led? For some reason, when I am hard wired to a LAN, I
like I shouldn't be letting my radio continously scan (95% of the time
I run AC - so battery isn't much of a concern). With
this didn't really bother me much because there is no visual clue it is
scanning. But it is highly annoying with ipw3945.
Apart from annoying flicker, are there any downsides to just
letting my radio scan for hours on end while hard wired to a LAN.
- Around 8/10/2007, I needed to run KISMET
(very neat tool!). KISMET needs monitor mode to be enabled
at the driver level. IPW3945 does appear to have support for
this. I pulled the latest IPW3945 source code (ipw3945-1.2.2 -- http://prdownloads.sourceforge.net/ipw3945/ipw3945-1.2.2.tgz?download)
and yummed up KISMET. To enable monitor mode, you
recompile IPW3945 with a few MAKE parameters set to yes/on.
I edited the make file and uncommented or otherwise set
CONFIG_IPW3945_PROMISCUOUS, and CONFIG_IPW3945_SIM_RX to 'y' and
recompiled and installed the driver (as per above). After
doing this, kismet seems to work fine.
USB And Automounting Kernel
126.96.36.199-27.fc7 has introduced some evilness such that some/lots (maybe
all) USB devices/drive are not automounted. My D820 suffers
from this. As of 7/29/2007, this is still the case and the
lastest '33' kernel still seems to have problems.
8/2/2007 and 8/3/2007, there emerged some 'noise' on the above thread
about this problem. Please go and read the thread; but the
abbrieviated version is that is look like the issue is really a udev
issue and a fix is due any day now. Some folks report success
with tweaking udev rules.
you are following thism, especially the thread mentioned above, then
you may already know that UDEV package udev-113-8.fc7 appears to
fix the problem with automount USB flash devices. For me,
the update does indeed work!
JavaJava/SWING programs have redraw problems under compiz & beryl. Here is a bug about the problem: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6429775.
If you poke around the web you'll find lots of people with this
problem, running a variety of VM's. Maybe it is fixed in
1.6 JDK, but I am sticking with 1.5 for a bit more. One work
around, that I have had good results is by adding:
to my environment before running a SWING application. This, of
course, require that some version of MOTIF be available (this variable
appears to tell SWING/AWT to use the motif toolkit rather than
...whatever else it can use). I just YUMEX'ed lesstif.
lesstif-devel-0.95.0-15.fc7 and was able to run SWING stuff.
YUM Update to Kernel 188.8.131.52-41.fc7After
the USB problems introduced by 184.108.40.206-27.fc7, I have been gunshy to
take kernel updates. For me fedora kernel updates have always
been pretty painless but that changed somewhat
with 220.127.116.11-27.fc7. Throwing caution into the
wind, I accepted about 20 RPMs via YUM on 8/3/2007, including kernel
18.104.22.168-41.fc7. Some spelunking revelealed that it probably
didn't fix USB problem and I was curious why I was even
bothering...well I did it and am please to say it is fine. Like
'usual' I had to rebuild the ipw3945 driver and re-run the NVIDIA
installer; but after that, things on my D820 are fine.