However, I do still see issues with the kernel I end up with, so I'm either starting from the wrong 'good', or there are several bad commits.

A third update: I just experienced slow-down with 1k interrupts per second on 3.7.10, which may indicate that I picked a bad starting point for bisecting. I'll leave the post up since it can serve as a guide for how to bisect in general.

* the bug only manifests itself on one of my computers, with intel graphics -- and that's a laptop (I'm not a huge fan of laptops, especially not with budding carpal tunnel syndrome, so testing the bisected version is a bit of a pain -- literally)

* the bug isn't consistently triggered, so you need to test the new kernel for an hour or more, and only by the absence of a specific behaviour can you see whether all is good i.e. testing is a bit of hit and miss.

* compiling the kernel takes a long time, and I don't currently have a suitable computer for it at home where my laptop (the one with the i915) is, so I'll build the kernel on a work computer, then install it at home, then repeat each day.

NOTE: there's no sure-fire way of triggering this issue, but it seems to occur more frequently when the fan is on but approaching the thermal cut-off point where it will turn off. This makes troubleshooting somewhat more difficult.

1. Download/checkout
First get the sources -- it pulls everything from 2.6.12, so it's bigger than a normal kernel source download. I'll skip explicitly telling you what packages you need to have in order to compile the kernel or use git, since if you don't know, you're probably not really ready for this anyway. Besides, that information is available in other posts on this blog.

2A. Bisect
I know that 3.8.5 is bad and that 3.7.10 may be good (seem to remember having issues with the Arch version of 3.7.10, but no issues with my own build on debian. Not sure I can trust my memory).

I know for a fact that 3.2 is good. I don't want to bisect everything from 3.8.5 to 3.2 though, so I'll take a leap of faith and presume that 3.7.10 is good (which I'll regret if that's not true) and 3.8.0 is bad.

Repeat step 3 until you've isolated the commit that caused the issue.
For me
* the first bisect didn't cause kworker slow downs (bisect good)
* the second bisect immediately led to slowdown (bisect bad)
* the third one was fine (bisect good)
* the fourth one had no issues (bisect good)
* the fifth one was good (bisect good)
* the sixth one was definitely bad (bisect bad)

powertop gives the following when it's slowing down

0 mW 423.5 ms/s 4.5 kWork i915_hotplug_work_func

and watch cat /proc/interrupts:

The number of interrupts increases very, very rapidly for '49: PCI-MSI-edge i915' during mouse slowdown. Normal rate is around 70 per two seconds.

This is where it gets less clear -- from what I can see:
* the seventh one was a little bit bad (bisect bad).
* the eight one had minor issues when the fan went off (bisect bad).

But the first time I did the bisect I came to the exact opposite conclusion for the last two bisects. I'm suspecting that it's really down to two or more commits that together cause bad behavior, but on their own are merely annoying.

Anyway, I've ended up with this commit as the current culprit (again, the first time around I ended up with a different commit):

607a6f7a6621f65706ff536b2615ee65b5c2f575 is the first bad commit
commit 607a6f7a6621f65706ff536b2615ee65b5c2f575
Author: Daniel Vetter
Date: Wed Nov 14 17:47:39 2012 +0100
drm/i915: drop buggy write to FDI_RX_CHICKEN register
Jani Nikula noticed that the parentheses are wrong and we & the bit
with the register address instead of the read-back value. He sent a
patch to correct that.
On second look, we write the same register in the previous line, and
the w/a seems to be to set FDI_RX_PHASE_SYNC_POINTER_OVR to enable the
logic, then keep always set FDI_RX_PHASE_SYNC_POINTER_OVR and toggle
FDI_RX_PHASE_SYNC_POINTER_EN before/after enabling the pc transcoder.
So the right things seems to be to simply kill the 2nd write.
Cc: Jani Nikula
Reviewed-by: Chris Wilson
[danvet: Dropped a bogus ~ from the commit message that somehow crept
in.]
Signed-off-by: Daniel Vetter
:040000 040000 f789c6c199c9db5c9d0d7961760574b5f0b1ede9 9e0cd2a09cab610b437164b1a74f620e43686ef1 M drivers

It's just really difficult to reproduce the issue consistently with the last couple of kernels. I am in no way confident that the above commit is what's causing all this.The last confirmed troublesome bisect (#6):Here's the log:

23 February 2013

While I find latex superior to word processors in almost every single aspect, there is one thing I have to admit that MS/Libre/Open Office have over LaTeX: track changes. Since LaTeX is nothing but code you can obviously use something like git or svn to manage versions of .tex code. There are some differences though -- e.g. git would show you the diff output, but not necessarily the context of the changes, and I'm having a difficult enough time convincing people to use LaTeX without having to worry about setting up a git server as well (I can obviously cheat around it by running a local git server, downloading their file and push it to my git server etc, but then I would be the only one who'd be able to track the changes. Also, it's not elegant).

I have a student who is currently preparing a thesis, and while I've managed to give most of my feedback via the pdf annotation function in mendeley, it doesn't feel natural when it should be a simple matter of editing the .tex directly (yet in a way that leaves the student in control over whether to accept or reject the changes).

So here's an exploration of three different ways of passing comments and corrections back and forth when using LaTeX.

You can see the version differences using a couple of methods, but gitk might be the easiest one. The downside with this is that you lose some of the context of the changes. Also, it shows you the code that was changed, the changes in the final document (e.g. formatting, figures etc.).

Still it's a pretty intuitive and easy way of tracking changes -- and in terms of versioning it is certainly the best solution. You can fork, roll back and generally have a perfect account of how the document has evolved.

git in particular makes it easy to see added code

In terms of small changes like fixing typos it is a lot more subtle though

3. latexdiff
latexdiff is an easy to use tool that's in the debian repos. Simply do

latexdiff version1.tex version2.tex > diff.tex

and then open diff.tex and compile it to see the changes.

Pleasantly suprised

4. Other solutions
there are plenty of solutions for introducing mark-up directly into the tex document, like trackchanges, changes etc. I've used them in the past but it lack elegance when doing heavier collaborative writing.

Thoughts

I can't help but think that the best solution is to combine git with latexdiff -- or even a special fork of git that uses latexdiff.

22 January 2013

I've recently moved one of my more mature projects to sourceforge.net, which allowed me to re-discover the joys of using a version management system, in this case git. While I've spent some time playing with SVN in the past, git feels more natural to me. That's it's used widely in the FOSS community certainly doesn't hurt either.

So that got me interested in setting up a local git server for projects that may or may not result in anything tangible i.e. projects that I don't want to put online, but are under so much flux that they may break anytime (and I thus want to be able to roll back).

[A pointer to my students: you can obviously use git to maintain versions of your .tex documents as well...]

In this particular case the development machine and the git host are the same. The project is called shellnmr (an attempt to make a bash-like shell in python for NMR processing)