Matthew Garrett: USB runtime power management

Matthew Garret have just committed some patches to the rawhide (not F14) tree that re-enable USB autosuspend on some devices. This set includes a workaround in the bluetooth input code that should handle the case where people were seeing their input devices become laggy when autosuspend was enabled, but there's still some chance that other bluetooth devices will behave slightly oddly. If that's the case then try:

echo on >/sys/class/bluetooth/hci0/device/power/control

and see if it improves things. If so then please file a bug and include information about the device you're trying to connect to.

Complete story.

Linux Programming Interface : Michael Kerrisk

Today, Michael Kerrisk post about his new book at his blog.

You can see the and download the resource from the book website.

[GIT PULL] Btrfs updates for 2.6.35

-----Original Message-----
From: Chris Mason
Date: Fri, 11 Jun 2010 15:37:31
To: Linus Torvalds; linux-kernel; linux-btrfs
Subject: [GIT PULL] Btrfs updates for 2.6.35

Hello everyone,

The master branch of the btrfs-unstable tree is a collection of fixes
and cleanups, including two btrfs regressions from rc1:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git master

One is an freeing blocks on an FS converted from ext34 to btrfs,
and the other is a fallocate fix.

The rest are the usual small bug fixes.

Dan Carpenter (11) commits (+24/-17):
Btrfs: handle error returns from btrfs_lookup_dir_item() (+2/-0)
Btrfs: btrfs_read_fs_root_no_name() returns ERR_PTRs (+4/-0)
Btrfs: unwind after btrfs_start_transaction() errors (+1/-1)
Btrfs: remove unneeded null check in btrfs_rename() (+1/-3)
Btrfs: The file argument for fsync() is never null (+1/-1)
Btrfs: handle ERR_PTR from posix_acl_from_xattr() (+2/-0)
Btrfs: btrfs_lookup_dir_item() can return ERR_PTR (+1/-1)
Btrfs: uninitialized data is check_path_shared() (+1/-1)
Btrfs: handle kzalloc() failure in open_ctree() (+5/-2)
Btrfs: silence sparse warnings in ioctl.c (+4/-6)
Btrfs: btrfs_iget() returns ERR_PTR (+2/-2)

Zheng Yan (2) commits (+6/-4):
Btrfs: Fix BUG_ON for fs converted from extN (+2/-1)
Btrfs: Fix null dereference in relocation.c (+4/-3)

Liu Bo (2) commits (+14/-4):
Btrfs: Add error check for add_to_page_cache_lru (+13/-3)
Btrfs: fix break in btrfs_insert_some_items() (+1/-1)

Julia Lawall (2) commits (+9/-17):
Btrfs: Use memdup_user (+6/-14)
Btrfs: Use ERR_CAST (+3/-3)

Shi Weihua (2) commits (+6/-0):
Btrfs: prohibit a operation of changing acl's mask when noacl mount option used (+3/-0)
Btrfs: should add a permission check for setfacl (+3/-0)

Miao Xie (2) commits (+9/-1):
Btrfs: fix loop device on top of btrfs (+1/-0)
Btrfs: fix remap_file_pages error (+8/-1)

Sage Weil (1) commits (+0/-3):
Btrfs: avoid BUG when dropping root and reference in same transaction

Andi Kleen (1) commits (+2/-94):
BTRFS: Clean up unused variables -- nonbugs

Josef Bacik (1) commits (+1/-1):
Btrfs: fix fallocate regression

Prarit Bhargava (1) commits (+1/-1):
Btrfs: Fix warning in tree_search()

Total: (25) commits (+72/-142)

fs/btrfs/acl.c | 8 ++++++++
fs/btrfs/compression.c | 18 +++++++++++++-----
fs/btrfs/ctree.c | 20 +-------------------
fs/btrfs/disk-io.c | 22 +++++++++-------------
fs/btrfs/extent-tree.c | 5 ++---
fs/btrfs/extent_io.c | 9 ---------
fs/btrfs/extent_map.c | 4 ++--
fs/btrfs/file.c | 12 ++++++++++--
fs/btrfs/inode.c | 22 +++-------------------
fs/btrfs/ioctl.c | 36 ++++++++++++------------------------
fs/btrfs/ordered-data.c | 4 +---
fs/btrfs/relocation.c | 7 ++++---
fs/btrfs/root-tree.c | 5 -----
fs/btrfs/super.c | 14 +++++++-------
fs/btrfs/tree-defrag.c | 2 --
fs/btrfs/tree-log.c | 15 ---------------
fs/btrfs/volumes.c | 4 ----
fs/btrfs/xattr.c | 2 --
fs/btrfs/zlib.c | 5 -----
19 files changed, 72 insertions(+), 142 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linus Torvalds : Linux 2.6.35-rc2 is out!

From: Linus Torvalds;
Sender: linux-kernel-owner;
Date: Sat, 5 Jun 2010 21:15:36;
To: Linux Kernel Mailing List;
Subject: Linux 2.6.35-rc2


So -rc2 is out there, and hopefully fixes way more problems than it
introduces.

I'm slightly unhappy with its size - admittedly it's not nearly as big as
rc2 was the last release cycle, but that was an unusually big -rc2. And I
really hoped for a calmer release cycle this time.

In fact, for once I'm going to enforce -rc3 being sane, because the
upcoming week is the last week of school for my kids. And when the kids
get out of school, I'm going be offline for a while. And as a result, I
_really_ don't want to pull anything even half-way scary in the next week
for -rc3.

So any pull requests had better be obvious fixes only, and this time I'm
not going to let things slide.

Anyway, the biggest patches in -rc2 are some staging drivers (70% of the
patch is just that), so while it's still biggish, at least most of it is
clearly staging.

Of the remaining non-staging 30%, half of _that_ is just the regular
drivers (drm: i915 and radeon, along with some dvb updates is a noticeable
chunk), with a new Core i7 EDAC driver that I had gotten a pull request
for before -rc1, but just hadn't had the energy to pull until -rc2 (same
goes for a build system update - the pull request predated -rc1).

And some late powerpc changes that I do _not_ think predated -rc1. Tssk.
I'm really not going to let things like that slide next -rc, as mentioned.

But the most important part is obviously the regression fixes, which tend
to be small and not show up much in the patch statistics. A number of
reverts, a number of fixes, hopefully things are all rosy.

And it really isn't _that_ bad - the -rc2 shortlog is almost never small
enough to be worth posting on the mailing list, but I think it's doable
this time, even if it's borderline. So ShortLog appended if people care
about the (summary of) details.

Linus

Article in Phoronix about loss of performance in 2.6.35 releasecandidates

Dari:Alex Buell
Pengirim:linux-kernel-owner
Ke:Mailing Lists - Kernel Developers
Balas Ke:alex.buell
Perihal:Article in Phoronix about loss of performance in 2.6.35 releasecandidates
Terkirim:1 Jun 2010 06:19

http://www.phoronix.com/vr.php?view=14976
Question: Why?
--
http://www.munted.org.uk

One very high maintenance cat living here.
--

Linus Torvalds : Linux 2.6.35-rc1 is out!

From: Linus Torvalds;
Sender: linux-kernel-owner
Date: Sun, 30 May 2010 14:11:09
To: Linux Kernel Mailing List;
Subject: Linux 2.6.35-rc1


It's been two weeks, and so the merge window is closed. There may be a few
trees I haven't pulled yet, but the bulk should all be there. And please,
let's try to make the merge window mean something this time - don't send
me any new pull request unless they are for real regressions or for major
bugs, ok?

This time, there are no new filesystems (surprise surprise), but there's
certainly been filesystem work both on an individual FS layer (btrfs,
cept, cifs, ext4, nfs, ocfs2 and xfs) and at the VFS layer (superblock
and quota cleanups in particular).

But as usual, the bulk of the changes are in drivers. About two thirds of
all the changes, to be exact. infiniband, networking and staging drivers
are the bulk of it, but there's changes all over (drm, sound, media, usb,
input layer, you name it).

And what's good to see is that we continue to have very healthy
statistics. About 8500 commits (of which 400+ are merges), with about a
thousand individual developers involved (git counts 1047, but some of them
are bound to be duplicates due to people mis-spelling their names etc).
It's skewed, of course - with the median number of commits per person
being just three - but I think that's what we want to see in a healthy
development environment.

Linus

H Peter Anvin : Does anyone care about gcc 3.x support for *x86* anymore?

Just forwarding email in linux-kernel mailing list.

-----Original Message-----
From: "H. Peter Anvin"
Sender: linux-kernel-owner [at] vger [dot] kernel [dot] org
Date: Tue, 18 May 2010 18:19:41
Subject: Does anyone care about gcc 3.x support for *x86* anymore?

[Reposting as a separate thread]

Recently, we have seen an increasing number of problems with gcc 3.4 on
x86; mostly due to poor constant propagation producing not just bad code
but failing to properly eliminate what should be dead code.

I'm wondering if there is any remaining real use of gcc 3.4 on x86 for
compiling current kernels (as opposed to residual use for compiling
applications on old enterprise distros.) I'm specifically not referring
to other architectures here -- most of these issues have been in
relation to low-level arch-specific code, and as such only affects the
x86 architectures. Other architectures may very well have a much
stronger need for continued support of an older toolchain.

If there isn't a reason to preserve support, I would like to consider
discontinue support for using gcc 3 to compile x86 kernels. If there is
a valid use case, it would be good to know what it is.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.