From: nasokan@yoho.uwaterloo.ca (Asokan)
Subject: Re: System V IPC on a Sun MP running 4.1.2
Organization: University of Waterloo
Date: Thu, 15 Oct 1992 17:49:18 GMT

In article <92Oct14.131924edt.105820-2@yoho.uwaterloo.ca> I wrote:
[...]
>doug@perry.berkeley.edu (Doug Neuhauser) confirmed this and
>sent me a writeup he had received from his field engineer
>that describes how to check if a given kernel has this problem.
[...]

Since several people have requested for this write-up, I am
posting this.  Remember that this is not an official
Sun document.  Use it at your own risk.

Based on this, I wrote a quick script to sanity-check a kernel.
I'll post that next.

- Asokan

---

****** UNOFFICIAL DOCUMENT ******

From: doug@perry.berkeley.edu (Doug Neuhauser)
To: nasokan@yoho.uwaterloo.ca
Subject: Re: System V IPC on a Sun MP running 4.1.2
Newsgroups: comp.sys.sun.admin

I received the following from my FE.


Here is a more complete bug detection/workaround writeup:



To determine if you are running into this problem:

        1. Symptoms: machine hang, l1-a and pulling the keyboard are
                ineffective, cannot ping or rlogin, LED's on CPU
                ineffective, cannot ping or rlogin, LED's on CPU
                are frozen solid.

                        -or-

          The machine crashes with a watchdog reset.  The ctrace
          output indicates that the crash occured in either
          _ross_vac_ctxflush or _srmmu_mmu_flushctx and the pc
          is on a page boundary.

        2. Run nm -n on the kernel that is running when the hang
occurs.
                ie. nm -n /vmunix > /tmp/nm.out
        3. Examine the contents of the file in an editor.
                ie. vi /tmp/nm.out
 
        4. Search for the following strings:
                _ross_vac_ctxflush
                        and
                _srmmu_mmu_flushctx
        5. For each string, save the hex number to the left of the
                string. Also, save the hex number that follows
                on the next line.
 
                When you are finished you should have something that
                looks like:
 
                f8111f7c T _ross_vac_ctxflush
                f8112020 T _ross_vac_rgnflush
 
                f81114e0 T _srmmu_mmu_flushctx
                f8111540 T _srmmu_mmu_flushrgn
 
        6. For each set of strings check to see if _ross_vac_ctxflush
                or _srmmu_mmu_flushctx cross a page boundary:
 
                One page is 0x1000 bytes.
 
        Note: If you are unsure of how to do this, follow these
        steps....
                a. # bc
                     ibase=16   *set things up for hex numbers *
                     <hex number of _ross_vac_ctxflush> / 1000
                     * bc prints out the result here *
                     <hex number the routine that follows> / 1000
                     * bc prints out the result here *
 
                b. If the two results are the same then the routine is
                   not crossing a page boundary. If they differ, then
                   the routine does cross a page boundary.
 
                c. For example:
                        capo 28: bc
                        ibase=16
                        F8111F7C/1000   *note:hex #s must be in CAPS*
                        1016081         * result *
                        F8112020/1000
                        1016082         * result *
 
                   The results are different so this routine crosses a
                   page boundary (the page boundary is f8112000).
 
        7. If neither _ross_vac_ctxflush or _srmmu_mmu_flushctx are
                crossing a page boundary, then you are not running
into
                this bug.
 
 
The workaround:
 
        1. Add or remove an option from your kernel config file and
        rebuild your kernel.  This will have the effect of moving the
        location of the routine in question so that it no longer
        straddles a page boundary.  Usually, it is only necessary to
        add/remove one option.
 
 
        one key item to have with all this is that the failure is
        happening when we cross a page boundrey while executing
        inside a borrowed context; this implies that the mappings
        for the borrowed context are not "all there".
 
        Whether this happens or not is going to be highly dependent on
        whether any of the bits of assembly code where we borrow
        contexts happen to cross page boundreys while the mmu is
        translating in the borrowed context.

****** UNOFFICIAL DOCUMENT ******