[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#752881: Fwd: Bug#752881: Found exact revision that causes problem



For got to cc this to the bug...-(

On 21 July 2014 09:29, Ben Hutchings <ben@decadent.org.uk> wrote:
...
>
> Assuming that this regression only happened once, we can be fairly
> confident that it happened before
> 4c823cc3d568277aa6340d8df6981e34f4c4dee5, but as that is around v3.2-rc1
> it doesn't reduce the range very much. :-(
>

Thank for looking at this issue. I don't get what is going on here
either but it seemed to reliably cause the problem BUT when I reverted
this change in the v3.2 kernel it still had the fault! (Broke my
heart!).

Then I built the version 8a9c59 (just prior to the bad version) from
scratch and this time it had the fault where as before worked!
 So I think I have to build completely cleanly each time...

So I am doing a git bisect again using  a cleaner way of rebuilding the kernels.

I did compile one on either side of it and it seemed solid. i.e.
rebooting the same kernel reliably results in a failure. I didn't
reboot every kernel but certainly the squeeze one is always good and
the wheezy is almost always bad (sometimes you can partially write a
BluRay before it completely bombs but it always gives these errors on
kernel booting).

One idea was that it might be a kernel configuration dependant because
I had to do make oldconfig and as I switched back and forth between
revisions it might have different configurations. But I just diff'ed
the config file from the last 4 builds and there was *NO* difference
so that should cover good and bad builds.

As I didn't rebuild the last set of kernels from scratch I suspect
this is the  cause of the inconstancies.

I am now trying the bisection again but now doing this each time.
  1. Rebuilding from scratch (make-kpkg clean)
  2. Copying the same config file and doing make oldconfig and always
accepting the default.

So far I have:

git bisect start
# bad: [8a9c594422ecad912d6470888acdee9a1236ad68]
drivers/block/loop.c: emit uevent on auto release
git bisect bad 8a9c594422ecad912d6470888acdee9a1236ad68
# good: [02f8c6aee8df3cdc935e9bdd4f2d020306035dbe] Linux 3.0
git bisect good 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe
# good: [0003230e8200699860f0b10af524dc47bf8aecad] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6
git bisect good 0003230e8200699860f0b10af524dc47bf8aecad
# good: [206d440f64030b6425841bf7cb38e26a5ea0c382] xfs: Fix build
breakage in xfs_iops.c when CONFIG_FS_POSIX_ACL is not set
git bisect good 206d440f64030b6425841bf7cb38e26a5ea0c382
# skip: [c11abbbaa3252875c5740a6880b9a1a6f1e2a870] Merge branch
'slub/lockless' of
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6
git bisect skip c11abbbaa3252875c5740a6880b9a1a6f1e2a870

The last skip because I got compile errors.
...
arch/x86/built-in.o: In function `atomic_read':
/movies3/work/linux/arch/x86/include/asm/atomic.h:25: undefined
reference to `__tracepoint_xen_cpu_write_gdt_entry'
...
Actually I couldn't build the squeeze kernel under wheezy (lots of
problems) so I was building that under the squeeze in a virtual
machine.

This is a real annoying bug because I have to build so many kernels
and hit compile problems but I will crush it.
Suggestions on improving this debug plan would be much welcomed.

Andrew


Reply to: