Re: fxp at pci on arm32 and bus_dmamap_sync()

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

筒井です。

各種テストどうもありがとうございます。
頼んでいるばかりでなくてこちらでもやらないといけないんですが……

> > 1) if_fxp_pci.c で強制的に memh_valid = 0 して
> >    i/o mapped access を指定する
> これ、効きました。指定しない場合は90Mバイトのftp、相手がちょっとトロイ
> ので、よくて8MB/sくらいでも、7回持ちませんでした。これを適用した場合は
> (現在進行形で)34回まで持っています。

BIOS まわりの設定で変化するということからしても、
なんらかの原因にはなっているようですね。
if_fxp_pci.c のコメントには

 * We must work around this problem by always forcing the mapping
 * for memory space to be uncacheable.  On systems which cannot
 * create an uncacheable mapping (because the firmware mapped it
 * into only cacheable/prefetchable space due to the "prefetchable"
 * bit), we can fall back onto i/o mapped access.

とありますが、 "cannot create an uncachable mapping" の場合でも
bus_space_map() が失敗しない場合があるということでしょうか。
(つまり本来なら i/o mapped に fall back すべきところがしてない?)
また改めて pci まわりのコード眺めてみます。

> といった 1 のprintfを入れてみましたが、相関関係はあまりはっきりとわか
> りませんでした。"no resouce ready"は表示されつつ頑張っているときもあれ
> ば、いきなり落ちるときもあるようです。

よく考えると、 no resouce が発生した直後に panic するわけではない
(free された memory pool に fxp が転送をしたとしても、その pool が
 再利用される時になって panic する) のですぐにはわからないですね。
すいません。確認できるのは no resouce が起きずに panic することが
ないかどうか、くらいでしょうか。

> >  CSR_WRITE_1(sc, FXP_CSR_SCB_COMMAND, FXP_SCB_COMMAND_RU_ABORT);

> > を入れてみましたが、目立った変化はありませんでした。:-(
> ABORTするんだから、fxp_scb_wait()する前の3のところに入れてしまうという
> 乱暴な(?)ことをしていみたところ、落ちない様です。:-D

こういうことはちゃんとマニュアルを手に入れてから言うべきですが、
ざっとソースを眺めた限りでは CSR_SCB_COMMAND に書く前には毎回
fxp_scb_wait(sc) する必要があるような感じなので、

--- i82557.c.orig	Wed Jul 12 00:09:14 2000
+++ i82557.c	Wed Jul 12 00:20:11 2000
@@ -998,6 +998,9 @@
 
  do_transmit:
 		if (statack & FXP_SCB_STATACK_RNR) {
+			fxp_scb_wait(sc);
+			CSR_WRITE_1(sc, FXP_CSR_SCB_COMMAND,
+			    FXP_SCB_COMMAND_RU_ABORT);
 			rxmap = M_GETCTX(sc->sc_rxq.ifq_head, bus_dmamap_t);
 			fxp_scb_wait(sc);
 			CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL,

てな感じだとどうでしょう?

受信バッファの再設定をするんだから今やってる転送は止めないと
いけないよなあ、とは思うんですが、やはり先にマニュアル入手ですね……
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp