- 02 Aug, 2010 40 commits
-
-
Nicolas Pitre authored
commit 0ebe25f9 upstream. From: Bin Yang <bin.yang@marvell.com> Signed-off-by:
Bin Yang <bin.yang@marvell.com> Signed-off-by:
Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Catalin Marinas authored
commit 2503a5ec upstream. RealView boards with certain revisions of the L220 cache controller (ARM11* processors only) may have issues (hardware deadlock) with the recent changes to the mb() barrier implementation (DSB followed by an L2 cache sync). The patch redefines the RealView ARM11MPCore mandatory barriers without the outer_sync() call. Tested-by:
Linus Walleij <linus.walleij@stericsson.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Dmitry Torokhov authored
commit 3fea6026 upstream. The Nokia RX51 board code (arch/arm/mach-omap2/board-rx51-peripherals.c) defines a key map for the matrix keypad keyboard. The hardware seems to use all of the 8 rows and 8 columns of the keypad, although not all possible locations are used. The TWL4030 supports keypads with at most 8 rows and 8 columns. Most keys are defined with a row and column number between 0 and 7, except KEY(0xff, 2, KEY_F9), KEY(0xff, 4, KEY_F10), KEY(0xff, 5, KEY_F11), which represent keycodes that should be emitted when entire row is connected to the ground. since the driver handles this case as if we had an extra column in the key matrix. Unfortunately we do not allocate enough space and end up owerwriting some random memory. Reported-and-tested-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Kamal Mostafa authored
commit 3e1bbc8d upstream. Gigabyte "Spring Peak" notebook indicates wrong chassis-type, tripping up i8042 and breaking the touchpad. Add this model to i8042_dmi_noloop_table[] to resolve. BugLink: https://bugs.launchpad.net/bugs/580664Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
Or Gerlitz authored
commit 7a52b34b upstream. Sumeet Lahorani <sumeet.lahorani@oracle.com> reported that the IPoIB child entries are world-writable; however we don't want ordinary users to be able to create and destroy child interfaces, so fix them to be writable only by root. Signed-off-by:
Or Gerlitz <ogerlitz@voltaire.com> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Yinghai Lu authored
commit fd19dce7 upstream. Found one x2apic system kexec loop test failed when CONFIG_NMI_WATCHDOG=y (old) or CONFIG_LOCKUP_DETECTOR=y (current tip) first kernel can kexec second kernel, but second kernel can not kexec third one. it can be duplicated on another system with BIOS preenabled x2apic. First kernel can not kexec second kernel. It turns out, when kernel boot with pre-enabled x2apic, it will not execute disable_local_APIC on shutdown path. when init_apic_mappings() is called in setup_arch, it will skip setting of apic_phys when x2apic_mode is set. ( x2apic_mode is much early check_x2apic()) Then later, disable_local_APIC() will bail out early because !apic_phys. So check !x2apic_mode in x2apic_mode in disable_local_APIC with !apic_phys. another solution could be updating init_apic_mappings() to set apic_phys even for preenabled x2apic system. Actually even for x2apic system, that lapic address is mapped already in early stage. BTW: is there any x2apic preenabled system with apicid of boot cpu > 255? Signed-off-by:
Yinghai Lu <yinghai@kernel.org> LKML-Reference: <4C3EB22B.3000701@kernel.org> Acked-by:
Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Mark Brown authored
commit 3c070939 upstream. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
-
Marek Szyprowski authored
commit 9d51a6b2 upstream. System will crash sooner or later once the memory with the code of the s3c-sdhci.ko module is reused for something else. I really have no idea how the lack of remove function went unnoticed into the mainline code. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Ben Hutchings authored
commit db048b69 upstream. On a 32-bit machine, info.rule_cnt >= 0x40000000 leads to integer overflow and the buffer may be smaller than needed. Since ETHTOOL_GRXCLSRLALL is unprivileged, this can presumably be used for at least denial of service. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Joakim Tjernlund authored
commit 96fc3a45 upstream. The ds1307 driver misreads the ds1388 registers when checking for 12 or 24 hour mode. Instead of checking the hour register it reads the minute register. Therefore the driver thinks minutes >= 40 has the 12HR bit set and resets the minute register by zeroing the high bits. This results in minutes are reset to 0-9, jumping back in time 40 or 50 minutes. The time jump is also written back to the RTC. Signed-off-by:
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Cc: Wan ZongShun <mcuos.com@gmail.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Paul Gortmaker <p_gortmaker@yahoo.com> Signed-off-by:
-
Ilpo Järvinen authored
commit 45e77d31 upstream. It can happen that there are no packets in queue while calling tcp_xmit_retransmit_queue(). tcp_write_queue_head() then returns NULL and that gets deref'ed to get sacked into a local var. There is no work to do if no packets are outstanding so we just exit early. This oops was introduced by 08ebd172 (tcp: remove tp->lost_out guard to make joining diff nicer). Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Reported-by:
Lennart Schulte <lennart.schulte@nets.rwth-aachen.de> Tested-by:
-
Doug Kehn authored
commit 91a72a70 upstream. When configuring DMVPN (GRE + openNHRP) and a GRE remote address is configured a kernel Oops is observed. The obserseved Oops is caused by a NULL header_ops pointer (neigh->dev->header_ops) in neigh_update_hhs() when void (*update)(struct hh_cache*, const struct net_device*, const unsigned char *) = neigh->dev->header_ops->cache_update; is executed. The dev associated with the NULL header_ops is the GRE interface. This patch guards against the possibility that header_ops is NULL. This Oops was first observed in kernel version 2.6.26.8. Signed-off-by:
Doug Kehn <rdkehn@yahoo.com> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Mikulas Patocka authored
commit 720fc22a upstream. When ide taskfile access is being used (for example with hdparm --security commands) and cfq scheduler is selected, the scheduler crashes on BUG in cfq_put_request. The reason is that the cfq scheduler is tracking counts of read and write requests separately; the ide-taskfile subsystem allocates a read request and then flips the flag to make it a write request. The counters in cfq will mismatch. This patch changes ide-taskfile to allocate the READ or WRITE request as required and don't change the flag later. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
Sergei Shtylyov authored
commit a9ddabc5 upstream. When implementing the test_iqr() method, I forgot that this driver is not an ordinary PCI driver and also needs to support VLB variant of the chip. Moreover, 'hwif->dev' should be NULL, potentially causing oops in pci_read_config_byte(). Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
-
Dongdong Deng authored
commit 8cd774ad upstream. The cpm_uart_early_write() function which was used for console poll isn't implemented in the cpm uart driver. Implementing this function both fixes the build when CONFIG_CONSOLE_POLL is set and allows kgdboc to work via the cpm uart. Signed-off-by:
Dongdong Deng <dongdong.deng@windriver.com> Reviewed-by:
Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by:
-
Thomas Gleixner authored
commit 46732475 upstream. The set_type() function can change the chip implementation when the trigger mode changes. That might result in using an non-initialized irq chip when called from __setup_irq() or when called via set_irq_type() on an already enabled irq. The set_irq_type() function should not be called on an enabled irq, but because we forgot to put a check into it, we have a bunch of users which grew the habit of doing that and it never blew up as the function is serialized via desc->lock against all users of desc->chip and they never hit the non-initialized irq chip issue. The easy fix for the __setup_irq() issue would be to move the irq_chip_set_defaults(desc->chip) call after the trigger setting to make sure that a chip change is covered. But as we have already users, which do the type setting after request_irq(), the safe fix for now is to call irq_chip_set_defaults() from __irq_set_trigger() when desc->set_type() changed the irq chip. It needs a deeper analysis whether we should refuse to change the chip on an already enabled irq, but that'd be a large scale change to fix all the existing users. So that's neither stable nor 2.6.35 material. Reported-by:
Esben Haabendal <eha@doredevelopment.dk> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: linuxppc-dev <linuxppc-dev@ozlabs.org> Signed-off-by:
-
Alex,Shi authored
commit 3c93717c upstream. Commit e7097159 ("sched: Optimize unused cgroup configuration") introduced an imbalanced scheduling bug. If we do not use CGROUP, function update_h_load won't update h_load. When the system has a large number of tasks far more than logical CPU number, the incorrect cfs_rq[cpu]->h_load value will cause load_balance() to pull too many tasks to the local CPU from the busiest CPU. So the busiest CPU keeps going in a round robin. That will hurt performance. The issue was found originally by a scientific calculation workload that developed by Yanmin. With that commit, the workload performance drops about 40%. CPU before after 00 : 2 : 7 01 : 1 : 7 02 : 11 : 6 03 : 12 : 7 04 : 6 : 6 05 : 11 : 7 06 : 10 : 6 07 : 12 : 7 08 : 11 : 6 09 : 12 : 6 10 : 1 : 6 11 : 1 : 6 12 : 6 : 6 13 : 2 : 6 14 : 2 : 6 15 : 1 : 6 Reviewed-by:
Yanmin zhang <yanmin.zhang@intel.com> Signed-off-by:
Alex Shi <alex.shi@intel.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <1276754893.9452.5442.camel@debian> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Will Deacon authored
commit 0d98bb26 upstream. GCC 4.4.1 on ARM has been observed to replace the while loop in sched_avg_update with a call to uldivmod, resulting in the following build failure at link-time: kernel/built-in.o: In function `sched_avg_update': kernel/sched.c:1261: undefined reference to `__aeabi_uldivmod' kernel/sched.c:1261: undefined reference to `__aeabi_uldivmod' make: *** [.tmp_vmlinux1] Error 1 This patch introduces a fake data hazard to the loop body to prevent the compiler optimising the loop away. Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Darrick J. Wong authored
commit d596043d upstream. The x3950 family can have as many as 256 PCI buses in a single system, so change the limits to the maximum. Since there can only be 256 PCI buses in one domain, we no longer need the BUG_ON check. Signed-off-by:
Darrick J. Wong <djwong@us.ibm.com> LKML-Reference: <20100701004519.GQ15515@tux1.beaverton.ibm.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Darrick J. Wong authored
commit 499a00e9 upstream. Newer systems (x3950M2) can have 48 PHBs per chassis and 8 chassis, so bump the limits up and provide an explanation of the requirements for each class. Signed-off-by:
Muli Ben-Yehuda <muli@il.ibm.com> Cc: Corinna Schultz <cschultz@linux.vnet.ibm.com> LKML-Reference: <20100624212647.GI15515@tux1.beaverton.ibm.com> [ v2: Fixed build bug, added back PHBS_PER_CALGARY == 4 ] Signed-off-by:
-
Andi Kleen authored
commit 12448293 upstream. This fixes the -Os breaks with gcc 4.5 bug. rdtsc_barrier needs to be force inlined, otherwise user space will jump into kernel space and kill init. This also addresses http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44129 I believe. Signed-off-by:
Andi Kleen <ak@linux.intel.com> LKML-Reference: <20100618210859.GA10913@basil.fritz.box> Signed-off-by:
-
Frederic Weisbecker authored
commit 97aa1052 upstream. Initialize the callchain radix tree root correctly. When we walk through the parents, we must stop after the root, but since it wasn't well initialized, its parent pointer was random. Also the number of hits was random because uninitialized, hence it was part of the callchain while the root doesn't contain anything. This fixes segfaults and percentages followed by empty callchains while running: perf report -g flat Reported-by:
Frederic Weisbecker <fweisbec@gmail.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Ben Hutchings authored
commit 6fd02489 upstream. The current initialisation code probes 'unsupported' AGP devices simply by calling its own probe function. It does not lock these devices or even check whether another driver is already bound to them. We must use the device core to manage this. So if the specific device id table didn't match anything and agp_try_unsupported=1, switch the device id table and call driver_attach() again. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Julia Lawall authored
commit 8a52da63 upstream. The debugging code using the freed structure is moved before the kfree. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @free@ expression E; position p; @@ kfree@p(E) @@ expression free.E, subE<=free.E, E1; position free.p; @@ kfree@p(E) ... ( subE = E1 | * E ) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-
Eric Dumazet authored
commit 499031ac upstream. We should release dst if dst->error is set. Bug introduced in 2.6.14 by commit e104411b ([XFRM]: Always release dst_entry on error in xfrm_lookup) Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Sven Wegener authored
commit aea9d711 upstream. The code that hashes and unhashes connections from the connection table is missing locking of the connection being modified, which opens up a race condition and results in memory corruption when this race condition is hit. Here is what happens in pretty verbose form: CPU 0 CPU 1 ------------ ------------ An active connection is terminated and we schedule ip_vs_conn_expire() on this CPU to expire this connection. IRQ assignment is changed to this CPU, but the expire timer stays scheduled on the other CPU. New connection from same ip:port comes in right before the timer expires, we find the inactive connection in our connection table and get a reference to it. We proper lock the connection in tcp_state_transition() and read the connection flags in set_tcp_state(). ip_vs_conn_expire() gets called, we unhash the connection from our connection table and remove the hashed flag in ip_vs_conn_unhash(), without proper locking! While still holding proper locks we write the connection flags in set_tcp_state() and this sets the hashed flag again. ip_vs_conn_expire() fails to expire the connection, because the other CPU has incremented the reference count. We try to re-insert the connection into our connection table, but this fails in ip_vs_conn_hash(), because the hashed flag has been set by the other CPU. We re-schedule execution of ip_vs_conn_expire(). Now this connection has the hashed flag set, but isn't actually hashed in our connection table and has a dangling list_head. We drop the reference we held on the connection and schedule the expire timer for timeouting the connection on this CPU. Further packets won't be able to find this connection in our connection table. ip_vs_conn_expire() gets called again, we think it's already hashed, but the list_head is dangling and while removing the connection from our connection table we write to the memory location where this list_head points to. The result will probably be a kernel oops at some other point in time. This race condition is pretty subtle, but it can be triggered remotely. It needs the IRQ assignment change or another circumstance where packets coming from the same ip:port for the same service are being processed on different CPUs. And it involves hitting the exact time at which ip_vs_conn_expire() gets called. It can be avoided by making sure that all packets from one connection are always processed on the same CPU and can be made harder to exploit by changing the connection timeouts to some custom values. Signed-off-by:
Sven Wegener <sven.wegener@stealer.net> Acked-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Rajiv Andrade authored
commit 59f6fbe4 upstream. Fix subsequent suspends by issuing tpm_continue_selftest during resume. Otherwise, the tpm chip seems to be not fully initialized and will reject the save state command during suspend, thus preventing the whole system to suspend. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16256Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
Rajiv Andrade <srajiv@linux.vnet.ibm.com> Cc: James Morris <jmorris@namei.org> Cc: Debora Velarde <debora@linux.vnet.ibm.com> Cc: David Safford <safford@watson.ibm.com> Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Alex Deucher authored
commit 15cb02c0 upstream. Add delay after turning off the LVDS encoder. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=16389Tested-by:
Jan Kreuzer <kontrollator@gmx.de> Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
-
Alex Deucher authored
commit e153b70b upstream. Connector is actually DVI rather than HDMI. Reported-by:
trapDoor <trapdoor6@gmail.com> Signed-off-by:
-
Roland Scheidegger authored
commit 688acaa2 upstream. Code did not handle projected 2d and depth coordinates, meaning potentially set 3d or cube special handling might stick. (Not sure what depth coord actually does, but I guess handling it like a normal coordinate is the right thing to do.) Might be related to https://bugs.freedesktop.org/show_bug.cgi?id=26428 Signed-off-by: sroland@vmware.com Signed-off-by:
-
Adam Jackson authored
commit 6ba770dc upstream. Fixes an Ironlake laptop with a 68.940MHz 1280x800 panel and 120MHz SSC reference clock. More generally, the 0.488% tolerance used before is just too tight to reliably find a PLL setting. I extracted the search algorithm and modified it to find the dot clocks with maximum error over the valid range for the given output type: http://people.freedesktop.org/~ajax/intel_g4x_find_best_pll.c This gave: Worst dotclock for Ironlake DAC refclk is 350000kHz (error 0.00571) Worst dotclock for Ironlake SL-LVDS refclk is 102321kHz (error 0.00524) Worst dotclock for Ironlake DL-LVDS refclk is 219642kHz (error 0.00488) Worst dotclock for Ironlake SL-LVDS SSC refclk is 84374kHz (error 0.00529) Worst dotclock for Ironlake DL-LVDS SSC refclk is 183035kHz (error 0.00488) Worst dotclock for G4X SDVO refclk is 267600kHz (error 0.00448) Worst dotclock for G4X HDMI refclk is 334400kHz (error 0.00478) Worst dotclock for G4X SL-LVDS refclk is 95571kHz (error 0.00449) Worst dotclock for G4X DL-LVDS refclk is 224000kHz (error 0.00510) Signed-off-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Dave Airlie authored
commit 94400120 upstream. A lot of 945GMs have had stability issues for a long time, this manifested as X hangs, blitter engine hangs, and lots of crashes. one such report is at: https://bugs.freedesktop.org/show_bug.cgi?id=20560 along with numerous distro bugzillas. This only took a week of digging and hair ripping to figure out. Tracked down and tested on a 945GM Lenovo T60, previously running x11perf -copypixwin500 or x11perf -copywinpix500 repeatedly would cause the GPU to wedge within 4 or 5 tries, with random busy bits set. After this patch no hangs were observed. Signed-off-by:
-
Keith Packard authored
commit 45503ded upstream. The i915 memory arbiter has a register full of configuration bits which are currently not defined in the driver header file. Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
Daniel J Blueman authored
commit f953c935 upstream. While investigating Intel i5 Arrandale GPU lockups with -rc4, I noticed a lock imbalance. Signed-off-by:
Daniel J Blueman <daniel.blueman@gmail.com> Signed-off-by:
-
Jason Baron authored
commit b82bab4b upstream. The command echo "file ec.c +p" >/sys/kernel/debug/dynamic_debug/control causes an oops. Move the call to ddebug_remove_module() down into free_module(). In this way it should be called from all error paths. Currently, we are missing the remove if the module init routine fails. Signed-off-by:
Jason Baron <jbaron@redhat.com> Reported-by:
Thomas Renninger <trenn@suse.de> Tested-by:
-
Joerg Albert authored
commit 50900f16 upstream. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Dan Rosenberg authored
commit 2ebc3464 upstream. 1. The BTRFS_IOC_CLONE and BTRFS_IOC_CLONE_RANGE ioctls should check whether the donor file is append-only before writing to it. 2. The BTRFS_IOC_CLONE_RANGE ioctl appears to have an integer overflow that allows a user to specify an out-of-bounds range to copy from the source file (if off + len wraps around). I haven't been able to successfully exploit this, but I'd imagine that a clever attacker could use this to read things he shouldn't. Even if it's not exploitable, it couldn't hurt to be safe. Signed-off-by:
Dan Rosenberg <dan.j.rosenberg@gmail.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com> Signed-off-by:
-
Javier Cardona authored
commit 1cb561f8 upstream. This fixes the problem introduced in commit 84040805 which broke mesh peer link establishment. changes: v2 Added missing break (Johannes) v3 Broke original patch into two (Johannes) Signed-off-by:
Javier Cardona <javier@cozybit.com> Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Stanislaw Gruszka authored
commit f0b058b6 upstream. Use old supported rates, if AP do not provide supported rates information element in a new managment frame. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
John W. Linville authored
commit a69b03e9 upstream. Avoids this: WARNING: at net/mac80211/scan.c:312 ieee80211_scan_completed+0x5f/0x1f1 [mac80211]() Hardware name: Latitude E5400 Modules linked in: aes_x86_64 aes_generic fuse ipt_MASQUERADE iptable_nat nf_nat rfcomm sco bridge stp llc bnep l2cap sunrpc cpufreq_ondemand acpi_cpufreq freq_table xt_physdev ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput arc4 ecb snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel iwlagn snd_hda_codec snd_hwdep snd_seq snd_seq_device iwlcore snd_pcm dell_wmi sdhci_pci sdhci iTCO_wdt tg3 dell_laptop mmc_core i2c_i801 wmi mac80211 snd_timer iTCO_vendor_support btusb joydev dcdbas cfg80211 bluetooth snd soundcore microcode rfkill snd_page_alloc firewire_ohci firewire_core crc_itu_t yenta_socket rsrc_nonstatic i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] Pid: 979, comm: iwlagn Tainted: G W 2.6.33.3-85.fc13.x86_64 #1 Call Trace: [<ffffffff8104b558>] warn_slowpath_common+0x77/0x8f [<ffffffff8104b57f>] warn_slowpath_null+0xf/0x11 [<ffffffffa01bb7d9>] ieee80211_scan_completed+0x5f/0x1f1 [mac80211] [<ffffffffa02a23f0>] iwl_bg_scan_completed+0xbb/0x17a [iwlcore] [<ffffffff81060d3d>] worker_thread+0x1a4/0x232 [<ffffffffa02a2335>] ? iwl_bg_scan_completed+0x0/0x17a [iwlcore] [<ffffffff81064817>] ? autoremove_wake_function+0x0/0x34 [<ffffffff81060b99>] ? worker_thread+0x0/0x232 [<ffffffff810643c7>] kthread+0x7a/0x82 [<ffffffff8100a924>] kernel_thread_helper+0x4/0x10 [<ffffffff8106434d>] ? kthread+0x0/0x82 [<ffffffff8100a920>] ? kernel_thread_helper+0x0/0x10 Reported here: https://bugzilla.redhat.com/show_bug.cgi?id=590436Signed-off-by:
Mihai Harpau <mishu@piatafinanciara.ro> Acked-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
