On Tuesday 29 July 2008 13:23, Linus Torvalds wrote:

> Other stuff? tracing. firmware loading. continued x86 arch merging. And
> moving more code to generic support (unified generic IPI handling,
> coherent dma memory allocation, show_mem etc). bootmem rewrites. Some
> support for further scalability (ie 4k cpu cores).

And lockless pagecache, woohoo!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi,

Just tried switching to 2.6.27-rc1 on my desktop, with a supported zd1211rw
device, and my wireless AP does not "authenticate". With 2.6.26 (the only
previous working version tested) I get the following in dmesg:

[ 17.481900] firmware: requesting zd1211/zd1211b_ub
[ 17.536820] firmware: requesting zd1211/zd1211b_uphr
[ 17.601837] zd1211rw 1-2:1.0: firmware version 4725
[ 17.602837] zd1211rw 1-2:1.0: zd1211b chip 050d:705c v4810 high 00-17-3f AL2230_RF pa0 g--NS
[ 18.613540] wlan0: Initial auth_alg=0
[ 18.613540] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
[ 18.622538] wlan0: RX authentication from 00:17:3f:a4:d6:9d (alg=0 transaction=2 status=0)
[ 18.622538] wlan0: authenticated
[ 18.622538] wlan0: associate with AP 00:17:3f:a4:d6:9d
[ 18.622538] wlan0: RX AssocResp from 00:17:3f:a4:d6:9d (capab=0x461 status=0 aid=2)
[ 18.622538] wlan0: associated
[ 18.622538] wlan0: switched to short barker preamble (BSSID=00:17:3f:a4:d6:9d)

Which is correct. One perhaps interesting detail is that the AP is unencrypted,
here is what iwlist wlan0 scanning sees:

wlan0 Scan completed :
Cell 01 - Address: 00:17:3F:A46:9D
ESSID:"strachan"
Mode:Master
Channel:6
Frequency:2.437 GHz (Channel 6)
Quality=100/100 Signal level=44/100
Encryption keyff
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 22 Mb/s
6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
36 Mb/s; 48 Mb/s; 54 Mb/s
Extra:tsf=00000036b0f6e1b6

However, on 2.6.27-rc1 I see the following instead:

[ 12.120189] firmware: requesting zd1211/zd1211b_ub
[ 12.166388] firmware: requesting zd1211/zd1211b_uphr
[ 12.218877] zd1211rw 4-2:1.0: firmware version 4725
[ 12.258877] zd1211rw 4-2:1.0: zd1211b chip 050d:705c v4810 high 00-17-3f AL2230_RF pa0 g--NS
[ 13.097289] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
[ 13.296890] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
[ 13.496890] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
[ 13.696886] wlan0: authentication with AP 00:17:3f:a4:d6:9d timed out

And Debian's networking script fails to obtain an IP address. I notice the line:

[ 18.613540] wlan0: Initial auth_alg=0

Is missing from the 2.6.27-rc1 dmesg, however my config should not have been
altered (I simply make oldconfig'ed it). Find attached anyway.

I'll start a bisection if nobody has any immediate ideas.

--
Cheers,
Alistair.

> However, on 2.6.27-rc1 I see the following instead:
>
> [ 12.120189] firmware: requesting zd1211/zd1211b_ub
> [ 12.166388] firmware: requesting zd1211/zd1211b_uphr
> [ 12.218877] zd1211rw 4-2:1.0: firmware version 4725
> [ 12.258877] zd1211rw 4-2:1.0: zd1211b chip 050d:705c v4810 high 00-17-3f AL2230_RF pa0 g--NS
> [ 13.097289] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
> [ 13.296890] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
> [ 13.496890] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
> [ 13.696886] wlan0: authentication with AP 00:17:3f:a4:d6:9d timed out
>
> And Debian's networking script fails to obtain an IP address. I notice the line:
>
> [ 18.613540] wlan0: Initial auth_alg=0
>
> Is missing from the 2.6.27-rc1 dmesg, however my config should not have been
> altered (I simply make oldconfig'ed it). Find attached anyway.
>
> I'll start a bisection if nobody has any immediate ideas.

This is about the 100 millionth time this is reported. Please try the
patch I just posted.

johannes

-----BEGIN PGP SIGNATURE-----
Comment: Johannes Berg (powerbook)

iQIcBAABAgAGBQJIjuxvAAoJEKVg1VMiehFYTfsQAIijYb1B7J UcbYZ+Wvmut5se
4oa+NEu9E7NlFHDdRoI0OzH6q0THdxLvby1B0Ulxmf6NYIyDzd Y+ON30rz8hjrdC
i4j+ZjTf8HVpYgXNJt+aiR305jr954EZQcGO7u4u3/oze6UWDhrtGb9FjryxaL/o
qrSxJTLc4J5Vd3qmY6Co8FaNPhwHzEplzts79qGgV5xHKaBPHy S0iDkXJcKH4miP
YEIzczVT5HQp3e+Rls5dMf50tjGIsFwzvu9ULRR7b9JJzYwRnW CIUwEnJt0vvGVl
zxcbc8M8E56iru4ord+1U+/mHrqYCYDLoemWv/teVryQuZK74Z1a7RtI3s5pmpht
2i4wk8PGZhGEC9p/r9HJ3Y+z3SNqe510qrYpUbm6LoZ1+k/ZhiQktU+q0QnoBpmI
nxgtS3xu4KMcV7JmouapFjhrAMeDGshA+oxiQ8dq6+5t6zgMZP MbClWqFMU7Mwdq
qp2H3D7fhJNINRpfBqFbXMB65hZcl/PPv/IqfGDHFXsJHXs9g7AnwBsiBzdiAuCH
W/4BdNqgbnagmseDQaT4z66mPB+pXMe2CMfzjC/YuTAZ+xBOaEIzSeXkCKJhH6PK
mRNNEEY4HDpzhRiP5pr8pG0AEZv1bKZiNp7J2ub1fdojd9JW6j RexUgxO6wocMmP
/I75EyH5qV3eTJ9zQauR
=D0b7
-----END PGP SIGNATURE-----

> If it doesn't strain you too much more, could you actually tell me where this
> is? Your last 5 posts to LKML don't seem to contain such a patch, and I'mnot
> subscribed to linux-wireless.

Well, the latter has archives.

johannes

-----BEGIN PGP SIGNATURE-----
Comment: Johannes Berg (powerbook)

iQIcBAABAgAGBQJIjv5VAAoJEKVg1VMiehFYSakP/0cKisClmeEBiH9Tziil3/+V
++MXA/IfExkw4CpadkUoupjyqFez/49apV93Jab3q4ffXZU09KTEb8QYd8Tqvu/W
X/DkUCWMqYvhv5hOAcdKItzmHFvvev8oY2xicmJFeua5kzczKhQb IJDje53/Kkgy
Sk6oLPVP9pxenMmV/l0RoB2JM6ehtgTcBEAv/KXpG8xTT7iTT/YU++TBswdgXhZz
j5//xW5YrKZFEE+0tLZFKt7/SFyTlAO92KS2CFMESjag4s/E1ufS1+FvoFIj/ilu
Tiy3YwdviQ9wctl3urV/pWV7q5NCYLLVIPpykyf8mCOSK9WvzVvdNofdWzn0U3H/
LgrMhZ319jo54DfBAJZ/K6XYvVCMBEMuOJ649LQalSd5QieS8wt2narHutjOWgAh
N9+x078BH7vXNB07N9ASL5qJ8L76drUp/8aW4eEsHzlQ0FbJiVoHipMoO+DOGtKG
r8xVfFbPZ1HDT8ZYdW4wCMUasBXhiV02YN4YLW/tGZQucn+sec7X783zVUeXTySc
xdStPaKe2NXDnObDyTuCY/GjwNfnOpXTRx9dEUsfFYgHwykezXZrDpXp0O+B5KOV
NsEBv2IjV5pLb4FNi57dZUG9EWOY82NEEY3QXbFT9/qNdLMiu5qRRl/QVfXZ/NUI
YGYoGJ0jOwU+X7Gm0lCm
=+126
-----END PGP SIGNATURE-----

On Tuesday 29 July 2008 11:09:55 Johannes Berg wrote:
> > However, on 2.6.27-rc1 I see the following instead:
> >
> > [ 12.120189] firmware: requesting zd1211/zd1211b_ub
> > [ 12.166388] firmware: requesting zd1211/zd1211b_uphr
> > [ 12.218877] zd1211rw 4-2:1.0: firmware version 4725
> > [ 12.258877] zd1211rw 4-2:1.0: zd1211b chip 050d:705c v4810 high
> > 00-17-3f AL2230_RF pa0 g--NS [ 13.097289] wlan0: authenticate with AP
> > 00:17:3f:a4:d6:9d
> > [ 13.296890] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
> > [ 13.496890] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
> > [ 13.696886] wlan0: authentication with AP 00:17:3f:a4:d6:9d timed out
> >
> > And Debian's networking script fails to obtain an IP address. I notice
> > the line:
> >
> > [ 18.613540] wlan0: Initial auth_alg=0
> >
> > Is missing from the 2.6.27-rc1 dmesg, however my config should not have
> > been altered (I simply make oldconfig'ed it). Find attached anyway.
> >
> > I'll start a bisection if nobody has any immediate ideas.
>
> This is about the 100 millionth time this is reported. Please try the
> patch I just posted.

If it doesn't strain you too much more, could you actually tell me where this
is? Your last 5 posts to LKML don't seem to contain such a patch, and I'm not
subscribed to linux-wireless.

--
Cheers,
Alistair.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, 29 Jul 2008, Johannes Berg wrote:
>
> > If it doesn't strain you too much more, could you actually tell me where this
> > is? Your last 5 posts to LKML don't seem to contain such a patch, and I'm not
> > subscribed to linux-wireless.
>
> Well, the latter has archives.

Wow, your patches seem to be a lot more helpful than your emails.
I presume it's this one below, which at first sight seems to be
working for me on iwl3945 - thank you for that.

Hugh


This patch fixes mac80211 to not use the skb->cb over the queue step
from virtual interfaces to the master. The patch also, for now,
disables aggregation because that would still require requeuing,
will fix that in a separate patch. There are two other places (software
requeue and powersaving stations) where requeue can happen, but that is
not currently used by any drivers/not possible to use respectively.

Signed-off-by: Johannes Berg
---
This fixes wireless. At least it works on my WPA network, I haven't
actually tested a broken kernel.

drivers/net/wireless/ath5k/base.c | 2 -
drivers/net/wireless/b43/xmit.c | 2 -
drivers/net/wireless/b43legacy/xmit.c | 2 -
drivers/net/wireless/iwlwifi/iwl-tx.c | 2 -
drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 -
drivers/net/wireless/rt2x00/rt2x00mac.c | 2 -
include/linux/skbuff.h | 5 ++
include/net/mac80211.h | 6 ---
net/core/skbuff.c | 3 +
net/mac80211/main.c | 8 ----
net/mac80211/mlme.c | 8 +---
net/mac80211/tx.c | 47 ++++++++++++----------------
net/mac80211/wme.c | 3 +
13 files changed, 40 insertions(+), 52 deletions(-)

--- everything.orig/include/net/mac80211.h 2008-07-29 09:08:16.000000000 +0200
+++ everything/include/net/mac80211.h 2008-07-29 11:07:41.000000000 +0200
@@ -206,8 +206,6 @@ struct ieee80211_bss_conf {
* These flags are used with the @flags member of &ieee80211_tx_info.
*
* @IEEE80211_TX_CTL_REQ_TX_STATUS: request TX status callback for this frame.
- * @IEEE80211_TX_CTL_DO_NOT_ENCRYPT: send this frame without encryption;
- * e.g., for EAPOL frame
* @IEEE80211_TX_CTL_USE_RTS_CTS: use RTS-CTS before sending frame
* @IEEE80211_TX_CTL_USE_CTS_PROTECT: use CTS protection for the frame (e.g.,
* for combined 802.11g / 802.11b networks)
@@ -220,7 +218,6 @@ struct ieee80211_bss_conf {
* @IEEE80211_TX_CTL_SHORT_PREAMBLE: TBD
* @IEEE80211_TX_CTL_LONG_RETRY_LIMIT: this frame should be send using the
* through set_retry_limit configured long retry value
- * @IEEE80211_TX_CTL_EAPOL_FRAME: internal to mac80211
* @IEEE80211_TX_CTL_SEND_AFTER_DTIM: send this frame after DTIM beacon
* @IEEE80211_TX_CTL_AMPDU: this frame should be sent as part of an A-MPDU
* @IEEE80211_TX_CTL_OFDM_HT: this frame can be sent in HT OFDM rates. number
@@ -253,7 +250,6 @@ struct ieee80211_bss_conf {
*/
enum mac80211_tx_control_flags {
IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0),
- IEEE80211_TX_CTL_DO_NOT_ENCRYPT = BIT(1),
IEEE80211_TX_CTL_USE_RTS_CTS = BIT(2),
IEEE80211_TX_CTL_USE_CTS_PROTECT = BIT(3),
IEEE80211_TX_CTL_NO_ACK = BIT(4),
@@ -263,7 +259,6 @@ enum mac80211_tx_control_flags {
IEEE80211_TX_CTL_FIRST_FRAGMENT = BIT(8),
IEEE80211_TX_CTL_SHORT_PREAMBLE = BIT(9),
IEEE80211_TX_CTL_LONG_RETRY_LIMIT = BIT(10),
- IEEE80211_TX_CTL_EAPOL_FRAME = BIT(11),
IEEE80211_TX_CTL_SEND_AFTER_DTIM = BIT(12),
IEEE80211_TX_CTL_AMPDU = BIT(13),
IEEE80211_TX_CTL_OFDM_HT = BIT(14),
@@ -323,7 +318,6 @@ struct ieee80211_tx_info {
struct ieee80211_vif *vif;
struct ieee80211_key_conf *hw_key;
unsigned long jiffies;
- int ifindex;
u16 aid;
s8 rts_cts_rate_idx, alt_retry_rate_idx;
u8 retry_limit;
--- everything.orig/net/mac80211/tx.c 2008-07-29 09:08:16.000000000 +0200
+++ everything/net/mac80211/tx.c 2008-07-29 11:09:09.000000000 +0200
@@ -439,14 +439,14 @@ ieee80211_tx_h_select_key(struct ieee802
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
u16 fc = tx->fc;

- if (unlikely(info->flags & IEEE80211_TX_CTL_DO_NOT_ENCRYPT))
+ if (unlikely(tx->skb->do_not_encrypt))
tx->key = NULL;
else if (tx->sta && (key = rcu_dereference(tx->sta->key)))
tx->key = key;
else if ((key = rcu_dereference(tx->sdata->default_key)))
tx->key = key;
else if (tx->sdata->drop_unencrypted &&
- !(info->flags & IEEE80211_TX_CTL_EAPOL_FRAME) &&
+ (tx->skb->protocol != cpu_to_be16(ETH_P_PAE)) &&
!(info->flags & IEEE80211_TX_CTL_INJECTED)) {
I802_DEBUG_INC(tx->local->tx_handlers_drop_unencrypted);
return TX_DROP;
@@ -476,7 +476,7 @@ ieee80211_tx_h_select_key(struct ieee802
}

if (!tx->key || !(tx->key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE))
- info->flags |= IEEE80211_TX_CTL_DO_NOT_ENCRYPT;
+ tx->skb->do_not_encrypt = 1;

return TX_CONTINUE;
}
@@ -732,6 +732,7 @@ ieee80211_tx_h_fragment(struct ieee80211
memcpy(skb_put(frag, copylen), pos, copylen);
memcpy(frag->cb, first->cb, sizeof(frag->cb));
skb_copy_queue_mapping(frag, first);
+ frag->do_not_encrypt = first->do_not_encrypt;

pos += copylen;
left -= copylen;
@@ -852,7 +853,7 @@ __ieee80211_parse_tx_radiotap(struct iee

sband = tx->local->hw.wiphy->bands[tx->channel->band];

- info->flags |= IEEE80211_TX_CTL_DO_NOT_ENCRYPT;
+ skb->do_not_encrypt = 1;
info->flags |= IEEE80211_TX_CTL_INJECTED;
tx->flags &= ~IEEE80211_TX_FRAGMENTED;

@@ -925,8 +926,7 @@ __ieee80211_parse_tx_radiotap(struct iee
skb_trim(skb, skb->len - FCS_LEN);
}
if (*iterator.this_arg & IEEE80211_RADIOTAP_F_WEP)
- info->flags &=
- ~IEEE80211_TX_CTL_DO_NOT_ENCRYPT;
+ tx->skb->do_not_encrypt = 0;
if (*iterator.this_arg & IEEE80211_RADIOTAP_F_FRAG)
tx->flags |= IEEE80211_TX_FRAGMENTED;
break;
@@ -1042,10 +1042,9 @@ static int ieee80211_tx_prepare(struct i
struct sk_buff *skb,
struct net_device *mdev)
{
- struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct net_device *dev;

- dev = dev_get_by_index(&init_net, info->control.ifindex);
+ dev = dev_get_by_index(&init_net, skb->iif);
if (unlikely(dev && !is_ieee80211_device(dev, mdev))) {
dev_put(dev);
dev = NULL;
@@ -1306,8 +1305,8 @@ int ieee80211_master_start_xmit(struct s
bool may_encrypt;
int ret;

- if (info->control.ifindex)
- odev = dev_get_by_index(&init_net, info->control.ifindex);
+ if (skb->iif)
+ odev = dev_get_by_index(&init_net, skb->iif);
if (unlikely(odev && !is_ieee80211_device(odev, dev))) {
dev_put(odev);
odev = NULL;
@@ -1321,9 +1320,13 @@ int ieee80211_master_start_xmit(struct s
return 0;
}

+ memset(info, 0, sizeof(*info));
+
+ info->flags |= IEEE80211_TX_CTL_REQ_TX_STATUS;
+
osdata = IEEE80211_DEV_TO_SUB_IF(odev);

- may_encrypt = !(info->flags & IEEE80211_TX_CTL_DO_NOT_ENCRYPT);
+ may_encrypt = !skb->do_not_encrypt;

headroom = osdata->local->tx_headroom;
if (may_encrypt)
@@ -1348,7 +1351,6 @@ int ieee80211_monitor_start_xmit(struct
struct net_device *dev)
{
struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
- struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_radiotap_header *prthdr =
(struct ieee80211_radiotap_header *)skb->data;
u16 len_rthdr;
@@ -1371,11 +1373,11 @@ int ieee80211_monitor_start_xmit(struct
skb->dev = local->mdev;

/* needed because we set skb device to master */
- info->control.ifindex = dev->ifindex;
+ skb->iif = dev->ifindex;

- info->flags |= IEEE80211_TX_CTL_DO_NOT_ENCRYPT;
- /* Interfaces should always request a status report */
- info->flags |= IEEE80211_TX_CTL_REQ_TX_STATUS;
+ /* sometimes we do encrypt injected frames, will be fixed
+ * up in radiotap parser if not wanted */
+ skb->do_not_encrypt = 0;

/*
* fix up the pointers accounting for the radiotap
@@ -1419,7 +1421,6 @@ int ieee80211_subif_start_xmit(struct sk
struct net_device *dev)
{
struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
- struct ieee80211_tx_info *info;
struct ieee80211_sub_if_data *sdata;
int ret = 1, head_need;
u16 ethertype, hdrlen, meshhdrlen = 0;
@@ -1645,14 +1646,7 @@ int ieee80211_subif_start_xmit(struct sk
nh_pos += hdrlen;
h_pos += hdrlen;

- info = IEEE80211_SKB_CB(skb);
- memset(info, 0, sizeof(*info));
- info->control.ifindex = dev->ifindex;
- if (ethertype == ETH_P_PAE)
- info->flags |= IEEE80211_TX_CTL_EAPOL_FRAME;
-
- /* Interfaces should always request a status report */
- info->flags |= IEEE80211_TX_CTL_REQ_TX_STATUS;
+ skb->iif = dev->ifindex;

skb->dev = local->mdev;
dev->stats.tx_packets++;
@@ -1922,6 +1916,8 @@ struct sk_buff *ieee80211_beacon_get(str

info = IEEE80211_SKB_CB(skb);

+ skb->do_not_encrypt = 1;
+
info->band = band;
rate_control_get_rate(local->mdev, sband, skb, &rsel);

@@ -1940,7 +1936,6 @@ struct sk_buff *ieee80211_beacon_get(str
info->tx_rate_idx = rsel.rate_idx;

info->flags |= IEEE80211_TX_CTL_NO_ACK;
- info->flags |= IEEE80211_TX_CTL_DO_NOT_ENCRYPT;
info->flags |= IEEE80211_TX_CTL_CLEAR_PS_FILT;
info->flags |= IEEE80211_TX_CTL_ASSIGN_SEQ;
if (sdata->bss_conf.use_short_preamble &&
--- everything.orig/net/mac80211/mlme.c 2008-07-29 09:08:16.000000000 +0200
+++ everything/net/mac80211/mlme.c 2008-07-29 09:15:17.000000000 +0200
@@ -606,7 +606,6 @@ void ieee80211_sta_tx(struct net_device
int encrypt)
{
struct ieee80211_sub_if_data *sdata;
- struct ieee80211_tx_info *info;

sdata = IEEE80211_DEV_TO_SUB_IF(dev);
skb->dev = sdata->local->mdev;
@@ -614,11 +613,8 @@ void ieee80211_sta_tx(struct net_device
skb_set_network_header(skb, 0);
skb_set_transport_header(skb, 0);

- info = IEEE80211_SKB_CB(skb);
- memset(info, 0, sizeof(struct ieee80211_tx_info));
- info->control.ifindex = sdata->dev->ifindex;
- if (!encrypt)
- info->flags |= IEEE80211_TX_CTL_DO_NOT_ENCRYPT;
+ skb->iif = sdata->dev->ifindex;
+ skb->do_not_encrypt = !encrypt;

dev_queue_xmit(skb);
}
--- everything.orig/include/linux/skbuff.h 2008-07-29 09:08:16.000000000 +0200
+++ everything/include/linux/skbuff.h 2008-07-29 09:15:17.000000000 +0200
@@ -316,7 +316,10 @@ struct sk_buff {
#ifdef CONFIG_IPV6_NDISC_NODETYPE
__u8 ndisc_nodetype:2;
#endif
- /* 14 bit hole */
+#if defined(CONFIG_MAC80211) || defined(CONFIG_MAC80211_MODULE)
+ __u8 do_not_encrypt:1;
+#endif
+ /* 0/13/14 bit hole */

#ifdef CONFIG_NET_DMA
dma_cookie_t dma_cookie;
--- everything.orig/net/core/skbuff.c 2008-07-29 09:15:39.000000000 +0200
+++ everything/net/core/skbuff.c 2008-07-29 09:16:13.000000000 +0200
@@ -485,6 +485,9 @@ static struct sk_buff *__skb_clone(struc
C(head);
C(data);
C(truesize);
+#if defined(CONFIG_MAC80211) || defined(CONFIG_MAC80211_MODULE)
+ C(do_not_encrypt);
+#endif
atomic_set(&n->users, 1);

atomic_inc(&(skb_shinfo(skb)->dataref));
--- everything.orig/net/mac80211/main.c 2008-07-29 09:18:20.000000000 +0200
+++ everything/net/mac80211/main.c 2008-07-29 09:19:06.000000000 +0200
@@ -1233,18 +1233,12 @@ static void ieee80211_tasklet_handler(un
/* Remove added headers (e.g., QoS control), encryption header/MIC, etc. to
* make a prepared TX frame (one that has been given to hw) to look like brand
* new IEEE 802.11 frame that is ready to go through TX processing again.
- * Also, tx_packet_data in cb is restored from tx_control. */
+ */
static void ieee80211_remove_tx_extra(struct ieee80211_local *local,
struct ieee80211_key *key,
struct sk_buff *skb)
{
int hdrlen, iv_len, mic_len;
- struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
-
- info->flags &= IEEE80211_TX_CTL_REQ_TX_STATUS |
- IEEE80211_TX_CTL_DO_NOT_ENCRYPT |
- IEEE80211_TX_CTL_REQUEUE |
- IEEE80211_TX_CTL_EAPOL_FRAME;

hdrlen = ieee80211_get_hdrlen_from_skb(skb);

--- everything.orig/drivers/net/wireless/ath5k/base.c 2008-07-29 09:38:38.000000000 +0200
+++ everything/drivers/net/wireless/ath5k/base.c 2008-07-29 09:38:53.000000000 +0200
@@ -1224,7 +1224,7 @@ ath5k_txbuf_setup(struct ath5k_softc *sc

pktlen = skb->len;

- if (!(info->flags & IEEE80211_TX_CTL_DO_NOT_ENCRYPT)) {
+ if (info->control.hw_key) {
keyidx = info->control.hw_key->hw_key_idx;
pktlen += info->control.icv_len;
}
--- everything.orig/drivers/net/wireless/b43/xmit.c 2008-07-29 09:39:28.000000000 +0200
+++ everything/drivers/net/wireless/b43/xmit.c 2008-07-29 09:40:19.000000000 +0200
@@ -192,7 +192,7 @@ int b43_generate_txhdr(struct b43_wldev
const struct b43_phy *phy = &dev->phy;
const struct ieee80211_hdr *wlhdr =
(const struct ieee80211_hdr *)fragment_data;
- int use_encryption = (!(info->flags & IEEE80211_TX_CTL_DO_NOT_ENCRYPT));
+ int use_encryption = !!info->control.hw_key;
__le16 fctl = wlhdr->frame_control;
struct ieee80211_rate *fbrate;
u8 rate, rate_fb;
--- everything.orig/drivers/net/wireless/b43legacy/xmit.c 2008-07-29 09:39:29.000000000 +0200
+++ everything/drivers/net/wireless/b43legacy/xmit.c 2008-07-29 09:40:25.000000000 +0200
@@ -192,7 +192,7 @@ static int generate_txhdr_fw3(struct b43
u16 cookie)
{
const struct ieee80211_hdr *wlhdr;
- int use_encryption = (!(info->flags & IEEE80211_TX_CTL_DO_NOT_ENCRYPT));
+ int use_encryption = !!info->control.hw_key;
u16 fctl;
u8 rate;
struct ieee80211_rate *rate_fb;
--- everything.orig/drivers/net/wireless/iwlwifi/iwl-tx.c 2008-07-29 09:39:28.000000000 +0200
+++ everything/drivers/net/wireless/iwlwifi/iwl-tx.c 2008-07-29 09:39:44.000000000 +0200
@@ -906,7 +906,7 @@ int iwl_tx_skb(struct iwl_priv *priv, st
* first entry */
iwl_hw_txq_attach_buf_to_tfd(priv, tfd, txcmd_phys, len);

- if (!(info->flags & IEEE80211_TX_CTL_DO_NOT_ENCRYPT))
+ if (info->control.hw_key)
iwl_tx_cmd_build_hwcrypto(priv, info, tx_cmd, skb, sta_id);

/* Set up TFD's 2nd entry to point directly to remainder of skb,
--- everything.orig/drivers/net/wireless/iwlwifi/iwl3945-base.c 2008-07-29 09:39:28.000000000 +0200
+++ everything/drivers/net/wireless/iwlwifi/iwl3945-base.c 2008-07-29 09:39:39.000000000 +0200
@@ -2667,7 +2667,7 @@ static int iwl3945_tx_skb(struct iwl3945
* first entry */
iwl3945_hw_txq_attach_buf_to_tfd(priv, tfd, txcmd_phys, len);

- if (!(info->flags & IEEE80211_TX_CTL_DO_NOT_ENCRYPT))
+ if (info->control.hw_key)
iwl3945_build_tx_cmd_hwcrypto(priv, info, out_cmd, skb, 0);

/* Set up TFD's 2nd entry to point directly to remainder of skb,
--- everything.orig/drivers/net/wireless/rt2x00/rt2x00mac.c 2008-07-29 09:39:28.000000000 +0200
+++ everything/drivers/net/wireless/rt2x00/rt2x00mac.c 2008-07-29 09:40:08.000000000 +0200
@@ -63,7 +63,7 @@ static int rt2x00mac_tx_rts_cts(struct r
*/
memcpy(skb->cb, frag_skb->cb, sizeof(skb->cb));
rts_info = IEEE80211_SKB_CB(skb);
- rts_info->flags |= IEEE80211_TX_CTL_DO_NOT_ENCRYPT;
+ rts_info->control.hw_key = NULL;
rts_info->flags &= ~IEEE80211_TX_CTL_USE_RTS_CTS;
rts_info->flags &= ~IEEE80211_TX_CTL_USE_CTS_PROTECT;
rts_info->flags &= ~IEEE80211_TX_CTL_REQ_TX_STATUS;
--- everything.orig/net/mac80211/wme.c 2008-07-29 09:45:41.000000000 +0200
+++ everything/net/mac80211/wme.c 2008-07-29 09:47:17.000000000 +0200
@@ -188,6 +188,9 @@ int ieee80211_ht_agg_queue_add(struct ie
{
int i;

+ /* XXX: currently broken due to cb/requeue use */
+ return -EPERM;
+
/* prepare the filter and save it for the SW queue
* matching the received HW queue */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Johannes Berg writes:

>> If it doesn't strain you too much more, could you actually tell me
>> where this is? Your last 5 posts to LKML don't seem to contain such
>> a patch, and I'm not subscribed to linux-wireless.
>
> Well, the latter has archives.

Here's a link to the patch:

http://marc.info/?l=linux-wireless&m...2394028001&w=2

--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tuesday 29 July 2008 12:26:17 Johannes Berg wrote:
> > If it doesn't strain you too much more, could you actually tell me where
> > this is? Your last 5 posts to LKML don't seem to contain such a patch,
> > and I'm not subscribed to linux-wireless.
>
> Well, the latter has archives.

Thanks for the patch, it fixes the issue for me with my zd1211rw. I hope
the "100 million" rabid users that reported this can piss off happily with
their working wireless. ;-)

(BTW thanks Hugh/Holger for the patch posting/link.)

--
Cheers,
Alistair.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, Jul 29, 2008 at 12:09:55PM +0200, Johannes Berg wrote:
> This is about the 100 millionth time this is reported. Please try the
> patch I just posted.

Yeah, it's really too bad -rc1 got released just before you were able
to post the fix to this, since if there were 100 million people who
were trying out kernels starting with -git7 that use wireless, there
will probably be 200 million people trying out -rc1. :-)

Thanks for finding and fixing it, though. I stopped trying out
kernels after -git6 since I was travelling at OSCON, and not having
wireless was a show-stopper for me....

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, 2008-07-29 at 08:04 -0400, Theodore Tso wrote:
> On Tue, Jul 29, 2008 at 12:09:55PM +0200, Johannes Berg wrote:
> > This is about the 100 millionth time this is reported. Please try the
> > patch I just posted.
>
> Yeah, it's really too bad -rc1 got released just before you were able
> to post the fix to this, since if there were 100 million people who
> were trying out kernels starting with -git7 that use wireless, there
> will probably be 200 million people trying out -rc1. :-)
>
> Thanks for finding and fixing it, though. I stopped trying out
> kernels after -git6 since I was travelling at OSCON, and not having
> wireless was a show-stopper for me....

If everybody's going to decide now to hit on _me_, I'll point out that
davem's MQ TX changes broke it, I only heard about the problem once that
was out because nobody had found it earlier, and I was also travelling
at OLS.

Maybe the lesson we could learn from this is to not release an rc1 while
a bunch of important people are at various conferences.

johannes

-----BEGIN PGP SIGNATURE-----
Comment: Johannes Berg (powerbook)

iQIcBAABAgAGBQJIjwhrAAoJEKVg1VMiehFY6dEP/2lg8SaEuRNLLFo2T8H9863W
5n88QtaULrVamQV4F9TCvuWsshGqzWes6DABsONyY426SyvmUw zitUIYRQjV8DHt
HxdfTy0PuK9kEO542koJZEsBPSMLz84biAXOiV6aIVQnl1wbZk/N3MLl/+RM1MJe
QW3cwzWZQUz7PpId/EqkVM3AngMQ5jl/IiuxrR1aRNdGN+yIMr+nquZB4m9LnGlL
CIHZnCZc27FsNY45YSpUIcKqPGN7ptLQsOQfx3u2zDuuaJOvhw dqKlbsVdyYMZIF
wPbMQNOCiphfzp1zNyaa/Gj3plbQJYN4+lTMSCGk4JuXZSZQA62xQlbaEY5E1gjp
vQ/4TI+dRk6xrLH1nG1SZ6OJybyBC316+lt6ocXonNZCqMRqC+u+z ArWnYlE8RuE
4jan/bBa/e9AnjF/sAyPzAMfXNQqMFjsLaZxap+QdY1WGXZCeIGlwmUH1UeHGDJ6
hFLz/frZSLn+BhR9iOde//Mni9aAnNHTWDVHW6ZKmUcn2sfeNZEZ3uaIPb6Q3lrv
/AETQ9FBjJNiLm5ApSjrMwQp2vLFIy0iDsGuixRL48vGRXQwZzM vx9Mv7HbvDGHO
fjbFvCPtVVfG+7GXuJ7Cm3FMxX+IwHY8zUdWMDZl+rSe4EUXIa X76UFK7wwSkPhT
lb91bhvsuuCajFtgqLjh
=K2l+
-----END PGP SIGNATURE-----

> > Yeah, it's really too bad -rc1 got released just before you were able
> > to post the fix to this, since if there were 100 million people who
> > were trying out kernels starting with -git7 that use wireless, there
> > will probably be 200 million people trying out -rc1. :-)
> >
> > Thanks for finding and fixing it, though. I stopped trying out
> > kernels after -git6 since I was travelling at OSCON, and not having
> > wireless was a show-stopper for me....
>
> If everybody's going to decide now to hit on _me_, I'll point out that
> davem's MQ TX changes broke it

Of course that's not strictly true, it had been broken forever, it just
happened to never show up before. And I mean forever, the original
devicescape code that got in was already broken.

johannes

-----BEGIN PGP SIGNATURE-----
Comment: Johannes Berg (powerbook)

iQIcBAABAgAGBQJIjwnHAAoJEKVg1VMiehFYZ14P/19rawXslWwYfN0YodvWyRcM
2SLXlNog06zelMyR9CpfAzyzkkhHAMBfTCWWLbN4mJ8anLDQpr TXuD2/nK/E1WTF
c5Z6WLlWBFoPeR559j0K34f6nL/4moPVilxKfdOANMnyhUhfKCQfG41iei2BE0NA
cIc+MkXBji1FvgSZgyqnVdVDZ7/aO+KeNsEx4+gM+lGgRDeVNDBMVOhMdvRMHkvy
C4WKP09IeyU+0vW4WYNSj6V3lDRNUF6e0Tdp1vYTxUXq75wSFU QoUbSKBekggIcb
0Z6kWIbLO6Cpf/N7Q6LvSeWtcOYdG/2Py+MXAyGK9TiX9t30H6vwlBwcnhGWNwb3
MPA2SFGSkylzTOXyflsqKzpnMWG8JR6pQ9fOs0kk3Mn/1hbT6xV1m4ZqJKpEAO25
YDUd51AY+oTm9yOY1M5HRjgrzlH0yzoTgaKGgUW1tSJSg/aPmybUyhiJiRbWAqKw
UuaIbPoRxvUXBQ8ZEm4JahKUyKCv8gUp2y5+W9dNUbll0NFS7W pY30Beds7b4vvs
qErAxlAaLDRuknHCBpOI4dqX0n7+scH/dShP2K20wanTqzQOw8RzVZqREXHUAD2A
N4jqdYu9hsVenzUpDSaLFN+mhWsBX5Kt8kZIkEoFR3tH8k2lvb +Fvs0SQJoULWOM
FtH4Ay3sUrfYhE6aLMyX
=Saww
-----END PGP SIGNATURE-----

Hi,

(Sorry for the CC frenzy. If you don't have or want anything to do with the
tracing framework in 2.6.27 or the microcode driver, you can stop reading
now.)

Noticing pq's mmiotrace was merged I tried to get a trace of the proprietary
NVIDIA blob. Normally I wouldn't waste your time posting a tainted oops,
however in this case it doesn't look related to the proprietary garbage and I
think there's a real bug somewhere.

As I understand it, the mmiotrace tracing framework requires only one logical
CPU to be active, automatically offlining the other CPUs. When mmiotrace is
disabled, it automatically re-enables the CPUs it offlined. If I offline the
spare CPUs myself, prior to enabling mmiotrace, I do not see the issue I'm
about to describe. That's why tracing people have been CCed, even though that
could be a red herring.

The full dmesg and kernel config are available from
http://devzero.co.uk/~alistair/2.6.27-rc1-mc-oops/

nvidia: module license 'NVIDIA' taints kernel.
Symbol init_mm is marked as UNUSED, however this module is using it.
This symbol will go away in the future.
Please evalute if this is the right api to use and if it really is, submit a report the linux kernel mailinglist together with submitting your code for inclusion.
nvidia 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
nvidia 0000:01:00.0: setting latency timer to 64
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 173.14.09 Wed Jun 4 23:40:50 PDT 2008
in mmio_trace_init
mmiotrace: Disabling non-boot CPUs...
kvm: disabling virtualization on CPU1
CPU 1 is now offline
SMP alternatives: switching to UP code
CPU0 attaching NULL sched-domain.
CPU1 attaching NULL sched-domain.
CPU0 attaching NULL sched-domain.
mmiotrace: CPU1 is down.
mmiotrace: enabled.
Symbol init_mm is marked as UNUSED, however this module is using it.
This symbol will go away in the future.
Please evalute if this is the right api to use and if it really is, submit a report the linux kernel mailinglist together with submitting your code for inclusion.
nvidia 0000:01:00.0: setting latency timer to 64
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 173.14.09 Wed Jun 4 23:40:50 PDT 2008
mmiotrace: ioremap_*(0xfa000000, 0x1000000) = ffffc20010b80000
mmiotrace: ioremap_*(0xd0000000, 0x6000) = ffffc20010578000
mmiotrace: ioremap_*(0xe0000000, 0x1000) = ffffc200104fe000
mmiotrace: Unmapping ffffc200104fe000.
mmiotrace: ioremap_*(0xe0008000, 0x1000) = ffffc200104fe000
mmiotrace: ioremap_*(0xe0100000, 0x1000) = ffffc20010500000
mmiotrace: Unmapping ffffc20010500000.
mmiotrace: ioremap_*(0xf8000000, 0x1000000) = ffffc20011c00000
mmiotrace: ioremap_*(0xe0100000, 0x1000) = ffffc20010500000
mmiotrace: Unmapping ffffc20010500000.
mmiotrace: ioremap_*(0xd0504000, 0x1000) = ffffc20010500000
mmiotrace: ioremap_*(0xd0519000, 0x1000) = ffffc20010502000
mmiotrace: ioremap_*(0xd051a000, 0x1000) = ffffc20010572000
mmiotrace: Unmapping ffffc20010502000.
mmiotrace: Unmapping ffffc20010572000.
mmiotrace: Unmapping ffffc20010500000.
mmiotrace: Unmapping ffffc200104fe000.
mmiotrace: Unmapping ffffc20011c00000.
mmiotrace: Unmapping ffffc20010578000.
mmiotrace: Unmapping ffffc20010b80000.
in mmio_trace_reset
mmiotrace: Re-enabling CPUs...
SMP alternatives: switching to SMP code
Booting processor 1/1 ip 6000
Initializing CPU#1
Calibrating delay using timer specific routine.. <6>7200.61 BogoMIPS (lpj=3600306)
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
CPU1: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping 06
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
kvm: enabling virtualization on CPU1
CPU0 attaching NULL sched-domain.
Switched to high resolution mode on CPU 1
CPU0 attaching sched-domain:
domain 0: span 0-1 level MC
groups: 0 1
CPU1 attaching sched-domain:
domain 0: span 0-1 level MC
groups: 1 0
------------[ cut here ]------------
Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
invalid opcode: 0000 [1] PREEMPT SMP
CPU 0
Modules linked in: nvidia(P) rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc acpi_cpufreq freq_table coretemp
hwmon snd_pcm_oss snd_mixer_oss firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1 snd_rawmidi
snd_ac97_codec ac97_bus snd_seq_device sg snd_util_mem snd_hda_intel snd_pcm snd_timer snd_hwdep snd i2c_i801 sr_mod firewire_ohci firewire_core soundcore r8169 ehci_hcd uhci_hcd
snd_page_alloc crc_itu_t i2c_core usbcore cdrom [last unloaded: nvidia]
Pid: 2733, comm: bash Tainted: P A 2.6.27-rc1-damocles #3
RIP: 0010:[] [] __mc_sysdev_add+0xc3/0x1f1
RSP: 0018:ffff8800b7c1dce8 EFLAGS: 00010297
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
RBP: ffff8800b7c1dd48 R08: ffff8800b7c1c000 R09: ffffffff80229ca4
R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
FS: 00007fa4bf6176e0(0000) GS:ffffffff805da200(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f3a6cf05098 CR3: 00000000b7d64000 CR4: 00000000000026e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
Process bash (pid: 2733, threadinfo ffff8800b7c1c000, task ffff8800bd06ab20)
Stack: ffffffff80627040 0000000000000000 0000000000000008 ffffffff8048bb28
0000000000000003 ffffffff802ce910 ffff8800b7c1dd28 0000000000000002
00000000ffffffe8 0000000000000001 0000000000000001 ffff880001028418
Call Trace:
[] ? sysfs_add_file+0xc/0xe
[] mc_sysdev_add+0xb/0xd
[] mc_cpu_callback+0x4b/0x208
[] ? mce_cpu_callback+0x3e/0xbc
[] notifier_call_chain+0x33/0x5b
[] raw_notifier_call_chain+0xf/0x11
[] _cpu_up+0xce/0x119
[] cpu_up+0x5e/0x8a
[] disable_mmiotrace+0xfe/0x173
[] mmio_trace_reset+0x2d/0x44
[] tracing_set_trace_write+0xd3/0x10f
[] ? filp_close+0x67/0x72
[] vfs_write+0xa7/0xe1
[] sys_write+0x47/0x6f
[] system_call_fastpath+0x16/0x1b
[ 903.144002]
[ 903.144002]
Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00
00 00 00 41
RIP [] __mc_sysdev_add+0xc3/0x1f1
RSP
---[ end trace 39a5700403aca092 ]---

The box was vaguely usable and then choked to death a few minutes later. I was
initially confused by the multi-core stuff chiming in, but the functions
mc_cpu_callback and mc_sysdev_add are from the microcode driver. At a guess,
something is being done in a context it shouldn't be. I've not tested it
enough to say whether or not it will always crash.

Also, I'm sure this is reproducible without the NVIDIA garbage, but I was too lazy
to test it. If you want me to repeat the experiment without the driver I would be
more than happy to do so.

--
Cheers,
Alistair.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, Jul 29, 2008 at 02:15:06PM +0200, Johannes Berg wrote:
> > If everybody's going to decide now to hit on _me_, I'll point out that
> > davem's MQ TX changes broke it
>
> Of course that's not strictly true, it had been broken forever, it just
> happened to never show up before. And I mean forever, the original
> devicescape code that got in was already broken.

Sorry, no, I wasn't trying to blame you. I understand that this was a
hard problem to fix, and it wasn't at all obvious that changes in one
part of the networking stack would break wireless stack due to bad
assumptions it had made, that had been hiding for quite some time.

The timing is just very unfortunate, since if -rc1 had been delayed by
just one more day so it could have incorporated it we would probably
reduce the large number of regression reports; a lot of people who
test -rc1 don't necessarily follow netdev or linux-wireless.

I'm of course also nervously building -rc1 and about to test it, since
I haven't had a chance to test anything since -git6, and I'm wondering
if some other regression may have been introduced since then.

Since it probably doesn't get said enough to everyone who works of
fixing bugs/regressions, thanks very much for your efforts; I (and
many other people) very much appreciate it!!

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, 29 Jul 2008 14:57:58 +0100
Alistair John Strachan wrote:

> Noticing pq's mmiotrace was merged I tried to get a trace of the proprietary
> NVIDIA blob. Normally I wouldn't waste your time posting a tainted oops,
> however in this case it doesn't look related to the proprietary garbage and I
> think there's a real bug somewhere.
>
> As I understand it, the mmiotrace tracing framework requires only one logical
> CPU to be active, automatically offlining the other CPUs. When mmiotrace is
> disabled, it automatically re-enables the CPUs it offlined. If I offline the
> spare CPUs myself, prior to enabling mmiotrace, I do not see the issue I'm
> about to describe. That's why tracing people have been CCed, even though that
> could be a red herring.

I have a wild hunch...
Could you try the following:
1. with all cpus enabled, load the nvidia proprietary driver
2. start and quit X
3. disable a cpu by hand
4. unload the proprietary driver
5. enable the cpu by hand

I have a vague recollection of the nvidia blob doing something bad
with notifiers, so if that crashes, and it does not crash when you
leave step 4 out, it's an nvidia problem. I assume you unloaded the
blob before disabling mmiotrace, right?

You may need to alter the sequence of things, but my guess is that
the blob may leave a notifier registered even when it is unloaded,
so it crashes when the notifier chain is traversed. I'm not sure the
backtrace really supports this scenario, but worth to try.

> The full dmesg and kernel config are available from
> http://devzero.co.uk/~alistair/2.6.27-rc1-mc-oops/
....
> Also, I'm sure this is reproducible without the NVIDIA garbage, but I was too lazy
> to test it. If you want me to repeat the experiment without the driver I would be
> more than happy to do so.

I'm not sure people are willing to look into this without a clean report,
so this would be cool. There's even a test module for mmiotrace in the
kernel, but I doubt it would make difference to use it or not, when trying
to reproduce the crash without the blob.

Thanks.

--
Pekka Paalanen
http://www.iki.fi/pq/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Monday, July 28, 2008 8:23 pm Linus Torvalds wrote:
> Much of -rc1 was in linux-next, but certainly not everything. We'll see
> how that whole thing ends up evolving - it certainly didn't solve all
> problems, and there was some bickering about things that weren't there
> (and some things that mostly were , but maybe it helped.

I think linux-next has been a *huge* help. It's been great at catching merge
conflicts and build bugs (though not so much when you don't use it[1]!), and
Stephen is really easy to work with. So I, for one, would love to see it
continue.

Jesse

[1] http://marc.info/?t=121699085400001&r=1&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tuesday 29 July 2008 17:22:14 Pekka Paalanen wrote:
> > Also, I'm sure this is reproducible without the NVIDIA garbage, but I was
> > too lazy to test it. If you want me to repeat the experiment without the
> > driver I would be more than happy to do so.
>
> I'm not sure people are willing to look into this without a clean report,
> so this would be cool. There's even a test module for mmiotrace in the
> kernel, but I doubt it would make difference to use it or not, when trying
> to reproduce the crash without the blob.

Of course, and I should have attempted to reproduce without the driver.
Fortunately that was easy: it is not an NVIDIA driver bug.

Steps to reproduce: have CONFIG_MICROCODE=y and a suitable Intel
processor, then do:

echo mmiotrace >/debug/tracing/current_tracer
echo none >/debug/tracing/current_tracer

And you get this (snipped) oops:

in mmio_trace_init
mmiotrace: Disabling non-boot CPUs...
kvm: disabling virtualization on CPU1
CPU 1 is now offline
SMP alternatives: switching to UP code
CPU0 attaching NULL sched-domain.
CPU1 attaching NULL sched-domain.
CPU0 attaching NULL sched-domain.
mmiotrace: CPU1 is down.
mmiotrace: enabled.
in mmio_trace_reset
mmiotrace: Re-enabling CPUs...
SMP alternatives: switching to SMP code
Booting processor 1/1 ip 6000
Initializing CPU#1
Calibrating delay using timer specific routine.. <6>7204.76 BogoMIPS (lpj=3602381)
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
CPU1: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping 06
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
kvm: enabling virtualization on CPU1
CPU0 attaching NULL sched-domain.
Switched to high resolution mode on CPU 1
CPU0 attaching sched-domain:
domain 0: span 0-1 level MC
groups: 0 1
CPU1 attaching sched-domain:
domain 0: span 0-1 level MC
groups: 1 0
------------[ cut here ]------------
Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
invalid opcode: 0000 [1] PREEMPT SMP
CPU 0
Modules linked in: rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc acpi_cpufreq freq_table coretemp hwmon
snd_pcm_oss snd_mixer_oss firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1 snd_rawmidi
snd_ac97_codec ac97_bus sg snd_seq_device snd_hda_intel snd_pcm snd_util_mem snd_timer sr_mod snd_hwdep i2c_i801 ehci_hcd firewire_ohci uhci_hcd snd snd_page_alloc firewire_core
soundcore r8169 cdrom usbcore i2c_core crc_itu_t
Pid: 2757, comm: bash Tainted: G A 2.6.27-rc1-damocles #3
RIP: 0010:[] [] __mc_sysdev_add+0xc3/0x1f1
RSP: 0018:ffff8800b8905ce8 EFLAGS: 00010297
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
RBP: ffff8800b8905d48 R08: ffff8800b8904000 R09: ffffffff80229ca4
R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
FS: 00007f8ddc78f6e0(0000) GS:ffffffff805da200(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f57cb9b2098 CR3: 00000000b8985000 CR4: 00000000000026e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process bash (pid: 2757, threadinfo ffff8800b8904000, task ffff8800bd125640)
Stack: ffffffff80627040 0000000000000000 0000000000000008 ffffffff8048bb28
0000000000000003 ffffffff802ce910 ffff8800b8905d28 0000000000000002
00000000ffffffe8 0000000000000001 0000000000000001 ffff880001028418
Call Trace:
[] ? sysfs_add_file+0xc/0xe
[] mc_sysdev_add+0xb/0xd
[] mc_cpu_callback+0x4b/0x208
[] ? mce_cpu_callback+0x3e/0xbc
[] notifier_call_chain+0x33/0x5b
[] raw_notifier_call_chain+0xf/0x11
[] _cpu_up+0xce/0x119
[] cpu_up+0x5e/0x8a
[] disable_mmiotrace+0xfe/0x173
[] mmio_trace_reset+0x2d/0x44
[] tracing_set_trace_write+0xd3/0x10f
[] ? filp_close+0x67/0x72
[] vfs_write+0xa7/0xe1
[] sys_write+0x47/0x6f
[] system_call_fastpath+0x16/0x1b
[ 68.405002]
[ 68.405002]
Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00
00 00 00 41
RIP [] __mc_sysdev_add+0xc3/0x1f1
RSP
---[ end trace ee9c9240024cb48c ]---

I've replaced the originally tainted dmesg with this new clean one, so
there's no proprietary smell about it :-)

http://devzero.co.uk/~alistair/2.6.27-rc1-mc-oops/

--
Cheers,
Alistair.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, 29 Jul 2008, Jesse Barnes wrote:
>
> I think linux-next has been a *huge* help. It's been great at catching merge
> conflicts and build bugs (though not so much when you don't use it[1]!), and
> Stephen is really easy to work with. So I, for one, would love to see it
> continue.

I don't think anybody wants it to go away. The question in my mind is more
along the way of how/whether it should be changed. There was some
bickering about patches that weren't there, and some about how _partial_
series were there but then the finishing touches broke things.

I don't personally really think that it's reasonable to expect everything
to be in -next (but hey, I'm willing to be convinced otherwise). And don't
get me wrong - it certainly wouldn't bother _me_ to have everything go
through next, since it just makes it likelier that I have less to worry
about.

BUT. I do think 'next' as it is has a few issues that either need to be
fixed (unlikely - it's not the point of next) or just need to be aired as
issues and understood:

- I don't think it does 'quality control', and I think that's pretty
fundamental.

Now, admittedly I don't look much at the patches of people I trust
either (that's what the whole point of that 'trust' is, after all - to
make me not be the part that limits development speed), but that's
still different from 'largely automated merging'.

So I _do_ check the things that aren't obvious "maintainer works on his
own subsystem" or are so core that I really feel like I need to know
what's up. I seldom actually say "that's so broken that I refuse to
pull it", but I tend to do that a couple of times per release.

That may not sound like much, but it's enough to make me worry about
'next'. I worry that 'it has been in next' has become a code-word for
"pull this, because it's good", and I'm not at all convinced that
'next' sees any real critical checking.

- I don't think the 'next' thing works as well for the occasional
developer that just has a few patches pending as it works for subsystem
maintainers that are used to it.

IOW, I think 'next' needs enough infrastructure setup from the
developer side that I don't think it's reasonable for _everything_ to
go through next. And that in turn means that I'm not entirely thrilled
when people then complain "that wasn't in next". I think people should
accept that not everything will be in next.

But I don't think either of the above issues is a 'problem' - I just think
they should be acknowledged. I think 'next' is a good way for the big
subsystem developers to be able to see problems early, but I really hope
that nobody will _ever_ see next as a "that's the way into Linus' tree",
because for the above two reasons I do not think it can really work that
way.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> That may not sound like much, but it's enough to make me worry about
> 'next'. I worry that 'it has been in next' has become a code-word for
> "pull this, because it's good", and I'm not at all convinced that
> 'next' sees any real critical checking.

I've been mentioning that my trees have been in next as code for, "I
don't think this should break the build or clash too badly with anything
else." And next has been useful to me on several occasions for catching
that sort of problem before things hit mainline.

- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tuesday, 29 of July 2008, Linus Torvalds wrote:
>
> It's two weeks (and one day), and the merge window is over.
>
> Finally. I don't know why, but this one really did feel pretty dang busy.
> And the size of the -rc1 patch bears that out - at 12MB, it's about 50%
> bigger than 26-rc1 (but not that much bigger than 24/25-rc1, so it's not
> like it's anything unheard of).
>
> The pure size of the -rc's _is_ making me a bit nervous, though. Sure, it
> means that we are good at merging it all, but I have to say that I
> sometimes wonder if we don't merge too much in one go, and even our
> current (fairly short) release cycle is actually too big.
>
> Anyway, that's a discussion for some other event.
>
> Much of -rc1 was in linux-next, but certainly not everything. We'll see
> how that whole thing ends up evolving - it certainly didn't solve all
> problems, and there was some bickering about things that weren't there
> (and some things that mostly were , but maybe it helped.
>
> There's a ton of new stuff in there, but at least personally the
> interesting things are the BKL pushdown and perhaps the introduction of
> the lockless get_user_pages_fast(). The build system also got updated to
> allow moving the architecture include files ("include/asm-xyz") into the
> architecture subdirectories ("arch/xyz/include/asm"), and sparc seems to
> have taken advantage of that already.
>
> But those changes are just small details in the end. As usual, the bulk of
> changes are all to device drivers (roughly half, as usual), with the arch
> directory amounting to about half of the remainder. Dirstat:
>
> 3.2% arch/arm/
> 9.2% arch/ppc/
> 24.6% arch/
> 5.2% drivers/char/drm/
> 6.3% drivers/char/
> 4.5% drivers/gpu/drm/
> 4.5% drivers/gpu/
> 4.6% drivers/media/video/
> 5.5% drivers/media/
> 3.0% drivers/net/wireless/
> 10.7% drivers/net/
> 6.4% drivers/usb/misc/
> 4.7% drivers/usb/serial/
> 12.9% drivers/usb/
> 51.2% drivers/
> 4.4% firmware/
> 3.7% fs/
> 9.2% include/
>
> where the bulk of that fs/ update is the merge of the UBI filesystem, to
> pick one fairly sizeable chunk outside of arch or drivers (there's omfs
> too, but that's tiny in comparison).
>
> Other stuff? tracing. firmware loading.

That one happens to break things for me badly:

rafael@chimera:~/src/linux-2.6> make O=../build/mainline/chimera -j5
GEN /home/rafael/src/build/mainline/chimera/Makefile
CHK include/linux/version.h
CHK include/linux/utsrelease.h
Using /home/rafael/src/linux-2.6 as source for kernel
CALL /home/rafael/src/linux-2.6/scripts/checksyscalls.sh
CHK include/linux/compile.h
Building modules, stage 2.
Kernel: arch/x86/boot/bzImage is ready (#208)
MODPOST 564 modules
IHEX2FW firmware/emi26/loader.fw
Failed to open destination file: Permission deniedihex2fw: Convert ihex files into binary representation for use by Linux kernel
usage: ihex2fw []
-w: wide records (16-bit length)
-s: sort records by address
IHEX2FW firmware/emi26/bitstream.fw
IHEX2FW firmware/emi26/firmware.fw
Failed to open destination file: Permission deniedihex2fw: Convert ihex files into binary representation for use by Linux kernel
usage: ihex2fw []
-w: wide records (16-bit length)
-s: sort records by address
make[2]: *** [firmware/emi26/loader.fw] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [firmware/emi26/bitstream.fw] Error 1
Failed to open destination file: Permission deniedihex2fw: Convert ihex files into binary representation for use by Linux kernel
usage: ihex2fw []
-w: wide records (16-bit length)
-s: sort records by address
make[2]: *** [firmware/emi26/firmware.fw] Error 1
make[1]: *** [modules] Error 2
make: *** [sub-make] Error 2

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/