Shallow Thoughts : : Aug

Akkana's Musings on Open Source Computing and Technology, Science, and Nature.

Sat, 25 Aug 2007

Widescreen Monitor, Intel Graphics on Ubuntu

On a seemingly harmless trip to Fry's, my mother got a look at the 22-inch widescreen LCD monitors and decided she had to have one. (Can't blame her ... I've been feeling the urge myself lately.)

We got the lovely new monitor home, plugged it in, configured X and discovered that the screen showed severe vertical banding. It was beautiful at low resolutions, but whenever we went to the monitor's maximum resolution of 1680x1050, the bands appeared.

After lots of testing, we tentatively pinned the problem down to the motherboard. It turns out ancient machines with 1x AGP motherboards can't drive that many pixels properly, even if the video card is up to the job. Who knew?

Off we trooped to check out new computers. We'd been hinting for quite some time that it might be about time for a new machine, and Mom was ready to take the plunge (especially if it meant not having to return that beautiful monitor).

We were hoping to find something with a relatively efficient Intel Core 2 processor and Intel integrated graphics: I've been told the Intel graphics chip works well with Linux using open source drivers. (Mom, being a person of good taste, prefers Linux, and none of us wanted to wrestle with the proprietary nvidia drivers). We found a likely machine at PC Club. They were even willing to knock $60 off the price since she didn't want Windows.

But that raised a new problem. During our fiddling with her old machine, we'd tried burning a Xubuntu CD, to see if the banding problem was due to the old XFree86 she was running. Installing it hadn't worked: her CD burner claimed it burned correctly, but the resulting CD had errors and didn't pass verification. So we needed a CD burned. We asked PC Club when buying the computer whether we might burn the ISO to CD, but apparently that counts as a "data transfer" and their minimum data transfer charge is $80. A bit much.

No problem -- a friend was coming over for dinner that night, and he was kind enough to bring his Mac laptop ... and after a half hour of fiddling, we determined that his burner didn't work either (it gave a checksum error before starting the burn). He'd never tried burning a CD on that laptop.

What about Kinko's? They have lots of data services, right? Maybe they can burn an ISO. So we stopped at Kinko's after dinner. They, of course, had never heard of an ISO image and had no idea how to burn one on their Windows box. Fearing getting a disk with a filesystem containing one file named "xubuntu-7.04-alternate-i386.iso", we asked if they had a mac, since we knew how to burn an ISO there. They did, though they said sometimes the CD burner was flaky. We decided to take the risk.

Burning an ISO on a mac isn't straightforward -- you have to do things in exactly the right order. It took some fast talking to persuade them of the steps ("No, it really won't work if you insert the blank CD first. Yes, we're quite sure") and we had to wait a long time for Kinko's antivirus software to decide that Xubuntu wasn't malware, but 45 minutes and $10 later, we had a disc.

And it worked! We first set up the machine in the living room, away from the network, so we had to kill aptitude update when the install hung installing "xubuntu-desktop" at 85% (thank goodness for alternate consoles on ctl-alt-F2) but otherwise the install went just fine. We rebooted, and Xubuntu came up ... at 1280x1024, totally wrong. Fiddling with the resolution in xorg.conf didn't help; trying to autodetect the monitor with dpkg-reconfigure xorg crashed the machine and we had to power cycle.

Back to the web ... turns out that Ubuntu "Feisty" ships with a bad Intel driver. Lots of people have hit the problem, and we found a few elaborate workarounds involving installing X drivers from various places, but nothing simple. Well, we hadn't come this far to take all the hardware back now.

First we moved the machine into the computer room, hooked up networking and reinstalled xubuntu with a full network, just in case. The resolution was still wrong. Then, with Dave in the living room calling out steps off a web page he'd found, we began the long workaround process.

"First," Dave suggested, reading, "check the version of xserver-xorg-video-intel. Let's make sure we're starting with the same version this guy is."

dpkg -l xserver-xorg-video-intel ... "Uh, it isn't installed," I reported. I tried installing it. "It wants to remove xserver-xorg-video-i810." Hmm! We decided we'd better do it, since the rest of the instructions depended on having the intel, not i810, driver.

And that was all it needed! The intel driver autodetected the monitor and worked fine at 1680x1050.

So forget the elaborate instructions for trying X drivers from various sources. The problem was that xubuntu installed the wrong driver: the i810 driver instead of the more generic intel driver. (Apparently that bug is fixed for the next Ubuntu release.)

With that fix, it was only a few more minutes before Mom was happily using her new system, widescreen monitor and all.

Tags: , ,
[ 14:23 Aug 25, 2007    More linux | permalink to this entry | ]

Tue, 21 Aug 2007

Oh, you wanted to use your LCD monitor at one pixel per pixel?

Dave and I are helping my mom shop for a new computer to drive a 22-inch widescreen monitor, 1680x1050 (long story, more on that later). This is how we find ourselves in Circuit City staring at a candidate PC on the lower shelf running a 19-inch widescreen at 1440x900. Unfortunately that's not the resolution we were hoping to check.

There's an unplugged 22-inch LCD on the shelf right above it, just like the one we're trying to get working. A salesguy comes by and ask if we have any questions, so I ask him, "Is there any way we can plug that monitor into this computer to see if it works?" and explain our mission.

He's amenable, and plugs it in, but Windows doesn't notice the new monitor. I try Display Settings but it's still maxed out at 1440x900.

I ask the salesguy, "Can we try rebooting or something? Maybe that'll make Windows see it."

He looks puzzled. "But it's already running a widescreen monitor."

I point to the Display Settings window. "But it's only running at 1440x900, and that's the most it'll let us use."

He says, "Oh, you wanted to run that 22-inch at full resolution?"

Me: "Well, yeah."

Salesguy: "But ... then your text will be small!"

Tags:
[ 11:42 Aug 21, 2007    More humor | permalink to this entry | ]

Sat, 18 Aug 2007

The Importance of Being ESSID (simple Linux wi-fi troubleshooting)

I'm forever having problems connecting to wireless networks, especially with my Netgear Prism 54 card. The most common failure mode: I insert the card and run /etc/init.d/networking restart (udev is supposed to handle this, but that stopped working a month or so ago). The card looks like it's connecting, ifconfig eth0 says it has the right IP address and it's marked up -- but try to connect anywhere and it says "no route to host" or "Destination host unreachable".

I've seen this both on networks which require a WEP key and those that don't, and on nets where my older Prism2/Orinoco based card will connect fine.

Apparently, the root of the problem is that the Prism54 is more sensitive than the Prism2: it can see more nearby networks. The Prism2 (with the orinoco_cs driver) only sees the strongest network, and gloms onto it. But the Prism54 chooses an access point according to arcane wisdom only known to the driver developers. So even if you're sitting right next to your access point and the next one is half a block away and almost out of range, you need to specify which one you want. How do you do that? Use the ESSID.

Every wireless network has a short identifier called the ESSID to distinguish it from other nearby networks. You can list all the access points the card sees with: 

iwlist eth0 scan
(I'll be assuming eth0 as the ethernet device throughout this article. Depending on your distro and hardware, you may need to substitute ath0 or eth1 or whatever your wireless card calls itself. Some cards don't support scanning, but details like that seem to be improving in recent kernels.)

You'll probably see a lot of ESSIDs like "linksys" or "default" or "OEM" -- the default values on typical low-cost consumer access points. Of course, you can set your own access point's ESSID to anything you want.

So what if you think your wireless card should be working, but it can't connect anywhere? Check the ESSID first. Start with iwconfig: 

iwconfig eth0
iwconfig lists the access point associated with the card right now. If it's not the one you expect, there are two ways to change that.

First, change it temporarily to make sure you're choosing the right ESSID: 

iwconfig eth0 essid MyESSID

If your accesspoint requires a key, add key nnnnnnnnnn to the end of that line. Then see if your network is working.

If that works, you can make it permanent. On Debian-derived distros, just add lines to the entry in /etc/network/interfaces: 

wireless-essid MyESSID
wireless-key nnnnnnnnnn

Some older howtos may suggest an interfaces line that looks like this:
up iwconfig eth0 essid MyESSID
Don't get sucked in. This "up" syntax used to work (along with pre-up and post-up), but although man interfaces still mentions it, it doesn't work reliably in modern releases. Use wireless-essid instead.

Of course, you can also use a gooey tool like gnome-network-manager to set the essid and key. Not being a gnome user, some time ago I hacked up the beginnings of a standalone Python GTK tool to configure networks. During this week's wi-fi fiddlings, I dug it out and blew some of the dust off: wifi-picker.

You can choose from a list of known networks (including both essid and key) set up in your own configuration file, or from a list of essids currently visible to the card, and (assuming you run it as root) it can then set the essid and key to whatever you choose. For networks I use often, I prefer to set up a long-term network scheme, but it's fun to have something I can run once to show me the visible networks then let me set essid and key.

Tags: , , ,
[ 15:44 Aug 18, 2007    More linux | permalink to this entry | ]

Sun, 12 Aug 2007

Powertop BOF at Linuxworld 2007

The best thing at Linuxworld was the Powertop BOF, despite the fact that it ended up stuck in a room with no projector. The presenter, Arjan van de Ven, coped well with the setback and managed just fine.

The main goal of Powertop is to find applications that are polling or otherwise waking the CPU unnecessarily, draining power when they don't need to. Most of the BOF focused on "stupid stuff": programs that wake up too often for no reason. Some examples he gave (many of these will be fixed in upcoming versions of the software):

And that's all just the desktop stuff, without getting into other polling culprits like hal and the kernel's USB system. The kernel itself is often a significant culprit: until recently, kernels woke up once a millisecond whether they needed to or not. With the recent "tickless" option that appeared in the most recent kernel, 2.6.22, the CPU won't wake up unless it needs to.

A KDE user asked if the KDE desktop was similarly bad. The answer was yes, with a caveat: Arjan said he gave a presentation a while back to a group of KDE developers, and halfway through, one of the developers interrupted him when he pointed out a problem to say "That's not true any more -- I just checked in a fix while you were talking." It's nice to hear that at least some developers care about this stuff! Arjan said most developers responded very well to patches he'd contributed to fix the polling issues.

(Of course, those of us who use lightweight window managers like openbox or fvwm have already cut out most of these gnome and kde power-suckers. The browser issues were the only ones that applied to me, and I certainly do notice firefox' polling: when the laptop gets slow, firefox is almost always the culprit, and killing it usually brings performance back.)

As for hardware, he mentioned that some linux LCD drivers don't really dim the backlight when you reduce brightness -- they just make all the pixels darker. (I've been making a point of dimming my screen when running off batteries; time to use that Kill-A-Watt and find out if it actually matters!) Wireless cards like the ipw100 use a lot of power even when not transmitting -- sometimes even more than when they're transmitting -- so turning them off can be a big help. Using a USB mouse can cut as much as half an hour off a battery. The 2.6.23 kernel has lots of new USB power saving code, which should help. Many devices have activity every millisecond, so there's lots of room to improve.

Another issue is that even if you get rid of the 10x/sec misbehavers, some applications really do need to wake up every second or so. That's not so bad by itself, but if you have lots of daemons all waking up at different times, you end up with a CPU that never gets to sleep.

The solution is to synchronize them by rounding the wakeup times to the nearest second, so that they all wake up at about the same time, and the CPU can deal with them all then go back to sleep. But there's a trick: each machine has to round to a different value. You don't want every networking application on every machine across the internet all waking up at once -- that's a good way to flood your network servers. Arjan's phrase: "You don't want to round the entire internet" [to the same value].

The solution is a new routine in glib: timeout_add_seconds. It takes a hash of the hostname (and maybe other values) and uses that to decide where to round timeouts for the current machine. If you write programs that wake up on a regular basis, check it out. In the kernel, round_jiffies does something similar.

After all the theory, we were treated to a demo of powertop in action. Not surprisingly, it looks a bit like top. High on the screen is summary information telling you how much time your CPU is spending in the various sleep states. Getting into the deeper sleep states is generally best, but it's not quite that simple: if you're only getting there for short periods, it takes longer and uses more power to get back to a running state than it would from higher sleep states.

Below that is the list of culprits: who is waking your CPU up most often? This updates every few seconds, much like the top program. Some of it's clear (names of programs or library routines); other lines are more obscure if you're not a kernel hacker, but I'm sure they can all be tracked down.

At the bottom of the screen is a geat feature: a short hint telling you how you could eliminate the current top offender (e.g. kill the process that's polling). Not only that, but in many cases powertop will do it for you at the touch of a key. Very nice! You can try disabling things and see right away whether it helped.

Arjan stepped through killing several processes and showing the power saving benefits of each one. (I couldn't help but notice, when he was done, that the remaining top offender, right above nautilus, was gnome-power-manager. Oh, the irony!)

It's all very nifty and I'm looking forward to trying it myself. Unfortunately, I can't do that on the laptop where I really care about battery life. Powertop requires a kernel API that went in with the "tickless" option, meaning it's in 2.6.22 (and I believe it's available as a patch for 2.6.21). My laptop is stuck back on 2.6.18 because of an IRQ handling bug (bug 7264). Powertop also requires ACPI, which I have to disable because of an infinite loop in kacpid (bug 8274, Ubuntu bug 75174). It's frustrating to have great performance tools like powertop available, yet not be able to use them because of kernel regressions. But at least I can experiment with it on my desktop machine.

Tags: , , , ,
[ 14:06 Aug 12, 2007    More linux | permalink to this entry | ]

Sat, 11 Aug 2007

Linuxworld 2007

Last week was the annual trek to Linuxworld.

There wasn't much of interest on the exhibit floor. Lots of small companies doing virtualization or sysadmin tools. The usual assortment of publishers. A few big companies, but fewer than in past years. Not much swag. Dave commented that there was a much higher "bunny quotient" this year than last (lots of perky booth bunnies, very few knowledgeable people working the floor). The ratio of Linux to Windows in the big-company booths was much lower than last year, especially at AMD and HP, who both had far more Windows machines visible than Linux ones.

The most interesting new hardware was the Palm Foleo. It looks like a very thin 10-inch screen laptop, much like my own Vaio only much thinner and lighter, with a full QWERTY keyboard with a good feel to it. The booth staff weren't very technical, but apparently it sports a 300MHz Intel processor, built-in wi-fi and bluetooth, a resolution a hair under 1024x768 (I didn't write down the exact numbers and their literature doesn't say), a claimed battery life of 5 hours, and runs a Linux from Wind River. The booth rep I talked to said it would run regular Linux apps once they were recompiled for the processor, but he didn't seem very technical and I doubt it runs X, so I'm not sure I believe that. For a claimed price of around $400 it looks potentially quite interesting.

Their glossy handout says it has VGA out and can display PowerPoint presentations, which was interesting since the only powerpoint reader I know of on Linux is OpenOffice and I don't see that running on 300MHz (considering how slow it is on my P3 700). Apparently they're using Documents To Go from DataVis, a PalmOS app.

Aside from that there wasn't much of interest going on. They split up the "Dot Org Pavilion" this year so not all the community groups were in the same place, which was a bummer -- usually that's where all the interesting booths are (local LUGs, FSF, EFF, Debian, Ubuntu and groups like that: no Mozilla booth this time around). But this year the dotorgs were too spread out to offer a good hangout spot. It didn't look like there was much of interest at the conference either: this year they gave us Exhibit Hall pass attendees a free ticket to attend one of the paid talks, and I couldn't find one on the day we attended that looked interesting enough to bother.

However, that changed at the end of the day with the BOF sessions. The Intel Powertop BOF was an easy choice -- I've been curious about Powertop ever since it was announced, and was eager to hear more about it from one of the developers. The BOF didn't disappoint, though the room did: they didn't even provide a projector (!), so we all had to cluster around the presenter's laptop when he wanted to show something. Too bad! but it didn't keep the BOF from being full of interesting information. I'll split that off into a separate article.

Tags: , ,
[ 12:34 Aug 11, 2007    More conferences | permalink to this entry | ]

Mon, 06 Aug 2007

Votes on the Warrantless Wiretapping Act

All the news media carried stories on how our (US) legislators voted in a bill on Friday night that greatly eased the rules on wiretapping. The House followed through and passed the bill on Saturday.

The new updates to FISA, the Foreign Intelligence Surveillance Act, will allow the NSA or the attorney general to authorize monitoring of telephones or email, without a warrant, if the comunications involve people "reasonably believed to be outside the United States".

The story reported in most of the papers is that Democrats were against the bill and wanted a version which required warrants in more cases. But the President threatened to hold Congress in session into its scheduled summer recess if it did not approve the changes he wanted -- and that was enough, apparently, for the Senate to vote for warrantless surveillance of Americans. (I confess I don't quite understand why the president can hold Congress in session indefinitely until he gets the vote he wants. Can't they just vote No?)

What I couldn't find in any of the stories was a breakdown of the votes. What about our presidential candidates? Did they support warrantless wiretapping -- or, perhaps worse, just not care about the ramifications of a bill if further consideration of it might cut into their vacation time?

Finding out

Finding Senate votes is very easy. Googling for senate votes takes you right to the Senate.gov breakdown of recent votes by Senator name or by state. Here are the results for S.1927.

The House is harder. They don't seem to have a nice "recent votes" page like the Senate does, or any obvious way to find bills (I had little luck with their site search), though a pressec.com story gave a link to the bill on Thomas.loc.gov, which links to an official House.gov vote count.

In the absence of pressec.com's help, the easiest way to find House voting records is to use the Washington Post Votes Database.

How did they vote?

I was happy to see that all the major Democratic candidates in Congress voted against the smarmily named "Protect America Act", including Hillary Clinton, Barack Obama, Joe Biden, and Christopher Dodd, and (in the House) Dennis Kucinich. John Kerry (who is not an official candidate) didn't vote.

On the Republican side, candidate Sam Brownback voted for the bill, while candidates John McCain, Tom Tancredo and Ron Paul didn't vote.

Of course, I was also interested in my local legislators. California Senator Dianne Feinstein voted for passage (why do people keep voting her back in?) while our other senator, Barbara Boxer didn't vote. In the House, my representative, the always sensible Zoe Lofgren, voted against the bill. In fact, she spoke out against it, saying "This bill would grant the attorney general the ability to wiretap anybody, any place, any time without court review, without any checks and balances. I think this unwarranted, unprecedented measure would simply eviscerate the 4th Amendment." Hurray, Zoe! House Speaker Nancy Pelosi also voted against.

How did your legislators vote?

Tags: , ,
[ 14:20 Aug 06, 2007    More politics | permalink to this entry | ]