fxp0 interface going up/down/up/down (dhclient related?)
I'm having an issue where my fxp0 interface keeps looping between DOWN/UP, with dhclient requesting a lease each time in between. I think it's caused by dhclient: solfertje # dhclient -d fxp0 DHCPREQUEST on fxp0 to 255.255.255.255 port 67 send_packet: Network is down DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down ^C In above test I turned off devd (/etc/rc.d/devd stop) and background dhclient (/etc/rc.d/dhclient stop fxp0), and I still go the above result. There's practically no time spent between up/down cycles, this just keeps going on and on. fxp0 is the only interface that runs on DHCP. The others have static IP's. Initially I thought the issue might be caused by devd, because I have both ethernet and 822.11 type NICs (2x ethernet, 1x wifi) in that system. This is 9-STABLE from yesterday. Before, I had 9-RELEASE running on this system with the same config, and that worked well. I'm not sure it's related, but on the wireless interface I get alot of: Jun 9 12:08:11 solfertje kernel: ath0: stuck beacon; resetting (bmiss count 4) ifconfig reads: solfertje # ifconfig em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=4219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO ether 68:05:ca:17:fe:f7 inet 10.236.150.1 netmask 0xff00 broadcast 10.236.150.255 inet6 fe80::6a05:caff:fe17:fef7%em0 prefixlen 64 scopeid 0x2 nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 6c:fd:b9:68:db:36 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=4219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO ether 00:0e:0c:b2:04:b0 inet6 fe80::20e:cff:feb2:4b0%fxp0 prefixlen 64 scopeid 0x9 inet 141.105.10.89 netmask 0xff80 broadcast 141.105.10.127 nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=63RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xd inet 127.0.0.1 netmask 0xff00 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 6c:fd:b9:68:db:36 inet 10.236.151.1 netmask 0xff00 broadcast 10.236.151.255 inet6 fe80::6efd:b9ff:fe68:db36%wlan0 prefixlen 64 scopeid 0xe nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running ssid solfertje channel 11 (2462 MHz 11g) bssid 6c:fd:b9:68:db:36 regdomain 32924 country CN indoor ecm authmode WPA privacy MIXED deftxkey 3 TKIP 2:128-bit TKIP 3:128-bit txpower 20 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs pflog0: flags=141UP,RUNNING,PROMISC metric 0 mtu 33152 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL And the hardware is as follows: hostb0@pci0:0:0:0: class=0x06 card=0x5a141002 chip=0x5a141002 rev=0x02 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'RD890 PCI to PCI bridge (external gfx0 port B)' class = bridge subclass = HOST-PCI cap 08[f0] = HT MSI fixed address window enabled at 0xfee0 cap 08[c4] = HT slave cap 08[40] = HT retry mode cap 08[54] = HT unit ID clumping cap 08[9c] = HT Gen3 cap 05[70] = MSI supports 4 messages PCI errors = Received Master-Abort none0@pci0:0:0:2: class=0x080600 card=0x5a231002 chip=0x5a231002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' class = base peripheral cap 0f[40] = unknown cap 05[54] = MSI supports 1 message, 64 bit cap
Re: fxp0 interface going up/down/up/down (dhclient related?)
On Sun, Jun 09, 2013 at 12:21:37PM +0200, Alban Hertroys wrote:
I'm having an issue where my fxp0 interface keeps looping between DOWN/UP,
with dhclient requesting a lease each time in between. I think it's caused by
dhclient:
solfertje # dhclient -d fxp0
DHCPREQUEST on fxp0 to 255.255.255.255 port 67
send_packet: Network is down
DHCPREQUEST on fxp0 to 255.255.255.255 port 67
DHCPACK from 109.72.40.1
bound to 141.105.10.89 -- renewal in 7200 seconds.
fxp0 link state up - down
fxp0 link state down - up
DHCPREQUEST on fxp0 to 255.255.255.255 port 67
DHCPACK from 109.72.40.1
bound to 141.105.10.89 -- renewal in 7200 seconds.
fxp0 link state up - down
fxp0 link state down - up
DHCPREQUEST on fxp0 to 255.255.255.255 port 67
DHCPACK from 109.72.40.1
bound to 141.105.10.89 -- renewal in 7200 seconds.
fxp0 link state up - down
fxp0 link state down - up
DHCPREQUEST on fxp0 to 255.255.255.255 port 67
DHCPACK from 109.72.40.1
bound to 141.105.10.89 -- renewal in 7200 seconds.
fxp0 link state up - down
fxp0 link state down - up
DHCPREQUEST on fxp0 to 255.255.255.255 port 67
DHCPACK from 109.72.40.1
bound to 141.105.10.89 -- renewal in 7200 seconds.
fxp0 link state up - down
^C
In above test I turned off devd (/etc/rc.d/devd stop) and background dhclient
(/etc/rc.d/dhclient stop fxp0), and I still go the above result. There's
practically no time spent between up/down cycles, this just keeps going on
and on.
fxp0 is the only interface that runs on DHCP. The others have static IP's.
Initially I thought the issue might be caused by devd, because I have both
ethernet and 822.11 type NICs (2x ethernet, 1x wifi) in that system.
This is 9-STABLE from yesterday.
Before, I had 9-RELEASE running on this system with the same config, and that
worked well.
And so what I predicted begins...
The issue is described in the 8.4-RELEASE Errata Notes; the driver is
using the same driver version as in stable/9, hence you're experiencing
the same problem. See Open Issues:
http://www.freebsd.org/releases/8.4R/errata.html
No fix for this has been committed. It is still under discussions by
multiple kernel folks as to where the fix should be applied (dhclient or
the fxp(4) driver), because the changes made to dhclient (that tickle
this bug) may actually affect more drivers than just fxp(4).
You can start by reading the (extremely long but very informative)
thread here. I do urge you to read all the posts, not skim them:
http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073440.html
http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/thread.html#73440
The only known workarounds at this time are:
a) Cease use of DHCP; set a static IP in rc.conf,
b) Try some of the patches mentioned within the above thread,
specifically this one:
http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073581.html
The patch is for head (CURRENT) so it may not patch cleanly. If not,
you can try to work the patch in yourself/by hand, or you can ask
Yong-Hyeon or others for help.
I'm not sure it's related, but on the wireless interface I get alot of:
Jun 9 12:08:11 solfertje kernel: ath0: stuck beacon; resetting (bmiss count
4)
Absolutely 100% unrelated. That issue has been around for years, and
the root cause varies tremendously. I discussed it back in February
2011:
http://lists.freebsd.org/pipermail/freebsd-stable/2011-February/061700.html
If you want to know how I solved that problem, I can tell you, but I'm
certain you won't be happy to hear what I have to say.
If you're concerned about this problem, please start another thread
discussing it. I'm sure Adrian Chadd can provide you lots of insights,
but most of them are already in his response to my above thread/post.
{snipping other stuff}
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fxp0 interface going up/down/up/down (dhclient related?)
On Sun, Jun 9, 2013, at 12:44, Jeremy Chadwick wrote: On Sun, Jun 09, 2013 at 12:21:37PM +0200, Alban Hertroys wrote: I'm having an issue where my fxp0 interface keeps looping between DOWN/UP, with dhclient requesting a lease each time in between. I think it's caused by dhclient: And so what I predicted begins... I have been suffering this issue since forever (which for me began at freebsd 9.0). Currently I'm at stable9. Much appreciated, shouldn't this be at wiki? -- Cheers, Łukasz Gruner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fxp0 interface going up/down/up/down (dhclient related?)
On Sun, Jun 09, 2013 at 12:21:37PM +0200, Alban Hertroys wrote:
I'm having an issue where my fxp0 interface keeps looping between DOWN/UP,
with dhclient requesting a lease each time in between. I think it's caused by
dhclient:
solfertje # dhclient -d fxp0
DHCPREQUEST on fxp0 to 255.255.255.255 port 67
send_packet: Network is down
DHCPREQUEST on fxp0 to 255.255.255.255 port 67
DHCPACK from 109.72.40.1
bound to 141.105.10.89 -- renewal in 7200 seconds.
fxp0 link state up - down
fxp0 link state down - up
DHCPREQUEST on fxp0 to 255.255.255.255 port 67
DHCPACK from 109.72.40.1
bound to 141.105.10.89 -- renewal in 7200 seconds.
fxp0 link state up - down
fxp0 link state down - up
DHCPREQUEST on fxp0 to 255.255.255.255 port 67
DHCPACK from 109.72.40.1
bound to 141.105.10.89 -- renewal in 7200 seconds.
fxp0 link state up - down
fxp0 link state down - up
DHCPREQUEST on fxp0 to 255.255.255.255 port 67
DHCPACK from 109.72.40.1
bound to 141.105.10.89 -- renewal in 7200 seconds.
fxp0 link state up - down
fxp0 link state down - up
DHCPREQUEST on fxp0 to 255.255.255.255 port 67
DHCPACK from 109.72.40.1
bound to 141.105.10.89 -- renewal in 7200 seconds.
fxp0 link state up - down
^C
In above test I turned off devd (/etc/rc.d/devd stop) and background dhclient
(/etc/rc.d/dhclient stop fxp0), and I still go the above result. There's
practically no time spent between up/down cycles, this just keeps going on
and on.
fxp0 is the only interface that runs on DHCP. The others have static IP's.
Try attached patch and let me know whether it also works for you.
Index: sys/dev/fxp/if_fxp.c
===
--- sys/dev/fxp/if_fxp.c (revision 251021)
+++ sys/dev/fxp/if_fxp.c (working copy)
@@ -1075,7 +1075,8 @@ fxp_suspend(device_t dev)
pmstat |= PCIM_PSTAT_PME | PCIM_PSTAT_PMEENABLE;
sc-flags |= FXP_FLAG_WOL;
/* Reconfigure hardware to accept magic frames. */
- fxp_init_body(sc, 1);
+ ifp-if_drv_flags = ~IFF_DRV_RUNNING;
+ fxp_init_body(sc, 0);
}
pci_write_config(sc-dev, pmc + PCIR_POWER_STATUS, pmstat, 2);
}
@@ -2141,8 +2142,10 @@ fxp_tick(void *xsc)
*/
if (sc-rx_idle_secs FXP_MAX_RX_IDLE) {
sc-rx_idle_secs = 0;
- if ((ifp-if_drv_flags IFF_DRV_RUNNING) != 0)
+ if ((ifp-if_drv_flags IFF_DRV_RUNNING) != 0) {
+ ifp-if_drv_flags = ~IFF_DRV_RUNNING;
fxp_init_body(sc, 1);
+ }
return;
}
/*
@@ -2240,6 +2243,7 @@ fxp_watchdog(struct fxp_softc *sc)
device_printf(sc-dev, device timeout\n);
sc-ifp-if_oerrors++;
+ sc-ifp-if_drv_flags = ~IFF_DRV_RUNNING;
fxp_init_body(sc, 1);
}
@@ -2274,6 +2278,10 @@ fxp_init_body(struct fxp_softc *sc, int setmedia)
int i, prm;
FXP_LOCK_ASSERT(sc, MA_OWNED);
+
+ if ((ifp-if_drv_flags IFF_DRV_RUNNING) != 0)
+ return;
+
/*
* Cancel any pending I/O
*/
@@ -2813,6 +2821,7 @@ fxp_miibus_statchg(device_t dev)
*/
if (sc-revision == FXP_REV_82557)
return;
+ ifp-if_drv_flags = ~IFF_DRV_RUNNING;
fxp_init_body(sc, 0);
}
@@ -2836,9 +2845,10 @@ fxp_ioctl(struct ifnet *ifp, u_long command, caddr
if (ifp-if_flags IFF_UP) {
if (((ifp-if_drv_flags IFF_DRV_RUNNING) != 0)
((ifp-if_flags ^ sc-if_flags)
- (IFF_PROMISC | IFF_ALLMULTI | IFF_LINK0)) != 0)
+ (IFF_PROMISC | IFF_ALLMULTI | IFF_LINK0)) != 0) {
+ifp-if_drv_flags = ~IFF_DRV_RUNNING;
fxp_init_body(sc, 0);
- else if ((ifp-if_drv_flags IFF_DRV_RUNNING) == 0)
+ } else if ((ifp-if_drv_flags IFF_DRV_RUNNING) == 0)
fxp_init_body(sc, 1);
} else {
if ((ifp-if_drv_flags IFF_DRV_RUNNING) != 0)
@@ -2851,8 +2861,10 @@ fxp_ioctl(struct ifnet *ifp, u_long command, caddr
case SIOCADDMULTI:
case SIOCDELMULTI:
FXP_LOCK(sc);
- if ((ifp-if_drv_flags IFF_DRV_RUNNING) != 0)
+ if ((ifp-if_drv_flags IFF_DRV_RUNNING) != 0) {
+ ifp-if_drv_flags = ~IFF_DRV_RUNNING;
fxp_init_body(sc, 0);
+ }
FXP_UNLOCK(sc);
break;
@@ -2942,8 +2954,10 @@ fxp_ioctl(struct ifnet *ifp, u_long command, caddr
~(IFCAP_VLAN_HWTSO | IFCAP_VLAN_HWCSUM);
reinit++;
}
- if (reinit 0 ifp-if_flags IFF_UP)
+ if (reinit 0 (ifp-if_drv_flags IFF_DRV_RUNNING) != 0) {
+ ifp-if_drv_flags = ~IFF_DRV_RUNNING;
fxp_init_body(sc, 0);
+ }
FXP_UNLOCK(sc);
VLAN_CAPABILITIES(ifp);
break;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fxp0 interface going up/down/up/down (dhclient related?)
On Jun 9, 2013, at 12:44, Jeremy Chadwick j...@koitsu.org wrote: On Sun, Jun 09, 2013 at 12:21:37PM +0200, Alban Hertroys wrote: I'm having an issue where my fxp0 interface keeps looping between DOWN/UP, with dhclient requesting a lease each time in between. I think it's caused by dhclient: solfertje # dhclient -d fxp0 DHCPREQUEST on fxp0 to 255.255.255.255 port 67 send_packet: Network is down DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down ^C In above test I turned off devd (/etc/rc.d/devd stop) and background dhclient (/etc/rc.d/dhclient stop fxp0), and I still go the above result. There's practically no time spent between up/down cycles, this just keeps going on and on. fxp0 is the only interface that runs on DHCP. The others have static IP's. Initially I thought the issue might be caused by devd, because I have both ethernet and 822.11 type NICs (2x ethernet, 1x wifi) in that system. This is 9-STABLE from yesterday. Before, I had 9-RELEASE running on this system with the same config, and that worked well. And so what I predicted begins... The issue is described in the 8.4-RELEASE Errata Notes; the driver is using the same driver version as in stable/9, hence you're experiencing the same problem. See Open Issues: http://www.freebsd.org/releases/8.4R/errata.html No fix for this has been committed. It is still under discussions by multiple kernel folks as to where the fix should be applied (dhclient or the fxp(4) driver), because the changes made to dhclient (that tickle this bug) may actually affect more drivers than just fxp(4). You can start by reading the (extremely long but very informative) thread here. I do urge you to read all the posts, not skim them: http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073440.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/thread.html#73440 Goodness, and here I was hoping it was just a silly mistake I made… IIUC, the issue is a combination of: - dhclient now being aware of link state changes and - the fxp driver reinitializes for certain mode changes, such as assigning an IP address Which causes dhclient to think that the link state changed, fetch a new IP address and assigns it to the fxp adapter again, causing the same link state change over and over again. Is that about correct? The only known workarounds at this time are: a) Cease use of DHCP; set a static IP in rc.conf, b) Try some of the patches mentioned within the above thread, specifically this one: http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073581.html Or c) Use DHCP with a static media setting: ifconfig_fxp0=DHCP media 100baseTX mediaopt full-duplex That worked for two out of three people apparently. I'm not done reading this thread yet though and I noticed a patch by YongHyeon that I'll test first. The patch is for head (CURRENT) so it may not patch cleanly. If not, you can try to work the patch in yourself/by hand, or you can ask Yong-Hyeon or others for help. I'm not sure it's related, but on the wireless interface I get alot of: Jun 9 12:08:11 solfertje kernel: ath0: stuck beacon; resetting (bmiss count 4) Absolutely 100% unrelated. That issue has been around for years, and the root cause varies tremendously. I discussed it back in February 2011: http://lists.freebsd.org/pipermail/freebsd-stable/2011-February/061700.html If you want to know how I solved that problem, I can tell you, but I'm certain you won't be happy to hear what I have to say. If you're concerned about this problem, please start another thread discussing it. I'm sure Adrian Chadd can provide you lots of insights, but most of them are already in his response to my above thread/post. Right, then I won't polute this thread with wifi-related issues any further. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to
Re: fxp0 interface going up/down/up/down (dhclient related?)
On Sun, Jun 09, 2013 at 01:21:53PM +0200, ?ukasz Gruner wrote: On Sun, Jun 9, 2013, at 12:44, Jeremy Chadwick wrote: On Sun, Jun 09, 2013 at 12:21:37PM +0200, Alban Hertroys wrote: I'm having an issue where my fxp0 interface keeps looping between DOWN/UP, with dhclient requesting a lease each time in between. I think it's caused by dhclient: And so what I predicted begins... I have been suffering this issue since forever (which for me began at freebsd 9.0). Currently I'm at stable9. The problem we're talking about was a direct result of this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=166656 The commit (MFC) was done to stable/8 and stable/9 in this revision and at this date/time: stable/9 commit: r247335 -- 2013/02/26 stable/8 commit: r247336 -- 2013/02/26 You can see the commit log/messages in the PR. Now let's talk about versions: FreeBSD 9.0-RELEASE came out 2012/01/12: http://lists.freebsd.org/pipermail/freebsd-announce/2012-January/001406.html FreeBSD 9.1-RELEASE came out 2012/12/30: http://lists.freebsd.org/pipermail/freebsd-announce/2012-December/001448.html So when you say the issue for you began at FreeBSD 9.0, you need to be more specific (uname -a output would be a good start), because otherwise to me it sounds like you're experiencing a *completely* different problem. Much appreciated, shouldn't this be at wiki? What wiki? How would people know to read it? Using a web search engine like Google? That would return this mailing list thread, as well as the ones I've referenced. There is enough old/outdated/completely and absolutely WRONG crap on the FreeBSD Wiki as is. The Wiki is not the official source/list of problems (there is no official source/list -- the mailing lists are, for a decade, have been as good as it gets). -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fxp0 interface going up/down/up/down (dhclient related?)
On Sun, Jun 09, 2013 at 02:48:29PM +0200, Alban Hertroys wrote: On Jun 9, 2013, at 12:44, Jeremy Chadwick j...@koitsu.org wrote: On Sun, Jun 09, 2013 at 12:21:37PM +0200, Alban Hertroys wrote: I'm having an issue where my fxp0 interface keeps looping between DOWN/UP, with dhclient requesting a lease each time in between. I think it's caused by dhclient: solfertje # dhclient -d fxp0 DHCPREQUEST on fxp0 to 255.255.255.255 port 67 send_packet: Network is down DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down ^C In above test I turned off devd (/etc/rc.d/devd stop) and background dhclient (/etc/rc.d/dhclient stop fxp0), and I still go the above result. There's practically no time spent between up/down cycles, this just keeps going on and on. fxp0 is the only interface that runs on DHCP. The others have static IP's. Initially I thought the issue might be caused by devd, because I have both ethernet and 822.11 type NICs (2x ethernet, 1x wifi) in that system. This is 9-STABLE from yesterday. Before, I had 9-RELEASE running on this system with the same config, and that worked well. And so what I predicted begins... The issue is described in the 8.4-RELEASE Errata Notes; the driver is using the same driver version as in stable/9, hence you're experiencing the same problem. See Open Issues: http://www.freebsd.org/releases/8.4R/errata.html No fix for this has been committed. It is still under discussions by multiple kernel folks as to where the fix should be applied (dhclient or the fxp(4) driver), because the changes made to dhclient (that tickle this bug) may actually affect more drivers than just fxp(4). You can start by reading the (extremely long but very informative) thread here. I do urge you to read all the posts, not skim them: http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073440.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/thread.html#73440 Goodness, and here I was hoping it was just a silly mistake I made? IIUC, the issue is a combination of: - dhclient now being aware of link state changes and - the fxp driver reinitializes for certain mode changes, such as assigning an IP address Which causes dhclient to think that the link state changed, fetch a new IP address and assigns it to the fxp adapter again, causing the same link state change over and over again. Is that about correct? Someone else can answer this. The only known workarounds at this time are: a) Cease use of DHCP; set a static IP in rc.conf, b) Try some of the patches mentioned within the above thread, specifically this one: http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073581.html Or c) Use DHCP with a static media setting: ifconfig_fxp0=DHCP media 100baseTX mediaopt full-duplex DO NOT DO THIS. People who do this do not understand what this does. This has bad effects on IEEE 802.3 and will not do/behave like you might think. The short version: The ONLY TIME you should be hard-setting speed and duplex in ifconfig is when you have a managed switch on the other end where you can set the speed/duplex for that port as well. Otherwise, if you have autoneg on one side, and forced speed/duplex on the other, there is ABSOLUTELY NO GUARANTEE it will work -- the behaviour at that point is generally undefined (and chaotic), and in my experience what happens is the switch ends up picking 100/half while the FreeBSD box thinks 100/full and you end up with an insane collision rate + hilariously slow network speeds (but usually only in one direction). The behaviour varies per brand (and revision) of switch, firmware, and other things. So bottom line: if you're going to use autoneg, use it consistently on both ends; if you're going to force speed/duplex, do so consistently on both ends. (If you don't own a managed switch, then autoneg is your only choice) That worked for two out of three people apparently. I'm not done reading this thread yet though and I noticed a patch by YongHyeon that I'll test first. The fact it didn't
Re: fxp0 interface going up/down/up/down (dhclient related?)
On Jun 9, 2013, at 13:45, YongHyeon PYUN pyu...@gmail.com wrote: On Sun, Jun 09, 2013 at 12:21:37PM +0200, Alban Hertroys wrote: I'm having an issue where my fxp0 interface keeps looping between DOWN/UP, with dhclient requesting a lease each time in between. I think it's caused by dhclient: solfertje # dhclient -d fxp0 DHCPREQUEST on fxp0 to 255.255.255.255 port 67 send_packet: Network is down DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down ^C In above test I turned off devd (/etc/rc.d/devd stop) and background dhclient (/etc/rc.d/dhclient stop fxp0), and I still go the above result. There's practically no time spent between up/down cycles, this just keeps going on and on. fxp0 is the only interface that runs on DHCP. The others have static IP's. Try attached patch and let me know whether it also works for you. fxp.init.diff I'm now running with this patch and the symptoms seem to have gone away. Thanks! Is there anything I should be aware of with this patch or anything you'd like to know about how it runs? Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
8.4 and EHCI - regression?
After upgrade from 8.3 to 8.4, ehci (USB 2.0) disappeared from `dmesg`. Details: Motherboard: ASUS M2NPV-MX ACPI BIOS Revision 1101 Before upgrade, 8.3-RELEASE-p2 i386: ~ $ egrep -i 'usb|hci' dmesg.yesterday ohci0: OHCI (generic) USB controller mem 0xfe02f000-0xfe02 irq 21 at device 11.0 on pci0 ohci0: [ITHREAD] usbus0: OHCI (generic) USB controller on ohci0 ehci0: EHCI (generic) USB 2.0 controller mem 0xfe02e000-0xfe02e0ff irq 22 at device 11.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: EHCI (generic) USB 2.0 controller on ehci0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: nVidia at usbus0 uhub0: nVidia OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: nVidia at usbus1 uhub1: nVidia EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus1 Root mount waiting for: usbus1 usbus0 Root mount waiting for: usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 ugen0.2: vendor 0x055f at usbus0 (the last line - a scanner). After upgrade to 8.4-RELEASE - no EHCI: ~ $ dmesg | egrep -i 'usb|hci' ohci0: OHCI (generic) USB controller mem 0xfe02f000-0xfe02 irq 21 at device 11.0 on pci0 ohci0: [ITHREAD] usbus0 on ohci0 usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: nVidia at usbus0 uhub0: nVidia OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 ugen0.2: vendor 0x055f at usbus0 ~ $ pciconf -l | grep hci ohci0@pci0:0:11:0: class=0x0c0310 card=0x81c01043 chip=0x026d10de rev=0xa3 hdr=0x00 ehci0@pci0:0:11:1: class=0x0c0320 card=0x81c01043 chip=0x026e10de rev=0xa3 hdr=0x00 ~ $ kldstat Id Refs AddressSize Name 1 33 0xc040 58ae60 kernel 22 0xc098b000 57964sound.ko 31 0xc09e3000 2abe8snd_hda.ko 41 0xc0a0e000 3288 speaker.ko 51 0xc0a12000 a91200 nvidia.ko 61 0xc14a4000 308c aibs.ko 71 0xc6169000 8000 linprocfs.ko 81 0xc6175000 4000 fdescfs.ko 91 0xc62eb000 2000 linux_adobe.ko 101 0xc6497000 2000 rtc.ko ~ $ kldstat -v | grep hci 131 ohci/usbus 130 uhci/usbus 129 ehci/usbus 128 xhci/usbus 124 pci/uhci 123 pci/ohci 42 pci/ata_ahci 122 pci/ehci 41 atapci/ata_ahci_ata ~ # kldload ehci module_register: module pci/ehci already exists! Module pci/ehci failed to register: 17 kldload: can't load ehci: File exists How I upgraded: rm -rf /usr/src svn export svn://svn0.us-east.FreeBSD.org/base/releng/8.4 /usr/src (created custom kernel config from GENERIC) cd /usr/obj chflags -R noschg * rm -rf * cd /usr/src make buildworld kernel shutdown -p now (boot in single user) fsck -p mount -a swapon -a cd /usr/src adjkerntz -i mergemaster -p make installworld make delete-old mergemaster -Fi shutdown -p now cd /usr/src make delete-old-libs In /etc/make.conf : KERNCONF=BEDSIDE INSTALL_NODEBUG=yes CPUTYPE?=athlon64 Custom kernel config in /usr/src/sys/i386/conf/BEDSIDE (I edited from GENERIC 8.4): # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: sys/i386/conf/GENERIC 247909 2013-03-07 07:28:05Z bryanv $ #lena cpu I486_CPU #lena cpu I586_CPU cpu I686_CPU ident BEDSIDE #lena was GENERIC # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. # Use the following to compile in values accessible to the kernel # through getenv() (or kenv(1) in userland). The format of the file # is 'variable=value', see kenv(1) # # env GENERIC.env #lena makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking #lena options INET6 # IPv6 communications protocols #lena options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates
Re: fxp0 interface going up/down/up/down (dhclient related?)
Hello, Jeremy. You wrote 9 июня 2013 г., 14:44:01: JC The issue is described in the 8.4-RELEASE Errata Notes; the driver is JC using the same driver version as in stable/9, hence you're experiencing JC the same problem. See Open Issues: I had some memory, that I had had this problem on my router some time (year? two years? three?) ago, and it was fixed somehow at then-HEAD (9?) system with disabling link down event on fxp(4), caused by chip reset after address setting. Is it deja-vu or true memory? -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.4 and EHCI - regression?
On Sun, Jun 09, 2013 at 08:03:13PM +0300, l...@lena.kiev.ua wrote: After upgrade from 8.3 to 8.4, ehci (USB 2.0) disappeared from `dmesg`. Details: Motherboard: ASUS M2NPV-MX ACPI BIOS Revision 1101 Before upgrade, 8.3-RELEASE-p2 i386: ~ $ egrep -i 'usb|hci' dmesg.yesterday ohci0: OHCI (generic) USB controller mem 0xfe02f000-0xfe02 irq 21 at device 11.0 on pci0 ohci0: [ITHREAD] usbus0: OHCI (generic) USB controller on ohci0 ehci0: EHCI (generic) USB 2.0 controller mem 0xfe02e000-0xfe02e0ff irq 22 at device 11.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: EHCI (generic) USB 2.0 controller on ehci0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: nVidia at usbus0 uhub0: nVidia OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: nVidia at usbus1 uhub1: nVidia EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus1 Root mount waiting for: usbus1 usbus0 Root mount waiting for: usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 ugen0.2: vendor 0x055f at usbus0 (the last line - a scanner). After upgrade to 8.4-RELEASE - no EHCI: ~ $ dmesg | egrep -i 'usb|hci' ohci0: OHCI (generic) USB controller mem 0xfe02f000-0xfe02 irq 21 at device 11.0 on pci0 ohci0: [ITHREAD] usbus0 on ohci0 usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: nVidia at usbus0 uhub0: nVidia OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 ugen0.2: vendor 0x055f at usbus0 ~ $ pciconf -l | grep hci ohci0@pci0:0:11:0: class=0x0c0310 card=0x81c01043 chip=0x026d10de rev=0xa3 hdr=0x00 ehci0@pci0:0:11:1: class=0x0c0320 card=0x81c01043 chip=0x026e10de rev=0xa3 hdr=0x00 ~ $ kldstat Id Refs AddressSize Name 1 33 0xc040 58ae60 kernel 22 0xc098b000 57964sound.ko 31 0xc09e3000 2abe8snd_hda.ko 41 0xc0a0e000 3288 speaker.ko 51 0xc0a12000 a91200 nvidia.ko 61 0xc14a4000 308c aibs.ko 71 0xc6169000 8000 linprocfs.ko 81 0xc6175000 4000 fdescfs.ko 91 0xc62eb000 2000 linux_adobe.ko 101 0xc6497000 2000 rtc.ko ~ $ kldstat -v | grep hci 131 ohci/usbus 130 uhci/usbus 129 ehci/usbus 128 xhci/usbus 124 pci/uhci 123 pci/ohci 42 pci/ata_ahci 122 pci/ehci 41 atapci/ata_ahci_ata ~ # kldload ehci module_register: module pci/ehci already exists! Module pci/ehci failed to register: 17 kldload: can't load ehci: File exists How I upgraded: rm -rf /usr/src svn export svn://svn0.us-east.FreeBSD.org/base/releng/8.4 /usr/src (created custom kernel config from GENERIC) cd /usr/obj chflags -R noschg * rm -rf * cd /usr/src make buildworld kernel shutdown -p now (boot in single user) fsck -p mount -a swapon -a cd /usr/src adjkerntz -i mergemaster -p make installworld make delete-old mergemaster -Fi shutdown -p now cd /usr/src make delete-old-libs In /etc/make.conf : KERNCONF=BEDSIDE INSTALL_NODEBUG=yes CPUTYPE?=athlon64 Custom kernel config in /usr/src/sys/i386/conf/BEDSIDE (I edited from GENERIC 8.4): # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: sys/i386/conf/GENERIC 247909 2013-03-07 07:28:05Z bryanv $ #lena cpu I486_CPU #lena cpu I586_CPU cpu I686_CPU ident BEDSIDE #lena was GENERIC # To statically compile in device wiring instead of /boot/device.hints #hintsGENERIC.hints # Default places to look for devices. # Use the following to compile in values accessible to the kernel # through getenv() (or kenv(1) in userland). The format of the file # is 'variable=value', see kenv(1) # # env GENERIC.env #lena makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking #lena options INET6 # IPv6 communications
RE: 8.4 and EHCI - regression?
Hi, EHCI is probed by PCI. It will print if probing fails. Probably ACPI regression. Did you load ACPI? --HPS -Original message- From:Jeremy Chadwick j...@koitsu.org Sent: Sunday 9th June 2013 19:16 To: l...@lena.kiev.ua Cc: freebsd-stable@freebsd.org; freebsd-...@freebsd.org Subject: Re: 8.4 and EHCI - regression? On Sun, Jun 09, 2013 at 08:03:13PM +0300, l...@lena.kiev.ua wrote: After upgrade from 8.3 to 8.4, ehci (USB 2.0) disappeared from `dmesg`. Details: Motherboard: ASUS M2NPV-MX ACPI BIOS Revision 1101 Before upgrade, 8.3-RELEASE-p2 i386: ~ $ egrep -i 'usb|hci' dmesg.yesterday ohci0: OHCI (generic) USB controller mem 0xfe02f000-0xfe02 irq 21 at device 11.0 on pci0 ohci0: [ITHREAD] usbus0: OHCI (generic) USB controller on ohci0 ehci0: EHCI (generic) USB 2.0 controller mem 0xfe02e000-0xfe02e0ff irq 22 at device 11.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: EHCI (generic) USB 2.0 controller on ehci0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: nVidia at usbus0 uhub0: nVidia OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: nVidia at usbus1 uhub1: nVidia EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus1 Root mount waiting for: usbus1 usbus0 Root mount waiting for: usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 ugen0.2: vendor 0x055f at usbus0 (the last line - a scanner). After upgrade to 8.4-RELEASE - no EHCI: ~ $ dmesg | egrep -i 'usb|hci' ohci0: OHCI (generic) USB controller mem 0xfe02f000-0xfe02 irq 21 at device 11.0 on pci0 ohci0: [ITHREAD] usbus0 on ohci0 usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: nVidia at usbus0 uhub0: nVidia OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 ugen0.2: vendor 0x055f at usbus0 ~ $ pciconf -l | grep hci ohci0@pci0:0:11:0: class=0x0c0310 card=0x81c01043 chip=0x026d10de rev=0xa3 hdr=0x00 ehci0@pci0:0:11:1: class=0x0c0320 card=0x81c01043 chip=0x026e10de rev=0xa3 hdr=0x00 ~ $ kldstat Id Refs AddressSize Name 1 33 0xc040 58ae60 kernel 22 0xc098b000 57964sound.ko 31 0xc09e3000 2abe8snd_hda.ko 41 0xc0a0e000 3288 speaker.ko 51 0xc0a12000 a91200 nvidia.ko 61 0xc14a4000 308c aibs.ko 71 0xc6169000 8000 linprocfs.ko 81 0xc6175000 4000 fdescfs.ko 91 0xc62eb000 2000 linux_adobe.ko 101 0xc6497000 2000 rtc.ko ~ $ kldstat -v | grep hci 131 ohci/usbus 130 uhci/usbus 129 ehci/usbus 128 xhci/usbus 124 pci/uhci 123 pci/ohci 42 pci/ata_ahci 122 pci/ehci 41 atapci/ata_ahci_ata ~ # kldload ehci module_register: module pci/ehci already exists! Module pci/ehci failed to register: 17 kldload: can't load ehci: File exists How I upgraded: rm -rf /usr/src svn export svn://svn0.us-east.FreeBSD.org/base/releng/8.4 /usr/src (created custom kernel config from GENERIC) cd /usr/obj chflags -R noschg * rm -rf * cd /usr/src make buildworld kernel shutdown -p now (boot in single user) fsck -p mount -a swapon -a cd /usr/src adjkerntz -i mergemaster -p make installworld make delete-old mergemaster -Fi shutdown -p now cd /usr/src make delete-old-libs In /etc/make.conf : KERNCONF=BEDSIDE INSTALL_NODEBUG=yes CPUTYPE?=athlon64 Custom kernel config in /usr/src/sys/i386/conf/BEDSIDE (I edited from GENERIC 8.4): # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: sys/i386/conf/GENERIC 247909 2013-03-07 07:28:05Z bryanv $ #lena cpu I486_CPU #lena cpu I586_CPU cpu I686_CPU ident BEDSIDE #lena was GENERIC # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. # Use the following to compile in values accessible to the kernel #
Re: 8.4 and EHCI - regression?
- Original Message - From: l...@lena.kiev.ua After upgrade from 8.3 to 8.4, ehci (USB 2.0) disappeared from `dmesg`. Details: ... Does a verbose boot give you any insight? This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.4 and EHCI - never mind
From: Steven Hartland After upgrade from 8.3 to 8.4, ehci (USB 2.0) disappeared from `dmesg`. Does a verbose boot give you any insight? Thank you, it was my fault: hint.ehci.0.disabled=1 in /boot/device.hints I can't recall what I tried to fix when I wrote that. It didn't work in 8.3 but works in 8.4. I commented it out, ECHI reappeared. Sorry and thank you. Lena ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.4 and EHCI - never mind
On 06/09/13 21:00, l...@lena.kiev.ua wrote: From: Steven Hartland After upgrade from 8.3 to 8.4, ehci (USB 2.0) disappeared from `dmesg`. Does a verbose boot give you any insight? Thank you, it was my fault: hint.ehci.0.disabled=1 in /boot/device.hints I can't recall what I tried to fix when I wrote that. It didn't work in 8.3 but works in 8.4. I commented it out, ECHI reappeared. Sorry and thank you. No, problem :-) --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fxp0 interface going up/down/up/down (dhclient related?)
On Sun, Jun 09, 2013 at 03:39:45PM +0200, Alban Hertroys wrote: On Jun 9, 2013, at 13:45, YongHyeon PYUN pyu...@gmail.com wrote: On Sun, Jun 09, 2013 at 12:21:37PM +0200, Alban Hertroys wrote: I'm having an issue where my fxp0 interface keeps looping between DOWN/UP, with dhclient requesting a lease each time in between. I think it's caused by dhclient: solfertje # dhclient -d fxp0 DHCPREQUEST on fxp0 to 255.255.255.255 port 67 send_packet: Network is down DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down fxp0 link state down - up DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 109.72.40.1 bound to 141.105.10.89 -- renewal in 7200 seconds. fxp0 link state up - down ^C In above test I turned off devd (/etc/rc.d/devd stop) and background dhclient (/etc/rc.d/dhclient stop fxp0), and I still go the above result. There's practically no time spent between up/down cycles, this just keeps going on and on. fxp0 is the only interface that runs on DHCP. The others have static IP's. Try attached patch and let me know whether it also works for you. fxp.init.diff I'm now running with this patch and the symptoms seem to have gone away. Thanks! Is there anything I should be aware of with this patch or anything you'd like to know about how it runs? No, I already tested the patch and will commit today. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fxp0 interface going up/down/up/down (dhclient related?)
On Sun, Jun 09, 2013 at 09:13:33PM +0400, Lev Serebryakov wrote: Hello, Jeremy. You wrote 9 июня 2013 г., 14:44:01: JC The issue is described in the 8.4-RELEASE Errata Notes; the driver is JC using the same driver version as in stable/9, hence you're experiencing JC the same problem. See Open Issues: I had some memory, that I had had this problem on my router some time (year? two years? three?) ago, and it was fixed somehow at then-HEAD (9?) system with disabling link down event on fxp(4), caused by chip reset after address setting. Is it deja-vu or true memory? There was a bug at the time but it was fixed long time ago. Current issue is different one but the end result looks very similar to the old bug. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Multicast panic caused by elasticsearch
On Jun 8, 2013, at 9:33 PM, Daniel O'Connor docon...@gsoft.com.au wrote: On 09/06/2013, at 11:45, Daniel O'Connor docon...@gsoft.com.au wrote: On 09/06/2013, at 3:00, Guy Helmer guy.hel...@gmail.com wrote: uname is.. FreeBSD maarsy-rdb.maarsy.rocketrange.no 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r224195: Tue Jul 19 17:45:03 CST 2011 ra...@maarsy-acq3.gsoft.com.au:/usr/obj/usr/src/sys/GENERIC amd64 FWIW, I have not had any problem with elasticsearch on 9.1-stable from about mid-May. OK thanks. I need to try it on a crash box and test a few things, thanks for the data point. Can you tell me what revision you are running? Also, which JVM? FreeBSD 9.1-stable r250314 (built on May 10) openjdk-7.17.02_2 elasticsearch 0.90.0 (not from ports) Please let me know if you want me to try anything. Guy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
