- 05 Jul, 2004 13 commits
-
-
Mika Kukkonen authored
CHECK fs/udf/dir.c fs/udf/dir.c:240:13: warning: expected lvalue for member dereference [...] CHECK fs/udf/namei.c fs/udf/namei.c:872:6: warning: expected lvalue for member dereference fs/udf/namei.c:916:6: warning: expected lvalue for member dereference fs/udf/namei.c:1189:14: warning: expected lvalue for member dereference fs/udf/namei.c:1234:7: warning: expected lvalue for member dereference Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Andrey Panin authored
This patch moves reboot related workarounds out of dmi_scan.c Please consider applying. Signed-off-by:
Andrey Panin <pazke@donpac.ru> Signed-off-by:
-
Andrew Morton authored
rmk added a check to vmlinux for undefined symbols in -mm kernels. ppc64 fails due to trying to export an unimplemented symbol from assembly code. Signed-off-by:
-
Olaf Hering authored
A native powerpc64-linux gcc can not compile a ppc32 kernel properly. This patch fixes it. It was copied from ppc64. The change to vmlinux.lds.S fixes this error: ld: warning: powerpc:common architecture of input file `init/built-in.o' is incompatible with powerpc:common64 output Signed-off-by:
-
Anton Blanchard authored
Currently our spinlocks can call into the hypervisor on dedicated processor machines. Doing this may slow our locks down, so avoid it where possible. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Anton Blanchard authored
Here are the ppc64 specific gcc 3.5 fixes. Signed-off-by:
-
Anton Blanchard authored
gcc 3.5 ICEd on the ppc64 version of __ptep_set_access_flags, but it does look like we want to use *ptep here. Signed-off-by:
-
Paul Mackerras authored
From: Linas Vepstas <linas@austin.ibm.com> When an RTAS call returns the "hardware error" code, we need to do another RTAS call to find out what went wrong. Previously we weren't doing that inside the lock that serializes RTAS calls, and thus another cpu could get in and do another RTAS call in the meantime. This patch fixes it. This patch also includes some minor whitespace fixes. Signed-off-by:
Linas Vepstas <linas@linas.org> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Paul Mackerras authored
From: Linas Vepstas <linas@austin.ibm.com> This patch fixes the usage of the slot-error-detail log buffer for the Power5 architecture. The size of the error buffer is variable, and the correct size to use should have been obtained from firmware. Failure to use the correct buffer sizes will result in hard-to-debug system lockups deep in firmware. This patch is based on an earlier patch from Ben Herrenschmidt, which essentially did the same thing. This patch also tweaks some of the subroutine documentation. Signed-off-by:
-
Paul Mackerras authored
From: Linas Vepstas <linas@austin.ibm.com> This patch allows ppc64 to boot on Power5 machines. The new Power5 PCI bridge design requires EEH (enhanced PCI error handling) to be enabled for all PCI devices, not just some PCI devices. In addition, this patch moves the check for PCI to ISA bridges out of perf critical code, and into initialization code. This also avoids race conditions where the device type might not have been set. Also, some whitespace fixes, and some error-message-printing beautification. Signed-off-by:
-
Miles Bader authored
Signed-off-by:
Miles Bader <miles@gnu.org> Signed-off-by:
-
Miles Bader authored
Otherwise recent versions of gcc seem to optimize away some necessary tests. Signed-off-by:
-
Miles Bader authored
Signed-off-by:
-
- 04 Jul, 2004 3 commits
-
-
Paul Mundt authored
include/linux/swap.h changed the definition for swap_unplug_io_fn() awhile back, but mm/nommu.c was never updated to reflect the new definition. As such, mm/nommu.c presently fails to compile. This fixes it. Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
Christoph Hellwig authored
This fixes compilation on ppc32. The power/smp.o file should be linked only if both SMP and SWSUSPEND are configured in. It used to do it even without SWSUSPEND.
-
bk://gkernel.bkbits.net/libata-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
- 03 Jul, 2004 24 commits
-
-
Jeff Garzik authored
The ->qc_issue hook was designed to allow drivers to override some or all of the actual delivery of the taskfile to hardware. In the case of Promise, the hardware has its own packet format when doing read/write DMA commands, but uses traditional ATA taskfile registers for other types of commands.
-
Jeff Garzik authored
Move more SCSI-specific code out of libata core.
-
Jeff Garzik authored
In part of the effort to remove SCSI specifics from the libata internals, remove references to cmd->use_sg. cmd->use_sg becomes ATA_QCFLAG_SG, and !cmd->use_sg becomes ATA_QCFLAG_SINGLE. Convenience constant ATA_QCFLAG_DMAMAP is created when the programmer wishes to refer collectively to ATA_QCFLAG_{SG,SINGLE}. -
Jeff Garzik authored
-
Jeff Garzik authored
This is more conservative in general, and so applies to multiple controllers. Specifically it attempts to address irq-related issues on the Intel ICH5/6 hardware. On Intel ICH5/6, the BMDMA 'interrupt' status bit will be set even on non-DMA commands, which software (and I) did not expect. This change clears pending interrupts once upon initialization, and then each time ata_irq_on() is called.
-
Paul Jackson authored
The remainder of the const qualifiers on cpumask ops. My cpumask overhaul missed specifying the const qualifiers in cpumask.h. Subsequently, Linus has added some. The following should provide the remainder of them. It also fixes one src vs dst variable misnaming. Using crosstool on 2.6.7-mm5, I have built the following arch's with the following change included: alpha ia64 powerpc-405 powerpc-750 sparc sparc64 x86_64 Signed-off-by:
Paul Jackson <pj@sgi.com> Signed-off-by:
-
bk://bk.arm.linux.org.uk/linux-2.6-serialLinus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
bk://bk.arm.linux.org.uk/linux-2.6-rmkLinus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Andrew Morton authored
arch/i386/kernel/apm.c: In function `suspend': arch/i386/kernel/apm.c:1221: warning: implicit declaration of function `save_processor_state' arch/i386/kernel/apm.c:1223: warning: implicit declaration of function `restore_processor_state' Signed-off-by:
-
Adrian Bunk authored
s/2.5/2.6/ in MAINTAINERS Signed-off-by:
Adrian Bunk <bunk@fs.tum.de> Signed-off-by:
-
Paul King authored
Add devfs support to telephony devices. Only tested with a single telephony device. Devices name phone/<minor>. Signed-off-by:
-
James Bottomley authored
This new function fails to build on sparc64 due to nasty include dependencies. Fix that by uninlining it - it was too big for inlining anyway. Signed-off-by:
-
Andrew Morton authored
Found by the Stanford locking checker Signed-off-by:
-
Andrew Morton authored
Found by the Stanford locking checker Signed-off-by:
-
Andrew Morton authored
Found by the Stanford locking checker. Signed-off-by:
-
Andrew Morton authored
Fix deadlock identified by the Stanford locking checker. Signed-off-by:
-
Andrew Morton authored
Lamely fix a straightforward deadlock in sb_audio.c. Founf by the Stanford locking checker. Signed-off-by:
-
Andrew Morton authored
Fix deadlock identified by the Stanford locking checker. Signed-off-by:
-
Andrew Morton authored
Found by the new Stanford locking checker. Minimal fix for a deadlock in sysvfs: get_branch() can take read_lock(&pointers_lock), but one caller already has a write_lock. Perhaps some of the "oh we raced, drop everything and try again" logic in there can go away now, but this is enugh to fix the obvious deadlock. Signed-off-by:
-
Antonino Daplas authored
I did some simple benchmarking (time cat linux-2.6.7-mm5/MAINTAINERS) between 2.4 and 2.6 and I am not satisfied with what I see (It's claimed that fbdev-2.6 is faster than 2.4). The reason for the claim: 2.4 putcs - draw small amounts of data a lot of times 2.6 putcs - draw larger amounts of data a fewer times The way characters are drawn in 2.6 is optimal for accelerated drivers but should also give a speed boost for drivers that rely on software drawing. However the penaly incurred when preparing a large bitmap from a number of small bitmaps is currently very high. This is because of the following reasons: 1 fb_move_buf_{aligned|unaligned} uses pixmap->{out|in}buf. This is very expensive since outbuf and inbuf methods process only a byte or 2 of data at a time. 2 fb_sys_outbuf (the default method for pixmap->outbuf) uses memcpy(). Not a good choice if moving only a few bytes. 3 fb_move_buf_unaligned (used for fonts such as 12x22) also involves a lot of bit operations + a lot of calls to outbuf/inbuf which proportionately increases the penaly. So, I thought of separating fb_move_buf_* to fb_iomove_buf_* and fb_sysmove_buf_*. fb_iomove_buf_* - used if drivers specified outbuf and inbuf methods fb_sysmove_buf_* - used if drivers have no outbuf or inbuf methods *Most, if not all drivers fall in the second category. Below is a table that show differences between 2.4, 2.6 and 2.6 + abovementioned changes. To reduce the effect of panning and fillrect/copyarea, the scrollmode is forced to redraw. ================================================================= Test Hardware: P4 2G nVidia GeForce2 MX 64 Scrollmode: redraw time cat linux-2.6.7-mm5/MAINTAINERS 1024x768-8 1024x768-16 1024x768-32 ================================================================= 8x16 noaccel (2.4) real 0m5.490s real 0m8.535s real 0m15.388s user 0m0.001s user 0m0.000s user 0m0.001s sys 0m5.487s sys 0m8.535s sys 0m15.386s 8x16 noaccel (2.6) real 0m5.166s real 0m7.195s real 0m12.177s user 0m0.001s user 0m0.000s user 0m0.000s sys 0m5.164s sys 0m7.192s sys 0m12.176s 8x16 noaccel+patch (2.6) real 0m3.474s real 0m5.496s real 0m10.460s user 0m0.001s user 0m0.001s user 0m0.001s sys 0m5.492s sys 0m5.492s sys 0m10.454s ================================================================= 8x16 accel (2.4) real 0m4.368s real 0m9.420s real 0m22.415s user 0m0.001s user 0m0.001s user 0m0.001s sys 0m4.019s sys 0m9.384s sys 0m22.312s 8x16 accel (2.6) real 0m4.296s real 0m4.339s real 0m4.391s user 0m0.001s user 0m0.001s user 0m0.000s sys 0m4.280s sys 0m4.336s sys 0m4.389s 8x16 accel+patch (2.6) real 0m2.536s real 0m2.649s real 0m2.799s user 0m0.000s user 0m0.000s user 0m0.001s sys 0m2.536s sys 0m2.645s sys 0m2.798s ================================================================= 1024x768-8 1024x768-16 1024x768-32 ================================================================= 12x22 noaccel (2.4) real 0m7.883s real 0m12.175s real 0m21.134s user 0m0.000s user 0m0.000s user 0m0.001s sys 0m7.882s sys 0m12.174s sys 0m21.129s 12x22 noaccel (2.6) real 0m10.651s real 0m13.550s real 0m21.009s user 0m0.001s user 0m0.001s user 0m0.000s sys 0m10.617s sys 0m13.545s sys 0m21.008s 12x22 noaccel+patch (2.6) real 0m4.794s real 0m7.718s real 0m15.173s user 0m0.002s user 0m0.001s user 0m0.000s sys 0m4.792s sys 0m7.715s sys 0m15.170s ================================================================= 12x22 accel (2.4) real 0m3.971s real 0m9.030s real 0m21.711s user 0m0.000s user 0m0.000s user 0m0.000s sys 0m3.950s sys 0m8.983s sys 0m21.602s 12x22 accel (2.6) real 0m9.392s real 0m9.486s real 0m9.508s user 0m0.000s user 0m0.000s user 0m0.001s sys 0m9.392s sys 0m9.484s sys 0m9.484s 12x22 accel+patch (2.6) real 0m3.570s real 0m3.603s real 0m3.848s user 0m0.001s user 0m0.000s user 0m0.000s sys 0m3.567s sys 0m3.600s sys 0m3.844s ================================================================= Summary: 1 2.6 unaccelerated is a bit faster than 2.4 when handling 8x16 fonts, with a higher speed differential at high color depths. 2 2.4 unaccelerated is a bit faster than 2.6 when handling 12x22 fonts, with a smaller speed difference at high color depths (2.6 is actually a bit faster than 2.4 at 32bpp). 3 2.4 rivafb accelerated suffers at high color depths, even becoming slower than unaccelerated, possibly because of the 'draw few bytes many times' method. 4 2.6 rivafb accelerated has similar performance at any color depth, possibly because of 'draw lots of bytes a fewer times' method. 5 With the changes, there is a speed gain of ~1.7 seconds and ~5.7 seconds with 8x16 and 12x22 fonts respectively indepependent of the color depth or acceleration used. The speed gain is constant but significant. Below is a patch against 2.6.7-mm5. The effects will be very noticeable with drivers that uses SCROLL_REDRAW, but one should still see some speed gain even if SCROLL_YPAN/YWRAP is used. Separated fb_sys_move_* into fb_iosys_move_* and fb_sysmove_* to reduce penalty when constructing fb_image->data from character maps. In my testcase (1024x768 SCROLL_REDRAW), I get a ~1.7 second advantage with 'time cat MAINTAINERS' using 8x16 fonts and ~5.7 seconds with 12x22 fonts. The speed gain is independent of acceleration or color depth. Signed-off-by:Antonino Daplas <adaplas@pol.net> Signed-off-by:
-
Adrian Bunk authored
Signed-off-by:
-
Adrian Bunk authored
Signed-off-by:
-
Andrew Morton authored
rmk's patch found a defined-but-unimplemented symbol Signed-off-by:
-
Jan Kara authored
It fixes a possible race between quotaoff and prune_icache. The race could lead to some forgotten pointers to quotas in inodes leading later to BUG when invalidating quota structures. Signed-off-by:
-
