Re: Fujitsu MB87030/MB89352 (SPC) manual

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

何度もテストありがとうございます。

<20040813.224820.82036306.oshimaya@sc.starcat.ne.jp>の記事において
oshimaya@sc.starcat.ne.jpさんは書きました。

> cd0 at scsibus0 target 4 lun 0: <PIONEER, CD-ROM PCP-PR24, 1.02> cdrom removable
> cd0: async, 8-bit transfers
> 
> というCD-ROMドライブを繋げてみたところsd1を認識したあとcd0を認識す
> るところでpanicしました。sd1の電源を落としてcd0だけ有効にしてもpanic
> したのでどうもこれが原因のようです(さらにcd0の電源を落としてsd0と
> sd1にしてもちゃんと起動します)。

実は OpenBSD/hp300 な人から OpenBSD に移植した mb89352.c で
st や一部の cd だと request sense まわりで何か変だと訊かれて
いろいろ調べていたんですが、どうもタイミング依存の部分がある感じです。
(うちの NetBSD/hp300 だと現状問題ないっぽいんですが……)

> db> tr
> cpu_Debugger(2104,0,781c7c,781c68,149b3e) + 6
> panic(1a5fea,0,94,10,1) + f8
> trap(0,755,a96035) + 250
> spc_datain_pio(453800,453938,1,6c,0) + 12c

spc_datain_pio() の引数からすると PH_STAT の status phase の
読み込み部分っぽいですが、デバイスによってタイミング厳しいのか
quirk のあるデバイスだと変なことになるのか……

> > あと、テストついでに x68k 用の #define NO_MANUAL_XFER を
> > はずしたらどうなるか確かめてもらえないでしょうか?
 :
> このNO_MANUAL_XFERを外したkernelも作ってみて試していますが、
> 正常に動いていますし、今のところこちらではcd0を繋げてpanicし
> たことはありません。

うーん、これはちょっと予想外でした……

rev 1.20 で message in phase と status phase とで SCMD_XFER を
使うのをやめて TEMP register 経由のマニュアル転送でデータを
持ってくるように変更したんですが、このときは井崎さんから
変更後 x68k で動かなくなったとここで報告を受けた
http://www.jp.netbsd.org/ja/JP/ml/tech-misc-ja/200307/msg00005.html
ので x68k だけ #ifdef NO_MANUAL_XFER で元に戻したのでした。

が、上記の問い合わせのあといろいろ SCSI spec を調べたら
マニュアル転送時にデータを読み出すタイミングが間違っていた
(ベースにした arch/hp300/dev/scsi.c から間違っていた)
のに気づいたので rev 1.27 で修正したのでした。

たびたびすいませんが、 rev 1.27 の修正によって
#define NO_MANUAL_XFER がなくても動くようになったと
いうことなら NO_MANUAL_XFER 部分を削除してしまいますので、
rev 1.27 の修正を元に戻したら NO_MANUAL_XFER がないと
動かなくなることの確認というのをお願いできないでしょうか?

＃戻しても動いちゃうとこれまたデバイス依存の問題になって
＃ややこしい話になりますが……
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp