- 22 Oct, 2004 7 commits
-
-
Paul Mackerras authored
When the generic IRQ stuff went in, it seems that HARDIRQ_BITS got bumped from 9 (for ppc64) up to 12. Consequently, the PREEMPT_ACTIVE bit is now within HARDIRQ_MASK, and I get in_interrupt() falsely returning true when PREEMPT_ACTIVE is set, and thus a BUG_ON tripping in arch/ppc64/mm/tlb.c. The patch below fixes this by changing PREEMPT_ACTIVE to 0x10000000. I have changed the PREEMPT_ACTIVE definitions for each of the architectures that define CONFIG_GENERIC_HARDIRQS (i386, ppc, ppc64, x86_64) and fixed the comment in include/linux/hardirq.h. We could perhaps move the PREEMPT_ACTIVE definition to include/linux/hardirq.h - I don't know why it is still per-arch. Signed-off-by:
Paul Mackerras <paulus@samba.org> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Benjamin Herrenschmidt authored
This patch fixes build of arch/ppc/kernel/irc.c when CONFIG_TAU_INT is set. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Benjamin Herrenschmidt authored
The current "generic" implementation of IRQ probing isn't well suited for ppc in it's current form, and causes issues with yenta_socket (and possibly others) on pmac laptops. We didn't have a probe implementation in the past, we probably don't need one anyway, so for now, the fix is to make this optional and enable it on x86 and x86_64 but not ppc and ppc64 (the 4 archs to use the generic IRQ code). Signed-off-by:
-
Benjamin Herrenschmidt authored
This patch updates the G5 thermal control driver, the main change is support for the new "PowerMac7,3" type desktops including the dual 2.5Ghz with liquid cooling. Signed-off-by:
-
Benjamin Herrenschmidt authored
This patch fixes a typo in the zImage boot wrapper (incorrect printf). Signed-off-by:
Matthew Dharm <mdharm@momenco.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
This patch fixes a problem when allocating the TCE tables (iommu) during early boot on some non-LPAR machines with a lot of memory. Signed-off-by:
-
Paul Mackerras authored
This patch, from John Rose, is the counterpart of one recently forwarded by Greg KH. It has the same description, but isn't the same patch - this is the arch/ppc64 part of the change. As an unfortunate side effect of runtime addition/removal of PCI Host Bridges, the RPA DLPAR driver can no longer depend on the success of ioremap_explicit() (and therefore remap_page_range()) for the case of DLPAR adding an I/O Slot. Without addressing this, an attempt to add the first child slot of a newly added PHB will fail when __ioremap_explicit() determines the mappings for that range to already exist. For a little context, __ioremap_explicit() creates mappings for the range of a newly added slot. Here's why these calls will be expected to fail in some cases. Keep in mind that at boot-time, the PPC64 kernel calls ioremap() for the entire range spanned by each PHB. Consider the following scenarios of DLPAR-adding an I/O slot. 1) Just after boot, one removes an I/O slot. At this point the range associated with the parent PHB is fragmented, and the child range for the slot in question is iounmap()'ed. One then re-adds the slot, at which point remap_page_range()/ioremap_explicit() restores the mappings that were previously removed. 2) One adds a new PHB, at which point the ppc64-specific addition ioremaps the entire PHB range. One then performs a DLPAR-add of a child slot of that PHB. At this point, mappings already exist for the range of the slot to be added. So remap_page_range()/ioremap_explicit() will fail at this point. The problem is, there's not a good way to distinguish between cases 1 and 2 from the perspective of the DLPAR driver. Because of that, I believe the correct solution to be: - Removal of relevant error prints from iounmap_explicit(), which is only used for DLPAR. - Removal of error code checks from the RPA driver Here's the first of these. Signed-off-by:
John Rose <johnrose@austin.ibm.com> Signed-off-by:
-
- 21 Oct, 2004 10 commits
-
-
Alexander Viro authored
ioremap() made inlined function on sparc64; that had caught one bogosity in drivers, actually - cpwatchdog.c passed sizeof(structure that was never declared) as the second argument to ioremap(). It went unnoticed since that argument was never used in the body of macro, so it disappeared without a trace... Signed-off-by:
Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by:
-
Alexander Viro authored
A bunch of places passes volatile pointers to readb() et.al.; sparc64 has their arguments declared as void __iomem *. Prototypes changed to match other platforms. Signed-off-by:
-
Alexander Viro authored
Signed-off-by:
-
Alexander Viro authored
Signed-off-by:
-
Alexander Viro authored
sparse complains on casts from long to pointers; unsigned long is OK, though, and it's OK with all numeric cases. Signed-off-by:
-
Alexander Viro authored
Signed-off-by:
-
Alexander Viro authored
Some drivers do ifdef on writeq; alpha has it as inline function, so they get confused. Signed-off-by:
-
Alexander Viro authored
Signed-off-by:
-
Alexander Viro authored
Signed-off-by:
-
-
- 22 Oct, 2004 2 commits
-
-
Bartlomiej Zolnierkiewicz authored
It is not needed any longer: * PIO code is unified and converted to use scatterlists * taskfile code doesn't support falling back to PIO * it is much easier to convert non-taskfile version of __ide_do_rw_disk() to something sane than taskfile one Signed-off-by:Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
Bartlomiej Zolnierkiewicz authored
All users of this code were fixed to use scatterlists. Acked by Jens. Signed-off-by:
-
- 21 Oct, 2004 21 commits
-
-
Bartlomiej Zolnierkiewicz authored
Sigh, I broke it by accident 16 months ago and nobody has noticed (I suspect that it was non-functional even earlier). Additionally, this driver: * should be converted to use scatterlists * has verbose debugging enabled by default * needs hacks all over IDE code * is guilty of crimes against ide_hwifs[] Just remove it for now. Signed-off-by: -
Linus Torvalds authored
Based on input from Roland McGrath and Hugh Dickins. This simplifies the logic, and takes advantage of the "new" VM information in the form of vma->anon_vma.
-
Linus Torvalds authored
Rather than the deprecated remap_page_range() function that can't handle all of the PFN range anyway. Also, since that will now mark the vma as being special, there's no need to do it in mmap_mem() any more.
-
Linus Torvalds authored
VM_IO tells the rest fo the world that the pages may have side effects on reads/writes etc, and VM_RESERVED historically told swap-out not to bother with it.
-
William Lee Irwin III authored
It was pointed out to me that I typo'd and lost a backslash in the PA-RISC io_remap_page_range() definition. This patch corrects the one-character typo.
-
Paul Fulghum authored
Here is the hangup implementation for ppp_synctty.c (same as patch previously for ppp_asynctty.c) Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: -
bk://linux-mtd.bkbits.net/mtd-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Randy Dunlap authored
Use %p to print a pointer, so that its length doesn't matter and so that gcc won't complain. drivers/mtd/maps/dilnetpc.c:416: warning: long unsigned int format, pointer arg (arg 2) Signed-off-by:
Randy Dunlap <rddunlap@osdl.org> Signed-off-by:
David Woodhouse <dwmw2@infradead.org>
-
Paul Fulghum authored
I reviewed, patched, and tested ppp_async.c to implement ldisc->hangup(). This correctly terminates the PPP connection on hangup. Paul Mackerras already did an excellent job of ensuring safe shutdown and I/O completion in ldisc->close so the change is trivial: just add the ldisc->hangup and call the existing close routine. Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: -
bk://gkernel.bkbits.net/libata-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Adrian Bunk authored
Below is a patch from Denis Zaitsev <zzz@anda.ru> with the following two adjustments: - applies with -p1 (not -p0) - USRobotics -> U.S. Robotics (consistent with the rest of the entries) Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Yoichi Yuasa authored
The MIPS Makefile was changed so that the offset of data section may not be dependent on a specific machine header file. Signed-off-by:
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Signed-off-by:
-
Dinakar Guniguntala authored
One more place in fs/proc/array.c where ppid is wrong, which I missed in my previous mail to lkml. Signed-off-by:
Dinakar Guniguntala <dino@in.ibm.com> Signed-off-by:
-
Stefan Esser authored
From: <Urban.Widmark@enlight.net> The memset is because it was previously possible to send always the same CIFS fragment and use this to increase the data counters. When the data counter "exceeds" the amount of bytes expected this will return the buffer only partially initialised... With findfirst etc requests this should allow leaking kernel memory content. The other thing is that the data is only returned when data_tot and parm_tot both "exceed" the expected values. Previously it was possible to create a sequence of CIFS fragments that allowed exceeding the counters. The calling functions then would believe they received a number of bytes that does not fit into the allocated buffer. Signed-off-by:
-
Andy Whitcroft authored
When a system has a very large imbalance of overall memory size to ZONE_NORMAL (for example when large amounts of numa remap space are in use) page_writeback_init() may incorrectly set vm_dirty_ratio and dirty_background_ratio to zero; leading to divide by zero errors elsewhere. This patch bounds these at 1%. Signed-off-by:
Andy Whitcroft <apw@shadowen.org> Signed-off-by:
-
Randy Dunlap authored
Error: ./drivers/media/video/cx88/cx88-video.o .data refers to 0000000000000b28 R_X86_64_64 .exit.text Signed-off-by:
-
Randy Dunlap authored
Error: ./drivers/media/dvb/bt8xx/bt878.o .data refers to 0000000000000048 R_X86_64_64 .exit.text Signed-off-by:
-
Randy Dunlap authored
Error: ./drivers/media/video/saa7134/saa7134-core.o .data refers to 0000000000000028 R_X86_64_64 .exit.text Signed-off-by:
-
Hirokazu Takata authored
Here is a patch for M32R SIO driver, which replaces deprecated MODULE_PARAM() with modern module_param(). * drivers/serial/m32r_sio.c: - Replace MODULE_PARAM() with module_param(). - Fix a typo: UARRT_RSA_BASE --> UART_RSA_BASE. Signed-off-by:
Hirokazu Takata <takata@linux-m32r.org> Signed-off-by:
-
Werner Almesberger authored
In ia32 emulation, the amd64 kernel refuses the ioctls TIOCSBRK and TIOCCBRK with EINVAL. I've attached a patch that adds them to the compatibility list. Since all architectures have these ioctls ("m68knommu" inherits them from "m68k", "um" from its host) and use the same code, I think adding them to compat_ioctl.h is the correct choice (as opposed to adding them to arch/x86_64/ia32/ia32_ioctl.c). Signed-off-by:Werner Almesberger <werner@almesberger.net> Signed-off-by:
-
Olof Johansson authored
There seems to have been a couple of thinkos in the NUMA init code, in particular in find_cpu_node(): * Property size returned is in bytes, not words * Off-by-one error in loop iteration Signed-off-by:
Nathan Lynch <nathanl@austin.ibm.com> Signed-off-by:
Olof Johansson <olof@austin.ibm.com> Signed-off-by:
-
