Pyun YongHyeon <pyunyh_at_gmail.com> writes: > On Tue, Nov 04, 2008 at 10:36:21PM +0100, Jan Henrik Sylvester wrote: > > Pyun YongHyeon wrote: > > >On Mon, Nov 03, 2008 at 07:49:34PM +0100, Jan Henrik Sylvester wrote: > > > > >Pyun YongHyeon <pyunyh at gmail.com> writes: > > > > >> http://people.freebsd.org/~yongari/ale/if_ale.c > > > > > > > > I got an Eee PC 1000H, too, with 7.1-BETA2 and just used scp to copy > > > > with 11.5MB/s -- much better than wlan for big files. Great! > > > > > > > > > >Thanks for testing! > > > > I was happy too early. Now I keep getting these: > > ale0: DMA read error! -- resetting > > ale0: could not disable Tx/Rx MAC(0x00000008)! > > It looks like Tx queue processing is still in progress. > Would you show me hardware MAC statistics? > ("sysctl dev.ale.0.stats" will show you detailed information.) > Also ale(4) related dmesg output might be useful. > > > ale0: interrupt moderation is 100 us. > > > > The speed of copying a file has dropped to <50kB/s. Stopping and > > restarting the interface does not help, even if I kldunload the driver > > in the meantime. I have yet to reboot the machine. > > > > I do not know what is different, though. I left the computer alone for > > an hour before using the network... > > > > Hmm, this is the first severe report that is related to stability > of driver. Personally I've nerver met this kind of error during > writing of ale(4). ATM I have no idea why DMA read error happens on > your box though. As you guess I don't have access to datasheet. > > Is there any reliable way to reproduce it? I tried to reproduce under heavy net load but failed. I created a tmpfs 500M disk and fetched big files (i.e. openoffice.org3 distro as of 300M) to /tmp (at 11-12MB/s rate). No traces of failure. Here is some info: ----- # ifconfig ale0 ale0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=3199<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC> ether 00:22:15:XX:XX:XX inet 192.168.233.80 netmask 0xffffffc0 broadcast 192.168.233.127 media: Ethernet autoselect (100baseTX <full-duplex>) status: active # sysctl dev.ale.0.stats dev.ale.0.stats.rx.good_frames: 779733 dev.ale.0.stats.rx.good_bcast_frames: 232 dev.ale.0.stats.rx.good_mcast_frames: 0 dev.ale.0.stats.rx.pause_frames: 0 dev.ale.0.stats.rx.control_frames: 0 dev.ale.0.stats.rx.crc_errs: 0 dev.ale.0.stats.rx.len_errs: 0 dev.ale.0.stats.rx.good_octets: 1115319790 dev.ale.0.stats.rx.good_bcast_octets: 20376 dev.ale.0.stats.rx.good_mcast_octets: 0 dev.ale.0.stats.rx.runts: 0 dev.ale.0.stats.rx.fragments: 0 dev.ale.0.stats.rx.frames_64: 370 dev.ale.0.stats.rx.frames_65_127: 159 dev.ale.0.stats.rx.frames_128_255: 108 dev.ale.0.stats.rx.frames_256_511: 124 dev.ale.0.stats.rx.frames_512_1023: 58 dev.ale.0.stats.rx.frames_1024_1518: 779088 dev.ale.0.stats.rx.frames_1519_max: 0 dev.ale.0.stats.rx.trunc_errs: 0 dev.ale.0.stats.rx.fifo_oflows: 0 dev.ale.0.stats.rx.desc_oflows: 0 dev.ale.0.stats.rx.align_errs: 0 dev.ale.0.stats.rx.filtered: 174 dev.ale.0.stats.tx.good_frames: 516845 dev.ale.0.stats.tx.good_bcast_frames: 4 dev.ale.0.stats.tx.good_mcast_frames: 0 dev.ale.0.stats.tx.pause_frames: 0 dev.ale.0.stats.tx.control_frames: 0 dev.ale.0.stats.tx.excess_defers: 0 dev.ale.0.stats.tx.defers: 0 dev.ale.0.stats.tx.good_octets: 34113213 dev.ale.0.stats.tx.good_bcast_octets: 0 dev.ale.0.stats.tx.good_mcast_octets: 0 dev.ale.0.stats.tx.frames_64: 5 dev.ale.0.stats.tx.frames_65_127: 516840 dev.ale.0.stats.tx.frames_128_255: 0 dev.ale.0.stats.tx.frames_256_511: 0 dev.ale.0.stats.tx.frames_512_1023: 0 dev.ale.0.stats.tx.frames_1024_1518: 0 dev.ale.0.stats.tx.frames_1519_max: 0 dev.ale.0.stats.tx.single_colls: 0 dev.ale.0.stats.tx.multi_colls: 0 dev.ale.0.stats.tx.late_colls: 0 dev.ale.0.stats.tx.excess_colls: 0 dev.ale.0.stats.tx.abort: 0 dev.ale.0.stats.tx.underruns: 0 dev.ale.0.stats.tx.desc_underruns: 0 dev.ale.0.stats.tx.len_errs: 0 dev.ale.0.stats.tx.trunc_errs: 240 ----- > Also I've slightly changed code which may help to stop MAC in case > of critical condition. Would you get the latest if_ale.c at the > following URL and try again? > http://people.freebsd.org/~yongari/ale/if_ale.c I didn't use this file version though. > > > > This will probably not go into 7.1-RELEASE, will it? > > > > > >It was too late to go into 7.1-RELEASE, I guess. > > > > It seems to be too early, anyhow. > > > > That's one of reason why I need more wider testing. :-) > > > Do you want me to try anything specific? (I hope it does not involve > > recompiling the kernel on this slow Eee PC.) > > > > Since you're using kernel module, just unload ale(4) and > rebuilding ale(4) is enough. For example, > #cd /path/to/ale_directory/ > #fetch http://people.freebsd.org/~yongari/ale/if_ale.c > #ifconfig ale0 down > #kldunload if_ale > #make && make install > #kldload if_ale > #ifconfig ale0 inet x.x.x.x netmask y.y.y.y > or > #dhclinet ale0 if you use DHCP. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To ServeReceived on Wed Nov 05 2008 - 05:30:56 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:37 UTC