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
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 pr
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 w
On Fri, Nov 09, 2007 at 10:05:05PM -0500, Jeff Garzik wrote:
> By forcing AHCI, your PATA devices will be inaccessible, in a common
> configuration. It also means shuffling users from one driver to another,
> which induces breakage.
>
> I was speaking wishfully. Real life intrudes, alas.
Not e
On Fri, Nov 02, 2007 at 04:37:08PM -0700, Kristen Carlson Accardi wrote:
>
> Does this patch fix your problem? It seems to get hung up while disabling
> DIPM, and after thinking about this a bit, I don't think we really need
> to do this anyway.
Yep, this fixes suspend/resume on my X61 thinkpad.
On Mon, Feb 26, 2007 at 04:33:37PM +1100, Neil Brown wrote:
> Do we want a path in the other direction to handle write errors? The
> file system could say "Don't worry to much if this block cannot be
> written, just return an error and I will write it somewhere else"?
> This might allow md not to
On Fri, Feb 23, 2007 at 05:37:23PM -0700, Andreas Dilger wrote:
> > Probably the only sane thing to do is to remember the bad sectors and
> > avoid attempting reading them; that would mean marking "automatic"
> > versus "explicitly requested" requests to determine whether or not to
> > filter th
