Re: fxp at pci on arm32 and bus_dmamap_sync()

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

筒井です。

<200006302151.e5ULpk006260@edge.sky.yamashina.kyoto.jp>の記事において
taca@sky.yamashina.kyoto.jpさんは書きました。

> > するのでたいてい cache 無効になっているんですが、 fxp の RFA の場合は
> > fxp の仕様の都合上通常の mbuf 中のメモリをパラメータ転送に使っており、
> > その場合は cache が有効なので bus_dmamap_sync がシビアに要求される
> > ということのようです。
> これは無事にソース・ツリーに取り込まれた様ですね。sbus_dmamap_sync()っ
> て、私がTerkram DC-390(SCSI)とIntel fastether express 10/100で遭遇した
> のは、i386だ空っぽなので直接の関連はないかもしれません。

fxp には高負荷の状況では本質的に問題があるような気がします。
port-alpha でも同じような報告が出ています。
http://mail-index.netbsd.org/port-alpha/2000/06/05/0005.html

今回の arm32 の場合、上記の dmamap_sync() 抜けのせいで
見かけ上受信バッファが不足するような状況が発生していて、
dmamap_sync() の修正でそれが起きなくなっただけじゃないかな
と思ってます。

パケットが受信されると sys/dev/ic/i82557.c の fxp_intr() の
rcvloop: あたりで処理されて、最終的に 964行目あたりで呼んでいる
fxp_add_rfabuf() で新しい受信バッファ用 mbuf が確保されます。

fxp_add_rfabuf() では i82557var.h で定義されている
FXP_INIT_RFABUF() を使って RFA 内の各種 descriptor を
設定しますが、このとき新たに確保した mbuf だけでなく、
一つ前に確保した mbuf の RFA 内の link_addr 等も書き換えます。

高負荷で受信バッファが一杯になっている状況だと、
fxp_add_rfabuf() でバッファを確保したそばからそのバッファへの
転送が開始されるような状況が起こり得ると思いますが、
そうなると FXP_INIT_RFABUF() で前のバッファの RFA を
書き換えている最中に fxp が DMA でそのバッファの RFA を
読み込み始める、なんて事態も起こると思います。

そんな状況が発生したとすればもはや受信データがどこに
転送されるかは保証できないんじゃないかなあ、
と推測してるんですが全然確認できてません。

＃FXP_NRFABUFS を増やして起きる頻度が減るようなら正解?

> なぜかDC-390の
> BIOSをdisableすることで発生しなくなってましたが、DC-390が製造中止で、
> DC-390Uはあるんですが、こっちはBIOSをdisableするジャンパーがなくて、
> さぁ、どうしようです。:-(

port-arm32 に出した後に EBSA285 の fxp で同じ問題があった
という人からメールもらったんですが、その人の場合は
"we were allocating too little memory to the PCI window."
という原因だったとの話でした。

fxp が使える PCI の帯域が変わると受信パケットの処理能力も
変わると思うのでそのへん関係するのかなあという気はします。
DC390 の場合も BIOS が PCI の設定を変にいじくってて
同じようなことが起こるのかなあという気はしてますが、
PCI bus まわりの構造をよく知らないので分かってないです。
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp