[tip:perf/urgent] perf tools: check if -DFORTIFY_SOURCE= 2 is allowed
Commit-ID: d2f32479e5526a1ab3b4e43910fcb279871524ce
Gitweb: http://git.kernel.org/tip/d2f32479e5526a1ab3b4e43910fcb279871524ce
Author: Marcin Slusarz
AuthorDate: Sun, 17 Feb 2013 16:03:36 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 13 Mar 2013 16:57:27 -0300
perf tools: check if -DFORTIFY_SOURCE=2 is allowed
It seems gcc (4.7.2) defines _FORTIFY_SOURCE internally and becomes
confused when it sees another definition in flags.
For me, build failed like this:
CHK glibc
Makefile:548: *** No gnu/libc-version.h found, please install
glibc-dev[el]/glibc-static. Stop.
and only with V=1 it printed:
:0:0: error: "_FORTIFY_SOURCE" redefined [-Werror]
:1:0: note: this is the location of the previous definition
Signed-off-by: Marcin Slusarz
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1361113416-8662-1-git-send-email-marcin.slus...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Makefile | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index a2108ca..bb74c79 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -95,7 +95,7 @@ ifeq ("$(origin DEBUG)", "command line")
PERF_DEBUG = $(DEBUG)
endif
ifndef PERF_DEBUG
- CFLAGS_OPTIMIZE = -O6 -D_FORTIFY_SOURCE=2
+ CFLAGS_OPTIMIZE = -O6
endif
ifdef PARSER_DEBUG
@@ -180,6 +180,12 @@ ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror
-Wvolatile-register-var,-W
CFLAGS := $(CFLAGS) -Wvolatile-register-var
endif
+ifndef PERF_DEBUG
+ ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS)
-D_FORTIFY_SOURCE=2,-D_FORTIFY_SOURCE=2),y)
+ CFLAGS := $(CFLAGS) -D_FORTIFY_SOURCE=2
+ endif
+endif
+
### --- END CONFIGURATION SECTION ---
ifeq ($(srctree),)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf tools: check if -DFORTIFY_SOURCE= 2 is allowed
Commit-ID: d2f32479e5526a1ab3b4e43910fcb279871524ce Gitweb: http://git.kernel.org/tip/d2f32479e5526a1ab3b4e43910fcb279871524ce Author: Marcin Slusarz marcin.slus...@gmail.com AuthorDate: Sun, 17 Feb 2013 16:03:36 +0100 Committer: Arnaldo Carvalho de Melo a...@redhat.com CommitDate: Wed, 13 Mar 2013 16:57:27 -0300 perf tools: check if -DFORTIFY_SOURCE=2 is allowed It seems gcc (4.7.2) defines _FORTIFY_SOURCE internally and becomes confused when it sees another definition in flags. For me, build failed like this: CHK glibc Makefile:548: *** No gnu/libc-version.h found, please install glibc-dev[el]/glibc-static. Stop. and only with V=1 it printed: command-line:0:0: error: _FORTIFY_SOURCE redefined [-Werror] stdin:1:0: note: this is the location of the previous definition Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com Cc: Ingo Molnar mi...@redhat.com Cc: Paul Mackerras pau...@samba.org Cc: Peter Zijlstra a.p.zijls...@chello.nl Link: http://lkml.kernel.org/r/1361113416-8662-1-git-send-email-marcin.slus...@gmail.com Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com --- tools/perf/Makefile | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tools/perf/Makefile b/tools/perf/Makefile index a2108ca..bb74c79 100644 --- a/tools/perf/Makefile +++ b/tools/perf/Makefile @@ -95,7 +95,7 @@ ifeq ($(origin DEBUG), command line) PERF_DEBUG = $(DEBUG) endif ifndef PERF_DEBUG - CFLAGS_OPTIMIZE = -O6 -D_FORTIFY_SOURCE=2 + CFLAGS_OPTIMIZE = -O6 endif ifdef PARSER_DEBUG @@ -180,6 +180,12 @@ ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -Wvolatile-register-var,-W CFLAGS := $(CFLAGS) -Wvolatile-register-var endif +ifndef PERF_DEBUG + ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -D_FORTIFY_SOURCE=2,-D_FORTIFY_SOURCE=2),y) + CFLAGS := $(CFLAGS) -D_FORTIFY_SOURCE=2 + endif +endif + ### --- END CONFIGURATION SECTION --- ifeq ($(srctree),) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau lockdep splat
On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: > On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: > > Dropping Tegra ML, it's not the place where Nouveau mails should go. > > $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c > ... > linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) > > Maybe get_maintainer.pl patterns need correction... That's new feature (introduced in commit eb90d0855b75f8 "get_maintainer: allow keywords to match filenames") of get_maintainer.pl which now can look at file contents... TEGRA SUPPORT M: Stephen Warren L: linux-te...@vger.kernel.org Q: http://patchwork.ozlabs.org/project/linux-tegra/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git S: Supported K: (?i)[^a-z]tegra Note the last line and this: $ grep tegra drivers/gpu/drm/nouveau/nv50_display.c u32 rekey = 56; /* binary driver, and tegra constant */ max_ac_packet -= 18; /* constant from tegra */ Fun. Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau lockdep splat
On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: Dropping Tegra ML, it's not the place where Nouveau mails should go. $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c ... linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) Maybe get_maintainer.pl patterns need correction... That's new feature (introduced in commit eb90d0855b75f8 get_maintainer: allow keywords to match filenames) of get_maintainer.pl which now can look at file contents... TEGRA SUPPORT M: Stephen Warren swar...@wwwdotorg.org L: linux-te...@vger.kernel.org Q: http://patchwork.ozlabs.org/project/linux-tegra/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git S: Supported K: (?i)[^a-z]tegra Note the last line and this: $ grep tegra drivers/gpu/drm/nouveau/nv50_display.c u32 rekey = 56; /* binary driver, and tegra constant */ max_ac_packet -= 18; /* constant from tegra */ Fun. Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable request] fix for nouveau mem corruption [was: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242]
On Wed, Feb 20, 2013 at 03:47:05PM +0100, Jiri Slaby wrote: > On 02/19/2013 08:07 AM, Marcin Slusarz wrote: > >>> Crash/warning should be fixed by commit > >>> cfd376b6bfccf33782a0748a9c70f7f752f8b869 > >>> "drm/nouveau/vm: fix memory corruption when pgt allocation fails". > >> > >> Oh, thanks for the pointer. Could that bug cause real "memory > >> corruption"? As we're hunting one there... > > > > Yes. > > > >> Isn't this a stable-3.7 candidate? > > > > Should have been :/. > > Ok, if you have no objections: stable fellows, please consider the > commit above for stable inclusion. As far as I can tell this is only > applicable for 3.7 -- Marcin? Correct. Please apply it for 3.7.x. Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable request] fix for nouveau mem corruption [was: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242]
On Wed, Feb 20, 2013 at 03:47:05PM +0100, Jiri Slaby wrote: On 02/19/2013 08:07 AM, Marcin Slusarz wrote: Crash/warning should be fixed by commit cfd376b6bfccf33782a0748a9c70f7f752f8b869 drm/nouveau/vm: fix memory corruption when pgt allocation fails. Oh, thanks for the pointer. Could that bug cause real memory corruption? As we're hunting one there... Yes. Isn't this a stable-3.7 candidate? Should have been :/. Ok, if you have no objections: stable fellows, please consider the commit above for stable inclusion. As far as I can tell this is only applicable for 3.7 -- Marcin? Correct. Please apply it for 3.7.x. Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
On Tue, Feb 19, 2013 at 08:07:44AM +0100, Marcin Slusarz wrote:
> On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote:
> > On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
> > > On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
> > >> Hi,
> > >>
> > >> we have a report of WARNING from 3.7.6 in nouveau at
> > >> drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
> > >> https://bugzilla.novell.com/show_bug.cgi?id=802347#c11
> > >>
> > >> There is an order 4 allocation failure in nouveau_drm_open ->
> > >> nouveau_vm_create, i.e. this one failed:
> > >> vm->pgt = kcalloc(vm->lpde - vm->fpde + 1, sizeof(*vm->pgt),
> > >> GFP_KERNEL);
> > >>
> > >> Then, on the error path in still in nouveau_drm_open, it is followed by
> > >> a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref ->
> > >> nouveau_mm_fini -> nouveau_vm_del -> nouveau_mm_fini which triggers the
> > >> warning.
> > >>
> > >> Any ideas?
> > >
> > > Crash/warning should be fixed by commit
> > > cfd376b6bfccf33782a0748a9c70f7f752f8b869
> > > "drm/nouveau/vm: fix memory corruption when pgt allocation fails".
> >
> > Oh, thanks for the pointer. Could that bug cause real "memory
> > corruption"? As we're hunting one there...
>
> Yes.
>
> > Isn't this a stable-3.7 candidate?
>
> Should have been :/.
>
> > > Tomorrow I'll post a patch for page allocation failure.
> >
> > What do you mean -- what kind of patch?
>
> A patch which will change pgt allocation to use vmalloc.
---
From: Marcin Slusarz
Subject: [PATCH] drm/nouveau: use vmalloc for pgt allocation
Page tables on nv50 take 48kB, which can be hard to allocate in one piece.
Let's use vmalloc.
Signed-off-by: Marcin Slusarz
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/core/subdev/vm/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
index 77c67fc..e66fb77 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
@@ -362,7 +362,7 @@ nouveau_vm_create(struct nouveau_vmmgr *vmm, u64 offset,
u64 length,
vm->fpde = offset >> (vmm->pgt_bits + 12);
vm->lpde = (offset + length - 1) >> (vmm->pgt_bits + 12);
- vm->pgt = kcalloc(vm->lpde - vm->fpde + 1, sizeof(*vm->pgt),
GFP_KERNEL);
+ vm->pgt = vzalloc((vm->lpde - vm->fpde + 1) * sizeof(*vm->pgt));
if (!vm->pgt) {
kfree(vm);
return -ENOMEM;
@@ -371,7 +371,7 @@ nouveau_vm_create(struct nouveau_vmmgr *vmm, u64 offset,
u64 length,
ret = nouveau_mm_init(>mm, mm_offset >> 12, mm_length >> 12,
block >> 12);
if (ret) {
- kfree(vm->pgt);
+ vfree(vm->pgt);
kfree(vm);
return ret;
}
@@ -446,7 +446,7 @@ nouveau_vm_del(struct nouveau_vm *vm)
}
nouveau_mm_fini(>mm);
- kfree(vm->pgt);
+ vfree(vm->pgt);
kfree(vm);
}
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
On Tue, Feb 19, 2013 at 08:07:44AM +0100, Marcin Slusarz wrote:
On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote:
On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
Hi,
we have a report of WARNING from 3.7.6 in nouveau at
drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
https://bugzilla.novell.com/show_bug.cgi?id=802347#c11
There is an order 4 allocation failure in nouveau_drm_open -
nouveau_vm_create, i.e. this one failed:
vm-pgt = kcalloc(vm-lpde - vm-fpde + 1, sizeof(*vm-pgt),
GFP_KERNEL);
Then, on the error path in still in nouveau_drm_open, it is followed by
a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref -
nouveau_mm_fini - nouveau_vm_del - nouveau_mm_fini which triggers the
warning.
Any ideas?
Crash/warning should be fixed by commit
cfd376b6bfccf33782a0748a9c70f7f752f8b869
drm/nouveau/vm: fix memory corruption when pgt allocation fails.
Oh, thanks for the pointer. Could that bug cause real memory
corruption? As we're hunting one there...
Yes.
Isn't this a stable-3.7 candidate?
Should have been :/.
Tomorrow I'll post a patch for page allocation failure.
What do you mean -- what kind of patch?
A patch which will change pgt allocation to use vmalloc.
---
From: Marcin Slusarz marcin.slus...@gmail.com
Subject: [PATCH] drm/nouveau: use vmalloc for pgt allocation
Page tables on nv50 take 48kB, which can be hard to allocate in one piece.
Let's use vmalloc.
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/core/subdev/vm/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
index 77c67fc..e66fb77 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
@@ -362,7 +362,7 @@ nouveau_vm_create(struct nouveau_vmmgr *vmm, u64 offset,
u64 length,
vm-fpde = offset (vmm-pgt_bits + 12);
vm-lpde = (offset + length - 1) (vmm-pgt_bits + 12);
- vm-pgt = kcalloc(vm-lpde - vm-fpde + 1, sizeof(*vm-pgt),
GFP_KERNEL);
+ vm-pgt = vzalloc((vm-lpde - vm-fpde + 1) * sizeof(*vm-pgt));
if (!vm-pgt) {
kfree(vm);
return -ENOMEM;
@@ -371,7 +371,7 @@ nouveau_vm_create(struct nouveau_vmmgr *vmm, u64 offset,
u64 length,
ret = nouveau_mm_init(vm-mm, mm_offset 12, mm_length 12,
block 12);
if (ret) {
- kfree(vm-pgt);
+ vfree(vm-pgt);
kfree(vm);
return ret;
}
@@ -446,7 +446,7 @@ nouveau_vm_del(struct nouveau_vm *vm)
}
nouveau_mm_fini(vm-mm);
- kfree(vm-pgt);
+ vfree(vm-pgt);
kfree(vm);
}
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote: > On 02/19/2013 12:23 AM, Marcin Slusarz wrote: > > On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote: > >> Hi, > >> > >> we have a report of WARNING from 3.7.6 in nouveau at > >> drivers/gpu/drm/nouveau/core/core/mm.c:242 here: > >> https://bugzilla.novell.com/show_bug.cgi?id=802347#c11 > >> > >> There is an order 4 allocation failure in nouveau_drm_open -> > >> nouveau_vm_create, i.e. this one failed: > >> vm->pgt = kcalloc(vm->lpde - vm->fpde + 1, sizeof(*vm->pgt), GFP_KERNEL); > >> > >> Then, on the error path in still in nouveau_drm_open, it is followed by > >> a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref -> > >> nouveau_mm_fini -> nouveau_vm_del -> nouveau_mm_fini which triggers the > >> warning. > >> > >> Any ideas? > > > > Crash/warning should be fixed by commit > > cfd376b6bfccf33782a0748a9c70f7f752f8b869 > > "drm/nouveau/vm: fix memory corruption when pgt allocation fails". > > Oh, thanks for the pointer. Could that bug cause real "memory > corruption"? As we're hunting one there... Yes. > Isn't this a stable-3.7 candidate? Should have been :/. > > Tomorrow I'll post a patch for page allocation failure. > > What do you mean -- what kind of patch? A patch which will change pgt allocation to use vmalloc. Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote: > Hi, > > we have a report of WARNING from 3.7.6 in nouveau at > drivers/gpu/drm/nouveau/core/core/mm.c:242 here: > https://bugzilla.novell.com/show_bug.cgi?id=802347#c11 > > There is an order 4 allocation failure in nouveau_drm_open -> > nouveau_vm_create, i.e. this one failed: > vm->pgt = kcalloc(vm->lpde - vm->fpde + 1, sizeof(*vm->pgt), GFP_KERNEL); > > Then, on the error path in still in nouveau_drm_open, it is followed by > a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref -> > nouveau_mm_fini -> nouveau_vm_del -> nouveau_mm_fini which triggers the > warning. > > Any ideas? Crash/warning should be fixed by commit cfd376b6bfccf33782a0748a9c70f7f752f8b869 "drm/nouveau/vm: fix memory corruption when pgt allocation fails". Tomorrow I'll post a patch for page allocation failure. Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote: Hi, we have a report of WARNING from 3.7.6 in nouveau at drivers/gpu/drm/nouveau/core/core/mm.c:242 here: https://bugzilla.novell.com/show_bug.cgi?id=802347#c11 There is an order 4 allocation failure in nouveau_drm_open - nouveau_vm_create, i.e. this one failed: vm-pgt = kcalloc(vm-lpde - vm-fpde + 1, sizeof(*vm-pgt), GFP_KERNEL); Then, on the error path in still in nouveau_drm_open, it is followed by a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref - nouveau_mm_fini - nouveau_vm_del - nouveau_mm_fini which triggers the warning. Any ideas? Crash/warning should be fixed by commit cfd376b6bfccf33782a0748a9c70f7f752f8b869 drm/nouveau/vm: fix memory corruption when pgt allocation fails. Tomorrow I'll post a patch for page allocation failure. Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote: On 02/19/2013 12:23 AM, Marcin Slusarz wrote: On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote: Hi, we have a report of WARNING from 3.7.6 in nouveau at drivers/gpu/drm/nouveau/core/core/mm.c:242 here: https://bugzilla.novell.com/show_bug.cgi?id=802347#c11 There is an order 4 allocation failure in nouveau_drm_open - nouveau_vm_create, i.e. this one failed: vm-pgt = kcalloc(vm-lpde - vm-fpde + 1, sizeof(*vm-pgt), GFP_KERNEL); Then, on the error path in still in nouveau_drm_open, it is followed by a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref - nouveau_mm_fini - nouveau_vm_del - nouveau_mm_fini which triggers the warning. Any ideas? Crash/warning should be fixed by commit cfd376b6bfccf33782a0748a9c70f7f752f8b869 drm/nouveau/vm: fix memory corruption when pgt allocation fails. Oh, thanks for the pointer. Could that bug cause real memory corruption? As we're hunting one there... Yes. Isn't this a stable-3.7 candidate? Should have been :/. Tomorrow I'll post a patch for page allocation failure. What do you mean -- what kind of patch? A patch which will change pgt allocation to use vmalloc. Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf: check if -DFORTIFY_SOURCE=2 is allowed
It seems gcc (4.7.2) defines _FORTIFY_SOURCE internally and becomes confused
when it sees another definition in flags.
For me, build failed like this:
CHK glibc
Makefile:548: *** No gnu/libc-version.h found, please install
glibc-dev[el]/glibc-static. Stop.
and only with V=1 it printed:
:0:0: error: "_FORTIFY_SOURCE" redefined [-Werror]
:1:0: note: this is the location of the previous definition
Signed-off-by: Marcin Slusarz
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
---
tools/perf/Makefile | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 8ab05e5..7925bb2 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -94,7 +94,7 @@ ifeq ("$(origin DEBUG)", "command line")
PERF_DEBUG = $(DEBUG)
endif
ifndef PERF_DEBUG
- CFLAGS_OPTIMIZE = -O6 -D_FORTIFY_SOURCE=2
+ CFLAGS_OPTIMIZE = -O6
endif
ifdef PARSER_DEBUG
@@ -167,6 +167,12 @@ ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror
-Wvolatile-register-var,-W
CFLAGS := $(CFLAGS) -Wvolatile-register-var
endif
+ifndef PERF_DEBUG
+ ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS)
-D_FORTIFY_SOURCE=2,-D_FORTIFY_SOURCE=2),y)
+ CFLAGS := $(CFLAGS) -D_FORTIFY_SOURCE=2
+ endif
+endif
+
### --- END CONFIGURATION SECTION ---
ifeq ($(srctree),)
--
1.8.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf: check if -DFORTIFY_SOURCE=2 is allowed
It seems gcc (4.7.2) defines _FORTIFY_SOURCE internally and becomes confused when it sees another definition in flags. For me, build failed like this: CHK glibc Makefile:548: *** No gnu/libc-version.h found, please install glibc-dev[el]/glibc-static. Stop. and only with V=1 it printed: command-line:0:0: error: _FORTIFY_SOURCE redefined [-Werror] stdin:1:0: note: this is the location of the previous definition Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Paul Mackerras pau...@samba.org Cc: Ingo Molnar mi...@redhat.com Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net --- tools/perf/Makefile | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tools/perf/Makefile b/tools/perf/Makefile index 8ab05e5..7925bb2 100644 --- a/tools/perf/Makefile +++ b/tools/perf/Makefile @@ -94,7 +94,7 @@ ifeq ($(origin DEBUG), command line) PERF_DEBUG = $(DEBUG) endif ifndef PERF_DEBUG - CFLAGS_OPTIMIZE = -O6 -D_FORTIFY_SOURCE=2 + CFLAGS_OPTIMIZE = -O6 endif ifdef PARSER_DEBUG @@ -167,6 +167,12 @@ ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -Wvolatile-register-var,-W CFLAGS := $(CFLAGS) -Wvolatile-register-var endif +ifndef PERF_DEBUG + ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -D_FORTIFY_SOURCE=2,-D_FORTIFY_SOURCE=2),y) + CFLAGS := $(CFLAGS) -D_FORTIFY_SOURCE=2 + endif +endif + ### --- END CONFIGURATION SECTION --- ifeq ($(srctree),) -- 1.8.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc7, nouveau, possible recursive locking, nouveau_instobj_create_ and nv50_disp_data_ctor
On Sat, Feb 16, 2013 at 12:57:07AM +0200, Denys Fedoryshchenko wrote: > Hi > > Booted on Toshiba laptop, x86_64, NVIDIA Corporation GT218 [GeForce > 310M], latest rc, and got this. > Please let me know if you need additional information. It's harmless and already quieted down in Linus' tree (post 3.8-rc7). (Commit 5f97ab913cf0fbc378ea8ffc3ee66f4890d11c55) Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc7, nouveau, possible recursive locking, nouveau_instobj_create_ and nv50_disp_data_ctor
On Sat, Feb 16, 2013 at 12:57:07AM +0200, Denys Fedoryshchenko wrote: Hi Booted on Toshiba laptop, x86_64, NVIDIA Corporation GT218 [GeForce 310M], latest rc, and got this. Please let me know if you need additional information. It's harmless and already quieted down in Linus' tree (post 3.8-rc7). (Commit 5f97ab913cf0fbc378ea8ffc3ee66f4890d11c55) Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 61/61] drm/nouveau: add lockdep annotations
On Wed, Feb 13, 2013 at 06:46:20PM +0100, Marcin Slusarz wrote: > On Wed, Feb 13, 2013 at 07:43:41PM +1000, Ben Skeggs wrote: > > On Wed, 2013-02-13 at 10:33 +0100, Arend van Spriel wrote: > > > On 02/13/2013 04:35 AM, Peter Hurley wrote: > > > > On Tue, 2013-02-12 at 12:35 -0800, Greg Kroah-Hartman wrote: > > > >> 3.7-stable review patch. If anyone has any objections, please let me > > > >> know. > > > > > > > > FWIW, I never saw this on 3.7 but it happened 1st time on 3.8-rcX > > > > I haven't tested this fix either. > > > > > > Dito. > > > > > > Gr. AvS > > Yeah, I don't believe anything could trigger it in 3.7. It doesn't hurt > > anyway. > > Client locking splat is definitely triggerable on 3.7: > https://lkml.org/lkml/2012/10/16/251 > > Subdev locking splat is triggerable since 3.7 has "drm/nouveau: add locking s/is/should be/ > around instobj list operations" and "drm/nvc0/fb: fix crash when different > mutex is used to protect same list" (both applied for 3.7.3). > > Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 61/61] drm/nouveau: add lockdep annotations
On Wed, Feb 13, 2013 at 07:43:41PM +1000, Ben Skeggs wrote: > On Wed, 2013-02-13 at 10:33 +0100, Arend van Spriel wrote: > > On 02/13/2013 04:35 AM, Peter Hurley wrote: > > > On Tue, 2013-02-12 at 12:35 -0800, Greg Kroah-Hartman wrote: > > >> 3.7-stable review patch. If anyone has any objections, please let me > > >> know. > > > > > > FWIW, I never saw this on 3.7 but it happened 1st time on 3.8-rcX > > > I haven't tested this fix either. > > > > Dito. > > > > Gr. AvS > Yeah, I don't believe anything could trigger it in 3.7. It doesn't hurt > anyway. Client locking splat is definitely triggerable on 3.7: https://lkml.org/lkml/2012/10/16/251 Subdev locking splat is triggerable since 3.7 has "drm/nouveau: add locking around instobj list operations" and "drm/nvc0/fb: fix crash when different mutex is used to protect same list" (both applied for 3.7.3). Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 61/61] drm/nouveau: add lockdep annotations
On Wed, Feb 13, 2013 at 07:43:41PM +1000, Ben Skeggs wrote: On Wed, 2013-02-13 at 10:33 +0100, Arend van Spriel wrote: On 02/13/2013 04:35 AM, Peter Hurley wrote: On Tue, 2013-02-12 at 12:35 -0800, Greg Kroah-Hartman wrote: 3.7-stable review patch. If anyone has any objections, please let me know. FWIW, I never saw this on 3.7 but it happened 1st time on 3.8-rcX I haven't tested this fix either. Dito. Gr. AvS Yeah, I don't believe anything could trigger it in 3.7. It doesn't hurt anyway. Client locking splat is definitely triggerable on 3.7: https://lkml.org/lkml/2012/10/16/251 Subdev locking splat is triggerable since 3.7 has drm/nouveau: add locking around instobj list operations and drm/nvc0/fb: fix crash when different mutex is used to protect same list (both applied for 3.7.3). Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 61/61] drm/nouveau: add lockdep annotations
On Wed, Feb 13, 2013 at 06:46:20PM +0100, Marcin Slusarz wrote: On Wed, Feb 13, 2013 at 07:43:41PM +1000, Ben Skeggs wrote: On Wed, 2013-02-13 at 10:33 +0100, Arend van Spriel wrote: On 02/13/2013 04:35 AM, Peter Hurley wrote: On Tue, 2013-02-12 at 12:35 -0800, Greg Kroah-Hartman wrote: 3.7-stable review patch. If anyone has any objections, please let me know. FWIW, I never saw this on 3.7 but it happened 1st time on 3.8-rcX I haven't tested this fix either. Dito. Gr. AvS Yeah, I don't believe anything could trigger it in 3.7. It doesn't hurt anyway. Client locking splat is definitely triggerable on 3.7: https://lkml.org/lkml/2012/10/16/251 Subdev locking splat is triggerable since 3.7 has drm/nouveau: add locking s/is/should be/ around instobj list operations and drm/nvc0/fb: fix crash when different mutex is used to protect same list (both applied for 3.7.3). Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm/nouveau: add lockdep annotations
1) Lockdep thinks all nouveau subdevs belong to the same class and can be
locked in arbitrary order, which is not true (at least in general case).
Tell it to distinguish subdevs by (o)class type.
2) DRM client can be locked under user client lock - tell lockdep to put DRM
client lock in a separate class.
Reported-by: Arend van Spriel
Reported-by: Peter Hurley
Reported-by: Maarten Lankhorst
Reported-by: Daniel J Blueman
Signed-off-by: Marcin Slusarz
Cc: sta...@vger.kernel.org [3.7, but needs s/const ofuncs/ofuncs/ to build]
---
Lightly tested, only on NV4B and NVC1.
---
drivers/gpu/drm/nouveau/core/core/subdev.c | 2 +-
drivers/gpu/drm/nouveau/core/include/core/object.h | 7 +--
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +++
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/subdev.c
b/drivers/gpu/drm/nouveau/core/core/subdev.c
index f74c30a..48f0637 100644
--- a/drivers/gpu/drm/nouveau/core/core/subdev.c
+++ b/drivers/gpu/drm/nouveau/core/core/subdev.c
@@ -99,7 +99,7 @@ nouveau_subdev_create_(struct nouveau_object *parent,
if (ret)
return ret;
- mutex_init(>mutex);
+ __mutex_init(>mutex, subname, >lock_class_key);
subdev->name = subname;
if (parent) {
diff --git a/drivers/gpu/drm/nouveau/core/include/core/object.h
b/drivers/gpu/drm/nouveau/core/include/core/object.h
index 6a90267..62e68ba 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/object.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/object.h
@@ -50,10 +50,13 @@ int nouveau_object_fini(struct nouveau_object *, bool
suspend);
extern struct nouveau_ofuncs nouveau_object_ofuncs;
+/* Don't allocate dynamically, because lockdep needs lock_class_keys to be in
+ * ".data". */
struct nouveau_oclass {
u32 handle;
- struct nouveau_ofuncs *ofuncs;
- struct nouveau_omthds *omthds;
+ struct nouveau_ofuncs * const ofuncs;
+ struct nouveau_omthds * const omthds;
+ struct lock_class_key lock_class_key;
};
#define nv_oclass(o)nv_object(o)->oclass
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index ef1ad21..bc00587 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -245,6 +245,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
return 0;
}
+static struct lock_class_key drm_client_lock_class_key;
+
static int
nouveau_drm_load(struct drm_device *dev, unsigned long flags)
{
@@ -256,6 +258,7 @@ nouveau_drm_load(struct drm_device *dev, unsigned long
flags)
ret = nouveau_cli_create(pdev, "DRM", sizeof(*drm), (void**));
if (ret)
return ret;
+ lockdep_set_class(>client.mutex, _client_lock_class_key);
dev->dev_private = drm;
drm->dev = dev;
--
1.8.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm/nouveau: add lockdep annotations
1) Lockdep thinks all nouveau subdevs belong to the same class and can be
locked in arbitrary order, which is not true (at least in general case).
Tell it to distinguish subdevs by (o)class type.
2) DRM client can be locked under user client lock - tell lockdep to put DRM
client lock in a separate class.
Reported-by: Arend van Spriel ar...@broadcom.com
Reported-by: Peter Hurley pe...@hurleysoftware.com
Reported-by: Maarten Lankhorst maarten.lankho...@canonical.com
Reported-by: Daniel J Blueman dan...@quora.org
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: sta...@vger.kernel.org [3.7, but needs s/const ofuncs/ofuncs/ to build]
---
Lightly tested, only on NV4B and NVC1.
---
drivers/gpu/drm/nouveau/core/core/subdev.c | 2 +-
drivers/gpu/drm/nouveau/core/include/core/object.h | 7 +--
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +++
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/subdev.c
b/drivers/gpu/drm/nouveau/core/core/subdev.c
index f74c30a..48f0637 100644
--- a/drivers/gpu/drm/nouveau/core/core/subdev.c
+++ b/drivers/gpu/drm/nouveau/core/core/subdev.c
@@ -99,7 +99,7 @@ nouveau_subdev_create_(struct nouveau_object *parent,
if (ret)
return ret;
- mutex_init(subdev-mutex);
+ __mutex_init(subdev-mutex, subname, oclass-lock_class_key);
subdev-name = subname;
if (parent) {
diff --git a/drivers/gpu/drm/nouveau/core/include/core/object.h
b/drivers/gpu/drm/nouveau/core/include/core/object.h
index 6a90267..62e68ba 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/object.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/object.h
@@ -50,10 +50,13 @@ int nouveau_object_fini(struct nouveau_object *, bool
suspend);
extern struct nouveau_ofuncs nouveau_object_ofuncs;
+/* Don't allocate dynamically, because lockdep needs lock_class_keys to be in
+ * .data. */
struct nouveau_oclass {
u32 handle;
- struct nouveau_ofuncs *ofuncs;
- struct nouveau_omthds *omthds;
+ struct nouveau_ofuncs * const ofuncs;
+ struct nouveau_omthds * const omthds;
+ struct lock_class_key lock_class_key;
};
#define nv_oclass(o)nv_object(o)-oclass
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index ef1ad21..bc00587 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -245,6 +245,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
return 0;
}
+static struct lock_class_key drm_client_lock_class_key;
+
static int
nouveau_drm_load(struct drm_device *dev, unsigned long flags)
{
@@ -256,6 +258,7 @@ nouveau_drm_load(struct drm_device *dev, unsigned long
flags)
ret = nouveau_cli_create(pdev, DRM, sizeof(*drm), (void**)drm);
if (ret)
return ret;
+ lockdep_set_class(drm-client.mutex, drm_client_lock_class_key);
dev-dev_private = drm;
drm-dev = dev;
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 59/74] drm/nv17-50: restore fence buffer on resume
On Thu, Jan 24, 2013 at 01:27:11AM -0200, Herton Ronaldo Krzesinski wrote:
> 3.5.7.4 -stable review patch. If anyone has any objections, please let me
> know.
>
> --
>
> From: Marcin Slusarz
>
> commit f20ebd034eab43fd38c58b11c5bb5fb125e5f7d7 upstream.
>
> Since commit 5e120f6e4b3f35b741c5445dfc755f50128c3c44 "drm/nouveau/fence:
> convert to exec engine, and improve channel sync" nouveau fence sync
> implementation for nv17-50 and nvc0+ started to rely on state of fence buffer
> left by previous sync operation. But as pinned bo's (where fence state is
> stored) are not saved+restored across suspend/resume, we need to do it
> manually.
>
> nvc0+ was fixed by commit d6ba6d215a538a58f0f0026f0961b0b9125e8042
> "drm/nvc0/fence: restore pre-suspend fence buffer context on resume".
>
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=50121
>
> Signed-off-by: Marcin Slusarz
> Signed-off-by: Ben Skeggs
> [ herton: backport for 3.5, looks like we only need to call
> nouveau_bo_wr32 on nv10_fence_init ]
> Signed-off-by: Herton Ronaldo Krzesinski
> ---
> drivers/gpu/drm/nouveau/nv10_fence.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nv10_fence.c
> b/drivers/gpu/drm/nouveau/nv10_fence.c
> index 8a1b750..18932a6 100644
> --- a/drivers/gpu/drm/nouveau/nv10_fence.c
> +++ b/drivers/gpu/drm/nouveau/nv10_fence.c
> @@ -155,6 +155,9 @@ nv10_fence_fini(struct drm_device *dev, int engine, bool
> suspend)
> static int
> nv10_fence_init(struct drm_device *dev, int engine)
> {
> + struct nv10_fence_priv *priv = nv_engine(dev, engine);
> +
> + nouveau_bo_wr32(priv->bo, 0, priv->sequence);
> return 0;
> }
>
> --
As I already mentioned in linked bug report, this backport will crash on module
load for nv10-nv17 cards. priv->bo is created only for chipsets >= nv17.
You need to add "if (priv->bo)" before nouveau_bo_wr32.
Marcin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 59/74] drm/nv17-50: restore fence buffer on resume
On Thu, Jan 24, 2013 at 01:27:11AM -0200, Herton Ronaldo Krzesinski wrote:
3.5.7.4 -stable review patch. If anyone has any objections, please let me
know.
--
From: Marcin Slusarz marcin.slus...@gmail.com
commit f20ebd034eab43fd38c58b11c5bb5fb125e5f7d7 upstream.
Since commit 5e120f6e4b3f35b741c5445dfc755f50128c3c44 drm/nouveau/fence:
convert to exec engine, and improve channel sync nouveau fence sync
implementation for nv17-50 and nvc0+ started to rely on state of fence buffer
left by previous sync operation. But as pinned bo's (where fence state is
stored) are not saved+restored across suspend/resume, we need to do it
manually.
nvc0+ was fixed by commit d6ba6d215a538a58f0f0026f0961b0b9125e8042
drm/nvc0/fence: restore pre-suspend fence buffer context on resume.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=50121
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Signed-off-by: Ben Skeggs bske...@redhat.com
[ herton: backport for 3.5, looks like we only need to call
nouveau_bo_wr32 on nv10_fence_init ]
Signed-off-by: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com
---
drivers/gpu/drm/nouveau/nv10_fence.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nv10_fence.c
b/drivers/gpu/drm/nouveau/nv10_fence.c
index 8a1b750..18932a6 100644
--- a/drivers/gpu/drm/nouveau/nv10_fence.c
+++ b/drivers/gpu/drm/nouveau/nv10_fence.c
@@ -155,6 +155,9 @@ nv10_fence_fini(struct drm_device *dev, int engine, bool
suspend)
static int
nv10_fence_init(struct drm_device *dev, int engine)
{
+ struct nv10_fence_priv *priv = nv_engine(dev, engine);
+
+ nouveau_bo_wr32(priv-bo, 0, priv-sequence);
return 0;
}
--
As I already mentioned in linked bug report, this backport will crash on module
load for nv10-nv17 cards. priv-bo is created only for chipsets = nv17.
You need to add if (priv-bo) before nouveau_bo_wr32.
Marcin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Announcement: STEC EnhanceIO SSD caching software for Linux kernel
On Sat, Jan 12, 2013 at 01:18:37AM +0800, Amit Kale wrote: > Greetings, > > STEC is happy to announce hosting of our EnhanceIO SSD caching software on > github. > We would like to invite kernel hackers to try it. We'll appreciate your > valuable feedback to help us improve it to the standards of Linux kernel > source code. We hope to eventually submit it for a possible inclusion in > Linux kernel. If you are serious about inclusion in Linux kernel sources, you may want to act on these comments: - kernel API wrappers should be removed - your ioctl won't work with 32-bit userspace on 64-bit kernel (differences in size and padding of struct cache_rec_short fields) - volatiles (probably) should go, see Documentation/volatile-considered-harmful.txt - printk wrappers can be easily replaced by pr_debug/pr_info/etc - the code should be more or less checkpatch.pl clean - this is buggy: VERIFY(spin_is_locked((sl))); - spin_is_locked always returns 0 on !CONFIG_SMP && !CONFIG_DEBUG_SPINLOCK > (...) > PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED > > This electronic transmission, and any documents attached hereto, may contain > confidential, proprietary and/or legally privileged information. The > information is intended only for use by the recipient named above. If you > received this electronic message in error, please notify the sender and delete > the electronic message. Any disclosure, copying, distribution, or use of the > contents of information received in error is strictly prohibited, and > violators will be pursued legally. FYI, most people are annoyed when they see those kind of threats on public mailing lists... Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announcement: STEC EnhanceIO SSD caching software for Linux kernel
On Sat, Jan 12, 2013 at 01:18:37AM +0800, Amit Kale wrote: Greetings, STEC is happy to announce hosting of our EnhanceIO SSD caching software on github. We would like to invite kernel hackers to try it. We'll appreciate your valuable feedback to help us improve it to the standards of Linux kernel source code. We hope to eventually submit it for a possible inclusion in Linux kernel. If you are serious about inclusion in Linux kernel sources, you may want to act on these comments: - kernel API wrappers should be removed - your ioctl won't work with 32-bit userspace on 64-bit kernel (differences in size and padding of struct cache_rec_short fields) - volatiles (probably) should go, see Documentation/volatile-considered-harmful.txt - printk wrappers can be easily replaced by pr_debug/pr_info/etc - the code should be more or less checkpatch.pl clean - this is buggy: VERIFY(spin_is_locked((sl))); - spin_is_locked always returns 0 on !CONFIG_SMP !CONFIG_DEBUG_SPINLOCK (...) PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED This electronic transmission, and any documents attached hereto, may contain confidential, proprietary and/or legally privileged information. The information is intended only for use by the recipient named above. If you received this electronic message in error, please notify the sender and delete the electronic message. Any disclosure, copying, distribution, or use of the contents of information received in error is strictly prohibited, and violators will be pursued legally. FYI, most people are annoyed when they see those kind of threats on public mailing lists... Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau E[ DRM] fail ttm_validate
On Fri, Jan 04, 2013 at 10:25:27PM +0100, Kees Bakker wrote: > On 04-01-13 18:49, Marcin Slusarz wrote: > > On Fri, Jan 04, 2013 at 01:21:14PM +0100, Kees Bakker wrote: > >> Hi, > >> > >> Right after I upgraded to Ubuntu quantal I started seeing these > >> messages: > >> Jan 4 12:18:12 koli kernel: [ 3705.970720] nouveau E[ DRM] fail > >> ttm_validate > >> Jan 4 12:18:12 koli kernel: [ 3705.970726] nouveau E[ DRM] validate > >> vram_list > >> Jan 4 12:18:12 koli kernel: [ 3705.970760] nouveau E[ DRM] validate: > >> -12 > > This is userspace bug. See below. > > > >> A few times I had corrupted graphics, and I had to stop X. Restarting > >> didn't > >> help and I had to reboot. > >> > >> I'm running my own 3.7.1 kernel, so I also installed the 3.7.0 development > >> kernel > >> from Ubuntu (3.7.0-7). And that kernel shows these messages too. > >> > >> With the Ubuntu kernel the graphics corruption is milder. I can continue > >> to work. Sometimes > >> I get a burst of the messages, but I have no clue how it is triggered. > >> > >> Now the strange thing is that I was running my 3.7.1 kernel on Ubuntu > >> precise > >> and I have never seen these messages before. What could be the case is that > >> xorg is doing something new and that is causing the errors. > >> > >> xserver-xorg-video-nouveau > >> precise 1:1.0.2-0ubuntu3 > >> quantal 1:0.0.16+git20111201+b5534a1-1build2 > > (Please do not use distro codenames when reporting bugs upstream) > > > > Quantal, being newer release than Precise, ships much older Nouveau DDX, > > WTF? > > You used some PPA with Precise? > Sorry about that. That was a typo. I meant to say: > quantal 1:1.0.2-0ubuntu3 > precise 1:0.0.16+git20111201+b5534a1-1build2 > > > > > 0.0.16 is known to behave like that - you need to upgrade to >= 1.0. > > In other words, I have >= 1.0. But you suggest that it shouldn't > happen with >= 1.0 > Should I report it on the nouveau list at freedesktop.org ? Ugh, it was unexpected :/ Please follow instructions from http://nouveau.freedesktop.org/wiki/Bugs and open new bug report. I have some patches which may help in narrowing it down, but I would like to see all bug report data first. Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau E[ DRM] fail ttm_validate
On Fri, Jan 04, 2013 at 10:25:27PM +0100, Kees Bakker wrote: On 04-01-13 18:49, Marcin Slusarz wrote: On Fri, Jan 04, 2013 at 01:21:14PM +0100, Kees Bakker wrote: Hi, Right after I upgraded to Ubuntu quantal I started seeing these messages: Jan 4 12:18:12 koli kernel: [ 3705.970720] nouveau E[ DRM] fail ttm_validate Jan 4 12:18:12 koli kernel: [ 3705.970726] nouveau E[ DRM] validate vram_list Jan 4 12:18:12 koli kernel: [ 3705.970760] nouveau E[ DRM] validate: -12 This is userspace bug. See below. A few times I had corrupted graphics, and I had to stop X. Restarting didn't help and I had to reboot. I'm running my own 3.7.1 kernel, so I also installed the 3.7.0 development kernel from Ubuntu (3.7.0-7). And that kernel shows these messages too. With the Ubuntu kernel the graphics corruption is milder. I can continue to work. Sometimes I get a burst of the messages, but I have no clue how it is triggered. Now the strange thing is that I was running my 3.7.1 kernel on Ubuntu precise and I have never seen these messages before. What could be the case is that xorg is doing something new and that is causing the errors. xserver-xorg-video-nouveau precise 1:1.0.2-0ubuntu3 quantal 1:0.0.16+git20111201+b5534a1-1build2 (Please do not use distro codenames when reporting bugs upstream) Quantal, being newer release than Precise, ships much older Nouveau DDX, WTF? You used some PPA with Precise? Sorry about that. That was a typo. I meant to say: quantal 1:1.0.2-0ubuntu3 precise 1:0.0.16+git20111201+b5534a1-1build2 0.0.16 is known to behave like that - you need to upgrade to = 1.0. In other words, I have = 1.0. But you suggest that it shouldn't happen with = 1.0 Should I report it on the nouveau list at freedesktop.org ? Ugh, it was unexpected :/ Please follow instructions from http://nouveau.freedesktop.org/wiki/Bugs and open new bug report. I have some patches which may help in narrowing it down, but I would like to see all bug report data first. Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau E[ DRM] fail ttm_validate
On Fri, Jan 04, 2013 at 01:21:14PM +0100, Kees Bakker wrote: > Hi, > > Right after I upgraded to Ubuntu quantal I started seeing these > messages: > Jan 4 12:18:12 koli kernel: [ 3705.970720] nouveau E[ DRM] fail > ttm_validate > Jan 4 12:18:12 koli kernel: [ 3705.970726] nouveau E[ DRM] validate > vram_list > Jan 4 12:18:12 koli kernel: [ 3705.970760] nouveau E[ DRM] validate: -12 This is userspace bug. See below. > A few times I had corrupted graphics, and I had to stop X. Restarting didn't > help and I had to reboot. > > I'm running my own 3.7.1 kernel, so I also installed the 3.7.0 development > kernel > from Ubuntu (3.7.0-7). And that kernel shows these messages too. > > With the Ubuntu kernel the graphics corruption is milder. I can continue to > work. Sometimes > I get a burst of the messages, but I have no clue how it is triggered. > > Now the strange thing is that I was running my 3.7.1 kernel on Ubuntu precise > and I have never seen these messages before. What could be the case is that > xorg is doing something new and that is causing the errors. > > xserver-xorg-video-nouveau >precise 1:1.0.2-0ubuntu3 >quantal 1:0.0.16+git20111201+b5534a1-1build2 (Please do not use distro codenames when reporting bugs upstream) Quantal, being newer release than Precise, ships much older Nouveau DDX, WTF? You used some PPA with Precise? 0.0.16 is known to behave like that - you need to upgrade to >= 1.0. > > Some more details > /var/log/syslog:Jan 4 11:16:42 koli kernel: [0.00] Linux version > 3.7.0-7-generic (root@koli) (gcc version 4.7.2 (Ubuntu/Lin > /var/log/syslog:Jan 4 11:16:44 koli kernel: [ 18.081288] [drm] Initialized > drm 1.1.0 20060810 > /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.615246] nouveau [ > DEVICE][:01:00.0] BOOT0 : 0x04b300b1 > /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.615251] nouveau [ > DEVICE][:01:00.0] Chipset: G73 (NV4B) > /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.615254] nouveau [ > DEVICE][:01:00.0] Family : NV40 > /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.616802] nouveau [ > VBIOS][:01:00.0] checking PRAMIN for image... > /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.655315] nouveau [ > VBIOS][:01:00.0] ... appears to be valid > /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.655320] nouveau [ > VBIOS][:01:00.0] using image from PRAMIN > /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.655505] nouveau [ > VBIOS][:01:00.0] BIT signature found > /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.655509] nouveau [ > VBIOS][:01:00.0] version 05.73.22.67 > /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.660805] nouveau [ > PFB][:01:00.0] RAM type: DDR2 > /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.660811] nouveau [ > PFB][:01:00.0] RAM size: 256 MiB -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau E[ DRM] fail ttm_validate
On Fri, Jan 04, 2013 at 01:21:14PM +0100, Kees Bakker wrote: Hi, Right after I upgraded to Ubuntu quantal I started seeing these messages: Jan 4 12:18:12 koli kernel: [ 3705.970720] nouveau E[ DRM] fail ttm_validate Jan 4 12:18:12 koli kernel: [ 3705.970726] nouveau E[ DRM] validate vram_list Jan 4 12:18:12 koli kernel: [ 3705.970760] nouveau E[ DRM] validate: -12 This is userspace bug. See below. A few times I had corrupted graphics, and I had to stop X. Restarting didn't help and I had to reboot. I'm running my own 3.7.1 kernel, so I also installed the 3.7.0 development kernel from Ubuntu (3.7.0-7). And that kernel shows these messages too. With the Ubuntu kernel the graphics corruption is milder. I can continue to work. Sometimes I get a burst of the messages, but I have no clue how it is triggered. Now the strange thing is that I was running my 3.7.1 kernel on Ubuntu precise and I have never seen these messages before. What could be the case is that xorg is doing something new and that is causing the errors. xserver-xorg-video-nouveau precise 1:1.0.2-0ubuntu3 quantal 1:0.0.16+git20111201+b5534a1-1build2 (Please do not use distro codenames when reporting bugs upstream) Quantal, being newer release than Precise, ships much older Nouveau DDX, WTF? You used some PPA with Precise? 0.0.16 is known to behave like that - you need to upgrade to = 1.0. Some more details /var/log/syslog:Jan 4 11:16:42 koli kernel: [0.00] Linux version 3.7.0-7-generic (root@koli) (gcc version 4.7.2 (Ubuntu/Lin /var/log/syslog:Jan 4 11:16:44 koli kernel: [ 18.081288] [drm] Initialized drm 1.1.0 20060810 /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.615246] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x04b300b1 /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.615251] nouveau [ DEVICE][:01:00.0] Chipset: G73 (NV4B) /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.615254] nouveau [ DEVICE][:01:00.0] Family : NV40 /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.616802] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.655315] nouveau [ VBIOS][:01:00.0] ... appears to be valid /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.655320] nouveau [ VBIOS][:01:00.0] using image from PRAMIN /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.655505] nouveau [ VBIOS][:01:00.0] BIT signature found /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.655509] nouveau [ VBIOS][:01:00.0] version 05.73.22.67 /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.660805] nouveau [ PFB][:01:00.0] RAM type: DDR2 /var/log/syslog:Jan 4 11:16:45 koli kernel: [ 18.660811] nouveau [ PFB][:01:00.0] RAM size: 256 MiB -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH] drm/nouveau: fix init with agpgart-uninorth
On Mon, Dec 31, 2012 at 03:34:59AM +0200, Aaro Koskinen wrote:
> Check that the AGP aperture can be mapped. This follows a similar change
> done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
> the aperture can be mapped by the CPU.).
>
> The patch fixes the following error seen on G5 iMac:
>
> nouveau E[ DRM] failed to create kernel channel, -12
>
> Reviewed-by: Michel Dänzer
> Signed-off-by: Aaro Koskinen
> ---
This patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=58806.
For some (weird) reason Nouveau worked on this configuration on 3.6 kernel,
so cc'ing stable@vger seems to be appropriate.
> drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 5614c89..69d7b1d 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1276,7 +1276,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
> struct ttm_mem_reg *mem)
> if (drm->agp.stat == ENABLED) {
> mem->bus.offset = mem->start << PAGE_SHIFT;
> mem->bus.base = drm->agp.base;
> - mem->bus.is_iomem = true;
> + mem->bus.is_iomem = !dev->agp->cant_use_aperture;
> }
> #endif
> break;
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH] drm/nouveau: fix init with agpgart-uninorth
On Mon, Dec 31, 2012 at 03:34:59AM +0200, Aaro Koskinen wrote:
Check that the AGP aperture can be mapped. This follows a similar change
done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
the aperture can be mapped by the CPU.).
The patch fixes the following error seen on G5 iMac:
nouveau E[ DRM] failed to create kernel channel, -12
Reviewed-by: Michel Dänzer mic...@daenzer.net
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
This patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=58806.
For some (weird) reason Nouveau worked on this configuration on 3.6 kernel,
so cc'ing stable@vger seems to be appropriate.
drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 5614c89..69d7b1d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1276,7 +1276,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_mem_reg *mem)
if (drm-agp.stat == ENABLED) {
mem-bus.offset = mem-start PAGE_SHIFT;
mem-bus.base = drm-agp.base;
- mem-bus.is_iomem = true;
+ mem-bus.is_iomem = !dev-agp-cant_use_aperture;
}
#endif
break;
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [3.7-rc5/rc6 regression] "drm/nvc0/disp: fix regression in vblank semaphore release" broke nouveau driver and mplayer
On Sat, Nov 17, 2012 at 08:35:18PM +0100, Mikael Pettersson wrote: > mplayer worked fine on my Dell Latitude E6510 (nVidia GT218 [NVS 3100M] > graphics) > up to and including kernel 3.7-rc4. However, with 3.7-rc5 or -rc6, any > attempt to > run mplayer just blanks the screen, shows some stray white pixels in the > upper left > corner, kills the X server, and spews the following errors from the kernel: Fix was already posted and should be merged soon. http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=7a259e65569bd7593ad541c84982027969ec9c45 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.7-rc5/rc6 regression] drm/nvc0/disp: fix regression in vblank semaphore release broke nouveau driver and mplayer
On Sat, Nov 17, 2012 at 08:35:18PM +0100, Mikael Pettersson wrote: mplayer worked fine on my Dell Latitude E6510 (nVidia GT218 [NVS 3100M] graphics) up to and including kernel 3.7-rc4. However, with 3.7-rc5 or -rc6, any attempt to run mplayer just blanks the screen, shows some stray white pixels in the upper left corner, kills the X server, and spews the following errors from the kernel: Fix was already posted and should be merged soon. http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=7a259e65569bd7593ad541c84982027969ec9c45 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nouveau: Fix crash after D3
On Tue, Nov 06, 2012 at 10:03:40PM +0800, Daniel J Blueman wrote:
> In 3.7-rc4, when starting X with the integrated GPU and suspending the
> discrete GPU,
> after one or more 32-bit applications are used (eg Skype) and X is stopped,
> we hit a panic.
>
> Prevent this by testing if the fini function is valid.
It's a bit weird. Can you explain better what is going on?
Why do we try to destroy this object (with NULL fini) only when GPU is
suspended? Maybe it means we are leaking this object on normal close/destroy?
Did you test what happens when you resume nv GPU after stopping X?
> Full panic bootlog is at: http://quora.org/2012/nouveau/dmesg-crash.txt
> Xorg.log is at: http://quora.org/2012/nouveau/Xorg.0.log-crash.txt
> Kernel log after fix is at: http://quora.org/2012/nouveau/dmesg-fix.txt
>
> Signed-off-by: Daniel J Blueman
> ---
> drivers/gpu/drm/nouveau/core/core/object.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/core/object.c
> b/drivers/gpu/drm/nouveau/core/core/object.c
> index 0daab62..3da3525 100644
> --- a/drivers/gpu/drm/nouveau/core/core/object.c
> +++ b/drivers/gpu/drm/nouveau/core/core/object.c
> @@ -354,12 +354,16 @@ static int
> nouveau_object_decf(struct nouveau_object *object)
> {
> int ret;
> + struct nouveau_ofuncs *pfuncs;
>
> nv_trace(object, "stopping...\n");
>
> - ret = nv_ofuncs(object)->fini(object, false);
> - if (ret)
> - nv_warn(object, "failed fini, %d\n", ret);
> + pfuncs = nv_ofuncs(object);
> + if (pfuncs->fini) {
> + ret = nv_ofuncs(object)->fini(object, false);
> + if (ret)
> + nv_warn(object, "failed fini, %d\n", ret);
> + }
>
> if (object->engine) {
> mutex_lock(_subdev(object->engine)->mutex);
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nouveau: Fix crash after D3
On Tue, Nov 06, 2012 at 10:03:40PM +0800, Daniel J Blueman wrote:
In 3.7-rc4, when starting X with the integrated GPU and suspending the
discrete GPU,
after one or more 32-bit applications are used (eg Skype) and X is stopped,
we hit a panic.
Prevent this by testing if the fini function is valid.
It's a bit weird. Can you explain better what is going on?
Why do we try to destroy this object (with NULL fini) only when GPU is
suspended? Maybe it means we are leaking this object on normal close/destroy?
Did you test what happens when you resume nv GPU after stopping X?
Full panic bootlog is at: http://quora.org/2012/nouveau/dmesg-crash.txt
Xorg.log is at: http://quora.org/2012/nouveau/Xorg.0.log-crash.txt
Kernel log after fix is at: http://quora.org/2012/nouveau/dmesg-fix.txt
Signed-off-by: Daniel J Blueman dan...@quora.org
---
drivers/gpu/drm/nouveau/core/core/object.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/object.c
b/drivers/gpu/drm/nouveau/core/core/object.c
index 0daab62..3da3525 100644
--- a/drivers/gpu/drm/nouveau/core/core/object.c
+++ b/drivers/gpu/drm/nouveau/core/core/object.c
@@ -354,12 +354,16 @@ static int
nouveau_object_decf(struct nouveau_object *object)
{
int ret;
+ struct nouveau_ofuncs *pfuncs;
nv_trace(object, stopping...\n);
- ret = nv_ofuncs(object)-fini(object, false);
- if (ret)
- nv_warn(object, failed fini, %d\n, ret);
+ pfuncs = nv_ofuncs(object);
+ if (pfuncs-fini) {
+ ret = nv_ofuncs(object)-fini(object, false);
+ if (ret)
+ nv_warn(object, failed fini, %d\n, ret);
+ }
if (object-engine) {
mutex_lock(nv_subdev(object-engine)-mutex);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote: > On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz > wrote: > > > > This looks like ACPI bug... > > I'm _shocked_ to hear that firmware would be fragile. > > Anyway, here's the #1 thing to keep in mind about firmware: > > - firmware is *always* buggy. I know. But this bug is not about broken firmware. It's about Linux kernel ACPI implementation, which (I think) wrongly interprets ACPI script. Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 08:58:07AM +0200, Paweł Sikora wrote:
> On Sunday 21 of October 2012 00:19:48 Marcin Slusarz wrote:
> > On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > > On 20.10.2012, Marcin Slusarz wrote:
> > >
> > > > Try this one.
> > >
> > > It works, now I can boot again. However, nouveau seems to be dead now.
> > > The dmesg output with your patch on top of 3.7-rc1 is:
> > >
> > > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> > > minor 0
> > > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> > > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> > > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
> > > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for
> > > image...
> > > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for
> > > image...
> > > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for
> > > image...
> > > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is
> > > beyond end of region [VROM] (length 24) (20120913/exfldio-210)
> > > [3.704139] ACPI Error: Method parse/execution
> > > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
> > > AE_AML_REGION_LIMIT (20120913/psparse-536)
> > > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> > > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for
> > > image...
> > > [3.724111] nouveau :01:00.0: Invalid ROM contents
> > > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable
> > > image
> > > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create
> > > 0x1001, -22
> > > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> > > [3.736097] nouveau: probe of :01:00.0 failed with error -22
> > > [3.740523] dracut: Starting plymouth daemon
> >
> > Hmm, maybe we can't fetch 3 bytes only...
> >
> > Let's check this:
> >
> > ---
> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > index 824eea0..8bd71aa 100644
> > --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > @@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
> > {
> > struct pci_dev *pdev = nv_device(bios)->pdev;
> > int ret, cnt, i;
> > - u8 data[3];
> > + u8 *data;
> >
> > if (!nouveau_acpi_rom_supported(pdev))
> > return;
> >
> > bios->size = 0;
> > - if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
> > + data = kmalloc(4096, GFP_KERNEL);
> > + if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
> > bios->size = data[2] * 512;
> > + kfree(data);
> > if (!bios->size)
> > return;
>
> with these both patches applied my laptop boots and gui works fine.
> here's dmesg:
>
> (...)
> [8.751795] nouveau [ VBIOS][:01:00.0] ... appears to be valid
> [8.751798] nouveau [ VBIOS][:01:00.0] using image from ACPI
> [8.751895] nouveau [ VBIOS][:01:00.0] BIT signature found
> [8.751898] nouveau [ VBIOS][:01:00.0] version 70.08.45.00
> [8.752366] nouveau [ DEVINIT][:01:00.0] adaptor not initialised
> [8.752368] nouveau [ VBIOS][:01:00.0] running init tables
> [8.867660] nouveau [ MXM][:01:00.0] no VBIOS data, nothing to do
> [8.867690] nouveau [ PFB][:01:00.0] RAM type: DDR3
> [8.867692] nouveau [ PFB][:01:00.0] RAM size: 512 MiB
> [8.901523] vga_switcheroo: enabled
> [8.901979] [TTM] Zone kernel: Available graphics memory: 6104282 kiB
> [8.901980] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
> [8.901982] [TTM] Initializing pool allocator
> [8.902014] [TTM] Initializing DMA pool allocator
> [8.902180] mtrr: type mismatch for c000,1000 old: write-back new:
> write-combining
> [8.902184] nouveau
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 08:58:07AM +0200, Paweł Sikora wrote:
On Sunday 21 of October 2012 00:19:48 Marcin Slusarz wrote:
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
On 20.10.2012, Marcin Slusarz wrote:
Try this one.
It works, now I can boot again. However, nouveau seems to be dead now.
The dmesg output with your patch on top of 3.7-rc1 is:
[3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
minor 0
[3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
[3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
[3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
[3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for
image...
[3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
[3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for
image...
[3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
[3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for
image...
[3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is
beyond end of region [VROM] (length 24) (20120913/exfldio-210)
[3.704139] ACPI Error: Method parse/execution
failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
AE_AML_REGION_LIMIT (20120913/psparse-536)
[3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
[3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
[3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for
image...
[3.724111] nouveau :01:00.0: Invalid ROM contents
[3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
[3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable
image
[3.731677] nouveau E[ DEVICE][:01:00.0] failed to create
0x1001, -22
[3.734231] nouveau E[ DRM] failed to create 0x8080, -22
[3.736097] nouveau: probe of :01:00.0 failed with error -22
[3.740523] dracut: Starting plymouth daemon
Hmm, maybe we can't fetch 3 bytes only...
Let's check this:
---
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index 824eea0..8bd71aa 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
{
struct pci_dev *pdev = nv_device(bios)-pdev;
int ret, cnt, i;
- u8 data[3];
+ u8 *data;
if (!nouveau_acpi_rom_supported(pdev))
return;
bios-size = 0;
- if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
+ data = kmalloc(4096, GFP_KERNEL);
+ if (data nouveau_acpi_get_bios_chunk(data, 0, 4096) = 3)
bios-size = data[2] * 512;
+ kfree(data);
if (!bios-size)
return;
with these both patches applied my laptop boots and gui works fine.
here's dmesg:
(...)
[8.751795] nouveau [ VBIOS][:01:00.0] ... appears to be valid
[8.751798] nouveau [ VBIOS][:01:00.0] using image from ACPI
[8.751895] nouveau [ VBIOS][:01:00.0] BIT signature found
[8.751898] nouveau [ VBIOS][:01:00.0] version 70.08.45.00
[8.752366] nouveau [ DEVINIT][:01:00.0] adaptor not initialised
[8.752368] nouveau [ VBIOS][:01:00.0] running init tables
[8.867660] nouveau [ MXM][:01:00.0] no VBIOS data, nothing to do
[8.867690] nouveau [ PFB][:01:00.0] RAM type: DDR3
[8.867692] nouveau [ PFB][:01:00.0] RAM size: 512 MiB
[8.901523] vga_switcheroo: enabled
[8.901979] [TTM] Zone kernel: Available graphics memory: 6104282 kiB
[8.901980] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[8.901982] [TTM] Initializing pool allocator
[8.902014] [TTM] Initializing DMA pool allocator
[8.902180] mtrr: type mismatch for c000,1000 old: write-back new:
write-combining
[8.902184] nouveau [ DRM] VRAM: 512 MiB
[8.902185] nouveau [ DRM] GART: 512 MiB
[8.902188] nouveau [ DRM] BIT BIOS found
[8.902190] nouveau [ DRM] Bios version 70.08.45.00
[8.902192] nouveau [ DRM] TMDS table version 2.0
[8.902194] nouveau [ DRM] DCB version 4.0
[8.902196] nouveau [ DRM] DCB outp 00: 02011300
[8.902198] nouveau [ DRM] DCB conn 01: 0100
[8.903540] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[8.903541] [drm] No driver support for vblank timestamp query.
[8.903545] nouveau [ DRM] ACPI backlight interface available, not
registering our own
[8.903938] nouveau [ DRM] 3 available performance level(s)
[8.903941] nouveau [ DRM] 0: core 50MHz shader 101MHz memory 135MHz
voltage 830mV
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote: On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz marcin.slus...@gmail.com wrote: This looks like ACPI bug... I'm _shocked_ to hear that firmware would be fragile. Anyway, here's the #1 thing to keep in mind about firmware: - firmware is *always* buggy. I know. But this bug is not about broken firmware. It's about Linux kernel ACPI implementation, which (I think) wrongly interprets ACPI script. Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Marcin Slusarz wrote:
>
> > Try this one.
>
> It works, now I can boot again. However, nouveau seems to be dead now.
> The dmesg output with your patch on top of 3.7-rc1 is:
>
> [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> minor 0
> [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
> [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image...
> [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image...
> [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image...
> [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond
> end of region [VROM] (length 24) (20120913/exfldio-210)
> [3.704139] ACPI Error: Method parse/execution
> failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
> AE_AML_REGION_LIMIT (20120913/psparse-536)
> [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for image...
> [3.724111] nouveau :01:00.0: Invalid ROM contents
> [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable image
> [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create 0x1001,
> -22
> [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> [3.736097] nouveau: probe of :01:00.0 failed with error -22
> [3.740523] dracut: Starting plymouth daemon
Hmm, maybe we can't fetch 3 bytes only...
Let's check this:
---
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index 824eea0..8bd71aa 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
{
struct pci_dev *pdev = nv_device(bios)->pdev;
int ret, cnt, i;
- u8 data[3];
+ u8 *data;
if (!nouveau_acpi_rom_supported(pdev))
return;
bios->size = 0;
- if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
+ data = kmalloc(4096, GFP_KERNEL);
+ if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
bios->size = data[2] * 512;
+ kfree(data);
if (!bios->size)
return;
---
Please attach acpidump output.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 11:42:17PM +0200, Marcin Slusarz wrote: > On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote: > > On 20.10.2012, Marcin Slusarz wrote: > > > > > Try this one. > > > > It works, now I can boot again. However, nouveau seems to be dead now. > > The dmesg output with your patch on top of 3.7-rc1 is: > > > > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on > > minor 0 > > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1 > > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8) > > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50 > > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for > > image... > > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found > > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image... > > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found > > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image... > > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond > > end of region [VROM] (length 24) (20120913/exfldio-210) > > [3.704139] ACPI Error: Method parse/execution > > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), > > AE_AML_REGION_LIMIT (20120913/psparse-536) > > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT > > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found > > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for > > image... > > [3.724111] nouveau :01:00.0: Invalid ROM contents > > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found > > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable > > image > > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create > > 0x1001, -22 > > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22 > > [3.736097] nouveau: probe of :01:00.0 failed with error -22 > > [3.740523] dracut: Starting plymouth daemon > > > > And here's the same output with plain vanilla 3.6.2: > > > > [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card > > (0x0a8800b1) > > [3.599783] vga_switcheroo: enabled > > [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS > > [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found > > [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS > > [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found > > [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS > > [3.856854] [drm] nouveau :01:00.0: ... appears to be valid > > [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI > > [3.861907] [drm] nouveau :01:00.0: BIT BIOS found > > [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00 > > [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0 > > [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do > > [3.870871] [drm] nouveau :01:00.0: DCB version 4.0 > > [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 > > [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040 > > [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146 > > [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261 > > [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330 > > [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400 > > [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560 > > [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running > > VBIOS init tables. > > [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at > > offset 0xDECD > > [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6 > > [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at > > offset 0xE378 > > [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at > > offset 0xEF4B > > [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at > > offset 0xEF64 > > [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at > > offset 0xF04B > > [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at > > offset 0xF0B0 > > [4.018084] [TTM] Zone kernel: Available graphics memory: 1917766 kiB > > [4.019438] [TTM] Initializing pool a
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote: > On 20.10.2012, Marcin Slusarz wrote: > > > Try this one. > > It works, now I can boot again. However, nouveau seems to be dead now. > The dmesg output with your patch on top of 3.7-rc1 is: > > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on > minor 0 > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1 > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8) > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50 > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image... > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image... > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond > end of region [VROM] (length 24) (20120913/exfldio-210) > [3.704139] ACPI Error: Method parse/execution > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), > AE_AML_REGION_LIMIT (20120913/psparse-536) > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for image... > [3.724111] nouveau :01:00.0: Invalid ROM contents > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable image > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create 0x1001, > -22 > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22 > [3.736097] nouveau: probe of :01:00.0 failed with error -22 > [3.740523] dracut: Starting plymouth daemon > > And here's the same output with plain vanilla 3.6.2: > > [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card > (0x0a8800b1) > [3.599783] vga_switcheroo: enabled > [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS > [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found > [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS > [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found > [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS > [3.856854] [drm] nouveau :01:00.0: ... appears to be valid > [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI > [3.861907] [drm] nouveau :01:00.0: BIT BIOS found > [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00 > [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0 > [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do > [3.870871] [drm] nouveau :01:00.0: DCB version 4.0 > [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 > [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040 > [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146 > [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261 > [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330 > [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400 > [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560 > [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running > VBIOS init tables. > [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at > offset 0xDECD > [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6 > [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at > offset 0xE378 > [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at > offset 0xEF4B > [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at > offset 0xEF64 > [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at > offset 0xF04B > [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset > 0xF0B0 > [4.018084] [TTM] Zone kernel: Available graphics memory: 1917766 kiB > [4.019438] [TTM] Initializing pool allocator > [4.020694] [TTM] Initializing DMA pool allocator > [4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3) > [4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture) > [4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > [4.084909] [drm] No driver support for vblank timestamp query. > [4.085985] [drm] nouveau :01:00.0: ACPI backlight interface > available, not registering o
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 10:28:46PM +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Martin Peres wrote:
> >
> > > Can you test the attached patch too ? I rebased the previous one I sent on
> > > top on 3.7-rc1 as I accidentally used an older version.
> >
> > Yes, of course.
> >
> > Tried it. Unfortunately, the crash remains the same as reported.
>
> Try this one.
>
> Now, the question is: could 3.6 kernel get VBIOS by ACPI?
> If yes, please mount debugfs and send vbios.rom to me please.
> (cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom)
>
> ---
> From: Marcin Slusarz
> Subject: [PATCH] drm/nouveau: validate vbios size
>
> Without checking, we could detect vbios size as 0, allocate 0-byte array
> (kmalloc returns invalid pointer for such allocation) and crash in
> nouveau_bios_score while checking for vbios signature.
>
> Reported-by: Heinz Diehl
And of course:
Reported-by: Paweł Sikora
> Signed-off-by: Marcin Slusarz
> ---
> drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> index dcb5c2b..824eea0 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> @@ -72,7 +72,7 @@ nouveau_bios_shadow_of(struct nouveau_bios *bios)
> }
>
> data = of_get_property(dn, "NVDA,BMP", );
> - if (data) {
> + if (data && size) {
> bios->size = size;
> bios->data = kmalloc(bios->size, GFP_KERNEL);
> if (bios->data)
> @@ -104,6 +104,9 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
> goto out;
>
> bios->size = nv_rd08(bios, 0x72) * 512;
> + if (!bios->size)
> + goto out;
> +
> bios->data = kmalloc(bios->size, GFP_KERNEL);
> if (bios->data) {
> for (i = 0; i < bios->size; i++)
> @@ -155,6 +158,9 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios)
>
> /* read entire bios image to system memory */
> bios->size = nv_rd08(bios, 0x32) * 512;
> + if (!bios->size)
> + goto out;
> +
> bios->data = kmalloc(bios->size, GFP_KERNEL);
> if (bios->data) {
> for (i = 0; i < bios->size; i++)
> @@ -194,6 +200,8 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
> bios->size = 0;
> if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
> bios->size = data[2] * 512;
> + if (!bios->size)
> + return;
>
> bios->data = kmalloc(bios->size, GFP_KERNEL);
> for (i = 0; bios->data && i < bios->size; i += cnt) {
> @@ -229,12 +237,14 @@ nouveau_bios_shadow_pci(struct nouveau_bios *bios)
> static int
> nouveau_bios_score(struct nouveau_bios *bios, const bool writeable)
> {
> - if (!bios->data || bios->data[0] != 0x55 || bios->data[1] != 0xAA) {
> + if (bios->size < 3 || !bios->data || bios->data[0] != 0x55 ||
> + bios->data[1] != 0xAA) {
> nv_info(bios, "... signature not found\n");
> return 0;
> }
>
> - if (nvbios_checksum(bios->data, bios->data[2] * 512)) {
> + if (nvbios_checksum(bios->data,
> + min_t(u32, bios->data[2] * 512, bios->size))) {
> nv_info(bios, "... checksum invalid\n");
> /* if a ro image is somewhat bad, it's probably all rubbish */
> return writeable ? 2 : 1;
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Martin Peres wrote:
>
> > Can you test the attached patch too ? I rebased the previous one I sent on
> > top on 3.7-rc1 as I accidentally used an older version.
>
> Yes, of course.
>
> Tried it. Unfortunately, the crash remains the same as reported.
Try this one.
Now, the question is: could 3.6 kernel get VBIOS by ACPI?
If yes, please mount debugfs and send vbios.rom to me please.
(cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom)
---
From: Marcin Slusarz
Subject: [PATCH] drm/nouveau: validate vbios size
Without checking, we could detect vbios size as 0, allocate 0-byte array
(kmalloc returns invalid pointer for such allocation) and crash in
nouveau_bios_score while checking for vbios signature.
Reported-by: Heinz Diehl
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index dcb5c2b..824eea0 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -72,7 +72,7 @@ nouveau_bios_shadow_of(struct nouveau_bios *bios)
}
data = of_get_property(dn, "NVDA,BMP", );
- if (data) {
+ if (data && size) {
bios->size = size;
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data)
@@ -104,6 +104,9 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
goto out;
bios->size = nv_rd08(bios, 0x72) * 512;
+ if (!bios->size)
+ goto out;
+
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data) {
for (i = 0; i < bios->size; i++)
@@ -155,6 +158,9 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios)
/* read entire bios image to system memory */
bios->size = nv_rd08(bios, 0x32) * 512;
+ if (!bios->size)
+ goto out;
+
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data) {
for (i = 0; i < bios->size; i++)
@@ -194,6 +200,8 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
bios->size = 0;
if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
bios->size = data[2] * 512;
+ if (!bios->size)
+ return;
bios->data = kmalloc(bios->size, GFP_KERNEL);
for (i = 0; bios->data && i < bios->size; i += cnt) {
@@ -229,12 +237,14 @@ nouveau_bios_shadow_pci(struct nouveau_bios *bios)
static int
nouveau_bios_score(struct nouveau_bios *bios, const bool writeable)
{
- if (!bios->data || bios->data[0] != 0x55 || bios->data[1] != 0xAA) {
+ if (bios->size < 3 || !bios->data || bios->data[0] != 0x55 ||
+ bios->data[1] != 0xAA) {
nv_info(bios, "... signature not found\n");
return 0;
}
- if (nvbios_checksum(bios->data, bios->data[2] * 512)) {
+ if (nvbios_checksum(bios->data,
+ min_t(u32, bios->data[2] * 512, bios->size))) {
nv_info(bios, "... checksum invalid\n");
/* if a ro image is somewhat bad, it's probably all rubbish */
return writeable ? 2 : 1;
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
On 20.10.2012, Martin Peres wrote:
Can you test the attached patch too ? I rebased the previous one I sent on
top on 3.7-rc1 as I accidentally used an older version.
Yes, of course.
Tried it. Unfortunately, the crash remains the same as reported.
Try this one.
Now, the question is: could 3.6 kernel get VBIOS by ACPI?
If yes, please mount debugfs and send vbios.rom to me please.
(cat /sys/kernel/debug/dri/0/vbios.rom vbios.rom)
---
From: Marcin Slusarz marcin.slus...@gmail.com
Subject: [PATCH] drm/nouveau: validate vbios size
Without checking, we could detect vbios size as 0, allocate 0-byte array
(kmalloc returns invalid pointer for such allocation) and crash in
nouveau_bios_score while checking for vbios signature.
Reported-by: Heinz Diehl h...@fritha.org
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index dcb5c2b..824eea0 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -72,7 +72,7 @@ nouveau_bios_shadow_of(struct nouveau_bios *bios)
}
data = of_get_property(dn, NVDA,BMP, size);
- if (data) {
+ if (data size) {
bios-size = size;
bios-data = kmalloc(bios-size, GFP_KERNEL);
if (bios-data)
@@ -104,6 +104,9 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
goto out;
bios-size = nv_rd08(bios, 0x72) * 512;
+ if (!bios-size)
+ goto out;
+
bios-data = kmalloc(bios-size, GFP_KERNEL);
if (bios-data) {
for (i = 0; i bios-size; i++)
@@ -155,6 +158,9 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios)
/* read entire bios image to system memory */
bios-size = nv_rd08(bios, 0x32) * 512;
+ if (!bios-size)
+ goto out;
+
bios-data = kmalloc(bios-size, GFP_KERNEL);
if (bios-data) {
for (i = 0; i bios-size; i++)
@@ -194,6 +200,8 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
bios-size = 0;
if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
bios-size = data[2] * 512;
+ if (!bios-size)
+ return;
bios-data = kmalloc(bios-size, GFP_KERNEL);
for (i = 0; bios-data i bios-size; i += cnt) {
@@ -229,12 +237,14 @@ nouveau_bios_shadow_pci(struct nouveau_bios *bios)
static int
nouveau_bios_score(struct nouveau_bios *bios, const bool writeable)
{
- if (!bios-data || bios-data[0] != 0x55 || bios-data[1] != 0xAA) {
+ if (bios-size 3 || !bios-data || bios-data[0] != 0x55 ||
+ bios-data[1] != 0xAA) {
nv_info(bios, ... signature not found\n);
return 0;
}
- if (nvbios_checksum(bios-data, bios-data[2] * 512)) {
+ if (nvbios_checksum(bios-data,
+ min_t(u32, bios-data[2] * 512, bios-size))) {
nv_info(bios, ... checksum invalid\n);
/* if a ro image is somewhat bad, it's probably all rubbish */
return writeable ? 2 : 1;
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 10:28:46PM +0200, Marcin Slusarz wrote:
On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
On 20.10.2012, Martin Peres wrote:
Can you test the attached patch too ? I rebased the previous one I sent on
top on 3.7-rc1 as I accidentally used an older version.
Yes, of course.
Tried it. Unfortunately, the crash remains the same as reported.
Try this one.
Now, the question is: could 3.6 kernel get VBIOS by ACPI?
If yes, please mount debugfs and send vbios.rom to me please.
(cat /sys/kernel/debug/dri/0/vbios.rom vbios.rom)
---
From: Marcin Slusarz marcin.slus...@gmail.com
Subject: [PATCH] drm/nouveau: validate vbios size
Without checking, we could detect vbios size as 0, allocate 0-byte array
(kmalloc returns invalid pointer for such allocation) and crash in
nouveau_bios_score while checking for vbios signature.
Reported-by: Heinz Diehl h...@fritha.org
And of course:
Reported-by: Paweł Sikora pawel.sik...@agmk.net
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index dcb5c2b..824eea0 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -72,7 +72,7 @@ nouveau_bios_shadow_of(struct nouveau_bios *bios)
}
data = of_get_property(dn, NVDA,BMP, size);
- if (data) {
+ if (data size) {
bios-size = size;
bios-data = kmalloc(bios-size, GFP_KERNEL);
if (bios-data)
@@ -104,6 +104,9 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
goto out;
bios-size = nv_rd08(bios, 0x72) * 512;
+ if (!bios-size)
+ goto out;
+
bios-data = kmalloc(bios-size, GFP_KERNEL);
if (bios-data) {
for (i = 0; i bios-size; i++)
@@ -155,6 +158,9 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios)
/* read entire bios image to system memory */
bios-size = nv_rd08(bios, 0x32) * 512;
+ if (!bios-size)
+ goto out;
+
bios-data = kmalloc(bios-size, GFP_KERNEL);
if (bios-data) {
for (i = 0; i bios-size; i++)
@@ -194,6 +200,8 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
bios-size = 0;
if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
bios-size = data[2] * 512;
+ if (!bios-size)
+ return;
bios-data = kmalloc(bios-size, GFP_KERNEL);
for (i = 0; bios-data i bios-size; i += cnt) {
@@ -229,12 +237,14 @@ nouveau_bios_shadow_pci(struct nouveau_bios *bios)
static int
nouveau_bios_score(struct nouveau_bios *bios, const bool writeable)
{
- if (!bios-data || bios-data[0] != 0x55 || bios-data[1] != 0xAA) {
+ if (bios-size 3 || !bios-data || bios-data[0] != 0x55 ||
+ bios-data[1] != 0xAA) {
nv_info(bios, ... signature not found\n);
return 0;
}
- if (nvbios_checksum(bios-data, bios-data[2] * 512)) {
+ if (nvbios_checksum(bios-data,
+ min_t(u32, bios-data[2] * 512, bios-size))) {
nv_info(bios, ... checksum invalid\n);
/* if a ro image is somewhat bad, it's probably all rubbish */
return writeable ? 2 : 1;
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote: On 20.10.2012, Marcin Slusarz wrote: Try this one. It works, now I can boot again. However, nouveau seems to be dead now. The dmesg output with your patch on top of 3.7-rc1 is: [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1 [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8) [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50 [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image... [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image... [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond end of region [VROM] (length 24) (20120913/exfldio-210) [3.704139] ACPI Error: Method parse/execution failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), AE_AML_REGION_LIMIT (20120913/psparse-536) [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for image... [3.724111] nouveau :01:00.0: Invalid ROM contents [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable image [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create 0x1001, -22 [3.734231] nouveau E[ DRM] failed to create 0x8080, -22 [3.736097] nouveau: probe of :01:00.0 failed with error -22 [3.740523] dracut: Starting plymouth daemon And here's the same output with plain vanilla 3.6.2: [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x0a8800b1) [3.599783] vga_switcheroo: enabled [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS [3.856854] [drm] nouveau :01:00.0: ... appears to be valid [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI [3.861907] [drm] nouveau :01:00.0: BIT BIOS found [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00 [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0 [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do [3.870871] [drm] nouveau :01:00.0: DCB version 4.0 [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040 [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146 [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261 [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330 [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400 [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560 [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running VBIOS init tables. [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDECD [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6 [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE378 [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEF4B [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xEF64 [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xF04B [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xF0B0 [4.018084] [TTM] Zone kernel: Available graphics memory: 1917766 kiB [4.019438] [TTM] Initializing pool allocator [4.020694] [TTM] Initializing DMA pool allocator [4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3) [4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [4.084909] [drm] No driver support for vblank timestamp query. [4.085985] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [4.246449] [drm] nouveau :01:00.0: 3 available performance level(s) [4.247560] [drm] nouveau :01:00.0: 0: core 135MHz shader 270MHz memory 135MHz voltage 850mV [4.248707] [drm] nouveau :01:00.0: 1: core 405MHz shader 810MHz memory 405MHz voltage 850mV [4.249807] [drm] nouveau :01:00.0: 3
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 11:42:17PM +0200, Marcin Slusarz wrote: On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote: On 20.10.2012, Marcin Slusarz wrote: Try this one. It works, now I can boot again. However, nouveau seems to be dead now. The dmesg output with your patch on top of 3.7-rc1 is: [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1 [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8) [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50 [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image... [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image... [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond end of region [VROM] (length 24) (20120913/exfldio-210) [3.704139] ACPI Error: Method parse/execution failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), AE_AML_REGION_LIMIT (20120913/psparse-536) [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for image... [3.724111] nouveau :01:00.0: Invalid ROM contents [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable image [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create 0x1001, -22 [3.734231] nouveau E[ DRM] failed to create 0x8080, -22 [3.736097] nouveau: probe of :01:00.0 failed with error -22 [3.740523] dracut: Starting plymouth daemon And here's the same output with plain vanilla 3.6.2: [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x0a8800b1) [3.599783] vga_switcheroo: enabled [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS [3.856854] [drm] nouveau :01:00.0: ... appears to be valid [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI [3.861907] [drm] nouveau :01:00.0: BIT BIOS found [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00 [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0 [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do [3.870871] [drm] nouveau :01:00.0: DCB version 4.0 [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040 [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146 [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261 [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330 [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400 [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560 [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running VBIOS init tables. [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDECD [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6 [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE378 [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEF4B [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xEF64 [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xF04B [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xF0B0 [4.018084] [TTM] Zone kernel: Available graphics memory: 1917766 kiB [4.019438] [TTM] Initializing pool allocator [4.020694] [TTM] Initializing DMA pool allocator [4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3) [4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [4.084909] [drm] No driver support for vblank timestamp query. [4.085985] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [4.246449] [drm] nouveau :01:00.0: 3 available performance level(s) [4.247560] [drm] nouveau :01:00.0: 0: core 135MHz shader 270MHz memory 135MHz
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
On 20.10.2012, Marcin Slusarz wrote:
Try this one.
It works, now I can boot again. However, nouveau seems to be dead now.
The dmesg output with your patch on top of 3.7-rc1 is:
[3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
minor 0
[3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
[3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
[3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
[3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image...
[3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
[3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image...
[3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
[3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image...
[3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond
end of region [VROM] (length 24) (20120913/exfldio-210)
[3.704139] ACPI Error: Method parse/execution
failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
AE_AML_REGION_LIMIT (20120913/psparse-536)
[3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
[3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
[3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for image...
[3.724111] nouveau :01:00.0: Invalid ROM contents
[3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
[3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable image
[3.731677] nouveau E[ DEVICE][:01:00.0] failed to create 0x1001,
-22
[3.734231] nouveau E[ DRM] failed to create 0x8080, -22
[3.736097] nouveau: probe of :01:00.0 failed with error -22
[3.740523] dracut: Starting plymouth daemon
Hmm, maybe we can't fetch 3 bytes only...
Let's check this:
---
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index 824eea0..8bd71aa 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
{
struct pci_dev *pdev = nv_device(bios)-pdev;
int ret, cnt, i;
- u8 data[3];
+ u8 *data;
if (!nouveau_acpi_rom_supported(pdev))
return;
bios-size = 0;
- if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
+ data = kmalloc(4096, GFP_KERNEL);
+ if (data nouveau_acpi_get_bios_chunk(data, 0, 4096) = 3)
bios-size = data[2] * 512;
+ kfree(data);
if (!bios-size)
return;
---
Please attach acpidump output.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: "netpoll: re-enable irq in poll_napi()" breaks boot with netconsole
On Wed, Aug 29, 2012 at 02:59:47PM -0400, David Miller wrote: > From: Marcin Slusarz > Date: Wed, 29 Aug 2012 20:53:29 +0200 > > > Kernel 3.6-rc3 does not boot for me with netconsole enabled, while 3.6-rc2 > > did. > > I bisected it to commit 6bdb7fe31046ac50b47e83c35cd6c6b6160a475d "netpoll: > > re-enable irq in poll_napi()" and reverting it on top of current Linus' tree > > restores proper behaviour (disabling netconsole does this too). > > "Not booting" manifests as immediate hang after network card enabling. > > Fix is already pending, thanks: > > http://patchwork.ozlabs.org/patch/179954/ It works for me. Thanks. Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
"netpoll: re-enable irq in poll_napi()" breaks boot with netconsole
Hi Kernel 3.6-rc3 does not boot for me with netconsole enabled, while 3.6-rc2 did. I bisected it to commit 6bdb7fe31046ac50b47e83c35cd6c6b6160a475d "netpoll: re-enable irq in poll_napi()" and reverting it on top of current Linus' tree restores proper behaviour (disabling netconsole does this too). "Not booting" manifests as immediate hang after network card enabling. Cheers, Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
netpoll: re-enable irq in poll_napi() breaks boot with netconsole
Hi Kernel 3.6-rc3 does not boot for me with netconsole enabled, while 3.6-rc2 did. I bisected it to commit 6bdb7fe31046ac50b47e83c35cd6c6b6160a475d netpoll: re-enable irq in poll_napi() and reverting it on top of current Linus' tree restores proper behaviour (disabling netconsole does this too). Not booting manifests as immediate hang after network card enabling. Cheers, Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: netpoll: re-enable irq in poll_napi() breaks boot with netconsole
On Wed, Aug 29, 2012 at 02:59:47PM -0400, David Miller wrote: From: Marcin Slusarz marcin.slus...@gmail.com Date: Wed, 29 Aug 2012 20:53:29 +0200 Kernel 3.6-rc3 does not boot for me with netconsole enabled, while 3.6-rc2 did. I bisected it to commit 6bdb7fe31046ac50b47e83c35cd6c6b6160a475d netpoll: re-enable irq in poll_napi() and reverting it on top of current Linus' tree restores proper behaviour (disabling netconsole does this too). Not booting manifests as immediate hang after network card enabling. Fix is already pending, thanks: http://patchwork.ozlabs.org/patch/179954/ It works for me. Thanks. Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
On Thu, Aug 02, 2012 at 01:26:55PM +0200, Ortwin Glück wrote:
> I have managed to turn the crash into a WARN_ON, by adding this to the
> begin of nouveau_software_vblank():
>
> if (!psw) {
> WARN_ON(1);
> return;
> }
Yes, I know about it, but this change fixes only a symptom. We should not get
into this code at all without enabling vblank.
> And I have also managed to load the module manually instead by udev. So
> I am happy to attach a full log of what's going on here. See also my
> added printk's starting with XXX that mark some interesting points in
> the initialization.
>
> This should give you enough information to track down the cause of the
> problem. To my non-expert eyes it looks like "noaccel" prevents
> registration of NVOBJ_ENGINE_SW or at least delays it too much.
Yes, that's what I wrote in my last patch - with noaccel it's not registered,
which leads to NULL pointer derefence.
I'm currently out of ideas why my patch does not work. But I have some ideas
how to debug it. Can you come to nouveau IRC channel at freenode and do some
additional tests? My nick is "joi" and I'm available on IRC between 6pm and
11pm CEST.
Marcin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
On Thu, Aug 02, 2012 at 01:26:55PM +0200, Ortwin Glück wrote:
I have managed to turn the crash into a WARN_ON, by adding this to the
begin of nouveau_software_vblank():
if (!psw) {
WARN_ON(1);
return;
}
Yes, I know about it, but this change fixes only a symptom. We should not get
into this code at all without enabling vblank.
And I have also managed to load the module manually instead by udev. So
I am happy to attach a full log of what's going on here. See also my
added printk's starting with XXX that mark some interesting points in
the initialization.
This should give you enough information to track down the cause of the
problem. To my non-expert eyes it looks like noaccel prevents
registration of NVOBJ_ENGINE_SW or at least delays it too much.
Yes, that's what I wrote in my last patch - with noaccel it's not registered,
which leads to NULL pointer derefence.
I'm currently out of ideas why my patch does not work. But I have some ideas
how to debug it. Can you come to nouveau IRC channel at freenode and do some
additional tests? My nick is joi and I'm available on IRC between 6pm and
11pm CEST.
Marcin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
On Mon, Jul 30, 2012 at 01:16:37PM +0200, Ortwin Glück wrote: > On 29.07.2012 22:15, Marcin Slusarz wrote: > > No, the real problem is: with "noaccel" we don't register "software engine", > > but vblank ISR relies on its existance and happily derefences NULL pointer. > > > > Now, this patch should fix it for real... > > Unfortunately I am still seeing the crash. Without "noaccel" it works though > (until X crashes the machine, but that is a different thing). Are you sure you boot the correct kernel? I'm asking because your panic says its version is "3.5.0 #3" - exactly the same as in previous crash log. Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
On Mon, Jul 30, 2012 at 01:16:37PM +0200, Ortwin Glück wrote: On 29.07.2012 22:15, Marcin Slusarz wrote: No, the real problem is: with noaccel we don't register software engine, but vblank ISR relies on its existance and happily derefences NULL pointer. Now, this patch should fix it for real... Unfortunately I am still seeing the crash. Without noaccel it works though (until X crashes the machine, but that is a different thing). Are you sure you boot the correct kernel? I'm asking because your panic says its version is 3.5.0 #3 - exactly the same as in previous crash log. Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote: > On 25.07.2012 20:42, Marcin Slusarz wrote: > > Good, below patch should fix this panic. > > > > Note that you can hit an oops in drm_handle_vblank because patch from > > http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html > > has not been applied (yet?). > > After applying your patch, it still crashes, although with a slightly > different stack trace. I then also applied the second patch, but that > doesn't make any difference. New log attached. > > Looks like interrupt occurs before nouveau_software_context_new() is > called? Shouldn't the initialization be done from > nouveau_irq_preinstall() so it is available when the irq occurs? Again, > I am not an expert here. Just guessing... No, the real problem is: with "noaccel" we don't register "software engine", but vblank ISR relies on its existance and happily derefences NULL pointer. Now, this patch should fix it for real... --- From: Marcin Slusarz Subject: [PATCH] drm/nouveau: disable vblank interrupts before registering PDISPLAY ISR Currently, we register vblank IRQ handler and later we disable vblank interrupts. So, for the short amount of time, we rely on vblank ISR to operate correctly, even if vblank interrupts are never going to be used later. In "noaccel" case, software engine - which is used by vblank ISR - is not registered, so if vblank interrupt triggers in a wrong moment, we can hit NULL pointer dereference in nouveau_software_vblank. To fix it, disable vblank interrupts before registering PDISPLAY ISR. Reported-by: Ortwin Glück Signed-off-by: Marcin Slusarz Cc: sta...@vger.kernel.org [3.5] --- drivers/gpu/drm/nouveau/nv04_crtc.c|1 + drivers/gpu/drm/nouveau/nv50_crtc.c|1 + drivers/gpu/drm/nouveau/nvd0_display.c |2 ++ 3 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv04_crtc.c b/drivers/gpu/drm/nouveau/nv04_crtc.c index 4c31c63..38bfe8d 100644 --- a/drivers/gpu/drm/nouveau/nv04_crtc.c +++ b/drivers/gpu/drm/nouveau/nv04_crtc.c @@ -1057,6 +1057,7 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num) } nv04_cursor_init(nv_crtc); + nouveau_vblank_disable(dev, crtc_num); return 0; } diff --git a/drivers/gpu/drm/nouveau/nv50_crtc.c b/drivers/gpu/drm/nouveau/nv50_crtc.c index 97a477b..7648f52 100644 --- a/drivers/gpu/drm/nouveau/nv50_crtc.c +++ b/drivers/gpu/drm/nouveau/nv50_crtc.c @@ -792,6 +792,7 @@ nv50_crtc_create(struct drm_device *dev, int index) goto out; nv50_cursor_init(nv_crtc); + nouveau_vblank_disable(dev, index); out: if (ret) nv50_crtc_destroy(_crtc->base); diff --git a/drivers/gpu/drm/nouveau/nvd0_display.c b/drivers/gpu/drm/nouveau/nvd0_display.c index c486d3c..32f8a86 100644 --- a/drivers/gpu/drm/nouveau/nvd0_display.c +++ b/drivers/gpu/drm/nouveau/nvd0_display.c @@ -908,6 +908,8 @@ nvd0_crtc_create(struct drm_device *dev, int index) goto out; nvd0_crtc_lut_load(crtc); + /* uncomment once nvd0 vblank lands */ + /* nouveau_vblank_disable(dev, index); */ out: if (ret) -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote: On 25.07.2012 20:42, Marcin Slusarz wrote: Good, below patch should fix this panic. Note that you can hit an oops in drm_handle_vblank because patch from http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html has not been applied (yet?). After applying your patch, it still crashes, although with a slightly different stack trace. I then also applied the second patch, but that doesn't make any difference. New log attached. Looks like interrupt occurs before nouveau_software_context_new() is called? Shouldn't the initialization be done from nouveau_irq_preinstall() so it is available when the irq occurs? Again, I am not an expert here. Just guessing... No, the real problem is: with noaccel we don't register software engine, but vblank ISR relies on its existance and happily derefences NULL pointer. Now, this patch should fix it for real... --- From: Marcin Slusarz marcin.slus...@gmail.com Subject: [PATCH] drm/nouveau: disable vblank interrupts before registering PDISPLAY ISR Currently, we register vblank IRQ handler and later we disable vblank interrupts. So, for the short amount of time, we rely on vblank ISR to operate correctly, even if vblank interrupts are never going to be used later. In noaccel case, software engine - which is used by vblank ISR - is not registered, so if vblank interrupt triggers in a wrong moment, we can hit NULL pointer dereference in nouveau_software_vblank. To fix it, disable vblank interrupts before registering PDISPLAY ISR. Reported-by: Ortwin Glück o...@odi.ch Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com Cc: sta...@vger.kernel.org [3.5] --- drivers/gpu/drm/nouveau/nv04_crtc.c|1 + drivers/gpu/drm/nouveau/nv50_crtc.c|1 + drivers/gpu/drm/nouveau/nvd0_display.c |2 ++ 3 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv04_crtc.c b/drivers/gpu/drm/nouveau/nv04_crtc.c index 4c31c63..38bfe8d 100644 --- a/drivers/gpu/drm/nouveau/nv04_crtc.c +++ b/drivers/gpu/drm/nouveau/nv04_crtc.c @@ -1057,6 +1057,7 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num) } nv04_cursor_init(nv_crtc); + nouveau_vblank_disable(dev, crtc_num); return 0; } diff --git a/drivers/gpu/drm/nouveau/nv50_crtc.c b/drivers/gpu/drm/nouveau/nv50_crtc.c index 97a477b..7648f52 100644 --- a/drivers/gpu/drm/nouveau/nv50_crtc.c +++ b/drivers/gpu/drm/nouveau/nv50_crtc.c @@ -792,6 +792,7 @@ nv50_crtc_create(struct drm_device *dev, int index) goto out; nv50_cursor_init(nv_crtc); + nouveau_vblank_disable(dev, index); out: if (ret) nv50_crtc_destroy(nv_crtc-base); diff --git a/drivers/gpu/drm/nouveau/nvd0_display.c b/drivers/gpu/drm/nouveau/nvd0_display.c index c486d3c..32f8a86 100644 --- a/drivers/gpu/drm/nouveau/nvd0_display.c +++ b/drivers/gpu/drm/nouveau/nvd0_display.c @@ -908,6 +908,8 @@ nvd0_crtc_create(struct drm_device *dev, int index) goto out; nvd0_crtc_lut_load(crtc); + /* uncomment once nvd0 vblank lands */ + /* nouveau_vblank_disable(dev, index); */ out: if (ret) -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote: > On 25.07.2012 20:42, Marcin Slusarz wrote: > > Good, below patch should fix this panic. > > > > Note that you can hit an oops in drm_handle_vblank because patch from > > http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html > > has not been applied (yet?). > > After applying your patch, it still crashes, although with a slightly > different stack trace. I then also applied the second patch, but that > doesn't make any difference. New log attached. > > Looks like interrupt occurs before nouveau_software_context_new() is > called? Shouldn't the initialization be done from > nouveau_irq_preinstall() so it is available when the irq occurs? Again, > I am not an expert here. Just guessing... I didn't look at it yet, but can you catch panic with maxcpus=1? Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote: On 25.07.2012 20:42, Marcin Slusarz wrote: Good, below patch should fix this panic. Note that you can hit an oops in drm_handle_vblank because patch from http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html has not been applied (yet?). After applying your patch, it still crashes, although with a slightly different stack trace. I then also applied the second patch, but that doesn't make any difference. New log attached. Looks like interrupt occurs before nouveau_software_context_new() is called? Shouldn't the initialization be done from nouveau_irq_preinstall() so it is available when the irq occurs? Again, I am not an expert here. Just guessing... I didn't look at it yet, but can you catch panic with maxcpus=1? Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
On Wed, Jul 25, 2012 at 10:46:49AM +0200, Ortwin Glück wrote:
> > Does it work if you boot without X and modprobe nouveau manually? If it
> > does,
> > can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau
> > device section) and recheck with X?
>
> It happens long before X, when the nouveau module is loaded.
>
> > Does it work if you disable acceleration (nouveau.noaccel=1 in kernel
> > command
> > line)?
>
> nouveau.noaccel=1 is already on my cmdline as running X with accel
> enabled never worked anyway.
>
> > Is there anything saved in /var/log/ from previous boot? Can you ssh
> > into and check dmesg? Can you use netconsole and catch full log?
>
> Thanks for the netconsole tip. I have attached the log.
>
Good, below patch should fix this panic.
Note that you can hit an oops in drm_handle_vblank because patch from
http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html
has not been applied (yet?).
--
From: Marcin Slusarz
Date: Wed, 25 Jul 2012 20:07:22 +0200
Subject: [PATCH] drm/nouveau: init vblank requests list
Fixes kernel panic when vblank interrupt triggers before first sync to vblank
request.
(Besides init, remove some relevant leftovers from vblank rework)
Reported-by: Ortwin Glück
Signed-off-by: Marcin Slusarz
Cc: sta...@vger.kernel.org [3.5]
---
drivers/gpu/drm/nouveau/nouveau_drv.h |2 --
drivers/gpu/drm/nouveau/nouveau_irq.c |4
drivers/gpu/drm/nouveau/nouveau_software.h |1 +
3 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 8613cb2..b863a3a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -689,8 +689,6 @@ struct drm_nouveau_private {
void (*irq_handler[32])(struct drm_device *);
bool msi_enabled;
- struct list_head vbl_waiting;
-
struct {
struct drm_global_reference mem_global_ref;
struct ttm_bo_global_ref bo_global_ref;
diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c
b/drivers/gpu/drm/nouveau/nouveau_irq.c
index 868c7fd..b2c2937 100644
--- a/drivers/gpu/drm/nouveau/nouveau_irq.c
+++ b/drivers/gpu/drm/nouveau/nouveau_irq.c
@@ -41,12 +41,8 @@
void
nouveau_irq_preinstall(struct drm_device *dev)
{
- struct drm_nouveau_private *dev_priv = dev->dev_private;
-
/* Master disable */
nv_wr32(dev, NV03_PMC_INTR_EN_0, 0);
-
- INIT_LIST_HEAD(_priv->vbl_waiting);
}
int
diff --git a/drivers/gpu/drm/nouveau/nouveau_software.h
b/drivers/gpu/drm/nouveau/nouveau_software.h
index e60bc6c..b507a92 100644
--- a/drivers/gpu/drm/nouveau/nouveau_software.h
+++ b/drivers/gpu/drm/nouveau/nouveau_software.h
@@ -38,6 +38,7 @@ static inline void
nouveau_software_context_new(struct nouveau_software_chan *pch)
{
INIT_LIST_HEAD(>flip);
+ INIT_LIST_HEAD(>vblank.list);
}
static inline void
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
On Wed, Jul 25, 2012 at 10:46:49AM +0200, Ortwin Glück wrote:
Does it work if you boot without X and modprobe nouveau manually? If it
does,
can you disable page flipping in xorg.conf (Option PageFlip 0 in nouveau
device section) and recheck with X?
It happens long before X, when the nouveau module is loaded.
Does it work if you disable acceleration (nouveau.noaccel=1 in kernel
command
line)?
nouveau.noaccel=1 is already on my cmdline as running X with accel
enabled never worked anyway.
Is there anything saved in /var/log/ from previous boot? Can you ssh
into and check dmesg? Can you use netconsole and catch full log?
Thanks for the netconsole tip. I have attached the log.
Good, below patch should fix this panic.
Note that you can hit an oops in drm_handle_vblank because patch from
http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html
has not been applied (yet?).
--
From: Marcin Slusarz marcin.slus...@gmail.com
Date: Wed, 25 Jul 2012 20:07:22 +0200
Subject: [PATCH] drm/nouveau: init vblank requests list
Fixes kernel panic when vblank interrupt triggers before first sync to vblank
request.
(Besides init, remove some relevant leftovers from vblank rework)
Reported-by: Ortwin Glück o...@odi.ch
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: sta...@vger.kernel.org [3.5]
---
drivers/gpu/drm/nouveau/nouveau_drv.h |2 --
drivers/gpu/drm/nouveau/nouveau_irq.c |4
drivers/gpu/drm/nouveau/nouveau_software.h |1 +
3 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 8613cb2..b863a3a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -689,8 +689,6 @@ struct drm_nouveau_private {
void (*irq_handler[32])(struct drm_device *);
bool msi_enabled;
- struct list_head vbl_waiting;
-
struct {
struct drm_global_reference mem_global_ref;
struct ttm_bo_global_ref bo_global_ref;
diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c
b/drivers/gpu/drm/nouveau/nouveau_irq.c
index 868c7fd..b2c2937 100644
--- a/drivers/gpu/drm/nouveau/nouveau_irq.c
+++ b/drivers/gpu/drm/nouveau/nouveau_irq.c
@@ -41,12 +41,8 @@
void
nouveau_irq_preinstall(struct drm_device *dev)
{
- struct drm_nouveau_private *dev_priv = dev-dev_private;
-
/* Master disable */
nv_wr32(dev, NV03_PMC_INTR_EN_0, 0);
-
- INIT_LIST_HEAD(dev_priv-vbl_waiting);
}
int
diff --git a/drivers/gpu/drm/nouveau/nouveau_software.h
b/drivers/gpu/drm/nouveau/nouveau_software.h
index e60bc6c..b507a92 100644
--- a/drivers/gpu/drm/nouveau/nouveau_software.h
+++ b/drivers/gpu/drm/nouveau/nouveau_software.h
@@ -38,6 +38,7 @@ static inline void
nouveau_software_context_new(struct nouveau_software_chan *pch)
{
INIT_LIST_HEAD(pch-flip);
+ INIT_LIST_HEAD(pch-vblank.list);
}
static inline void
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
On Tue, Jul 24, 2012 at 07:22:52PM +0200, Ortwin Glück wrote: > On 24.07.2012 19:00, Marcin Slusarz wrote: > > Please post the crash log. > > Sorry, I was not precise: it boots until drm performs modesetting (so it > seems). The screen goes black and the machine is dead. So there is > nothing I could post here, unfortunately. > > This is a video of 3.5 booting: > http://www.odi.ch/VIDEO0010.3gp Does it work if you boot without X and modprobe nouveau manually? If it does, can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau device section) and recheck with X? Does it work if you disable acceleration (nouveau.noaccel=1 in kernel command line)? Is there anything saved in /var/log/ from previous boot? Can you ssh into and check dmesg? Can you use netconsole and catch full log? Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
On Mon, Jul 23, 2012 at 08:01:14PM +0200, Ortwin Glück wrote: > Hi, > > My HP Elitebook 8540w now crashes on boot with 3.5. All works fine with > 3.4. Bisected to the following commit: > > 20abd1634a6e2eedb84ca977adea56b8aa06cc3e is the first bad commit > commit 20abd1634a6e2eedb84ca977adea56b8aa06cc3e > Author: Ben Skeggs > Date: Mon Apr 30 11:33:43 2012 -0500 > > drm/nouveau: create real execution engine for software object class > > Just a cleanup more or less, and to remove the need for special > handling of > software objects. > > This removes a heap of documentation on dma/graph object formats. > The info > is very out of date with our current understanding, and is far better > documented in rnndb in envytools git. > > Signed-off-by: Ben Skeggs > > lspci: > 01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [Quadro FX > 1800M] (rev a2) > Please post the crash log. Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
On Mon, Jul 23, 2012 at 08:01:14PM +0200, Ortwin Glück wrote: Hi, My HP Elitebook 8540w now crashes on boot with 3.5. All works fine with 3.4. Bisected to the following commit: 20abd1634a6e2eedb84ca977adea56b8aa06cc3e is the first bad commit commit 20abd1634a6e2eedb84ca977adea56b8aa06cc3e Author: Ben Skeggs bske...@redhat.com Date: Mon Apr 30 11:33:43 2012 -0500 drm/nouveau: create real execution engine for software object class Just a cleanup more or less, and to remove the need for special handling of software objects. This removes a heap of documentation on dma/graph object formats. The info is very out of date with our current understanding, and is far better documented in rnndb in envytools git. Signed-off-by: Ben Skeggs bske...@redhat.com lspci: 01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [Quadro FX 1800M] (rev a2) Please post the crash log. Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
On Tue, Jul 24, 2012 at 07:22:52PM +0200, Ortwin Glück wrote: On 24.07.2012 19:00, Marcin Slusarz wrote: Please post the crash log. Sorry, I was not precise: it boots until drm performs modesetting (so it seems). The screen goes black and the machine is dead. So there is nothing I could post here, unfortunately. This is a video of 3.5 booting: http://www.odi.ch/VIDEO0010.3gp Does it work if you boot without X and modprobe nouveau manually? If it does, can you disable page flipping in xorg.conf (Option PageFlip 0 in nouveau device section) and recheck with X? Does it work if you disable acceleration (nouveau.noaccel=1 in kernel command line)? Is there anything saved in /var/log/ from previous boot? Can you ssh into and check dmesg? Can you use netconsole and catch full log? Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] video: limit stack usage of ir-kbd-i2c.c
ir_probe allocated struct i2c_client on stack;
it's pretty big structure, so allocate it with kzalloc
make checkstack output without this patch:
x059d ir_probe [ir-kbd-i2c]: 1000
compile tested only
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Cc: Jean Delvare <[EMAIL PROTECTED]>
---
drivers/media/video/ir-kbd-i2c.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/ir-kbd-i2c.c b/drivers/media/video/ir-kbd-i2c.c
index 9851987..aec122f 100644
--- a/drivers/media/video/ir-kbd-i2c.c
+++ b/drivers/media/video/ir-kbd-i2c.c
@@ -510,9 +510,9 @@ static int ir_probe(struct i2c_adapter *adap)
static const int probe_cx88[] = { 0x18, 0x6b, 0x71, -1 };
static const int probe_cx23885[] = { 0x6b, -1 };
const int *probe = NULL;
- struct i2c_client c;
+ struct i2c_client *c;
unsigned char buf;
- int i,rc;
+ int i, rc;
switch (adap->id) {
case I2C_HW_B_BT848:
@@ -537,19 +537,23 @@ static int ir_probe(struct i2c_adapter *adap)
if (NULL == probe)
return 0;
- memset(,0,sizeof(c));
- c.adapter = adap;
+ c = kzalloc(sizeof(*c), GFP_KERNEL);
+ if (!c)
+ return -ENOMEM;
+
+ c->adapter = adap;
for (i = 0; -1 != probe[i]; i++) {
- c.addr = probe[i];
- rc = i2c_master_recv(,,0);
+ c->addr = probe[i];
+ rc = i2c_master_recv(c, , 0);
dprintk(1,"probe 0x%02x @ %s: %s\n",
probe[i], adap->name,
(0 == rc) ? "yes" : "no");
if (0 == rc) {
- ir_attach(adap,probe[i],0,0);
+ ir_attach(adap, probe[i], 0, 0);
break;
}
}
+ kfree(c);
return 0;
}
--
1.5.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] video: limit stack usage of ir-kbd-i2c.c
ir_probe allocated struct i2c_client on stack;
it's pretty big structure, so allocate it with kzalloc
make checkstack output without this patch:
x059d ir_probe [ir-kbd-i2c]: 1000
compile tested only
Signed-off-by: Marcin Slusarz [EMAIL PROTECTED]
Cc: Mauro Carvalho Chehab [EMAIL PROTECTED]
Cc: Jean Delvare [EMAIL PROTECTED]
---
drivers/media/video/ir-kbd-i2c.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/ir-kbd-i2c.c b/drivers/media/video/ir-kbd-i2c.c
index 9851987..aec122f 100644
--- a/drivers/media/video/ir-kbd-i2c.c
+++ b/drivers/media/video/ir-kbd-i2c.c
@@ -510,9 +510,9 @@ static int ir_probe(struct i2c_adapter *adap)
static const int probe_cx88[] = { 0x18, 0x6b, 0x71, -1 };
static const int probe_cx23885[] = { 0x6b, -1 };
const int *probe = NULL;
- struct i2c_client c;
+ struct i2c_client *c;
unsigned char buf;
- int i,rc;
+ int i, rc;
switch (adap-id) {
case I2C_HW_B_BT848:
@@ -537,19 +537,23 @@ static int ir_probe(struct i2c_adapter *adap)
if (NULL == probe)
return 0;
- memset(c,0,sizeof(c));
- c.adapter = adap;
+ c = kzalloc(sizeof(*c), GFP_KERNEL);
+ if (!c)
+ return -ENOMEM;
+
+ c-adapter = adap;
for (i = 0; -1 != probe[i]; i++) {
- c.addr = probe[i];
- rc = i2c_master_recv(c,buf,0);
+ c-addr = probe[i];
+ rc = i2c_master_recv(c, buf, 0);
dprintk(1,probe 0x%02x @ %s: %s\n,
probe[i], adap-name,
(0 == rc) ? yes : no);
if (0 == rc) {
- ir_attach(adap,probe[i],0,0);
+ ir_attach(adap, probe[i], 0, 0);
break;
}
}
+ kfree(c);
return 0;
}
--
1.5.3.7
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ufs: [bl]e*_add_cpu conversion
On Tue, Feb 19, 2008 at 12:22:19AM +0100, Roel Kluin wrote:
> Andrew Morton wrote:
> > On Wed, 13 Feb 2008 10:41:44 +0100 Roel Kluin <[EMAIL PROTECTED]> wrote:
> >
> >> you may also want these:
> >> ---
> >> [bl]e_add_cpu conversion in return
>
> > upsets powerpc (at least):
> >
> > fs/ufs/swab.h: In function `fs64_add':
> > fs/ufs/swab.h:47: warning: passing arg 1 of `le64_add_cpu' from
> > incompatible pointer type
> > fs/ufs/swab.h:49: warning: passing arg 1 of `be64_add_cpu' from
> > incompatible pointer type
> > fs/ufs/swab.h: In function `fs64_sub':
> > fs/ufs/swab.h:58: warning: passing arg 1 of `le64_add_cpu' from
> > incompatible pointer type
> > fs/ufs/swab.h:60: warning: passing arg 1 of `be64_add_cpu' from
> > incompatible pointer type
>
> sorry for this. Is it correct to cast like the patch below does?
I don't think so. Their prototypes are wrong. We can:
a) remove fs64_add and fs64_sub as nobody use them
b) fix them - change second parameter do __fs64 (and convert to [bl]e64_add_cpu)
Evgeniy?
> If not (anyone) feel free to correct and send a patch yourself.
> The patch below was *not* tested
> ---
> [bl]e_add_cpu conversion in return (with cast)
>
> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
> ---
> diff --git a/fs/ufs/swab.h b/fs/ufs/swab.h
> index 1683d2b..594d6e8 100644
> --- a/fs/ufs/swab.h
> +++ b/fs/ufs/swab.h
> @@ -44,18 +44,22 @@ static __inline u32
> fs64_add(struct super_block *sbp, u32 *n, int d)
> {
> if (UFS_SB(sbp)->s_bytesex == BYTESEX_LE)
> - return *n = cpu_to_le64(le64_to_cpu(*n)+d);
> + le64_add_cpu((__le64 *)n, d);
> else
> - return *n = cpu_to_be64(be64_to_cpu(*n)+d);
> + be64_add_cpu((__le64 *)n, d);
> +
> + return *n;
> }
>
> static __inline u32
> fs64_sub(struct super_block *sbp, u32 *n, int d)
> {
> if (UFS_SB(sbp)->s_bytesex == BYTESEX_LE)
> - return *n = cpu_to_le64(le64_to_cpu(*n)-d);
> + le64_add_cpu((__le64 *)n, -d);
> else
> - return *n = cpu_to_be64(be64_to_cpu(*n)-d);
> + be64_add_cpu((__le64 *)n, -d);
> +
> + return *n;
> }
>
> static __inline u32
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ufs: [bl]e*_add_cpu conversion
On Tue, Feb 19, 2008 at 12:22:19AM +0100, Roel Kluin wrote:
Andrew Morton wrote:
On Wed, 13 Feb 2008 10:41:44 +0100 Roel Kluin [EMAIL PROTECTED] wrote:
you may also want these:
---
[bl]e_add_cpu conversion in return
upsets powerpc (at least):
fs/ufs/swab.h: In function `fs64_add':
fs/ufs/swab.h:47: warning: passing arg 1 of `le64_add_cpu' from
incompatible pointer type
fs/ufs/swab.h:49: warning: passing arg 1 of `be64_add_cpu' from
incompatible pointer type
fs/ufs/swab.h: In function `fs64_sub':
fs/ufs/swab.h:58: warning: passing arg 1 of `le64_add_cpu' from
incompatible pointer type
fs/ufs/swab.h:60: warning: passing arg 1 of `be64_add_cpu' from
incompatible pointer type
sorry for this. Is it correct to cast like the patch below does?
I don't think so. Their prototypes are wrong. We can:
a) remove fs64_add and fs64_sub as nobody use them
b) fix them - change second parameter do __fs64 (and convert to [bl]e64_add_cpu)
Evgeniy?
If not (anyone) feel free to correct and send a patch yourself.
The patch below was *not* tested
---
[bl]e_add_cpu conversion in return (with cast)
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
---
diff --git a/fs/ufs/swab.h b/fs/ufs/swab.h
index 1683d2b..594d6e8 100644
--- a/fs/ufs/swab.h
+++ b/fs/ufs/swab.h
@@ -44,18 +44,22 @@ static __inline u32
fs64_add(struct super_block *sbp, u32 *n, int d)
{
if (UFS_SB(sbp)-s_bytesex == BYTESEX_LE)
- return *n = cpu_to_le64(le64_to_cpu(*n)+d);
+ le64_add_cpu((__le64 *)n, d);
else
- return *n = cpu_to_be64(be64_to_cpu(*n)+d);
+ be64_add_cpu((__le64 *)n, d);
+
+ return *n;
}
static __inline u32
fs64_sub(struct super_block *sbp, u32 *n, int d)
{
if (UFS_SB(sbp)-s_bytesex == BYTESEX_LE)
- return *n = cpu_to_le64(le64_to_cpu(*n)-d);
+ le64_add_cpu((__le64 *)n, -d);
else
- return *n = cpu_to_be64(be64_to_cpu(*n)-d);
+ be64_add_cpu((__le64 *)n, -d);
+
+ return *n;
}
static __inline u32
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/7] fs/udf/truncate.c: Use BUG_ON
On Sun, Feb 17, 2008 at 06:56:18PM +0100, Julia Lawall wrote:
> From: Julia Lawall <[EMAIL PROTECTED]>
>
> if (...) BUG(); should be replaced with BUG_ON(...) when the test has no
> side-effects to allow a definition of BUG_ON that drops the code completely.
The same change is in my patch which is waiting for inclusion.
http://lkml.org/lkml/2008/1/30/512
> The semantic patch that makes this change is as follows:
> (http://www.emn.fr/x-info/coccinelle/)
>
> //
> @ disable unlikely @ expression E,f; @@
>
> (
> if (<... f(...) ...>) { BUG(); }
> |
> - if (unlikely(E)) { BUG(); }
> + BUG_ON(E);
> )
>
> @@ expression E,f; @@
>
> (
> if (<... f(...) ...>) { BUG(); }
> |
> - if (E) { BUG(); }
> + BUG_ON(E);
> )
> //
>
> Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
>
> ---
>
> diff -u -p a/fs/udf/truncate.c b/fs/udf/truncate.c
> --- a/fs/udf/truncate.c 2008-02-10 22:34:15.0 +0100
> +++ b/fs/udf/truncate.c 2008-02-17 16:41:19.0 +0100
> @@ -224,8 +224,7 @@ void udf_truncate_extents(struct inode *
> if (indirect_ext_len) {
> /* We managed to free all extents in the
>* indirect extent - free it too */
> - if (!epos.bh)
> - BUG();
> + BUG_ON(!epos.bh);
> udf_free_blocks(sb, inode, epos.block,
> 0, indirect_ext_len);
> } else {
> @@ -272,8 +271,7 @@ void udf_truncate_extents(struct inode *
> }
>
> if (indirect_ext_len) {
> - if (!epos.bh)
> - BUG();
> + BUG_ON(!epos.bh);
> udf_free_blocks(sb, inode, epos.block, 0,
> indirect_ext_len);
> } else {
> -
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: build failure (x86)
On Sun, Feb 17, 2008 at 02:37:09AM +0100, Rafael J. Wysocki wrote:
> On Saturday, 16 of February 2008, Marcin Slusarz wrote:
> > On Sat, Feb 16, 2008 at 03:09:49AM -0800, Andrew Morton wrote:
> > > On Sat, 16 Feb 2008 11:59:07 +0100 Marcin Slusarz <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > arch/x86/kernel/built-in.o: In function `amd_smp_thermal_interrupt':
> > > > (.text+0xe03b): undefined reference to `mce_log_therm_throt_event'
> > > > arch/x86/kernel/built-in.o: In function `acpi_save_state_mem':
> > > > (.text+0x12239): undefined reference to `setup_trampoline'
> > > >
> > > > #
> > > > # Automatically generated make config: don't edit
> > > > # Linux kernel version: 2.6.25-rc2-mm1
> > > > # Sat Feb 16 11:32:49 2008
> > >
> > > ho hum, thanks. I think I'll drop
> > > x86-amd-thermal-interrupt-support.patch.
> > > I don't think it's the final version anwyay.
> > >
> > Ok, I had to revert x86-remove-pt_regs-arg-from-smp_thermal_interrupt
> > before x86-amd-thermal-interrupt-support.
> >
> > Second error vanished when I reverted "suspend: wakeup code in C".
>
> The appended patch should fix the second error.
Yes, it did.
> Thanks,
> Rafael
>
> ---
> On x86-64 the CPU trampoline code is now used while waking up from ACPI
> suspend to RAM. For this reason, make it depend on
> (64BIT && ACPI_SLEEP) as well as on SMP, move the relevant declarations
> to a separate header and move the definition of setup_trampoline() from
> smpboot_64.c .
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> ---
> arch/x86/Kconfig |2 +-
> arch/x86/kernel/acpi/sleep.c |1 -
> arch/x86/kernel/acpi/sleep.h |3 ++-
> arch/x86/kernel/e820_64.c|5 +++--
> arch/x86/kernel/setup_64.c | 16
> arch/x86/kernel/smpboot_64.c | 23 ++-
> include/asm-x86/smp_64.h |2 --
> include/asm-x86/trampoline.h | 18 ++
> 8 files changed, 42 insertions(+), 28 deletions(-)
>
> Index: linux-2.6.25-rc2-mm1/arch/x86/Kconfig
> ===
> --- linux-2.6.25-rc2-mm1.orig/arch/x86/Kconfig
> +++ linux-2.6.25-rc2-mm1/arch/x86/Kconfig
> @@ -180,7 +180,7 @@ config X86_BIOS_REBOOT
>
> config X86_TRAMPOLINE
> bool
> - depends on X86_SMP || (X86_VOYAGER && SMP)
> + depends on X86_SMP || (X86_VOYAGER && SMP) || (64BIT && ACPI_SLEEP)
> default y
>
> config KTIME_SCALAR
> Index: linux-2.6.25-rc2-mm1/arch/x86/kernel/e820_64.c
> ===
> --- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/e820_64.c
> +++ linux-2.6.25-rc2-mm1/arch/x86/kernel/e820_64.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> struct e820map e820;
>
> @@ -58,8 +59,8 @@ struct early_res {
> };
> static struct early_res early_res[MAX_EARLY_RES] __initdata = {
> { 0, PAGE_SIZE, "BIOS data page" }, /* BIOS data
> page */
> -#ifdef CONFIG_SMP
> - { SMP_TRAMPOLINE_BASE, SMP_TRAMPOLINE_BASE + 2*PAGE_SIZE,
> "SMP_TRAMPOLINE" },
> +#ifdef CONFIG_X86_TRAMPOLINE
> + { TRAMPOLINE_BASE, TRAMPOLINE_BASE + 2 * PAGE_SIZE, "TRAMPOLINE" },
> #endif
> {}
> };
> Index: linux-2.6.25-rc2-mm1/arch/x86/kernel/smpboot_64.c
> ===
> --- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/smpboot_64.c
> +++ linux-2.6.25-rc2-mm1/arch/x86/kernel/smpboot_64.c
> @@ -59,6 +59,7 @@
> #include
> #include
> #include
> +#include
>
> /* Number of siblings per CPU package */
> int smp_num_siblings = 1;
> @@ -96,13 +97,6 @@ EXPORT_PER_CPU_SYMBOL(cpu_sibling_map);
> DEFINE_PER_CPU(cpumask_t, cpu_core_map);
> EXPORT_PER_CPU_SYMBOL(cpu_core_map);
>
> -/*
> - * Trampoline 80x86 program as an array.
> - */
> -
> -extern const unsigned char trampoline_data[];
> -extern const unsigned char trampoline_end[];
> -
> /* State of each CPU */
> DEFINE_PER_CPU(int, cpu_state) = { 0 };
>
> @@ -127,19 +121,6 @@ struct task_struct *idle_thread_array[NR
>
>
> /*
> - * Currently trivial. Write the real->protected mode
> - * bootstrap into the page concerned. The caller
> - * has made sure it's suitably aligned.
> - */
> -
> -unsigned long __cpuinit setup_trampoline(void)
> -{
> - void *tramp = __va(SMP_TRAMPOLI
Re: 2.6.25-rc2-mm1: build failure (x86)
On Sun, Feb 17, 2008 at 01:22:11AM +0100, Rafael J. Wysocki wrote: > On Saturday, 16 of February 2008, Marcin Slusarz wrote: > > On Sat, Feb 16, 2008 at 03:09:49AM -0800, Andrew Morton wrote: > > > On Sat, 16 Feb 2008 11:59:07 +0100 Marcin Slusarz <[EMAIL PROTECTED]> > > > wrote: > > > > > > > arch/x86/kernel/built-in.o: In function `amd_smp_thermal_interrupt': > > > > (.text+0xe03b): undefined reference to `mce_log_therm_throt_event' > > This one is easily fixed by the appended patch (whether it works is a separate > issue, though). Yes. It fixed compilation error. > > > > arch/x86/kernel/built-in.o: In function `acpi_save_state_mem': > > > > (.text+0x12239): undefined reference to `setup_trampoline' > > > > > > > > # > > > > # Automatically generated make config: don't edit > > > > # Linux kernel version: 2.6.25-rc2-mm1 > > > > # Sat Feb 16 11:32:49 2008 > > > > > > ho hum, thanks. I think I'll drop > > > x86-amd-thermal-interrupt-support.patch. > > > I don't think it's the final version anwyay. > > > > > Ok, I had to revert x86-remove-pt_regs-arg-from-smp_thermal_interrupt > > before x86-amd-thermal-interrupt-support. > > > > Second error vanished when I reverted "suspend: wakeup code in C". > > It will compile if you set CONFIG_SMP. Working on a fix. > > Thanks, > Rafael > > > --- > arch/x86/kernel/cpu/mcheck/mce_64.c |4 ++-- > arch/x86/kernel/cpu/mcheck/mce_thermal.h |2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > Index: linux-2.6.25-rc2-mm1/arch/x86/kernel/cpu/mcheck/mce_64.c > === > --- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/cpu/mcheck/mce_64.c > +++ linux-2.6.25-rc2-mm1/arch/x86/kernel/cpu/mcheck/mce_64.c > @@ -317,7 +317,7 @@ void do_machine_check(struct pt_regs * r > atomic_dec(_entry); > } > > -#ifdef CONFIG_X86_MCE_INTEL > +#ifdef CONFIG_X86_MCE > /*** > * mce_log_therm_throt_event - Logs the thermal throttling event to mcelog > * @cpu: The CPU on which the event occurred. > @@ -342,7 +342,7 @@ void mce_log_therm_throt_event(unsigned > rdtscll(m.tsc); > mce_log(); > } > -#endif /* CONFIG_X86_MCE_INTEL */ > +#endif /* CONFIG_X86_MCE */ > > /* > * Periodic polling timer for "silent" machine check errors. If the > Index: linux-2.6.25-rc2-mm1/arch/x86/kernel/cpu/mcheck/mce_thermal.h > === > --- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/cpu/mcheck/mce_thermal.h > +++ linux-2.6.25-rc2-mm1/arch/x86/kernel/cpu/mcheck/mce_thermal.h > @@ -4,5 +4,5 @@ > typedef void (*smp_thermal_interrupt_callback_t)(void); > extern smp_thermal_interrupt_callback_t smp_thermal_interrupt; > > -void mce_log_therm_throt_event(unsigned int cpu, __u64 status); > +extern void mce_log_therm_throt_event(unsigned int cpu, __u64 status); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: build failure (x86)
On Sun, Feb 17, 2008 at 01:22:11AM +0100, Rafael J. Wysocki wrote: On Saturday, 16 of February 2008, Marcin Slusarz wrote: On Sat, Feb 16, 2008 at 03:09:49AM -0800, Andrew Morton wrote: On Sat, 16 Feb 2008 11:59:07 +0100 Marcin Slusarz [EMAIL PROTECTED] wrote: arch/x86/kernel/built-in.o: In function `amd_smp_thermal_interrupt': (.text+0xe03b): undefined reference to `mce_log_therm_throt_event' This one is easily fixed by the appended patch (whether it works is a separate issue, though). Yes. It fixed compilation error. arch/x86/kernel/built-in.o: In function `acpi_save_state_mem': (.text+0x12239): undefined reference to `setup_trampoline' # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc2-mm1 # Sat Feb 16 11:32:49 2008 ho hum, thanks. I think I'll drop x86-amd-thermal-interrupt-support.patch. I don't think it's the final version anwyay. Ok, I had to revert x86-remove-pt_regs-arg-from-smp_thermal_interrupt before x86-amd-thermal-interrupt-support. Second error vanished when I reverted suspend: wakeup code in C. It will compile if you set CONFIG_SMP. Working on a fix. Thanks, Rafael --- arch/x86/kernel/cpu/mcheck/mce_64.c |4 ++-- arch/x86/kernel/cpu/mcheck/mce_thermal.h |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) Index: linux-2.6.25-rc2-mm1/arch/x86/kernel/cpu/mcheck/mce_64.c === --- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/cpu/mcheck/mce_64.c +++ linux-2.6.25-rc2-mm1/arch/x86/kernel/cpu/mcheck/mce_64.c @@ -317,7 +317,7 @@ void do_machine_check(struct pt_regs * r atomic_dec(mce_entry); } -#ifdef CONFIG_X86_MCE_INTEL +#ifdef CONFIG_X86_MCE /*** * mce_log_therm_throt_event - Logs the thermal throttling event to mcelog * @cpu: The CPU on which the event occurred. @@ -342,7 +342,7 @@ void mce_log_therm_throt_event(unsigned rdtscll(m.tsc); mce_log(m); } -#endif /* CONFIG_X86_MCE_INTEL */ +#endif /* CONFIG_X86_MCE */ /* * Periodic polling timer for silent machine check errors. If the Index: linux-2.6.25-rc2-mm1/arch/x86/kernel/cpu/mcheck/mce_thermal.h === --- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/cpu/mcheck/mce_thermal.h +++ linux-2.6.25-rc2-mm1/arch/x86/kernel/cpu/mcheck/mce_thermal.h @@ -4,5 +4,5 @@ typedef void (*smp_thermal_interrupt_callback_t)(void); extern smp_thermal_interrupt_callback_t smp_thermal_interrupt; -void mce_log_therm_throt_event(unsigned int cpu, __u64 status); +extern void mce_log_therm_throt_event(unsigned int cpu, __u64 status); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: build failure (x86)
On Sun, Feb 17, 2008 at 02:37:09AM +0100, Rafael J. Wysocki wrote:
On Saturday, 16 of February 2008, Marcin Slusarz wrote:
On Sat, Feb 16, 2008 at 03:09:49AM -0800, Andrew Morton wrote:
On Sat, 16 Feb 2008 11:59:07 +0100 Marcin Slusarz [EMAIL PROTECTED]
wrote:
arch/x86/kernel/built-in.o: In function `amd_smp_thermal_interrupt':
(.text+0xe03b): undefined reference to `mce_log_therm_throt_event'
arch/x86/kernel/built-in.o: In function `acpi_save_state_mem':
(.text+0x12239): undefined reference to `setup_trampoline'
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25-rc2-mm1
# Sat Feb 16 11:32:49 2008
ho hum, thanks. I think I'll drop
x86-amd-thermal-interrupt-support.patch.
I don't think it's the final version anwyay.
Ok, I had to revert x86-remove-pt_regs-arg-from-smp_thermal_interrupt
before x86-amd-thermal-interrupt-support.
Second error vanished when I reverted suspend: wakeup code in C.
The appended patch should fix the second error.
Yes, it did.
Thanks,
Rafael
---
On x86-64 the CPU trampoline code is now used while waking up from ACPI
suspend to RAM. For this reason, make it depend on
(64BIT ACPI_SLEEP) as well as on SMP, move the relevant declarations
to a separate header and move the definition of setup_trampoline() from
smpboot_64.c .
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
arch/x86/Kconfig |2 +-
arch/x86/kernel/acpi/sleep.c |1 -
arch/x86/kernel/acpi/sleep.h |3 ++-
arch/x86/kernel/e820_64.c|5 +++--
arch/x86/kernel/setup_64.c | 16
arch/x86/kernel/smpboot_64.c | 23 ++-
include/asm-x86/smp_64.h |2 --
include/asm-x86/trampoline.h | 18 ++
8 files changed, 42 insertions(+), 28 deletions(-)
Index: linux-2.6.25-rc2-mm1/arch/x86/Kconfig
===
--- linux-2.6.25-rc2-mm1.orig/arch/x86/Kconfig
+++ linux-2.6.25-rc2-mm1/arch/x86/Kconfig
@@ -180,7 +180,7 @@ config X86_BIOS_REBOOT
config X86_TRAMPOLINE
bool
- depends on X86_SMP || (X86_VOYAGER SMP)
+ depends on X86_SMP || (X86_VOYAGER SMP) || (64BIT ACPI_SLEEP)
default y
config KTIME_SCALAR
Index: linux-2.6.25-rc2-mm1/arch/x86/kernel/e820_64.c
===
--- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/e820_64.c
+++ linux-2.6.25-rc2-mm1/arch/x86/kernel/e820_64.c
@@ -27,6 +27,7 @@
#include asm/setup.h
#include asm/sections.h
#include asm/kdebug.h
+#include asm/trampoline.h
struct e820map e820;
@@ -58,8 +59,8 @@ struct early_res {
};
static struct early_res early_res[MAX_EARLY_RES] __initdata = {
{ 0, PAGE_SIZE, BIOS data page }, /* BIOS data
page */
-#ifdef CONFIG_SMP
- { SMP_TRAMPOLINE_BASE, SMP_TRAMPOLINE_BASE + 2*PAGE_SIZE,
SMP_TRAMPOLINE },
+#ifdef CONFIG_X86_TRAMPOLINE
+ { TRAMPOLINE_BASE, TRAMPOLINE_BASE + 2 * PAGE_SIZE, TRAMPOLINE },
#endif
{}
};
Index: linux-2.6.25-rc2-mm1/arch/x86/kernel/smpboot_64.c
===
--- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/smpboot_64.c
+++ linux-2.6.25-rc2-mm1/arch/x86/kernel/smpboot_64.c
@@ -59,6 +59,7 @@
#include asm/irq.h
#include asm/hw_irq.h
#include asm/numa.h
+#include asm/trampoline.h
/* Number of siblings per CPU package */
int smp_num_siblings = 1;
@@ -96,13 +97,6 @@ EXPORT_PER_CPU_SYMBOL(cpu_sibling_map);
DEFINE_PER_CPU(cpumask_t, cpu_core_map);
EXPORT_PER_CPU_SYMBOL(cpu_core_map);
-/*
- * Trampoline 80x86 program as an array.
- */
-
-extern const unsigned char trampoline_data[];
-extern const unsigned char trampoline_end[];
-
/* State of each CPU */
DEFINE_PER_CPU(int, cpu_state) = { 0 };
@@ -127,19 +121,6 @@ struct task_struct *idle_thread_array[NR
/*
- * Currently trivial. Write the real-protected mode
- * bootstrap into the page concerned. The caller
- * has made sure it's suitably aligned.
- */
-
-unsigned long __cpuinit setup_trampoline(void)
-{
- void *tramp = __va(SMP_TRAMPOLINE_BASE);
- memcpy(tramp, trampoline_data, trampoline_end - trampoline_data);
- return virt_to_phys(tramp);
-}
-
-/*
* The bootstrap kernel entry code has set these up. Save them for
* a given CPU
*/
@@ -690,7 +671,7 @@ do_rest:
Dprintk(CPU has booted.\n);
} else {
boot_error = 1;
- if (*((volatile unsigned char
*)phys_to_virt(SMP_TRAMPOLINE_BASE))
+ if (*((unsigned char *)phys_to_virt(TRAMPOLINE_BASE))
== 0xA5)
/* trampoline started but...? */
printk(Stuck ??\n);
Index: linux-2.6.25-rc2-mm1
Re: [PATCH 4/7] fs/udf/truncate.c: Use BUG_ON
On Sun, Feb 17, 2008 at 06:56:18PM +0100, Julia Lawall wrote:
From: Julia Lawall [EMAIL PROTECTED]
if (...) BUG(); should be replaced with BUG_ON(...) when the test has no
side-effects to allow a definition of BUG_ON that drops the code completely.
The same change is in my patch which is waiting for inclusion.
http://lkml.org/lkml/2008/1/30/512
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@ disable unlikely @ expression E,f; @@
(
if (... f(...) ...) { BUG(); }
|
- if (unlikely(E)) { BUG(); }
+ BUG_ON(E);
)
@@ expression E,f; @@
(
if (... f(...) ...) { BUG(); }
|
- if (E) { BUG(); }
+ BUG_ON(E);
)
// /smpl
Signed-off-by: Julia Lawall [EMAIL PROTECTED]
---
diff -u -p a/fs/udf/truncate.c b/fs/udf/truncate.c
--- a/fs/udf/truncate.c 2008-02-10 22:34:15.0 +0100
+++ b/fs/udf/truncate.c 2008-02-17 16:41:19.0 +0100
@@ -224,8 +224,7 @@ void udf_truncate_extents(struct inode *
if (indirect_ext_len) {
/* We managed to free all extents in the
* indirect extent - free it too */
- if (!epos.bh)
- BUG();
+ BUG_ON(!epos.bh);
udf_free_blocks(sb, inode, epos.block,
0, indirect_ext_len);
} else {
@@ -272,8 +271,7 @@ void udf_truncate_extents(struct inode *
}
if (indirect_ext_len) {
- if (!epos.bh)
- BUG();
+ BUG_ON(!epos.bh);
udf_free_blocks(sb, inode, epos.block, 0,
indirect_ext_len);
} else {
-
To unsubscribe from this list: send the line unsubscribe kernel-janitors in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: build failure (x86)
On Sat, Feb 16, 2008 at 03:09:49AM -0800, Andrew Morton wrote: > On Sat, 16 Feb 2008 11:59:07 +0100 Marcin Slusarz <[EMAIL PROTECTED]> wrote: > > > arch/x86/kernel/built-in.o: In function `amd_smp_thermal_interrupt': > > (.text+0xe03b): undefined reference to `mce_log_therm_throt_event' > > arch/x86/kernel/built-in.o: In function `acpi_save_state_mem': > > (.text+0x12239): undefined reference to `setup_trampoline' > > > > # > > # Automatically generated make config: don't edit > > # Linux kernel version: 2.6.25-rc2-mm1 > > # Sat Feb 16 11:32:49 2008 > > ho hum, thanks. I think I'll drop x86-amd-thermal-interrupt-support.patch. > I don't think it's the final version anwyay. > Ok, I had to revert x86-remove-pt_regs-arg-from-smp_thermal_interrupt before x86-amd-thermal-interrupt-support. Second error vanished when I reverted "suspend: wakeup code in C". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: build failure (x86)
arch/x86/kernel/built-in.o: In function `amd_smp_thermal_interrupt': (.text+0xe03b): undefined reference to `mce_log_therm_throt_event' arch/x86/kernel/built-in.o: In function `acpi_save_state_mem': (.text+0x12239): undefined reference to `setup_trampoline' # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc2-mm1 # Sat Feb 16 11:32:49 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_QUICKLIST is not set CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CGROUPS is not set # CONFIG_GROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y # CONFIG_MARKERS is not set CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_VSMP is not set # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set CONFIG_MK8=y # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set
Re: 2.6.25-rc2-mm1: build failure (x86)
arch/x86/kernel/built-in.o: In function `amd_smp_thermal_interrupt': (.text+0xe03b): undefined reference to `mce_log_therm_throt_event' arch/x86/kernel/built-in.o: In function `acpi_save_state_mem': (.text+0x12239): undefined reference to `setup_trampoline' # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc2-mm1 # Sat Feb 16 11:32:49 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_QUICKLIST is not set CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CGROUPS is not set # CONFIG_GROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y # CONFIG_MARKERS is not set CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_VSMP is not set # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set CONFIG_MK8=y # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set
Re: 2.6.25-rc2-mm1: build failure (x86)
On Sat, Feb 16, 2008 at 03:09:49AM -0800, Andrew Morton wrote: On Sat, 16 Feb 2008 11:59:07 +0100 Marcin Slusarz [EMAIL PROTECTED] wrote: arch/x86/kernel/built-in.o: In function `amd_smp_thermal_interrupt': (.text+0xe03b): undefined reference to `mce_log_therm_throt_event' arch/x86/kernel/built-in.o: In function `acpi_save_state_mem': (.text+0x12239): undefined reference to `setup_trampoline' # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc2-mm1 # Sat Feb 16 11:32:49 2008 ho hum, thanks. I think I'll drop x86-amd-thermal-interrupt-support.patch. I don't think it's the final version anwyay. Ok, I had to revert x86-remove-pt_regs-arg-from-smp_thermal_interrupt before x86-amd-thermal-interrupt-support. Second error vanished when I reverted suspend: wakeup code in C. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto: be*_add_cpu conversion
On Wed, Feb 13, 2008 at 09:25:47AM +0100, Roel Kluin wrote:
> [EMAIL PROTECTED] wrote:
> > From: Marcin Slusarz <[EMAIL PROTECTED]>
> >
> > replace all:
> > big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) +
> > expression_in_cpu_byteorder);
> > with:
> > beX_add_cpu(_endian_variable, expression_in_cpu_byteorder);
> > generated with semantic patch
> >
> > Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
> > Cc: Herbert Xu <[EMAIL PROTECTED]>
> > Cc: David S. Miller <[EMAIL PROTECTED]>
> > ---
> > crypto/lrw.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/crypto/lrw.c b/crypto/lrw.c
> > index 9d52e58..4d93928 100644
> > --- a/crypto/lrw.c
> > +++ b/crypto/lrw.c
> > @@ -92,7 +92,7 @@ struct sinfo {
> > static inline void inc(be128 *iv)
> > {
> > if (!(iv->b = cpu_to_be64(be64_to_cpu(iv->b) + 1)))
>
> maybe you also want instead of the line above:
>
> be64_add_cpu(>b, 1);
> if (!iv->b)
>
> > - iv->a = cpu_to_be64(be64_to_cpu(iv->a) + 1);
> > + be64_add_cpu(>a, 1);
> > }
> >
> > static inline void lrw_round(struct sinfo *s, void *dst, const void *src)
>
I'm a bit ashamed... but here is updated patch:
---
crypto: replace all adds to big endians variables with be*_add_cpu
replace all:
big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) +
expression_in_cpu_byteorder);
with:
beX_add_cpu(_endian_variable, expression_in_cpu_byteorder);
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: Herbert Xu <[EMAIL PROTECTED]>
Cc: David S. Miller <[EMAIL PROTECTED]>
Cc: Roel Kluin <[EMAIL PROTECTED]>
---
crypto/lrw.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/crypto/lrw.c b/crypto/lrw.c
index 9d52e58..8ef664e 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -91,8 +91,9 @@ struct sinfo {
static inline void inc(be128 *iv)
{
- if (!(iv->b = cpu_to_be64(be64_to_cpu(iv->b) + 1)))
- iv->a = cpu_to_be64(be64_to_cpu(iv->a) + 1);
+ be64_add_cpu(>b, 1);
+ if (!iv->b)
+ be64_add_cpu(>a, 1);
}
static inline void lrw_round(struct sinfo *s, void *dst, const void *src)
--
1.5.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ufs: [bl]e*_add_cpu conversion
On Wed, Feb 13, 2008 at 10:41:44AM +0100, Roel Kluin wrote:
> [EMAIL PROTECTED] wrote:
> > replace all:
> > big/little_endian_variable =
> > cpu_to_[bl]eX([bl]eX_to_cpu(big/little_endian_variable) +
> > expression_in_cpu_byteorder);
> > with:
> > [bl]eX_add_cpu(/little_endian_variable,
> > expression_in_cpu_byteorder);
>
> you may also want these:
> ---
> [bl]e_add_cpu conversion in return
>
> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
Acked-by: Marcin Slusarz <[EMAIL PROTECTED]>
> ---
> diff --git a/fs/ufs/swab.h b/fs/ufs/swab.h
> index 1683d2b..a1e3000 100644
> --- a/fs/ufs/swab.h
> +++ b/fs/ufs/swab.h
> @@ -44,18 +44,22 @@ static __inline u32
> fs64_add(struct super_block *sbp, u32 *n, int d)
> {
> if (UFS_SB(sbp)->s_bytesex == BYTESEX_LE)
> - return *n = cpu_to_le64(le64_to_cpu(*n)+d);
> + le64_add_cpu(n, d);
> else
> - return *n = cpu_to_be64(be64_to_cpu(*n)+d);
> + be64_add_cpu(n, d);
> +
> + return *n;
> }
>
> static __inline u32
> fs64_sub(struct super_block *sbp, u32 *n, int d)
> {
> if (UFS_SB(sbp)->s_bytesex == BYTESEX_LE)
> - return *n = cpu_to_le64(le64_to_cpu(*n)-d);
> + le64_add_cpu(n, -d);
> else
> - return *n = cpu_to_be64(be64_to_cpu(*n)-d);
> + be64_add_cpu(n, -d);
> +
> + return *n;
> }
>
> static __inline u32
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto: be*_add_cpu conversion
On Wed, Feb 13, 2008 at 09:25:47AM +0100, Roel Kluin wrote:
[EMAIL PROTECTED] wrote:
From: Marcin Slusarz [EMAIL PROTECTED]
replace all:
big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) +
expression_in_cpu_byteorder);
with:
beX_add_cpu(big_endian_variable, expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz [EMAIL PROTECTED]
Cc: Herbert Xu [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
---
crypto/lrw.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/crypto/lrw.c b/crypto/lrw.c
index 9d52e58..4d93928 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -92,7 +92,7 @@ struct sinfo {
static inline void inc(be128 *iv)
{
if (!(iv-b = cpu_to_be64(be64_to_cpu(iv-b) + 1)))
maybe you also want instead of the line above:
be64_add_cpu(iv-b, 1);
if (!iv-b)
- iv-a = cpu_to_be64(be64_to_cpu(iv-a) + 1);
+ be64_add_cpu(iv-a, 1);
}
static inline void lrw_round(struct sinfo *s, void *dst, const void *src)
I'm a bit ashamed... but here is updated patch:
---
crypto: replace all adds to big endians variables with be*_add_cpu
replace all:
big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) +
expression_in_cpu_byteorder);
with:
beX_add_cpu(big_endian_variable, expression_in_cpu_byteorder);
Signed-off-by: Marcin Slusarz [EMAIL PROTECTED]
Cc: Herbert Xu [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Cc: Roel Kluin [EMAIL PROTECTED]
---
crypto/lrw.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/crypto/lrw.c b/crypto/lrw.c
index 9d52e58..8ef664e 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -91,8 +91,9 @@ struct sinfo {
static inline void inc(be128 *iv)
{
- if (!(iv-b = cpu_to_be64(be64_to_cpu(iv-b) + 1)))
- iv-a = cpu_to_be64(be64_to_cpu(iv-a) + 1);
+ be64_add_cpu(iv-b, 1);
+ if (!iv-b)
+ be64_add_cpu(iv-a, 1);
}
static inline void lrw_round(struct sinfo *s, void *dst, const void *src)
--
1.5.3.7
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ufs: [bl]e*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]>
replace all:
big/little_endian_variable =
cpu_to_[bl]eX([bl]eX_to_cpu(big/little_endian_variable) +
expression_in_cpu_byteorder);
with:
[bl]eX_add_cpu(/little_endian_variable,
expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: Evgeniy Dushistov <[EMAIL PROTECTED]>
---
fs/ufs/swab.h | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/ufs/swab.h b/fs/ufs/swab.h
index 1683d2b..a4340d0 100644
--- a/fs/ufs/swab.h
+++ b/fs/ufs/swab.h
@@ -80,18 +80,18 @@ static inline void
fs32_add(struct super_block *sbp, __fs32 *n, int d)
{
if (UFS_SB(sbp)->s_bytesex == BYTESEX_LE)
- *(__le32 *)n = cpu_to_le32(le32_to_cpu(*(__le32 *)n)+d);
+ le32_add_cpu((__le32 *)n, d);
else
- *(__be32 *)n = cpu_to_be32(be32_to_cpu(*(__be32 *)n)+d);
+ be32_add_cpu((__be32 *)n, d);
}
static inline void
fs32_sub(struct super_block *sbp, __fs32 *n, int d)
{
if (UFS_SB(sbp)->s_bytesex == BYTESEX_LE)
- *(__le32 *)n = cpu_to_le32(le32_to_cpu(*(__le32 *)n)-d);
+ le32_add_cpu((__le32 *)n, -d);
else
- *(__be32 *)n = cpu_to_be32(be32_to_cpu(*(__be32 *)n)-d);
+ be32_add_cpu((__be32 *)n, -d);
}
static inline u16
@@ -116,18 +116,18 @@ static inline void
fs16_add(struct super_block *sbp, __fs16 *n, int d)
{
if (UFS_SB(sbp)->s_bytesex == BYTESEX_LE)
- *(__le16 *)n = cpu_to_le16(le16_to_cpu(*(__le16 *)n)+d);
+ le16_add_cpu((__le16 *)n, d);
else
- *(__be16 *)n = cpu_to_be16(be16_to_cpu(*(__be16 *)n)+d);
+ be16_add_cpu((__be16 *)n, d);
}
static inline void
fs16_sub(struct super_block *sbp, __fs16 *n, int d)
{
if (UFS_SB(sbp)->s_bytesex == BYTESEX_LE)
- *(__le16 *)n = cpu_to_le16(le16_to_cpu(*(__le16 *)n)-d);
+ le16_add_cpu((__le16 *)n, -d);
else
- *(__be16 *)n = cpu_to_be16(be16_to_cpu(*(__be16 *)n)-d);
+ be16_add_cpu((__be16 *)n, -d);
}
#endif /* _UFS_SWAB_H */
--
1.5.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sysv: [bl]e*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]>
replace all:
big/little_endian_variable =
cpu_to_[bl]eX([bl]eX_to_cpu(big/little_endian_variable) +
expression_in_cpu_byteorder);
with:
[bl]eX_add_cpu(/little_endian_variable,
expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: Christoph Hellwig <[EMAIL PROTECTED]>
---
fs/sysv/sysv.h |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/sysv/sysv.h b/fs/sysv/sysv.h
index 42d51d1..38ebe3f 100644
--- a/fs/sysv/sysv.h
+++ b/fs/sysv/sysv.h
@@ -217,9 +217,9 @@ static inline __fs32 fs32_add(struct sysv_sb_info *sbi,
__fs32 *n, int d)
if (sbi->s_bytesex == BYTESEX_PDP)
*(__u32*)n = PDP_swab(PDP_swab(*(__u32*)n)+d);
else if (sbi->s_bytesex == BYTESEX_LE)
- *(__le32*)n = cpu_to_le32(le32_to_cpu(*(__le32*)n)+d);
+ le32_add_cpu((__le32 *)n, d);
else
- *(__be32*)n = cpu_to_be32(be32_to_cpu(*(__be32*)n)+d);
+ be32_add_cpu((__be32 *)n, d);
return *n;
}
@@ -242,9 +242,9 @@ static inline __fs16 cpu_to_fs16(struct sysv_sb_info *sbi,
__u16 n)
static inline __fs16 fs16_add(struct sysv_sb_info *sbi, __fs16 *n, int d)
{
if (sbi->s_bytesex != BYTESEX_BE)
- *(__le16*)n = cpu_to_le16(le16_to_cpu(*(__le16 *)n)+d);
+ le16_add_cpu((__le16 *)n, d);
else
- *(__be16*)n = cpu_to_be16(be16_to_cpu(*(__be16 *)n)+d);
+ be16_add_cpu((__be16 *)n, d);
return *n;
}
--
1.5.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] reiserfs: le*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]>
replace all:
little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) +
expression_in_cpu_byteorder);
with:
leX_add_cpu(_endian_variable, expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
---
fs/reiserfs/objectid.c |5 ++---
fs/reiserfs/stree.c|3 +--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/fs/reiserfs/objectid.c b/fs/reiserfs/objectid.c
index 65feba4..f0c1543 100644
--- a/fs/reiserfs/objectid.c
+++ b/fs/reiserfs/objectid.c
@@ -114,7 +114,7 @@ void reiserfs_release_objectid(struct
reiserfs_transaction_handle *th,
if (objectid_to_release == le32_to_cpu(map[i])) {
/* This incrementation unallocates the objectid. */
//map[i]++;
- map[i] = cpu_to_le32(le32_to_cpu(map[i]) + 1);
+ le32_add_cpu([i], 1);
/* Did we unallocate the last member of an odd
sequence, and can shrink oids? */
if (map[i] == map[i + 1]) {
@@ -138,8 +138,7 @@ void reiserfs_release_objectid(struct
reiserfs_transaction_handle *th,
/* size of objectid map is not changed */
if (objectid_to_release + 1 == le32_to_cpu(map[i + 1]))
{
//objectid_map[i+1]--;
- map[i + 1] =
- cpu_to_le32(le32_to_cpu(map[i + 1]) - 1);
+ le32_add_cpu([i + 1], -1);
return;
}
diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c
index d2db241..abbc64d 100644
--- a/fs/reiserfs/stree.c
+++ b/fs/reiserfs/stree.c
@@ -1419,8 +1419,7 @@ int reiserfs_delete_object(struct
reiserfs_transaction_handle *th,
inode_generation =
_SB(th->t_super)->s_rs->s_inode_generation;
- *inode_generation =
- cpu_to_le32(le32_to_cpu(*inode_generation) + 1);
+ le32_add_cpu(inode_generation, 1);
}
/* USE_INODE_GENERATION_COUNTER */
#endif
--
1.5.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] quota: le*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]>
replace all:
little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) +
expression_in_cpu_byteorder);
with:
leX_add_cpu(_endian_variable, expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: Jan Kara <[EMAIL PROTECTED]>
---
fs/quota_v2.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/quota_v2.c b/fs/quota_v2.c
index c519a58..a9f9eef 100644
--- a/fs/quota_v2.c
+++ b/fs/quota_v2.c
@@ -303,7 +303,7 @@ static uint find_free_dqentry(struct dquot *dquot, int *err)
printk(KERN_ERR "VFS: find_free_dqentry(): Can't remove
block (%u) from entry free list.\n", blk);
goto out_buf;
}
- dh->dqdh_entries = cpu_to_le16(le16_to_cpu(dh->dqdh_entries)+1);
+ le16_add_cpu(>dqdh_entries, 1);
memset(, 0, sizeof(struct v2_disk_dqblk));
/* Find free structure in block */
for (i = 0; i < V2_DQSTRINBLK && memcmp(, ddquot+i,
sizeof(struct v2_disk_dqblk)); i++);
@@ -445,7 +445,7 @@ static int free_dqentry(struct dquot *dquot, uint blk)
goto out_buf;
}
dh = (struct v2_disk_dqdbheader *)buf;
- dh->dqdh_entries = cpu_to_le16(le16_to_cpu(dh->dqdh_entries)-1);
+ le16_add_cpu(>dqdh_entries, -1);
if (!le16_to_cpu(dh->dqdh_entries)) { /* Block got free? */
if ((ret = remove_free_dqentry(sb, type, buf, blk)) < 0 ||
(ret = put_free_dqblk(sb, type, buf, blk)) < 0) {
--
1.5.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ocfs2: le*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]>
replace all:
little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) +
expression_in_cpu_byteorder);
with:
leX_add_cpu(_endian_variable, expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: Mark Fasheh <[EMAIL PROTECTED]>
Cc: Kurt Hackel <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
---
fs/ocfs2/dir.c|5 ++---
fs/ocfs2/localalloc.c |3 +--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index e280833..8a18758 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -390,9 +390,8 @@ static int __ocfs2_delete_entry(handle_t *handle, struct
inode *dir,
goto bail;
}
if (pde)
- pde->rec_len =
- cpu_to_le16(le16_to_cpu(pde->rec_len) +
- le16_to_cpu(de->rec_len));
+ le16_add_cpu(>rec_len,
+ le16_to_cpu(de->rec_len));
else
de->inode = 0;
dir->i_version++;
diff --git a/fs/ocfs2/localalloc.c b/fs/ocfs2/localalloc.c
index add1ffd..d0e217e 100644
--- a/fs/ocfs2/localalloc.c
+++ b/fs/ocfs2/localalloc.c
@@ -588,8 +588,7 @@ int ocfs2_claim_local_alloc_bits(struct ocfs2_super *osb,
while(bits_wanted--)
ocfs2_set_bit(start++, bitmap);
- alloc->id1.bitmap1.i_used = cpu_to_le32(*num_bits +
- le32_to_cpu(alloc->id1.bitmap1.i_used));
+ le32_add_cpu(>id1.bitmap1.i_used, *num_bits);
status = ocfs2_journal_dirty(handle, osb->local_alloc_bh);
if (status < 0) {
--
1.5.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ntfs: le*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]> replace all: little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) + expression_in_cpu_byteorder); with: leX_add_cpu(_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]> Cc: Anton Altaparmakov <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] --- fs/ntfs/upcase.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/ntfs/upcase.c b/fs/ntfs/upcase.c index 9101807..e2f72ca 100644 --- a/fs/ntfs/upcase.c +++ b/fs/ntfs/upcase.c @@ -77,11 +77,10 @@ ntfschar *generate_default_upcase(void) uc[i] = cpu_to_le16(i); for (r = 0; uc_run_table[r][0]; r++) for (i = uc_run_table[r][0]; i < uc_run_table[r][1]; i++) - uc[i] = cpu_to_le16(le16_to_cpu(uc[i]) + - uc_run_table[r][2]); + le16_add_cpu([i], uc_run_table[r][2]); for (r = 0; uc_dup_table[r][0]; r++) for (i = uc_dup_table[r][0]; i < uc_dup_table[r][1]; i += 2) - uc[i + 1] = cpu_to_le16(le16_to_cpu(uc[i + 1]) - 1); + le16_add_cpu([i + 1], -1); for (r = 0; uc_word_table[r][0]; r++) uc[uc_word_table[r][0]] = cpu_to_le16(uc_word_table[r][1]); return uc; -- 1.5.3.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] jfs: le*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]>
replace all:
little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) +
expression_in_cpu_byteorder);
with:
leX_add_cpu(_endian_variable, expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
---
fs/jfs/jfs_dmap.c | 11 +--
fs/jfs/jfs_imap.c | 15 ++-
fs/jfs/jfs_xtree.c | 26 --
3 files changed, 19 insertions(+), 33 deletions(-)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index e198506..2bc7d8a 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -2172,7 +2172,7 @@ static void dbAllocBits(struct bmap * bmp, struct dmap *
dp, s64 blkno,
}
/* update the free count for this dmap */
- dp->nfree = cpu_to_le32(le32_to_cpu(dp->nfree) - nblocks);
+ le32_add_cpu(>nfree, -nblocks);
BMAP_LOCK(bmp);
@@ -2316,7 +2316,7 @@ static int dbFreeBits(struct bmap * bmp, struct dmap *
dp, s64 blkno,
/* update the free count for this dmap.
*/
- dp->nfree = cpu_to_le32(le32_to_cpu(dp->nfree) + nblocks);
+ le32_add_cpu(>nfree, nblocks);
BMAP_LOCK(bmp);
@@ -3226,7 +3226,7 @@ static int dbAllocDmapBU(struct bmap * bmp, struct dmap *
dp, s64 blkno,
}
/* update the free count for this dmap */
- dp->nfree = cpu_to_le32(le32_to_cpu(dp->nfree) - nblocks);
+ le32_add_cpu(>nfree, -nblocks);
/* reconstruct summary tree */
dbInitDmapTree(dp);
@@ -3660,9 +3660,8 @@ static int dbInitDmap(struct dmap * dp, s64 Blkno, int
nblocks)
goto initTree;
}
} else {
- dp->nblocks =
- cpu_to_le32(le32_to_cpu(dp->nblocks) + nblocks);
- dp->nfree = cpu_to_le32(le32_to_cpu(dp->nfree) + nblocks);
+ le32_add_cpu(>nblocks, nblocks);
+ le32_add_cpu(>nfree, nblocks);
}
/* word number containing start block number */
diff --git a/fs/jfs/jfs_imap.c b/fs/jfs/jfs_imap.c
index 9bf29f7..734ec91 100644
--- a/fs/jfs/jfs_imap.c
+++ b/fs/jfs/jfs_imap.c
@@ -1019,8 +1019,7 @@ int diFree(struct inode *ip)
/* update the free inode counts at the iag, ag and
* map level.
*/
- iagp->nfreeinos =
- cpu_to_le32(le32_to_cpu(iagp->nfreeinos) + 1);
+ le32_add_cpu(>nfreeinos, 1);
imap->im_agctl[agno].numfree += 1;
atomic_inc(>im_numfree);
@@ -1219,9 +1218,8 @@ int diFree(struct inode *ip)
/* update the number of free inodes and number of free extents
* for the iag.
*/
- iagp->nfreeinos = cpu_to_le32(le32_to_cpu(iagp->nfreeinos) -
- (INOSPEREXT - 1));
- iagp->nfreeexts = cpu_to_le32(le32_to_cpu(iagp->nfreeexts) + 1);
+ le32_add_cpu(>nfreeinos, -(INOSPEREXT - 1));
+ le32_add_cpu(>nfreeexts, 1);
/* update the number of free inodes and backed inodes
* at the ag and inode map level.
@@ -2124,7 +2122,7 @@ static int diAllocBit(struct inomap * imap, struct iag *
iagp, int ino)
/* update the free inode count at the iag, ag, inode
* map levels.
*/
- iagp->nfreeinos = cpu_to_le32(le32_to_cpu(iagp->nfreeinos) - 1);
+ le32_add_cpu(>nfreeinos, -1);
imap->im_agctl[agno].numfree -= 1;
atomic_dec(>im_numfree);
@@ -2378,9 +2376,8 @@ static int diNewExt(struct inomap * imap, struct iag *
iagp, int extno)
/* update the free inode and free extent counts for the
* iag.
*/
- iagp->nfreeinos = cpu_to_le32(le32_to_cpu(iagp->nfreeinos) +
- (INOSPEREXT - 1));
- iagp->nfreeexts = cpu_to_le32(le32_to_cpu(iagp->nfreeexts) - 1);
+ le32_add_cpu(>nfreeinos, (INOSPEREXT - 1));
+ le32_add_cpu(>nfreeexts, -1);
/* update the free and backed inode counts for the ag.
*/
diff --git a/fs/jfs/jfs_xtree.c b/fs/jfs/jfs_xtree.c
index a000aaa..5a61ebf 100644
--- a/fs/jfs/jfs_xtree.c
+++ b/fs/jfs/jfs_xtree.c
@@ -905,8 +905,7 @@ int xtInsert(tid_t tid, /* transaction id */
XT_PUTENTRY(xad, xflag, xoff, xlen, xaddr);
/* advance next available entry index */
- p->header.nextindex =
- cpu_to_le16(le16_to_cpu(p->header.nextindex) + 1);
+ le16_add_cpu(>header.nextindex, 1);
/* Don't log it if there are no links to the file */
if (!test_cflag(COMMIT_Nolink, ip)) {
@@ -997,8 +996,7 @@ xtSplitUp(tid_t tid,
split->addr);
/* advance next available entry index */
-
[PATCH] ext4: le*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]>
replace all:
little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) +
expression_in_cpu_byteorder);
with:
leX_add_cpu(_endian_variable, expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: Andrew Morton <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: "Theodore Ts'o" <[EMAIL PROTECTED]>
Cc: Mingming Cao <[EMAIL PROTECTED]>
---
fs/ext4/balloc.c |7 ++-
fs/ext4/extents.c | 20 +---
fs/ext4/ialloc.c | 12
fs/ext4/mballoc.c |7 ++-
fs/ext4/resize.c |6 ++
fs/ext4/super.c |2 +-
fs/ext4/xattr.c |6 ++
7 files changed, 22 insertions(+), 38 deletions(-)
diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
index 0737e05..5d34899 100644
--- a/fs/ext4/balloc.c
+++ b/fs/ext4/balloc.c
@@ -752,9 +752,7 @@ do_more:
jbd_unlock_bh_state(bitmap_bh);
spin_lock(sb_bgl_lock(sbi, block_group));
- desc->bg_free_blocks_count =
- cpu_to_le16(le16_to_cpu(desc->bg_free_blocks_count) +
- group_freed);
+ le16_add_cpu(>bg_free_blocks_count, group_freed);
desc->bg_checksum = ext4_group_desc_csum(sbi, block_group, desc);
spin_unlock(sb_bgl_lock(sbi, block_group));
percpu_counter_add(>s_freeblocks_counter, count);
@@ -1823,8 +1821,7 @@ allocated:
spin_lock(sb_bgl_lock(sbi, group_no));
if (gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT))
gdp->bg_flags &= cpu_to_le16(~EXT4_BG_BLOCK_UNINIT);
- gdp->bg_free_blocks_count =
- cpu_to_le16(le16_to_cpu(gdp->bg_free_blocks_count)-num);
+ le16_add_cpu(>bg_free_blocks_count, -num);
gdp->bg_checksum = ext4_group_desc_csum(sbi, group_no, gdp);
spin_unlock(sb_bgl_lock(sbi, group_no));
percpu_counter_sub(>s_freeblocks_counter, num);
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index bc7081f..ad628ff 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -608,7 +608,7 @@ static int ext4_ext_insert_index(handle_t *handle, struct
inode *inode,
ix->ei_block = cpu_to_le32(logical);
ext4_idx_store_pblock(ix, ptr);
- curp->p_hdr->eh_entries =
cpu_to_le16(le16_to_cpu(curp->p_hdr->eh_entries)+1);
+ le16_add_cpu(>p_hdr->eh_entries, 1);
BUG_ON(le16_to_cpu(curp->p_hdr->eh_entries)
> le16_to_cpu(curp->p_hdr->eh_max));
@@ -730,7 +730,7 @@ static int ext4_ext_split(handle_t *handle, struct inode
*inode,
}
if (m) {
memmove(ex, path[depth].p_ext-m, sizeof(struct ext4_extent)*m);
- neh->eh_entries = cpu_to_le16(le16_to_cpu(neh->eh_entries)+m);
+ le16_add_cpu(>eh_entries, m);
}
set_buffer_uptodate(bh);
@@ -747,8 +747,7 @@ static int ext4_ext_split(handle_t *handle, struct inode
*inode,
err = ext4_ext_get_access(handle, inode, path + depth);
if (err)
goto cleanup;
- path[depth].p_hdr->eh_entries =
-cpu_to_le16(le16_to_cpu(path[depth].p_hdr->eh_entries)-m);
+ le16_add_cpu([depth].p_hdr->eh_entries, -m);
err = ext4_ext_dirty(handle, inode, path + depth);
if (err)
goto cleanup;
@@ -811,8 +810,7 @@ static int ext4_ext_split(handle_t *handle, struct inode
*inode,
if (m) {
memmove(++fidx, path[i].p_idx - m,
sizeof(struct ext4_extent_idx) * m);
- neh->eh_entries =
- cpu_to_le16(le16_to_cpu(neh->eh_entries) + m);
+ le16_add_cpu(>eh_entries, m);
}
set_buffer_uptodate(bh);
unlock_buffer(bh);
@@ -828,7 +826,7 @@ static int ext4_ext_split(handle_t *handle, struct inode
*inode,
err = ext4_ext_get_access(handle, inode, path + i);
if (err)
goto cleanup;
- path[i].p_hdr->eh_entries =
cpu_to_le16(le16_to_cpu(path[i].p_hdr->eh_entries)-m);
+ le16_add_cpu([i].p_hdr->eh_entries, -m);
err = ext4_ext_dirty(handle, inode, path + i);
if (err)
goto cleanup;
@@ -1363,7 +1361,7 @@ int ext4_ext_try_to_merge(struct inode *inode,
* sizeof(struct ext4_extent);
memmove(ex + 1, ex + 2, len);
}
- eh->eh_entries = cpu_to_le16(le16_to_cpu(eh->eh_e
[PATCH] ext2: le*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]>
replace all:
little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) +
expression_in_cpu_byteorder);
with:
leX_add_cpu(_endian_variable, expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
---
fs/ext2/ialloc.c | 12
fs/ext2/super.c |2 +-
fs/ext2/xattr.c |9 +++--
3 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/fs/ext2/ialloc.c b/fs/ext2/ialloc.c
index 5deb8b7..0f3e3f3 100644
--- a/fs/ext2/ialloc.c
+++ b/fs/ext2/ialloc.c
@@ -75,11 +75,9 @@ static void ext2_release_inode(struct super_block *sb, int
group, int dir)
}
spin_lock(sb_bgl_lock(EXT2_SB(sb), group));
- desc->bg_free_inodes_count =
- cpu_to_le16(le16_to_cpu(desc->bg_free_inodes_count) + 1);
+ le16_add_cpu(>bg_free_inodes_count, 1);
if (dir)
- desc->bg_used_dirs_count =
- cpu_to_le16(le16_to_cpu(desc->bg_used_dirs_count) - 1);
+ le16_add_cpu(>bg_used_dirs_count, -1);
spin_unlock(sb_bgl_lock(EXT2_SB(sb), group));
if (dir)
percpu_counter_dec(_SB(sb)->s_dirs_counter);
@@ -539,13 +537,11 @@ got:
percpu_counter_inc(>s_dirs_counter);
spin_lock(sb_bgl_lock(sbi, group));
- gdp->bg_free_inodes_count =
-cpu_to_le16(le16_to_cpu(gdp->bg_free_inodes_count) - 1);
+ le16_add_cpu(>bg_free_inodes_count, -1);
if (S_ISDIR(mode)) {
if (sbi->s_debts[group] < 255)
sbi->s_debts[group]++;
- gdp->bg_used_dirs_count =
- cpu_to_le16(le16_to_cpu(gdp->bg_used_dirs_count) + 1);
+ le16_add_cpu(>bg_used_dirs_count, 1);
} else {
if (sbi->s_debts[group])
sbi->s_debts[group]--;
diff --git a/fs/ext2/super.c b/fs/ext2/super.c
index 108f739..7e68673 100644
--- a/fs/ext2/super.c
+++ b/fs/ext2/super.c
@@ -603,7 +603,7 @@ static int ext2_setup_super (struct super_block * sb,
"running e2fsck is recommended\n");
if (!le16_to_cpu(es->s_max_mnt_count))
es->s_max_mnt_count = cpu_to_le16(EXT2_DFL_MAX_MNT_COUNT);
- es->s_mnt_count=cpu_to_le16(le16_to_cpu(es->s_mnt_count) + 1);
+ le16_add_cpu(>s_mnt_count, 1);
ext2_write_super(sb);
if (test_opt (sb, DEBUG))
printk ("[EXT II FS %s, %s, bs=%lu, fs=%lu, gc=%lu, "
diff --git a/fs/ext2/xattr.c b/fs/ext2/xattr.c
index 3e8683d..495ec0d 100644
--- a/fs/ext2/xattr.c
+++ b/fs/ext2/xattr.c
@@ -646,8 +646,7 @@ ext2_xattr_set2(struct inode *inode, struct buffer_head
*old_bh,
unlock_buffer(new_bh);
goto cleanup;
}
- HDR(new_bh)->h_refcount = cpu_to_le32(1 +
- le32_to_cpu(HDR(new_bh)->h_refcount));
+ le32_add_cpu((new_bh)->h_refcount, 1);
ea_bdebug(new_bh, "refcount now=%d",
le32_to_cpu(HDR(new_bh)->h_refcount));
}
@@ -731,8 +730,7 @@ ext2_xattr_set2(struct inode *inode, struct buffer_head
*old_bh,
bforget(old_bh);
} else {
/* Decrement the refcount only. */
- HDR(old_bh)->h_refcount = cpu_to_le32(
- le32_to_cpu(HDR(old_bh)->h_refcount) - 1);
+ le32_add_cpu((old_bh)->h_refcount, -1);
if (ce)
mb_cache_entry_release(ce);
DQUOT_FREE_BLOCK(inode, 1);
@@ -789,8 +787,7 @@ ext2_xattr_delete_inode(struct inode *inode)
bforget(bh);
unlock_buffer(bh);
} else {
- HDR(bh)->h_refcount = cpu_to_le32(
- le32_to_cpu(HDR(bh)->h_refcount) - 1);
+ le32_add_cpu((bh)->h_refcount, -1);
if (ce)
mb_cache_entry_release(ce);
ea_bdebug(bh, "refcount now=%d",
--
1.5.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scsi: le*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]>
replace all:
little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) +
expression_in_cpu_byteorder);
with:
leX_add_cpu(_endian_variable, expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
---
drivers/scsi/aacraid/commsup.c |2 +-
drivers/scsi/ips.c |8 ++--
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/aacraid/commsup.c b/drivers/scsi/aacraid/commsup.c
index 81b3692..3ac8c82 100644
--- a/drivers/scsi/aacraid/commsup.c
+++ b/drivers/scsi/aacraid/commsup.c
@@ -594,7 +594,7 @@ void aac_consumer_free(struct aac_dev * dev, struct
aac_queue *q, u32 qid)
if (le32_to_cpu(*q->headers.consumer) >= q->entries)
*q->headers.consumer = cpu_to_le32(1);
else
- *q->headers.consumer =
cpu_to_le32(le32_to_cpu(*q->headers.consumer)+1);
+ le32_add_cpu(q->headers.consumer, 1);
if (wasfull) {
switch (qid) {
diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
index bb152fb..f45770a 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -3696,9 +3696,7 @@ ips_send_cmd(ips_ha_t * ha, ips_scb_t * scb)
scb->cmd.basic_io.sg_count = scb->sg_len;
if (scb->cmd.basic_io.lba)
- scb->cmd.basic_io.lba =
- cpu_to_le32(le32_to_cpu
- (scb->cmd.basic_io.lba) +
+ le32_add_cpu(>cmd.basic_io.lba,
le16_to_cpu(scb->cmd.basic_io.
sector_count));
else
@@ -3744,9 +3742,7 @@ ips_send_cmd(ips_ha_t * ha, ips_scb_t * scb)
scb->cmd.basic_io.sg_count = scb->sg_len;
if (scb->cmd.basic_io.lba)
- scb->cmd.basic_io.lba =
- cpu_to_le32(le32_to_cpu
- (scb->cmd.basic_io.lba) +
+ le32_add_cpu(>cmd.basic_io.lba,
le16_to_cpu(scb->cmd.basic_io.
sector_count));
else
--
1.5.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ipw2200: le*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]> replace all: little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) + expression_in_cpu_byteorder); with: leX_add_cpu(_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]> Cc: Zhu Yi <[EMAIL PROTECTED]> Cc: John W. Linville <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] --- drivers/net/wireless/ipw2200.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c index 3e6ad7b..5d9854e 100644 --- a/drivers/net/wireless/ipw2200.c +++ b/drivers/net/wireless/ipw2200.c @@ -10326,9 +10326,7 @@ static int ipw_tx_skb(struct ipw_priv *priv, struct ieee80211_txb *txb, remaining_bytes, PCI_DMA_TODEVICE)); - tfd->u.data.num_chunks = - cpu_to_le32(le32_to_cpu(tfd->u.data.num_chunks) + - 1); + le32_add_cpu(>u.data.num_chunks, 1); } } -- 1.5.3.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hfs/hfsplus: be*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]> replace all: big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) + expression_in_cpu_byteorder); with: beX_add_cpu(_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]> Cc: Roman Zippel <[EMAIL PROTECTED]> --- fs/hfs/mdb.c |2 +- fs/hfsplus/super.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/hfs/mdb.c b/fs/hfs/mdb.c index b4651e1..36ca2e1 100644 --- a/fs/hfs/mdb.c +++ b/fs/hfs/mdb.c @@ -215,7 +215,7 @@ int hfs_mdb_get(struct super_block *sb) attrib &= cpu_to_be16(~HFS_SB_ATTRIB_UNMNT); attrib |= cpu_to_be16(HFS_SB_ATTRIB_INCNSTNT); mdb->drAtrb = attrib; - mdb->drWrCnt = cpu_to_be32(be32_to_cpu(mdb->drWrCnt) + 1); + be32_add_cpu(>drWrCnt, 1); mdb->drLsMod = hfs_mtime(); mark_buffer_dirty(HFS_SB(sb)->mdb_bh); diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index b0f9ad3..068523b 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -423,7 +423,7 @@ static int hfsplus_fill_super(struct super_block *sb, void *data, int silent) */ vhdr->last_mount_vers = cpu_to_be32(HFSP_MOUNT_VERSION); vhdr->modify_date = hfsp_now2mt(); - vhdr->write_count = cpu_to_be32(be32_to_cpu(vhdr->write_count) + 1); + be32_add_cpu(>write_count, 1); vhdr->attributes &= cpu_to_be32(~HFSPLUS_VOL_UNMNT); vhdr->attributes |= cpu_to_be32(HFSPLUS_VOL_INCNSTNT); mark_buffer_dirty(HFSPLUS_SB(sb).s_vhbh); -- 1.5.3.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gfs2: be*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]>
replace all:
big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) +
expression_in_cpu_byteorder);
with:
beX_add_cpu(_endian_variable, expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: Steven Whitehouse <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
---
fs/gfs2/dir.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c
index c347095..6f2e382 100644
--- a/fs/gfs2/dir.c
+++ b/fs/gfs2/dir.c
@@ -1021,13 +1021,13 @@ static int dir_split_leaf(struct inode *inode, const
struct qstr *name)
new->de_inum = dent->de_inum; /* No endian worries */
new->de_type = dent->de_type; /* No endian worries */
- nleaf->lf_entries =
cpu_to_be16(be16_to_cpu(nleaf->lf_entries)+1);
+ be16_add_cpu(>lf_entries, 1);
dirent_del(dip, obh, prev, dent);
if (!oleaf->lf_entries)
gfs2_consist_inode(dip);
- oleaf->lf_entries =
cpu_to_be16(be16_to_cpu(oleaf->lf_entries)-1);
+ be16_add_cpu(>lf_entries, -1);
if (!prev)
prev = dent;
@@ -1616,7 +1616,7 @@ int gfs2_dir_add(struct inode *inode, const struct qstr
*name,
dent->de_type = cpu_to_be16(type);
if (ip->i_di.di_flags & GFS2_DIF_EXHASH) {
leaf = (struct gfs2_leaf *)bh->b_data;
- leaf->lf_entries =
cpu_to_be16(be16_to_cpu(leaf->lf_entries) + 1);
+ be16_add_cpu(>lf_entries, 1);
}
brelse(bh);
error = gfs2_meta_inode_buffer(ip, );
--
1.5.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] affs: be*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]> replace all: big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) + expression_in_cpu_byteorder); with: beX_add_cpu(_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]> Cc: Roman Zippel <[EMAIL PROTECTED]> --- fs/affs/file.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/affs/file.c b/fs/affs/file.c index 6e0c939..95b48af 100644 --- a/fs/affs/file.c +++ b/fs/affs/file.c @@ -543,7 +543,7 @@ affs_extent_file_ofs(struct inode *inode, u32 newsize) if (boff + tmp > bsize || tmp > bsize) BUG(); memset(AFFS_DATA(bh) + boff, 0, tmp); - AFFS_DATA_HEAD(bh)->size = cpu_to_be32(be32_to_cpu(AFFS_DATA_HEAD(bh)->size) + tmp); + be32_add_cpu(_DATA_HEAD(bh)->size, tmp); affs_fix_checksum(sb, bh); mark_buffer_dirty_inode(bh, inode); size += tmp; @@ -686,7 +686,7 @@ static int affs_write_end_ofs(struct file *file, struct address_space *mapping, if (boff + tmp > bsize || tmp > bsize) BUG(); memcpy(AFFS_DATA(bh) + boff, data + from, tmp); - AFFS_DATA_HEAD(bh)->size = cpu_to_be32(be32_to_cpu(AFFS_DATA_HEAD(bh)->size) + tmp); + be32_add_cpu(_DATA_HEAD(bh)->size, tmp); affs_fix_checksum(sb, bh); mark_buffer_dirty_inode(bh, inode); written += tmp; -- 1.5.3.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] infiniband: be*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]> replace all: big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) + expression_in_cpu_byteorder); with: beX_add_cpu(_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]> Cc: Roland Dreier <[EMAIL PROTECTED]> Cc: Sean Hefty <[EMAIL PROTECTED]> Cc: Hal Rosenstock <[EMAIL PROTECTED]> --- drivers/infiniband/hw/mthca/mthca_cq.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/infiniband/hw/mthca/mthca_cq.c b/drivers/infiniband/hw/mthca/mthca_cq.c index 6bd9f13..1e1e336 100644 --- a/drivers/infiniband/hw/mthca/mthca_cq.c +++ b/drivers/infiniband/hw/mthca/mthca_cq.c @@ -473,7 +473,7 @@ static void handle_error_cqe(struct mthca_dev *dev, struct mthca_cq *cq, if (!(new_wqe & cpu_to_be32(0x3f)) || (!cqe->db_cnt && dbd)) return; - cqe->db_cnt = cpu_to_be16(be16_to_cpu(cqe->db_cnt) - dbd); + be16_add_cpu(>db_cnt, -dbd); cqe->wqe = new_wqe; cqe->syndrome = SYNDROME_WR_FLUSH_ERR; -- 1.5.3.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
