Re: -current sun4c weirdness

[Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>]

<200104121542.f3CFgSg02108@mirage.ceres.dti.ne.jp>の記事において
私は書きました。

> > dumping to dev 7,1 offset 196807
> > dump 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 succeeded
> > rebooting
> 
> >  メモリは 32MB で 4MB SIMM 8 枚ですから、16+16 で 16MB 分が
> > ダンプされない、ってことでしょうか?

> ですね。

この件いろいろ見てたんですが、これは sparc/machdep.c の dumpsys() で

	/* print out how many MBs we have dumped */
	if (i && (i % (1024*1024)) == 0)
		printf("%d ", i / (1024*1024));

と 1M 毎に経過を表示させるようになっているけど、
最初の memory bank についてはその直前で

	if (maddr == 0) {
		/* Skip first page at physical address 0 */
		maddr += NBPG;
		i += NBPG;
		blkno += btodb(NBPG);
	}

と NBPG (==4096 or 8192) だけ飛ばしてて、かつ dump は 32kbytes ずつ
行われるので dumped bytes が 1M の倍数にならないだけでした。
dump 自体はされてるようです。

options DEBUG したときの

 pv_link: proc halt, va=0xf0221000: unexpected uncached mapping at 0xf25b0000

の表示に関しては、やはり 

> ちゃんと読み切れてないんですが、 sparc/pmap.c で
> pv_table_map() が全物理メモリを記録するようになってて、
> かつ pv_list は vm_physmem[] を使うようになってるのに、
> pmap_page_upload() では最初の bank を kernel text end 以降しか
> uvm_page_physload() に登録してないからという気がしてます。

の推測で正しいようで、 pmap.c:pmap_page_upload() の
uvm_page_physload() で start, end については kernel text/data/bss を
含めたすべての物理メモリを渡して、 avail_start, avail_end の
ほうだけ空いてるメモリだけを渡すようにすると kernel text/data/bss に
対する pmap_enter() も警告なしに動くようになりました。

＃関係ないけど、 uvm_page_physload() で start, end と
＃avail_start, avail_end とを正しく区別して指定してる port って
＃ほとんどないような。 (uvm(9) 参照)

が、結局これは

> 例の core dump とは関係あるのかないのか…

この件とは関係ありませんでした。うーん。
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp