Re: User mode address error problems on 7763

Matt Fleming
2009-09-15T08:39:44Z

On Mon, Sep 14, 2009 at 08:54:31AM -0500, Dale Larson wrote:
> On Mon, Sep 14, 2009 at 8:14 AM, Matt Fleming <matt@console-pimps.org> wrote:
>
> >There was an issue a few weeks ago
> > where we were unneccessarily reporting unaligned fix ups. It was fixed
> > by this commit,
>
> I think later changes may have changed that. There are now a couple
> global variables used to control kernel and user messages having to do
> with address fixups in traps_32.c.:
>
> /* bitfield: 1: warn 2: fixup 4: signal -> combinations 2|4 && 1|2|4
> are not valid! */
> static int se_usermode = 3;
> /* 0: no warning 1: print a warning message */
> static int se_kernmode_warn = 0; /* WAS 1 - DLL20090914 */
>

Ah, OK, I missed that change.

>
> Log of kernel run:
>

[...]

> Starting network...
> ip: RTNETLINK answers: File exists
> [ 17.040000] Unaligned userspace access in "sh" pid\x189
> pc=0x295583d0 ins=0x60b2
> [ 17.044000] Fixing up unaligned userspace access in "sh" pid\x189
> pc=0x295583d0 ins=0x60b2
> [ 17.048000] Sending SIGBUS to "sh" due to unaligned access (PC
> a0042955 PR 295583da)
> Starting dropbear sshd: generating rsa key... generating dsa key... OK
> [ 45.608000] Unaligned userspace access in "syslogd" pid\x199
> pc=0x295583d0 ins=0x60b2
> [ 45.612000] Fixing up unaligned userspace access in "syslogd"
> pid\x199 pc=0x295583d0 ins=0x60b2
> [ 45.624000] Sending SIGBUS to "syslogd" due to unaligned access (PC
> a0042955 PR 295583da)
>

OK, these are unexpected fixups and similar to the issues I've been
seeing. The current train of thought is that these unaligned accesses
are a symptom of having aliases in the D-cache. I've been trawling
through the cache/tlb code for SH4 and so far haven't found the bug.

As a little experiment, could you try bumping the page size from 4K to
8K and see if the unaligned accesses go away? If they are caused by
D-cache aliasing, in theory, they should disappear with 8K pages.

The option in menuconfig is under,

System type --->
Memory management options --->
Kernel page size --->

> [ 108.736000] ------------[ cut here ]------------
> [ 108.736000] Kernel BUG at 8804492e [verbose debug info unavailable]
> [ 108.736000] Kernel BUG: 003e [#1]
> [ 108.736000]
> [ 108.736000] Pid : 198, Comm: sh
> [ 108.736000] CPU : 0 Not tainted (2.6.31-rc9 #5)
> [ 108.736000]
> [ 108.736000] PC is at cache_alloc_refill+0xc2/0x39c
> [ 108.736000] PR is at kmem_cache_alloc+0x52/0xb0
> [ 108.736000] PC : 8804492e SP : 8f903e94 SR : 400080f1 TEA : 00485a14
> [ 108.736000] R0 : 00000023 R1 : 0000002e R2 : 0000002e R3 : 8f8e2e48
> [ 108.736000] R4 : 00000010 R5 : 8f8029a0 R6 : 8f8e2000 R7 : 0000002f
> [ 108.736000] R8 : 8f8029a8 R9 : 8f809400 R10 : 8f8029b0 R11 : 8f800a20
> [ 108.736000] R12 : 0000000f R13 : 00000001 R14 : 8f903e94
> [ 108.736000] MACH: 00000000 MACL: 00000d74 GBR : 00000000 PR : 88044d2a
> [ 108.736000]
> [ 108.736000] Call trace:
> [ 108.736000] [<88044d2a>] kmem_cache_alloc+0x52/0xb0
> [ 108.736000] [<88011790>] dup_mm+0x150/0x2cc
> [ 108.736000] [<88011e64>] copy_process+0x518/0xa9c
> [ 108.736000] [<880bc614>] memcpy+0x0/0x28c
> [ 108.736000] [<880124d6>] do_fork+0xee/0x250
> [ 108.736000] [<88003bac>] sys_fork+0x0/0x28
> [ 108.736000] [<88003bc8>] sys_fork+0x1c/0x28
> [ 108.736000] [<88003bac>] sys_fork+0x0/0x28
> [ 108.736000] [<88007226>] syscall_call+0xc/0x10
> [ 108.736000]
> [ 108.736000] Code:
> [ 108.736000] 88044928: mov.l @(28,r11), r1
> [ 108.736000] 8804492a: cmp/hs r1, r2
> [ 108.736000] 8804492c: bf 8804495a
> [ 108.736000] ->8804492e: trapa #62
> [ 108.736000] 88044930: bra 8804495c
> [ 108.736000] 88044932: mov r12, r4
> [ 108.736000] 88044934: mov.l @(16,r11), r3
> [ 108.736000] 88044936: mov.l @(20,r6), r1
> [ 108.736000] 88044938: mov.l @r9, r2
> [ 108.736000]
> [ 108.736000] Process: sh (pid: 198, stack limit = 8f902001)
> [ 108.736000] Stack: (0x8f903e94 to 0x8f904000)
> [ 108.736000] 3e80:
> 000000d0 000000d0 00000000
> [ 108.736000] 3ea0: 88044d2a 8f903ec0 8f95248c 8f8d5ba0 8f800a20
> 000000d0 00000001 00000000
> [ 108.736000] 3ec0: 88011790 8f903ed8 8f8fff44 8f8d5380 00000001
> 8f952470 8f952488 8f95247c
> [ 108.736000] 3ee0: 8f8d53b4 8f8d5bd4 88011e64 8f903f08 8f865900
> 8f867840 8f86793c 880bc614
> [ 108.736000] 3f00: fffffff4 00000000 8f865940 00000000 8f903fa4
> 7bdf09d8 00000011 8f867954
> [ 108.736000] 3f20: 00000000 8f44ec38 00000000 880124d6 8f903f58
> 00000000 00000000 00000011
> [ 108.736000] 3f40: 00000071 00000000 88003bac 00000000 00000000
> 00000000 00000000 8f903fa4
> [ 108.736000] 3f60: 7bdf09d8 00000000 00456fd0 10000000 00481e4c
> 88003bc8 8f903f9c ffffffff
> [ 108.736000] 3f80: 295da3b8 00000000 00000071 00000100 88003bac
> 00000000 00000000 88007226
> [ 108.736000] 3fa0: 7bdf09d8 00000002 00403c70 08000000 00000002
> 00485a00 00483234 00000000
> [ 108.736000] 3fc0: 00000004 00483234 00485a00 00000000 004847fd
> 295da3b8 ffffffff 7bdf09d8
> [ 108.736000] 3fe0: 7bdf09d8 29591782 0042403c 00000000 00000000
> 0000003e 000000c8 00000040
> [ 108.740000] ---[ end trace 0313ffa0cd7d6a7f ]---
>

Can you reliably reproduce this? A little tip when doing development is
to turn on Verbose BUG() reporting, which is located in the Kernel
Hacking menu. That'll give you a line and number in the source file.