- 17 Feb, 2011 10 commits
-
-
Richard Schütz authored
USB: usb-storage: unusual_devs update for TrekStor DataStation maxi g.u external hard drive enclosure commit 7e1e7bd9 upstream. The TrekStor DataStation maxi g.u external hard drive enclosure uses a JMicron USB to SATA chip which needs the US_FL_IGNORE_RESIDUE flag to work properly. Signed-off-by:
Richard Schütz <r.schtz@t-online.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Richard Schütz authored
commit cae41118 upstream. New device ID added for unusual Cypress ATACB device. Signed-off-by:
-
Craig Shelley authored
commit 9926c0df upstream. Device ID removed 0x10C4/0x8149 for West Mountain Radio Computerized Battery Analyzer. This device is actually based on a SiLabs C8051Fxxx, see http://www.etheus.net/SiUSBXp_Linux_Driver for further info. Signed-off-by:
Craig Shelley <craig@microtron.org.uk> Signed-off-by:
-
Craig Shelley authored
commit faea63f7 upstream. Device Ids added for IRZ Automation Teleport SG-10 GSM/GPRS Modem and DekTec DTA Plus VHF/UHF Booster/Attenuator. Signed-off-by:
-
Libor Pechacek authored
commit d14fc1a7 upstream. Alan's commit 335f8514 introduced .carrier_raised function in several drivers. That also means tty_port_block_til_ready can now suspend the process trying to open the serial port when Carrier Detect is low and put it into tty_port.open_wait queue. We need to wake up the process when Carrier Detect goes high and trigger TTY hangup when CD goes low. Some of the devices do not report modem status line changes, or at least we don't understand the status message, so for those we remove .carrier_raised again. Signed-off-by:
Libor Pechacek <lpechacek@suse.cz> Signed-off-by:
-
Jean Delvare authored
commit f790674d upstream. Functions set_fan_min() and set_fan_div() assume that the fan_div values have already been read from the register. The driver currently doesn't initialize them at load time, they are only set when function via686a_update_device() is called. This means that set_fan_min() and set_fan_div() misbehave if, for example, "sensors -s" is called before any monitoring application (e.g. "sensors") is has been run. Fix the problem by always initializing the fan_div values at device bind time. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by:
-
Karsten Wiese authored
commit cdce2db7 upstream. Fix missing NULL checks in usb_stream_hwdep_poll() and usb_stream_hwdep_ioctl(). Wake up poll waiters before returning from usb_stream_hwdep_ioctl(). Signed-off-by:
Karsten Wiese <fzu@wemgehoertderstaat.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 9c4cf6d9 upstream. This patch adds the device id for the windy31 USB device to the rt73usb driver. Thanks to Ralf Flaxa for reporting this and providing testing and a sample device. Reported-by:
Ralf Flaxa <rf@suse.de> Tested-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Alex He authored
commit 05570297 upstream. When ASPM PM Feature is enabled on UMI link, devices that use ISOC stream of data transfer may be exposed to longer latency causing less than optimal per- formance of the device. The longer latencies are normal and are due to link wake time coming out of low power state which happens frequently to save power when the link is not active. The following code will make exception for certain features of ASPM to be by passed and keep the logic normal state only when the ISOC device is connected and active. This change will allow the device to run at optimal performance yet minimize the impact on overall power savings. Signed-off-by:
Alex He <alex.he@amd.com> Acked-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Márton Németh authored
commit 7571f089 upstream. In the vhci_urb_dequeue() function the TCP connection is checked twice. Each time when the TCP connection is closed the URB is unlinked and given back. Remove the second attempt of unlinking and giving back of the URB completely. This patch fixes the bug described at https://bugzilla.kernel.org/show_bug.cgi?id=24872 . Signed-off-by:
Márton Németh <nm127@freemail.hu> Signed-off-by:
-
- 07 Jan, 2011 30 commits
-
-
Greg Kroah-Hartman authored
-
Oleg Nesterov authored
commit e0a70217 upstream. posix-cpu-timers.c correctly assumes that the dying process does posix_cpu_timers_exit_group() and removes all !CPUCLOCK_PERTHREAD timers from signal->cpu_timers list. But, it also assumes that timer->it.cpu.task is always the group leader, and thus the dead ->task means the dead thread group. This is obviously not true after de_thread() changes the leader. After that almost every posix_cpu_timer_ method has problems. It is not simple to fix this bug correctly. First of all, I think that timer->it.cpu should use struct pid instead of task_struct. Also, the locking should be reworked completely. In particular, tasklist_lock should not be used at all. This all needs a lot of nontrivial and hard-to-test changes. Change __exit_signal() to do posix_cpu_timers_exit_group() when the old leader dies during exec. This is not the fix, just the temporary hack to hide the problem for 2.6.37 and stable. IOW, this is obviously wrong but this is what we currently have anyway: cpu timers do not work after mt exec. In theory this change adds another race. The exiting leader can detach the timers which were attached to the new leader. However, the window between de_thread() and release_task() is small, we can pretend that sys_timer_create() was called before de_thread(). Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Vlad Yasevich authored
commit 50b5d6ad upstream. ICMP protocol unreachable handling completely disregarded the fact that the user may have locked the socket. It proceeded to destroy the association, even though the user may have held the lock and had a ref on the association. This resulted in the following: Attempt to release alive inet socket f6afcc00 ========================= [ BUG: held lock freed! ] ------------------------- somenu/2672 is freeing memory f6afcc00-f6afcfff, with a lock still held there! (sk_lock-AF_INET){+.+.+.}, at: [<c122098a>] sctp_connect+0x13/0x4c 1 lock held by somenu/2672: #0: (sk_lock-AF_INET){+.+.+.}, at: [<c122098a>] sctp_connect+0x13/0x4c stack backtrace: Pid: 2672, comm: somenu Not tainted 2.6.32-telco #55 Call Trace: [<c1232266>] ? printk+0xf/0x11 [<c1038553>] debug_check_no_locks_freed+0xce/0xff [<c10620b4>] kmem_cache_free+0x21/0x66 [<c1185f25>] __sk_free+0x9d/0xab [<c1185f9c>] sk_free+0x1c/0x1e [<c1216e38>] sctp_association_put+0x32/0x89 [<c1220865>] __sctp_connect+0x36d/0x3f4 [<c122098a>] ? sctp_connect+0x13/0x4c [<c102d073>] ? autoremove_wake_function+0x0/0x33 [<c12209a8>] sctp_connect+0x31/0x4c [<c11d1e80>] inet_dgram_connect+0x4b/0x55 [<c11834fa>] sys_connect+0x54/0x71 [<c103a3a2>] ? lock_release_non_nested+0x88/0x239 [<c1054026>] ? might_fault+0x42/0x7c [<c1054026>] ? might_fault+0x42/0x7c [<c11847ab>] sys_socketcall+0x6d/0x178 [<c10da994>] ? trace_hardirqs_on_thunk+0xc/0x10 [<c1002959>] syscall_call+0x7/0xb This was because the sctp_wait_for_connect() would aqcure the socket lock and then proceed to release the last reference count on the association, thus cause the fully destruction path to finish freeing the socket. The simplest solution is to start a very short timer in case the socket is owned by user. When the timer expires, we can do some verification and be able to do the release properly. Signed-off-by:
Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Martin K. Petersen authored
commit e692cb66 upstream. When stacking devices, a request_queue is not always available. This forced us to have a no_cluster flag in the queue_limits that could be used as a carrier until the request_queue had been set up for a metadevice. There were several problems with that approach. First of all it was up to the stacking device to remember to set queue flag after stacking had completed. Also, the queue flag and the queue limits had to be kept in sync at all times. We got that wrong, which could lead to us issuing commands that went beyond the max scatterlist limit set by the driver. The proper fix is to avoid having two flags for tracking the same thing. We deprecate QUEUE_FLAG_CLUSTER and use the queue limit directly in the block layer merging functions. The queue_limit 'no_cluster' is turned into 'cluster' to avoid double negatives and to ease stacking. Clustering defaults to being enabled as before. The queue flag logic is removed from the stacking function, and explicitly setting the cluster flag is no longer necessary in DM and MD. Reported-by:
Ed Lin <ed.lin@promise.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Acked-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
-
Daniel T Chen authored
commit e03fa055 upstream. Sjoerd Simons reports that, without using position_fix=1, recording experiences overruns. Work around that by applying the LPIB quirk for his hardware. Reported-and-tested-by:
Sjoerd Simons <sjoerd@debian.org> Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
-
Daniel T Chen authored
commit 9919c761 upstream. BugLink: https://launchpad.net/bugs/530346 The OR has verified that position_fix=1 is necessary to work around errors on his machine. Reported-by: Tom Louwrier Signed-off-by:
-
Mimi Zohar authored
commit 867c2026 upstream. If security_filter_rule_init() doesn't return a rule, then not everything is as fine as the return code implies. This bug only occurs when the LSM (eg. SELinux) is disabled at runtime. Adding an empty LSM rule causes ima_match_rules() to always succeed, ignoring any remaining rules. default IMA TCB policy: # PROC_SUPER_MAGIC dont_measure fsmagic=0x9fa0 # SYSFS_MAGIC dont_measure fsmagic=0x62656572 # DEBUGFS_MAGIC dont_measure fsmagic=0x64626720 # TMPFS_MAGIC dont_measure fsmagic=0x01021994 # SECURITYFS_MAGIC dont_measure fsmagic=0x73636673 < LSM specific rule > dont_measure obj_type=var_log_t measure func=BPRM_CHECK measure func=FILE_MMAP mask=MAY_EXEC measure func=FILE_CHECK mask=MAY_READ uid=0 Thus without the patch, with the boot parameters 'tcb selinux=0', adding the above 'dont_measure obj_type=var_log_t' rule to the default IMA TCB measurement policy, would result in nothing being measured. The patch prevents the default TCB policy from being replaced. Signed-off-by:
Mimi Zohar <zohar@us.ibm.com> Cc: James Morris <jmorris@namei.org> Acked-by:
Serge Hallyn <serge.hallyn@canonical.com> Cc: David Safford <safford@watson.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Saeed Bishara authored
commit 8333f65e upstream. use mv_xor_slot_cleanup() instead of __mv_xor_slot_cleanup() as the former function aquires the spin lock that needed to protect the drivers data. Signed-off-by:
Saeed Bishara <saeed@marvell.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Dan Rosenberg authored
commit d81a12bc upstream. The load_mixer_volumes() function, which can be triggered by unprivileged users via the SOUND_MIXER_SETLEVELS ioctl, is vulnerable to a buffer overflow. Because the provided "name" argument isn't guaranteed to be NULL terminated at the expected 32 bytes, it's possible to overflow past the end of the last element in the mixer_vols array. Further exploitation can result in an arbitrary kernel write (via subsequent calls to load_mixer_volumes()) leading to privilege escalation, or arbitrary kernel reads via get_mixer_levels(). In addition, the strcmp() may leak bytes beyond the mixer_vols array. Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by:
-
Eduardo Costa authored
commit 56e6417b upstream. This USB ID is for the WUBI-100GW 802.11g Wireless LAN USB Device that uses p54usb. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Eduardo Costa <ecosta.tmp@gmail.com> Signed-off-by:
-
Christian Lamparter authored
commit 16cad7fb upstream. This patch adds five more USBIDs to the table. Source: http://www.linuxant.com/pipermail/driverloader/2005q3/002307.html http://wireless.kernel.org/en/users/Drivers/p54/devices (by M. Davis) Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Vitaly Kuznetsov authored
commit d73a9b30 upstream. Add an unusual_devs entry for the Samsung YP-CP3 MP4 player. User was getting the following errors in dmesg: usb 2-6: reset high speed USB device using ehci_hcd and address 2 usb 2-6: reset high speed USB device using ehci_hcd and address 2 usb 2-6: reset high speed USB device using ehci_hcd and address 2 usb 2-6: USB disconnect, address 2 sd 3:0:0:0: [sdb] Assuming drive cache: write through sdb:<2>ldm_validate_partition_table(): Disk read failed. Dev sdb: unable to read RDB block 0 unable to read partition table Signed-off-by:
Vitaly Kuznetsov <vitty@altlinux.ru> Acked-by:
Alan Stern <stern@rowland.harvard.edu> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by:
-
Florian Faber authored
commit 5363cdc3 upstream. Add FTDI PID to identify D.O.Tec devices correctly. Signed-off-by:
Florian Faber <faberman@linuxproaudio.org> Signed-off-by:
-
Thomas Sailer authored
commit ecc1624a upstream. Fabio Battaglia report that he has another cable that works with this driver, so this patch adds its vendor/product ID. Signed-off-by:
Thomas Sailer <t.sailer@alumni.ethz.ch> Signed-off-by:
-
Tavis Ormandy authored
commit 462e635e upstream. The install_special_mapping routine (used, for example, to setup the vdso) skips the security check before insert_vm_struct, allowing a local attacker to bypass the mmap_min_addr security restriction by limiting the available pages for special mappings. bprm_mm_init() also skips the check, and although I don't think this can be used to bypass any restrictions, I don't see any reason not to have the security check. $ uname -m x86_64 $ cat /proc/sys/vm/mmap_min_addr 65536 $ cat install_special_mapping.s section .bss resb BSS_SIZE section .text global _start _start: mov eax, __NR_pause int 0x80 $ nasm -D__NR_pause=29 -DBSS_SIZE=0xfffed000 -f elf -o install_special_mapping.o install_special_mapping.s $ ld -m elf_i386 -Ttext=0x10000 -Tbss=0x11000 -o install_special_mapping install_special_mapping.o $ ./install_special_mapping & [1] 14303 $ cat /proc/14303/maps 0000f000-00010000 r-xp 00000000 00:00 0 [vdso] 00010000-00011000 r-xp 00001000 00:19 2453665 /home/taviso/install_special_mapping 00011000-ffffe000 rwxp 00000000 00:00 0 [stack] It's worth noting that Red Hat are shipping with mmap_min_addr set to 4096. Signed-off-by:
Tavis Ormandy <taviso@google.com> Acked-by:
Kees Cook <kees@ubuntu.com> Acked-by:
Robert Swiecki <swiecki@google.com> [ Changed to not drop the error code - akpm ] Reviewed-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Krishna Kumar authored
commit 068a2de5 upstream. Non-GSO code drops dst entry for performance reasons, but the same is missing for GSO code. Drop dst while cache-hot for GSO case too. Signed-off-by:
Krishna Kumar <krkumar2@in.ibm.com> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
-
Alexander Duyck authored
commit 31b24b95 upstream. This change makes it so that vlan_gro_receive is only used if vlans have been registered to the adapter structure. Previously we were just sending all vlan tagged frames in via this function but this results in a null pointer dereference when vlans are not registered. [ This fixes bugzilla entry 15582 -Eric Dumazet] Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by:
-
Krishna Gudipati authored
commit 7873ca4e upstream. The port data structure related to fc_host statistics collection is not initialized. This causes system crash when reading the fc_host statistics. The fix is to initialize port structure during driver attach. Signed-off-by:
Krishna Gudipati <kgudipat@brocade.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
Jiri Slaby authored
commit cb174681 upstream. [ Backport to .32.y by Antonio Ospite <ospite@studenti.unina.it> ] There is a window between hidraw_table check and its dereference. In that window, the device may be unplugged and removed form the system and we will then dereference NULL. Lock that place properly so that either we get NULL and jump out or we can work with real pointer. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Antonio Ospite <ospite@studenti.unina.it> Signed-off-by:
-
Anton Blanchard authored
commit 320718ee upstream. I don't claim to understand the tty layer, but it seems like hvc_open and hvc_close should be balanced in their kref reference counting. Right now we get a kref every call to hvc_open: if (hp->count++ > 0) { tty_kref_get(tty); <----- here spin_unlock_irqrestore(&hp->lock, flags); hvc_kick(); return 0; } /* else count == 0 */ tty->driver_data = hp; hp->tty = tty_kref_get(tty); <------ or here if hp->count was 0 But hvc_close has: tty_kref_get(tty); if (--hp->count == 0) { ... /* Put the ref obtained in hvc_open() */ tty_kref_put(tty); ... } tty_kref_put(tty); Since the outside kref get/put balance we only do a single kref_put when count reaches 0. The patch below changes things to call tty_kref_put once for every hvc_close call, and with that my machine boots fine. Signed-off-by:
Anton Blanchard <anton@samba.org> Acked-by:
Amit Shah <amit.shah@redhat.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Amit Shah authored
commit e74d098c upstream. Alan pointed out a race in the code where hvc_remove is invoked. The recent virtio_console work is the first user of hvc_remove(). Alan describes it thus: The hvc_console assumes that a close and remove call can't occur at the same time. In addition tty_hangup(tty) is problematic as tty_hangup is asynchronous itself.... So this can happen hvc_close hvc_remove hung up ? - no lock tty = hp->tty unlock lock hp->tty = NULL unlock notify del kref_put the hvc struct close completes tty is destroyed tty_hangup dead tty tty->ops will be NULL NULL->... This patch adds some tty krefs and also converts to using tty_vhangup(). Reported-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Suresh Siddha authored
commit 254e4200 upstream. On platforms with Intel 7500 chipset, there were some reports of system hang/NMI's during kexec/kdump in the presence of interrupt-remapping enabled. During kdump, there is a window where the devices might be still using old kernel's interrupt information, while the kdump kernel is coming up. This can cause vt-d faults as the interrupt configuration from the old kernel map to null IRTE entries in the new kernel etc. (with out interrupt-remapping enabled, we still have the same issue but in this case we will see benign spurious interrupt hit the new kernel). Based on platform config settings, these platforms seem to generate NMI/SMI when a vt-d fault happens and there were reports that the resulting SMI causes the system to hang. Fix it by masking vt-d spec defined errors to platform error reporting logic. VT-d spec related errors are already handled by the VT-d OS code, so need to report the same error through other channels. Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <1291667190.2675.8.camel@sbsiddha-MOBL3.sc.intel.com> Reported-by:
Max Asbock <masbock@linux.vnet.ibm.com> Reported-and-tested-by:
Takao Indoh <indou.takao@jp.fujitsu.com> Acked-by:
Chris Wright <chrisw@sous-sol.org> Acked-by:
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Kenji Kaneshige authored
commit 086e8ced upstream. In x2apic mode, we need to set the upper address register of the fault handling interrupt register of the vt-d hardware. Without this irq migration of the vt-d fault handling interrupt is broken. Signed-off-by:
-
Suresh Siddha authored
commit 7f99d946 upstream. Fault handling is getting enabled after enabling the interrupt-remapping (as the success of interrupt-remapping can affect the apic mode and hence the fault handling mode). Hence there can potentially be some faults between the window of enabling interrupt-remapping in the vt-d and the fault-handling of the vt-d units. Handle any previous faults after enabling the vt-d fault handling. For v2.6.38 cleanup, need to check if we can remove the dmar_fault() in the enable_intr_remapping() and see if we can enable fault handling along with enabling intr-remapping. Signed-off-by:
-
Kenji Kaneshige authored
commit 7f7fbf45 upstream. Interrupt-remapping gets enabled very early in the boot, as it determines the apic mode that the processor can use. And the current code enables the vt-d fault handling before the setup_local_APIC(). And hence the APIC LDR registers and data structure in the memory may not be initialized. So the vt-d fault handling in logical xapic/x2apic modes were broken. Fix this by enabling the vt-d fault handling in the end_local_APIC_setup() A cleaner fix of enabling fault handling while enabling intr-remapping will be addressed for v2.6.38. [ Enabling intr-remapping determines the usage of x2apic mode and the apic mode determines the fault-handling configuration. ] Signed-off-by:
-
H. Peter Anvin authored
commit de2a8cf9 upstream. The vdso Makefile passes linker-style -m options not to the linker but to gcc. This happens to work with earlier gcc, but fails with gcc 4.6. Pass gcc-style -m options, instead. Note: all currently supported versions of gcc supports -m32, so there is no reason to conditionalize it any more. Reported-by:
H. J. Lu <hjl.tools@gmail.com> Signed-off-by:
-
Slava Pestov authored
commit 364829b1 upstream. The file_ops struct for the "trace" special file defined llseek as seq_lseek(). However, if the file was opened for writing only, seq_open() was not called, and the seek would dereference a null pointer, file->private_data. This patch introduces a new wrapper for seq_lseek() which checks if the file descriptor is opened for reading first. If not, it does nothing. Signed-off-by:
Slava Pestov <slavapestov@google.com> LKML-Reference: <1290640396-24179-1-git-send-email-slavapestov@google.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
NeilBrown authored
commit 1a855a06 upstream. With v0.90 metadata, a hot-spare does not become a full member of the array until recovery is complete. So if we re-add such a device to the array, we know that all of it is as up-to-date as the event count would suggest, and so it a bitmap-based recovery is possible. However with v1.x metadata, the hot-spare immediately becomes a full member of the array, but it record how much of the device has been recovered. If the array is stopped and re-assembled recovery starts from this point. When such a device is hot-added to an array we currently lose the 'how much is recovered' information and incorrectly included it as a full in-sync member (after bitmap-based fixup). This is wrong and unsafe and could corrupt data. So be more careful about setting saved_raid_disk - which is what guides the re-adding of devices back into an array. The new code matches the code in slot_store which does a similar thing, which is encouraging. This is suitable for any -stable kernel. Reported-by:
"Dailey, Nate" <Nate.Dailey@stratus.com> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Andreas Herrmann authored
[The mainline kernel doesn't have this problem. Commit "(23588c38) x86, amd: Add support for CPUID topology extension of AMD CPUs" removed the family check. But 2.6.32.y needs to be fixed.] This CPU family check is not required -- existence of the NodeId MSR is indicated by a CPUID feature flag which is already checked in amd_fixup_dcm() -- and it needlessly prevents amd_fixup_dcm() to be called for newer AMD CPUs. In worst case this can lead to a panic in the scheduler code for AMD family 0x15 multi-node AMD CPUs. I just have a picture of VGA console output so I can't copy-and-paste it herein, but the call stack of such a panic looked like: do_divide_error ... find_busiest_group run_rebalance_domains ... apic_timer_interrupt ... cpu_idle The mainline kernel doesn't have this problem. Commit "(23588c38) x86, amd: Add support for CPUID topology extension of AMD CPUs" removed the family check. But 2.6.32.y needs to be fixed. Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by:
-
David Kilroy authored
commit ba34fcee upstream. ... and interface up. In these situations, you are usually trying to connect to a new AP, so keeping TKIP countermeasures active is confusing. This is already how the driver behaves (inadvertently). However, querying SIOCGIWAUTH may tell userspace that countermeasures are active when they aren't. Clear the setting so that the reporting matches what the driver has done.. Signed-off by: David Kilroy <kilroyd@googlemail.com> Signed-off-by:
-
