- 27 May, 2008 1 commit
-
-
Michael Reed authored
Following a hard reset of a SAS raid, one of the raid targets is occasionally missing. I tracked this down to a pretty obscure little bug. The LSI fusion drivers for SAS and Fibre Channel both use their respective transport layers. Those transport layers increment the target number assigned to new targets. The routine __scsi_scan_target uses the "this_id" element of the Scsi_Host structure to avoid scanning the scsi host adapter. Both fusion drivers set "this_id" from a value returned in a firmware PortFacts response. For my particular test case (SAS) the firmware id assigned to the initiator was 173. After enough raid resets to cause the raid targets to go and come a sufficient number of times, the id assigned by the transport to a raid target would match the id assigned by the host adapter to the "this_id" field, resulting in that target not being scanned. Fix by not assigning this_id and not checking it in slave_configure. Signed-off-by:
Michael Reed <mdr@sgi.com> Acked-by:
"Moore, Eric" <Eric.Moore@lsi.com> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com>
-
- 23 May, 2008 1 commit
-
-
James Bottomley authored
Reported-by:
Sitsofe Wheeler <sitsofe@yahoo.com> > BUG: unable to handle kernel paging request at e6f17fac > IP: [<c02604d6>] scsi_bus_uevent+0x1/0x17 > *pde = 2714b163 *pte = 26f17160 > Oops: 0000 [#1] DEBUG_PAGEALLOC > last sysfs file: > > Pid: 1, comm: swapper Not tainted (2.6.26-rc2-next-20080516skw #30) > EIP: 0060:[<c02604d6>] EFLAGS: 00010282 CPU: 0 > EIP is at scsi_bus_uevent+0x1/0x17 > EAX: e6f18014 EBX: e6f18014 ECX: c02604d5 EDX: e7173000 > ESI: e7173000 EDI: e7173000 EBP: e7851ca0 ESP: e7851c90 > DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 The problem is caused by: commit b0ed4336 Author: Hannes Reinecke <hare@suse.de> Date: Tue Mar 18 14:32:28 2008 +0100 [SCSI] add scsi_host and scsi_target to scsi_bus which added scsi_bus_type to the struct scsi_target device. This causes both the scsi_device and scsi_target to fire scsi_bus_uevents. However, the actualy scsi_bus_uevent() call assumes blindly that it's a struct scsi_device. Check for this and return immediately if it isn't. Signed-off-by:
-
- 15 May, 2008 38 commits
-
-
Andrew Vasquez authored
Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
-
Andrew Vasquez authored
This reverts commit 8084fe16. The midlayer should be given the oppotunity to interpret the check-condition and based on scsi_cmnd->resid determine if a transfer should be retried or failed. Signed-off-by:
-
Andrew Vasquez authored
Matthew Wilcox <matthew@wil.cx> reported the following lockdep warning: > ================================= > [INFO:inconsistentlockstate] > 2.6.26-rc1-00115-g0340eda-dirty#60 > --------------------------------- > inconsistent{hardirq-on-W}->{in-hardirq-W}usage. > swapper/1[HC1[1]:SC0[0]:HE0:SE1]takes: > (&ha->hardware_lock){+-..},at:[<c035495d>]qla2300_intr_handler+0x35/0x1f5 > {hardirq-on-W}statewasregisteredat: > [<c0139a16>]__lock_acquire+0x459/0xb1d > [<c013a091>]__lock_acquire+0xad4/0xb1d > [<c013a142>]lock_acquire+0x68/0x82 > [<c035495d>]qla2300_intr_handler+0x35/0x1f5 > [<c0506da5>]_spin_lock+0x24/0x4d > [<c035495d>]qla2300_intr_handler+0x35/0x1f5 > [<c035495d>]qla2300_intr_handler+0x35/0x1f5 > [<c01391e4>]trace_hardirqs_on+0xe7/0x10e > [<c034f0a6>]qla2x00_mailbox_command+0x1c6/0x433 ... > other info that might help us debug this: > no locks held by swapper/1. > > stack backtrace: > Pid:1,comm:swapperNottainted2.6.26-rc1-00115-g0340eda-dirty#60 > [<c0138121>]print_usage_bug+0x100/0x10a > [<c0138d37>]mark_lock+0xaa/0x395 > [<c01399af>]__lock_acquire+0x3f2/0xb1d > [<c013a091>]__lock_acquire+0xad4/0xb1d > [<c013a142>]lock_acquire+0x68/0x82 > [<c035495d>]qla2300_intr_handler+0x35/0x1f5 > [<c0506da5>]_spin_lock+0x24/0x4d > [<c035495d>]qla2300_intr_handler+0x35/0x1f5 > [<c035495d>]qla2300_intr_handler+0x35/0x1f5 > [<c014a37b>]handle_IRQ_event+0x13/0x3d > [<c014b366>]handle_fasteoi_irq+0x76/0xab Which shows that lockdep is detecting the driver's interrupt-handler is run in both process and interrupt context with irqs-enabled in the former case. During init-time and error-recovery (after a RISC reset), the driver disables interrupts and 'polls' for completions by calling qla2x00_poll(): static inline void qla2x00_poll(scsi_qla_host_t *ha) { ha->isp_ops->intr_handler(0, ha); } which in-turn calls the ISP registered interrupt handler. This patch corrects it by disabling local interrupts during polling. Reviewed-by:Matthew Wilcox <willy@linux.intel.com> Signed-off-by:
-
Andrew Vasquez authored
The user-initiated dump can be a useful tool in triaging complex ISP and FC issues. Signed-off-by:
-
Andrew Vasquez authored
Recent firmwares no longer return the 'number of buffers' in mailbox6. The original code may result in a potential panic during a FW-dump process due to the driver misinterpreting the size of the allocated buffer. Signed-off-by:
-
matthias@kaehlcke.net authored
The semaphore vport_sem is used as a mutex. Convert it to the mutex API. Signed-off-by:
Matthias Kaehlcke <matthias@kaehlcke.net> Signed-off-by:
-
Daniel Walker authored
Signed-off-by:
Daniel Walker <dwalker@mvista.com> Signed-off-by:
-
Andrew Vasquez authored
Both MSI-X vector handlers attempt to acquire the HA's hardware_lock. This though requires that interrupts be disabled/enabled during acquisition and release of the spinlock. Signed-off-by:
-
Andrew Vasquez authored
Signed-off-by:
-
Shyam Sundar authored
For Vports, the port_type should be set to FC_PORTTYPE_NPIV. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fsLinus Torvalds authored
* 'for-linus' of ssh://master.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs: 9p: fix error path during early mount 9p: make cryptic unknown error from server less scary 9p: fix flags length in net 9p: Correct fidpool creation failure in p9_client_create 9p: use struct mutex instead of struct semaphore 9p: propagate parse_option changes to client and transports fs/9p/v9fs.c (v9fs_parse_options): Handle kstrdup and match_strdup failure. 9p: Documentation updates add match_strlcpy() us it to make v9fs make uname and remotename parsing more robust
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6: sparc64: Use a TS_RESTORE_SIGMASK lmb: Make lmb debugging more useful. lmb: Fix inconsistent alignment of size argument. sparc: Fix mremap address range validation.
-
Andrew Morton authored
net/irda/irnet/irnet_irda.c: In function 'irnet_discovery_indication': net/irda/irnet/irnet_irda.c:1676: error: implicit declaration of function 'get_unaligned' Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Andrew Morton authored
May 11 09:42:27 [kernel] [ 1104.496819] rarian-sk-get-c[5630]: segfault at 0 ip 7f478556caf0 sp 7fff8e3fe338 error 4 in libc-2.6.1.so[7f47854f9000+136000] May 11 10:59:48 [kernel] [ 2494.165792] May 11 10:59:48 [kernel] [ 2494.165794] ======================================================= May 11 10:59:48 [kernel] [ 2494.165801] [ INFO: possible circular locking dependency detected ] May 11 10:59:48 [kernel] [ 2494.165805] 2.6.26-rc1-00007-g91b3a7a #217 May 11 10:59:48 [kernel] [ 2494.165807] ------------------------------------------------------- May 11 10:59:48 [kernel] [ 2494.165809] less/7053 is trying to acquire lock: May 11 10:59:48 [kernel] [ 2494.165812] (tasklist_lock){..??}, at: [<ffffffff80232e95>] is_current_pgrp_orphaned+0x15/0x50 May 11 10:59:48 [kernel] [ 2494.165821] May 11 10:59:48 [kernel] [ 2494.165822] but task is already holding lock: May 11 10:59:48 [kernel] [ 2494.165824] (&tty->ctrl_lock){....}, at: [<ffffffff803d5f31>] tty_check_change+0x61/0x110 May 11 10:59:48 [kernel] [ 2494.165831] May 11 10:59:48 [kernel] [ 2494.165832] which lock already depends on the new lock. May 11 10:59:48 [kernel] [ 2494.165833] May 11 10:59:48 [kernel] [ 2494.165835] May 11 10:59:48 [kernel] [ 2494.165836] the existing dependency chain (in reverse order) is: May 11 10:59:48 [kernel] [ 2494.165838] May 11 10:59:48 [kernel] [ 2494.165839] -> #2 (&tty->ctrl_lock){....}: May 11 10:59:48 [kernel] [ 2494.165843] [<ffffffff80253796>] __lock_acquire+0xf86/0x1080 May 11 10:59:48 [kernel] [ 2494.165851] [<ffffffff80253922>] lock_acquire+0x92/0xc0 May 11 10:59:48 [kernel] [ 2494.165858] [<ffffffff804deee0>] _spin_lock_irqsave+0x40/0x60 May 11 10:59:48 [kernel] [ 2494.165866] [<ffffffff803d31b5>] __proc_set_tty+0x35/0xe0 May 11 10:59:48 [kernel] [ 2494.165873] [<ffffffff803d76d4>] tty_ioctl+0xbf4/0xfe0 May 11 10:59:48 [kernel] [ 2494.165880] [<ffffffff802a05e1>] vfs_ioctl+0x31/0x90 May 11 10:59:48 [kernel] [ 2494.165888] [<ffffffff802a06b3>] do_vfs_ioctl+0x73/0x2d0 May 11 10:59:48 [kernel] [ 2494.165895] [<ffffffff802a095a>] sys_ioctl+0x4a/0x80 May 11 10:59:48 [kernel] [ 2494.165902] [<ffffffff8020b5ab>] system_call_after_swapgs+0x7b/0x80 May 11 10:59:48 [kernel] [ 2494.165910] [<ffffffffffffffff>] 0xffffffffffffffff May 11 10:59:48 [kernel] [ 2494.165924] May 11 10:59:48 [kernel] [ 2494.165925] -> #1 (&sighand->siglock){++..}: May 11 10:59:48 [kernel] [ 2494.165929] [<ffffffff80253796>] __lock_acquire+0xf86/0x1080 May 11 10:59:48 [kernel] [ 2494.165936] [<ffffffff80253922>] lock_acquire+0x92/0xc0 May 11 10:59:48 [kernel] [ 2494.165943] [<ffffffff804dec1f>] _spin_lock+0x2f/0x40 May 11 10:59:48 [kernel] [ 2494.165951] [<ffffffff8022d5a3>] copy_process+0x973/0x1210 May 11 10:59:48 [kernel] [ 2494.165959] [<ffffffff8022df12>] do_fork+0x82/0x2f0 May 11 10:59:48 [kernel] [ 2494.165967] [<ffffffff8020bfe1>] kernel_thread+0x81/0xde May 11 10:59:48 [kernel] [ 2494.165974] [<ffffffff8020c048>] child_rip+0xa/0x12 May 11 10:59:48 [kernel] [ 2494.165981] [<ffffffffffffffff>] 0xffffffffffffffff May 11 10:59:48 [kernel] [ 2494.166038] May 11 10:59:48 [kernel] [ 2494.166039] -> #0 (tasklist_lock){..??}: May 11 10:59:48 [kernel] [ 2494.166043] [<ffffffff802535ab>] __lock_acquire+0xd9b/0x1080 May 11 10:59:48 [kernel] [ 2494.166050] [<ffffffff80253922>] lock_acquire+0x92/0xc0 May 11 10:59:48 [kernel] [ 2494.166057] [<ffffffff804dede2>] _read_lock+0x32/0x50 May 11 10:59:48 [kernel] [ 2494.166063] [<ffffffff80232e95>] is_current_pgrp_orphaned+0x15/0x50 May 11 10:59:48 [kernel] [ 2494.166071] [<ffffffff803d5f80>] tty_check_change+0xb0/0x110 May 11 10:59:48 [kernel] [ 2494.166078] [<ffffffff803dac5f>] set_termios+0x1f/0x4c0 May 11 10:59:48 [kernel] [ 2494.166085] [<ffffffff803db379>] tty_mode_ioctl+0x279/0x3e0 May 11 10:59:48 [kernel] [ 2494.166092] [<ffffffff803db51d>] n_tty_ioctl+0x3d/0x260 May 11 10:59:48 [kernel] [ 2494.166100] [<ffffffff803d6c34>] tty_ioctl+0x154/0xfe0 May 11 10:59:48 [kernel] [ 2494.166107] [<ffffffff802a05e1>] vfs_ioctl+0x31/0x90 May 11 10:59:48 [kernel] [ 2494.166114] [<ffffffff802a06b3>] do_vfs_ioctl+0x73/0x2d0 May 11 10:59:48 [kernel] [ 2494.166121] [<ffffffff802a095a>] sys_ioctl+0x4a/0x80 May 11 10:59:48 [kernel] [ 2494.166128] [<ffffffff8020b5ab>] system_call_after_swapgs+0x7b/0x80 May 11 10:59:48 [kernel] [ 2494.166135] [<ffffffffffffffff>] 0xffffffffffffffff May 11 10:59:48 [kernel] [ 2494.166142] May 11 10:59:48 [kernel] [ 2494.166143] other info that might help us debug this: May 11 10:59:48 [kernel] [ 2494.166144] May 11 10:59:48 [kernel] [ 2494.166146] 1 lock held by less/7053: May 11 10:59:48 [kernel] [ 2494.166148] #0: (&tty->ctrl_lock){....}, at: [<ffffffff803d5f31>] tty_check_change+0x61/0x110 May 11 10:59:48 [kernel] [ 2494.166155] May 11 10:59:48 [kernel] [ 2494.166156] stack backtrace: May 11 10:59:48 [kernel] [ 2494.166159] Pid: 7053, comm: less Not tainted 2.6.26-rc1-00007-g91b3a7a #217 May 11 10:59:48 [kernel] [ 2494.166161] May 11 10:59:48 [kernel] [ 2494.166162] Call Trace: May 11 10:59:48 [kernel] [ 2494.166168] [<ffffffff80251223>] print_circular_bug_tail+0x83/0x90 May 11 10:59:48 [kernel] [ 2494.166172] [<ffffffff80250889>] ? print_circular_bug_entry+0x49/0x60 May 11 10:59:48 [kernel] [ 2494.166178] [<ffffffff802535ab>] __lock_acquire+0xd9b/0x1080 May 11 10:59:48 [kernel] [ 2494.166184] [<ffffffff80232e95>] ? is_current_pgrp_orphaned+0x15/0x50 May 11 10:59:48 [kernel] [ 2494.166189] [<ffffffff80253922>] lock_acquire+0x92/0xc0 May 11 10:59:48 [kernel] [ 2494.166206] [<ffffffff803d5f80>] tty_check_change+0xb0/0x110 May 11 10:59:48 [kernel] [ 2494.166211] [<ffffffff803dac5f>] set_termios+0x1f/0x4c0 May 11 10:59:48 [kernel] [ 2494.166216] [<ffffffff803d3423>] ? tty_ldisc_try+0x23/0x60 May 11 10:59:48 [kernel] [ 2494.166220] [<ffffffff803d3444>] ? tty_ldisc_try+0x44/0x60 May 11 10:59:48 [kernel] [ 2494.166224] [<ffffffff804df2c5>] ? _spin_unlock_irqrestore+0x65/0x80 May 11 10:59:48 [kernel] [ 2494.166230] [<ffffffff803db379>] tty_mode_ioctl+0x279/0x3e0 May 11 10:59:48 [kernel] [ 2494.166234] [<ffffffff803d3444>] ? tty_ldisc_try+0x44/0x60 May 11 10:59:48 [kernel] [ 2494.166239] [<ffffffff803db51d>] n_tty_ioctl+0x3d/0x260 May 11 10:59:48 [kernel] [ 2494.166244] [<ffffffff803d6c34>] tty_ioctl+0x154/0xfe0 May 11 10:59:48 [kernel] [ 2494.166249] [<ffffffff80252baa>] ? __lock_acquire+0x39a/0x1080 May 11 10:59:48 [kernel] [ 2494.166256] [<ffffffff80252baa>] ? __lock_acquire+0x39a/0x1080 May 11 10:59:48 [kernel] [ 2494.166263] [<ffffffff80252baa>] ? __lock_acquire+0x39a/0x1080 May 11 10:59:48 [kernel] [ 2494.166269] [<ffffffff802a05e1>] vfs_ioctl+0x31/0x90 May 11 10:59:48 [kernel] [ 2494.166274] [<ffffffff802a06b3>] do_vfs_ioctl+0x73/0x2d0 May 11 10:59:48 [kernel] [ 2494.166280] [<ffffffff802a095a>] sys_ioctl+0x4a/0x80 May 11 10:59:48 [kernel] [ 2494.166286] [<ffffffff8020b5ab>] system_call_after_swapgs+0x7b/0x80 May 11 10:59:48 [kernel] [ 2494.166292] Acked-by:Alan Cox <alan@lxorguk.ukuu.org.uk> Reported-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by:
-
Neil Brown authored
As setting and clearing queue flags now requires that we hold a spinlock on the queue, and as blk_queue_stack_limits is called without that lock, get the lock inside blk_queue_stack_limits. For blk_queue_stack_limits to be able to find the right lock, each md personality needs to set q->queue_lock to point to the appropriate lock. Those personalities which didn't previously use a spin_lock, us q->__queue_lock. So always initialise that lock when allocated. With this in place, setting/clearing of the QUEUE_FLAG_PLUGGED bit will no longer cause warnings as it will be clear that the proper lock is held. Thanks to Dan Williams for review and fixing the silly bugs. Signed-off-by:
NeilBrown <neilb@suse.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Alistair John Strachan <alistair@devzero.co.uk> Cc: Nick Piggin <npiggin@suse.de> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Jacek Luczak <difrost.kernel@gmail.com> Cc: Prakash Punnoor <prakash@punnoor.de> Signed-off-by:
-
Jiri Slaby authored
Select FW_LOADER since moxa needs it, otherwise we face link problems such as: drivers/built-in.o: In function moxa_pci_probe':moxa.c:(.devinit.text+0x76d8): undefined reference to request_firmware' :moxa.c:(.devinit.text+0x7e6e): undefined reference to release_firmware' make: *** [.tmp_vmlinux1] Error 1 Reported-by:
Philippe Roussel <p.o.roussel@free.fr> Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
Heiko Carstens authored
Trying to online a new memory section that was added via memory hotplug sometimes results in crashes when the new pages are added via __free_page. Reason for that is that the pageblock bitmap isn't initialized and hence contains random stuff. That means that get_pageblock_migratetype() returns also random stuff and therefore list_add(&page->lru, &zone->free_area[order].free_list[migratetype]); in __free_one_page() tries to do a list_add to something that isn't even necessarily a list. This happens since 86051ca5 ("mm: fix usemap initialization") which makes sure that the pageblock bitmap gets only initialized for pages present in a zone. Unfortunately for hot-added memory the zones "grow" after the memmap and the pageblock memmap have been initialized. Which means that the new pages have an unitialized bitmap. To solve this the calls to grow_zone_span() and grow_pgdat_span() are moved to __add_zone() just before the initialization happens. The patch also moves the two functions since __add_zone() is the only caller and I didn't want to add a forward declaration. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Andy Whitcroft <apw@shadowen.org> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Yasunori Goto <y-goto@jp.fujitsu.com> Cc: <stable@kernel.org> Signed-off-by:
-
Venki Pallipadi authored
There is a defect in mprotect, which lets the user change the page cache type bits by-passing the kernel reserve_memtype and free_memtype wrappers. Fix the problem by not letting mprotect change the PAT bits. Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Eric Dumazet authored
Current module loader lookups ".data.percpu" ELF section to perform per_cpu relocation. But DEFINE_PER_CPU_SHARED_ALIGNED() uses another section (".data.percpu.shared_aligned"), currently only handled in vmlinux.lds, not by module loader. To correct this problem, instead of adding logic into module loader, or using at build time a module.lds file for all arches to group ".data.percpu.shared_aligned" into ".data.percpu", just use ".data.percpu" for modules. Alignment requirements are correctly handled by ld and module loader. Signed-off-by:Eric Dumazet <dada1@cosmosbay.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by:
-
Geoff Levand authored
Add a check to online_pages() to test for failure of walk_memory_resource(). This fixes a condition where a failure of walk_memory_resource() can lead to online_pages() returning success without the requested pages being onlined. Signed-off-by:
Geoff Levand <geoffrey.levand@am.sony.com> Cc: Yasunori Goto <y-goto@jp.fujitsu.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Keith Mannthey <kmannth@us.ibm.com> Cc: Christoph Lameter <clameter@sgi.com> Cc: Paul Jackson <pj@sgi.com> Signed-off-by:
-
Harvey Harrison authored
Add a common hex array in hexdump.c so everyone can use it. Add a common hi/lo helper to avoid the shifting masking that is done to get the upper and lower nibbles of a byte value. Pull the pack_hex_byte helper from kgdb as it is opencoded many places in the tree that will be consolidated. Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Acked-by:
Paul Mundt <lethal@linux-sh.org> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Robin Getz authored
This art design is beautiful, isn't it? And you can watch our demo on YouTube: http://youtube.com/watch?v=fKyQOntPEFsSigned-off-by:
Robin Getz <robin.getz@analog.com> Signed-off-by:
Bryan Wu <cooloney@kernel.org> Signed-off-by:
-
Tiger Yang authored
This fix the uninitialized bs when we try to replace a xattr entry in ibody with the new value which require more than free space. This situation only happens we format ext3/4 with inode size more than 128 and we have put xattr entries both in ibody and block. The consequences about this bug is we will lost the xattr block which pointed by i_file_acl with all xattr entires in it. We will alloc a new xattr block and put that large value entry in it. The old xattr block will become orphan block. Signed-off-by:
Tiger Yang <tiger.yang@oracle.com> Cc: <linux-ext4@vger.kernel.org> Cc: Andreas Gruenbacher <agruen@suse.de> Acked-by:
Andreas Dilger <adilger@sun.com> Cc: <stable@kernel.org> Signed-off-by:
-
Mirco Tischler authored
Return type of cpu_rt_runtime_write() should be int instead of ssize_t. Signed-off-by:
Mirco Tischler <mt-ml@gmx.de> Acked-by:
Paul Menage <menage@google.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Mike Frysinger authored
I noticed this because alpha was broken due to the recent commit commit bdc80787 ("avoid overflows in kernel/time.c"). Most arches do something like this in their asm/param.h: #ifdef __KERNEL__ # define HZ CONFIG_HZ #else # define HZ 100 #endif A few arches though (namely alpha/h8300/um/v850/xtensa) either do no set HZ at all for !__KERNEL__, or they set it wrongly. This should bring all arches in line by setting up HZ for userspace. Without this currently perl 5.10 doesn't build on alpha: perl.c: In function 'perl_construct': perl.c:388: error: 'CONFIG_HZ' undeclared (first use in this function) -> http://buildd.debian.org/fetch.cgi?pkg=perl;ver=5.10.0-10;arch=alpha;stamp=1210252894Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Jeff Dike <jdike@addtoit.com> Cc: Chris Zankel <chris@zankel.net> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Mingming Cao authored
Updating the current transaction's t_state is protected by j_state_lock. We need to do the same when updating the t_state to T_COMMIT. Signed-off-by:
Mingming Cao <cmm@us.ibm.com> Acked-by:
Jan Kara <jack@ucw.cz> Signed-off-by:
-
Heiko Carstens authored
__add_zone calls memmap_init_zone twice if memory gets attached to an empty zone. Once via init_currently_empty_zone and once explictly right after that call. Looks like this is currently not a bug, however the call is superfluous and might lead to subtle bugs if memmap_init_zone gets changed. So make sure it is called only once. Cc: Yasunori Goto <y-goto@jp.fujitsu.com> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Dave Hansen <haveblue@us.ibm.com> Signed-off-by:
-
Nate Case authored
The current OF probing assumes that the resource is IORESOURCE_MEM. This checks for the IORESOURCE_IO flag and behaves appropriately. An I/O resource can exist with an ipmi device node on a legacy ISA bus. Signed-off-by:
Nate Case <ncase@xes-inc.com> Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
Nicolas Ferre authored
Fix initialization of framebuffer not calling ioremap_writecombine() function and not using internal SRAM for at91sam9rl. This is a little rework of the "Don't initialize a pre-allocated framebuffer" patch that corrects the call to ioremap_writecombine() function. It also cuts the use of internal SRAM for at91sam9rl : it is a bit small for a framebuffer. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Andrew Victor <linux@maxim.org.za> Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by:
-
Miklos Szeredi authored
filemap_fault will go into an infinite loop if ->readpage() fails asynchronously. AFAICS the bug was introduced by this commit, which removed the wait after the final readpage: commit d00806b1 Author: Nick Piggin <npiggin@suse.de> Date: Thu Jul 19 01:46:57 2007 -0700 mm: fix fault vs invalidate race for linear mappings Fix by reintroducing the wait_on_page_locked() after ->readpage() to make sure the page is up-to-date before jumping back to the beginning of the function. I've noticed this while testing nfs exporting on fuse. The patch fixes it. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Cc: Nick Piggin <npiggin@suse.de> Signed-off-by:
-
Rene Herman authored
The AD181x and AZT230 chips don't support an IRQ-less MPU401 option but work fine without one. This adds (priority functional) IRQ-less options for each port option to help systems with few available IRQs. The AD1815 quirk can't use pnp_register_irq_resource() due to doubly penalizing the IRQ. Also, while not a practical issue due to no IRQ option being present for the dependents, this needs to add in front, not back. Doesn't use pnp_register_port_resource() for symetry with above. This does not delete the AD1815 independent option even though it should be empty after the IRQ transfer due to AD1816 coming with an empty but still present independent option by default. Was tested on AD1815, AD1816 and AZT2320. The ALSA snd-ad1818a driver also support the AZT2002 ID for MPU401 but this doesn't as I was unable to test it. Signed-off-by:
Rene Herman <rene.herman@gmail.com> Tested-by:
Uwe Bugla <uwe.bugla@gmx.de> Acked-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Len Brown <len.brown@intel.com Signed-off-by:
-
Rene Herman authored
The subsequent AD181x quirk patch would like this as part of the API. pnp_register_dependent_option() adds to the same dependent chain the quirk is walking which is fairly unclean. This enables a private option chain build which it can then just add onto the end when done. Signed-off-by:
-
Rene Herman authored
Make it look a bit more like pci_fixup_device/pci_do_fixups. Also print the PnP ID and delete the () from the "foo+0x0/0x1234()". Signed-off-by:
-
Jens Rottmann authored
The following patch caused a regression with OLPC panels: commit 3888d463 lxfb: extend PLL table to support dotclocks below 25 MHz Extends the PLL frequency table of the AMD Geode-LX frame buffer driver to make use of the DIV4 bit, thus adding support for dotclocks between 6 and 25 MHz. These are needed for small LCDs (e.g. 320x240). Also inserts some intermediate steps between pre-existing frequencies. The problem was the insertion of intermediate steps into the frequency table; they would cause the wrong frequency to be matched. This patch drops those intermediate frequencies while keeping the sub-25MHz frequencies. Signed-off-by:
Andres Salomon <dilinger@debian.org> Signed-off-by:
Jens Rottmann <JRottmann@LiPPERT-AT.de> Tested-by:
Jordan Crouse <jordan.crouse@amd.com> Signed-off-by:
-
Eric Dumazet authored
Alignment was previously requested because cpu_buffer was an [NR_CPUS] array, to avoid cache line sharing between CPUS. After commit 608dfddd (oprofile: change cpu_buffer from array to per_cpu variable ), we dont need to force an alignement anymore since cpu_buffer sits in per_cpu zone. Signed-off-by:
-
Sebastian Siewior authored
Schedule a removal for this driver. Alternative driver is available for a while now. Signed-off-by:
Sebastian Siewior <bigeasy@linutronix.de> Acked-by:
Greg Ungerer <gerg@uclinux.org> Acked-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Grant Likely authored
Signed-off-by:
Grant Likely <grant.likely@secretlab.ca> Acked-by:
David Brownell <david-b@pacbell.net> Signed-off-by:
-
Eric Van Hensbergen authored
There was some cleanup issues during early mount which would trigger a kernel bug for certain types of failure. This patch reorganizes the cleanup to get rid of the bad behavior. This also merges the 9pnet and 9pnet_fd modules for the purpose of configuration and initialization. Keeping the fd transport separate from the core 9pnet code seemed like a good idea at the time, but in practice has caused more harm and confusion than good. Signed-off-by:Eric Van Hensbergen <ericvh@gmail.com>
-
