It's been two weeks rather than the usual one, because we've been hunting 
a really annoying VM regression that not a lot of people seem to have 
seen, but I didn't want to release an -rc4 with it. So we had the choice 
of either reverting all the anon-vma scalability improvements, or finding 
out exactly what caused the regression and fixing it.

And we got pretty close to the point where I was going to just revert it 
all. 

Absolutely _huge_ kudos to Borislav Petkov who reported the problem and 
was able to not just reliably reproduce it, but also test new patches to 
try to narrow things down at a moments notice. The thing took ten days of 
emails flying back and forth, and Borislav was there all the time, day and 
night, through several patches that tried to fix it (several real bugs, 
but not the one he hit) and lots of patches to just add instrumentation to 
get us nearer to the cause of the problem.

And finally, today, confirmation that we actually nailed the problem. So 
if anybody has been seeing a oops (or sometimes a GP fault) in 
page_referenced(), that should be gone now.

Anyway, there's certainly been other things going on too, but the VM 
regression was the one that kept me personally busy, and held up the 
release.

The bulk of the changes come from drivers - a new network driver (cxgb4), 
but also updates to the radeon and nouveau drivers.

And then there is the random updates everywhere. The appended shortlog is 
about as good an overview as anything.

		Linus

---
Adam Jackson (1):
      drm/edid/quirks: Envision EN2028

Ajit Khaparde (3):
      be2net: fix a bug in flashing the redboot section
      be2net: fix flashing on big endian architectures
      be2net: fix bug in vlan rx path for big endian architecture

Al Viro (1):
      Have nfs ->d_revalidate() report errors properly

Alan Jenkins (2):
      ACPI: battery: Fix CONFIG_ACPI_SYSFS_POWER=n
      ACPI: battery drivers should call power_supply_changed()

Alberto Panizzo (5):
    ...
[ message continues ]

I noticed the vm discussion, but had no idea what was going on.
In any case that's pretty cool to see(read). Love to see the hard
work and collaboration to fix a problem.

cheers,

Justin P. Mattock
--

[ message continues ]

Hi,

-rc4 does not boot on my MacBook v2.1. Unfortunately, I can not add much 
info on what happens since it's all happening really fast. Last thing I 
can really see is that KMS takes over (?), outputs a few lines which 
look ok, last line being something about ata. Here the boot stops.

Before the switch to KMS I can briefly see something what's probably a 
stacktrace, like < ?blabla >. Only words I could recognize were "?acpi" 
and "mutex".

Config is from make localyesconfig, based on rc3 which is running fine 
(beside the occasional flickering/screen corruption drm/i915 seems to be 
famous for ;) ).

Please excuse layman's terms and let me know if I there is anything I 
can do to produce a helpful error message.

Regards,

Tobias
[ message continues ]

The absolutely most helpful thing you could do (and it really isn't that 
complex, just somewhat time-consuming) is to do a "git bisect" to figure 
out exactly where it started.

"git bisect" is really simple to run, and since you know a start-point and 
an end-point, and they aren't even all _that_ far away from each other, 
it's going to be reasonably quick.

The fact that you have tested only -rc release kernels makes me suspect 
you aren't a git user, but don't worry, it's really quite easy. 

Just make sure you have git installed (most distros have it, so a "yum 
install git-core" or something like that should do it), and then do

	# get the kernel repo
	git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
	cd linux-2.6

	# start bisecting
	git bisect start
	git bisect good v2.6.34-rc3
	git bisect bad v2.6.34-rc4

and git will look at the good/bad pair you told it, and try to find a 
mid-point between the two. It will say something like this:

	Bisecting: 288 revisions left to test after this (roughly 8 steps)
	[14e71e4fb94c340273534a6d7f210aa82a3ca717] Merge git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog

which just means that there were roughly 2*288=576 commits (584 to be 
exact - since history isn't linear, it couldn't find an _exact_ mid-point) 
between -rc3 and -rc4, and it has checked out a midpoint for you to try.

Now, just compile that kernel version, install it, and try to boot it.

If it works, you tell git so with "git bisect good" and it will pick a new 
kernel for you to test (now half-way between that _new_ good kernel and 
the bad kernel). And if it _doesn't_ work, just tell git so with "git 
bisect bad", and it will pick another kernel for you to test.

You'll end up having to test maybe nine or ten kernels, but then git will 
tell you exactly which commit caused your problem.

Alternatively, if you find the process really tedious (I admit that it is 
tedious, but the nice thing is that it's ...
[ message continues ]

> > -rc4 does not boot on my MacBook v2.1.

It is likely that this is already bisected
and fixed by the patch here:
https://bugzilla.kernel.org/show_bug.cgi?id=15749

thanks,
Len Brown, Intel Open Source Technology Center
--

[ message continues ]

Doh, indeed it looks like it. So far I have

git bisect start
# good: [2eaa9cfdf33b8d7fb7aff27792192e0019ae8fc6] Linux 2.6.34-rc3
git bisect good 2eaa9cfdf33b8d7fb7aff27792192e0019ae8fc6
# bad: [0d0fb0f9c5fddef4a10242fe3337f00f528a3099] Linux 2.6.34-rc4
git bisect bad 0d0fb0f9c5fddef4a10242fe3337f00f528a3099
# good: [14e71e4fb94c340273534a6d7f210aa82a3ca717] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog
git bisect good 14e71e4fb94c340273534a6d7f210aa82a3ca717
# bad: [2f10ffcfb28beb35137d9e86992c771b4a6c5f2a] Merge branch 
'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
git bisect bad 2f10ffcfb28beb35137d9e86992c771b4a6c5f2a
# good: [fb1ae635772d679eb312fa447290fc02cd0e4cf1] Merge branch 
'x86-fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip
git bisect good fb1ae635772d679eb312fa447290fc02cd0e4cf1
# bad: [d620a7cf05d4f12f5bbb1060d766e8139ab31458] Merge branch 
'upstream-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
git bisect bad d620a7cf05d4f12f5bbb1060d766e8139ab31458
# good: [f5284e7635787224dda1a2bf82a4c56b1c75671f] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus
git bisect good f5284e7635787224dda1a2bf82a4c56b1c75671f
# bad: [c25f7cf2032aaac9bd50d6eee982719878538082] Merge branches 
'battery', 'bugzilla-14667', 'bugzilla-15096', 'bugzilla-15480', 
'bugzilla-15521', 'bugzilla-15605', 'gpe-reference-counters', 'misc', 
'pxm-fix' and 'video-random-key' into release
git bisect bad c25f7cf2032aaac9bd50d6eee982719878538082

At least I got a free bisect turorial and will know my way next time.

Thanks and sorry for the noice.

Tobias

--

[ message continues ]

As a non-kernel-hacker, I agree fully. "git bisect" is the best
error diagnosing tool ever invented.

I have on two occations bisected kernel problems with the help of the
kernel community, and I have really been impressed by the help I have
got.
-- 
Hilsen Harald.
--

[ message continues ]