- 17 Feb, 2007 27 commits
-
-
Kyle McMartin authored
Signed-off-by:Kyle McMartin <kyle@parisc-linux.org>
-
Kyle McMartin authored
Signed-off-by: -
Kyle McMartin authored
Signed-off-by: -
Helge Deller authored
Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Kyle McMartin authored
And unmask the pselect6/ppoll system calls. Signed-off-by: -
Helge Deller authored
Signed-off-by:
-
Helge Deller authored
And remove it's reference in time.c. Allow lcd_print() to take a const char *. Signed-off-by:
-
Helge Deller authored
Signed-off-by:
-
Helge Deller authored
Signed-off-by:
-
Helge Deller authored
And clean up 32/64bit branch assembler statements Signed-off-by:
-
Kyle McMartin authored
Signed-off-by: -
Helge Deller authored
Signed-off-by:
-
Matthew Wilcox authored
Fix resource_size_t warnings in a variety of ways Signed-off-by:
Matthew Wilcox <matthew@wil.cx> Signed-off-by:
-
Helge Deller authored
Signed-off-by:
-
Helge Deller authored
Signed-off-by:
-
Helge Deller authored
Signed-off-by:
-
Helge Deller authored
Signed-off-by:
-
Helge Deller authored
Signed-off-by:
-
Helge Deller authored
Signed-off-by:
-
Matthew Wilcox authored
show_stack() was calling kzalloc() to allocate a struct pt_regs. This meant that *really* early stack dumps would cause a null pointer dereference. x86_64 allocates its pt_regs on the stack, so do the same. Kyle actually committed this exact patch to CVS on Wed Jul 26 14:32:39 2006 UTC, and never moved it across to git. Bad Kyle. Signed-off-by:
-
Matthew Wilcox authored
Al Viro did this for x86-64 and reduced the number of dependencies on sched.h significantly. We had a couple of files which were relying on uaccess.h pulling in sched.h, so they need explicit dependencies added. Signed-off-by:
-
Matthew Wilcox authored
They're called from signal.c, so need to be prototyped Signed-off-by:
-
Kyle McMartin authored
Use a really big hammer for the mean time to get things building again. Signed-off-by: -
Matthew Wilcox authored
going to change the bit. Signed-off-by:
-
Randolph Chung authored
No changes in functionality. Signed-off-by:
Randolph Chung <tausq@debian.org> Signed-off-by:
-
Randolph Chung authored
Signed-off-by:
-
Kyle McMartin authored
Conflicts: arch/parisc/hpux/sys_hpux.c arch/parisc/mm/ioremap.c
-
- 08 Feb, 2007 3 commits
-
-
Mike Frysinger authored
Use __u64 rather than u64 in the struct statfs64 exported to userspace. Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Cc: Kyle McMartin <kyle@mcmartin.ca> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Matthew Wilcox authored
parisc and parisc64 seem to name sections a little differently from other targets. parisc64 gives spurious warnings like: WARNING: drivers/net/dummy.o - Section mismatch: reference to .init.text:dummy_setup from .data.rel.ro between '.LC1' (at offset 0x0) and '.LC6' and parisc gives spurious warnings like: WARNING: drivers/net/dummy.o - Section mismatch: reference to .init.text:dummy_setup from .rodata.cst4 between '.LC1' (at offset 0x0) and '.LC6' Given the other comments in modpost.c, it seems that the best solution is to move rodata down to the 'match at start of name' section and add .data.rel.ro to the 'match entire name' section. Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Kyle McMartin <kyle@mcmartin.ca> Signed-off-by: -
Randy Dunlap authored
Fix/change module_param permissions parameter from an init value to a permission value. Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Matthew Wilcox <willy@debian.org> Signed-off-by:
-
- 04 Feb, 2007 3 commits
-
-
Linus Torvalds authored
-
Frédéric Riss authored
When calling into the EFI firmware, the parameters need to be passed on the stack. The recent change to use -mregparm=3 breaks x86 EFI support. This patch is needed to allow the new Intel-based Macs to suspend to ram (efi.get_time is called during the suspend phase). Signed-off-by:
Frederic Riss <frederic.riss@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Al Viro authored
That code doesn't do what its author apparently thought it would do... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
- 03 Feb, 2007 7 commits
-
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: [SCSI] sd: udev accessing an uninitialized scsi_disk field results in a crash [SCSI] st: A MTIOCTOP/MTWEOF within the early warning will cause the file number to be incorrect [SCSI] qla4xxx: bug fixes [SCSI] Fix scsi_add_device() for async scanning
-
Jeff Garzik authored
x86-64 is missing these: Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
John Keller authored
The SN Altix platform does not conform to the IOSAPIC IRQ routing model. Add code in acpi_unregister_gsi() to check if (acpi_irq_model == ACPI_IRQ_MODEL_PLATFORM) and return. Due to an oversight, this code was not added previously when similar code was added to acpi_register_gsi(). http://marc.theaimsgroup.com/?l=linux-acpi&m=116680983430121&w=2Signed-off-by:
John Keller <jpk@sgi.com> Acked-by:
Len Brown <lenb@kernel.org> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by:
-
Andrew Morton authored
Andrew Vasquez is reporting as-iosched oopses and a 65% throughput slowdown due to the recent special-casing of direct-io against blockdevs. We don't know why either of these things are occurring. The patch minimally reverts us back to the 2.6.19 code for a 2.6.20 release. Cc: Andrew Vasquez <andrew.vasquez@qlogic.com> Cc: Ken Chen <kenchen@google.com> Signed-off-by:
-
Mike Frysinger authored
We went and named them __NR_sys_foo instead of __NR_foo. It may be too late to change this, but we can at least add the proper names now. Signed-off-by:
-
Peter Korsgaard authored
smc911x_phy_configure's error handling unconditionally unlocks the spinlock even if it wasn't locked. Patch fixes it. Signed-off-by:
Peter Korsgaard <jacmet@sunsite.dk> Cc: Jeff Garzik <jeff@garzik.org> Cc: <stable@kernel.org> Signed-off-by:
-
Magnus Damm authored
This patch fixes up ia64 kexec support for HP rx2620 hardware. It does this by skipping migration of already disabled irqs. This is most likely a problem on other ia64 platforms as well, but I've only been able to reproduce it on one machine so far. The full story is that handle_bad_irq() gets invoked before starting the new kernel without this patch. This seems to happen when fixup_irqs() calls generic_handle_irq() on already migrated (and disabled) irqs. So by avoiding migration of disabled irqs we stay away of handle_bad_irq(). The code has been tested on three different ia64 machines, all with good results. It is possible to trigger the same bug by offlining a processor using echo 0 > /sys/devices/system/cpu/cpuX/online. More detailed information is available in the following mail thread: http://lists.osdl.org/pipermail/fastboot/2007-January/thread.html#5774Signed-off-by:
Magnus Damm <magnus@valinux.co.jp> Acked-by:
Simon Horman <horms@verge.net.au> Acked-by:
Zou, Nanhai <nanhai.zou@intel.com> Acked-by:
Jay Lan <jlan@sgi.com> Acked-by:
"Luck, Tony" <tony.luck@intel.com> Signed-off-by:
-
