From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Linux Kernel List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@osdl.org>
Subject: [ARM] Regression somewhere between 2.6.19 and 2.6.19-rc1
Date: Tue, 2 Jan 2007 16:39:23 +0000 [thread overview]
Message-ID: <20070102163923.GB12902@flint.arm.linux.org.uk> (raw)
I'm seeing utterly random behaviour from kernels on ARM SMP hardware
built after 2.6.19. I won't bother trying to paste the kernel output;
sometimes the kernel locks solid (no IRQs, no output to say what's wrong).
Other times I get the first line of an oops repeating but with random
addresses. Othertimes the oops doesn't complete.
2.6.19 runs fine.
So I just tried using git bisect to track down the problem. First issue
that presky cmpxchg() causing a build error. Ok, so I provide a version
to get around that.
Next problem:
fs/proc/proc_misc.c: In function `version_read_proc':
fs/proc/proc_misc.c:256: warning: implicit declaration of function `utsname'
fs/proc/proc_misc.c:256: error: invalid type argument of `->'
fs/proc/proc_misc.c:256: error: invalid type argument of `->'
make[3]: *** [fs/proc/proc_misc.o] Error 1
make[2]: *** [fs/proc] Error 2
make[1]: *** [fs] Error 2
make: *** [uImage] Error 2
It seems this breakage seems to have been introduced some 260-odd commits
prior to the point which git bisect wants me to test.
How do I tell git bisect "I can't test this, this is neither good nor bad,
please choose another to try" ? Or is git bisect hopeless given the large
amount of unbuildable commits thanks to our weekly merges?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
next reply other threads:[~2007-01-02 16:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-02 16:39 Russell King [this message]
2007-01-02 16:50 ` [ARM] Regression somewhere between 2.6.19 and 2.6.19-rc1 Russell King
2007-01-02 16:57 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070102163923.GB12902@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.