- 19 Nov, 2004 34 commits
-
-
Andrea Arcangeli authored
mempolicy.c code will return the wrong policy in some cases. Signed-off-by: Andrea Arcangeli <andrea@novell.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andrea Arcangeli authored
With the inline symlink shmem_inode_info structure is overwritten with data until vfs_inode, and that caused the ->policy to be a corrupted pointer during unlink. It wasn't immediatly easy to see what was going on due the random mm corruption that generated a weird oops, it looked more like a race condition on freed memory at first. There's simply no need to set a policy for inodes, since the idx is always zero. All we have to do is to initialize the data structure (the semaphore may need to run during the page allocation for the non-inline symlink) but we don't need to allocate the rb nodes. This way we don't need to call mpol_free during the destroy_inode (not doable at all if the policy rbtree is corrupt by the inline symlink ;). An equivalent version of this patch based on a 2.6.5 tree with additional numa features on top of this (i.e. interleaved by default, and that's prompted me to add a comment in the LNK init path), works fine in a numa simulation on my laptop (untested on the bare hardware). Signed-off-by: Andrea Arcangeli <andrea@novell.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Hirokazu Takata authored
The modification of "Changes for arch/m32r/mm/fault.c@1.3" was prepared for enforce-a-gap-between-heap-and-stack.patch(*) of -mm tree, but it has not been merged into mainline. (*) "heap-stack-gap for 2.6" (Sep. 25, 2004) http://www.uwsg.iu.edu/hypermail/linux/kernel/0409.3/0435.html So, this patch is for withdrawing the previous arch/m32r/mm/fault.c. Signed-off-by: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
William Lee Irwin III authored
Stomp a couple of warnings which several people have tried to fix. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Russell King authored
The following patch fixes these build errors on machines with CONFIG_PCI=n: drivers/parport/parport_pc.c:3199: error: `parport_init_mode' undeclared (first use in this function) drivers/parport/parport_pc.c:3199: error: (Each undeclared identifier is reported only once drivers/parport/parport_pc.c:3199: error: for each function it appears in.) Signed-off-by: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Stephen Rothwell authored
It appears that the PURR emulation patch was the victim of the renaming of a structure element. The current BK kernel will not build for iSeries without this patch. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Ingo Molnar authored
PREEMPT_RT on SMP systems triggered weird (very high) load average values rather easily, which turned out to be a mainline kernel ->nr_uninterruptible handling bug in try_to_wake_up(). the following code: if (old_state == TASK_UNINTERRUPTIBLE) { old_rq->nr_uninterruptible--; potentially executes with old_rq potentially being != rq, and hence updating ->nr_uninterruptible without the lock held. Given a sufficiently concurrent preemption workload the count can get out of whack and updates might get lost, permanently skewing the global count. Nothing except the load-average uses nr_uninterruptible() so this condition can go unnoticed quite easily. the fix is to update ->nr_uninterruptible always on the runqueue where the task currently is. (this is also a tiny performance plus for try_to_wake_up() as a stackslot gets freed up.) while fixing this bug i found three other ->nr_uninterruptible related bugs: - the update should be moved from deactivate_task() into schedule(), beacause e.g. setscheduler() does deactivate_task()+activate_task(), which in turn may result in a -1 counter-skew if setscheduler() is done on a task asynchronously, which task is still on the runqueue but has already set ->state to TASK_UNINTERRUPTIBLE. sys_sched_setscheduler() is used rarely, but the bug is real. (The fix is also a small performance enhancement.) The rules for ->nr_uninterruptible updating are the following: it gets increased by schedule() only, when a task is moved off the runqueue and it has a state of TASK_UNINTERRUPTIBLE. It is decreased by try_to_wake_up(), by the first wakeup that materially changes the state from TASK_UNINTERRUPTIBLE back to TASK_RUNNING, and moves the task to the runqueue. - on CPU-hotplug down we might zap a CPU that has a nonzero counter. Due to the fuzzy nature of the global counter a CPU might hold a nonzero ->nr_uninterruptible count even if it has no tasks anymore. The solution is to 'migrate' the counter to another runqueue. - we should not return negative counter values from the nr_uninterruptible() function, since it accesses them without taking the runqueue locks, so the total sum might be slightly above or slightly below the real count. I tested the attached patch on x86 SMP and it solves the load-average problem. (I have tested CPU_HOTPLUG compilation but not functionality.) I think this is a must-have for 2.6.10, because there are apps that go berzerk if load-average is too high (e.g. sendmail). Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
bk://kernel.bkbits.net/gregkh/linux/i2c-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
bk://kernel.bkbits.net/gregkh/linux/pci-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
bk://kernel.bkbits.net/gregkh/linux/usb-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Jeff Mahoney authored
If security_load_policy() fails on the first try, the cache is never cleaned up. When the policy is fixed and a reload is attempted, the old cache will still exist, causing a BUG() in kmem_cache_create(). This patch adds a destroy operation to clean up the cache on failure. Signed-off-by: Jeff Mahoney <jeffm@novell.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
bk://kernel.bkbits.net/gregkh/linux/driver-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Andi Kleen authored
Fix async IPI to not return before stack data is used. This can fix reboot crashes and apparently helps vmware. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Rolf Eike Beer authored
Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Randy Dunlap authored
drivers/pci/hotplug/cpcihp_generic.c:214: warning: return from incompatible pointer type Signed-off-by: Randy Dunlap <rddunlap@osdl.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Rolf Eike Beer authored
this patch improves rpaphp_find_pci_dev. First it uses the for_each_pci_dev macro instead of the while loop, making this hotplug safe (which is a good idea in a hotplug driver, isn't it?). Then it removes retval_dev. retval_dev is set to the found device when something is found, NULL otherwise. If nothing is found dev will be NULL at the end of the loop anyway and the found device if we found something, no need for retval_dev then. And a very small coding style fix. Signed-off-by: Rolf Eike Beer <eike-hotplug@sf-tec.de> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Adrian Bunk authored
Remove unused the drivers/pci/hotplug/pciehp_sysfs.c Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Matthew Dharm authored
This patch started as as405 from Alan Stern. It has been re-generated against the current tip of the BK tree. For quite a while we've had a bunch of state-transition testing code in the driver, to report if anything bad ever happens (like the SCSI midlayer trying to queue a second command before the first one finishes). None of those tests triggered in a very long time; this aspect of the code appears to be extremely stable. So this patch removes all those tests for illegal values of us->sm_state. It turns out that sm_state was used only for one other purpose: to check whether a command had timed out and caused a SCSI abort. That piece of information can easily be stored in a single new bitflag (which is called calling US_FLIDX_TIMED_OUT) and doing so makes us->sm_state completely unused. Hence the patch removes it from the structure. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Matthew Dharm authored
This is patch as399, originally from Alan Stern. A recent change to the scsi_probe_lun() routine now allows host drivers to specify a device's INQUIRY length in a way that cannot be overridden by the value returned from the device. This patch makes usb-storage set the length to 36; now buggy devices won't be able to cause trouble by saying that they have 37 bytes of INQUIRY data available. The only way this value could be changed is if someone creates a SCSI blacklist entry with the BLIST_INQUIRY_58 flag -- and no one would do that for a USB device (I hope)! Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Matthew Dharm authored
This was originally patch as401 from Alan Stern. This patch makes a couple of small changes to the new scanning thread. It changes the name to "usb-stor-scan", which was my original intention and makes more sense than the current name. It also removes the PF_NOFREEZE flag; if someone suspends their system immediately after plugging in a USB storage device then the scanning thread should be frozen along with everything else. The delay will be restarted after the system wakes up. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Masaki Chikama authored
Add device ID to pl2303 usb serial driver for 1) I/O DATA USB-RSAQ3 2) ELECOM UC-SGT Signed-off-by: CHIKAMA Masaki <masaki-c@nict.go.jp> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Phil Dibowitz authored
Here's another unusual_devs entry for the Tekom/Yakumo devices. While I was there I realized two of the tekom entries were out of order, so I fixed that as well. From: Paul Ortyl <ortylp@3miasto.net> Signed-off-by: Phil Dibowitz <phil@ipom.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
David Eriksson authored
This patch for ipaq.h and ipaq.c in drivers/usb/serial/ has the following features: o Provides an updated table with all vendor/product IDs (except one [1]) present in Microsoft ActiveSync 3.7.1, the latest version available for download. o Removes #defines with vendor and product IDs from ipaq.h [2] The table has been autogenerated from the file wceusbsh.inf (extracted from MSASYNC.EXE with cabextract). The scripts used to generate the table become available for download as part of the SynCE project (http://synce.sourceforge.net). [1] Vendor 0x45e (Microsoft) with device 0xCE is not included, because they are used when the device is turned off but still connected to the PC via USB. When the device is turned on, it changes vendor/product IDs to the more specific ones. [2] Not needed with an autogenerated device table Signed-off-by: David Eriksson <twogood@users.sourceforge.net> Signed-off-by: Ganesh Varadarajan <ganesh@veritas.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Roger Luethi authored
generic_startup in visor.c was not called for some hardware, resulting in attempts to access memory that had never been allocated, which in turn caused the problem several people reported with recent (2.6.10ish) kernels. Signed-off-by: Roger Luethi <rl@hellgate.ch> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Paulo Marques authored
The attached patch fixes a bug introduced by myself (a brown paper bag one) when I posted the patch that introduced this same PID to the id_table_FT232BM array only and not the id_table_combined array. Signed-off-by: Paulo Marques <pmarques@grupopie.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Petko Manolov authored
big-endian related fixes; Signed-off-by: Petko Manolov <petkan@nucleusys.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Daniel Ritz authored
add some help text for touchkitusb. the howto there should also work for mtouchusb and other touchscreens using the input layer. Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Thomas Leibold authored
This is the all new and improved version of the patch: - following the advise from Jean Delvare I removed the redundant definition of the PCI IDs from the driver and just add them to the pci_ids.h file. - the patch is now created against linux 2.6.10-RC2. Signed-off-by: Thomas Leibold <thomas@plx.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Gabriel Paubert authored
It seems so. BTW I hate wrong comments and happened to add one in my patch. To fix my blunder, can you apply the appended one line removal on top of Jean's patch. Signed-off-by: Gabriel Paubert <paubert@iram.es> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Jean Delvare authored
This patch cleans up the recent removal of smbus functions proposed by Arjan and then fixed by Gabriel. Changes are as follow: 1* Discard i2c_smbus_block_process_call, as it isn't used anywhere either. I guess that Arjan missed it because it wasn't exported. 2* Document the functions removal, so that people have at least an idea that the functions can be restored later if needed. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Jean Delvare authored
While working on the 2.4 version of the i2c-amd756-s4882 driver, I noticed a few quirks on the 2.6 version I sent to you. The following patch attempts to fix them. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Jean Delvare authored
While verifying my stack of patches against what you sent to Linus last week, I noticed this one. Looks like I simply forgot to send it to you, as I cannot find any trace of it in the lm_sensors mailing-list archives. The patch prevents an smsc47m1 device from being registered when no monitoring function is actually active within the chip. See this ticket for background: http://secure.netroedge.com/~lm78/readticket.cgi?ticket=1801 This is certainly better to explicitely fail in this case than leave the user with an empty sysfs directory (except for alarms), which tends to make him/her think of a driver bug, which it isn't (what it really is is a BIOS brokenness). Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Maneesh Soni authored
The following patch should avoid the sysfs_remove_dir() oops you are seeing while device removal. It anyway fixes the obvious error and is needed. But it will not make any change to the first error you are seeing while connecting the device. o Following patch avoids the sysfs_remove_dir() oops when it is passed a kobject with NULL dentry. Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Andrew Morton authored
From: Gerd Knorr <kraxel@bytesex.org> It uses the varargs list twice in a illegal way. That doesn't harm on i386 by pure luck, but blows things up on amd64 machines. Using var args list twice without calling va_start twice is illegal. Signed-off-by: Gerd Knorr <kraxel@bytesex.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
- 18 Nov, 2004 6 commits
-
-
bk://bk.arm.linux.org.uk/linux-2.6-rmkLinus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Deepak Saxena authored
Patch from Deepak Saxena One of the problems I have seen with several bootloaders is that they forget to disable network devices before jumping into the kernel and we end up with kernel text being overwritten by random data before the in-kernel driver resets the devices. This patch adds a blurb to the ARM Bootloader documentation reminding developers to quiesce all DMA capable devices before executing the kernel. Signed-off-by: Deepak Saxena Signed-off-by: Russell King
-
Deepak Saxena authored
Patch from Deepak Saxena Patch from Lennert Buytenhek Signed-off-by: Lennert Buytenhek Signed-off-by: Deepak Saxena Signed-off-by: Russell King
-
Deepak Saxena authored
Patch from Deepak Saxena Signed-off-by: Deepak Saxena Signed-off-by: Russell King
-
Deepak Saxena authored
Patch from Deepak Saxena There seems to be a typo that has creeped into include/asm/arch-ixp4xx/ixp4xx-regs.h. IXP4XX_EXP_CFG_BASE_VIRT and IXP4XX_PCI_CFG_BASE_VIRT were both defined to the same value. The patch changes PCI_CFG_BASE_VIRT to the value in the memory map comment. Signed-off-by: Deepak Saxena Signed-off-by: Russell King
-
Deepak Saxena authored
Patch from Deepak Saxena The IXP4xx PCI config cycle routines currently virtualize accesses to device 0:0 to map to the host bridge itself. This is technically incorrect b/c on certain boards we have an actual device wired to 0:0 and the existing code will not see these. Signed-off-by: Deepak Saxena Signed-off-by: Russell King
-