14 Jul, 2008
15 commits
-
Conflicts:
arch/x86/kernel/entry_32.S
arch/x86/kernel/process_32.c
arch/x86/kernel/process_64.c
arch/x86/lib/Makefile
include/asm-x86/irqflags.h
kernel/Makefile
kernel/sched.cSigned-off-by: Ingo Molnar
-
keep the one for VSYSCALL_HPET
Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
when try to make hpet_enable use io_remap instead fixmap got
ioremap: invalid physical address fed00000
------------[ cut here ]------------
WARNING: at arch/x86/mm/ioremap.c:161 __ioremap_caller+0x8c/0x2f3()
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.26-rc9-tip-01873-ga9827e7-dirty #358Call Trace:
[] warn_on_slowpath+0x6c/0xa7
[] ? __slab_alloc+0x20a/0x3fb
[] ? mpol_new+0x88/0x17d
[] ? mcount_call+0x5/0x31
[] ? mcount_call+0x5/0x31
[] __ioremap_caller+0x8c/0x2f3
[] ? hpet_enable+0x39/0x241
[] ? mcount_call+0x5/0x31
[] ioremap_nocache+0x2a/0x40
[] hpet_enable+0x39/0x241
[] hpet_time_init+0x21/0x4e
[] start_kernel+0x302/0x395
[] x86_64_start_reservations+0xb9/0xd4
[] ? x86_64_init_pda+0x39/0x4f
[] x86_64_start_kernel+0xec/0x107---[ end trace a7919e7f17c0a725 ]---
it seems for amd system that is set later...
try to move setting early in early_identify_cpu.
and remove same code for intel and centaur.Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
only add direct mapping for aperture
Signed-off-by: Yinghai Lu
Cc: Suresh Siddha
Signed-off-by: Ingo Molnar -
# cat devices.list
c 1:3 r
# echo 'c 1:3 w' > sub/devices.allow
# cat sub/devices.list
c 1:3 wAs illustrated, the parent group has no write permission to /dev/null, so
it's child should not be allowed to add this write permission.Signed-off-by: Li Zefan
Acked-by: Serge Hallyn
Cc: Serge Hallyn
Cc: Paul Menage
Cc: Pavel Emelyanov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
# echo "b $((0x7fffffff)):$((0x80000000)) rwm" > devices.allow
# cat devices.list
b 214748364:-21474836 rwmthough a major/minor number of 0x800000000 is meaningless, we
should not cast it to a negative value.Signed-off-by: Li Zefan
Acked-by: Serge Hallyn
Cc: Serge Hallyn
Cc: Paul Menage
Cc: Pavel Emelyanov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Signed-off-by: Jiri Pirko
Cc: Randy Dunlap
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
…l/git/tip/linux-2.6-tip
* 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
cpusets, hotplug, scheduler: fix scheduler domain breakage -
* Strengthen the return type for the _node_to_cpumask_ptr to be
a const pointer. This adds compiler checking to insure that
node_to_cpumask_map[] is not changed inadvertently.Signed-off-by: Mike Travis
Cc: "akpm@linux-foundation.org"
Cc: Yinghai Lu
Acked-by: Vegard Nossum
Signed-off-by: Ingo Molnar
13 Jul, 2008
21 commits
-
Now that IRQ2 is never made available to the I/O APIC, there is no need
to special-case it and mask as a workaround for broken systems. Actually,
because of the former, mask_IO_APIC_irq(2) is a no-op already.Signed-off-by: Maciej W. Rozycki
Cc: "Rafael J. Wysocki"
Cc: Matthew Garrett
Cc: Andreas Herrmann
Cc: Stephen Rothwell
Signed-off-by: Ingo Molnar -
Commit f18f982ab ("sched: CPU hotplug events must not destroy scheduler
domains created by the cpusets") introduced a hotplug-related problem as
described below:Upon CPU_DOWN_PREPARE,
update_sched_domains() -> detach_destroy_domains(&cpu_online_map)
does the following:
/*
* Force a reinitialization of the sched domains hierarchy. The domains
* and groups cannot be updated in place without racing with the balancing
* code, so we temporarily attach all running cpus to the NULL domain
* which will prevent rebalancing while the sched domains are recalculated.
*/The sched-domains should be rebuilt when a CPU_DOWN ops. has been
completed, effectively either upon CPU_DEAD{_FROZEN} (upon success) or
CPU_DOWN_FAILED{_FROZEN} (upon failure -- restore the things to their
initial state). That's what update_sched_domains() also does but only
for !CPUSETS case.With f18f982ab, sched-domains' reinitialization is delegated to
CPUSETS code:cpuset_handle_cpuhp() -> common_cpu_mem_hotplug_unplug() ->
rebuild_sched_domains()Being called for CPU_UP_PREPARE and if its callback is called after
update_sched_domains()), it just negates all the work done by
update_sched_domains() -- i.e. a soon-to-be-offline cpu is included in
the sched-domains and that makes it visible for the load-balancer
while the CPU_DOWN ops. is in progress.__migrate_live_tasks() moves the tasks off a 'dead' cpu (it's already
"offline" when this function is called).try_to_wake_up() is called for one of these tasks from another CPU ->
the load-balancer (wake_idle()) picks up a "dead" CPU and places the
task on it. Then e.g. BUG_ON(rq->nr_running) detects this a bit later
-> oops.Signed-off-by: Dmitry Adamushko
Tested-by: Vegard Nossum
Cc: Paul Menage
Cc: Max Krasnyansky
Cc: Paul Jackson
Cc: Peter Zijlstra
Cc: miaox@cn.fujitsu.com
Cc: rostedt@goodmis.org
Cc: Linus Torvalds
Signed-off-by: Ingo Molnar -
got this on a test-system:
calling numaq_tsc_disable+0x0/0x39
NUMAQ: disabling TSC
initcall numaq_tsc_disable+0x0/0x39 returned 0 after 0 msecsthat's because we should not be using arch_initcall to call numaq_tsc_disable.
need to call it in setup_arch before time_init()/tsc_init()
and call it in init_intel() to make the cpu feature bits right.Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
end_user_pfn used to modify the meaning of the e820 maps.
Now that all e820 operations are cleaned up, unified, tightened up,
the e820 map always get updated to reality, we don't need to keep
this secondary mechanism anymore.If you hit this commit in bisection it means something slipped through.
Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
optimization: try to merge the range with same page size in
init_memory_mapping, to get the best possible linear mappings set up.thus when GBpages is not there, we could do 2M pages.
Signed-off-by: Yinghai Lu
Cc: Suresh Siddha
Signed-off-by: Ingo Molnar -
tighten the boundary checks around max_low_pfn_mapped - dont overmap
nor undermap into holes.also print out tseg for AMD cpus, for diagnostic purposes.
(this is an SMM area, and we split up any big mappings around that area)Signed-off-by: Yinghai Lu
Cc: Suresh Siddha
Signed-off-by: Ingo Molnar -
fix crash on Ingo's big box:
calling pci_iommu_init+0x0/0x17
PCI-DMA: Disabling AGP.
PCI-DMA: aperture base @ d0000000 size 65536 KB
PCI-DMA: using GART IOMMU.
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
BUG: unable to handle kernel paging request at ffff88000003be88
IP: [] __alloc_pages_internal+0xc3/0x3f2
PGD 202063 PUD 206063 PMD 22fc00163 PTE 3b162
Oops: 0000 [1] SMPand e820 is:
BIOS-e820: 0000000000000000 - 000000000009ac00 (usable)
BIOS-e820: 000000000009ac00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000ca000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000007ff70000 (usable)
BIOS-e820: 000000007ff70000 - 000000007ff86000 (ACPI data)
BIOS-e820: 000000007ff86000 - 0000000080000000 (ACPI NVS)
BIOS-e820: 0000000080000000 - 00000000cfe00000 (usable)
BIOS-e820: 00000000cfe00000 - 00000000d0000000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000830000000 (usable)system has 32 GB RAM installed.
max_low_pfn_mapped is 0xcfe00, and GART aperture is not mapped.
So try to use init_memory_mapping to map that area, because the iommu
thinks that area is ram ...Signed-off-by: Yinghai Lu
Cc: Suresh Siddha
Signed-off-by: Ingo Molnar -
…git/tip/linux-2.6-tip
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86: fix ldt limit for 64 bit -
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
[SCSI] bsg: fix oops on remove
[SCSI] fusion: default MSI to disabled for SPI and FC controllers
[SCSI] ipr: Fix HDIO_GET_IDENTITY oops for SATA devices
[SCSI] mptspi: fix oops in mptspi_dv_renegotiate_work()
[SCSI] erase invalid data returned by device -
The current definition of wksidarr works fine on little endian arches
(since cpu_to_le32 is a no-op there), but on big-endian arches, it fails
to compile with this error:error: braced-group within expression allowed only inside a function
The problem is that this static declaration has cpu_to_le32 embedded
within it, and that expands into a function macro. We need to use
__constant_cpu_to_le32() instead.Signed-off-by: Jeff Layton
Cc: Steven French
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Try this:
mount a share with unix extensions
create a file on it
umount the shareYou'll get the following message in the ring buffer:
VFS: Busy inodes after unmount of cifs. Self-destruct in 5 seconds. Have a
nice day......the problem is that cifs_get_inode_info_unix is creating and hashing
a new inode even when it's going to return error anyway. The first
lookup when creating a file returns an error so we end up leaking this
inode before we do the actual create. This appears to be a regression
caused by commit 0e4bbde94fdc33f5b3d793166b21bf768ca3e098.The following patch seems to fix it for me, and fixes a minor
formatting nit as well.Signed-off-by: Jeff Layton
Acked-by: Steven French
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix FRV irqs_disabled() to return an int, not an unsigned long to avoid
this warning:kernel/sched.c: In function '__might_sleep':
kernel/sched.c:8198: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int'Signed-off-by: David Howells
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Cc: Philippe Elie
Cc: John Levon
Cc: Maynard Johnson
Cc: Richard Purdie
Cc: Daniel Hansel
Cc: Jason Yeh
Cc: Andrew Morton
Signed-off-by: Robert Richter
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Add the rtc8564 chip entry
Signed-off-by: Jon Smirl
Signed-off-by: Alessandro Zummo
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix chip naming from fm3031-rtc to fm3031
Signed-off-by: Alessandro Zummo
Cc: Sergey Lapin
Cc: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Cortland Setlow pointed out a bug in ov7670.c where the result from
ov7670_read() was just being checked for !0, rather than
Signed-off-by: Andres Salomon
Acked-by: Jonathan Corbet
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
I had 8250.nr_uarts=16 in the boot line of a test kernel and I had a weird
mysterious crash in sysfs. After taking an in-depth look I realized that
CONFIG_SERIAL_8250_NR_UARTS was set to 4 and I was walking off the end of
the serial8250_ports array.Ouch!!!
Don't let this happen to someone else.
Signed-off-by: Eric W. Biederman
Acked-by: Alan Cox
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This patch is a bugfix for how defio handles multiple processes manipulating
the same framebuffer.Thanks to Bernard Blackham for identifying this bug.
It occurs when two applications mmap the same framebuffer and concurrently
write to the same page. Normally, this doesn't occur since only a single
process mmaps the framebuffer. The symptom of the bug is that the mapping
applications will hang. The cause is that defio incorrectly tries to add the
same page twice to the pagelist. The solution I have is to walk the pagelist
and check for a duplicate before adding. Since I needed to walk the pagelist,
I now also keep the pagelist in sorted order.Signed-off-by: Jaya Kumar
Cc: Bernard Blackham
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Coverity CID: 1356 RESOURCE_LEAK
I found a very old patch for this that was Acked but did not get applied
https://lists.linux-foundation.org/pipermail/kernel-janitors/2006-September/016362.htmlThere looks to be a small leak in isdn_writebuf_stub() in isdn_common.c, when
copy_from_user() returns an un-copied data length (length != 0). The below
patch should be a minimally invasive fix.Signed-off-by: Darren Jenkins
Acked-by: Karsten Keil
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Coverity CID: 2172 RESOURCE_LEAK
When pool_allocate() tries to enlarge a packet, if it can not allocate enough
memory, it returns NULL without first freeing the old packet.This patch just frees the packet first.
Signed-off-by: Darren Jenkins
Acked-by: Jiri Kosina
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
12 Jul, 2008
4 commits
-
If you do a modremove of any sas driver, you run into an oops on
shutdown when the host is removed (coming from the host bsg device).
The root cause seems to be that there's a use after free of the
bsg_class_device: In bsg_kref_release_function, this is used (to do a
put_device(bcg->parent) after bcg->release has been called. In sas (and
possibly many other things) bcd->release frees the queue which contains
the bsg_class_device, so we get a put_device on unreferenced memory.
Fix this by taking a copy of the pointer to the parent before releasing
bsg.Acked-by: FUJITA Tomonori
Signed-off-by: James Bottomley -
There's a fault on the FC controllers that makes them not respond
correctly to MSI. The SPI controllers are fine, but are likely to be
onboard on older motherboards which don't handle MSI correctly, so
default both these cases to disabled. Enable by setting the module
parameter mpt_msi_enable=1.For the SAS case, enable MSI by default, but it can be disabled by
setting the module parameter mpt_msi_enable=0.Cc: "Prakash, Sathya"
Signed-off-by: James Bottomley -
Conflicts:
arch/x86/mm/ioremap.c
Signed-off-by: Ingo Molnar
-
Fix size of LDT entries. On x86-64, ldt_desc is a double-sized descriptor.
Signed-off-by: Michael Karcher
Signed-off-by: Ingo Molnar
