“One step forward and three steps back” must’ve been the guiding force for my first day back from vacation yesterday, where I struggled both mightily and frantically to get my working life back on the rails after a blissful 6 days of vacation bracketed by a full day of travel to and from the lovely and cool mid-coast region of Maine. Before my departure, I’d been seeking diagnosis and cure of an ongoing series of network failures on my home LAN which currently includes 10 computers: 6 running some form of Windows 7, one each XP and Vista, one running a Fedora-based Linux image (an OLPC that I supposedly bought for my son), and one running whatever GNU/Linux version the Nintendo Wii uses, plus my D-Link DIR 655 router/switch/WAP and my D-Link 2100AWL 802.11 g wireless hub.
By the time I left town to hit the Maine beaches and attractions, I’d determined by trial and error that my network failures would cease when I removed the cable coming from the network interface on the Asus P5E3 Pro motherboard in one of my machines named A900Test. To fix the problem, I purchased a D-Link DGE-530T 10/100/1000 PCI network adapter at my local Fry’s before leaving town. Upon my return to work, after I got through e-mail, and met all of yesterday’s immediate deadlines, I decided to disable the NIC on the Asus motherboard in A900Test, and to install the D-Link NIC in its place.
After installing the 530T in that machine, I found myself in the rare position of rebooting to have Windows 7 tell me it couldn’t find a driver for the NIC by itself. This is the first time Windows 7 has come up short in this regard in the year-and-a-half-plus that I’ve used this OS, starting with Build 7000 way back in January 2009. “No problem,” I thought, “I’ll just use the drivers on the CD that comes with the NIC.” But there, I found my only option was to use x64 Windows Vista drivers, since the card itself is old enough that it apparently predates the official Windows 7 release date in late October, 2009.
Again my thought was “No problem, I’ll just download the newer Windows 7-friendly drivers to a UFD on another machine, then install them on this one.” But when I did so, I got an error message from the D-Link installer informing me that another network control program was present on my machine that had to be removed before the D-Link installer (and its drivers) would install on my machine. “No problem” I said to myself “I’ll use Universal Extractor to suck the necessary driver files out of the setup.exe program and then install the drivers via Driver Update in Device Manager.” No dice: Device Manager politely informed me it could find no suitable drivers in the $INSTDIR that Universal Extractor created for me with all of the .sys, .cat, .dll, and .inf files that supply drivers to Windows 7 (and other OSes) these days.
“Aargh!” I thought to myself “Time for a call to D-Link tech support.” I shouldn’t have bothered. After a nice but fairly ignorant support tech named Seetha ran me through everything I’d already tried myself (with regular pauses for her to consult with some more knowledgeable third party, she had me uninstall the unidentified Ethernet NIC in Other Devices in Device Manager, then re-run the installer several times), she informed me I would have to return the card for a replacement to Fry’s and try again. I *KNEW* this to be bogus advice, because my problem was that the installer wouldn’t run, not that the hardware wouldn’t work (you can’t really tell the hardware isn’t working properly, in fact, until you have a working driver installed and running).
Upon trolling through Programs and Features in Control Panel, and reading through various items in the aforementioned $INSTDIR directory that Universal Extractor created for me, I saw numerous entries named yk*.*. Subsequent inspection of the readme file also unpacked in this directory informed me the NIC includes a Marvell Yukon GbE chipset. At this point, I finally realized that the D-Link card incorporates the same chipset that my on-board Asus NIC also uses.
Mystery solved: I had to uninstall the Marvell Control Program in Programs and Features before the D-Link installer program could do its job, after which everything went as smooth as silk. My question to D-Link is “Why doesn’t your standard 530T script for first-level Tech Support people include a question like ‘What kind of NIC chipset does your motherboard use?’” If that were the case, Seetha could have told me to uninstall the Marvell Control Program, and informed me that installation would proceed without further trouble. I’m just glad I know enough about how networking operates in the Windows environment to be able to figure this kind of thing out for myself.
Sigh. And so it goes… At least the network is working properly, and I’ve experienced no further LAN failures since I successfully installed the 530T on my primary test machine. I’m crossing my fingers that this will fix my network glitches going forward, but only time will tell. FYI, I’m forwarding this blog to a couple of D-Link PR people and requesting a response, which I’ll add to this posting should any such reply make its way into my inbox.
[Note added 7/29/2010: I did get a "looking into it" reply from one of the D-Link PR people to whom I sent a link to this blog, but nothing more substantial in reply just yet. Stay tuned! -E-]