[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1231670360.15041.41.camel@odie.local>
Date: Sun, 11 Jan 2009 11:39:20 +0100
From: Simon Holm Thøgersen <odie@...aau.dk>
To: We La <w.landgraf@...oo.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: multiple bugs
lør, 10 01 2009 kl. 20:21 -0800, skrev We La:
> I compile continuously almost all git's and test them on several computers.
>
> 1) Since the 2.6.27 serie, until 2.6.28 and its gits, on many machines
> the eth connections don't longer work. The drivers seems to 'work' so
> that with ifconfig the device is listed, however one don't get
> connections nor responses of ping. Booting instead with 2.6.26.X or
> earlier (changing nothing else on the system), everything works
> correctly. The routes are unchanged, too. Probably this is less a
> problem of the eth card drivers but of the routing or package handling.
>
The 2.6.27 series have been out for a while, so it's not a common bug
you have hit and something must be special in your case. Perhaps its
your config, but it's impossible to pinpoint anything from your
description above.
It sounds like that you could use git-bisect(1) to tell you which commit
it started not working from. According to your description above I'd say
you would want to start with
git bisect start
git bisect good v2.6.26
git bisect bad v2.6.27
and git will respond with something like
Bisecting: 5685 revisions left to test after this
[dd9ca5d9be7eba99d685d733e23d5be7110e9556] USB: usb-serial: fix a sparse
warning about different signedness
Then you'd make, install and test the kernel for this revision and
determine whether it was good or bad and get the next revision by
stating 'git bisect good/bad'. You'd have to repeat this about 13 times.
> 2) For all 2.6.28 -git's , and almost on all machines - office/home
> computers, and laptops inclusive my eeepc and msi win - I get error
> messages like that below. After the error occures, the video changes
> in a small-letter video mode, and later on trying startx with a
> framebuffer driver, X don't start. Annexed is also the configuration
> file.
> CONFIG_DRM_I915_KMS=y
Don't set that. The help text for this option warned you:
Choose this option if you want kernel modesetting enabled by default,
and you have a new enough userspace to support this. Running old
userspaces with this enabled will cause pain. Note that this causes
the driver to bind to PCI devices, which precludes loading things like
intelfb.
> 3) For the kernel politics: For the most new computers / laptops
> which come out and which are runners in the shops -- such like the
> eeepc or ms wind -- often it's only 1-2 drivers which are not yet in
> the kernel -- in this examples, the atl2 or the RL2700E drivers.
> Then it needs almost 1 year until they are included. During this
> time, people consider Linux as difficult to run on these machines;
> although some distros compile/add drivers, these depends on the
> kernel version. I suggest to include more fast the few modules for
> the important new computers. Even if these drivers aren't perfect,
> this is better than that people have to compile and install them
> separately.
Yeah, see [1].
[1] http://lwn.net/Articles/298570/
P.S. Please set a subject for your emails, and make it something more
descriptive than the one I provided if possible.
Simon Holm Thøgersen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists