- 03 Aug, 2005 5 commits
-
-
Linus Torvalds authored
The VM_FAULT_WRITE thing is an extra bit, not a valid return value, and has to be treated as such by get_user_pages(). Signed-off-by:Linus Torvalds <torvalds@osdl.org>
-
Nick Piggin authored
Checking pte_dirty instead of pte_write in __follow_page is problematic for s390, and for copy_one_pte which leaves dirty when clearing write. So revert __follow_page to check pte_write as before, and make do_wp_page pass back a special extra VM_FAULT_WRITE bit to say it has done its full job: once get_user_pages receives this value, it no longer requires pte_write in __follow_page. But most callers of handle_mm_fault, in the various architectures, have switch statements which do not expect this new case. To avoid changing them all in a hurry, make an inline wrapper function (using the old name) that masks off the new bit, and use the extended interface with double underscores. Yes, we do have a call to do_wp_page from do_swap_page, but no need to change that: in rare case it's needed, another do_wp_page will follow. Signed-off-by:
Hugh Dickins <hugh@veritas.com> [ Cleanups by Nick Piggin ] Signed-off-by:
-
Haren Myneni authored
For soft reset during system hang, got an error "CPU did not take control" for some CPUs even though they responded to soft-reset (called SystemReset, die and called debugger - xmon). First these CPUs entered into xmon by IPI callback and then got a soft-reset exception and re-entered into xmon again. The first CPU which re-entered into xmon got the output lock and made into xmon successfully without unlocking. Hence, the next CPU(s) which re-entered into xmon try to acquire a lock (get_output_lock). Therefore, we can not view state of those CPU(s). [This is a simple, very low risk, obvious fix for an obvious bug, and should go into 2.6.13. -- paulus] Signed-off-by:
Haren Myneni <hbabu@us.ibm.com> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Ivan Kokshaysky authored
We have increased PCIBIOS_MIN_IO to 0x4000, but still want motherboard resources to be allocated properly. So we need to state 0x1000 (according to the comment) limit explicitely. Signed-off-by:
Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by:
-
Ivan Kokshaysky authored
There is a number of x86 laptops that have some non-PCI IO ports in the 0x1000-0x1fff range, and it's quite hard to control the correct order of resource allocation between PCI and other subsystems controlling these ports. Especially with modular kernel. So just increase PCIBIOS_MIN_IO to 0x4000 to prevent any new PCI resource allocations in the problematic range (this limitation must apply _only_ to the root bus resources - see Linus' change in pci_bus_alloc_resource). As PCIBIOS_MIN_IO and PCIBIOS_MIN_CARDBUS_IO are the same now on i386 and x86-64, we can remove the latter. Signed-off-by:
-
- 02 Aug, 2005 35 commits
-
-
Linus Torvalds authored
The reason we have PCIBIOS_MIN_IO and PCIBIOS_MIN_CARDBUS_IO is because we want to protect badly documented motherboard PCI resources and thus don't want to allocate new resources in low IO/MEM space. However, if we have already discovered a PCI bridge with a specified resource base, that should override that decision. This change will allow us to move the "careful" region upwards without resulting in problems allocating resources in low mappings. This was brought on by us having allocated a bus resource at 0x1000, conflicting with a undocumented VAIO Sony PI resources.
-
Jens Axboe authored
CFQ will currently stall when using write barriers and the default max_depth setting of 1, since we artificially need a depth of 2 when pre-pending the first flush. So never deny the barrier request going to the device. This is a regression since 2.6.12, it was found in SUSE testing. Signed-off-by:
Jens Axboe <axboe@suse.de> Signed-off-by:
-
Olaf Hering authored
Rebuild the aic7xxx firmware doesn't work anymore after this change which appeared int 2.6.13-rc1: [SCSI] aic7xxx/aic79xx: remove useless byte order macro cruft Two files did not include byteorder.h, resulting in aic dying with a panic "Unknown opcode encountered in seq program" This fixes it for me. Signed-off-by:
Olaf Hering <olh@suse.de> Acked-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Paul Mackerras authored
Recent changes (well, dating from 12 July) have broken cardbus on my powerbook: I get 3 messages saying "no resource of type xxx available, trying to continue", and if I plug in my wireless card, it complains that there are no resources allocated to the card. This all worked in 2.6.12. Looking at the code in yenta_socket.c, function yenta_allocate_res, it's obvious what is wrong: if we get to line 639 (i.e. there wasn't a usable preassigned resource), we will always flow through to line 668, which is the printk that I was seeing, even if a resource was successfully allocated. It looks to me as though there should be a return statement after the two config_writel's in each of the 3 branches of the if statements, so that the function returns after successfully setting up the resource. The patch below adds these return statements, and with this patch, cardbus works on my powerbook once again. Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
-
Linus Torvalds authored
Ok, let's get it right this time
-
Mike Kravetz authored
If CONFIG_NUMA is set, some POWER 4 systems will fail to boot. This is because of special processing needed to handle invalid node IDs (0xffff) on POWER 4. My previous patch to handle memory 'holes' within nodes forgot to add this special case for POWER 4 in one place. In reality, I'm not sure that configuring the kernel for NUMA on POWER 4 makes much sense. Are there POWER 4 based systems with NUMA characteristics that are presented by the firmware? But, distros want one kernel for all systems so NUMA is on by default in their kernels. The patch handles those cases. Signed-off-by:
Mike Kravetz <kravetz@us.ibm.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Rusty Russell authored
The module code assumes noone will ever ask for a per-cpu area more than SMP_CACHE_BYTES aligned. However, as these cases show, gcc asks sometimes asks for 32-byte alignment for the per-cpu section on a module, and if CONFIG_X86_L1_CACHE_SHIFT is 4, we hit that BUG_ON(). This is obviously an unusual combination, as there have been few reports, but better to warn than die. See: http://www.ussg.iu.edu/hypermail/linux/kernel/0409.0/0768.html And more recently: http://bugs.gentoo.org/show_bug.cgi?id=97006Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Anton Blanchard authored
Dont include asm-generic/topology.h unconditionally, we end up overriding all the ppc64 specific functions when NUMA is on. Signed-off-by:
Anton Blanchard <anton@samba.org> Acked-by:
-
Andrew Morton authored
Fix bug found by Grant Coady <lkml@dodo.com.au>'s autobuild setup. shmem_set_policy() and shmem_get_policy() are macros if !CONFIG_SHMEM, so this doesn't work. Signed-off-by:
-
Andrew Morton authored
Fix bug found by Grant Coady <lkml@dodo.com.au>'s autobuild setup. Signed-off-by:
-
Eric Dumazet authored
A kernel BUG() is triggered by a call to set_mempolicy() with a negative first argument. This is because the mode is declared as an int, and the validity check doesnt check < 0 values. Alternatively, mode could be declared as unsigned int or unsigned long. Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
Hugh Dickins authored
x86_64 has a large sparse gate area between VSYSCALL_START and VSYSCALL_END, not all of it presently backed by pmds. Alexander Nyberg has found that in some circumstances gdb may try to ptrace here, and hit get_user_pages BUG_ON. It seems odd that gdb should be accessing here, but it certainly shouldn't crash in this way: relax BUG_ON to -EFAULT. Fixes kernel bugzilla #4801. Signed-off-by:
-
Roman Zippel authored
If there was a read error, the bnode might miss some pages, so skip them. Signed-off-by:
Roman Zippel <zippel@linux-m68k.org> Signed-off-by:
-
Roman Zippel authored
If inode size hasn't changed, don't do anything further in truncate, which also prevents a dirty inode, what might upset some readonly devices quite badly. Signed-off-by:
-
Adrian Bunk authored
We don't want these to be global functions. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Mauro Carvalho Chehab authored
This patch does correct radio chip autodetection to avoid misdetecting mt20xx microtune as tea5767 chip. Signed-off-by:
Mauro Carvalho Chehab <mchehab@brturbo.com.br> Signed-off-by:
-
Mark Haverkamp authored
Martin Drab found that he could get aacraid timeouts with high load on his controller / disk drive combinations. After some experimentation Mark Salyzyn has come up with a patch to reduce the default max_sectors to something that will keep the controller from being overloaded and will eliminate the timeout issues. Signed-off-by:
Mark Haverkamp <markh@osdl.org> Cc: James Bottomley <James.Bottomley@steeleye.com> Acked-by:
Mark Salyzyn <mark_salyzyn@adaptec.com> Signed-off-by:
-
Hirokazu Takata authored
There was a scheduling problem of the m32r SMP kernel; A process rarely stopped and gave no responding but the other process have been handled by the other CPU still lives, then if we did something in the other terminal or something like that, the stopped process came back to life and continued its operation... (ex. LMbench: lat_sig) In the m32r SMP kernel, a local-timer event is delivered by using an IPI(inter processor interrupts); LOCAL_TIMER_IPI. And a function smp_send_timer() is prepared to send the LOCAL_TIMER_IPI from the current CPU to the other CPUs. The funtion smp_send_timer() was placed and used in do_IRQ() in former times (before 2.6.10-rc3-mm1 kernel), however, it was unintentionally removed when arch/m32r/kernel/irq.c was modified to employ the generic hardirq framework (CONFIG_GENERIC_HARDIRQ) in my previous patch. [PATCH 2.6.10-rc3-mm1] m32r: Use generic hardirq framework http://www.ussg.iu.edu/hypermail/linux/kernel/0412.2/0358.html The following patch fixes the above problem. Signed-off-by:
Hitoshi Yamamoto <hitoshiy@isl.melco.co.jp> Signed-off-by:
Hirokazu Takata <takata@linux-m32r.org> Signed-off-by:
-
Martin Schwidefsky authored
Add system calls for io priorities and inotify. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Disable pseudo page fault handling before starting the new kernel and try to use diag308 to reset the machine. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Eugene Surovegin authored
Add missing 4xx EMAC data sysfs nodes. Signed-off-by:
Eugene Surovegin <ebs@ebshome.net> Signed-off-by:
-
Matt Porter authored
Add Bamboo platform defconfig Signed-off-by:
Wade Farnsworth <wfarnsworth@mvista.com> Signed-off-by:
Matt Porter <mporter@kernel.crashing.org> Signed-off-by:
-
Matt Porter authored
Add Bamboo platform support. This is an AMCC 440EP-based reference platform. Signed-off-by:
-
Matt Porter authored
Add PPC440EP core support. PPC440EP is a PPC440-based SoC with a classic PPC FPU and another set of peripherals. Signed-off-by:
-
Kumar Gala authored
Marked APUS and GEMINI as BROKEN since they do not build at the platform level. We have requested that the maintainers of these boards/platforms fix them by the time 2.6.15 is released or we plan on concerning them unmaintained and thus removing them. Signed-off-by:
Kumar Gala <kumar.gala@freescale.com> Signed-off-by:
-
Denis Vlasenko authored
cs89x0 talks a lot at boot. Seems like debug leftover. This patch downgrades printks to KERN_DEBUG. While we're at it, make these messages a bit less obscure. Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
-
NeilBrown authored
The default resync_max_sector is set to "mddev->size << 1". If the raid-personality-module updates mddev->size, it must update resync_max_sectors too. Signed-off-by:
Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
-
Benjamin Herrenschmidt authored
The code that sets the altivec capability of the CPU based on firmware informations can enable altivec when the kernel has CONFIG_ALTIVEC disabled. This results in "interesting" crashes. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Paul Jackson authored
Improve the likelihood that someone submitting a patch will notify the MAN-PAGES maintainer. This is a follow-up to comments on the July 29 lkml email thread: "Broke nice range for RLIMIT NICE" Signed-off-by:
Paul Jackson <pj@sgi.com> Cc: "Michael Kerrisk" <mtk-manpages@gmx.net> Signed-off-by:
-
Michael Kerrisk authored
Michael maintains the kernel manpages. He wants us to tell him when we change or augment the userspace API. Add his contact details to MAINTAINERS. Signed-off-by:
-
Michael Krufky authored
Peter Missel: - Add support for the SVideo input on the GDI Black Gold. Mauro Carvalho Chehab: - Linux/version.h removed. Replaced by linux/utsname.h Michael Krufky: - Added analog support for DViCO FusionHDTV5 Gold. CC: Peter Missel <peter.missel@onlinehome.de> Signed-off-by:
Michael Krufky <mkrufky@m1k.net> Signed-off-by:
-
Mauro Carvalho Chehab authored
- Fixed some bttv card numbers. - BTTV and SAA7134 version numbers incremented to reflect changes. - pci_dma_supported() is called after pci_set_dma_mask() which already did check that for us. This patch removes the unneeded call to pci_dma_supported() at bttv-driver.c - Ensure a sufficient I2C bus idle time between 2 messages for saa7134-i2c.c - It is important to write at first to MO_GP3_IO for cx88-tvaudio.c - Use try_to_freeze() instead of refrigerator at msp3400.c - Recognizing the MFPE05-2 Tuner at tveeprom.c - Add new parameter to help identify radio chipsets at tuner module: show_i2c=1 will show 16 reading bytes from detected tuners. - BTTV does generate some Unimplemented IOCTL log at tuner module: 0x40046d11(dir=1,tp=0x6d,nr=17,sz=4) means that it is sending MSP3400 calls to non-msp3400 tuners. Warning eliminated. VIDIOSAUDIO is also called, so debug messages updated. It is still requiring IOCTL implementation. - Added two more tuners. - Add support for the SVideo input on the GDI Black Gold. Signed-off-by:
Peter Missel <peter.missel@onlinehome.de> Signed-off-by:
Graham Bevan <graham.bevan@ntlworld.com> Signed-off-by:
Torsten Seeboth <Torsten.Seeboth@t-online.de> Signed-off-by:
Hartmut Hackmann <hartmut.hackmann@t.online.de> Signed-off-by:
Tobias Klauser <tklauser@nuerscht.ch> Signed-off-by:
-
Eric Lammerts authored
We know that the randomisation slows down some workloads on Transmeta CPUs by quite large amounts. We think it's because the CPU needs to recode the same x86 instructions when they pop up at a different virtual address after a fork+exec. So disable randomization by default on those CPUs. Signed-off-by:
-
Andrew Morton authored
Make it compile with CONFIG_PM=n Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
-
Andrew Morton authored
Seems that both Greg and I submitted the same patch and it just kept on applying... Cc: Greg KH <greg@kroah.com> Cc: Kumar Gala <galak@freescale.com> Signed-off-by:
-
