From: Stefan Richter on 30 May 2010 15:10 H.S. wrote: > Stefan Richter wrote: > <SNIP> >> The patch was generated against the latest kernel sources but is >> applicable with harmless line offsets to the 2.6.32.y stable kernel >> series too. Hence it should be applicable to Debian's 2.6.32 sources as >> well. >> >> H. S., could you please test this? > > Yes, I can give it a shot. Please pardon this basic question, should I > be downloading the vanilla kernel source, patching it, compiling it and > then testing it? Either this or the sources of the Debian kernel that you are currently running. The latter may perhaps be preferable for an easier switch between distributed kernel and patched kernel. > Or is there a precompiled binary available for download > (i368 or amd64) with this patch included? Alas not. (I could build such a package if I had Debian myself, but I don't.) > I admit I have never patched > and compiled a kernel before for testing a patch. I have, however, > compiled kernels numerous times quite a while ago (just for learning > objectives). OK; the patching as additional step is going to be the easiest one. A quick web search turned up the following pointers for using a custom kernel on Debian: http://www.debian.org/doc/FAQ/ch-kernel.en.html http://www.debian.org/releases/stable/i386/ch08s06.html.en (I hope the described method provides an already configured kernel source tree with Debian's configuration as baseline.) Before you start compilation, save the email with the patch somewhere, change into the top-level directory of the kernel sources, and apply the patch with "patch -p1 < /the/path/to/the/email". -- Stefan Richter -=====-==-=- -=-= ====- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Richter on 2 Jun 2010 14:30 H.S. wrote: > H.S. wrote: >> So, what is verdict? > > Should have been "So, what is the verdict?" I committed the patch to linux1394-2.6.git now, exposed it in the linux-next branch, and will send a pull request sometime next week. I marked the commit to be back-merged into the stable kernel branches (2.6.32.y and newer). Distributors will pick it up from there at their leisure, or earlier if they get a distro bug report that points them to the commit. Thanks for testing the patched kernel. > Anyway, just wanted to give a little additional information, in case > this is significant. While testing the camcorder on a different Debian > machine running Unstable and 2.6.32-5-686-bigmem kernel, I did not face > the face problem I reported earlier. On this new machine, I was able to > connect the camera and grab a footage using dvgrab. The syslog had this > in it: > May 30 19:31:42 blue kernel: [ 5203.926694] firewire_core: skipped bus generations, destroying all nodes > May 30 19:31:42 blue kernel: [ 5204.424019] firewire_core: rediscovered device fw0 > May 30 19:31:42 blue kernel: [ 5204.516343] firewire_core: created device fw1: GUID 08004601024aca36, S100 > May 30 19:31:42 blue kernel: [ 5204.516346] firewire_core: phy config: card 0, new root=ffc1, gap_count=5 > May 30 19:31:42 blue kernel: [ 5204.525209] firewire_core: skipped bus generations, destroying all nodes > May 30 19:31:43 blue kernel: [ 5205.024019] firewire_core: rediscovered device fw0 > May 30 19:31:43 blue kernel: [ 5205.116912] firewire_core: rediscovered device fw1 I suppose either the local node became root node (node with highest node ID) and thus the camcorder stopped doing bus management things, or the camcorder chose the optimum gap count 5 for some reason and thus the Linux node saw no reason to do its bus management routine. If you are very curious, you can look at node IDs and gap counts and more with the FireWire inspection utility gscanbus. -- Stefan Richter -=====-==-=- -==- ---=- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: Frontswap (was Transcendent Memory): overview Next: [GIT PULL] SLAB fixes for 2.6.35-rc0 |