- 18 Dec, 2009 40 commits
-
-
Alex Deucher authored
commit 500b7587 upstream. avivo chips Copied from pre-avivo code. Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alex Deucher authored
commit 4e3f9b78 upstream. Board is DVI+VGA, not DVI+DVI Signed-off-by:
-
Benjamin Herrenschmidt authored
commit e090aa80 upstream. e821ea70 introduced a bug by copying some 64-bit originated code as-is to be used by both 32 and 64-bit but this code contains a 64-bit ony "cmpdi" instruction. This changes it to cmpwi, which is fine since VRSAVE can only contains a 32-bit value anyway. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Darrick J. Wong authored
commit 1496e89a upstream. In commit 0512a9a8, we unilaterally zero the "pwm invert" bit in the fan behavior configuration register. On my PowerBook G4, this results in the fans going to full speed at low temperature and shutting off at high temperature because the pwm invert bit is supposed to be set. Therefore, record the pwm invert bit at driver load time, and write the bit into the fan behavior control register. This restores correct behavior on my PBG4 and should work around the bit being set to the wrong value after suspend/resume (which is what the original patch was trying to fix). It also fixes a minor omission where the pwm invert bit correction is NOT performed when switching into automatic mode. Signed-off-by:
Darrick J. Wong <djwong@us.ibm.com> Signed-off-by:
-
Bolko Maass authored
commit 529586dc upstream. Windfarm SMU control is explicitly missing support for a second CPU pump in G5 PowerMacs. Such machines actually exist (specifically Quads with a second pump), so this patch adds detection for it. Signed-off by: Bolko Maass <bmaass@math.uni-bremen.de> Signed-off-by:
-
Naoya Horiguchi authored
commit d33b9f45 upstream. Most callers of pmd_none_or_clear_bad() check whether the target page is in a hugepage or not, but walk_page_range() do not check it. So if we read /proc/pid/pagemap for the hugepage on x86 machine, the hugepage memory is leaked as shown below. This patch fixes it. Details ======= My test program (leak_pagemap) works as follows: - creat() and mmap() a file on hugetlbfs (file size is 200MB == 100 hugepages,) - read()/write() something on it, - call page-types with option -p (walk around the page tables), - munmap() and unlink() the file on hugetlbfs Without my patches ------------------ $ cat /proc/meminfo |grep "HugePage" HugePages_Total: 1000 HugePages_Free: 1000 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ./leak_pagemap [snip output] $ cat /proc/meminfo |grep "HugePage" HugePages_Total: 1000 HugePages_Free: 900 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ls /hugetlbfs/ $ 100 hugepages are accounted as used while there is no file on hugetlbfs. With my patches --------------- $ cat /proc/meminfo |grep "HugePage" HugePages_Total: 1000 HugePages_Free: 1000 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ./leak_pagemap [snip output] $ cat /proc/meminfo |grep "HugePage" HugePages_Total: 1000 HugePages_Free: 1000 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ls /hugetlbfs $ No memory leaks. Signed-off-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Wu Fengguang <fengguang.wu@intel.com> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: David Rientjes <rientjes@google.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Naoya Horiguchi authored
commit 4f16fc10 upstream. Most callers of pmd_none_or_clear_bad() check whether the target page is in a hugepage or not, but mincore() and walk_page_range() do not check it. So if we use mincore() on a hugepage on x86 machine, the hugepage memory is leaked as shown below. This patch fixes it by extending mincore() system call to support hugepages. Details ======= My test program (leak_mincore) works as follows: - creat() and mmap() a file on hugetlbfs (file size is 200MB == 100 hugepages,) - read()/write() something on it, - call mincore() for first ten pages and printf() the values of *vec - munmap() and unlink() the file on hugetlbfs Without my patch ---------------- $ cat /proc/meminfo| grep "HugePage" HugePages_Total: 1000 HugePages_Free: 1000 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ./leak_mincore vec[0] 0 vec[1] 0 vec[2] 0 vec[3] 0 vec[4] 0 vec[5] 0 vec[6] 0 vec[7] 0 vec[8] 0 vec[9] 0 $ cat /proc/meminfo |grep "HugePage" HugePages_Total: 1000 HugePages_Free: 999 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ls /hugetlbfs/ $ Return values in *vec from mincore() are set to 0, while the hugepage should be in memory, and 1 hugepage is still accounted as used while there is no file on hugetlbfs. With my patch ------------- $ cat /proc/meminfo| grep "HugePage" HugePages_Total: 1000 HugePages_Free: 1000 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ./leak_mincore vec[0] 1 vec[1] 1 vec[2] 1 vec[3] 1 vec[4] 1 vec[5] 1 vec[6] 1 vec[7] 1 vec[8] 1 vec[9] 1 $ cat /proc/meminfo |grep "HugePage" HugePages_Total: 1000 HugePages_Free: 1000 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ls /hugetlbfs/ $ Return value in *vec set to 1 and no memory leaks. [akpm@linux-foundation.org: cleanup] [akpm@linux-foundation.org: build fix] Signed-off-by:
-
Thomas Gleixner authored
commit a946d8f1 upstream. apic_noop is used to provide dummy apic functions. It's installed when the CPU has no APIC or when the APIC is disabled on the kernel command line. The apic_noop implementation of apic_write() warns when the CPU has an APIC or when the APIC is not disabled. That's bogus. The warning should only happen when the CPU has an APIC _AND_ the APIC is not disabled. apic_noop.apic_read() has the correct check. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Cyrill Gorcunov <gorcunov@openvz.org> LKML-Reference: <alpine.LFD.2.00.0912071255420.3089@localhost.localdomain> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Larry Finger authored
commit 70d57139 upstream. There are different bits used to convey the setting of the rfkill switch to the driver. The current driver only supports one of these possibilities. These changes were derived from the latest version of the vendor driver. This patch fixes the regression noted in kernel Bugzilla #14743. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Reported-and-tested-by:
Antti Kaijanmäki <antti@kaijanmaki.net> Tested-by:
Hin-Tak Leung <hintak.leung@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
John W. Linville authored
commit 19deffbe upstream. This part was missed in "cfg80211: implement get_wireless_stats", probably because sta_set_sinfo already existed and was only handling dBm signals. Signed-off-by:
-
Johannes Berg authored
commit 6d3560d4 upstream. Since sometimes mac80211 queues up a scan request to only act on it later, it must be allowed to (internally) cancel a not-yet-running scan, e.g. when the interface is taken down. This condition was missing since we always checked only the local->scanning variable which isn't yet set in that situation. Reported-by:
Luis R. Rodriguez <mcgrof@gmail.com> Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Javier Cardona authored
commit 7b324d28 upstream. The patch ("mac80211: Use correct sign for mesh active path refresh.") was actually a bug. Reverted it and improved the explanation of how mesh path refresh works. Signed-off-by:
Javier Cardona <javier@cozybit.com> Signed-off-by:
Andrey Yurovsky <andrey@cozybit.com> Signed-off-by:
-
Javier Cardona authored
commit 5d618cb8 upstream. Paths to mesh portals were being timed out immediately after each use in intermediate forwarding nodes. mppath->exp_time is set to the expiration time so assigning it to jiffies was marking the path as expired. Signed-off-by:
-
Vasanthakumar Thiagarajan authored
commit 1814077f upstream. On a 32-bit machine, BIT() macro does not give the required bit value if the bit is mroe than 31. In ieee802_11_parse_elems_crc(), BIT() is suppossed to get the bit value more than 31 (42 (id of ERP_INFO_IE), 37 (CHANNEL_SWITCH_IE), (42), 32 (POWER_CONSTRAINT_IE), 45 (HT_CAP_IE), 61 (HT_INFO_IE)). As we do not get the required bit value for the above IEs, crc over these IEs are never calculated, so any dynamic change in these IEs after the association is not really handled on 32-bit platforms. This patch fixes this issue. Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
-
Ian Jackson authored
commit 68cb4f8e upstream. Do not read IIR in serial8250_start_tx when UART_BUG_TXEN Reading the IIR clears some oustanding interrupts so it is not safe. Instead, simply transmit immediately if the buffer is empty without regard to IIR. Signed-off-by:
Ian Jackson <ian.jackson@eu.citrix.com> Reviewed-by:
Markus Armbruster <armbru@redhat.com> Reviewed-by:
Jiri Kosina <jkosina@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Alan Stern authored
commit 3589972e upstream. This patch (as1310) works around a race in dev_driver_string(). If the device is unbound while the function is running, dev->driver might become NULL after we test it and before we dereference it. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Mathieu Desnoyers authored
commit d3a3b0ad upstream. Setting fops and private data outside of the mutex at debugfs file creation introduces a race where the files can be opened with the wrong file operations and private data. It is easy to trigger with a process waiting on file creation notification. Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Signed-off-by:
-
Sukadev Bhattiprolu authored
commit edfacdd6 upstream. devpts_get_tty() assumes that the inode passed in is associated with a valid pty. But if the only reference to the pty is via a bind-mount, the inode passed to devpts_get_tty() while valid, would refer to a pty that no longer exists. With a lot of debug effort, Grzegorz Nosek developed a small program (see below) to reproduce a crash on recent kernels. This crash is a regression introduced by the commit: commit 527b3e47 Author: Sukadev Bhattiprolu <sukadev@us.ibm.com> Date: Mon Oct 13 10:43:08 2008 +0100 To fix, ensure that the dentry associated with the inode has not yet been deleted/unhashed by devpts_pty_kill(). See also: https://lists.linux-foundation.org/pipermail/containers/2009-July/019273.html tty-bug.c: #define _GNU_SOURCE #include <fcntl.h> #include <sched.h> #include <stdlib.h> #include <sys/mount.h> #include <sys/signal.h> #include <unistd.h> #include <stdio.h> #include <linux/fs.h> void dummy(int sig) { } static int child(void *unused) { int fd; signal(SIGINT, dummy); signal(SIGHUP, dummy); pause(); /* cheesy synchronisation to wait for /dev/pts/0 to appear */ mount("/dev/pts/0", "/dev/console", NULL, MS_BIND, NULL); sleep(2); fd = open("/dev/console", O_RDWR); dup(0); dup(0); write(1, "Hello world!\n", sizeof("Hello world!\n")-1); return 0; } int main(void) { pid_t pid; char *stack; stack = malloc(16384); pid = clone(child, stack+16384, CLONE_NEWNS|SIGCHLD, NULL); open("/dev/ptmx", O_RDWR|O_NOCTTY|O_NONBLOCK); unlockpt(fd); grantpt(fd); sleep(2); kill(pid, SIGHUP); sleep(1); return 0; /* exit before child opens /dev/console */ } Reported-by:
Grzegorz Nosek <root@localdomain.pl> Signed-off-by:
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Tested-by:
Serge Hallyn <serue@us.ibm.com> Signed-off-by:
-
Andi Kleen authored
commit 722d0172 upstream. get_user_pages() must be called with mmap_sem held. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: Andrew Morton <akpm@linuxfoundation.org> Cc: Nick Piggin <npiggin@suse.de> Cc: Darren Hart <dvhltc@us.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> LKML-Reference: <20091208121942.GA21298@basil.fritz.box> Signed-off-by:
-
NeilBrown authored
commit aa5cbd10 upstream. A write intent bitmap can be removed from an array while the array is active. When this happens, all IO is suspended and flushed before the bitmap is removed. However it is possible that bitmap_daemon_work is still running to clear old bits from the bitmap. If it is, it can dereference the bitmap after it has been freed. So introduce a new mutex to protect bitmap_daemon_work and get it before destroying a bitmap. This is suitable for any current -stable kernel. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Trond Myklebust authored
commit 190f38e5 upstream. The call to migrate_page() will cause the page->private field to be cleared. Also fix up the locking around the page->private transfer, so that we ensure that calls to nfs_page_find_request() don't end up racing. Finally, fix up a double free bug: nfs_unlock_request() already calls nfs_release_request() for us... Reported-by:
Wu Fengguang <fengguang.wu@intel.com> Tested-by:
Andi Kleen <andi@firstfloor.org> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Roel Kluin authored
commit 480e3243 upstream. IS_ERR returns 1 or 0, PTR_ERR returns the error value. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Signed-off-by:
-
Amerigo Wang authored
commit ec81aecb upstream. A specially-crafted Hierarchical File System (HFS) filesystem could cause a buffer overflow to occur in a process's kernel stack during a memcpy() call within the hfs_bnode_read() function (at fs/hfs/bnode.c:24). The attacker can provide the source buffer and length, and the destination buffer is a local variable of a fixed length. This local variable (passed as "&entry" from fs/hfs/dir.c:112 and allocated on line 60) is stored in the stack frame of hfs_bnode_read()'s caller, which is hfs_readdir(). Because the hfs_readdir() function executes upon any attempt to read a directory on the filesystem, it gets called whenever a user attempts to inspect any filesystem contents. [amwang@redhat.com: modify this patch and fix coding style problems] Signed-off-by:
WANG Cong <amwang@redhat.com> Cc: Eugene Teo <eteo@redhat.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Dave Anderson <anderson@redhat.com> Signed-off-by:
-
Igor Grinberg authored
commit 1b82e4c3 upstream. Signed-off-by:
Igor Grinberg <grinberg@compulab.co.il> Signed-off-by:
Mike Rapoport <mike@compulab.co.il> Signed-off-by:
Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
-
Russ Dill authored
commit c2d284ee upstream. USB drivers that create character devices call usb_register_dev in their probe function. This associates the usb_interface device with that minor number and creates the character device and announces it to the world. However, the driver's probe function is called before the new usb_interface is added to the driver's klist_devices. This is a problem because userspace will respond to the character device creation announcement by opening the character device. The driver's open function will the call usb_find_interface to find the usb_interface associated with that minor number. usb_find_interface will walk the driver's list of devices and find the usb_interface with the matching minor number. Because the announcement happens before the usb_interface is added to the driver's klist_devices, a race condition exists. A straightforward fix is to walk the list of devices on usb_bus_type instead since the device is added to that list before the announcement occurs. bus_find_device calls get_device to bump the reference count on the found device. It is arguable that the reference count should be dropped by the caller of usb_find_interface instead of usb_find_interface, however, the current users of usb_find_interface do not expect this. The original version of this patch only matched against minor number instead of driver and minor number. This version matches against both. Signed-off-by:
Russ Dill <Russ.Dill@gmail.com> Signed-off-by:
-
Alan Stern authored
commit a0bb1081 upstream. This patch (as1311) fixes a problem in usb-storage: Some devices are pretty broken when it comes to reporting sense data. The information they send back indicates that they have more than 18 bytes of sense data available, but when the system asks for more than 18 they fail or hang. The symptom is that probing fails with multiple resets. The patch adds a new BAD_SENSE flag to indicate that usb-storage should never ask for more than 18 bytes of sense data. The flag can be set in an unusual_devs entry or via the "quirks=" module parameter, and it is set automatically whenever a REQUEST SENSE command for more than 18 bytes fails or times out. An unusual_devs entry is added for the Agfa photo frame, which uses a Prolific chip having this bug. Signed-off-by:
Daniel Kukula <daniel.kuku@gmail.com> Signed-off-by:
-
Andre Herms authored
commit ec412b92 upstream. usb_bulk_msg() transfers only bytes up to the maximum packet size. It must be repeated by the usbtmc driver until all bytes of a TMC message are transfered. Without this patch, ETIMEDOUT is reported when writing TMC messages larger than the maximum USB bulk size and the transfer remains incomplete. The user will notice that the device hangs and must be reset by either closing the application or pulling the plug. Signed-off-by:
Andre Herms <andre.herms@tec-venture.de> Signed-off-by:
-
Zhang Le authored
commit 54a8e144 upstream. Add D-Link DWM-162-U5 device id 1e0e:ce16 into option driver. The device has 4 interfaces, of which 1 is handled by storage and the other 3 by option driver. The device appears first as CD-only 05c6:2100 device and must be switched to 1e0e:ce16 mode either by using "eject CD" or usb_modeswitch. The MessageContent for usb_modeswitch.conf is: "55534243e0c26a85000000000000061b000000020000000000000000000000" Signed-off-by:
Zhang Le <r0bertz@gentoo.org> Signed-off-by:
-
Sergei Shtylyov authored
commit 196f1b7a upstream. Commit a5073b52 (musb_gadget: fix unhandled endpoint 0 IRQs) somehow missed its key change: "The gadget EP0 code routinely ignores an interrupt at end of the data phase because of musb_g_ep0_giveback() resetting the state machine to "idle, waiting for SETUP" phase prematurely." So, the majority of the cases of unhandled IRQs is still unfixed... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
Anand Gadiyar <gadiyar@ti.com> Signed-off-by:
-
Sarah Sharp authored
commit 36d0344c upstream. Add the xHCI driver files to its MAINTAINERS entry so that I'm Cc'd on cleanup patches. Update the email address to one I actually use for sending patches and responding to Linux mailing list emails. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Theodore Ts'o authored
commit e6a47428 upstream. If there is a failed journal checksum, don't reset the journal. This allows for userspace programs to decide how to recover from this situation. It may be that ignoring the journal checksum failure might be a better way of recovering the file system. Once we add per-block checksums, we can definitely do better. Until then, a system administrator can try backing up the file system image (or taking a snapshot) and and trying to determine experimentally whether ignoring the checksum failure or aborting the journal replay results in less data loss. Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit 6afaf8a4 upstream. ubiupdatevol -t does the following: - ubi_start_update() - set_update_marker() - for all LEBs ubi_eba_unmap_leb() - clear_update_marker() - ubi_wl_flush() ubi_wl_flush() physically erases all PEB, once it returns all PEBs are empty. clear_update_marker() has the update marker written after return. If there is a power cut between the last two functions then the UBI volume has no longer the "update" marker set and may have some valid LEBs while some of them may be gone. If that volume in question happens to be a UBIFS volume, then mount will fail with |UBIFS error (pid 1361): ubifs_read_node: bad node type (255 but expected 6) |UBIFS error (pid 1361): ubifs_read_node: bad node at LEB 0:0 |Not a node, first 24 bytes: |00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff if there is at least one valid LEB and the wear-leveling worker managed to clear LEB 0. The patch waits for the wl worker to finish prior clearing the "update" marker on flash. The two new LEB which are scheduled for erasing after clear_update_marker() should not matter because they are only visible to UBI. Signed-off-by:
Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by:
-
Alexey Dobriyan authored
commit 4b731d50 upstream. commit d8e180dc "bsdacct: switch credentials for writing to the accounting file" introduced credential switching during final acct data collecting. However, uid/gid pair continued to be collected from current which became credentials of who created acct file, not who exits. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14676Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Reported-by:
Juho K. Juopperi <jkj@kapsi.fi> Acked-by:
David Howells <dhowells@redhat.com> Reviewed-by:
Michal Schmidt <mschmidt@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by:
-
Roel Kluin authored
commit c95a419a upstream. The reg_pair2[j].reg was tested twice. Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Hendrik Brueckner authored
commit cf87b743 upstream. When the kernel is IPLed without the CLEAR option and switches to 64-bit, the high-order half of the registers might contain random values. This can cause addressing exceptions and the kernel enters an interrupt loop. Initialize the high-order half of the general purpose registers with zeros after switching to 64-bit mode. Signed-off-by:
Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Sergei Shtylyov authored
commit 5600c70e upstream. These drivers inherited from the older 'hpt366' IDE driver the buggy timing register masks in their set_piomode() metods. As a result, too low command cycle active time is programmed for slow PIO modes. Quite fortunately, it's later "fixed up" by the set_dmamode() methods which also "helpfully" reprogram the command timings, usually to PIO mode 4; unfortunately, setting an UltraDMA mode #N also reprograms already set PIO data timings, usually to MWDMA mode # max(N, 2) timings... However, the drivers added some breakage of their own too: the bit that they set/clear to control the FIFO is sometimes wrong -- it's actually the MSB of the command cycle setup time; also, setting it in DMA mode is wrong as this bit is only for PIO actually and clearing it for PIO modes is not needed as no mode in any timing table has it set... Fix all this, inverting the masks while at it, like in the 'hpt366' and 'pata_hpt366' drivers; bump the drivers' versions, accounting for recent patches that forgot to do it... Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Dave Jones authored
commit e02e0e1a upstream. I double-checked the datasheet. One of the existing descriptors has a typo: it should be 2MB not 2038 KB. Signed-off-by:
Dave Jones <davej@redhat.com> LKML-Reference: <20091110200120.GA27090@redhat.com> Signed-off-by:
-
Dave Jones authored
commit 85160b92 upstream. The latest rev of Intel doc AP-485 details new cache descriptors that we don't yet support. 12MB, 18MB and 24MB 24-way assoc L3 caches. Signed-off-by:
-
Cliff Wickman authored
commit 1d865fb7 upstream. Interrupt vector 0xec has been doubly defined in irq_vectors.h It seems arbitrary whether LOCAL_PENDING_VECTOR or UV_BAU_MESSAGE is the higher number. As long as they are unique. If they are not unique we'll hit a BUG in alloc_system_vector(). Signed-off-by:
Cliff Wickman <cpw@sgi.com> LKML-Reference: <E1NJ9Pe-0004P7-0Q@eag09.americas.sgi.com> Signed-off-by:
-
Cliff Wickman authored
commit e38e2af1 upstream. A memory mapped register that affects the SGI UV Broadcast Assist Unit's interrupt handling may sometimes be unintialized. Remove the condition on its initialization, as that condition can be randomly satisfied by a hardware reset. Signed-off-by:
-
