Next Linux kernel release supports more ARMs with less code

A new coding effort recently folded into the next version of the Linux kernel may finally resolve the long-running problems associated with Linux on ARM processors. While devices like the Raspberry Pi have shown what can be done with Linux on the low-cost, low-power ARM processor, the burden of developing Linux on the growing number of ARM-derivative processors on the market has been, as Linus Torvalds himself has described it, “a fucking pain in the ass.”

via Next Linux kernel release supports more ARMs with less code | Ars Technica.

Until now, each implementation of ARM by manufacturers has had its own associated kernel code tree, creating a code management nightmare.

Open-Source NVIDIA Driver Approaches Stable State

The Nouveau driver has had a long and challenging journey to get where’s it at today where the developers are now comfortable with the Nouveau driver leaving the Linux kernel’s staging area and thus also fully committing to a stable ABI for their kernel driver (their DRM version is also now marked as v1.0). Nouveau began more than a half-decade ago; I first wrote about the project in 2006 and it wasn’t until 2007 that OpenGL began to sort of work on this free software driver that was started by Stephane Marchesin (he’s no longer directly involved with Nouveau as for a while now he’s been off working for Google on Chrome OS). Nouveau’s journey has been quite interesting and in the past six years has earned itself 450 news posts where I have written about this open-source NVIDIA driver and over 60 featured articles that have included benchmarks or more extensive information on this Linux driver.

via [Phoronix] Open-Source NVIDIA Driver Approaches Stable State.

Linux 3.3: Finally a little good news for bufferbloat

I, Cringely » Blog Archive » Linux 3.3: Finally a little good news for bufferbloat – Cringely on technology.

Bufferbloat, as you’ll recall from my 2011 predictions column, is the result of our misguided attempt to protect streaming applications (now 80 percent of Internet packets) by putting large memory buffers in modems, routers, network cards, and applications. These cascading buffers interfere with each other and with the flow control built into TCP from the very beginning, ultimately breaking that flow control, making things far worse than they’d be if all those buffers simply didn’t exist.

Bufferbloat was named by Jim Gettys of Bell Labs, who has become our chief defender against the scourge, attempting to coordinate what’s become a global response to the problem.

What AQM does is monitor the buffer, and signal the end points to slow down any time the buffer starts to fill, either due to that one transfer or competing transfers, by dropping or marking packets.  So the buffer is kept (almost) empty, except when it is handling a burst of traffic. So the steady state latency of the buffer, rather than being the size of the buffer, is set by the size of the bursts in traffic.  The size of the buffer becomes almost irrelevant.

Linux vendors rush to patch privilege escalation flaw after root exploits emerge

According to Carsten Eiram, the chief security specialist at vulnerability research firm Secunia, the flaw was introduced in the Linux kernel code in March 2011 and affects versions 2.6.39 and above. “Any Linux distributions providing these kernel versions should be vulnerable,” Eiram said.

via Linux vendors rush to patch privilege escalation flaw after root exploits emerge – security, secunia, Exploits / vulnerabilities – Malware – Security – Techworld.

Fedora 14 is stuck on 2.6.35 something.  This shouldn’t affect CentOS builds either.  Sometimes it’s beneficial not to upgrade the OS!

scanning for new scsi devices

scanning for new scsi devices.

New devices can be added using echo “scsi add-single-device <h> <b> <t> <l>” > /proc/scsi/scsi where the variables are host, bus (channel), target (scsi id) and lun. The success (or otherwise) of this command can be determined by sending a subsequent cat /proc/scsi/scsi command.

..from the scsi-howto (proc interface) at – see it for more info.

i have a script “” here on debian which uses the above method to recheck devices.

HTH ritch.

This was written in 2005. I found the script on medusa but have no idea which package it came from. It wasn’t on any other Fedora 14 install so it must have come from somewhere. It scans the SCSI bus and finds the drive perfectly well.

What do these SATA errors mean?

For SATA drives, occasional transmission problems are expected even on otherwise pretty healthy systems. No need to worry about it too much unless the problem repeats itself a lot.

via What do these SATA errors mean / kernel (DRDY ERR/ICRC ABRT) | Linux | Kernel.

This error occurred on the drive using the hot swap cage.  I wonder if perhaps the circuitry on the cage is iffy.  The circuit board on that cage is about the simplest board that can be designed — it just maps wires from one pin connector to another — that’s it.

Perhaps the centos install is OK after all.  It’s intermittent which is bad.  Looks like it might pay to use higher quality hot swap cages.  Tomorrow I’ll try another brand and investigate this further.  Here’s another pertinent point.  I’m seeing this exact same error.

> 51/84:f8:47:dc:35/00:03:02:00:00/e0 Emask 0x10 (ATA bus error)
> Jun 11 05:46:23 p34 kernel: [ 1445.288637] ata12.00: status: { DRDY ERR }
> Jun 11 05:46:23 p34 kernel: [ 1445.288639] ata12.00: error: { ICRC ABRT }

That’s your drive reporting that it saw transmission error on the wire.

Finding linux distro release info

Fedora Core: /etc/fedora-release

Red Hat: /etc/redhat-release, /etc/redhat_version (rare)

via release-files.

I got confused between two Centos VMs.  I had thought one Centos VM that I have running DNS was Centos 5.4 and the new one was Centos 5.6.  When I saw that they both used a 2.6.18.* kernel I got confused.  Fedora Core is using 2.6.35 and greater.  This led me to check the distro version upon which I didn’t get it out of uname -a or dmesg.  Searching the intertubes and I got the above answer.  Apparently the VM I thought was 5.4 is really 5.5.

It is interesting that Centos, which tracks RHEL, doesn’t make too many radical changes to the kernel.

Update: It should be noted that I wouldn’t have noticed the kernel versions had I not tried to compile and install my own kernel.

Xen – KVM – Linux – and the Community

KVM is a type-2 hypervisor built into the Linux kernel as a module and will ship with any Linux distribution moving forward as no work is required for the Linux distributions to add KVM. Having a virtualization platform built-in to the Linux kernel will be valuable to many customers looking for virtualization within a Linux based infrastructure; however these customers will lose the flexibility to run a bare-metal hypervisor, configure the hypervisor independent of the host operating system, and provide machine level security as a guest can bring down the operating system on KVM. Xen, on the other hand is a type-1 hypervisor built independent of any operating system and is a complete separate layer from the operating system and hardware and is seen by the community and customers as an Infrastructure Virtualization Platform to build their solutions upon.

via Xen – KVM – Linux – and the Community –