Linux v2.6.27-rc1 - Kernel

This is a discussion on Linux v2.6.27-rc1 - Kernel ; 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 ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 42

Thread: Linux v2.6.27-rc1

  1. Linux v2.6.27-rc1


    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. 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).

    But mostly lots and lots of driver and arch updates.

    Go to kernelnewbies or lwn for more reporting, I'm going to sleep for
    twenty-four hours now

    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/

  2. Re: Linux v2.6.27-rc1

    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/

  3. 2.6.27-rc1: zd1211rw association fails

    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.


  4. Re: 2.6.27-rc1: zd1211rw association fails


    > 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-----


  5. Re: 2.6.27-rc1: zd1211rw association fails


    > 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-----


  6. Re: 2.6.27-rc1: zd1211rw association fails

    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/

  7. Re: 2.6.27-rc1: zd1211rw association fails

    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/

  8. Re: 2.6.27-rc1: zd1211rw association fails

    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/

  9. Re: 2.6.27-rc1: zd1211rw association fails

    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/

  10. Re: 2.6.27-rc1: zd1211rw association fails

    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/

  11. Re: 2.6.27-rc1: zd1211rw association fails

    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-----


  12. Re: 2.6.27-rc1: zd1211rw association fails


    > > 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-----


  13. Oops in microcode sysfs registration,

    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/

  14. Re: 2.6.27-rc1: zd1211rw association fails

    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/

  15. Re: Oops in microcode sysfs registration,

    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/

  16. Re: Linux v2.6.27-rc1

    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/

  17. Re: Oops in microcode sysfs registration,

    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/

  18. Re: Linux v2.6.27-rc1



    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/

  19. Re: Linux v2.6.27-rc1

    > 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/

  20. Re: Linux v2.6.27-rc1: problem with firmware stuff

    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/

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast