headers
Izumi Tsutsui | 1 Sep 2006 06:06
Picon
Gravatar

Re: wired entry count problem on sun3x pmap

jeremy <at> NetBSD.org wrote:

> Izumi, thank you very much for your hard work finding this bug, and 
> especially for working to keep the comments in sync!

You're welcome. Actually whole comments in sun3x/pmap.c
are quite useful :-)

Unfortunately, after ~15 hours build on pkgsrc/lang/perl5
my 3/80 still got "panic: get_c_table: out of C tables." panic.
I'll try to see if it's caused by real shortage (by fragments)
or other leakage.
---
Izumi Tsutsui
Permalink | Reply | 6 comments |
headers
Izumi Tsutsui | 5 Sep 2006 15:29
Picon
Gravatar

Re: wired entry count problem on sun3x pmap

I wrote:

> Unfortunately, after ~15 hours build on pkgsrc/lang/perl5
> my 3/80 still got "panic: get_c_table: out of C tables." panic.
> I'll try to see if it's caused by real shortage (by fragments)
> or other leakage.

I added some debug printf()s on C table shortage, and then
more than a half of tables look still unused on the panic.
So it looks the TAILQ structure corruption.
Actually, the panic sometime happened during bootstrap,
right after ntpd was started. (mlockall() might trigger it?)

I wonder if we have to protect these TAILQ ops against A, B and C
tables by splvm()/splx() pairs... Comments?
---
Izumi Tsutsui
Permalink | Reply | 5 comments |
headers
Jason Thorpe | 5 Sep 2006 19:01

Re: wired entry count problem on sun3x pmap


On Sep 5, 2006, at 6:29 AM, Izumi Tsutsui wrote:

> I wrote:
>
>> Unfortunately, after ~15 hours build on pkgsrc/lang/perl5
>> my 3/80 still got "panic: get_c_table: out of C tables." panic.
>> I'll try to see if it's caused by real shortage (by fragments)
>> or other leakage.
>
> I added some debug printf()s on C table shortage, and then
> more than a half of tables look still unused on the panic.
> So it looks the TAILQ structure corruption.
> Actually, the panic sometime happened during bootstrap,
> right after ntpd was started. (mlockall() might trigger it?)
>
> I wonder if we have to protect these TAILQ ops against A, B and C
> tables by splvm()/splx() pairs... Comments?

If those tables can be allocated as a side-effect of calling malloc 
(9), then yes.

-- thorpej
Permalink | Reply | 4 comments |
headers
Izumi Tsutsui | 11 Sep 2006 17:30
Picon
Gravatar

Re: wired entry count problem on sun3x pmap

thorpej <at> shagadelic.org wrote:

> > I added some debug printf()s on C table shortage, and then
> > more than a half of tables look still unused on the panic.
> > So it looks the TAILQ structure corruption.
> > Actually, the panic sometime happened during bootstrap,
> > right after ntpd was started. (mlockall() might trigger it?)
> >
> > I wonder if we have to protect these TAILQ ops against A, B and C
> > tables by splvm()/splx() pairs... Comments?
> 
> If those tables can be allocated as a side-effect of calling malloc 
> (9), then yes.

These TAILQs are modified in pmap_enter(), pmap_unwire() and
pmap_remove(). In this case, should these functions be protected
by splvm()?
(3/80 is too slow to confirm how patches work... :-)
---
Izumi Tsutsui
Permalink | Reply | 3 comments |
headers
Jason Thorpe | 11 Sep 2006 17:36

Re: wired entry count problem on sun3x pmap


On Sep 11, 2006, at 8:30 AM, Izumi Tsutsui wrote:

> These TAILQs are modified in pmap_enter(), pmap_unwire() and
> pmap_remove(). In this case, should these functions be protected
> by splvm()?

Nope, you should be OK without splvm() then.

> (3/80 is too slow to confirm how patches work... :-)
> ---
> Izumi Tsutsui

-- thorpej
Permalink | Reply | 2 comments |
headers
Izumi Tsutsui | 13 Sep 2006 16:33
Picon
Gravatar

Re: wired entry count problem on sun3x pmap

thorpej <at> shagadelic.org wrote:

> > These TAILQs are modified in pmap_enter(), pmap_unwire() and
> > pmap_remove(). In this case, should these functions be protected
> > by splvm()?
> 
> Nope, you should be OK without splvm() then.

Thanks. Actually sprinkled splvm() didn't help at all.

Now I realize we should handle unwiring page case not only
in pmap_remove_[abc]() but also free_[abc]_table() functions.
(patch attached)

I'll try to see how pkgsrc perl5 build goes..
(it will take 20~40 hours again ;-)
---
Izumi Tsutsui

Index: arch/sun3/sun3x/pmap.c
===================================================================
RCS file: /cvsroot/src/sys/arch/sun3/sun3x/pmap.c,v
retrieving revision 1.90
diff -u -r1.90 pmap.c
--- arch/sun3/sun3x/pmap.c	10 May 2006 06:24:03 -0000	1.90
+++ arch/sun3/sun3x/pmap.c	13 Sep 2006 12:47:25 -0000
 <at>  <at>  -1222,6 +1222,7  <at>  <at> 
 	 * pool.  That is a job for the function that called us.
 	 */
 	if (tbl->at_parent) {
(Continue reading)

Permalink | Reply | 1 comment |
headers
Izumi Tsutsui | 15 Sep 2006 19:52
Picon
Gravatar

Re: wired entry count problem on sun3x pmap

I wrote:

> I'll try to see how pkgsrc perl5 build goes..
> (it will take 20~40 hours again ;-)

After ~54 hours, perl5 has been built and installed successfully
with no assertion failure on GENERIC3X with DIAGNOSTIC kernel :-)

I'll commit the change soon.
(maybe netbsd-3 needs this fix)
---
Izumi Tsutsui
Permalink | Reply | 0 comments |
headers
Izumi Tsutsui | 1 Oct 2006 09:13
Picon
Gravatar

sun3 bus_space(9) support added

In article <060606082156.M0114425 <at> mirage.ceres.dti.ne.jp>
I wrote:

> IIUC, the abuse is in sun3/sun3/vme.c. It uses cf_unit to specify
> VME bus types. Of cource sun3 should switch to the MI vme driver,
> but we have to implement bus_space(9) for sun3 first.
> It should be trivial (see sun68k/sun68k/bus.c), but...

As seen on source-changes, finally I've committed changes which
add bus_space(9) support on sun3 port with existing sun68k/bus.c.

http://mail-index.netbsd.org/source-changes/2006/10/01/0003.html

There is no device drivers which have been changed to use these
bus_space(9) API yet, but this is the (late) first step to switch
sun3 port to more MI drivers like sys/dev/sun and sys/dev/vme etc.
MD bus_dma(9) backends are not implemented yet, but it should be trivial..

I'll switch homegrown todclock functions (clock and oclock) to
MI intersil7170(4) and mk48txx(4) first.
(is there anyone who can test it on 3/4xx? ;-)
---
Izumi Tsutsui
Permalink | Reply | 501 comments |
headers
Izumi Tsutsui | 1 Oct 2006 10:58
Picon
Gravatar

intersil7170(4) cleanup

Hi,

I'd like to commit the following changes against the intersil7170(4)
TOD clock driver used on old sun3/sun4 machines:

- make intersil7170_softc more generic and allocate it during autoconf(9)
  (rather than MALLOC(9) in attachment)
- put todr_chip_handle_t, year0 value, and the century adjustment flag
  into the intersil7170_softc
- change the attachment function to just take the softc like mk48txx(4)
- split sys/dev/ic/intersil7170.h into intersil7170reg.h and intersil7170var.h
- cleanup some macro

I'll also change sun3 port to use these MI todr drivers.

Any comments (or reports on such ancient machines) are appricated.
(only tested on TME which emulates sun3/120)
---
Izumi Tsutsui

Index: share/man/man4/intersil7170.4
===================================================================
RCS file: /cvsroot/src/share/man/man4/intersil7170.4,v
retrieving revision 1.9
diff -u -r1.9 intersil7170.4
--- share/man/man4/intersil7170.4	27 Jun 2003 18:32:02 -0000	1.9
+++ share/man/man4/intersil7170.4	1 Oct 2006 06:11:44 -0000
 <at>  <at>  -34,22 +34,23  <at>  <at> 
 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 .\" POSSIBILITY OF SUCH DAMAGE.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nathan J. Williams | 1 Oct 2006 14:53

Re: sun3 bus_space(9) support added

Izumi Tsutsui <tsutsui <at> ceres.dti.ne.jp> writes:

> I'll switch homegrown todclock functions (clock and oclock) to
> MI intersil7170(4) and mk48txx(4) first.
> (is there anyone who can test it on 3/4xx? ;-)

sigh. of course this comes up about a month after I trashed my last
VME-card-cage system.....

        - Nathan
Permalink | Reply | 501 comments |

Gmane