The problem was introduced in 2.6.18.3 with the casting of some
36bit-defines (PCI memory) in au1000.h to resource_size_t which may be
u32 or u64 depending on the experimental CONFIG_RESOURCES_64BIT.
With unset CONFIG_RESOURCES_64BIT, the pci-memory cannot be accessed
because the ioremap in arch/mips/au1000/common/pci.c already used the
truncated addresses.
With set CONFIG_RESOURCES_64BIT, things get even worse, because PCI-scan
aborts, due to resource conflict: request_resource() in arch/mips/pci/pci.c
fails because the maximum iomem-address is 0xffffffff (32bit) but the
pci-memory-start-address is 0x440000000 (36bit).
To get pci working again, I propose the following patch:
1. remove the resource_size_t-casting from au1000.h again
2. make the casting in arch/mips/au1000/common/pci.c (it's allowed and
necessary here. The 36bit-handling will be done in __fixup_bigphys_addr).
With this patch pci works again like in 2.6.18.2, the gcc-compile warnings
in pci.c are gone and it doesn't depend on CONFIG_EXPERIMENTAL.
Signed-off-by: Alexander Bigga <ab@mycable.de>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The N32 and O32 pselect6 syscalls need to use compat_sys_pselect6 to
translate arguments from 32-bit to 64-bit layout.
Signed-off-by: Joseph Myers <joseph@codesourcery.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This patch adds LSM hooks into the setaffinity and getaffinity functions
for the mips architecture to enable security modules to control these
operations between tasks with different security attributes. This
implementation uses the existing task_setscheduler and task_getscheduler
LSM hooks.
Signed-Off-By: David Quigley <dpquigl@tycho.nsa.gov>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
CC arch/mips/au1000/pb1100/board_setup.o
arch/mips/au1000/pb1100/board_setup.c: In function ‘board_setup’:
arch/mips/au1000/pb1100/board_setup.c:104: warning: passing argument 1 of ‘readb’ makes pointer from integer without a cast
arch/mips/au1000/pb1100/board_setup.c:105: warning: passing argument 1 of ‘readb’ makes pointer from integer without a cast
arch/mips/au1000/pb1100/board_setup.c:105: warning: passing argument 2 of ‘writeb’ makes pointer from integer without a cast
arch/mips/au1000/pb1100/board_setup.c:109: warning: passing argument 1 of ‘readb’ makes pointer from integer without a cast
arch/mips/au1000/pb1100/board_setup.c:110: warning: passing argument 1 of ‘readb’ makes pointer from integer without a cast
arch/mips/au1000/pb1100/board_setup.c:110: warning: passing argument 2 of ‘writeb’ makes pointer from integer without a cast
arch/mips/au1000/pb1100/board_setup.c:51: warning: unused variable ‘sys_clksrc’
arch/mips/au1000/pb1100/board_setup.c:51: warning: unused variable ‘sys_freqctrl’
arch/mips/au1000/pb1100/board_setup.c:50: warning: unused variable ‘pin_func’
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
CC arch/mips/au1000/common/pci.o
arch/mips/au1000/common/pci.c:42: warning: large integer implicitly truncated to unsigned type
arch/mips/au1000/common/pci.c:43: warning: large integer implicitly truncated to unsigned type
arch/mips/au1000/common/pci.c:49: warning: large integer implicitly truncated to unsigned type
arch/mips/au1000/common/pci.c:50: warning: large integer implicitly truncated to unsigned type
arch/mips/au1000/common/pci.c: In function ‘au1x_pci_setup’:
arch/mips/au1000/common/pci.c:82: warning: ISO C90 forbids mixed declarations and code
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
early_serial_setup is only defined when CONFIG_SERIAL_8250 is set.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
pb1200/irqmap.c had been broken a while due to non-named initializer
and had missed some recent IRQ related changes. Apply these commits
to this file.
[MIPS] IRQ cleanups
commit 1603b5aca4
[MIPS] use generic_handle_irq, handle_level_irq, handle_percpu_irq
commit 1417836e81
[MIPS] Compile __do_IRQ() when really needed
commit e77c232cfc
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Given that the Makefiles involved already have conditional compilation of
the form:
obj-$(CONFIG_KGDB) += dbg_io.o
there seems to be little value for the dbg_io.c source files to check
that config variable yet again.
Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This get rid of some undesirable hole in BSS section due to random
order of placement.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The "typename" field was obsoleted by the "name" field.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Currently KEXEC is in "Machine selection", SECCOMP, PM, APM are in
"Executable file formats" menu. Move KEXEC and SECCOMP to "Kernel
type" and PM, APM to new "Power management options" menu. Also
replace "config PM" with kernel/power/Kconfig.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This patch has added MACINT controls.
They are necessary for VR4133 ethernet driver.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The old code was assuming that min_low_pfn was always 0. This
means that platforms having a big hole at their memory start
paid the price of wasting some memory for the allocation of
unused entries in mem_map[].
This patch prevents this waste.
It introduces PHYS_OFFSET define which is the start of the
physical memory and uses it wherever needed. Specially when
converting physical/virtual addresses into virtual/physical
ones.
Currently all platforms defines PHYS_OFFSET to 0.
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This patch makes a better usage of these two globals.
'min_low_pfn' is now correctly setup for all configs, which
allow us to rely on it in boot memory code init.
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The 32-bit version and 64-bit version are almost equal. Unify them.
This makes further improvements (for example, supporting CDEX, etc.)
easier.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Current prom_free_prom_memory() implementations are almost same as
free_init_pages(), or no-op. Make free_init_pages() extern (again)
and make prom_free_prom_memory() use it.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Move I8259A_IRQ_BASE from asm/i8259.h to asm/mach-generic/irq.h and
make it really customizable. And remove I8259_IRQ_BASE declared on
some platforms. Currently only NEC_CMBVR4133 is using custom
I8259A_IRQ_BASE value.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The irq_base for {mips,rm7k,rm9k}_cpu_irq_init() are constant on all
platforms and are same value on most platforms (0 or 16, depends on
CONFIG_I8259). Define them in asm-mips/mach-generic/irq.h and make
them customizable. This will save a few cycle on each CPU interrupt.
A good side effect is removing some dependencies to MALTA in generic
SMTC code.
Although MIPS_CPU_IRQ_BASE is customizable, this patch changes irq
mappings on DDB5477, EMMA2RH and MIPS_SIM, since really customizing
them might cause some header dependency problem and there seems no
good reason to customize it. So currently only VR41XX is using custom
MIPS_CPU_IRQ_BASE value, which is 0 regardless of CONFIG_I8259.
Testing this patch on those platforms is greatly appreciated. Thank
you.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
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>
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: Linus Torvalds <torvalds@linux-foundation.org>
* 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
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=2
Signed-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 <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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: Mike Frysinger <vapier@gentoo.org>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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#5774
Signed-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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
An AIO bug was reported that sleeping function is being called in softirq
context:
BUG: warning at kernel/mutex.c:132/__mutex_lock_common()
Call Trace:
[<a000000100577b00>] __mutex_lock_slowpath+0x640/0x6c0
[<a000000100577ba0>] mutex_lock+0x20/0x40
[<a0000001000a25b0>] flush_workqueue+0xb0/0x1a0
[<a00000010018c0c0>] __put_ioctx+0xc0/0x240
[<a00000010018d470>] aio_complete+0x2f0/0x420
[<a00000010019cc80>] finished_one_bio+0x200/0x2a0
[<a00000010019d1c0>] dio_bio_complete+0x1c0/0x200
[<a00000010019d260>] dio_bio_end_aio+0x60/0x80
[<a00000010014acd0>] bio_endio+0x110/0x1c0
[<a0000001002770e0>] __end_that_request_first+0x180/0xba0
[<a000000100277b90>] end_that_request_chunk+0x30/0x60
[<a0000002073c0c70>] scsi_end_request+0x50/0x300 [scsi_mod]
[<a0000002073c1240>] scsi_io_completion+0x200/0x8a0 [scsi_mod]
[<a0000002074729b0>] sd_rw_intr+0x330/0x860 [sd_mod]
[<a0000002073b3ac0>] scsi_finish_command+0x100/0x1c0 [scsi_mod]
[<a0000002073c2910>] scsi_softirq_done+0x230/0x300 [scsi_mod]
[<a000000100277d20>] blk_done_softirq+0x160/0x1c0
[<a000000100083e00>] __do_softirq+0x200/0x240
[<a000000100083eb0>] do_softirq+0x70/0xc0
See report: http://marc.theaimsgroup.com/?l=linux-kernel&m=116599593200888&w=2
flush_workqueue() is not allowed to be called in the softirq context.
However, aio_complete() called from I/O interrupt can potentially call
put_ioctx with last ref count on ioctx and triggers bug. It is simply
incorrect to perform ioctx freeing from aio_complete.
The bug is trigger-able from a race between io_destroy() and aio_complete().
A possible scenario:
cpu0 cpu1
io_destroy aio_complete
wait_for_all_aios { __aio_put_req
... ctx->reqs_active--;
if (!ctx->reqs_active)
return;
}
...
put_ioctx(ioctx)
put_ioctx(ctx);
__put_ioctx
bam! Bug trigger!
The real problem is that the condition check of ctx->reqs_active in
wait_for_all_aios() is incorrect that access to reqs_active is not
being properly protected by spin lock.
This patch adds that protective spin lock, and at the same time removes
all duplicate ref counting for each kiocb as reqs_active is already used
as a ref count for each active ioctx. This also ensures that buggy call
to flush_workqueue() in softirq context is eliminated.
Signed-off-by: "Ken Chen" <kenchen@google.com>
Cc: Zach Brown <zach.brown@oracle.com>
Cc: Suparna Bhattacharya <suparna@in.ibm.com>
Cc: Benjamin LaHaise <bcrl@kvack.org>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Cc: <stable@kernel.org>
Acked-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix this by letting NF_CONNTRACK_H323 depend on (IPV6 || IPV6=n).
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: David S. Miller <davem@davemloft.net>