by Sam Ravnborg

[permalink] [raw]

Subject: Re: About git-bisect (was: Linux 2.6.28-rc7)

>
> I need more than 20min to compile each kernel, so is necessary ~260min.

You do not need to do a "make clean" between each build, so if none
of the core files are touched you should be much faster.
Do you bisect and then type make should be enough.

Sam

2008-12-02 16:55:30

On Tue, 02 Dec 2008 15:30:35 UTC
Alistair John Strachan <[email protected]> wrote:
> One thing I would point out is that your distro kernel (presumably
> 2.6.27 or older) would probably have had the NVIDIA module to hand
> and would not drop into safe mode, right? In this case, VT switching
> behaviour may be entirely different.

Ubuntu 8.10 comes with a 2.6.27 kernel as packaged by Ubuntu.

> Could you please find out what framebuffer driver your distro is
> loading (probably nvidiafb, I'd guess) before starting X, and what
> Xorg driver Ubuntu use in this "safe graphics mode" (nv, vesa)? Also,
> could you try removing the nvidia module in the older kernel and
> confirm that the same VT corruption does not occur, so Rafael can
> identify this as a regression?

The stock Ubuntu install includes vesafb support, but Alejandro's dmesg
doesn't indicate that he's using vesafb at all. The NVIDIA kernel
module refuses to work with the nvidiafb driver (claiming a conflict)
so if the NVIDIA module loads, nvidiafb isn't present. (In fact, the
NVIDIA kernel module linkage will refuse to build against a kernel that
was even configured for nvidiafb).

I'm using 2.6.28-rc7 successfully on Ubuntu with the NVIDIA kernel
module as packaged by Ubuntu (Ubuntu 8.10 uses DKMS to manage the
module). A single change to the linkage's C code was necessary, and
it is also necessary to either instruct the linkage where to find
relocated kernel headers or to create some symlinks:

$ cd /lib/modules/2.6.28-rc7/source/include/asm-x86
$ ln -s ../../arch/x86/include/asm/* .

(This may be different for a 32-bit configuration; mine is a 64-bit
x86-64 kernel. I don't think it is different, though.) I have it
working both using the standard 80x25 VGA console and with the vesafb
driver providing a significantly larger console.

> (Maybe things have changed over the years, but my understanding was
> that for the majority of Xorg drivers, mode setting was still done by
> the Xorg driver, not the kernel, and the X server is responsible for
> restoring the VT correctly, not the kernel's framebuffer driver. So
> this may possibly not be a kernel bug at all.)

NVIDIA still does mode setting in X.org, by default detecting the
native resolution of the attached monitor and using that.

This doesn't affect the VGA console... however, I have run into
NVIDIA-based graphics boards that don't like mode changes very much.
Some of the really finicky cards require using vesafb in the kernel and
then telling X.org to use the kernel-provided framebuffer to get it to
work correctly.

Also, the VESA X.org driver doesn't play nicely with all NVIDIA
boards; this might explain why the system didn't switch cleanly to a VT
after starting in "safe mode" --- which is Ubuntu's way of saying,
"640x480 using the vesa X.org driver".

Alejandro, can you switch back to VTs again after rebuilding your
NVIDIA module? Also, you seem to have mentioned that you're not using
Ubuntu's packaged NVIDIA driver... this may mean that you've
overwritten and/or moved other files that Ubuntu uses, since the NVIDIA
driver installer does this automatically. Can you try using a stock
system, updated kernel, and let DKMS build the NVIDIA module? You'll
need to make some alterations, but I can help with those.

HTH,
Mike

--
My sigfile ran away and is on hiatus.
http://www.trausch.us/

Attachments:

signature.asc (197.00 B)

2008-12-02 18:06:31

by Alejandro Riveira Fernández

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc7

El Tue, 2 Dec 2008 12:11:11 -0500
"Michael B. Trausch" <[email protected]> escribió:

[...]
>
> Alejandro, can you switch back to VTs again after rebuilding your
> NVIDIA module?

I can switch to VT's and the bug still manifest 2.6.28-rc7

> Also, you seem to have mentioned that you're not using
> Ubuntu's packaged NVIDIA driver... this may mean that you've
> overwritten and/or moved other files that Ubuntu uses, since the NVIDIA
> driver installer does this automatically.

I'm using the nvidia installer for the 180.06 driver yes

> Can you try using a stock
> system, updated kernel, and let DKMS build the NVIDIA module? You'll
> need to make some alterations, but I can help with those.

Would the nvidia.com uninstaller leave things as in a stock install?
Where can i find help about DKMS? also does it work if you use the
"vanilla way" of installing kernels? i do:
make ; make install ; make modules_install ; and mkinitramfs to install
kernels i test

>
> HTH,
> Mike
>

2008-12-02 18:49:22

by Alejandro Riveira Fernández

[permalink] [raw]

Subject: Re: Linux 2.6.28-rc7

El Tue, 2 Dec 2008 08:13:47 -0800 (PST)
Linus Torvalds <[email protected]> escribió:

>
>
> On Tue, 2 Dec 2008, Alejandro Riveira Fernández wrote:

[ ... ]
>
> Since you are apparently a git user, and 2.6.28-rc6-00007-ged31348 was
> fine, there's really only 270 commits in between that and 2.6.28-rc7. Can
> I ask you to bisect for a couple of runs, which would cut it down to a
> handful? (Ie you don't even need to do a full bisect, although that should
> really only require about 8 reboots).
>
> Just do
>
> git bisect start
> git bisect bad v2.6.27
v2.6.28-rc7 <<<
> git bisect good v2.6.28-rc6-00007-ged31348
>
> and off you go. That would help enormously.
>
> There are very few console-related changes in that range, and the most
> notably one is actually radeon-specific so it shouldn't be an issue for
> you. I'd _suspect_ bca404afdc5206c3bb30168315ee8a98a579ec65 ("fbdev: fix
> FB console blanking"), but quite frankly, it could be something random
> that just interacted badly. A bisection would narrow things down.

Here you go

[alex@varda:kernel/linux-2.6]$ git bisect bad
31168481c32c8a485e1003af9433124dede57f8d is first bad commit
commit 31168481c32c8a485e1003af9433124dede57f8d
Author: Al Viro <[email protected]>
Date: Sat Nov 22 17:33:24 2008 +0000

meminit section warnings

Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

:040000 040000 87b37c3148067870af9fd13e661e0dc96ddfb99c b971fe6efa622c1f90ef7da702997a04fc83418d M include
:040000 040000 6dc7c5088a129e3432c31aadce83e98c2e07916e ae9694713cee3ff50411102b08fb4f33f881f3c4 M mm

[alex@varda:kernel/linux-2.6]$ git bisect log

git bisect start
# bad: [061e41fdb5047b1fb161e89664057835935ca1d2] Linux 2.6.28-rc7
git bisect bad 061e41fdb5047b1fb161e89664057835935ca1d2
# good: [ed313489badef16d700f5a3be50e8fd8f8294bc8] Merge master.kernel.org:/home/rmk/linux-2.6-arm
git bisect good ed313489badef16d700f5a3be50e8fd8f8294bc8
# bad: [9bd062d9eaf9e790330f37d9f4518e1b95131f6c] Merge branch 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git bisect bad 9bd062d9eaf9e790330f37d9f4518e1b95131f6c
# bad: [499c59c42967329d39481314a839d7669f5e1506] MN10300: Tighten up the code using case ranges
git bisect bad 499c59c42967329d39481314a839d7669f5e1506
# bad: [211f05a034f49586fdd071abd174853217ec29ee] input: replace spin_lock_bh with spin_lock_irqsave in ml_ff_playback
git bisect bad 211f05a034f49586fdd071abd174853217ec29ee
# bad: [1c4567aeed84a2746d78d4c1fe092222a559d43f] m32r: section noise in head.S
git bisect bad 1c4567aeed84a2746d78d4c1fe092222a559d43f
# bad: [d16d7667f9c211e8d9b7e2365cc3d3a83fc6a8e2] icside section warnings
git bisect bad d16d7667f9c211e8d9b7e2365cc3d3a83fc6a8e2
# bad: [409832f5484cd1e2d8812c3236dffb33d01c359b] sparc32 cpuinit flase positives
git bisect bad 409832f5484cd1e2d8812c3236dffb33d01c359b
# bad: [7d6a8a1c487422b772201927c454930377d8cf7e] false __cpuinit positives on alpha
git bisect bad 7d6a8a1c487422b772201927c454930377d8cf7e
# bad: [31168481c32c8a485e1003af9433124dede57f8d] meminit section warnings
git bisect bad 31168481c32c8a485e1003af9433124dede57f8d

That's what i got after the bisection dunno if that helps...

>
> Linus

2008-12-02 18:56:50

On Wed, 3 Dec 2008, Renato S. Yamane wrote:
> Francis Moreau wrote:
> >
> > Care to share your network configuration ;) ?
>
> Maybe a repository with .config files used by linux hard-users (as most
> developers here) can be very interesting to a lot of people get a starter.

Well, it tends to depend not just on hardware, but on distribution too.
Some distros use different features than others.

And some people (me) hate modules. I just don't use them if I can avoid
it. Some drivers only work as modules, but it's getting happily
fairly rare. So if you don't need a lot of flexibility (eg you don't
expect to connect a lot of random USB devices), you can make a nonmodular
build and just not support random things like tablets etc at all.

So here's my .config, if anybody cares. It's for Fedora 9, and obviously
for _my_ particular hardware. It's not totally minimal, but it's
reasonably so, while not losing any basic functionality I've ever found
myself caring about. But it doesn't support (for example) auditing, and
thus not SELinux. Those just slow things down for me.

So I won't guarantee it's at all useful. But if nothing else, you can use
it to benchmark your machine against mine. When I do

git clean -dqfx
make oldconfig

to set up a clean compile with this config, I get:

[torvalds@nehalem linux]$ /usr/bin/time make -j16 > ../makes
Root device is (253, 3)
Setup is 11676 bytes (padded to 11776 bytes).
System is 2653 kB
CRC 6d0e8080
73.54user 16.53system 0:15.93elapsed 565%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+6070720minor)pagefaults 0swaps

and yeah, you need a pretty beefy machine to beat that. Most of them will
not fall in the category of "workstation".

(IOW, in the timing above, I do _not_ include the time it takes to do the
"make oldconfig", and as is obvious from the number of major pagefaults,
absolutely everything has been brought into the disk cache - if I do a
cold-cache compile it takes over a minute).

Linus

Attachments:

kernel-config (54.10 kB)

2008-12-03 17:24:50

by Francis Moreau

[permalink] [raw]

Subject: Re: About git-bisect

On Wed, Dec 3, 2008 at 1:55 PM, Renato S. Yamane
<[email protected]> wrote:
> Francis Moreau wrote:
>> Linus Torvalds writes:
>>> It takes me 16 seconds to compile my kernel (if it's all cached), and
>>> that's largely because I do _not_ compile one of the crazy distro kernels
>>> with thousands of totally irrelevant modules for my setup.
>>
>> an other reason is perhaps you're using a computer that most common
>> mortal don't have ;)
>>
>> Care to share your network configuration ;) ?
>
> Maybe a repository with .config files used by linux hard-users (as most
> developers here) can be very interesting to a lot of people get a starter.
>

Or perhaps just to keep 'make defconfig' uptodate with sane core values
which should fit a desktop config ?

BTW does anybody what the status of the defconfig files on x86 ?

thanks
--
Francis

2008-12-03 17:51:57

by Randy Dunlap

[permalink] [raw]

Subject: Re: About git-bisect (defconfigs)

Francis Moreau wrote:
> On Wed, Dec 3, 2008 at 1:55 PM, Renato S. Yamane
> <[email protected]> wrote:
>> Francis Moreau wrote:
>>> Linus Torvalds writes:
>>>> It takes me 16 seconds to compile my kernel (if it's all cached), and
>>>> that's largely because I do _not_ compile one of the crazy distro kernels
>>>> with thousands of totally irrelevant modules for my setup.
>>> an other reason is perhaps you're using a computer that most common
>>> mortal don't have ;)
>>>
>>> Care to share your network configuration ;) ?
>> Maybe a repository with .config files used by linux hard-users (as most
>> developers here) can be very interesting to a lot of people get a starter.
>>
>
> Or perhaps just to keep 'make defconfig' uptodate with sane core values
> which should fit a desktop config ?
>
> BTW does anybody what the status of the defconfig files on x86 ?

I looked at them about 1 week ago. I know that Ingo or the x86 maintainers
team update them occasionally, but I'd like to see a few changes or some
questions answered:

1. Disable CONFIG_TR. Token ring is antiquated. No reason to be in defconfig.

2. There are several security-related config items that default to =y but the
kconfig help says: If unsure, say N here. Like:

CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_KEYS=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_SELINUX=y

Maybe I just don't understand the current meaning/usage of defconfig. eh?

Thanks,
~Randy

2008-12-04 00:15:27

by Nick Andrew

[permalink] [raw]

Subject: Re: About git-bisect (defconfigs)

On Wed, Dec 03, 2008 at 09:50:51AM -0800, Randy Dunlap wrote:
> 2. There are several security-related config items that default to =y but the
> kconfig help says: If unsure, say N here. Like:
>
>
> CONFIG_NETLABEL=y
> CONFIG_NETWORK_SECMARK=y
> CONFIG_KEYS=y
> CONFIG_SECURITY=y
> CONFIG_SECURITY_NETWORK=y
> CONFIG_SECURITY_SELINUX=y
>
> Maybe I just don't understand the current meaning/usage of defconfig. eh?

A consistent approach to the Kconfig hints would help. To me,
"If unsure, say N" implies that turning off the feature won't break
the kernel nor be anything particularly important. The Kconfig hints
should follow the defaults (or else why default to 'y'?) for common
architectures.

Perhaps menuconfig can generate the "If unsure" message itself from
the architecture defaults? That will ensure consistency.

Nick.