The check then is to see if a non {}'d block has no statements in it if the
ifdef is null. Hmmm. May be possible. Will think on it.
if (err)
+#ifdef CONFIG_GFAR_NAPI
napi_disable(priv-napi);
+#endif
-apw
-
To unsubscribe from this list: send the line unsubscribe
On Thu, Oct 18, 2007 at 01:13:52PM +0200, Ingo Molnar wrote:
latest checkpatch.pl works really well on sched.c.
there's only one problem left, this bogus false positive warning
reappeared:
WARNING: braces {} are not necessary for single statement blocks
#5710: FILE: sched.c:5710:
On Thu, Oct 18, 2007 at 08:25:21PM +0100, Andy Whitcroft wrote:
On Thu, Oct 18, 2007 at 01:13:52PM +0200, Ingo Molnar wrote:
latest checkpatch.pl works really well on sched.c.
there's only one problem left, this bogus false positive warning
reappeared:
WARNING: braces
On Tue, Oct 16, 2007 at 01:59:49PM -0400, Erez Zadok wrote:
> In message <[EMAIL PROTECTED]>, Andy Whitcroft writes:
> > On Sat, Oct 13, 2007 at 02:35:12PM -0400, Erez Zadok wrote:
> > > In message <[EMAIL PROTECTED]>, Andy Whitcroft writes:
> > > > On Fri
On Wed, Oct 17, 2007 at 04:52:26PM +0200, Ingo Molnar wrote:
> > We (myself, Kamalesh and Dhaval) have tested the patch below, w/o
> > being able to recreate the problem. The patch allows for
> > task_new_fair() to be called even for the case when child is being
> > added to another cpu's
mpile" window
Andy Whitcroft (27):
Version: 0.11
fix up cat_vet for the case where there are no control characters
any cast to a pointer introduces a type
cpp unary operator detection needs to float
attributes are also valid in type definitions
sizeof may be
o noticed that it's not valid to call into
> task_new_fair() if this_cpu != task_cpu(p).
>
> Reported-by: Kamalesh Babulal <[EMAIL PROTECTED]>
> Reported-by: Andy Whitcroft <[EMAIL PROTECTED]>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
I have submitt
On Tue, Oct 16, 2007 at 07:00:37PM +0100, Andy Whitcroft wrote:
> On Tue, Oct 16, 2007 at 11:46:31AM +0200, Ingo Molnar wrote:
> >
> > * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > * Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
On Tue, Oct 16, 2007 at 07:00:37PM +0100, Andy Whitcroft wrote:
On Tue, Oct 16, 2007 at 11:46:31AM +0200, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Kamalesh Babulal [EMAIL PROTECTED] wrote:
While running kernbench with the 2.6.23-git8 following oops
-by: Kamalesh Babulal [EMAIL PROTECTED]
Reported-by: Andy Whitcroft [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
I have submitted jobs against a couple of the releases which showed this
problem with this patch. They will be a while as there are other tests
running at the moment
window
Andy Whitcroft (27):
Version: 0.11
fix up cat_vet for the case where there are no control characters
any cast to a pointer introduces a type
cpp unary operator detection needs to float
attributes are also valid in type definitions
sizeof may be a bareword
On Wed, Oct 17, 2007 at 04:52:26PM +0200, Ingo Molnar wrote:
We (myself, Kamalesh and Dhaval) have tested the patch below, w/o
being able to recreate the problem. The patch allows for
task_new_fair() to be called even for the case when child is being
added to another cpu's runqueue.
On Tue, Oct 16, 2007 at 01:59:49PM -0400, Erez Zadok wrote:
In message [EMAIL PROTECTED], Andy Whitcroft writes:
On Sat, Oct 13, 2007 at 02:35:12PM -0400, Erez Zadok wrote:
In message [EMAIL PROTECTED], Andy Whitcroft writes:
On Fri, Oct 12, 2007 at 03:26:54PM -0400, Mike D. Day wrote
revamp of the unary detection to make it more parser like
- a new summary at the bottom of the report
- --strict option for subjective checks
- --file to enable checking on complete files
- support for use in emacs "compile" window
Andy Whitcroft (27):
Version: 0.11
On Tue, Oct 16, 2007 at 11:46:31AM +0200, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> >
> > > While running kernbench with the 2.6.23-git8 following oops is
> > > produced
> > >
> > > Unable to handle kernel NULL
On Tue, Oct 16, 2007 at 11:10:12AM +0200, Ingo Molnar wrote:
>
> * Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
> > While running kernbench with the 2.6.23-git8 following oops is
> > produced
> >
> > Unable to handle kernel NULL pointer dereference at 0010 RIP:
> > []
On Tue, Oct 16, 2007 at 11:10:12AM +0200, Ingo Molnar wrote:
* Kamalesh Babulal [EMAIL PROTECTED] wrote:
While running kernbench with the 2.6.23-git8 following oops is
produced
Unable to handle kernel NULL pointer dereference at 0010 RIP:
[8033f347]
On Tue, Oct 16, 2007 at 11:46:31AM +0200, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Kamalesh Babulal [EMAIL PROTECTED] wrote:
While running kernbench with the 2.6.23-git8 following oops is
produced
Unable to handle kernel NULL pointer dereference at
revamp of the unary detection to make it more parser like
- a new summary at the bottom of the report
- --strict option for subjective checks
- --file to enable checking on complete files
- support for use in emacs compile window
Andy Whitcroft (27):
Version: 0.11
fix up cat_vet
On Sat, Oct 13, 2007 at 02:35:12PM -0400, Erez Zadok wrote:
> In message <[EMAIL PROTECTED]>, Andy Whitcroft writes:
> > On Fri, Oct 12, 2007 at 03:26:54PM -0400, Mike D. Day wrote:
> > > Fix line number reporting when checking source files (as opposed to
> > >
On Sat, Oct 13, 2007 at 02:35:12PM -0400, Erez Zadok wrote:
In message [EMAIL PROTECTED], Andy Whitcroft writes:
On Fri, Oct 12, 2007 at 03:26:54PM -0400, Mike D. Day wrote:
Fix line number reporting when checking source files (as opposed to
patches)
Signed-off-by: Mike D. Day
On Sat, Oct 13, 2007 at 02:55:01PM +0200, Jan Engelhardt wrote:
>
> On Oct 13 2007 14:47, Adrian Bunk wrote:
> >On Sat, Oct 13, 2007 at 02:28:00PM +0200, Geert Uytterhoeven wrote:
> >> scripts/checkpatch.pl doesn't seem to like this patch:
> >>
> >> $ scripts/checkpatch.pl
On Sat, Oct 13, 2007 at 02:55:01PM +0200, Jan Engelhardt wrote:
On Oct 13 2007 14:47, Adrian Bunk wrote:
On Sat, Oct 13, 2007 at 02:28:00PM +0200, Geert Uytterhoeven wrote:
scripts/checkpatch.pl doesn't seem to like this patch:
$ scripts/checkpatch.pl m68k-export-asm-cachectl-h.diff
On Fri, Oct 12, 2007 at 03:26:54PM -0400, Mike D. Day wrote:
> Fix line number reporting when checking source files (as opposed to
> patches)
>
> Signed-off-by: Mike D. Day <[EMAIL PROTECTED]>
Sorry you've had to fix this about 4 times, mostly because of ongoing
changes, and slow replication
On Fri, Oct 12, 2007 at 03:26:54PM -0400, Mike D. Day wrote:
Fix line number reporting when checking source files (as opposed to
patches)
Signed-off-by: Mike D. Day [EMAIL PROTECTED]
Sorry you've had to fix this about 4 times, mostly because of ongoing
changes, and slow replication getting
On Thu, Oct 11, 2007 at 08:28:00AM -0400, Mike D. Day wrote:
> When forming the prefix to output error msgs in gnu gcc format, the
> lack of a type ($ or @) when referencing ARGV causes error messages.
>
> When invoked to check source files, the linenumber was off by +3 in
> the gcc format
On Sun, Oct 07, 2007 at 03:05:47PM -0400, Erez Zadok wrote:
>
> and got many perl warnings such as:
>
> Use of uninitialized value in concatenation (.) or string at
> ./scripts/checkpatch.pl line 455.
Yes, this support seems to be wholy broken, as a non emacs user I had
failed to test it
On Tue, Oct 09, 2007 at 03:43:20PM -0500, Mark Langsdorf wrote:
> On Tuesday 09 October 2007 15:06, Andi Kleen wrote:
> > "Mark Langsdorf" <[EMAIL PROTECTED]> writes:
> >
> > > This patch should apply cleanly to the 2.6.22.6 kernel.
> >
> > Isn't that a little old? The earliest this could be
On Tue, Oct 09, 2007 at 03:43:20PM -0500, Mark Langsdorf wrote:
On Tuesday 09 October 2007 15:06, Andi Kleen wrote:
Mark Langsdorf [EMAIL PROTECTED] writes:
This patch should apply cleanly to the 2.6.22.6 kernel.
Isn't that a little old? The earliest this could be merged
is the
On Sun, Oct 07, 2007 at 03:05:47PM -0400, Erez Zadok wrote:
and got many perl warnings such as:
Use of uninitialized value in concatenation (.) or string at
./scripts/checkpatch.pl line 455.
Yes, this support seems to be wholy broken, as a non emacs user I had
failed to test it correctly
On Thu, Oct 11, 2007 at 08:28:00AM -0400, Mike D. Day wrote:
When forming the prefix to output error msgs in gnu gcc format, the
lack of a type ($ or @) when referencing ARGV causes error messages.
When invoked to check source files, the linenumber was off by +3 in
the gcc format output.
On Tue, Oct 02, 2007 at 09:01:10AM +0200, Andi Kleen wrote:
> x86_64-sparsemem_vmemmap-2m-page-size-support.patch
> x86_64-sparsemem_vmemmap-vmemmap-x86_64-convert-to-new-helper-based-initialisation.patch
>
> Look like these two should be merged together
>
> Also I'm concerned about a
On Tue, Oct 02, 2007 at 09:01:10AM +0200, Andi Kleen wrote:
x86_64-sparsemem_vmemmap-2m-page-size-support.patch
x86_64-sparsemem_vmemmap-vmemmap-x86_64-convert-to-new-helper-based-initialisation.patch
Look like these two should be merged together
Also I'm concerned about a third
On Mon, Oct 01, 2007 at 12:30:07AM -0700, Andrew Morton wrote:
> On Mon, 1 Oct 2007 08:44:48 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > (lkml Cc:-ed - this might be of interest to others too)
> >
> > * Andy Whitcroft <[EMAIL PROTECTED]> wr
On Mon, Oct 01, 2007 at 12:30:07AM -0700, Andrew Morton wrote:
On Mon, 1 Oct 2007 08:44:48 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:
(lkml Cc:-ed - this might be of interest to others too)
* Andy Whitcroft [EMAIL PROTECTED] wrote:
WARNING: EXPORT_SYMBOL(foo); should immediately
On Fri, Sep 28, 2007 at 10:46:42AM -0700, Andrew Morton wrote:
> On Fri, 28 Sep 2007 14:21:38 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Sep 28, 2007 at 12:49:35PM +0200, Ingo Molnar wrote:
> > >
> > > * Andy Whitcroft <[EMAIL PROTECTED
On Fri, Sep 28, 2007 at 10:46:42AM -0700, Andrew Morton wrote:
On Fri, 28 Sep 2007 14:21:38 +0100 Andy Whitcroft [EMAIL PROTECTED] wrote:
On Fri, Sep 28, 2007 at 12:49:35PM +0200, Ingo Molnar wrote:
* Andy Whitcroft [EMAIL PROTECTED] wrote:
On Fri, Sep 28, 2007 at 11:39:02AM
On Fri, Sep 28, 2007 at 04:37:49PM +0300, Pekka Enberg wrote:
> Hi Andy,
>
> On 9/28/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> > That is unfair. Every time we discuss it I state that I disagree that
> > hiding mostly useful tests is a good thing. I would l
On Fri, Sep 28, 2007 at 12:49:35PM +0200, Ingo Molnar wrote:
>
> * Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Sep 28, 2007 at 11:39:02AM +0200, Ingo Molnar wrote:
> >
> > > And this is not about any particular false positive. I dont mind an
&
On Fri, Sep 28, 2007 at 11:39:02AM +0200, Ingo Molnar wrote:
>
> * Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
> > > > WARNING: multiple assignments should be avoided
> > > > #2319:
> > > > + max_load = this_load = total_load = to
On Fri, Sep 28, 2007 at 10:40:03AM +0200, Ingo Molnar wrote:
>
> * Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
> > This version brings a number of new checks, and a number of bug fixes.
>
> your checkpatch patch itself produces 22 warnings ...
>
On Fri, Sep 28, 2007 at 02:01:32AM -0700, Andrew Morton wrote:
> On Fri, 28 Sep 2007 10:40:03 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > i ran it over kernel/sched.c and there are many bogus warnings that i
> > reported to you earlier:
> >
> > WARNING: multiple assignments should be
On Fri, Sep 28, 2007 at 10:32:38AM +0200, Thomas Gleixner wrote:
> On Fri, 2007-09-28 at 01:26 -0700, Andrew Morton wrote:
> > On Fri, 28 Sep 2007 10:17:30 +0200 Thomas Gleixner <[EMAIL PROTECTED]>
> > wrote:
> >
> > > can we please add this to checkpatch.pl ?
> > >
> > > > -spinlock_t
On Fri, Sep 28, 2007 at 01:26:56AM -0700, Andrew Morton wrote:
> On Fri, 28 Sep 2007 10:17:30 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > can we please add this to checkpatch.pl ?
> >
> > > -spinlock_t bpci_lock = SPIN_LOCK_UNLOCKED;
> > > +DEFINE_SPINLOCK(bpci_lock);
>
> That check
On Fri, Sep 28, 2007 at 01:26:56AM -0700, Andrew Morton wrote:
On Fri, 28 Sep 2007 10:17:30 +0200 Thomas Gleixner [EMAIL PROTECTED] wrote:
can we please add this to checkpatch.pl ?
-spinlock_t bpci_lock = SPIN_LOCK_UNLOCKED;
+DEFINE_SPINLOCK(bpci_lock);
That check is already in
On Fri, Sep 28, 2007 at 04:37:49PM +0300, Pekka Enberg wrote:
Hi Andy,
On 9/28/07, Andy Whitcroft [EMAIL PROTECTED] wrote:
That is unfair. Every time we discuss it I state that I disagree that
hiding mostly useful tests is a good thing. I would love the tests to
be 100% accurate
On Fri, Sep 28, 2007 at 12:49:35PM +0200, Ingo Molnar wrote:
* Andy Whitcroft [EMAIL PROTECTED] wrote:
On Fri, Sep 28, 2007 at 11:39:02AM +0200, Ingo Molnar wrote:
And this is not about any particular false positive. I dont mind an
advanced mode non-default opt-in option
On Fri, Sep 28, 2007 at 11:39:02AM +0200, Ingo Molnar wrote:
* Andy Whitcroft [EMAIL PROTECTED] wrote:
WARNING: multiple assignments should be avoided
#2319:
+ max_load = this_load = total_load = total_pwr = 0;
That warning is non-bogus, although this is one
On Fri, Sep 28, 2007 at 10:40:03AM +0200, Ingo Molnar wrote:
* Andy Whitcroft [EMAIL PROTECTED] wrote:
This version brings a number of new checks, and a number of bug fixes.
your checkpatch patch itself produces 22 warnings ...
i ran it over kernel/sched.c and there are many bogus
On Fri, Sep 28, 2007 at 02:01:32AM -0700, Andrew Morton wrote:
On Fri, 28 Sep 2007 10:40:03 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:
i ran it over kernel/sched.c and there are many bogus warnings that i
reported to you earlier:
WARNING: multiple assignments should be avoided
On Fri, Sep 28, 2007 at 10:32:38AM +0200, Thomas Gleixner wrote:
On Fri, 2007-09-28 at 01:26 -0700, Andrew Morton wrote:
On Fri, 28 Sep 2007 10:17:30 +0200 Thomas Gleixner [EMAIL PROTECTED]
wrote:
can we please add this to checkpatch.pl ?
-spinlock_t bpci_lock =
> actually, my first patch wasn't using weak symbols, but I have been
> convinced that it's the way to go(tm). Please see
> http://lkml.org/lkml/2007/9/1/131 and the ongoing thread.
>
> I am fine with replacing the brk randomization patch with the one that
> wasn't using weak symbols (posted
actually, my first patch wasn't using weak symbols, but I have been
convinced that it's the way to go(tm). Please see
http://lkml.org/lkml/2007/9/1/131 and the ongoing thread.
I am fine with replacing the brk randomization patch with the one that
wasn't using weak symbols (posted in the
arch/powerpc/mm/init_64.c:211: warning: passing arg 1 of
> `vmemmap_section_start' makes pointer from integer without a cast
>
> vmemmap_section_start() gets called with an argument which is unsigned long.
>
> Signed-off-by: Badari Pulavarty <[EMAIL PROTECTED]>
Clearly cor
: passing arg 1 of
`vmemmap_section_start' makes pointer from integer without a cast
vmemmap_section_start() gets called with an argument which is unsigned long.
Signed-off-by: Badari Pulavarty [EMAIL PROTECTED]
Clearly correct.
Acked-by: Andy Whitcroft [EMAIL PROTECTED]
Index: linux
2.6.23-rc6-mm1, 2.6.23-rc7-mm1 and 2.6.23-rc8-mm1 all fail to link
correctly on a powerpc machine (elm3b19) in our test grid. It fails as
below:
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1
On Wed, Sep 19, 2007 at 07:44:03PM +0200, Sam Ravnborg wrote:
> On Wed, Sep 19, 2007 at 10:28:48AM +0100, Andy Whitcroft wrote:
> > I am seeing this strange link error from a PowerMac G5 (powerpc):
> >
> > [...]
> > KSYM.tmp_kallsyms2.S
> > AS
On Wed, Sep 19, 2007 at 07:44:03PM +0200, Sam Ravnborg wrote:
On Wed, Sep 19, 2007 at 10:28:48AM +0100, Andy Whitcroft wrote:
I am seeing this strange link error from a PowerMac G5 (powerpc):
[...]
KSYM.tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
2.6.23-rc6-mm1, 2.6.23-rc7-mm1 and 2.6.23-rc8-mm1 all fail to link
correctly on a powerpc machine (elm3b19) in our test grid. It fails as
below:
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1
Seeing the following from an older power LPAR, pretty sure we had
this in the previous -mm also:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0047ac8
cpu 0x0: Vector: 300 (Data Access) at [c058f750]
pc:
Getting compile errors on S390:
CC arch/s390/mm/cmm.o
arch/s390/mm/cmm.c: In function `cmm_init':
arch/s390/mm/cmm.c:431: error: implicit declaration of function
`register_oom_notifier'
arch/s390/mm/cmm.c:443: error: implicit declaration of function
Getting compile errors on S390:
CC arch/s390/mm/cmm.o
arch/s390/mm/cmm.c: In function `cmm_init':
arch/s390/mm/cmm.c:431: error: implicit declaration of function
`register_oom_notifier'
arch/s390/mm/cmm.c:443: error: implicit declaration of function
Seeing the following from an older power LPAR, pretty sure we had
this in the previous -mm also:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0047ac8
cpu 0x0: Vector: 300 (Data Access) at [c058f750]
pc:
and tell me if it does what you
need? I refactored it a bit applying it.
-apw
=== 8< ===
#!/usr/bin/perl -w
# (c) 2001, Dave Jones. <[EMAIL PROTECTED]> (the file handling bit)
# (c) 2005, Joel Schopp <[EMAIL PROTECTED]> (the ugly bit)
# (c) 2007, Andy Whitcroft <[EMAIL PROTEC
This sounds an awful lot like the same problem I reported with fsck
hanging. I believe that Hugh had a candidate patch for that, which was
related to dirty tracking limits. It seems that that patch tested, and
acked by Peter. All on lkml under:
2.6.23-rc6-mm1 -- mkfs stuck in 'D'
-apw
This sounds an awful lot like the same problem I reported with fsck
hanging. I believe that Hugh had a candidate patch for that, which was
related to dirty tracking limits. It seems that that patch tested, and
acked by Peter. All on lkml under:
2.6.23-rc6-mm1 -- mkfs stuck in 'D'
-apw
if it does what you
need? I refactored it a bit applying it.
-apw
=== 8 ===
#!/usr/bin/perl -w
# (c) 2001, Dave Jones. [EMAIL PROTECTED] (the file handling bit)
# (c) 2005, Joel Schopp [EMAIL PROTECTED] (the ugly bit)
# (c) 2007, Andy Whitcroft [EMAIL PROTECTED] (new conditions, test suite, etc
On Thu, Sep 20, 2007 at 07:19:59PM +0530, Satyam Sharma wrote:
>
>
> On Thu, 20 Sep 2007, Tetsuo Handa wrote:
> >
> > I checked my patch using checkpatch.pl version 0.10
> > and I got the following error.
> >
> > ERROR: need consistent spacing around '*' (ctx:WxV)
> > #2334: FILE:
On Thu, Sep 20, 2007 at 12:38:55AM +0200, Michael Opdenacker wrote:
> Andrew, you're completely right... The patches should all aim at being
> included into mainline or die.
>
> I'm finishing a sequence of crazy weeks and I will have time to send you
> patches one by one next week, starting with
On Thu, Sep 20, 2007 at 12:38:55AM +0200, Michael Opdenacker wrote:
Andrew, you're completely right... The patches should all aim at being
included into mainline or die.
I'm finishing a sequence of crazy weeks and I will have time to send you
patches one by one next week, starting with the
On Fri, Sep 14, 2007 at 10:49:05AM +0100, Andy Whitcroft wrote:
> On Tue, Sep 11, 2007 at 06:30:49PM +0100, Andy Whitcroft wrote:
> > Annoyingly this seems to be intermittent, and I have not managed to get
> > a machine into this state again yet. Will keep trying.
>
> Ok,
On Wed, Sep 19, 2007 at 06:36:29PM +0200, Segher Boessenkool wrote:
> >I am seeing this strange link error from a PowerMac G5 (powerpc):
> >
> > [...]
> >KSYM.tmp_kallsyms2.S
> >AS .tmp_kallsyms2.o
> >LD vmlinux.o
> > ld: dynreloc miscount for fs/built-in.o, section
Seems I have a case of a largish i386 NUMA (NUMA-Q) which has a mkfs
stuck in a 'D' wait:
===
mkfs.ext2 D c10220f4 0 6233 6222
c344fc80 0082 0286 c10220f4 c344fc90 002ed099 c2963340 c2b9f640
c142bce0 c2b9f640 c344fc90 002ed099 c344fcfc
Seeing the following panic booting an old powerpc LPAR:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0047b48
cpu 0x0: Vector: 300 (Data Access) at [c06a3750]
pc: c0047b48: .pSeries_log_error+0x364/0x420
lr:
I am seeing this strange link error from a PowerMac G5 (powerpc):
[...]
KSYM.tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1
Compiler version
I am seeing this strange link error from a PowerMac G5 (powerpc):
[...]
KSYM.tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1
Compiler version
Seeing the following panic booting an old powerpc LPAR:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0047b48
cpu 0x0: Vector: 300 (Data Access) at [c06a3750]
pc: c0047b48: .pSeries_log_error+0x364/0x420
lr:
Seems I have a case of a largish i386 NUMA (NUMA-Q) which has a mkfs
stuck in a 'D' wait:
===
mkfs.ext2 D c10220f4 0 6233 6222
c344fc80 0082 0286 c10220f4 c344fc90 002ed099 c2963340 c2b9f640
c142bce0 c2b9f640 c344fc90 002ed099 c344fcfc
On Wed, Sep 19, 2007 at 06:36:29PM +0200, Segher Boessenkool wrote:
I am seeing this strange link error from a PowerMac G5 (powerpc):
[...]
KSYM.tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can
On Fri, Sep 14, 2007 at 10:49:05AM +0100, Andy Whitcroft wrote:
On Tue, Sep 11, 2007 at 06:30:49PM +0100, Andy Whitcroft wrote:
Annoyingly this seems to be intermittent, and I have not managed to get
a machine into this state again yet. Will keep trying.
Ok, I have been completly
On Tue, Sep 18, 2007 at 02:43:48PM +0530, Kamalesh Babulal wrote:
> Andrew Morton wrote:
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
> >
> >2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
> >
> >
>
>
> Hi Andrew,
>
> The 2.6.23-rc6-mm1build
On Tue, Sep 18, 2007 at 02:43:48PM +0530, Kamalesh Babulal wrote:
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
snip
Hi Andrew,
The 2.6.23-rc6-mm1build fails at
Anton, this seems a little reminicient of that bug which popped up in
2.6.23-rc3 so do with SLB loading (if memory serves), with machine
checks and signal 7's. Of course that is _supposed_ to be fixed by this
time ...
I believe it was Paul who fixed up that one, and he is already copied.
-apw
On Tue, Sep 11, 2007 at 06:30:49PM +0100, Andy Whitcroft wrote:
> Annoyingly this seems to be intermittent, and I have not managed to get
> a machine into this state again yet. Will keep trying.
Ok, I have been completly unsuccessful in reproducing this. Dispite
having two distinct ma
On Tue, Sep 11, 2007 at 04:31:12AM +0900, FUJITA Tomonori wrote:
[...]
> > The only patch which touches qla1280 is git-block.patch. From a quick
> > squizz the change looks OK, although it's tricky and something might have
> > broken.
> >
> > (the dprintk at line 2929 needs to print remseg, not
On Tue, Sep 11, 2007 at 04:31:12AM +0900, FUJITA Tomonori wrote:
[...]
The only patch which touches qla1280 is git-block.patch. From a quick
squizz the change looks OK, although it's tricky and something might have
broken.
(the dprintk at line 2929 needs to print remseg, not seg_cnt).
On Tue, Sep 11, 2007 at 06:30:49PM +0100, Andy Whitcroft wrote:
Annoyingly this seems to be intermittent, and I have not managed to get
a machine into this state again yet. Will keep trying.
Ok, I have been completly unsuccessful in reproducing this. Dispite
having two distinct machines
Anton, this seems a little reminicient of that bug which popped up in
2.6.23-rc3 so do with SLB loading (if memory serves), with machine
checks and signal 7's. Of course that is _supposed_ to be fixed by this
time ...
I believe it was Paul who fixed up that one, and he is already copied.
-apw
On Tue, Sep 11, 2007 at 04:10:47AM +0900, FUJITA Tomonori wrote:
> > The only patch which touches qla1280 is git-block.patch. From a quick
> > squizz the change looks OK, although it's tricky and something might have
> > broken.
>
> Can you try this patch (against 2.6.23-rc4-mm1)?
Yep this
On Tue, Aug 21, 2007 at 06:29:59PM -0400, Mike Frysinger wrote:
> Check for a few common errors in Blackfin-specific code wrt MMR loading in
> assembly and doing core/system syncs.
If we are going to pull arch specific things into checkpatch I think we
need to make sure we are pretty specific
On Tue, Aug 21, 2007 at 06:29:59PM -0400, Mike Frysinger wrote:
Check for a few common errors in Blackfin-specific code wrt MMR loading in
assembly and doing core/system syncs.
If we are going to pull arch specific things into checkpatch I think we
need to make sure we are pretty specific about
On Tue, Sep 11, 2007 at 04:10:47AM +0900, FUJITA Tomonori wrote:
The only patch which touches qla1280 is git-block.patch. From a quick
squizz the change looks OK, although it's tricky and something might have
broken.
Can you try this patch (against 2.6.23-rc4-mm1)?
Yep this patch seems
On Wed, Sep 12, 2007 at 06:58:54PM +0200, Michal Piotrowski wrote:
> FS
>
> Subject : hanging ext3 dbench tests
> References : http://lkml.org/lkml/2007/9/11/176
> Last known good : ?
> Submitter : Andy Whitcroft <[EMAIL PROTECTED]>
> Ca
On Wed, Sep 12, 2007 at 11:09:47AM -0400, Lee Schermerhorn wrote:
> > Interesting, I don't see a memory controller function in the stack
> > trace, but I'll double check to see if I can find some silly race
> > condition in there.
>
> right. I noticed that after I sent the mail.
>
> Also,
line endings
- detect redundant casts for kalloc()
Andy Whitcroft (18):
Version: 0.10
asmlinkage is also a storage type
pull out inline specifiers
allow only some operators before a unary operator
parenthesised values may span line ends
add additional
The following commit just hit mainline and all my powerpc test boxes are
failing during compilation:
commit f629307c857c030d5a3dd777fee37c8bb395e171
tty: termios locking functions break with new termios type
Failing as follows:
drivers/char/tty_ioctl.c: In function
line endings
- detect redundant casts for kalloc()
Andy Whitcroft (18):
Version: 0.10
asmlinkage is also a storage type
pull out inline specifiers
allow only some operators before a unary operator
parenthesised values may span line ends
add additional
On Wed, Sep 12, 2007 at 11:09:47AM -0400, Lee Schermerhorn wrote:
Interesting, I don't see a memory controller function in the stack
trace, but I'll double check to see if I can find some silly race
condition in there.
right. I noticed that after I sent the mail.
Also, config
On Wed, Sep 12, 2007 at 06:58:54PM +0200, Michal Piotrowski wrote:
FS
Subject : hanging ext3 dbench tests
References : http://lkml.org/lkml/2007/9/11/176
Last known good : ?
Submitter : Andy Whitcroft [EMAIL PROTECTED]
Caused-By : ?
Handled-By : ?
Status
The following commit just hit mainline and all my powerpc test boxes are
failing during compilation:
commit f629307c857c030d5a3dd777fee37c8bb395e171
tty: termios locking functions break with new termios type
Failing as follows:
drivers/char/tty_ioctl.c: In function
401 - 500 of 940 matches
Mail list logo
