Skip to main content

At Work with Linux: Fedora 17 on a Latitude E6510 (UPDATED)

Fedora 17 base install with Gnome 3 before a massive update
I spent the majority of last week at an integration event. Part of the toolkit I took with me was a Dell Latitude E6510 with RHEL 6.3 installed. Running on top of that was VMware Player to host several VMs that ran additional systems as part of the event. I'd also installed Google's exfat driver to support a 64GB SDXC card and additional drivers from EPEL to support a 500GB LaCie external drive formated as NTFS. It was a decent enough system, and certainly supported the integration event to a very successful conclusion.

When I got back home, however, I wanted a more advanced kernel on the notebook, one that had a chance of supporting the E6510's wifi wireless chipset. The older driver under RHEL couldn't see it (or I never saw it with the tools), so I installed Fedora 17 to get at least the drivers installed. Sure enough, dmesg logs that the Intel wifi chipset was found and enabled on boot:

[ 5.406423] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1 build 25532
[ 5.416058] cfg80211: World regulatory domain updated:
[ 5.416061] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 5.416063] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5.416064] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 5.416065] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 5.416067] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5.416068] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5.428513] iwldvm: Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:d
[ 5.428516] iwldvm: Copyright(c) 2003-2012 Intel Corporation
[ 5.428533] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG enabled
[ 5.428535] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS enabled
[ 5.428537] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[ 5.428539] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
[ 5.428541] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P disabled
[ 5.428543] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74
[ 5.428648] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 5.428968] iwlwifi 0000:03:00.0: RF_KILL bit toggled to disable radio.
[ 5.448659] iwlwifi 0000:03:00.0: device EEPROM VER=0x43a, CALIB=0x6
[ 5.448670] iwlwifi 0000:03:00.0: Device SKU: 0x1F0
[ 5.448675] iwlwifi 0000:03:00.0: Valid Tx ant: 0x7, Valid Rx ant: 0x7

iwconfig and lspci also show the hardware as present.

I'm certainly no expert this deep into the kernel, but the statement flagged above concerns me abou the RF_ILL bit being toggled to disable the radio. This, of course, fits in with all the userland tools telling me that the wireless hardware is disabled. As usual, a concentrated search via Google shows a world of hurt with regards to this radio. So much for installing a May 2012 Fedora release on a machine that is over two years old. Oddly enough, everything else seems to work, including the open nVidia drivers for both the desktop effects as well as something as mundane as playing DVDs. And I'm well past the point where I care one way or the other about Gnome 3. Yes, that's the director's cut of Bladerunner I'm watching/listening to while trying to debug the wireless problem.

Fedora 17 after update and with a decent wallpaper, playing Bladerunner via VLC
I think on the end I'll install a copy of Win2k8. I have no desire to try and google for the one lone thread that might give me a clue on how to enable wireless with this particular situation. I got too much to do and too few cycles to debug something that looks like it's fully supported, at least in the kernel (maybe).

Update

Well, I did something I at first swore I wouldn't do. I downloaded the source to the kernel and went looking for the logging message I highlighted above. It has been six years or so since I downloaded kernel source and played around with it. That was when I was running openSUSE and I was writing a generic USB driver for a then-new high resolution digital camera. I wrote the driver and was able to attach the camera to the system in support of an image processing project I was working on at the time. Once that was done I never looked inside the kernel sources again.

Imagine my surprise when I decided to get the sources for kernel version 3.6.2-4.fc17.x86_64. I finally found some fairly convoluted instructions here (Building a Kernel from the source RPM), and followed them well enough to at least get the sources that matched the running kernel. Gone are the days when I could go to kernelorg, download a bziped source tarball, unpack it, apply any patches, and work from there. Those seem like the good old days...

In any event, after a bit of grepping I managed to find how the logging message was constructed in drivers/net/wireless/iwlwifi/pcie/rx.c:

 /* HW RF KILL switch toggled */
 if (inta & CSR_INT_BIT_RF_KILL) {
  bool hw_rfkill;

  hw_rfkill = iwl_is_rfkill_set(trans);
  IWL_WARN(trans, "RF_KILL bit toggled to %s.\n",
    hw_rfkill ? "disable radio" : "enable radio");

  isr_stats->rfkill++;

  iwl_op_mode_hw_rf_kill(trans->op_mode, hw_rfkill);

  handled |= CSR_INT_BIT_RF_KILL;
 }

Such is the nature of this particular message that I had to look for fragments by trimming words away from the full message, starting at the end of the message and moving towards the front, until finally I found this. If you understand a bit of C programming, the message is constructed by the conditional result inside a ternary operator (?:). Basically if the RF_KILL bit is set then you get the logging message that the radio is disabled.

I have tried to unwind a bit of the code that leads to this point, but the most essential information I need, how the chip set in the 6300 works, is no where to be found on the web. At this point I really have no cycles to devote to trying to understand why this particular WiFi system isn't working by reverse engineering the driver source.

Oh. And as a quick check, I downloaded the latest Ubuntu (12.10) live CD and gave that a spin. Dmesg output shows the same logging message, so rather than trying to see if it would work under Ubuntu I decided to go back to Fedora and think about what to do next. I may just install Win2k8 R2 and be done with this. At least I can find working Windows drivers.

Comments

Popular posts from this blog

cat-in-a-box channels greta garbo

So I'm sitting at my computer, when I start to notice a racket in back. I ignore it for a while until I hear a load "thump!", as if something had been dropped on the floor, followed by a lot of loud rattling. I turn around and see Lucy in the box just having a grand old time, rolling around and rattling that box a good one. I grab the GX1 and snap a few shots before she notices me and the camera, then leaps out and back into her chair (which used to be my chair before she decided it was her chair).

Just like caring for Katie my black Lab taught me about dogs, caring for Lucy is teaching me about cats. She finds me fascinating, as I do her. And she expresses great affection and love toward me without coaxing. I try to return the affection and love, but she is a cat, and she takes a bat at me on occasion, although I think that's just her being playful. She always has her claws in when she does that.

She sits next to me during the evening in her chair while I sit in mi…

vm networking problem fixed

Over the weekend I upgraded to Windows 8.1, then discovered that networking for the virtual machines wouldn't work. Then I tried something incredibly simple and fixed the problem.

Checking the system I noticed that three VMware Windows services weren't running; VMnetDHCP, VMUSBArbService, and VMwareNatService. VMware Player allows you to install, remove, or fix an existing installation. I chose to try fixing the installation, and that fixed the problem. The services were re-installed/restarted, and the virtual machines had networking again.

Once network connectivity was established there was exactly one updated file for Ubuntu 13.10, a data file. This underscores how solid and finished the release was this time. Every other version of every other Linux installation I've ever dealt with has always been succeeded by boatloads of updates after the initial installation. But not this time.

Everything is working properly on my notebook. All's right with the world.

sony's pivotal mirrorless move

I'm a died-in-the-wool technologist, even when it comes to photography. I have always been fascinated with the technology that goes into manufacturing any camera, from the lenses (optics) through the mechanical construction, the electronics involved, and especially the chemistry of the film and the sophistication of the digital sensor. It's amazing that the camera can do all it's asked of it, regardless of manufacturer.

Of all the types of cameras that I've really taken an interest in, contemporary mirrorless (again, regardless of manufacturer) are the most interesting because of the challenging problems the scientists and engineers have had to solve in order to build a compact but highly functional camera. In particular I've followed the sensor advances over the years and watched image quality climb (especially with μ4:3rds) to exceed film and rival one another such that there's very little difference any more as you move from the smaller sensors such as 4:3r…