ia64/156900: ia64 -current r221488 panic if kern.maxssiz=536748033 or above

[Anton Shterenlikht]

>Number:         156900
>Category:       ia64
>Synopsis:       ia64 -current r221488 panic if kern.maxssiz=536748033 or above
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-ia64
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon May 09 09:00:18 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:     Anton Shterenlikht
>Release:        FreeBSD 9.0-CURRENT ia64
>Organization:
University of Bristol, UK
>Environment:
System: FreeBSD mech-cluster241.men.bris.ac.uk 9.0-CURRENT FreeBSD 9.0-CURRENT #3 r221488: Thu May 5 12:39:44 BST 2011 root at mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64


	
>Description:

On ia64 (Madison and Madison II) starting at least with
r221488, I get this panic on boot if kern.maxssiz=536748033
or above:

Trying to mount root from ufs:/dev/da0p2 [rw]...
panic: mutex Giant owned at /usr/src/sys/kern/kern_exit.c:125
cpuid = 0
KDB: enter: panic
[ thread pid 1 tid 100001 ]
Stopped at      kdb_enter+0x92: [I2]    addl r14=0xffffffffffe236c8,gp ;;
db>
db> show thread
Thread 100001 at 0xe000000010fc8000:
 proc (pid 1): 0xe000000010fc2000
 name: kernel
 stack: 0xa0000000ec748000-0xa0000000ec74ffff
 flags: 0x10004  pflags: 0
 state: RUNNING (CPU 0)
 priority: 84
 container lock: sched lock 0 (0x9ffc000000b04900)
db>
db> bt
Tracing pid 1 tid 100001 td 0xe000000010fc8000
kdb_enter(0x9ffc0000009e1f00, 0x9ffc0000009e1f00, 0x9ffc0000004063d0, 0x793) at kdb_enter+0x92
panic(0x9ffc0000009e0278, 0x9ffc0000009e05c8, 0x9ffc0000009db7b8, 0x7d) at panic+0x2e0
_mtx_assert(0x9ffc000000aed898, 0x0, 0x9ffc0000009db7b8, 0x7d, 0x9ffc0000003ada10) at
+_mtx_assert+0x200
exit1(0xe000000010fc8000, 0x6, 0x152e, 0x375) at exit1+0x40
kern_execve(0xe000000010fc8000, 0xa0000000ec74f4e0, 0x9ffc0000009db658, 0x0, 0xa0000000ec74f420) at
+kern_execve+0x1ed0
execve(0xe000000010fc8000, 0xa0000000ec74f538, 0x9ffc000000376c20, 0x91a, 0x91a) at execve+0x60
start_init(0x7fffffffffffffd8, 0x7ffffffffffffff2, 0x9ffc000000a7a7d2, 0x9ffc000000a7a7c8) at
+start_init+0x4a0
fork_exit(0x9ffc000000a2b5d0, 0x0, 0xa0000000ec74f550) at fork_exit+0x110
enter_userland() at enter_userland
db>


If the limit is reduced by 1 to kern.maxssiz=536748032,
the boot goes ahead fine.



	
>How-To-Repeat:

1. update to r221488.
2. set kern.maxssiz=536748033 (either in /boot/loader.conf
or in the loader directly).
3. boot

	
>Fix:

Marcel's analysis of the problem (in case anybody
else it looking at this):

*quote*
On ia64 each process has 2 stacks. There's the traditional
memory stack that grows downwards and the there's the RSE
register stack that grows upwards.

Before my change, the RSE stack started at offset 0 in
region 4 (=0x8000000000000000) and the register stack
started close to the top in region 4 (=9fffffffffffxxxx).

After my change, region 4 belongs to the kernel and the
last region of the process is region 3. The register stack
stayed at the top of the region (=0x7fffffffffffxxxx), but
I moved the RSE register stack closer to the register stack:
        (USRSTACK - (2 * MAXSSIZ) - PAGE_SIZE)

It's this change that causes the problem. The maxssiz is
effectively bounded by the distance between the RSE stack
(bottom) and the memory stack (top). This used to be close
(1<<61), but is now close to (1<<29) (~512MB = 536870912)
*end quote*


	


>Release-Note:
>Audit-Trail:
>Unformatted: