Latest working kernel version: 2.6.26-git6 Earliest failing kernel version: 2.6.26-git7 Distribution: Gentoo Hardware Environment: Packard Bell MB86, iwl4965 Software Environment: dhcpcd Problem Description: I can't get an IP address via DHCP with my wireless connection. I have an Intel Wireless 4965 card and I use WPA personal with AES encryption. After a git-bisect run, it seems the first bad commit is the following: commit 175f9c1bba9b825d22b142d183c9e175488b260c Author: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Date: Sun Jul 20 00:08:47 2008 -0700 net_sched: Add size table for qdiscs Add size table functions for qdiscs and calculate packet size in qdisc_enqueue(). Based on patch by Patrick McHardy http://marc.info/?l=linux-netdev&m=115201979221729&w=2 Steps to reproduce:
In fact I get the following messages in syslog: Jul 22 11:33:16 pc-francois dhcpcd[7121]: wlan0: dhcpcd 3.2.3 starting Jul 22 11:33:16 pc-francois dhcpcd[7121]: wlan0: hardware address = 00:13:e8:c1:41:b9 Jul 22 11:33:16 pc-francois dhcpcd[7121]: wlan0: DUID = 00:01:00:01:0e:f9:52:9e:00:13:e8:c1:41:b9 Jul 22 11:33:16 pc-francois dhcpcd[7121]: wlan0: broadcasting for a lease Jul 22 11:33:17 pc-francois dhcpcd[7121]: wlan0: offered 192.168.1.2 from 192.168.1.1 Jul 22 11:33:37 pc-francois dhcpcd[7121]: wlan0: timed out Jul 22 11:33:37 pc-francois dhcpcd[7121]: wlan0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-wlan0.info' Jul 22 11:33:38 pc-francois dhcpcd[7121]: wlan0: using IPV4LL address 169.254.83.182 Jul 22 11:33:38 pc-francois dhcpcd[7121]: wlan0: adding IP address 169.254.83.182/16 Jul 22 11:33:38 pc-francois dhcpcd[7121]: wlan0: adding route to 169.254.0.0/16 metric 2000 Jul 22 11:33:38 pc-francois dhcpcd[7121]: wlan0: removing route to 169.254.0.0/16 metric 0 Jul 22 11:33:38 pc-francois dhcpcd[7121]: wlan0: exiting Jul 22 11:33:48 pc-francois dhcpcd[9132]: wlan0: offered 192.168.1.2 from 192.168.1.1 Jul 22 11:34:09 pc-francois dhcpcd[9132]: wlan0: adding IP address 169.254.83.182/16 Jul 22 11:34:19 pc-francois dhcpcd[9132]: wlan0: offered 192.168.1.2 from 192.168.1.1 Jul 22 11:34:39 pc-francois dhcpcd[9132]: wlan0: adding IP address 169.254.83.182/16 Jul 22 11:34:49 pc-francois dhcpcd[9132]: wlan0: offered 192.168.1.2 from 192.168.1.1 Jul 22 11:35:10 pc-francois dhcpcd[9132]: wlan0: adding IP address 169.254.83.182/16 Jul 22 11:35:20 pc-francois dhcpcd[9132]: wlan0: offered 192.168.1.2 from 192.168.1.1 Jul 22 11:35:41 pc-francois dhcpcd[9132]: wlan0: adding IP address 169.254.83.182/16 Jul 22 11:35:51 pc-francois dhcpcd[9132]: wlan0: offered 192.168.1.2 from 192.168.1.1 Jul 22 11:36:12 pc-francois dhcpcd[9132]: wlan0: adding IP address 169.254.83.182/16 Jul 22 11:36:22 pc-francois dhcpcd[9132]: wlan0: offered 192.168.1.2 from 192.168.1.1 Jul 22 11:36:43 pc-francois dhcpcd[9132]: wlan0: adding IP address 169.254.83.182/16 So, my router proposes several time a good IP adress (192.168.1.2) but it is never accepted.
Reply-To: akpm@linux-foundation.org (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 22 Jul 2008 03:21:33 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=11144 > > Summary: dhcp doesn't work with iwl4965 > Product: Networking > Version: 2.5 > KernelVersion: 2.6.26-git7 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Wireless > AssignedTo: networking_wireless@kernel-bugs.osdl.org > ReportedBy: francois.valenduc@tvcablenet.be > > > Latest working kernel version: 2.6.26-git6 > Earliest failing kernel version: 2.6.26-git7 A very fresh regression. > Distribution: Gentoo > Hardware Environment: Packard Bell MB86, iwl4965 > Software Environment: dhcpcd > Problem Description: > I can't get an IP address via DHCP with my wireless connection. I have an > Intel > Wireless 4965 card and I use WPA personal with AES encryption. After a > git-bisect run, it seems the first bad commit is the following: > > commit 175f9c1bba9b825d22b142d183c9e175488b260c > Author: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> > Date: Sun Jul 20 00:08:47 2008 -0700 > > net_sched: Add size table for qdiscs > > Add size table functions for qdiscs and calculate packet size in > qdisc_enqueue(). > > Based on patch by Patrick McHardy > http://marc.info/?l=linux-netdev&m=115201979221729&w=2 > > A whole pile of networking patches went into mainline about 12 hours ago, one of which might have fixed this. Can you please test 2.6.26-git10 once it has appeared and let us know the result? Thanks.
Andrew Morton wrote: > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Tue, 22 Jul 2008 03:21:33 -0700 (PDT) bugme-daemon@bugzilla.kernel.org > wrote: > >> http://bugzilla.kernel.org/show_bug.cgi?id=11144 >> >> Summary: dhcp doesn't work with iwl4965 >> Latest working kernel version: 2.6.26-git6 >> Earliest failing kernel version: 2.6.26-git7 > > A very fresh regression. > >> Distribution: Gentoo >> Hardware Environment: Packard Bell MB86, iwl4965 >> Software Environment: dhcpcd >> Problem Description: >> I can't get an IP address via DHCP with my wireless connection. I have an >> Intel >> Wireless 4965 card and I use WPA personal with AES encryption. After a >> git-bisect run, it seems the first bad commit is the following: >> >> commit 175f9c1bba9b825d22b142d183c9e175488b260c >> Author: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> >> Date: Sun Jul 20 00:08:47 2008 -0700 >> >> net_sched: Add size table for qdiscs >> >> Add size table functions for qdiscs and calculate packet size in >> qdisc_enqueue(). >> This implies you're running shaping on your WLAN device. Please post the rules you're using.
Created attachment 16935 [details] iptables rules I guess you want to see my iptables rules. I am not using traffic shaping. Maybe the first bad commit is not the one I have listed. I had to use git-reset an git-bisect skip several times because the kernel didn't compile. But I am sure that the problem occurs between 2.6.26-git6 and -git7.
Andrew Morton wrote: > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). Please reply by mail so others can participate in this thread.
Reply-To: =?ISO-8859-1?Q?Fran=E7ois_Valenduc?= <francois.valenduc@tvcablenet.be> Andrew Morton a
Reply-To: =?ISO-8859-1?Q?Fran=E7ois_Valenduc?= <francois.valenduc@tvcablenet.be> Fran
Reply-To: akpm@linux-foundation.org On Wed, 23 Jul 2008 09:58:21 +0200 Fran__ois Valenduc <francois.valenduc@tvcablenet.be> wrote: > P.S: why don't you want to use the bugzilla interface ? Depends on the subsystem. ACPI is 100% bugzilla-based, net people prefer email, others are in-between. Plus for recently-occurring bugs it's best to knock them over via email without getting into bugzilla bureaucracy. bugzilla is more appropriate to longer-term bugs. And when the bug affects multiple subsystems, multiple developers and we don't even know which subsystem introduced it, it is much better to perform the diagnosis and repair via email. I make a judgement call on each report. Been doing it for a while, don't get too many complaints ;)
Fran
Reply-To: =?ISO-8859-15?Q?Fran=E7ois_Valenduc?= <francois.valenduc@tvcablenet.be> Patrick McHardy a
Patrick McHardy wrote: > Fran
Reply-To: =?windows-1252?Q?Fran=E7ois_Valenduc?= <francois.valenduc@tvcablenet.be> Patrick McHardy a
François Valenduc wrote: > Patrick McHardy a écrit : >>> I think I know whats happening (Jussi CCed). That commit introduced >>> a qdisc_skb_cb, which conflicts with the mac80211 usage of skb->cb. >>> mac80211 seems to expect the CB to survive the qdisc layer, which >>> is wrong. One possibility to fix this (or just test my theory) >>> would be to make sure they don't clash by adding the struct >>> ieee80211_tx_info to qdisc_skb_cb->data. Something like this patch. >>> >> > I tested your last patch. Unfortunately, I get the following compile error: > > In file included from net/mac80211/main.c:11: > include/net/mac80211.h: In function ‘IEEE80211_SKB_CB’: > include/net/mac80211.h:347: erreur: size of array ‘type name’ is negative I was afraid that might happen. This means skb->cb is not large enough to hold both the qdisc and the ieee80211 structs. Just for testing, changing (include/net/mac80211.h): #define IEEE80211_TX_INFO_DRIVER_DATA_SIZE \ (sizeof(((struct sk_buff *)0)->cb) - 8) to #define IEEE80211_TX_INFO_DRIVER_DATA_SIZE \ (sizeof(((struct sk_buff *)0)->cb) - 12) might help to get it to compile. If that doesn't work, try -16.
Reply-To: =?UTF-8?B?RnJhbsOnb2lzIFZhbGVuZHVj?= <francois.valenduc@tvcablenet.be> Patrick McHardy a écrit : > François Valenduc wrote: >> Patrick McHardy a écrit : >>>> I think I know whats happening (Jussi CCed). That commit introduced >>>> a qdisc_skb_cb, which conflicts with the mac80211 usage of skb->cb. >>>> mac80211 seems to expect the CB to survive the qdisc layer, which >>>> is wrong. One possibility to fix this (or just test my theory) >>>> would be to make sure they don't clash by adding the struct >>>> ieee80211_tx_info to qdisc_skb_cb->data. Something like this patch. >>>> >>> >> I tested your last patch. Unfortunately, I get the following compile >> error: >> >> In file included from net/mac80211/main.c:11: >> include/net/mac80211.h: In function ‘IEEE80211_SKB_CB’: >> include/net/mac80211.h:347: erreur: size of array ‘type name’ is >> negative > > > I was afraid that might happen. This means skb->cb is not large > enough to hold both the qdisc and the ieee80211 structs. > > Just for testing, changing (include/net/mac80211.h): > > #define IEEE80211_TX_INFO_DRIVER_DATA_SIZE \ > (sizeof(((struct sk_buff *)0)->cb) - 8) > > to > > #define IEEE80211_TX_INFO_DRIVER_DATA_SIZE \ > (sizeof(((struct sk_buff *)0)->cb) - 12) > > might help to get it to compile. If that doesn't work, try -16. > > That didn't work, neither with -12 or -16.
François Valenduc wrote: > Patrick McHardy a écrit : >>> In file included from net/mac80211/main.c:11: >>> include/net/mac80211.h: In function ‘IEEE80211_SKB_CB’: >>> include/net/mac80211.h:347: erreur: size of array ‘type name’ is >>> negative >> >> >> I was afraid that might happen. This means skb->cb is not large >> enough to hold both the qdisc and the ieee80211 structs. >> >> Just for testing, changing (include/net/mac80211.h): >> >> #define IEEE80211_TX_INFO_DRIVER_DATA_SIZE \ >> (sizeof(((struct sk_buff *)0)->cb) - 8) >> >> to >> >> #define IEEE80211_TX_INFO_DRIVER_DATA_SIZE \ >> (sizeof(((struct sk_buff *)0)->cb) - 12) >> >> might help to get it to compile. If that doesn't work, try -16. >> >> > That didn't work, neither with -12 or -16. I'll give it a try myself, please wait a few minutes.
Patrick McHardy wrote: > François Valenduc wrote: >> Patrick McHardy a écrit : >>>> In file included from net/mac80211/main.c:11: >>>> include/net/mac80211.h: In function ‘IEEE80211_SKB_CB’: >>>> include/net/mac80211.h:347: erreur: size of array ‘type name’ is >>>> negative >>> >>> >>> I was afraid that might happen. This means skb->cb is not large >>> enough to hold both the qdisc and the ieee80211 structs. >>> >>> Just for testing, changing (include/net/mac80211.h): >>> >>> #define IEEE80211_TX_INFO_DRIVER_DATA_SIZE \ >>> (sizeof(((struct sk_buff *)0)->cb) - 8) >>> >>> to >>> >>> #define IEEE80211_TX_INFO_DRIVER_DATA_SIZE \ >>> (sizeof(((struct sk_buff *)0)->cb) - 12) >>> >>> might help to get it to compile. If that doesn't work, try -16. >>> >>> >> That didn't work, neither with -12 or -16. > > I'll give it a try myself, please wait a few minutes. We can't fit them into the cb together, I don't see a way to shrink ieee80211_tx_info. Maybe one of the wireless folks can suggest something? Is it really necessary to pass the full struct ieee80211_tx_info through the qdisc layer, or could the struct be split? It needs to find a way to co-exist peacefully with qdiscs' skb->cb usage.
From: Patrick McHardy <kaber@trash.net> Date: Wed, 23 Jul 2008 18:25:48 +0200 > We can't fit them into the cb together, I don't see a way to > shrink ieee80211_tx_info. > > Maybe one of the wireless folks can suggest something? Is it > really necessary to pass the full struct ieee80211_tx_info > through the qdisc layer, or could the struct be split? It > needs to find a way to co-exist peacefully with qdiscs' > skb->cb usage. This is another area that got mangled up in the ->select_queue() conversion of the WME bits, but in another aspect this problem existed beforehand as well. Specifically, when RX packets get requeued out to transmit in the code in net/mac80211/rx.c that resends packets back out the wireless device by setting a bit in the SKB CB then calling dev_queue_xmit(). That's completely illegal :-) There's a ton of stuff in that structure, I can't see how to make it smaller either. Maybe some bits only matter through the layers of the TX mac80211 stack and thus can be passed as parameters during such processing?
David Miller wrote: > From: Patrick McHardy <kaber@trash.net> > Date: Wed, 23 Jul 2008 18:25:48 +0200 > >> We can't fit them into the cb together, I don't see a way to >> shrink ieee80211_tx_info. >> >> Maybe one of the wireless folks can suggest something? Is it >> really necessary to pass the full struct ieee80211_tx_info >> through the qdisc layer, or could the struct be split? It >> needs to find a way to co-exist peacefully with qdiscs' >> skb->cb usage. > > This is another area that got mangled up in the ->select_queue() > conversion of the WME bits, but in another aspect this problem > existed beforehand as well. > > Specifically, when RX packets get requeued out to transmit in > the code in net/mac80211/rx.c that resends packets back out the > wireless device by setting a bit in the SKB CB then calling > dev_queue_xmit(). > > That's completely illegal :-) It seems its doing even more illegal things that were also present previously. The ieee80211_master_start_xmit function expects to get a valid IEEE80211_SKB_CB, which means it expects it to survive through the entire qdisc layer. I'm not sure how packets get to the master device from the subifs though, so I might be wrong.
Reply-To: tomasw@gmail.com On Thu, Jul 24, 2008 at 11:58 AM, Patrick McHardy <kaber@trash.net> wrote: > David Miller wrote: >> >> From: Patrick McHardy <kaber@trash.net> >> Date: Wed, 23 Jul 2008 18:25:48 +0200 >> >>> We can't fit them into the cb together, I don't see a way to >>> shrink ieee80211_tx_info. >>> >>> Maybe one of the wireless folks can suggest something? Is it >>> really necessary to pass the full struct ieee80211_tx_info >>> through the qdisc layer, or could the struct be split? It >>> needs to find a way to co-exist peacefully with qdiscs' >>> skb->cb usage. >> >> This is another area that got mangled up in the ->select_queue() >> conversion of the WME bits, but in another aspect this problem >> existed beforehand as well. >> >> Specifically, when RX packets get requeued out to transmit in >> the code in net/mac80211/rx.c that resends packets back out the >> wireless device by setting a bit in the SKB CB then calling >> dev_queue_xmit(). >> >> That's completely illegal :-) > > It seems its doing even more illegal things that were also > present previously. The ieee80211_master_start_xmit function > expects to get a valid IEEE80211_SKB_CB, which means it > expects it to survive through the entire qdisc layer. I'm > not sure how packets get to the master device from the > subifs though, so I might be wrong. > Isn't this time to make 802.11 native? Tomas.
Tomas Winkler wrote: > On Thu, Jul 24, 2008 at 11:58 AM, Patrick McHardy <kaber@trash.net> wrote: >> David Miller wrote: >>> From: Patrick McHardy <kaber@trash.net> >>> Date: Wed, 23 Jul 2008 18:25:48 +0200 >>> >>>> We can't fit them into the cb together, I don't see a way to >>>> shrink ieee80211_tx_info. >>>> >>>> Maybe one of the wireless folks can suggest something? Is it >>>> really necessary to pass the full struct ieee80211_tx_info >>>> through the qdisc layer, or could the struct be split? It >>>> needs to find a way to co-exist peacefully with qdiscs' >>>> skb->cb usage. >>> This is another area that got mangled up in the ->select_queue() >>> conversion of the WME bits, but in another aspect this problem >>> existed beforehand as well. >>> >>> Specifically, when RX packets get requeued out to transmit in >>> the code in net/mac80211/rx.c that resends packets back out the >>> wireless device by setting a bit in the SKB CB then calling >>> dev_queue_xmit(). >>> >>> That's completely illegal :-) >> It seems its doing even more illegal things that were also >> present previously. The ieee80211_master_start_xmit function >> expects to get a valid IEEE80211_SKB_CB, which means it >> expects it to survive through the entire qdisc layer. I'm >> not sure how packets get to the master device from the >> subifs though, so I might be wrong. >> > Isn't this time to make 802.11 native? You mean by making these things real skb members? I hope you're not talking about the entire 48 bytes? :)
Reply-To: tomasw@gmail.com On Thu, Jul 24, 2008 at 1:19 PM, Patrick McHardy <kaber@trash.net> wrote: > Tomas Winkler wrote: >> >> On Thu, Jul 24, 2008 at 11:58 AM, Patrick McHardy <kaber@trash.net> wrote: >>> >>> David Miller wrote: >>>> >>>> From: Patrick McHardy <kaber@trash.net> >>>> Date: Wed, 23 Jul 2008 18:25:48 +0200 >>>> >>>>> We can't fit them into the cb together, I don't see a way to >>>>> shrink ieee80211_tx_info. >>>>> >>>>> Maybe one of the wireless folks can suggest something? Is it >>>>> really necessary to pass the full struct ieee80211_tx_info >>>>> through the qdisc layer, or could the struct be split? It >>>>> needs to find a way to co-exist peacefully with qdiscs' >>>>> skb->cb usage. >>>> >>>> This is another area that got mangled up in the ->select_queue() >>>> conversion of the WME bits, but in another aspect this problem >>>> existed beforehand as well. >>>> >>>> Specifically, when RX packets get requeued out to transmit in >>>> the code in net/mac80211/rx.c that resends packets back out the >>>> wireless device by setting a bit in the SKB CB then calling >>>> dev_queue_xmit(). >>>> >>>> That's completely illegal :-) >>> >>> It seems its doing even more illegal things that were also >>> present previously. The ieee80211_master_start_xmit function >>> expects to get a valid IEEE80211_SKB_CB, which means it >>> expects it to survive through the entire qdisc layer. I'm >>> not sure how packets get to the master device from the >>> subifs though, so I might be wrong. >>> >> Isn't this time to make 802.11 native? > > > You mean by making these things real skb members? I hope you're > not talking about the entire 48 bytes? :) I mean elevating 802.11 header to 802.3 level. Not doing 802.3 -> 802.11 translation where not needed. Tomas
On Thu, 2008-07-24 at 14:35 +0300, Tomas Winkler wrote: > >> Isn't this time to make 802.11 native? > > > > > > You mean by making these things real skb members? I hope you're > > not talking about the entire 48 bytes? :) > > I mean elevating 802.11 header to 802.3 level. Not doing 802.3 -> > 802.11 translation where not needed. We've discussed that over and over and over and over again, and it's not going to fly since 802.11 throughout assumes that you have a two-address data service to the upper layers. Besides, making it 802.11 native doesn't help with the control information at all. johannes
Reply-To: =?ISO-8859-1?Q?Fran=E7ois_Valenduc?= <francois.valenduc@tvcablenet.be> Johannes Berg a