- May 17, 2006
-
-
Nicolas Pitre authored
... otherwise xip_enable() won't do the right thing. Signed-off-by:
Nicolas Pitre <nico@cam.org> Signed-off-by:
David Woodhouse <dwmw2@infradead.org>
-
Josh Boyer authored
The patch below fixes a potential starvation issue that can arise when there is contention on a chip during a period when a process is currently writing to it. The starvation is avoided by conditionally rescheduling when the chip is left in a state usable by other processes. Signed-off-by:
Josh Boyer <jdub@us.ibm.com> Signed-off-by:
Tom Gall <tom_gall@vnet.ibm.com> Signed-off-by:
-
David Woodhouse authored
We have to pack at least the jint16_t structure, because otherwise it'll be four bytes in size. Thankfully, we can do that and _not_ pack the actual node structures, and the compiler still doesn't emit stupid code. Signed-off-by: -
Sergei Shtylyov authored
On AMD Au1550 the static bus controller fails to keep -CE asserted during chip ready delay on read commands and the NAND chip being used requires this. So, the current driver allows nand_base.c to drive -CE manually during the entire sector read. When the PCMCIA driver is enabled however, occasionally the ECC errors occur on NAND reads. This happens because the PCMCIA driver polls sockets periodically and reads one of the board's control/status regs (BCSRs) which are on the same static bus as the NAND flash, and just use another chip select (and the NOR flash also resides on that bus), so as the NAND driver forces NAND chip select asserted and the -RE signal is shared, a contention occurs on the static bus when BCSR or NOR flash is read while we're reading from NAND. So, we either can't keep interrupts enabled during the whole NAND sector read (which is hardly acceptable), or have to implement some interlocking scheme between multiple drivers (which is painful, and makes me shudder :-). There's a third way which has proven to work: to force -CE asserted only while we're waiting for a NAND chip to become ready after a read command, disabling interrupts for a maximum of 25 microseconds (according to Toshiba TC58DVM92A1FT00 datasheet -- this chip is mentioned in the board schematics); for Samsung NAND chip which seems to be actually used this delay is even less, 12 us. Signed-off-by:Konstantin Baydarov <kbaidarov@ru.mvista.com> Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
-
Ben Dooks authored
Fix build warnings from drivers/mtd/redboot.c due to use of `unsigned long` in `struct fis_image_desc` for fields being passed to swab32s() which expects __u32 * Change the entries to uint32_t to make them compatible with the swab32s() function Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Signed-off-by:
-
Sergei Shtylyov authored
During the last cleanup of the AMD Au1550 NAND driver the old buglet was reintroduced: as the MEM_STNDCTL register is write-only and seem to always read as 0x31, read-modify-write to it done in au1xxx_nand_init() will have the side effect of enabling -RCS0/1 pin override (via bits 4/5 of this reg.), thus possibly causing a contention on the static bus when the NOR flash (using -RCS0) or board control status registers (using -RCS2) are read. Luckily, this goes away with a first NAND access, since au1550_hwcontrol() doesn't try to read this register before writing anymore. Signed-off-by: -
David Woodhouse authored
fs/jffs2/summary.c: In function ‘jffs2_sum_write_data’: fs/jffs2/summary.c:658: warning: format ‘%zd’ expects type ‘signed size_t’, but argument 4 has type ‘uint32_t’ Signed-off-by:
-
- May 16, 2006
-
-
David Brownell authored
Mark certain functions with __init and __exit appropriately. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
David Woodhouse authored
We all inherited the same error from the original NAND board driver which got copied and changed. Fix them all at once... Signed-off-by: -
Adrian Bunk authored
On Mon, May 15, 2006 at 12:56:37AM -0700, Andrew Morton wrote: >... > Changes since 2.6.17-rc3-mm1: >... > git-mtd.patch >... > git trees >... If we correct the names of the config options, the code might actually work as intended... Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
David Woodhouse authored
Signed-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6David Woodhouse authored
Signed-off-by: -
Florin Malita authored
If jffs2_scan_eraseblock() fails and the exit path is taken, 's' is not being deallocated. Reported by Coverity, CID: 1258. Signed-off-by:
Florin Malita <fmalita@gmail.com> Signed-off-by:
-
Andrew Morton authored
On alpha: drivers/net/dl2k.c: In function `rio_free_tx': drivers/net/dl2k.c:768: error: `DMA_48BIT_MASK' undeclared (first use in this function) drivers/net/dl2k.c:768: error: (Each undeclared identifier is reported only once drivers/net/dl2k.c:768: error: for each function it appears in.) drivers/net/dl2k.c: In function `receive_packet': drivers/net/dl2k.c:896: error: `DMA_48BIT_MASK' undeclared (first use in this function) drivers/net/dl2k.c: In function `rio_close': drivers/net/dl2k.c:1803: error: `DMA_48BIT_MASK' undeclared (first use in this function) Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Andrew Morton authored
fs/jffs2/nodelist.c: In function `check_node_data': fs/jffs2/nodelist.c:441: warning: unsigned int format, different type arg (arg 4) fs/jffs2/nodelist.c:464: warning: int format, different type arg (arg 5) Signed-off-by:
-
Peter Osterlund authored
Changing the driver to use dynamic device numbers was one of the many changes that were made in order to have the driver accepted into the mainline kernel. Therefore I would say that the entry in devices.txt is obsolete. This patch removes it. Signed-off-by:
Peter Osterlund <petero2@telia.com> Cc: Torben Mathiasen <device@lanana.org> Signed-off-by:
-
Thomas Kleffel authored
Add the IBM microdrive to the known PCMCIA IDs for ide_cs. Signed-off-by:
Thomas Kleffel <tk@maintech.de> Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
-
Aneesh Kumar authored
Fix some typos in Documentation/memory-barriers.txt Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@gmail.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Cc: Hansjoerg Lipp <hjlipp@web.de> Cc: Tilman Schmidt <tilman@imap.cc> Signed-off-by:
-
Pavel Machek authored
HOTPLUG_CPU entry says "Say Y..." then "Say N.". Slightly ugly, so I fixed it up, and added remark about suspend on SMP as a bonus. Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Carl-Daniel Hailfinger authored
Do not enable the SMBus device on Asus boards if suspend is used. We do not reenable the device on resume, leading to all sorts of undesirable effects, the worst being a total fan failure after resume on Samsung P35 laptop. Signed-off-by:
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Signed-off-by:
-
Andrew Morton authored
Revert commit f6422f17 , due to Valdis.Kletnieks@vt.edu wrote: > > There seems to have been a bug introduced in this changeset: > > Am running 2.6.17-rc3-mm1. When this changeset is applied, 'mount --bind' > misbehaves: > > > # mkdir /foo > > # mount -t tmpfs -o rw,nosuid,nodev,noexec,noatime,nodiratime none /foo > > # mkdir /foo/bar > > # mount --bind /foo/bar /foo > > # tail -2 /proc/mounts > > none /foo tmpfs rw,nosuid,nodev,noexec,noatime,nodiratime 0 0 > > none /foo tmpfs rw 0 0 > > Reverting this changeset causes both mounts to have the same options. > > (Thanks to Stephen Smalley for tracking down the changeset...) > Cc: Herbert Poetzl <herbert@13thfloor.at> Cc: Christoph Hellwig <hch@infradead.org> Cc: <Valdis.Kletnieks@vt.edu> Cc: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by:
-
Andy Whitcroft authored
When we fail to mount from a valid root device list out the filesystems we have tried to mount it with. This gives the user vital diagnostics as to what is missing from their kernel. For example in the fragment below the kernel does not have CRAMFS compiled into the kernel and yet appears to recognise it at the RAMDISK detect stage. Later the mount fails as we don't have the filesystem. RAMDISK: cramfs filesystem found at block 0 RAMDISK: Loading 1604KiB [1 disk] into ram disk... done. XFS: bad magic number XFS: SB validate failed No filesystem could mount root, tried: reiserfs ext3 ext2 msdos vfat iso9660 jfs xfs Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1) Signed-off-by:Andy Whitcroft <apw@shadowen.org> Signed-off-by:
-
Alexey Dobriyan authored
Mentioned by Mark Armbrust somewhere on Usenet. Signed-off-by:
-
Daniel Walker authored
drivers/char/tpm/tpm.c: In function 'tpm_register_hardware': drivers/char/tpm/tpm.c:1157: warning: assignment from incompatible pointer type Signed-off-by:
Daniel Walker <dwalker@mvista.com> Acked-by:
Kylene Hall <kjhall@us.ibm.com> Signed-off-by:
-
Alan Cox authored
Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Kylene Jo Hall authored
Fix the constant used for the base address when it cannot be determined from ACPI. It was off by one order of magnitude. Signed-off-by:
-
Benjamin LaHaise authored
Add support to oprofile for the Intel Core Solo and Core Duo processors. See also the patch to add support to oprofile-0.9.1-8.1.1 at http://www.kvack.org/~bcrl/patches/oprofile/oprofile-core-0.9.1.diff . Signed-off-by:
Benjamin LaHaise <benjamin.c.lahaise@intel.com> Cc: Philippe Elie <phil.el@wanadoo.fr> Cc: John Levon <levon@movementarian.org> Cc: <stable@kernel.org> Signed-off-by:
-
Hua Zhong authored
can_share_swap_page() is used to check if the page has the last reference. This avoids allocating a new page for COW if it's the last page. However, if CONFIG_SWAP is not set, can_share_swap_page() is defined as 0, thus always causes a copy for the last COW page. The below simple patch fixes it. Signed-off-by:
Hua Zhong <hzhong@gmail.com> Cc: David Howells <dhowells@redhat.com> Cc: Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Latchesar Ionkov authored
Multiple races can happen when v9fs is interrupted by a signal and Tflush message is sent to the server. After v9fs sends Tflush it doesn't wait until it receives Rflush, and possibly the response of the original message. This behavior may confuse v9fs what fids are allocated by the file server. This patch fixes the races and the fid allocation. Signed-off-by:
Latchesar Ionkov <lucho@ionkov.net> Cc: Eric Van Hensbergen <ericvh@hera.kernel.org> Signed-off-by:
-
Latchesar Ionkov authored
v9fs leaks memory if the file server responds with Rerror to a Twalk message. The patch fixes the leak. Signed-off-by:
-
Richard Purdie authored
Fix the error handling of some LED _store functions. This corrects them to return -EINVAL if the value is not numeric with an optional byte of trailing whitespace. Signed-off-by:
Richard Purdie <rpurdie@rpsys.net> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Richard Purdie authored
Add a MAINTAINERS entry for the LED subsystem. Signed-off-by:
-
Richard Purdie authored
The backlight and LCD class _store functions currently accept values like "34 some random strings" without error. This corrects them to return -EINVAL if the value is not numeric with an optional byte of trailing whitespace. Signed-off-by:
-
Richard Purdie authored
Improve the NEW_LEDS Kconfig information to say what it does as well as what it doesn't. Signed-off-by:
-
Mike Kravetz authored
slab_is_available() indicates slab based allocators are available for use. SPARSEMEM code needs to know this as it can be called at various times during the boot process. Signed-off-by:
Mike Kravetz <kravetz@us.ibm.com> Signed-off-by:
-
Jan Niehusmann authored
Yesterday, I got the following error with 2.6.16.13 during a file copy from a smb filesystem over a wireless link. I guess there was some error on the wireless link, which in turn caused an error condition for the smb filesystem. In the log, smb_file_read reports error=4294966784 (0xfffffe00), which also shows up in the slab dumps, and also is -ERESTARTSYS. Error code 27499 corresponds to 0x6b6b, so the rq_errno field seems to be the only one being set after freeing the slab. In smb_add_request (which is the only place in smbfs where I found ERESTARTSYS), I found the following: if (!timeleft || signal_pending(current)) { /* * On timeout or on interrupt we want to try and remove the * request from the recvq/xmitq. */ smb_lock_server(server); if (!(req->rq_flags & SMB_REQ_RECEIVED)) { list_del_init(&req->rq_queue); smb_rput(req); } smb_unlock_server(server); } [...] if (signal_pending(current)) req->rq_errno = -ERESTARTSYS; I guess that some codepath like smbiod_flush() caused the request to be removed from the queue, and smb_rput(req) be called, without SMB_REQ_RECEIVED being set. This violates an asumption made by the quoted code. Then, the above code calls smb_rput(req) again, the req gets freed, and req->rq_errno = -ERESTARTSYS writes into the already freed slab. As list_del_init doesn't cause an error if called multiple times, that does cause the observed behaviour (freed slab with rq_errno=-ERESTARTSYS). If this observation is correct, the following patch should fix it. I wonder why the smb code uses list_del_init everywhere - using list_del instead would catch such situations by poisoning the next and prev pointers. May 4 23:29:21 knautsch kernel: [17180085.456000] ipw2200: Firmware error detected. Restarting. May 4 23:29:21 knautsch kernel: [17180085.456000] ipw2200: Sysfs 'error' log captured. May 4 23:33:02 knautsch kernel: [17180306.316000] ipw2200: Firmware error detected. Restarting. May 4 23:33:02 knautsch kernel: [17180306.316000] ipw2200: Sysfs 'error' log already exists. May 4 23:33:02 knautsch kernel: [17180306.968000] smb_file_read: //some_file validation failed, error=4294966784 May 4 23:34:18 knautsch kernel: [17180383.256000] smb_file_read: //some_file validation failed, error=4294966784 May 4 23:34:18 knautsch kernel: [17180383.284000] SMB connection re-established (-5) May 4 23:37:19 knautsch kernel: [17180563.956000] smb_file_read: //some_file validation failed, error=4294966784 May 4 23:40:09 knautsch kernel: [17180733.636000] smb_file_read: //some_file validation failed, error=4294966784 May 4 23:40:26 knautsch kernel: [17180750.700000] smb_file_read: //some_file validation failed, error=4294966784 May 4 23:43:02 knautsch kernel: [17180907.304000] smb_file_read: //some_file validation failed, error=4294966784 May 4 23:43:08 knautsch kernel: [17180912.324000] smb_file_read: //some_file validation failed, error=4294966784 May 4 23:43:34 knautsch kernel: [17180938.416000] smb_errno: class Unknown, code 27499 from command 0x6b May 4 23:43:34 knautsch kernel: [17180938.416000] Slab corruption: start=c4ebe09c, len=244 May 4 23:43:34 knautsch kernel: [17180938.416000] Redzone: 0x5a2cf071/0x5a2cf071. May 4 23:43:34 knautsch kernel: [17180938.416000] Last user: [<e087b903>](smb_rput+0x53/0x90 [smbfs]) May 4 23:43:34 knautsch kernel: [17180938.416000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b May 4 23:43:34 knautsch kernel: [17180938.416000] 0f0: 00 fe ff ff May 4 23:43:34 knautsch kernel: [17180938.416000] Next obj: start=c4ebe19c, len=244 May 4 23:43:34 knautsch kernel: [17180938.416000] Redzone: 0x5a2cf071/0x5a2cf071. May 4 23:43:34 knautsch kernel: [17180938.416000] Last user: [<00000000>](_stext+0x3feffde0/0x30) May 4 23:43:34 knautsch kernel: [17180938.416000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b May 4 23:43:34 knautsch kernel: [17180938.416000] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b May 4 23:43:34 knautsch kernel: [17180938.460000] SMB connection re-established (-5) May 4 23:43:42 knautsch kernel: [17180946.292000] ipw2200: Firmware error detected. Restarting. May 4 23:43:42 knautsch kernel: [17180946.292000] ipw2200: Sysfs 'error' log already exists. May 4 23:45:04 knautsch kernel: [17181028.752000] ipw2200: Firmware error detected. Restarting. May 4 23:45:04 knautsch kernel: [17181028.752000] ipw2200: Sysfs 'error' log already exists. May 4 23:45:05 knautsch kernel: [17181029.868000] smb_file_read: //some_file validation failed, error=4294966784 May 4 23:45:36 knautsch kernel: [17181060.984000] smb_errno: class Unknown, code 27499 from command 0x6b May 4 23:45:36 knautsch kernel: [17181060.984000] Slab corruption: start=c4ebe09c, len=244 May 4 23:45:36 knautsch kernel: [17181060.984000] Redzone: 0x5a2cf071/0x5a2cf071. May 4 23:45:36 knautsch kernel: [17181060.984000] Last user: [<e087b903>](smb_rput+0x53/0x90 [smbfs]) May 4 23:45:36 knautsch kernel: [17181060.984000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b May 4 23:45:36 knautsch kernel: [17181060.984000] 0f0: 00 fe ff ff May 4 23:45:36 knautsch kernel: [17181060.984000] Next obj: start=c4ebe19c, len=244 May 4 23:45:36 knautsch kernel: [17181060.984000] Redzone: 0x5a2cf071/0x5a2cf071. May 4 23:45:36 knautsch kernel: [17181060.984000] Last user: [<00000000>](_stext+0x3feffde0/0x30) May 4 23:45:36 knautsch kernel: [17181060.984000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b May 4 23:45:36 knautsch kernel: [17181060.984000] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b May 4 23:45:36 knautsch kernel: [17181061.024000] SMB connection re-established (-5) May 4 23:46:17 knautsch kernel: [17181102.132000] smb_file_read: //some_file validation failed, error=4294966784 May 4 23:47:46 knautsch kernel: [17181190.468000] smb_errno: class Unknown, code 27499 from command 0x6b May 4 23:47:46 knautsch kernel: [17181190.468000] Slab corruption: start=c4ebe09c, len=244 May 4 23:47:46 knautsch kernel: [17181190.468000] Redzone: 0x5a2cf071/0x5a2cf071. May 4 23:47:46 knautsch kernel: [17181190.468000] Last user: [<e087b903>](smb_rput+0x53/0x90 [smbfs]) May 4 23:47:46 knautsch kernel: [17181190.468000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b May 4 23:47:46 knautsch kernel: [17181190.468000] 0f0: 00 fe ff ff May 4 23:47:46 knautsch kernel: [17181190.468000] Next obj: start=c4ebe19c, len=244 May 4 23:47:46 knautsch kernel: [17181190.468000] Redzone: 0x5a2cf071/0x5a2cf071. May 4 23:47:46 knautsch kernel: [17181190.468000] Last user: [<00000000>](_stext+0x3feffde0/0x30) May 4 23:47:46 knautsch kernel: [17181190.468000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b May 4 23:47:46 knautsch kernel: [17181190.468000] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b May 4 23:47:46 knautsch kernel: [17181190.492000] SMB connection re-established (-5) May 4 23:49:20 knautsch kernel: [17181284.828000] smb_file_read: //some_file validation failed, error=4294966784 May 4 23:49:39 knautsch kernel: [17181303.896000] smb_file_read: //some_file validation failed, error=4294966784 Signed-off-by:Jan Niehusmann <jan@gondor.com> Cc: <stable@kernel.org> Signed-off-by:
-
Marcelo Tosatti authored
Signed-off-by:
Marcelo Tosatti <marcelo@kvack.org> Signed-off-by:
-
Trent Piepho authored
Even since a previous patch: Fix race between CONFIG_DEBUG_SLABALLOC and modules Sun, 27 Jun 2004 17:55:19 +0000 (17:55 +0000) http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commit;h=92b3db26d31cf21b70e3c1eadc56c179506d8fbe The function symbol_put_addr() will deadlock the kernel. symbol_put_addr() would acquire modlist_lock, then while holding the lock call two functions kernel_text_address() and module_text_address() which also try to acquire the same lock. This deadlocks the kernel of course. This patch changes symbol_put_addr() to not acquire the modlist_lock, it doesn't need it since it never looks at the module list directly. Also, it now uses core_kernel_text() instead of kernel_text_address(). The latter has an additional check for addr inside a module, but we don't need to do that since we call module_text_address() (the same function kernel_text_address uses) ourselves. Signed-off-by:
Trent Piepho <xyzzy@speakeasy.org> Cc: Zwane Mwaikambo <zwane@fsmlabs.com> Acked-by:
Rusty Russell <rusty@rustcorp.com.au> Cc: Johannes Stezenbach <js@linuxtv.org> Signed-off-by:
-
Martin Schwidefsky authored
Add new vmsplice system call and add missing __NR_xxx defines for sys_set_robust_list, sys_get_robust_list, sys_splice, sys_sync_file_range and sys_tee. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
