[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

fxp at pci on arm32 and bus_dmamap_sync()



筒井です。

NetBSD/arm32 (20000520 あたりの current) の CATS で
Intel Etherexpress PRO/100+ を使おうとしているんですが、
しばらく負荷をかけていると下記のように panic してしまいます。
(options DIAGNOSTIC つき kernel です)

---
panic: pool_get(mclpl): free list modified: magic=a020beef; \
page 0xf37ec000; item addr 0xf37ec000

Stopped at 	_cpu_Debugger+0x10:	ldmdb	r11, {r11, r13, r15}
db>trace
_cpu_Debugger(_cpu_Debugger+0x10)
_panic(_panic+0x14)
__pool_get(__pool_get+0x10)
_fxp_add_rfabuf(_fxp_add_rfabuf+0x10)
_fxp_intr(_fxp_intr+0x10)
_mi_switch(_mi_switch+0x10)
_tsleep(_tsleep+0x10)
_sys_select(_sys_select+0x10)
_syscall(_syscall+0x10)
db>
---

未使用の pool は PI_MAGIC (0xdeadbeef) でマークされているはずが、
そのうちの後半 2バイト(arm32 は little endian)だけ壊れてしまっています。
(sys/kern/subr_pool.c 参照)

4 byte align でない転送をするのは受信パケットの DMA だけなので
(Ethernet header が 14 byte なので alignment 合わせするため)、
受信バッファ用として確保した mbuf とは違う領域に受信パケットが
DMA 転送されていて panic しているように見えます。
(sys/dev/ic/i82557.c の RFA_ALIGNMENT_FUDGE のコメント参照)

受信バッファのアドレスは事前に Receive Frame Area (RFA) と
呼ばれる領域を通じて DMA で fxp に渡されるんですが、これが
うまく fxp に渡されていないような感じがしています。で、
i386 や alpha で問題がなくて arm32 で問題が出るというのは
bus_dmamap_sync() まわりかと思って調べてみたんですが、
i82557var.h:FXP_INIT_FRABUF() でも i82557.c:fxp_intr() でも
一応 FXP_RFASYNC() されているので見た目はおかしくありません。

いろいろ試行錯誤した結果、arm32/bus_dma.c の bus_dmamap_sync() で
mips 系の bus_dmamap_sync() と同じように write buffer drain を
cache flush 操作の前に移動させてやると上記の panic は
起こらなくなったように見えるんですが、今一つ釈然としません。
この状態で ftp 等の転送速度を計ってみても 1.6Mbyte/sec 程度しか
出ず、上位層でかなりリトライしているように見えます。
(macppc 上だと同じ条件で 3Mbyte/sec 以上出る)

で、ここまでが前置きで質問なんですが、

(1) i386, alpha, macppc 等で fxp を使っていて上記のような
    panic が起こったことのある方はいますか? 

(2) host → device への DMA 転送の前の cache flush においては
    write buffer の drain と data cache の write back flush とは
    どちらを先に行うべきなんでしょう? (CPU 依存?)

(3) alpha や mips の bus_dmamap_sync() を見ると DMA 転送前だけでなく
    DMA 転送後の sync でも write buffer の drain をしていますが、
    これは必要なんでしょうか?

DMA での cache coherency を OS で面倒見るのは arm と mips くらいな上に
arm CPU 自体をよく知らないので……
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp