From gnats@FreeBSD._ERASE_.org Thu Aug 31 14:43:08 2000 To: jhs@._ERASE_ From: gnats-admin@FreeBSD._ERASE_.org Subject: Re: kern/20958: ep0 lockup with ifconfig showing OACTIVE Reply-To: gnats-admin@FreeBSD._ERASE_.org, freebsd-bugs@FreeBSD._ERASE_.org In-Reply-To: Your message of Thu, 31 Aug 2000 01:29:44 GMT <200008310129.BAA03102@park> Sender: gnats@FreeBSD._ERASE_.org Date: Thu, 31 Aug 2000 09:40:05 +0200 Thank you very much for your problem report. It has the internal identification `kern/20958'. The individual assigned to look at your report is: freebsd-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=20958 >Category: kern >Responsible: freebsd-bugs >Synopsis: ep0 lockup with ifconfig showing OACTIVE >Arrival-Date: Thu Aug 31 00:40:01 PDT 2000 -------------------------------------- To: FreeBSD-gnats-submit@freebsd._ERASE_.org Subject: ep0 lockup with ifconfig showing OACTIVE From: "Julian Stacey" Submitter-Id: current-users >Originator: Julian H. Stacey jhs@._ERASE_ >Organization: FreeBSD >Confidential: no >Synopsis: ep0 lockup with ifconfig showing OACTIVE >Severity: serious >Priority: medium >Category: kern >Release: FreeBSD 4.1-RELEASE i386 >Class: sw-bug >Environment: >Description: With 4.1 I seem to be able to easily thrash FreeBSD into letting the ep driver interface lock up. Symptom seems to be seeing OACTIVE with ifconfig ep0 I suppose it's maybe swapping to hell, but I've not seen this poor behavious on previous FreeBSD releases with same hardware & similar loads ( It's a little 486 33M laptop with 12M, X11, ether, 1gig of IDE, & a few remote xterms moving trees, nfs heavy ide io etc. ) >How-To-Repeat: Get a slow disc, reduce ram, load & thrash. In case you can't do that, here's my log --- jhs@._ERASE_ 4.1-RELEASE csh ttyp2 2 % ping flip PING flip (192.168.91.24): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ^C --- flip ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss jhs@._ERASE_ 4.1-RELEASE csh ttyp2 4 % ifconfig -a ep0: flags=8c43 mtu 1500 inet 192.168.91.33 netmask 0xffffff00 broadcast 192.168.91.255 inet6 fe80::220:afff:fe0d:f426%ep0 prefixlen 64 scopeid 0xa ether 00:20:af:0d:f4:26 media: 10base2/BNC supported media: 10base2/BNC 10baseT/UTP 10base5/AUI jhs@._ERASE_ 4.1-RELEASE csh ttyp2 6 % su jhs@._ERASE_ 4.1-RELEASE csh ttyp2 101 % ifconfig ep0 down jhs@._ERASE_ 4.1-RELEASE csh ttyp2 102 % ifconfig ep0 up jhs@._ERASE_ 4.1-RELEASE csh ttyp2 103 % ping flip PING flip (192.168.91.24): 56 data bytes 64 bytes from 192.168.91.24: icmp_seq=0 ttl=255 time=0.981 ms 64 bytes from 192.168.91.24: icmp_seq=1 ttl=255 time=0.947 ms ^C --- flip ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.935/0.950/0.981/0.019 ms jhs@._ERASE_ 4.1-RELEASE csh ttyp2 104 % ifconfig -a ep0: flags=8843 mtu 1500 inet 192.168.91.33 netmask 0xffffff00 broadcast 192.168.91.255 inet6 fe80::220:afff:fe0d:f426%ep0 prefixlen 64 scopeid 0xa ether 00:20:af:0d:f4:26 media: 10base2/BNC supported media: 10base2/BNC 10baseT/UTP 10base5/AUI jhs@._ERASE_ 4.1-RELEASE csh ttyp2 105 % --- >Fix: No idea, but as those kernel developers who likely do have ideas, likely also have newer hardware which maybe wont see this, I'll volunteer to be guinea pig for experiments / diffs to try I guess maybe some kernel assumptions/constants need to be changed/increased ? An ifconfig down, up resets it temporarily.