headers
ITOH Yasufumi | 2 Nov 2002 16:30
Picon

Re: spontaneous reboot only once after power-up

[ port-sh3 added ]

I wrote (see http://mail-index.netbsd.org/port-dreamcast/2002/10/29/0000.html
for full text):

(on SH4 (Dreamcast))
> However, I have a weird problem.
> The kernel reboot at the context switching (tsleep(), kthread_create1()),
> only once after power-up.
> Load the kernel again, and it works without problems.

This is a immediate reset without panic message,
and I suspect it is a "TLB multiple hit" exception.

I happen to try following change and the problem disappear.
Here, we are clearing the TLB.  The original code clears TLB
via address array, and new code does it via data array 1.

Why this change is effective?
Is this a correct change?
Is the true problem elsewhere?

I placed the kernels
before change:
	ftp://ftp.netbsd.org/pub/NetBSD/misc/itohy/dreamcast/netbsd.397.gz
after change:
	ftp://ftp.netbsd.org/pub/NetBSD/misc/itohy/dreamcast/netbsd.398.gz
Note this is one byte change (modulo change in version numbers).

Regards,
(Continue reading)

Permalink | Reply | 14 comments |
headers
Izumi Tsutsui | 2 Nov 2002 18:30
Picon
Gravatar

Re: spontaneous reboot only once after power-up

In article <200211021530.gA2FUb914591 <at> pl374.nas911.nara.nttpc.ne.jp>
itohy <at> netbsd.org wrote:

> I happen to try following change and the problem disappear.
> Here, we are clearing the TLB.  The original code clears TLB
> via address array, and new code does it via data array 1.

I just take a look at SH4 programming manual, but
I guess if you use UTLB data array 1 to invalidate TLB entries
there are follow problems:
(1) it does not clear VPN
(2) it might break other bits (cacheable, writethrough etc.)

BTW, there is an errata about TLB usage for SH3:
http://www.hitachisemiconductor.com/sic/resource/japan/eng/pdf/mpumcu/ms/tnsh7291ae.pdf
According to this doc, it's better to wrote 0xf0000000 to VPN on
invalidating TLB entries to avoid an exception on TLB
(which might cause another bug of SH3).

I think SH4 does not have this bug, but I guess it's still better
to use 0xf0000000 for VPN on invalidating TLB via address array.
---
Izumi Tsutsui
tsutsui <at> ceres.dti.ne.jp
Permalink | Reply | 12 comments |
headers
ITOH Yasufumi | 3 Nov 2002 05:56
Picon

Re: spontaneous reboot only once after power-up

In article <200211021730.gA2HUZM06440 <at> mirage.ceres.dti.ne.jp>
tsutsui <at> ceres.dti.ne.jp writes:

> In article <200211021530.gA2FUb914591 <at> pl374.nas911.nara.nttpc.ne.jp>
> itohy <at> netbsd.org wrote:
> 
> > I happen to try following change and the problem disappear.
> > Here, we are clearing the TLB.  The original code clears TLB
> > via address array, and new code does it via data array 1.
> 
> I just take a look at SH4 programming manual, but
> I guess if you use UTLB data array 1 to invalidate TLB entries
> there are follow problems:
> (1) it does not clear VPN

I don't think it is a problem.
The V (valid) and D (dirty) bits are cleared by either way,
and the VPN shall not make sense if an entry is not valid
(if the MMU works as described).

> (2) it might break other bits (cacheable, writethrough etc.)

If a new entry is loaded by LDTLB instruction
all the fields will be overwritten, and I don't think
it is a problem (if the MMU works as described :-).

I tried some alternatives in sh4_tlb_invalidate_all():

(a) the code of my previous mail (works)
	for (e = 0; e < eend; e++) {
(Continue reading)

Permalink | Reply | 10 comments |
headers
Izumi Tsutsui | 3 Nov 2002 06:21
Picon
Gravatar

Re: spontaneous reboot only once after power-up

In article <200211030456.gA34u7h16089 <at> pl374.nas911.nara.nttpc.ne.jp>
itohy <at> netbsd.org wrote:

> > (1) it does not clear VPN
> 
> I don't think it is a problem.
> The V (valid) and D (dirty) bits are cleared by either way,
> and the VPN shall not make sense if an entry is not valid

Yeah, but I just think it is safe and is the difference
between AA and DA1.

> Possibly, an errata or something?

AFAIK, there is no errata on the Hitachi's web site.

> Mmm, I tried
> 
> (c) VA = 0xf0000000 (causes reset)
> 	for (e = 0; e < eend; e++) {
> 		a = SH4_UTLB_AA | (e << SH4_UTLB_E_SHIFT);
> 		_reg_write_4(a, 0xf0000000);
> 	}
> 
> and no improvement.

My dc also has a problem of ramdom reboot on heavy load,
and I tried the similar patch but it did not solve the problem.
Maybe some other problems are there..
(Continue reading)

Permalink | Reply | 8 comments |
headers
ITOH Yasufumi | 3 Nov 2002 11:25
Picon

Re: spontaneous reboot only once after power-up

In article <200211030521.gA35LGt07808 <at> mirage.ceres.dti.ne.jp>
tsutsui <at> ceres.dti.ne.jp writes:

> In article <200211030456.gA34u7h16089 <at> pl374.nas911.nara.nttpc.ne.jp>
> itohy <at> netbsd.org wrote:
> 
> > > (1) it does not clear VPN
> > 
> > I don't think it is a problem.
> > The V (valid) and D (dirty) bits are cleared by either way,
> > and the VPN shall not make sense if an entry is not valid
> 
> Yeah, but I just think it is safe and is the difference
> between AA and DA1.
> 
> > Possibly, an errata or something?
> 
> AFAIK, there is no errata on the Hitachi's web site.

Hm, anyway, uninitialized "data array 1" seems problematic....
I'm going to commit this change to work around it.
--

-- 
ITOH Yasufumi

--- sys/arch/sh3/sh3/mmu_sh4.c.orig	Sat Jun 29 11:22:59 2002
+++ sys/arch/sh3/sh3/mmu_sh4.c	Sun Nov  3 18:49:27 2002
 <at>  <at>  -129,8 +129,14  <at>  <at>  sh4_tlb_invalidate_all()
 	for (e = 0; e < eend; e++) {
 		a = SH4_UTLB_AA | (e << SH4_UTLB_E_SHIFT);
 		_reg_write_4(a, 0);
(Continue reading)

Permalink | Reply | 6 comments |
headers
Izumi Tsutsui | 3 Nov 2002 11:36
Picon
Gravatar

Re: spontaneous reboot only once after power-up

In article <200211031025.gA3APb316495 <at> pl374.nas911.nara.nttpc.ne.jp>
itohy <at> netbsd.org wrote:

> I'm going to commit this change to work around it.
 :
> +	_reg_write_4(SH4_ITLB_DA1, 0);
> +	_reg_write_4(SH4_ITLB_DA1 | (1 << SH4_ITLB_E_SHIFT), 0);
> +	_reg_write_4(SH4_ITLB_DA1 | (2 << SH4_ITLB_E_SHIFT), 0);
> +	_reg_write_4(SH4_ITLB_DA1 | (3 << SH4_ITLB_E_SHIFT), 0);

It seems these four statements should be in __sh4_itlb_invalidate_all(),
rather than sh4_tlb_invalidate_all().

BTW, __sh4_itlb_invalidate_all() should be declared as static, not extern?
---
Izumi Tsutsui
tsutsui <at> ceres.dti.ne.jp
Permalink | Reply | 4 comments |
headers
ITOH Yasufumi | 3 Nov 2002 11:55
Picon

Re: spontaneous reboot only once after power-up

In article <200211031036.gA3Aa3e08202 <at> mirage.ceres.dti.ne.jp>
tsutsui <at> ceres.dti.ne.jp writes:

> In article <200211031025.gA3APb316495 <at> pl374.nas911.nara.nttpc.ne.jp>
> itohy <at> netbsd.org wrote:
> 
> > I'm going to commit this change to work around it.
>  :
> > +	_reg_write_4(SH4_ITLB_DA1, 0);
> > +	_reg_write_4(SH4_ITLB_DA1 | (1 << SH4_ITLB_E_SHIFT), 0);
> > +	_reg_write_4(SH4_ITLB_DA1 | (2 << SH4_ITLB_E_SHIFT), 0);
> > +	_reg_write_4(SH4_ITLB_DA1 | (3 << SH4_ITLB_E_SHIFT), 0);
> 
> It seems these four statements should be in __sh4_itlb_invalidate_all(),
> rather than sh4_tlb_invalidate_all().

I think that VPN / PPN addresses which are not aligned to SZ boundary
caused the problem.
Valid entries are aligned to page size, and this initialization is needed
only once during boot process.

> BTW, __sh4_itlb_invalidate_all() should be declared as static, not extern?

Agreed.

--

-- 
ITOH Yasufumi
Permalink | Reply | 2 comments |
headers
Izumi Tsutsui | 3 Nov 2002 20:03
Picon
Gravatar

Re: spontaneous reboot only once after power-up

In article <200211031055.gA3AtfO16545 <at> pl374.nas911.nara.nttpc.ne.jp>
itohy <at> netbsd.org wrote:

> I think that VPN / PPN addresses which are not aligned to SZ boundary
> caused the problem.
> Valid entries are aligned to page size, and this initialization is needed
> only once during boot process.

Ah, now I see sh4_tlb_invalidate_all() is called only from sh4_mmu_start().
---
Izumi Tsutsui
tsutsui <at> ceres.dti.ne.jp
Permalink | Reply | 0 comments |
headers
Alex Kirk | 7 Nov 2002 05:52

Use for my NetBSD/Dreamcast

So, in a positive twist for all those who want to prove that 
NetBSD/Dreamcast isn't a waste of time, I've got a serious application going 
on mine: I'm running a Mixmaster anonymous remailer, with Qmail as my MTA. 

In doing so, I'm finding that the Dreamcast port, while fairly complete, has 
some interesting issues. First off, props to whoever made sure NTP came with 
the system; it's quite handy to be able to have my system clock synched when 
running a public server. 

On to the issues: gmake is broken. I can't even call it from the command 
line with no options without it core dumping. Also, portmap doesn't appear 
to be installed, which means that using cfs is just about impossible. 

I think I might be able to figure out how to get portmap running on my 
system, and because of its use with cfs, I'd recommend putting it into the 
base install for the Dreamcast port. As for gmake...I don't know that I'd be 
able to diagnose that. Anyone here think they can? 

Alex Kirk
Permalink | Reply | 2 comments |
headers
Jason R Thorpe | 7 Nov 2002 06:06

Re: Use for my NetBSD/Dreamcast

On Thu, Nov 07, 2002 at 04:52:29AM +0000, Alex Kirk wrote:

 > On to the issues: gmake is broken. I can't even call it from the command 
 > line with no options without it core dumping. Also, portmap doesn't appear 
 > to be installed, which means that using cfs is just about impossible. 

NetBSD uses rpcbind, not portmap.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
Permalink | Reply | 1 comment |

Gmane