Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 06:23:34PM -0500, Daniel Barkalow wrote: I don't see any reason that we couldn't have a tool accessible to Ubuntu users that does a real git bisect. Git is really good at being scripted by fancy GUIs. It should be easy enough to have a drop down with all of the Ubuntu kernel package releases, where the user selects what works and what doesn't. It's possible users who haven't yet downloaded a git repository have to surmount some obstacles that might cause them to lose interest. First, they have to download some 190 megs of git repository, and if they have a slow link, that can take a while, and then they have to build each kernel, which can take a while. A full kernel build with everything selected can take good 30 minutes or more, and that's on a fast dual-core machine with 4gigs of memory and 7200rpm disk drives. On a slower, memory limited laptop, doing a single kernel build can take more time than the user has patiences; multiply that by 7 or 8 build and test boots, and it starts to get tiresome. And then on top of that there are the issues about whether there is enough support for dealing with hitting kernel revisions that fail due to other bugs getting merged in during the -rc1 process, etc. I agree that a tool that automated the bisection process and walked the user through it would be helpful, but I believe it would be possible for us do better. - Ted
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote: Btw, I used to test every -mm kernel. But since I've switched distros (gentoo-ubuntu) and I have less time, I feel it's harder to test -rc or -mm kernels (I know this isn't a lkml problem but more a distro problem, but I would love having an ubuntu blessed repo with current dev kernel for the latest stable ubuntu release). There are two parts to this. One is a Ubuntu development kernel which we can give to large numbers of people to expand our testing pool. But if we don't do a better job of responding to bug reports that would be generated by expanded testing this won't necessarily help us. The other an automated set of standard pre-built bisection points so that testers can more easily localize a bug down to a few hundred commits without needing to learn how to use git bisect (think Ubuntu users). So for the first, I've actually been playing with some plans to put together an unofficial kernel that basically what Ted is using on his laptop. It generally has emergency bug fixes that haven't made it into mainline, plus some other trees where I've been more aggressive since I want to latest in wireless and powersaving technology, etc. It has the property that if it breaks, you get to keep both pieces --- and I've helpfully included the git ID in the package name so you can do the bisection yourself. If you want to try it, the first such kernel is here: http://www.kernel.org/~tytso/tbek I wasn't planning on talking about it until it was more fully baked, but if people want something vaguely stable based on 2.6.24-rc2, this might be interesting. As for the second, I was just talking to Arjan over pizza and beer last night, and we reached the same conclusion as Ingo, which is this really isn't that hard. It wouldn't be that hard to set up infrastructure to do this, and it's just a matter of getting the disk space and the network bandwidth togehter in the right place, plus a relatively small amount of prgramming at least for the simplest iteration of the idea. (As is quite common when doing designs over beer, we talked about some more gradious web-based schemes to do custom built kernels that was tied to the kernel bugzilla, but first things first. :-) - Ted
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 11:33:44AM -0600, Larry Finger wrote: I'm very encouraged to read of your expanded testing efforts. As a bcm43xx developer, Ubuntu has been our problem distro, mostly because your standard kernels have debugging turned off for bcm43xx. When a Ubuntu user reports a problem and we ask for the relevant output from dmesg, they have no information. I ask two things of all distros: (1) Turn on debugging - we don't spam the logs that badly, and (2) forward any bugs found by your testing to the maintainer, and/or the bcm43xx mailing list. Heh. I hadn't enabled CONFIG_BCM43XX_DEBUG myself, but I just changed it for my next kernel build. This is a slightly different issue, which is that sometimes _DEBUG options shouldn't be turned on by default (because they really trash performance and bloat log size), and sometimes they are painless to turn on and don't cost much. If that is the case, I'd suggest removing the option and just making it compiled in by default with a run-time option to enable it. - Ted
