* 2.6.37-rc8: Reported regressions from 2.6.36
From: Rafael J. Wysocki @ 2010-12-29 22:59 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.36,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.36, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-12-30 85 32 26
2010-12-19 73 28 24
2010-12-03 55 25 19
2010-11-19 39 29 25
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25842
Subject : thinkpad T410s intel i915 regression
Submitter : Travis Hume <travis@computoring.org>
Date : 2010-12-29 18:21 (1 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25822
Subject : [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
Submitter : Gurudas Pai <gurudas.pai@oracle.com>
Date : 2010-12-29 6:58 (1 days old)
Message-ID : <4D1AD935.1020504@oracle.com>
References : http://marc.info/?l=linux-kernel&m=129360511222037&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25812
Subject : 2.6.37-rc7: Regression: b43: crashes in hwrng_register()
Submitter : Mario 'BitKoenig' Holbe <Mario.Holbe@tu-ilmenau.de>
Date : 2010-12-28 13:32 (2 days old)
Message-ID : <slrnihjpnh.7t4.Mario.Holbe@darkside.dyn.samba-tng.org>
References : http://marc.info/?l=linux-kernel&m=129354319002301&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25602
Subject : [regression] 2.6.37-rc5: scsi_eh_11 CPU loop
Submitter : Martin Steigerwald <Martin@lichtvoll.de>
Date : 2010-12-20 10:05 (10 days old)
Message-ID : <201012201105.08993.Martin@lichtvoll.de>
References : http://marc.info/?l=linux-kernel&m=129283954108331&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25432
Subject : Alpha fails to build with gcc 4.4
Submitter : Ben Hutchings <ben@decadent.org.uk>
Date : 2010-12-22 01:55 (8 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25402
Subject : kernel (2.6.37-8-generic_amd64) panic on boot (with message "map_single: bounce buffer is not DMA'ble) - possible regression !!!
Submitter : carlos <carlos.palma@ono.com>
Date : 2010-12-21 19:58 (9 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25392
Subject : scsi_eh_11 CPU loop
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2010-08-18 6:18 (134 days old)
Message-ID : <1282112318.21202.8.camel@ymzhang.sh.intel.com>
References : http://marc.info/?t=129283967100004&r=1&w=2
http://lkml.org/lkml/2010/12/20/52
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24882
Subject : PM/Hibernate: Memory corruption patch introduces regression (2.6.36.2)
Submitter : <akwatts@ymail.com>
Date : 2010-12-14 04:00 (16 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24822
Subject : Embedded DisplayPort is detected wrongly on HP ProBook 5320m
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2010-12-13 11:09 (17 days old)
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24772
Subject : Crash with btrfs rootfs on dm-crypt [ kernel BUG at fs/btrfs/inode.c:806! ] on linux 2.6.37-rc5
Submitter : Fabio Comolli <fabio.comolli@gmail.com>
Date : 2010-12-10 20:30 (20 days old)
Message-ID : <AANLkTi=j9zsaYNcu=NgGV=HfE-3rNHzVswov8VrgwjQp@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=129201308706568&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24762
Subject : BUG at perf_ctx_adjust_freq (kernel/perf_event.c:1582)
Submitter : Chris Wilson <chris@chris-wilson.co.uk>
Date : 2010-12-10 12:00 (20 days old)
Message-ID : <c6d829$pqibha@fmsmga001.fm.intel.com>
References : http://marc.info/?l=linux-kernel&m=129198247531612&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24592
Subject : 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect
Submitter : Jeremy Fitzhardinge <jeremy@goop.org>
Date : 2010-12-08 21:09 (22 days old)
Message-ID : <4CFFF3F3.90100@goop.org>
References : http://marc.info/?l=linux-kernel&m=129184256629712&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24582
Subject : Kernel Oops at tty_buffer_request_room when using pppd program (2.6.37-rc4)
Submitter : baoyb <baoyb@avit.org.cn>
Date : 2010-12-08 13:55 (22 days old)
Message-ID : <EF6DDE218DB34702B1FA84D6CD7EA771@baoyb>
References : http://marc.info/?l=linux-kernel&m=129181763525738&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24372
Subject : kdump broken on 2.6.37-rc4
Submitter : Stanislaw Gruszka <sgruszka@redhat.com>
Date : 2010-12-03 11:16 (27 days old)
Message-ID : <20101203111623.GA2741@redhat.com>
References : http://marc.info/?l=linux-kernel&m=129137502323003&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24362
Subject : perf hw in kexeced kernel broken in tip
Submitter : Yinghai Lu <yinghai@kernel.org>
Date : 2010-12-01 8:00 (29 days old)
First-Bad-Commit: http://git.kernel.org/linus/33c6d6a7ad0ffab9b1b15f8e4107a2af072a05a0
Message-ID : <4CF60095.1020900@kernel.org>
References : http://marc.info/?l=linux-kernel&m=129119055922065&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24272
Subject : iotop reports insane per-process disk read/write statistics
Submitter : Brian Rogers <brian@xyzw.org>
Date : 2010-12-03 12:00 (27 days old)
First-Bad-Commit: http://git.kernel.org/linus/85893120699f8bae8caa12a8ee18ab5fceac978e
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23902
Subject : [BUG] 2.6.37-rc3 massive interactivity regression on ARM
Submitter : Mikael Pettersson <mikpe@it.uu.se>
Date : 2010-11-27 15:16 (33 days old)
First-Bad-Commit: http://git.kernel.org/linus/305e6835e05513406fa12820e40e4a8ecb63743c
Message-ID : <<19697.8378.717761.236202@pilspetsen.it.uu.se>>
References : http://marc.info/?l=linux-kernel&m=129087098911837&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23472
Subject : 2.6.37-rc2 vs. 2.6.36 laptop backlight changes?
Submitter : Patrick Schaaf <netdev@bof.de>
Date : 2010-11-17 13:41 (43 days old)
Message-ID : <1290001262.5727.2.camel@lat1>
References : http://marc.info/?l=linux-kernel&m=129000127920912&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23102
Subject : [bisected] i915 regression in post 2.6.36 kernels
Submitter : Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
Date : 2010-11-10 7:02 (50 days old)
Message-ID : <201011100802.20332.johannes.hirte@fem.tu-ilmenau.de>
References : http://marc.info/?l=linux-kernel&m=128937310017057&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22942
Subject : [2.6.37-rc1, OOM] virtblk: OOM in do_virtblk_request()
Submitter : Dave Chinner <david@fromorbit.com>
Date : 2010-11-05 1:30 (55 days old)
Message-ID : <20101105013003.GE13830@dastard>
References : http://marc.info/?l=linux-kernel&m=128892062917641&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22912
Subject : spi_lm70llp module crash on unload (2.6.37-rc1)
Submitter : Randy Dunlap <randy.dunlap@oracle.com>
Date : 2010-11-05 0:16 (55 days old)
Message-ID : <20101104171620.00d8c95d.randy.dunlap@oracle.com>
References : http://marc.info/?l=linux-kernel&m=128891627913647&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22882
Subject : (2.6.37-rc1) amd64-agp module crashed on second load
Submitter : Randy Dunlap <randy.dunlap@oracle.com>
Date : 2010-11-05 0:13 (55 days old)
Message-ID : <20101104171333.fea1f498.randy.dunlap@oracle.com>
References : http://marc.info/?l=linux-kernel&m=128891605213447&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22642
Subject : 2.6.37-rc1: Disk takes 10 seconds to resume - MacBook2,1
Submitter : Tobias <devnull@plzk.org>
Date : 2010-11-10 19:33 (50 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22562
Subject : Regression in 2.6.37-rc1 - logs spammed with "unable to enumerate USB port" - bisected to commit 3df7169e
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Date : 2010-11-02 22:32 (58 days old)
First-Bad-Commit: http://git.kernel.org/linus/3df7169e73fc1d71a39cffeacc969f6840cdf52b
Message-ID : <4CD09166.4060202@lwfinger.net>
References : http://marc.info/?l=linux-kernel&m=128873713207906&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22542
Subject : [2.6.37-rc1] drm:i195 errors
Submitter : Paul Rolland <rol@witbe.net>
Date : 2010-11-02 14:58 (58 days old)
Message-ID : <20101102155813.09cb2c6e@tux.DEF.witbe.net>
References : http://marc.info/?l=linux-kernel&m=128870991628970&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22472
Subject : vga_switcheroo fails to switch from intel to ati
Submitter : Radu Andries <admiral0@tuxfamily.org>
Date : 2010-11-08 16:46 (52 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25442
Subject : ixp4xx defines FREQ macro; conflicts with gspca/ov519 driver
Submitter : Ben Hutchings <ben@decadent.org.uk>
Date : 2010-12-22 02:02 (8 days old)
Handled-By : Ben Hutchings <ben@decadent.org.uk>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41252
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25422
Subject : nouveau fails to build on ia64
Submitter : Ben Hutchings <ben@decadent.org.uk>
Date : 2010-12-22 01:49 (8 days old)
Handled-By : Ben Hutchings <ben@decadent.org.uk>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41242
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25012
Subject : BUG: i915 causes NULL pointer dereference in 2.6.37-rc5-git4
Submitter : Tõnu Raitviir <jussuf@linux.ee>
Date : 2010-12-15 12:48 (15 days old)
First-Bad-Commit: http://git.kernel.org/linus/da79de97d254145dcb7c08c978b1093eac15ec9c
Message-ID : <alpine.DEB.2.00.1012151238570.4797@jbbyvx.ohzcpyho.rr>
References : http://www.spinics.net/lists/dri-devel/msg06282.html
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41502
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22812
Subject : kernel oops on 2.6.37-rc1
Submitter : Andrew <atswartz@gmail.com>
Date : 2010-11-12 16:05 (48 days old)
First-Bad-Commit: http://git.kernel.org/linus/a68c439b1966c91f0ef474e2bf275d6792312726
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41192
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22672
Subject : Regression in 2.6.37-rc1 for Intel 945 Graphics Adapter - bisected to commit e9e331a
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Date : 2010-11-11 01:56 (49 days old)
References : https://bugs.freedesktop.org/show_bug.cgi?id=31803
http://marc.info/?l=linux-kernel&m=128944001311444&w=2
http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg02235.html
Patch : https://patchwork.kernel.org/patch/359472/
https://patchwork.kernel.org/patch/359502/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22662
Subject : divide error in select_task_rq_fair()
Submitter : Myron Stowe <myron.stowe@hp.com>
Date : 2010-11-10 23:58 (50 days old)
Patch : http://lkml.org/lkml/2010/11/13/176
http://lkml.org/lkml/2010/11/13/181
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.36,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=21782
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* Re: [PATCH v3 14/18] wl1271: AP mode - record TX configuration settings
From: Luciano Coelho @ 2010-12-29 22:35 UTC (permalink / raw)
To: ext Arik Nemtsov; +Cc: linux-wireless
In-Reply-To: <AANLkTi=tTx=XZ0nFnTsds1F1X2saSYiVmgSxWL1zU-GY@mail.gmail.com>
On Wed, 2010-12-29 at 23:11 +0200, ext Arik Nemtsov wrote:
> On Wed, Dec 29, 2010 at 11:21, Luciano Coelho <luciano.coelho@nokia.com> wrote:
> > On Tue, 2010-12-28 at 19:36 +0200, ext Arik Nemtsov wrote:
> >>
> >> diff --git a/drivers/net/wireless/wl12xx/main.c
> >> b/drivers/net/wireless/wl12xx/main.c
> >> index 3747d98..ea61ae7 100644
> >> --- a/drivers/net/wireless/wl12xx/main.c
> >> +++ b/drivers/net/wireless/wl12xx/main.c
> >> @@ -1433,6 +1433,8 @@ static int wl1271_op_config(struct ieee80211_hw
> >> *hw, u32 changed)
> >> goto out;
> >> }
> >>
> >> + is_ap = (wl->bss_type == BSS_TYPE_AP_BSS);
> >> +
> >> ret = wl1271_ps_elp_wakeup(wl, false);
> >> if (ret < 0)
> >> goto out;
> >
> > Did you forget to fix this one? As we discussed, this should be in
> > 10/18.
> >
>
> Actually it was added in 10/18 (at the beginning of the function), but
> I forgot to remove it from 14/18.
> The correct place to set this is here after the mutex is held, so I've
> moved this line to 10/18 (for good this time I hope).
Yes, after I wrote this email, I checked 10/18 and it was there together
with the is_ap declaration, but, as you said, better do it after the
mutex is locked.
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH] cfg80211: fix transposition of words in printk
From: Bob Copeland @ 2010-12-29 22:09 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Bob Copeland
Fixes the misplaced article in the following:
"cfg80211: Updating information on frequency 5785 MHz for
20 a MHz width channel with regulatory rule:"
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
Take 2, sorry for the noise...
net/wireless/reg.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 99d4183..37693b6 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -752,7 +752,7 @@ static void chan_reg_rule_print_dbg(struct ieee80211_channel *chan,
snprintf(max_antenna_gain, 32, "%d", power_rule->max_antenna_gain);
REG_DBG_PRINT("Updating information on frequency %d MHz "
- "for %d a MHz width channel with regulatory rule:\n",
+ "for a %d MHz width channel with regulatory rule:\n",
chan->center_freq,
KHZ_TO_MHZ(desired_bw_khz));
--
1.7.1.1
^ permalink raw reply related
* Re: # $linville='linville@tuxdriver.com';
From: Bob Copeland @ 2010-12-29 22:07 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <1293659584-9249-1-git-send-email-me@bobcopeland.com>
On Wed, Dec 29, 2010 at 4:53 PM, Bob Copeland <me@bobcopeland.com> wrote:
> @to = (
> $linville,
> );
>
> @cc = (
> $wl
> );
Heh, wrong args to my mailer script...
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* # $linville='linville@tuxdriver.com';
From: Bob Copeland @ 2010-12-29 21:53 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
@to = (
$linville,
);
@cc = (
$wl
);
^ permalink raw reply
* Re: wl1271: how to use without runtime pm
From: Ohad Ben-Cohen @ 2010-12-29 21:22 UTC (permalink / raw)
To: Sergey Matyukevich; +Cc: Luciano Coelho, linux-wireless
In-Reply-To: <20101230000737.74d30852@lair>
On Wed, Dec 29, 2010 at 11:07 PM, Sergey Matyukevich <geomatsi@gmail.com> wrote:
> So the question is: what is the proper use of wl1271 driver in the case
> when wl1271 card is powered all the time ?
The wl1271 driver assumes it can control the power of the card.
If your card's power is always on, you will not be able to toggle the
interface down and up (as you have experienced).
It might be possible to change the driver around this "limitation",
but I'm not sure anyone has ever really tried.
^ permalink raw reply
* Re: [PATCH v3 14/18] wl1271: AP mode - record TX configuration settings
From: Arik Nemtsov @ 2010-12-29 21:11 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
In-Reply-To: <1293614508.15791.0.camel@powerslave>
On Wed, Dec 29, 2010 at 11:21, Luciano Coelho <luciano.coelho@nokia.com> wrote:
> On Tue, 2010-12-28 at 19:36 +0200, ext Arik Nemtsov wrote:
>>
>> diff --git a/drivers/net/wireless/wl12xx/main.c
>> b/drivers/net/wireless/wl12xx/main.c
>> index 3747d98..ea61ae7 100644
>> --- a/drivers/net/wireless/wl12xx/main.c
>> +++ b/drivers/net/wireless/wl12xx/main.c
>> @@ -1433,6 +1433,8 @@ static int wl1271_op_config(struct ieee80211_hw
>> *hw, u32 changed)
>> goto out;
>> }
>>
>> + is_ap = (wl->bss_type == BSS_TYPE_AP_BSS);
>> +
>> ret = wl1271_ps_elp_wakeup(wl, false);
>> if (ret < 0)
>> goto out;
>
> Did you forget to fix this one? As we discussed, this should be in
> 10/18.
>
Actually it was added in 10/18 (at the beginning of the function), but
I forgot to remove it from 14/18.
The correct place to set this is here after the mutex is held, so I've
moved this line to 10/18 (for good this time I hope).
Thanks,
Arik
^ permalink raw reply
* wl1271: how to use without runtime pm
From: Sergey Matyukevich @ 2010-12-29 21:07 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
Hello Luciano,
I use omap3evm board with wl1271 extension module. Current version of
wl1271 driver works fine on upstream kernel and (with minor
modifications resulting from older mac80211) on 2.6.32 kernel with
integrated SDIO runtime PM patches from Ohad Ben-Cohen.
In the current kernel runtime PM support is always enabled for
omap2plus boards. However this is not the case for the earlier kernels.
Besides, on some other boards there might be no gpio pin to control
power supply of wl1271 card.
So the question is: what is the proper use of wl1271 driver in the case
when wl1271 card is powered all the time ?
In a simple experiment I removed all pm_runtime functions from
wl1271_sdio.c and removed MMC_CAP_POWER_OFF_CARD flag from mmc slot
settings in board file. However I can't do ifdown/ifup procedure
properly:
root@omap3evm_minimal:~# ifconfig wlan0 down
root@omap3evm_minimal:~# ifconfig wlan0 up
[ 55.313201] wl1271: ERROR timeout waiting for the hardware to
complete initialization
[ 58.813964] wl1271: ERROR timeout waiting for the hardware to
complete initialization
[ 60.648651] wl1271: ERROR sdio read failed (-110)
[ 60.653686] wl1271: ERROR sdio write failed (-110)
[ 62.057067] wl1271: ERROR sdio read failed (-110)
[ 62.062072] wl1271: ERROR chip id doesn't match after firmware boot
[ 62.068786] wl1271: ERROR firmware boot failed despite 3 retries
ifconfig: SIOCSIFFLAGS: Input/output error
It looks like init procedure of wl1271 card can not be done twice
without powering off wl1271 card.
Thanks,
Sergey
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 1/6] ath5k: Always write tx powertable on hw
From: Bob Copeland @ 2010-12-29 21:02 UTC (permalink / raw)
To: ath5k-devel, linux-wireless, linville, me, mcgrof, jirislaby, nbd,
br1, sedat.dilek
In-Reply-To: <20101203040300.GA2988@makis.mantri>
On Thu, Dec 2, 2010 at 11:03 PM, Nick Kossifidis <mickflemm@gmail.com> wrote:
> * By skipping tx power table calibration we also skip setting
> tx power table on hw. Make sure we always write tx power table
> on hw since it gets cleared on reset.
>
> Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Just a very late heads-up, this patch seems to be causing problems
for me.
Seems a bit weird given the content, but the symptom is that
when I bring up the device none of my probe requests are actually
getting sent, according to wireshark captures from another device.
Reverting just this patch helps, so my power table must be broken
at start up.
I saw that Bruno had a later series that touched this area, so I'll
try them next.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Compat-wireless release for 2010-12-29 is baked
From: Compat-wireless cronjob account @ 2010-12-29 20:04 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
9688efd..2c4665a history -> origin/history
+ b79b3fb...fd9ae9b master -> origin/master (forced update)
ffc96d6..b52e2a6 stable -> origin/stable
* [new tag] next-20101229 -> next-20101229
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
compat-wireless code metrics
774936 - Total upstream lines of code being pulled
^ permalink raw reply
* [PATCH] Staging: ath6kl: fix potential buffer overflow
From: Vipin Mehta @ 2010-12-29 20:01 UTC (permalink / raw)
To: greg; +Cc: linux-wireless, simbwa, error27, devel, Vipin Mehta
From: Phillip Simbwa <simbwa@gmail.com>
Off by one
Signed-off-by: Phillip Simbwa <simbwa at gmail dot com>
Signed-off-by: Vipin Mehta <vmehta@atheros.com>
---
.../staging/ath6kl/miscdrv/ar3kps/ar3kpsconfig.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/ath6kl/miscdrv/ar3kps/ar3kpsconfig.c b/drivers/staging/ath6kl/miscdrv/ar3kps/ar3kpsconfig.c
index 0e298db..29b8ab4 100644
--- a/drivers/staging/ath6kl/miscdrv/ar3kps/ar3kpsconfig.c
+++ b/drivers/staging/ath6kl/miscdrv/ar3kps/ar3kpsconfig.c
@@ -360,8 +360,8 @@ int PSSendOps(void *arg)
status = 1;
goto complete;
}
- len = (firmware->size > MAX_BDADDR_FORMAT_LENGTH)? MAX_BDADDR_FORMAT_LENGTH: firmware->size;
- memcpy(config_bdaddr, firmware->data,len);
+ len = min(firmware->size, MAX_BDADDR_FORMAT_LENGTH - 1);
+ memcpy(config_bdaddr, firmware->data, len);
config_bdaddr[len] = '\0';
write_bdaddr(hdev,config_bdaddr,BDADDR_TYPE_STRING);
A_RELEASE_FIRMWARE(firmware);
--
1.6.3.3
^ permalink raw reply related
* Re: 2.6.37-rc7: Regression: b43: crashes in hwrng_register()
From: Mario 'BitKoenig' Holbe @ 2010-12-29 19:54 UTC (permalink / raw)
To: Larry Finger; +Cc: LKML, wireless, b43-dev
In-Reply-To: <4D1A8200.4010609@lwfinger.net>
[-- Attachment #1.1: Type: text/plain, Size: 3124 bytes --]
Hello Larry,
On Tue, Dec 28, 2010 at 06:34:08PM -0600, Larry Finger wrote:
> Mario Holbe wrote:
> > on 2.6.37-rc7 the b43 driver crashes in hwrng_register(). This makes the
...
> > This issue does also exist in 2.6.37-rc5.
> > This issue does not exist in 2.6.36.2.
...
> > [ 29.868632] BUG: unable to handle kernel paging request at 907cde0c
> > [ 29.868640] IP: [<f8d543cc>] hwrng_register+0x4c/0x139 [rng_core]
...
> > [ 29.868884] Call Trace:
> > [ 29.868909] [<f8e5a870>] ? b43_wireless_core_init+0xd0c/0xdd6 [b43]
>
> I almost missed this posting.
You're welcome :)
> Please post wireless problems with
> linux-wireless@vger.kernel.org for better visibility.
Sorry and thanks for completing the CC: list.
> I have a BCM4312 (14e4:4315) on a netbook that does not have this problem, thus
> I will have to rely on your debugging. An additional difficulty is that the only
> changes to b43 between 2.6.36 and 2.6.37 are adding an additional PCI ID, some
> fixes to the SDIO driver, and some code for an 802.11n device. None of these
> should affect your 802.11 b/g unit.
>
> Is it possible for you to bisect between 2.6.36 and 2.6.37-rc5? I wish I could
> suggest some way to minimize the number of commits and builds, but the problem
> could be anywhere.
To be honest, I never bisected such a huge amount of commits before and
I'm somewhat afraid of doing it.
However, I think I'm able to nail the issue down to:
commit 84c164a34ffe67908a932a2d641ec1a80c2d5435 which went to 2.6.37-rc1.
Author: John W. Linville <linville@tuxdriver.com>
Date: Fri Aug 6 15:31:45 2010 -0400
b43: move hwrng registration driver to wireless core initialization
Message-ID: <1281126412-5089-1-git-send-email-linville@tuxdriver.com>
http://marc.info/?l=linux-wireless&m=128112658829379&w=2
I did 2 things:
1. I (manually) reverted 84c164a34ffe67908a932a2d641ec1a80c2d5435 from
2.6.37-rc7: The crash disappears, b43 is useable.
2. I added 84c164a34ffe67908a932a2d641ec1a80c2d5435 to 2.6.36.2: The
crash shows up as with vanilla 2.6.37-rc7.
I'm not sure why this is not reproducible for you, probably it has
something to do with the VIA Nano having a second HW-RNG driven by
via-rng. I experienced crashes in the past with earlier kernels when I
tried to move RNGs around via /sys/devices/virtual/misc/hw_random, but
never took the time to trace them down since I just got it working :)
Oh, I'm still able to trigger a crash with
$ cat /sys/devices/virtual/misc/hw_random/rng_available
on 2.6.37-rc7 without 84c164a34ffe67908a932a2d641ec1a80c2d5435 as well
as on vanilla 2.6.36.2. Probably this is (better) reproducible for you?
I suspect both (the 84c164a34ffe67908a932a2d641ec1a80c2d5435 crash as
well as the cat rng_available crash) having something to do with a
partially uninitialized rng-struct, or better: parts of the rng-struct
that are free()d too early (i.e. within its lifetime).
regards
Mario
--
Doing it right is no excuse for not meeting the schedule.
-- Plant Manager, Delphi Corporation
[-- Attachment #1.2: 2.6.36.2.rng_available-crash.dmesg --]
[-- Type: text/plain, Size: 3304 bytes --]
[ 389.303538] BUG: unable to handle kernel paging request at 288dcb5b
[ 389.303553] IP: [<f8dda34c>] hwrng_attr_available_show+0x5c/0x90 [rng_core]
[ 389.303582] *pde = 00000000
[ 389.303591] Oops: 0000 [#1] SMP
[ 389.303599] last sysfs file: /sys/devices/virtual/misc/hw_random/rng_available
[ 389.303609] Modules linked in: uinput via drm sco bnep rfcomm l2cap crc16 parport_pc ppdev lp parport sbs sbshc power_meter pci_slot hed fan container acpi_cpufreq mperf cpufreq_conservative cpufreq_userspace cpufreq_stats cpufreq_powersave dm_crypt fuse loop eeprom via_cputemp i2c_dev nvram padlock_aes aes_i586 aes_generic padlock_sha sha256_generic sha1_generic via_rng msr cpuid snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm arc4 joydev ecb snd_seq_midi b43 rng_core snd_rawmidi snd_seq_midi_event mac80211 snd_seq uvcvideo video snd_timer cfg80211 snd_seq_device videodev v4l1_compat ideapad_laptop snd btusb i2c_viapro led_class sparse_keymap bluetooth tpm_tis tpm wmi output i2c_core battery tpm_bios shpchp processor ac soundcore rfkill pcspkr pci_hotplug snd_page_alloc psmouse button serio_raw evdev ext3 jbd mbcache raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0 multipath linear md_mod dm_mirror dm_region_hash dm_log dm_mod btrfs zlib_deflate crc32c libcrc32c sd_mod crc_t10dif ata_generic pata_via libata uhci_hcd ehci_hcd ssb scsi_mod usbcore tg3 via_sdmmc pcmcia mmc_core libphy thermal thermal_sys pcmcia_core nls_base [last unloaded: scsi_wait_scan]
[ 389.303871]
[ 389.303882] Pid: 3004, comm: cat Not tainted 2.6.36.2 #1 MoutCook/20021,2959
[ 389.303893] EIP: 0060:[<f8dda34c>] EFLAGS: 00010216 CPU: 0
[ 389.303908] EIP is at hwrng_attr_available_show+0x5c/0x90 [rng_core]
[ 389.303918] EAX: f5da2000 EBX: 288dcb3f ECX: 00000ff1 EDX: f8dda571
[ 389.303928] ESI: f5da2000 EDI: 0000000d EBP: 00000fff ESP: f6841f30
[ 389.303937] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 389.303948] Process cat (pid: 3004, ti=f6840000 task=f5c9f180 task.ti=f6840000)
[ 389.303955] Stack:
[ 389.303960] f8dda618 fffffffb f8dda2f0 c12b1834 c11bd17e f5ccaf40 f69fe330 f6841f9c
[ 389.303978] <0> c10f8244 f5d9bcc0 f5ccaf54 f69c7e08 09a66000 00008000 f5d9bcc0 09a66000
[ 389.303997] <0> c10f81b8 f6841f9c c10b7774 f6841f9c c1282259 f5d9bcc0 fffffff7 09a66000
[ 389.304015] Call Trace:
[ 389.304015] [<f8dda2f0>] ? hwrng_attr_available_show+0x0/0x90 [rng_core]
[ 389.304015] [<c11bd17e>] ? dev_attr_show+0x16/0x32
[ 389.304015] [<c10f8244>] ? sysfs_read_file+0x8c/0xf5
[ 389.304015] [<c10f81b8>] ? sysfs_read_file+0x0/0xf5
[ 389.304015] [<c10b7774>] ? vfs_read+0x7c/0xd6
[ 389.304015] [<c1282259>] ? do_page_fault+0x26d/0x2cf
[ 389.304015] [<c10b7861>] ? sys_read+0x3c/0x60
[ 389.304015] [<c1002f1f>] ? sysenter_do_call+0x12/0x28
[ 389.304015] Code: e9 89 f0 29 f9 e8 ef 63 36 c8 8b 03 e8 60 64 36 c8 89 e9 ba 71 a5 dd f8 8d 3c 38 89 f0 29 f9 47 e8 d4 63 36 c8 8b 5b 1c 83 eb 1c <8b> 43 1c 0f 18 00 90 81 fb d0 a5 dd f8 75 c3 b9 ff 0f 00 00 ba
[ 389.304015] EIP: [<f8dda34c>] hwrng_attr_available_show+0x5c/0x90 [rng_core] SS:ESP 0068:f6841f30
[ 389.304015] CR2: 00000000288dcb5b
[ 389.304311] ---[ end trace a1f28568aee0d057 ]---
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]
^ permalink raw reply
* Re: [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
From: Johannes Berg @ 2010-12-29 18:13 UTC (permalink / raw)
To: christoph.paasch; +Cc: Larry Finger, linville, linux-wireless, chunkeey
In-Reply-To: <201012291816.27302.christoph.paasch@uclouvain.be>
On Wed, 2010-12-29 at 18:16 +0100, Christoph Paasch wrote:
> +#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_P54_LEDS)
> struct p54_common *priv = dev->priv;
> +#endif
It seems a lot simpler to just add __maybe_unused...
johannes
^ permalink raw reply
* Re: [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
From: Larry Finger @ 2010-12-29 17:32 UTC (permalink / raw)
To: christoph.paasch; +Cc: linville, linux-wireless, chunkeey
In-Reply-To: <201012291816.27302.christoph.paasch@uclouvain.be>
On 12/29/2010 11:16 AM, Christoph Paasch wrote:
> On Wednesday, December 29, 2010 wrote Larry Finger:
>> I was too quick to ACK this. The second hunk causes a compiler ERROR as
>> priv is needed in the mutex_destroy() calls.
>
> Oups, sorry. I did not have CONFIG_DEBUG_MUTEXES enabled when trying it out.
> Thus the compile-error did not happen.
>
> What about the following patch?
It seems to be what is needed if the mutex_destroy() calls are compiled away.
> From 5701b5f5ffbf0927025906e968c957f3b2292ece Mon Sep 17 00:00:00 2001
> From: Christoph Paasch <christoph.paasch@uclouvain.be>
> Date: Wed, 29 Dec 2010 12:40:43 +0100
> Subject: [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
>
> The priv-variable is unused when compiling without CONFIG_P54_LEDS.
>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> ---
> drivers/net/wireless/p54/main.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
> index 622d27b..56ea1ce 100644
> --- a/drivers/net/wireless/p54/main.c
> +++ b/drivers/net/wireless/p54/main.c
> @@ -611,7 +611,9 @@ EXPORT_SYMBOL_GPL(p54_init_common);
>
> int p54_register_common(struct ieee80211_hw *dev, struct device *pdev)
> {
> +#ifdef CONFIG_P54_LEDS
> struct p54_common *priv = dev->priv;
> +#endif /* CONFIG_P54_LEDS */
> int err;
>
> err = ieee80211_register_hw(dev);
> @@ -653,7 +655,9 @@ EXPORT_SYMBOL_GPL(p54_free_common);
>
> void p54_unregister_common(struct ieee80211_hw *dev)
> {
> +#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_P54_LEDS)
> struct p54_common *priv = dev->priv;
> +#endif
>
> #ifdef CONFIG_P54_LEDS
> p54_unregister_leds(priv);
Larry
^ permalink raw reply
* Re: [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
From: Christoph Paasch @ 2010-12-29 17:16 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, chunkeey
In-Reply-To: <4D1B65D7.8090103@lwfinger.net>
On Wednesday, December 29, 2010 wrote Larry Finger:
> I was too quick to ACK this. The second hunk causes a compiler ERROR as
> priv is needed in the mutex_destroy() calls.
Oups, sorry. I did not have CONFIG_DEBUG_MUTEXES enabled when trying it out.
Thus the compile-error did not happen.
What about the following patch?
>From 5701b5f5ffbf0927025906e968c957f3b2292ece Mon Sep 17 00:00:00 2001
From: Christoph Paasch <christoph.paasch@uclouvain.be>
Date: Wed, 29 Dec 2010 12:40:43 +0100
Subject: [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
The priv-variable is unused when compiling without CONFIG_P54_LEDS.
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
drivers/net/wireless/p54/main.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
index 622d27b..56ea1ce 100644
--- a/drivers/net/wireless/p54/main.c
+++ b/drivers/net/wireless/p54/main.c
@@ -611,7 +611,9 @@ EXPORT_SYMBOL_GPL(p54_init_common);
int p54_register_common(struct ieee80211_hw *dev, struct device *pdev)
{
+#ifdef CONFIG_P54_LEDS
struct p54_common *priv = dev->priv;
+#endif /* CONFIG_P54_LEDS */
int err;
err = ieee80211_register_hw(dev);
@@ -653,7 +655,9 @@ EXPORT_SYMBOL_GPL(p54_free_common);
void p54_unregister_common(struct ieee80211_hw *dev)
{
+#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_P54_LEDS)
struct p54_common *priv = dev->priv;
+#endif
#ifdef CONFIG_P54_LEDS
p54_unregister_leds(priv);
--
1.7.1
--
Christoph Paasch
Research Assistant
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
www.rollerbulls.be
--
^ permalink raw reply related
* Re: Compile error for the last week inside rtlwifi/base.c
From: Larry Finger @ 2010-12-29 16:56 UTC (permalink / raw)
To: Weedy; +Cc: linux-wireless
In-Reply-To: <loom.20101229T034155-409@post.gmane.org>
On 12/28/2010 08:43 PM, Weedy wrote:
> Larry Finger <Larry.Finger@...> writes:
>
>> Older kernels used create_workqueue(), which is replaced by alloc_workqueue()
>> If you really need the driver for RTL8192CE/RTL8188CE, then apply the patch
>> shown below. If you do not need the driver, then disable it in the
>> configuration.
>>
>> Larry
>
> Actually I need RTL8192USB, I guess I need to wait more?
What are the USB Ids as shown by the lsusb command?
Larry
^ permalink raw reply
* Re: [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
From: Larry Finger @ 2010-12-29 16:46 UTC (permalink / raw)
To: Christoph Paasch; +Cc: linville, linux-wireless, chunkeey
In-Reply-To: <1293635679-9783-1-git-send-email-christoph.paasch@uclouvain.be>
On 12/29/2010 09:14 AM, Christoph Paasch wrote:
> The priv-variable is unused when compiling without CONFIG_P54_LEDS.
>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> ---
> drivers/net/wireless/p54/main.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
> index 622d27b..a6802f5 100644
> --- a/drivers/net/wireless/p54/main.c
> +++ b/drivers/net/wireless/p54/main.c
> @@ -611,7 +611,9 @@ EXPORT_SYMBOL_GPL(p54_init_common);
>
> int p54_register_common(struct ieee80211_hw *dev, struct device *pdev)
> {
> +#ifdef CONFIG_P54_LEDS
> struct p54_common *priv = dev->priv;
> +#endif /* CONFIG_P54_LEDS */
> int err;
>
> err = ieee80211_register_hw(dev);
> @@ -653,9 +655,9 @@ EXPORT_SYMBOL_GPL(p54_free_common);
>
> void p54_unregister_common(struct ieee80211_hw *dev)
> {
> +#ifdef CONFIG_P54_LEDS
> struct p54_common *priv = dev->priv;
>
> -#ifdef CONFIG_P54_LEDS
> p54_unregister_leds(priv);
> #endif /* CONFIG_P54_LEDS */
>
I was too quick to ACK this. The second hunk causes a compiler ERROR as priv is
needed in the mutex_destroy() calls.
NACK
Larry
^ permalink raw reply
* Re: [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
From: Larry Finger @ 2010-12-29 16:19 UTC (permalink / raw)
To: Christoph Paasch; +Cc: linville, linux-wireless, chunkeey
In-Reply-To: <1293635679-9783-1-git-send-email-christoph.paasch@uclouvain.be>
On 12/29/2010 09:14 AM, Christoph Paasch wrote:
> The priv-variable is unused when compiling without CONFIG_P54_LEDS.
>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> ---
> drivers/net/wireless/p54/main.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
> index 622d27b..a6802f5 100644
> --- a/drivers/net/wireless/p54/main.c
> +++ b/drivers/net/wireless/p54/main.c
> @@ -611,7 +611,9 @@ EXPORT_SYMBOL_GPL(p54_init_common);
>
> int p54_register_common(struct ieee80211_hw *dev, struct device *pdev)
> {
> +#ifdef CONFIG_P54_LEDS
> struct p54_common *priv = dev->priv;
> +#endif /* CONFIG_P54_LEDS */
> int err;
>
> err = ieee80211_register_hw(dev);
> @@ -653,9 +655,9 @@ EXPORT_SYMBOL_GPL(p54_free_common);
>
> void p54_unregister_common(struct ieee80211_hw *dev)
> {
> +#ifdef CONFIG_P54_LEDS
> struct p54_common *priv = dev->priv;
>
> -#ifdef CONFIG_P54_LEDS
> p54_unregister_leds(priv);
> #endif /* CONFIG_P54_LEDS */
>
ACKed-by: Larry Finger <Larry.Finger@lwfinger.net>
^ permalink raw reply
* Re: BUG: while bridging Ethernet and wireless device:
From: Tomas Winkler @ 2010-12-29 16:12 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-netdev, linux-wireless,
YOSHIFUJI Hideaki / 吉藤英明
In-Reply-To: <1293635067.3546.16.camel@jlt3.sipsolutions.net>
2010/12/29 Johannes Berg <johannes@sipsolutions.net>:
> On Thu, 2010-12-16 at 14:11 +0200, Tomas Winkler wrote:
>> Will be happy if someone can give me some more insight. (kernel 2.6.37-rc5)
>
> Tomas looked into it a bit more and told me that it happens on IPv6
> packets. To recap, he gets
>
> kernel BUG at include/linux/skbuff.h:1178!
> with
> EIP: [<f83edd65>] br_multicast_rcv+0xc95/0xe1c [bridge]
>
> Also remember that the packets are almost fully nonlinear, when they get
> here they likely have almost no data in the skb header.
>
> I then looked at br_multicast_ipv6_rcv(), and it looks fishy:
>
> Up to:
> skb2 = skb_clone(skb, GFP_ATOMIC);
>
> everything's fine, since ipv6_skip_exthdr() will use
> skb_header_pointer(). At this point, offset is the result of
> ipv6_skip_exthdr(). Remember that skb_clone() is not skb_copy().
So far I can confirm that switching to sbk_copy fixes the crash.
Thanks
Tomas
^ permalink raw reply
* [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
From: Christoph Paasch @ 2010-12-29 15:14 UTC (permalink / raw)
To: linville; +Cc: Christoph Paasch, linux-wireless, chunkeey
The priv-variable is unused when compiling without CONFIG_P54_LEDS.
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
drivers/net/wireless/p54/main.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
index 622d27b..a6802f5 100644
--- a/drivers/net/wireless/p54/main.c
+++ b/drivers/net/wireless/p54/main.c
@@ -611,7 +611,9 @@ EXPORT_SYMBOL_GPL(p54_init_common);
int p54_register_common(struct ieee80211_hw *dev, struct device *pdev)
{
+#ifdef CONFIG_P54_LEDS
struct p54_common *priv = dev->priv;
+#endif /* CONFIG_P54_LEDS */
int err;
err = ieee80211_register_hw(dev);
@@ -653,9 +655,9 @@ EXPORT_SYMBOL_GPL(p54_free_common);
void p54_unregister_common(struct ieee80211_hw *dev)
{
+#ifdef CONFIG_P54_LEDS
struct p54_common *priv = dev->priv;
-#ifdef CONFIG_P54_LEDS
p54_unregister_leds(priv);
#endif /* CONFIG_P54_LEDS */
--
1.7.1
^ permalink raw reply related
* Re: BUG: while bridging Ethernet and wireless device:
From: Johannes Berg @ 2010-12-29 15:04 UTC (permalink / raw)
To: Tomas Winkler
Cc: linux-netdev, linux-wireless,
YOSHIFUJI Hideaki / 吉藤英明
In-Reply-To: <AANLkTikYvBspVmAZ0DCMXJ-3WxkotwX+n8NpTtM+97_i@mail.gmail.com>
On Thu, 2010-12-16 at 14:11 +0200, Tomas Winkler wrote:
> Will be happy if someone can give me some more insight. (kernel 2.6.37-rc5)
Tomas looked into it a bit more and told me that it happens on IPv6
packets. To recap, he gets
kernel BUG at include/linux/skbuff.h:1178!
with
EIP: [<f83edd65>] br_multicast_rcv+0xc95/0xe1c [bridge]
Also remember that the packets are almost fully nonlinear, when they get
here they likely have almost no data in the skb header.
I then looked at br_multicast_ipv6_rcv(), and it looks fishy:
Up to:
skb2 = skb_clone(skb, GFP_ATOMIC);
everything's fine, since ipv6_skip_exthdr() will use
skb_header_pointer(). At this point, offset is the result of
ipv6_skip_exthdr(). Remember that skb_clone() is not skb_copy().
Then, however, we do
__skb_pull(skb2, offset);
At this point, however, I don't see anything that guarantees that all
"offset" bytes are part of the headroom -- and indeed I think this is
where it crashes.
If it didn't crash, because this many bytes were part of the header,
continuing further into the function, however, we could still crash:
if (!pskb_may_pull(skb2, sizeof(*icmp6h)))
goto out;
now makes sure that we can read the ICMPv6 header. Later, however, we do
case ICMPV6_MGM_REPORT:
{
struct mld_msg *mld = (struct mld_msg *)icmp6h;
BR_INPUT_SKB_CB(skb2)->mrouters_only = 1;
err = br_ip6_multicast_add_group(br, port, &mld->mld_mca);
which seems just as unsafe since "mld_mca" need not be part of the
header of the SKB. Similarly in another branch of this.
Additionally, I'm not convinced that there even is guaranteed to be
enough space in the SKB at all for the entire "struct mld_msg".
And finally, the error path in this function is confusing. Below patch
should be fine since unlike IPv4 (where this was copied maybe?) this
code unconditionally clones the SKB.
johannes
---
net/bridge/br_multicast.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- wireless-testing.orig/net/bridge/br_multicast.c 2010-12-29 15:45:03.000000000 +0100
+++ wireless-testing/net/bridge/br_multicast.c 2010-12-29 16:03:03.000000000 +0100
@@ -1430,7 +1430,7 @@ static int br_multicast_ipv6_rcv(struct
struct net_bridge_port *port,
struct sk_buff *skb)
{
- struct sk_buff *skb2 = skb;
+ struct sk_buff *skb2;
struct ipv6hdr *ip6h;
struct icmp6hdr *icmp6h;
u8 nexthdr;
@@ -1535,9 +1535,7 @@ static int br_multicast_ipv6_rcv(struct
}
out:
- __skb_push(skb2, offset);
- if (skb2 != skb)
- kfree_skb(skb2);
+ kfree_skb(skb2);
return err;
}
#endif
^ permalink raw reply
* Re: [PATCH RFC] mac80211: Extend channel to frequency mapping for 802.11j
From: Dave Kilroy @ 2010-12-29 13:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: Bruno Randolf, linville, linux-wireless
In-Reply-To: <1293529983.3526.9.camel@jlt3.sipsolutions.net>
On Tue, Dec 28, 2010 at 9:53 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2010-12-28 at 10:51 +0100, Johannes Berg wrote:
>
>> > ieee80211_dsss_chan_to_freq - atmel, airo, wl3501_cs, orinoco, rndis_wlan
>> > ieee80211_freq_to_dsss_chan - atmel, airo, orinoco, zd1201
>> >
>> > Anyhow i guess it would make sense to have a common channel to frequency
>> > mapping function for mac80211 and other wireless drivers? The problem is now
>> > we have to use enum ieee80211_band which is defined cfg80211.h...
>
> Interestingly, I just noticed that the above ones also have different
> semantics -- they try to round to the nearest channel rather than
> returning an error if the center frequency isn't exact.
I suspect I introduced these functions while refactoring orinoco (well
before the cfg80211 conversion). If I recall correctly, there was no
specific reason for the round to nearest behaviour - it just seemed
more appropriate than rounding down the frequencies. So if it helps, I
don't see why we shouldn't modify the behaviour of the ieee80211
functions where necessary.
Dave.
^ permalink raw reply
* Re: BUG: Microcode SW error detected / Frequent disconnects
From: Florian Kriener @ 2010-12-29 11:01 UTC (permalink / raw)
To: Guy, Wey-Yi; +Cc: sedat.dilek@gmail.com, linux-wireless@vger.kernel.org
In-Reply-To: <201012102010.16921.florian@kriener.org>
On Friday 10 December 2010 20:10:16 Florian Kriener wrote:
> On Friday 10 December 2010 16:26:14 Guy, Wey-Yi wrote:
> > Looks like you have 5000 NIC device based on the firmware version.
> > Please let me know the problem still happen in 2.6.36. If does, we
> > can look into possible firmware problem
>
> Yes, it is a 5300 . I guess you mean 2.6.37 and yes I will let you
> know.
I promised to mail again if I see the firmware error again with 2.6.37.
There you go:
[ 2296.117090] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 4
[ 2298.344144] iwlagn 0000:03:00.0: iwlagn_tx_agg_start on ra = 00:1f:3f:62:fd:83 tid = 0
[ 3132.669181] iwlagn 0000:03:00.0: low ack count detected, restart firmware
[ 3132.669190] iwlagn 0000:03:00.0: On demand firmware reload
[ 3132.706279] iwlagn 0000:03:00.0: Stopping AGG while state not ON or starting
[ 3132.706290] iwlagn 0000:03:00.0: queue number out of range: 0, must be 10 to 19
[ 3209.576047] iwlagn 0000:03:00.0: iwlagn_tx_agg_start on ra = 00:1f:3f:62:fd:83 tid = 0
[ 4913.689836] iwlagn 0000:03:00.0: Microcode SW error detected. Restarting 0x2000000.
[ 4913.689846] iwlagn 0000:03:00.0: Loaded firmware version: 8.24.2.12
[ 4913.689866] iwlagn 0000:03:00.0: Start IWL Error Log Dump:
[ 4913.689873] iwlagn 0000:03:00.0: Status: 0x000212E4, count: 5
[ 4913.690031] iwlagn 0000:03:00.0: Desc Time data1 data2 line
[ 4913.690041] iwlagn 0000:03:00.0: SYSASSERT (0x0005) 0000521857 0x00008035 0x00006905 1364
[ 4913.690047] iwlagn 0000:03:00.0: pc blink1 blink2 ilink1 ilink2 hcmd
[ 4913.690055] iwlagn 0000:03:00.0: 0x03AE8 0x039B8 0x039B8 0x008B2 0x00000 0x4E7004E
[ 4913.690060] iwlagn 0000:03:00.0: CSR values:
[ 4913.690065] iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
[ 4913.690075] iwlagn 0000:03:00.0: CSR_HW_IF_CONFIG_REG: 0X00480302
[ 4913.690084] iwlagn 0000:03:00.0: CSR_INT_COALESCING: 0X0000ff40
[ 4913.690093] iwlagn 0000:03:00.0: CSR_INT: 0X00000000
[ 4913.690101] iwlagn 0000:03:00.0: CSR_INT_MASK: 0X00000000
[ 4913.690110] iwlagn 0000:03:00.0: CSR_FH_INT_STATUS: 0X00000000
[ 4913.690118] iwlagn 0000:03:00.0: CSR_GPIO_IN: 0X00000000
[ 4913.690127] iwlagn 0000:03:00.0: CSR_RESET: 0X00000000
[ 4913.690135] iwlagn 0000:03:00.0: CSR_GP_CNTRL: 0X080403c5
[ 4913.690143] iwlagn 0000:03:00.0: CSR_HW_REV: 0X00000024
[ 4913.690152] iwlagn 0000:03:00.0: CSR_EEPROM_REG: 0X00000000
[ 4913.690160] iwlagn 0000:03:00.0: CSR_EEPROM_GP: 0X90000004
[ 4913.690169] iwlagn 0000:03:00.0: CSR_OTP_GP_REG: 0X00060000
[ 4913.690178] iwlagn 0000:03:00.0: CSR_GIO_REG: 0X00080046
[ 4913.690186] iwlagn 0000:03:00.0: CSR_GP_UCODE_REG: 0X00000885
[ 4913.690195] iwlagn 0000:03:00.0: CSR_GP_DRIVER_REG: 0X00000000
[ 4913.690203] iwlagn 0000:03:00.0: CSR_UCODE_DRV_GP1: 0X00000000
[ 4913.690211] iwlagn 0000:03:00.0: CSR_UCODE_DRV_GP2: 0X00000000
[ 4913.690220] iwlagn 0000:03:00.0: CSR_LED_REG: 0X00000058
[ 4913.690229] iwlagn 0000:03:00.0: CSR_DRAM_INT_TBL_REG: 0X88134338
[ 4913.690237] iwlagn 0000:03:00.0: CSR_GIO_CHICKEN_BITS: 0X27800200
[ 4913.690246] iwlagn 0000:03:00.0: CSR_ANA_PLL_CFG: 0X00880300
[ 4913.690255] iwlagn 0000:03:00.0: CSR_HW_REV_WA_REG: 0X0001001a
[ 4913.690263] iwlagn 0000:03:00.0: CSR_DBG_HPET_MEM_REG: 0Xffff0000
[ 4913.690269] iwlagn 0000:03:00.0: FH register values:
[ 4913.690287] iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X13623e00
[ 4913.690305] iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X01367fb0
[ 4913.690324] iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_WPTR: 0X00000050
[ 4913.690342] iwlagn 0000:03:00.0: FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
[ 4913.690361] iwlagn 0000:03:00.0: FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
[ 4913.690380] iwlagn 0000:03:00.0: FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
[ 4913.690398] iwlagn 0000:03:00.0: FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
[ 4913.690416] iwlagn 0000:03:00.0: FH_TSSR_TX_STATUS_REG: 0X07ff0001
[ 4913.690435] iwlagn 0000:03:00.0: FH_TSSR_TX_ERROR_REG: 0X00000000
[ 4913.690497] iwlagn 0000:03:00.0: Start IWL Event Log Dump: display last 20 entries
[ 4913.690522] iwlagn 0000:03:00.0: EVT_LOGT:1780995800:0x00000000:0212
[ 4913.690537] iwlagn 0000:03:00.0: EVT_LOGT:1780995854:0x00000000:0215
[ 4913.690553] iwlagn 0000:03:00.0: EVT_LOGT:1780995858:0x00000008:0220
[ 4913.690568] iwlagn 0000:03:00.0: EVT_LOGT:1780996115:0x0a1a001c:0206
[ 4913.690584] iwlagn 0000:03:00.0: EVT_LOGT:1780996117:0xc0000000:0228
[ 4913.690600] iwlagn 0000:03:00.0: EVT_LOGT:1780996118:0x00000001:0204
[ 4913.690615] iwlagn 0000:03:00.0: EVT_LOGT:1780996121:0x00000001:0214
[ 4913.690630] iwlagn 0000:03:00.0: EVT_LOGT:1780996122:0x01041110:0205
[ 4913.690646] iwlagn 0000:03:00.0: EVT_LOGT:1780996144:0x00000020:0208
[ 4913.690661] iwlagn 0000:03:00.0: EVT_LOGT:1780996163:0x00000000:0302
[ 4913.690677] iwlagn 0000:03:00.0: EVT_LOGT:1780996193:0x000000c4:0303
[ 4913.690693] iwlagn 0000:03:00.0: EVT_LOGT:1780996199:0x00000001:0203
[ 4913.690708] iwlagn 0000:03:00.0: EVT_LOGT:1780996203:0x0a1a001c:0206
[ 4913.690723] iwlagn 0000:03:00.0: EVT_LOGT:1780996204:0x00000040:0204
[ 4913.690739] iwlagn 0000:03:00.0: EVT_LOGT:1780996207:0x01040110:0211
[ 4913.690754] iwlagn 0000:03:00.0: EVT_LOGT:1780996212:0x00000000:0212
[ 4913.690769] iwlagn 0000:03:00.0: EVT_LOGT:1780996266:0x00000000:0215
[ 4913.690785] iwlagn 0000:03:00.0: EVT_LOGT:1780996270:0x00000008:0220
[ 4913.690800] iwlagn 0000:03:00.0: EVT_LOGT:1780996636:0x04e7004e:0401
[ 4913.690816] iwlagn 0000:03:00.0: EVT_LOGT:1780996648:0x00000000:0125
[ 4913.736574] iwlagn 0000:03:00.0: Stopping AGG while state not ON or starting
[ 4913.736584] iwlagn 0000:03:00.0: queue number out of range: 0, must be 10 to 19
[ 4964.632025] iwlagn 0000:03:00.0: Aggregation not enabled for tid 0 because load = 0
[ 4973.649242] iwlagn 0000:03:00.0: iwlagn_tx_agg_start on ra = 00:1f:3f:62:fd:83 tid = 0
[ 5037.471815] iwlagn 0000:03:00.0: low ack count detected, restart firmware
[ 5037.471824] iwlagn 0000:03:00.0: On demand firmware reload
[ 5037.507502] iwlagn 0000:03:00.0: Stopping AGG while state not ON or starting
[ 5037.507513] iwlagn 0000:03:00.0: queue number out of range: 0, must be 10 to 19
The card is a iwl5300 and the kernel is of version 2.6.37-rc7 running on amd64 arch.
It's the newest from debian experimental (2.6.37~rc7-1~experimental.1).
I have a full dmesg.log here which I can send you in private, just ask.
Sincerely,
Florian.
^ permalink raw reply
* Re: [PATCH v3 14/18] wl1271: AP mode - record TX configuration settings
From: Luciano Coelho @ 2010-12-29 9:21 UTC (permalink / raw)
To: ext Arik Nemtsov; +Cc: linux-wireless
In-Reply-To: <1293557808-27068-15-git-send-email-arik@wizery.com>
On Tue, 2010-12-28 at 19:36 +0200, ext Arik Nemtsov wrote:
>
> diff --git a/drivers/net/wireless/wl12xx/main.c
> b/drivers/net/wireless/wl12xx/main.c
> index 3747d98..ea61ae7 100644
> --- a/drivers/net/wireless/wl12xx/main.c
> +++ b/drivers/net/wireless/wl12xx/main.c
> @@ -1433,6 +1433,8 @@ static int wl1271_op_config(struct ieee80211_hw
> *hw, u32 changed)
> goto out;
> }
>
> + is_ap = (wl->bss_type == BSS_TYPE_AP_BSS);
> +
> ret = wl1271_ps_elp_wakeup(wl, false);
> if (ret < 0)
> goto out;
Did you forget to fix this one? As we discussed, this should be in
10/18.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 4/4] mwl8k: Enable HW encryption for AP mode
From: Johannes Berg @ 2010-12-29 9:18 UTC (permalink / raw)
To: Thomas Pedersen
Cc: linux-wireless, mwl8k-devel, buytenh, Nishant Sarmukadam,
Pradeep Nemavat
In-Reply-To: <1293614230.3546.4.camel@jlt3.sipsolutions.net>
On Wed, 2010-12-29 at 10:17 +0100, Johannes Berg wrote:
> On Tue, 2010-12-28 at 15:01 -0800, Thomas Pedersen wrote:
>
> > @@ -824,15 +827,22 @@ static void mwl8k_encapsulate_tx_frame(struct sk_buff *skb)
> > header_pad = 0;
> > data_pad = 0;
> > if (key_conf != NULL) {
> > - if (key_conf->alg == ALG_WEP) {
> > + switch (key_conf->cipher) {
>
> how can this patch possibly apply? key_conf->alg hasn't existed in a
> LONG time, so I don't see how you can be removing a line containing it?!
Oh, never mind, patch 2/4 is adding this code, so it can never
compile...........
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox