* Re: [PATCH] Fix build errors with strict MM checking
2007-06-12 23:16 [PATCH] Fix build errors with strict MM checking Martin Habets
@ 2007-06-12 23:23 ` David Miller
2007-06-14 19:19 ` Martin Habets
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2007-06-12 23:23 UTC (permalink / raw)
To: sparclinux
From: Martin Habets <errandir_news@mph.eclipse.co.uk>
Date: Wed, 13 Jun 2007 00:16:00 +0100
> @@ -2137,11 +2137,11 @@ static unsigned long srmmu_pte_to_pgoff(
>
> static pgprot_t srmmu_pgprot_noncached(pgprot_t prot)
> {
> - prot &= ~__pgprot(SRMMU_CACHE);
> + pgprot_val(prot) &= ~SRMMU_CACHE;
>
> return prot;
> }
This patch doesn't apply cleanly, and it's because of this hunk.
The patch hunk says that there should be "11" lines in both
the before and after, but there are only 7.
Please try to apply the patches your submit unless you
can ensure that all of your patches are perfect without
checking :-)
Also, I wouldn't run a kernel with strict MM checking on, it's
at best a compile time check and it causes the code output a lot,
PTE's and PGD's etc. get passed on the stack when given as
parameters to functions instead of in registers, and many
optimizations get disabled in the compiler because these
things are now structures instead of simple integers.
That's why it's off by default.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] Fix build errors with strict MM checking
2007-06-12 23:16 [PATCH] Fix build errors with strict MM checking Martin Habets
2007-06-12 23:23 ` David Miller
@ 2007-06-14 19:19 ` Martin Habets
2007-06-15 9:11 ` William Lee Irwin III
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Martin Habets @ 2007-06-14 19:19 UTC (permalink / raw)
To: sparclinux
On Tue, Jun 12, 2007 at 04:23:15PM -0700, David Miller wrote:
> From: Martin Habets <errandir_news@mph.eclipse.co.uk>
> Date: Wed, 13 Jun 2007 00:16:00 +0100
>
> > @@ -2137,11 +2137,11 @@ static unsigned long srmmu_pte_to_pgoff(
> >
> > static pgprot_t srmmu_pgprot_noncached(pgprot_t prot)
> > {
> > - prot &= ~__pgprot(SRMMU_CACHE);
> > + pgprot_val(prot) &= ~SRMMU_CACHE;
> >
> > return prot;
> > }
>
> This patch doesn't apply cleanly, and it's because of this hunk.
>
> The patch hunk says that there should be "11" lines in both
> the before and after, but there are only 7.
>
> Please try to apply the patches your submit unless you
> can ensure that all of your patches are perfect without
> checking :-)
Sorry for that. Not sure what happened, no other code changes in that hunk.
New diff below.
> Also, I wouldn't run a kernel with strict MM checking on, it's
> at best a compile time check and it causes the code output a lot,
> PTE's and PGD's etc. get passed on the stack when given as
> parameters to functions instead of in registers, and many
> optimizations get disabled in the compiler because these
> things are now structures instead of simple integers.
>
> That's why it's off by default.
I understand it slows down things a lot. Do you mean it has no
run-time value when debugging suspected MM problems? I do get
different output: unhandled paging request with strict MM checking
versus a DMA error without.
Now for the new patch attempt:
Turning on STRICT_MM_TYPECHECKS in include/asm/page.h causes some
build errors for sparc32. This patch against 2.6.21 fixes these.
Martin
Signed-off-by: Martin Habets <errandir_news@mph.eclipse.co.uk>
--- linux/arch/sparc/mm/srmmu.c.orig 2007-06-06 23:26:13.000000000 +0100
+++ linux/arch/sparc/mm/srmmu.c 2007-06-14 20:03:47.000000000 +0100
@@ -226,10 +226,10 @@
/* XXX should we hyper_flush_whole_icache here - Anton */
static inline void srmmu_ctxd_set(ctxd_t *ctxp, pgd_t *pgdp)
-{ srmmu_set_pte((pte_t *)ctxp, (SRMMU_ET_PTD | (__nocache_pa((unsigned long) pgdp) >> 4))); }
+{ srmmu_set_pte((pte_t *)ctxp, __pte(SRMMU_ET_PTD | (__nocache_pa((unsigned long) pgdp) >> 4))); }
static inline void srmmu_pgd_set(pgd_t * pgdp, pmd_t * pmdp)
-{ srmmu_set_pte((pte_t *)pgdp, (SRMMU_ET_PTD | (__nocache_pa((unsigned long) pmdp) >> 4))); }
+{ srmmu_set_pte((pte_t *)pgdp, __pte(SRMMU_ET_PTD | (__nocache_pa((unsigned long) pmdp) >> 4))); }
static void srmmu_pmd_set(pmd_t *pmdp, pte_t *ptep)
{
@@ -238,7 +238,7 @@
ptp = __nocache_pa((unsigned long) ptep) >> 4;
for (i = 0; i < PTRS_PER_PTE/SRMMU_REAL_PTRS_PER_PTE; i++) {
- srmmu_set_pte((pte_t *)&pmdp->pmdv[i], SRMMU_ET_PTD | ptp);
+ srmmu_set_pte((pte_t *)&pmdp->pmdv[i], __pte(SRMMU_ET_PTD | ptp));
ptp += (SRMMU_REAL_PTRS_PER_PTE*sizeof(pte_t) >> 4);
}
}
@@ -250,7 +250,7 @@
ptp = page_to_pfn(ptep) << (PAGE_SHIFT-4); /* watch for overflow */
for (i = 0; i < PTRS_PER_PTE/SRMMU_REAL_PTRS_PER_PTE; i++) {
- srmmu_set_pte((pte_t *)&pmdp->pmdv[i], SRMMU_ET_PTD | ptp);
+ srmmu_set_pte((pte_t *)&pmdp->pmdv[i], __pte(SRMMU_ET_PTD | ptp));
ptp += (SRMMU_REAL_PTRS_PER_PTE*sizeof(pte_t) >> 4);
}
}
@@ -2137,7 +2137,7 @@
static pgprot_t srmmu_pgprot_noncached(pgprot_t prot)
{
- prot &= ~__pgprot(SRMMU_CACHE);
+ pgprot_val(prot) &= ~SRMMU_CACHE;
return prot;
}
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] Fix build errors with strict MM checking
2007-06-12 23:16 [PATCH] Fix build errors with strict MM checking Martin Habets
2007-06-12 23:23 ` David Miller
2007-06-14 19:19 ` Martin Habets
@ 2007-06-15 9:11 ` William Lee Irwin III
2007-06-15 16:49 ` Martin Habets
2007-06-15 17:22 ` William Lee Irwin III
4 siblings, 0 replies; 6+ messages in thread
From: William Lee Irwin III @ 2007-06-15 9:11 UTC (permalink / raw)
To: sparclinux
On Thu, Jun 14, 2007 at 08:19:12PM +0100, Martin Habets wrote:
> I understand it slows down things a lot. Do you mean it has no
> run-time value when debugging suspected MM problems? I do get
> different output: unhandled paging request with strict MM checking
> versus a DMA error without.
> Now for the new patch attempt:
> Turning on STRICT_MM_TYPECHECKS in include/asm/page.h causes some
> build errors for sparc32. This patch against 2.6.21 fixes these.
Unhandled paging request vs. DMA errors? This sounds ominous. What
CPU type?
-- wli
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Fix build errors with strict MM checking
2007-06-12 23:16 [PATCH] Fix build errors with strict MM checking Martin Habets
` (2 preceding siblings ...)
2007-06-15 9:11 ` William Lee Irwin III
@ 2007-06-15 16:49 ` Martin Habets
2007-06-15 17:22 ` William Lee Irwin III
4 siblings, 0 replies; 6+ messages in thread
From: Martin Habets @ 2007-06-15 16:49 UTC (permalink / raw)
To: sparclinux
On Fri, Jun 15, 2007 at 02:11:49AM -0700, William Lee Irwin III wrote:
> On Thu, Jun 14, 2007 at 08:19:12PM +0100, Martin Habets wrote:
> > I understand it slows down things a lot. Do you mean it has no
> > run-time value when debugging suspected MM problems? I do get
> > different output: unhandled paging request with strict MM checking
> > versus a DMA error without.
> > Now for the new patch attempt:
> > Turning on STRICT_MM_TYPECHECKS in include/asm/page.h causes some
> > build errors for sparc32. This patch against 2.6.21 fixes these.
>
> Unhandled paging request vs. DMA errors? This sounds ominous. What
> CPU type?
This is a supersparc UP machine. It only happens if I use an SMP kernel,
and only on one machine out of 6 SS10/SS20 UP/SMP boxes.
The special thing about this machine is that is has 320MB memory, versus
128MB or less on the others. And it has 2 disks, but one other box has
2 disks as well.
I got 2 ross CPUs yesterday. With those no problem so far. Guess I'll
ignore it for now, maybe stress testing will make it pop up again on
one of the supersparcs.
Still, I would like to learn a debugging aproach if/when that time
comes, the oops is below (sorry Dave).
In general I'm very content with the SMP performance on 2.6.21.
--
Martin
esp: esp0, regs[fd025000:fd00f000] irq[36]
esp: esp0, regs[fd025000:fd00f000] irq[36]
esp: esp0 is a FAS100A, 40 MHz (ccf=0), SCSI ID 7
esp: esp0 is a FAS100A, 40 MHz (ccf=0), SCSI ID 7
scsi0 : esp
scsi0 : esp
do_sparc_fault: pgd:1
do_sparc_fault: pgd:1
do_sparc_fault: pmd:1 pmd_k:1
do_sparc_fault: pmd:1 pmd_k:1
Unable to handle kernel paging request at virtual address fff0d000
Unable to handle kernel paging request at virtual address fff0d000
tsk->{mm,active_mm}->context = ffffffff
tsk->{mm,active_mm}->context = ffffffff
tsk->{mm,active_mm}->pgd = fc000000
tsk->{mm,active_mm}->pgd = fc000000
\|/ ____ \|/
\|/ ____ \|/
"@'/ ,. \`@"
"@'/ ,. \`@"
/_| \__/ |_\
/_| \__/ |_\
\__U_/
\__U_/
swapper(1): Oops [#1]
swapper(1): Oops [#1]
PSR: 40400fc6 PC: f0122710 NPC: f0122714 Y: 00000000 Not tainted
PSR: 40400fc6 PC: f0122710 NPC: f0122714 Y: 00000000 Not tainted
PC: <esp_maybe_execute_command+0x32c/0x63c>
PC: <esp_maybe_execute_command+0x32c/0x63c>
%G: 00000000 ffffff80 00000000 00000001 00000006 f000f000 f0afe000 07ffff00
%G: 00000000 ffffff80 00000000 00000001 00000006 f000f000 f0afe000 07ffff00
%O: fbc75af0 fbc5d7a0 00000001 00000002 f00f31f0 fbc75b08 f0aff540 f0122610
%O: fbc75af0 fbc5d7a0 00000001 00000002 f00f31f0 fbc75b08 f0aff540 f0122610
RPC: <esp_maybe_execute_command+0x22c/0x63c>
RPC: <esp_maybe_execute_command+0x22c/0x63c>
%L: f0b3da00 fff0d000 fbc76cc0 fbc75b38 00000000 00000000 fbc75000 fbc68690
%L: f0b3da00 fff0d000 fbc76cc0 fbc75b38 00000000 00000000 fbc75000 fbc68690
%I: fbc75af0 fbc5d7a0 00000010 fbc71ba0 12000000 00000000 f0aff5a8 f0122c10
%I: fbc75af0 fbc5d7a0 00000010 fbc71ba0 12000000 00000000 f0aff5a8 f0122c10
Caller[f0122c10]Caller[f0122c10]: esp_queuecommand+0x80/0xc8
: esp_queuecommand+0x80/0xc8
Caller[f01135fc]Caller[f01135fc]: scsi_dispatch_cmd+0x19c/0x2b0
: scsi_dispatch_cmd+0x19c/0x2b0
Caller[f0119374]Caller[f0119374]: scsi_request_fn+0x214/0x394
: scsi_request_fn+0x214/0x394
Caller[f00e1958]Caller[f00e1958]: __generic_unplug_device+0x34/0x40
: __generic_unplug_device+0x34/0x40
Caller[f00e2868]Caller[f00e2868]: blk_execute_rq_nowait+0x70/0x94
: blk_execute_rq_nowait+0x70/0x94
Caller[f00e28f0]Caller[f00e28f0]: blk_execute_rq+0x64/0x9c
: blk_execute_rq+0x64/0x9c
Caller[f0117ce0]Caller[f0117ce0]: scsi_execute+0xc4/0xd8
: scsi_execute+0xc4/0xd8
Caller[f0117d50]Caller[f0117d50]: scsi_execute_req+0x5c/0x90
: scsi_execute_req+0x5c/0x90
Caller[f011aaa0]Caller[f011aaa0]: scsi_probe_and_add_lun+0x18c/0x9c4
: scsi_probe_and_add_lun+0x18c/0x9c4
Caller[f011b5b8]Caller[f011b5b8]: __scsi_scan_target+0xb0/0x5e4
: __scsi_scan_target+0xb0/0x5e4
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] Fix build errors with strict MM checking
2007-06-12 23:16 [PATCH] Fix build errors with strict MM checking Martin Habets
` (3 preceding siblings ...)
2007-06-15 16:49 ` Martin Habets
@ 2007-06-15 17:22 ` William Lee Irwin III
4 siblings, 0 replies; 6+ messages in thread
From: William Lee Irwin III @ 2007-06-15 17:22 UTC (permalink / raw)
To: sparclinux
On Fri, Jun 15, 2007 at 02:11:49AM -0700, William Lee Irwin III wrote:
>> Unhandled paging request vs. DMA errors? This sounds ominous. What
>> CPU type?
On Fri, Jun 15, 2007 at 05:49:07PM +0100, Martin Habets wrote:
> This is a supersparc UP machine. It only happens if I use an SMP kernel,
> and only on one machine out of 6 SS10/SS20 UP/SMP boxes.
> The special thing about this machine is that is has 320MB memory, versus
> 128MB or less on the others. And it has 2 disks, but one other box has
> 2 disks as well.
> I got 2 ross CPUs yesterday. With those no problem so far. Guess I'll
> ignore it for now, maybe stress testing will make it pop up again on
> one of the supersparcs.
> Still, I would like to learn a debugging aproach if/when that time
> comes, the oops is below (sorry Dave).
> In general I'm very content with the SMP performance on 2.6.21.
Usually it's the HyperSPARC's with trouble. I've bricked the sun4m SS20
I've got plugged into the AP9225's and Cisco 2511 somehow (probably the
big power surge that fried everything else, too), so I'll have to dig
for a fresh chassis. Disks OTOH I'm not quite as likely to have around.
It's oopsing on the DVMA virtual region, so debugging techniques are
likely to consist of logging DVMA-relevant MMU manipulations and
fishing for things like protections being wrong, the call stack for
offending calls, (esp. the ones right before you oops) and so on, and
hoping that timings aren't relevant (if they are, there are different,
more complicated things to try). There are a lot of XXX's/FIXME's in
and around IOMMU handling so it may end up related to some of that as
well, though I kind of doubt it.
-- wli
^ permalink raw reply [flat|nested] 6+ messages in thread