Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R
On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote:
> Regarding the 8.1 if_rum(4) panics... I got a similar one, extracted
> a dump and tried to gather some info for someone who knows the code:
>
> The zero divide fault was because (apparently) rate was unitialized,
> as is
>
> ((struct ieee80211_node *)
> m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms[0]
>
> i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters.
Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0
This can be mitigated by patch [1] or by setting ucastrate option in
ifconfig. Still real issue need to be solved.
--
Adios
Index: sys/dev/usb/wlan/if_rum.c
@@ -1153,9 +1153,11 @@
rate = params->ibp_rate0;
if (!ieee80211_isratevalid(ic->ic_rt, rate)) {
+ device_printf(sc->sc_dev, "invalid rate=%d\n", rate);
m_freem(m0);
return EINVAL;
}
+
flags = 0;
if ((params->ibp_flags & IEEE80211_BPF_NOACK) == 0)
flags |= RT2573_TX_NEED_ACK;
@@ -1217,6 +1219,13 @@
else
rate = ni->ni_txrate;
+ /* XXX ieee80211_ratectl sometimes set ni->ni_txrate to 0 */
+ if (!ieee80211_isratevalid(ic->ic_rt, rate)) {
+ device_printf(sc->sc_dev, "invalid rate=%d\n", rate);
+ m_freem(m0);
+ return EINVAL;
+ }
+
if (wh->i_fc[1] & IEEE80211_FC1_WEP) {
k = ieee80211_crypto_encap(ni, m0);
if (k == NULL) {
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R
The following reply was made to PR kern/149185; it has been noted by GNATS.
From: Alex Kozlov
To: n...@freebsd.org, rpa...@freebsd.org, freebsd-net@FreeBSD.org,
bug-follo...@freebsd.org, s...@rm-rf.kiev.ua
Cc:
Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R
Date: Thu, 5 Aug 2010 09:52:16 +0300
--Q68bSM7Ycu6FN28Q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote:
> Regarding the 8.1 if_rum(4) panics... I got a similar one, extracted
> a dump and tried to gather some info for someone who knows the code:
>
> The zero divide fault was because (apparently) rate was unitialized,
> as is
>
> ((struct ieee80211_node *)
> m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms[0]
>
> i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters.
Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0
This can be mitigated by patch [1] or by setting ucastrate option in
ifconfig. Still real issue need to be solved.
--
Adios
--Q68bSM7Ycu6FN28Q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="patch.txt"
Index: sys/dev/usb/wlan/if_rum.c
@@ -1153,9 +1153,11 @@
rate = params->ibp_rate0;
if (!ieee80211_isratevalid(ic->ic_rt, rate)) {
+ device_printf(sc->sc_dev, "invalid rate=%d\n", rate);
m_freem(m0);
return EINVAL;
}
+
flags = 0;
if ((params->ibp_flags & IEEE80211_BPF_NOACK) == 0)
flags |= RT2573_TX_NEED_ACK;
@@ -1217,6 +1219,13 @@
else
rate = ni->ni_txrate;
+ /* XXX ieee80211_ratectl sometimes set ni->ni_txrate to 0 */
+ if (!ieee80211_isratevalid(ic->ic_rt, rate)) {
+ device_printf(sc->sc_dev, "invalid rate=%d\n", rate);
+ m_freem(m0);
+ return EINVAL;
+ }
+
if (wh->i_fc[1] & IEEE80211_FC1_WEP) {
k = ieee80211_crypto_encap(ni, m0);
if (k == NULL) {
--Q68bSM7Ycu6FN28Q--
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/149306: [alc] Doesn't work Atheros AR8131 PCIe Gigabit Ethernet
Old Synopsis: Doesn't work Atheros AR8131 PCIe Gigabit Ethernet New Synopsis: [alc] Doesn't work Atheros AR8131 PCIe Gigabit Ethernet Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 5 08:05:13 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=149306 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/149307: [ath] Doesn't work Atheros 9285
Old Synopsis: Doesn't work Atheros 9285 New Synopsis: [ath] Doesn't work Atheros 9285 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 5 08:05:47 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=149307 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R
The following reply was made to PR kern/149185; it has been noted by GNATS. From: Bernhard Schmidt To: Alex Kozlov , bug-follo...@freebsd.org Cc: n...@freebsd.org, rpa...@freebsd.org Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Thu, 5 Aug 2010 10:05:39 +0200 On Thu, Aug 5, 2010 at 08:52, Alex Kozlov wrote: > On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: >> =A0Regarding the 8.1 if_rum(4) panics... =A0I got a similar one, extract= ed >> a dump and tried to gather some info for someone who knows the code: >> >> =A0The zero divide fault was because (apparently) rate was unitialized, >> as is >> >> =A0 =A0 =A0 ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_= vap->iv_txparms[0] >> >> i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. > Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0 > This can be mitigated by patch [1] or by setting ucastrate option in > ifconfig. Still real issue need to be solved. The real issue is that prior to an association (RUN state) ieee80211_ratectl_node_init() is not called, therefore iv_bss is not configured in any way. I'll look into that if no one beats me. --=20 Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159
The following reply was made to PR kern/144755; it has been noted by GNATS. From: Bernhard Schmidt To: Edwin Groothuis , bug-follo...@freebsd.org Cc: Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159 Date: Thu, 5 Aug 2010 10:08:42 +0200 On Thu, Aug 5, 2010 at 00:31, Edwin Groothuis wrote: > Hello Bernhard! > > On Wed, Jul 28, 2010 at 12:11:17PM +0200, Bernhard Schmidt wrote: >> Can you check if wpa_supplicant gets started twice after >> "/etc/rc.d/netif restart"? > > According to core.txt there are two wpa_supplicant processes, but > I don't know if it is caused by a fork of itself or if it is caused > by something started twice: > > =A0 =A00 =A07084 =A0 =A0 1 =A0 0 =A056 =A00 =A05192 =A0 =A0 0 select Ds = =A0 =A0?? =A03686:38.00 [wpa_suppli > =A0 =A00 =A07085 =A0 =A0 1 =A0 0 =A057 =A00 =A05192 =A0 =A0 0 select Ds = =A0 =A0?? =A02617:11.00 [wpa_suppli > > Based on the PPID of 1 for both, I would say it gets started twice. Indeed. > > [..] >> I have the feeling that this is a more or less known issue, a race >> between devd (/etc/pccard_ether) and /etc/rc.d/netif. There is a small >> window (a few ms) where this can happen and our net80211 isn't capable >> of handling two running wpa_supplicants on the same interface. Which >> leads to all kind of weird issues, .e.g. panics. > > Nice! Is there a workaround or patch available for testing? A temporary workaround is to add a "sleep 1" in /etc/pccard_ether, something I'd rather not commit. I haven't yet found a clean solution for this.. any pointers welcome. :) --=20 Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R
The following reply was made to PR kern/149185; it has been noted by GNATS. From: Alex Kozlov To: Bernhard Schmidt , bug-follo...@freebsd.org, n...@freebsd.org, rpa...@freebsd.org, s...@rm-rf.kiev.ua Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Thu, 5 Aug 2010 12:11:05 +0300 On Thu, Aug 05, 2010 at 10:05:39AM +0200, Bernhard Schmidt wrote: > On Thu, Aug 5, 2010 at 08:52, Alex Kozlov wrote: > > On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: > >> Regarding the 8.1 if_rum(4) panics... I got a similar one, extracted > >> a dump and tried to gather some info for someone who knows the code: > >> > >> The zero divide fault was because (apparently) rate was unitialized, > >> as is > >> > >> ((struct ieee80211_node *) > >> m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms[0] > >> > >> i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. > > Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0 > > This can be mitigated by patch [1] or by setting ucastrate option in > > ifconfig. Still real issue need to be solved. > > The real issue is that prior to an association (RUN state) > ieee80211_ratectl_node_init() is not called, therefore iv_bss is not > configured in any way. ieee80211_ratectl_node_init() called from iv_newstate when switching to IEEE80211_S_RUN state. Most drivers do the same. Is it wrong? Some call it from iv_newassoc, but this marked /* XXX move */ > I'll look into that if no one beats me. Thanks. -- Adios ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R
The following reply was made to PR kern/149185; it has been noted by GNATS. From: Bernhard Schmidt To: Alex Kozlov , bug-follo...@freebsd.org Cc: n...@freebsd.org, rpa...@freebsd.org Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Thu, 5 Aug 2010 11:34:35 +0200 On Thu, Aug 5, 2010 at 11:11, Alex Kozlov wrote: > On Thu, Aug 05, 2010 at 10:05:39AM +0200, Bernhard Schmidt wrote: >> On Thu, Aug 5, 2010 at 08:52, Alex Kozlov wrote: >> > On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: >> >> =A0Regarding the 8.1 if_rum(4) panics... =A0I got a similar one, extr= acted >> >> a dump and tried to gather some info for someone who knows the code: >> >> >> >> =A0The zero divide fault was because (apparently) rate was unitialize= d, >> >> as is >> >> >> >> =A0 =A0 =A0 ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->= ni_vap->iv_txparms[0] >> >> >> >> i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. >> > Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0 >> > This can be mitigated by patch [1] or by setting ucastrate option in >> > ifconfig. Still real issue need to be solved. >> >> The real issue is that prior to an association (RUN state) >> ieee80211_ratectl_node_init() is not called, therefore iv_bss is not >> configured in any way. > ieee80211_ratectl_node_init() called from iv_newstate when switching to > IEEE80211_S_RUN state. Most drivers do the same. Is it wrong? > Some call it from iv_newassoc, but this marked /* XXX move */ It is not wrong, but to late. Before RUN state and the iv_newassoc() call, you have to send frames for scanning and authentication, those need a valid rate too. I wonder if we can call node_init() in ieee80211_vap_setup() or something similar, that would definitely be early enough. >> I'll look into that if no one beats me. > Thanks. --=20 Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R
The following reply was made to PR kern/149185; it has been noted by GNATS. From: Rui Paulo To: Bernhard Schmidt Cc: Alex Kozlov , bug-follo...@freebsd.org, n...@freebsd.org Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Thu, 5 Aug 2010 10:38:44 +0100 On 5 Aug 2010, at 10:34, Bernhard Schmidt wrote: > On Thu, Aug 5, 2010 at 11:11, Alex Kozlov wrote: >> On Thu, Aug 05, 2010 at 10:05:39AM +0200, Bernhard Schmidt wrote: >>> On Thu, Aug 5, 2010 at 08:52, Alex Kozlov = wrote: On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: > Regarding the 8.1 if_rum(4) panics... I got a similar one, = extracted > a dump and tried to gather some info for someone who knows the = code: >=20 > The zero divide fault was because (apparently) rate was = unitialized, > as is >=20 > ((struct ieee80211_node *) = m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms[0] >=20 > i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it = matters. Yes, its seems that ratectl framework sometimes set ni->ni_txrate = to 0 This can be mitigated by patch [1] or by setting ucastrate option = in ifconfig. Still real issue need to be solved. >>>=20 >>> The real issue is that prior to an association (RUN state) >>> ieee80211_ratectl_node_init() is not called, therefore iv_bss is not >>> configured in any way. >> ieee80211_ratectl_node_init() called from iv_newstate when switching = to >> IEEE80211_S_RUN state. Most drivers do the same. Is it wrong? >> Some call it from iv_newassoc, but this marked /* XXX move */ >=20 > It is not wrong, but to late. Before RUN state and the iv_newassoc() > call, you have to send frames for scanning and authentication, those > need a valid rate too. I wonder if we can call node_init() in > ieee80211_vap_setup() or something similar, that would definitely be > early enough. vap_setup() runs once and we need need to call node_init for each node = connected to an AP or for the AP node when the vap is a STA. Regards, -- Rui Paulo ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R
The following reply was made to PR kern/149185; it has been noted by GNATS. From: Bernhard Schmidt To: Alex Kozlov Cc: bug-follo...@freebsd.org, Juergen Lock , rpa...@freebsd.org Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Thu, 5 Aug 2010 18:25:32 +0200 --00c09f89939bd0b2e9048d15ff5b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Aug 5, 2010 at 11:11, Alex Kozlov wrote: > On Thu, Aug 05, 2010 at 10:05:39AM +0200, Bernhard Schmidt wrote: >> On Thu, Aug 5, 2010 at 08:52, Alex Kozlov wrote: >> > On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: >> >> =A0Regarding the 8.1 if_rum(4) panics... =A0I got a similar one, extr= acted >> >> a dump and tried to gather some info for someone who knows the code: >> >> >> >> =A0The zero divide fault was because (apparently) rate was unitialize= d, >> >> as is >> >> >> >> =A0 =A0 =A0 ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->= ni_vap->iv_txparms[0] >> >> >> >> i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. >> > Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0 >> > This can be mitigated by patch [1] or by setting ucastrate option in >> > ifconfig. Still real issue need to be solved. >> >> The real issue is that prior to an association (RUN state) >> ieee80211_ratectl_node_init() is not called, therefore iv_bss is not >> configured in any way. > ieee80211_ratectl_node_init() called from iv_newstate when switching to > IEEE80211_S_RUN state. Most drivers do the same. Is it wrong? > Some call it from iv_newassoc, but this marked /* XXX move */ > >> I'll look into that if no one beats me. > Thanks. Please give attached patch a try, it should fix the issue for rum and all other drivers relying on the new ratectl stuff. Thanks --=20 Bernhard --00c09f89939bd0b2e9048d15ff5b Content-Type: application/octet-stream; name="net80211_ratectl_node_init.diff" Content-Disposition: attachment; filename="net80211_ratectl_node_init.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gchtkki90 SW5kZXg6IHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfbm9kZS5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9u ZXQ4MDIxMS9pZWVlODAyMTFfbm9kZS5jCShyZXZpc2lvbiAyMTA4NjIpCisrKyBzeXMvbmV0ODAy MTEvaWVlZTgwMjExX25vZGUuYwkod29ya2luZyBjb3B5KQpAQCAtODE3LDYgKzgxNyw3IEBAIGll ZWU4MDIxMV9zdGFfam9pbihzdHJ1Y3QgaWVlZTgwMjExdmFwICp2YXAsIHN0cnVjCiAJaWYgKGll ZWU4MDIxMV9pc2VycF9yYXRlc2V0KCZuaS0+bmlfcmF0ZXMpKQogCQluaS0+bmlfZmxhZ3MgfD0g SUVFRTgwMjExX05PREVfRVJQOwogCWllZWU4MDIxMV9ub2RlX3NldHVwdHhwYXJtcyhuaSk7CisJ aWVlZTgwMjExX3JhdGVjdGxfbm9kZV9pbml0KG5pKTsKIAogCXJldHVybiBpZWVlODAyMTFfc3Rh X2pvaW4xKGllZWU4MDIxMV9yZWZfbm9kZShuaSkpOwogfQpAQCAtMTQwMSw2ICsxNDAyLDcgQEAg aWVlZTgwMjExX2Zha2V1cF9hZGhvY19ub2RlKHN0cnVjdCBpZWVlODAyMTF2YXAgKnYKICNlbmRp ZgogCQl9CiAJCWllZWU4MDIxMV9ub2RlX3NldHVwdHhwYXJtcyhuaSk7CisJCWllZWU4MDIxMV9y YXRlY3RsX25vZGVfaW5pdChuaSk7CiAJCWlmIChpYy0+aWNfbmV3YXNzb2MgIT0gTlVMTCkKIAkJ CWljLT5pY19uZXdhc3NvYyhuaSwgMSk7CiAJCS8qIFhYWCBub3QgcmlnaHQgZm9yIDgwMi4xeC9X UEEgKi8KQEAgLTE0NzAsNiArMTQ3Miw3IEBAIGllZWU4MDIxMV9hZGRfbmVpZ2hib3Ioc3RydWN0 IGllZWU4MDIxMXZhcCAqdmFwLAogCQlpZiAoaWVlZTgwMjExX2lzZXJwX3JhdGVzZXQoJm5pLT5u aV9yYXRlcykpCiAJCQluaS0+bmlfZmxhZ3MgfD0gSUVFRTgwMjExX05PREVfRVJQOwogCQlpZWVl ODAyMTFfbm9kZV9zZXR1cHR4cGFybXMobmkpOworCQlpZWVlODAyMTFfcmF0ZWN0bF9ub2RlX2lu aXQobmkpOwogCQlpZiAoaWMtPmljX25ld2Fzc29jICE9IE5VTEwpCiAJCQlpYy0+aWNfbmV3YXNz b2MobmksIDEpOwogCQkvKiBYWFggbm90IHJpZ2h0IGZvciA4MDIuMXgvV1BBICovCkBAIC0yMzM4 LDYgKzIzNDEsNyBAQCBpZWVlODAyMTFfbm9kZV9qb2luKHN0cnVjdCBpZWVlODAyMTFfbm9kZSAq bmksIGludAogCSk7CiAKIAlpZWVlODAyMTFfbm9kZV9zZXR1cHR4cGFybXMobmkpOworCWllZWU4 MDIxMV9yYXRlY3RsX25vZGVfaW5pdChuaSk7CiAJLyogZ2l2ZSBkcml2ZXIgYSBjaGFuY2UgdG8g c2V0dXAgc3RhdGUgbGlrZSBuaV90eHJhdGUgKi8KIAlpZiAoaWMtPmljX25ld2Fzc29jICE9IE5V TEwpCiAJCWljLT5pY19uZXdhc3NvYyhuaSwgbmV3YXNzb2MpOwpJbmRleDogc3lzL25ldDgwMjEx L2llZWU4MDIxMV9zdGEuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX3N0 YS5jCShyZXZpc2lvbiAyMTA4NjIpCisrKyBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX3N0YS5jCSh3 b3JraW5nIGNvcHkpCkBAIC02MCw2ICs2MCw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNp ZmRlZiBJRUVFODAyMTFfU1VQUE9SVF9TVVBFUkcKICNpbmNsdWRlIDxuZXQ4MDIxMS9pZWVlODAy MTFfc3VwZXJnLmg+CiAjZW5kaWYKKyNpbmNsdWRlIDxuZXQ4MDIxMS9pZWVlODAyMTFfcmF0ZWN0 bC5oPgogCiAjZGVmaW5lCUlFRUU4MDIxMV9SQVRFMk1CUyhyKQkoKChyKSAmIElFRUU4MDIxMV9S QVRFX1ZBTCkgLyAyKQogCkBAIC0xNTk2LDYgKzE1OTcsNyBAQCBzdGFfcmVjdl9tZ210KHN0cnVj dCBpZWVlODAyMTFfbm9kZSAqbmksIHN0cnVjdCBtYgogCQkJICAgICBJRUVFODAyMTFfRl9KT0lO IHwgSUVFRTgwMjExX0ZfRE9CUlMpOwogCQkJaWVlZTgwMjExX3NldHVwX2Jhc2ljX2h0cmF0ZXMo bmksIGh0aW5mbyk7CiAJCQlpZWVlODAyMTFfbm9kZV9zZXR1cHR4cGFybXMobmkpOworCQkJaWVl ZTgwMjExX3JhdGVjdGxfbm9kZV9pbml0KG5pKTsKIAkJfSBlbHNlIHsKICNpZmRlZiBJRUVFODAy MTFfU1VQUE9SVF9TV
Re: 8.1-RELEASE em watchdog timeout broken?
I'm sending this out as an update to the net mailing list. The problem is that the PC running Windows XP was attempting DHCP on power up thru the bridge, and for some reason this fails in the 8.1 code, but the good news is its fixed in STABLE/8. So, I would recommend going to the STABLE/8 e1000 code as a first step if you are having any problems with any of the 1G drivers. Jack On Tue, Aug 3, 2010 at 7:02 PM, Scott Johnson wrote: > Under 8.0-RELEASE I would get warnings from em(4) in /var/log/messages > about > > "watchdog timeouts" on em0 whenever my desktop PC connected to em0 was > powered > off. This was fine, except for the annoying warnings. > > Under 8.1-RELEASE I no longer get the warnings, and any time my desktop is > powered off, when I turn it back on, it has no connectivity. The interface > is > dead until I log into the console and run: > # ifconfig em0 down up > > The em(4) driver has changed a lot since 8.0-RELEASE. It seems this > watchdog > timeout is no longer working. > > The board is a Supermicro X7SPA-H with Intel 82574L GbE. > > Any ideas for debugging? > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/149307: [ath] Doesn't work Atheros 9285
The following reply was made to PR kern/149307; it has been noted by GNATS. From: Troye Johnson To: bug-follo...@freebsd.org, aksen...@gmail.com Cc: Subject: Re: kern/149307: [ath] Doesn't work Atheros 9285 Date: Thu, 5 Aug 2010 17:12:56 + --000e0cd2e71e59326d048d16a94b Content-Type: text/plain; charset=ISO-8859-1 The chip scans and associates (according to 'ifconfig') but 'dhclient wlan0' and '/etc/rc.d/netif start' both cannot establish IP. There are multiple PRs out on this issue. PR:kern/148112 is one of them. I will test as soon as word gets out on the mailing list. --000e0cd2e71e59326d048d16a94b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The chip scans and associates (according to 'ifconfig') but 'dh= client wlan0' and '/etc/rc.d/netif start' both cannot establish= IP. There are multiple PRs out on this issue. PR:kern/148112 is one of the= m. I will test as soon as word gets out on the mailing list. --000e0cd2e71e59326d048d16a94b-- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/149306: [alc] Doesn't work Atheros AR8131 PCIe Gigabit Ethernet
The following reply was made to PR kern/149306; it has been noted by GNATS. From: Troye Johnson To: bug-follo...@freebsd.org, aksen...@gmail.com Cc: Subject: Re: kern/149306: [alc] Doesn't work Atheros AR8131 PCIe Gigabit Ethernet Date: Thu, 5 Aug 2010 17:16:07 + --000e0cd51986b1efd9048d16b405 Content-Type: text/plain; charset=ISO-8859-1 I think this is misfiled as I have this chip and it is detected properly and and I can transfer files over the link in 100mbit. Misfiled/erroneous PR? --000e0cd51986b1efd9048d16b405 Content-Type: text/html; charset=ISO-8859-1 I think this is misfiled as I have this chip and it is detected properly and and I can transfer files over the link in 100mbit. Misfiled/erroneous PR? --000e0cd51986b1efd9048d16b405-- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R
The following reply was made to PR kern/149185; it has been noted by GNATS. From: Alex Kozlov To: Bernhard Schmidt , bug-follo...@freebsd.org, s...@rm-rf.kiev.ua Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Thu, 5 Aug 2010 21:14:41 +0300 On Thu, Aug 05, 2010 at 06:25:32PM +0200, Bernhard Schmidt wrote: > On Thu, Aug 5, 2010 at 11:11, Alex Kozlov wrote: > > On Thu, Aug 05, 2010 at 10:05:39AM +0200, Bernhard Schmidt wrote: > >> On Thu, Aug 5, 2010 at 08:52, Alex Kozlov wrote: > >> > On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: > >> >> Regarding the 8.1 if_rum(4) panics... I got a similar one, extracted > >> >> a dump and tried to gather some info for someone who knows the code: > >> >> > >> >> The zero divide fault was because (apparently) rate was unitialized, > >> >> as is > >> >> > >> >> ((struct ieee80211_node *) > >> >> m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms[0] > >> >> > >> >> i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. > >> > Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0 > >> > This can be mitigated by patch [1] or by setting ucastrate option in > >> > ifconfig. Still real issue need to be solved. > >> > >> The real issue is that prior to an association (RUN state) > >> ieee80211_ratectl_node_init() is not called, therefore iv_bss is not > >> configured in any way. > > ieee80211_ratectl_node_init() called from iv_newstate when switching to > > IEEE80211_S_RUN state. Most drivers do the same. Is it wrong? > > Some call it from iv_newassoc, but this marked /* XXX move */ > >> I'll look into that if no one beats me. > > Thanks. > Please give attached patch a try, it should fix the issue for rum and > all other drivers relying on the new ratectl stuff. Testing. Thanks again. -- Adios ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159
The following reply was made to PR kern/144755; it has been noted by GNATS. From: Bernhard Schmidt To: Edwin Groothuis Cc: bug-follo...@freebsd.org Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159 Date: Thu, 5 Aug 2010 22:08:38 +0200 --0015175cda7eab5eec048d191d67 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 5, 2010 at 00:31, Edwin Groothuis wrote: > [..] > Nice! Is there a workaround or patch available for testing? Please give the attached patch a try. It does not prevent wpa_supplicant from starting twice (for that you can define ctrl_interface= in wpa_supplicant.conf), but should no longer panic. Thanks. -- Bernhard --0015175cda7eab5eec048d191d67 Content-Type: application/octet-stream; name="iwi_node_ref.diff" Content-Disposition: attachment; filename="iwi_node_ref.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gci1jhyx0 SW5kZXg6IHN5cy9kZXYvaXdpL2lmX2l3aS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvaXdpL2lm X2l3aS5jCShyZXZpc2lvbiAyMTA4NzMpCisrKyBzeXMvZGV2L2l3aS9pZl9pd2kuYwkod29ya2lu ZyBjb3B5KQpAQCAtMTM2MiwxMyArMTM2MiwxNCBAQCBpd2lfY2hlY2tmb3Jxb3Moc3RydWN0IGll ZWU4MDIxMXZhcCAqdmFwLAogCQlmcm0gKz0gZnJtWzFdICsgMjsKIAl9CiAKLQluaSA9IHZhcC0+ aXZfYnNzOworCW5pID0gaWVlZTgwMjExX3JlZl9ub2RlKHZhcC0+aXZfYnNzKTsKIAluaS0+bmlf Y2FwaW5mbyA9IGNhcGluZm87CiAJbmktPm5pX2Fzc29jaWQgPSBhc3NvY2lkOwogCWlmICh3bWUg IT0gTlVMTCkKIAkJbmktPm5pX2ZsYWdzIHw9IElFRUU4MDIxMV9OT0RFX1FPUzsKIAllbHNlCiAJ CW5pLT5uaV9mbGFncyAmPSB+SUVFRTgwMjExX05PREVfUU9TOworCWllZWU4MDIxMV9mcmVlX25v ZGUobmkpOwogI3VuZGVmIFNVQlRZUEUKIH0KIApAQCAtMjc3OSw3ICsyNzgwLDcgQEAgaXdpX2F1 dGhfYW5kX2Fzc29jKHN0cnVjdCBpd2lfc29mdGMgKnNjLCBzdHJ1Y3QgaWUKIHsKIAlzdHJ1Y3Qg aWVlZTgwMjExY29tICppYyA9IHZhcC0+aXZfaWM7CiAJc3RydWN0IGlmbmV0ICppZnAgPSB2YXAt Pml2X2lmcDsKLQlzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pID0gdmFwLT5pdl9ic3M7CisJc3Ry dWN0IGllZWU4MDIxMV9ub2RlICpuaSA9IGllZWU4MDIxMV9yZWZfbm9kZSh2YXAtPml2X2Jzcyk7 CiAJc3RydWN0IGl3aV9jb25maWd1cmF0aW9uIGNvbmZpZzsKIAlzdHJ1Y3QgaXdpX2Fzc29jaWF0 ZSAqYXNzb2MgPSAmc2MtPmFzc29jOwogCXN0cnVjdCBpd2lfcmF0ZXNldCByczsKQEAgLTI5NDcs NiArMjk0OCw3IEBAIGl3aV9hdXRoX2FuZF9hc3NvYyhzdHJ1Y3QgaXdpX3NvZnRjICpzYywgc3Ry dWN0IGllCiAJICAgIGxlMTZ0b2goYXNzb2MtPmludHZhbCkpKTsKIAllcnJvciA9IGl3aV9jbWQo c2MsIElXSV9DTURfQVNTT0NJQVRFLCBhc3NvYywgc2l6ZW9mICphc3NvYyk7CiBkb25lOgorCWll ZWU4MDIxMV9mcmVlX25vZGUobmkpOwogCWlmIChlcnJvcikKIAkJSVdJX1NUQVRFX0VORChzYywg SVdJX0ZXX0FTU09DSUFUSU5HKTsKIAo= --0015175cda7eab5eec048d191d67-- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/149086: [multicast] Generic multicast join failure in 8.1
The following reply was made to PR kern/149086; it has been noted by GNATS.
From: Hans-Werner Braun
To: bug-follo...@freebsd.org, h...@ucsd.edu
Cc:
Subject: Re: kern/149086: [multicast] Generic multicast join failure in 8.1
Date: Thu, 5 Aug 2010 13:20:56 -0700
A program that is a straight adaptation from the IO::Socket::Multicast
man page does not work either:
#!/usr/local/bin/perl
use strict;
use IO::Socket::Multicast;
use constant GROUP => '233.7.117.79';
use constant PORT => '4011';
my $sock = IO::Socket::Multicast->new(Proto=>'udp',LocalPort=>PORT);
$sock->mcast_add(GROUP) || die "Couldn't set group: $!\n";
while (1) {
my $data;
next unless $sock->recv($data,1024);
print $data;
}
It only displays data if the multicast stream already exists on the
local Ethernet, but it does not send the group join request out to
initiate the receiving stream on the local Ethernet.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159
The following reply was made to PR kern/144755; it has been noted by GNATS.
From: Alex Kozlov
To: Bernhard Schmidt ,
Edwin Groothuis , bug-follo...@freebsd.org,
s...@rm-rf.kiev.ua
Cc:
Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing
/etc/rc.d/netif restart on 8-STABLE r205159
Date: Thu, 5 Aug 2010 23:55:43 +0300
--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Thu, Aug 05, 2010 at 08:10:08PM +, Bernhard Schmidt wrote:
> The following reply was made to PR kern/144755; it has been noted by GNATS.
>
> From: Bernhard Schmidt
> To: Edwin Groothuis
> Cc: bug-follo...@freebsd.org
> Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing
> /etc/rc.d/netif
> restart on 8-STABLE r205159
> Date: Thu, 5 Aug 2010 22:08:38 +0200
>
> --0015175cda7eab5eec048d191d67
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, Aug 5, 2010 at 00:31, Edwin Groothuis wrote:
> > [..]
> > Nice! Is there a workaround or patch available for testing?
>
> Please give the attached patch a try. It does not prevent
> wpa_supplicant from starting twice (for that you can define
> ctrl_interface= in wpa_supplicant.conf), but should no longer panic.
I can reproduce this panic for if_rum, similiar patch also helps.
wlan0: ieee80211_new_state_locked: pending RUN -> SCAN transition lost
wlan0: ieee80211_new_state_locked: pending RUN -> SCAN transition lost
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x
fault code = supervisor read, page not present
instruction pointer= 0x20:0xc0900d42
stack pointer = 0x28:0xc4f05bac
frame pointer = 0x28:0xc4f05bb8
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process= 0 (rum0 taskq)
trap number= 12
panic: page fault
KDB: stack backtrace:
db_trace_self_wrapper(c0669547,c06cb000,c0660c6a,c4f05a5c,c4f05a5c,...) at
0xc0436706 = db_trace_self_wrapper+0x26
panic(c0660c6a,c0680c79,c4f05b6c,1,1,...) at 0xc04b898d = panic+0xed
trap_fatal(c06c9740,f000,1,0,c04c0ef6,...) at 0xc06474bd = trap_fatal+0x23d
trap_pfault(0,c066c5e8,2d7,0,c06c9220,...) at 0xc064787a = trap_pfault+0x27a
trap(c4f05b6c) at 0xc06481ab = trap+0x39b
calltrap() at 0xc062d4ac = calltrap+0x6
--- trap 0xc, eip = 0xc0900d42, esp = 0xc4f05bac, ebp = 0xc4f05bb8 ---
ieee80211_getcapinfo(c5caa000,,c08f415a,c5caa874,c5463d00,...) at
0xc0900d42 = ieee80211_getcapinfo+0x71
ieee80211_beacon_construct(c62a8000,18,676,c50f5c00,c54e3988,...) at
0xc090308d = ieee80211_beacon_construct+0x67
ieee80211_beacon_alloc(c62a8000,c5caa874,6,2c5,5,...) at 0xc09039a0 =
ieee80211_beacon_alloc+0x93
rum_newstate(c5caa000,5,,652,c5362014,...) at 0xc9a9b55f =
rum_newstate+0x259
ieee80211_newstate_cb(c5caa000,4,0,c0695c9c,0,...) at 0xc0906eb8 =
ieee80211_newstate_cb+0x7a
taskqueue_run(c537db00,c537db18,0,c0661905,0,...) at 0xc04ef61a =
taskqueue_run+0x8a
taskqueue_thread_loop(c5362074,c4f05d38,0,0,0,...) at 0xc04efd74 =
taskqueue_thread_loop+0x44
fork_exit(c04efd30,c5362074,c4f05d38) at 0xc048e868 = fork_exit+0x88
fork_trampoline() at 0xc062d524 = fork_trampoline+0x8
--
Adios
--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="patch.txt"
Index: sys/dev/usb/wlan/if_rum.c
@@ -719,7 +719,7 @@
break;
case IEEE80211_S_RUN:
- ni = vap->iv_bss;
+ ni = ieee80211_ref_node(vap->iv_bss);
if (vap->iv_opmode != IEEE80211_M_MONITOR) {
rum_update_slot(ic->ic_ifp);
@@ -743,6 +743,7 @@
tp = &vap->iv_txparms[ieee80211_chan2mode(ic->ic_curchan)];
if (tp->ucastrate == IEEE80211_FIXED_RATE_NONE)
rum_ratectl_start(sc, ni);
+ ieee80211_free_node(ni);
break;
default:
break;
@@ -2216,7 +2217,7 @@
struct ieee80211com *ic = vap->iv_ic;
struct ifnet *ifp = ic->ic_ifp;
struct rum_softc *sc = ifp->if_softc;
- struct ieee80211_node *ni = vap->iv_bss;
+ struct ieee80211_node *ni;
int ok, fail;
int sum, retrycnt;
@@ -2230,8 +2231,10 @@
sum = ok+fail;
retrycnt = (le32toh(sc->sta[5]) & 0x) + fail;
+ ni = ieee80211_ref_node(vap->iv_bss);
ieee80211_ratectl_tx_update(vap, ni, &sum, &ok, &retrycnt);
(void) ieee80211_ratectl_rate(ni, NULL, 0);
+ ieee80211_free_node(ni);
ifp->if_oerrors += fail;/* count TX retry-fail as Tx errors */
--mYCpIKhGyMATD0i+--
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscr
Re: kern/144898: [wpi] [panic] wpi panics system
The following reply was made to PR kern/144898; it has been noted by GNATS.
From: Alex Kozlov
To: Dominic Fandrey , bug-follo...@freebsd.org,
s...@rm-rf.kiev.ua
Cc:
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Fri, 6 Aug 2010 00:52:26 +0300
--7AUc2qLy4jB3hD7Z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi, Dominic
It's seems to be common issue for many wireless if drivers.
Can You please try this patch? Thanks.
--
Adios
--7AUc2qLy4jB3hD7Z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="patch.txt"
Index: sys/dev/wpi/if_wpi.c
@@ -2399,7 +2399,7 @@
wpi_auth(struct wpi_softc *sc, struct ieee80211vap *vap)
{
struct ieee80211com *ic = vap->iv_ic;
- struct ieee80211_node *ni = vap->iv_bss;
+ struct ieee80211_node *ni = ieee80211_ref_node(vap->iv_bss);
struct wpi_node_info node;
int error;
@@ -2449,6 +2449,7 @@
node.action = htole32(WPI_ACTION_SET_RATE);
node.antenna = WPI_ANTENNA_BOTH;
error = wpi_cmd(sc, WPI_CMD_ADD_NODE, &node, sizeof node, 1);
+ ieee80211_free_node(ni);
if (error != 0)
device_printf(sc->sc_dev, "could not add BSS node\n");
@@ -2459,7 +2460,7 @@
wpi_run(struct wpi_softc *sc, struct ieee80211vap *vap)
{
struct ieee80211com *ic = vap->iv_ic;
- struct ieee80211_node *ni = vap->iv_bss;
+ struct ieee80211_node *ni = ieee80211_ref_node(vap->iv_bss);
int error;
if (vap->iv_opmode == IEEE80211_M_MONITOR) {
@@ -2493,8 +2494,9 @@
}
error = wpi_set_txpower(sc, ni->ni_chan, 1);
+ ieee80211_free_node(ni);
if (error != 0) {
- device_printf(sc->sc_dev, "could set txpower\n");
+ device_printf(sc->sc_dev, "could not set txpower\n");
return error;
}
--7AUc2qLy4jB3hD7Z--
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
