[bb]USB-LANでnfsブートしたい場合には、それしかないのか・・・

http://www.usupi.org/info/koneta.html#nfsroot

えー、それしかないの？？？

cgrepで検索すると、「No network devices available」はnet/ipv4/ipconfig.c:255にあった。
ic_open_devs()という関数でネットワークデバイスを探している。
これよりも前にデバイスが存在しないと、エラーになるということだ。

では、待たせてみよう。

for_each_netdev()でループしている箇所が２つあるので、２つめの方をリトライさせるようにした。

int retry=3;
while(retry--) {
	for_each_netdev(&init_net, dev) {
		・・・
	}
	set_current_state(TASK_INTERRUPTIBLE);
	schedule_timeout(msecs_to_jiffies(1000));
	printk("retry : %d\n", retry);
}

まあ、こんなイメージだ。
そうすると・・・

pegasus 1-2.2:1.0: setup Pegasus II specific registers
retry : 2
retry : 1
retry : 0
IP-Config: No network devices available.
pegasus 1-2.2:1.0: eth0, MELCO/BUFFALO LUA2-TX, 00:40:26:c0:bf:af

だめやん。
しかたなくさかのぼると、ip_auto_config()から呼び出されていた。
ここに「try_try_again」という、なんとなくリトライしてくれそうなラベルがあった。
ic_open_devs()が失敗するとreturnしていたので、それをgoto try_try_againに変更。

pegasus 1-2.2:1.0: setup Pegasus II specific registers IP-Config: No network devices available. fail ic_open_devs() pegasus 1-2.2:1.0: eth0, MELCO/BUFFALO LUA2-TX, 00:40:26:c0:bf:af pegasus 1-2.2:1.0: update_eth_regs_async, status -22 IP-Config: Complete: device=eth0, addr=192.168.0.22, mask=255.255.255.0, gw=192.168.0.1, host=192.168.0.22, domain=, nis-domain=(none), bootserver=255.255.255.255, rootserver=192.168.0.2, rootpath= Looking up port of RPC 100003/2 on 192.168.0.2 Looking up port of RPC 100005/1 on 192.168.0.2 Root-NFS: Server returned error -22 while mounting /home/xxx/Qt/nfs VFS: Unable to mount root fs via NFS, trying floppy. List of all partitions: b300 1947648 mmcblk0 driver: mmcblk b301 263283 mmcblk0p1 No filesystem could mount root, tried: nfs Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

おお、リトライによって認識され、進んでいるように見える。
PCからpingしても通ったので、少しは動いたのだろう。

赤文字で書いてあるように、サーバがエラーを返したのだろう。
NFSサーバ側がうまく対応できていない、と信じたい。

---

このログは、fs/nfs/nfsroot.c:510で出している。
エラー元はmount_clnt.c。
では、とdprintkをprintkに定義し直してビルド。

NFS: sending MNT request for server:/home/xxx/Qt/nfs
NFS: MNT server returned result -22

よくわからん。
-22って値が、pegasusのエラー値と同じなのが気になる。
update_eth_regs_async()のエラー原因が未だにわかってないからなぁ。
関数名からすると、チップに対してUSBで非同期にレジスタ変更を行おうとしているのが失敗した、ってことなのかな。
うーむ。