Re: -current sun4c weirdness

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

筒井です。

<20010412173214K.mochid@netside.co.jp>の記事において
mochid@netside.co.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/pmap.c で
pv_table_map() が全物理メモリを記録するようになってて、
かつ pv_list は vm_physmem[] を使うようになってるのに、
pmap_page_upload() では最初の bank を kernel text end 以降しか
uvm_page_physload() に登録してないからという気がしてます。
(が、 VM はよく知らないのでちゃんとわかってないです)

ただ pv_table_map() の変更は 1.5 にも入ってますし、
pv_list が vm_physmem 使うようになったのは今年 3月なので、
例の core dump とは関係あるのかないのか…

>  それから、シングルユーザーで立ち上げて直後に reboot -d ってやると
> ぜんぜんダンプできないみたいなんですけど、そういうもんでしょうか?

そういうものみたいですね。これは sparc だけの話ではないようです。
ちょっと見てみましたが、 sys/dev/scsipi/sd.c:sddump() で
sd->sc_link->flags の SDEV_MEDIA_LOADED が立ってないと
ENXIO を返してる、ってとこでひっかかってる感じです。

SDEV_MEDIA_LOADED は /dev/sd?? をどれか一度 open しないと
set されないみたいなのでそうなるんですが、この動きで正しいのか
どうかはよくわかりません。
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp