- 11 Nov, 2004 40 commits
-
-
Neil Brown authored
Sometimes it didn't read all (working) drives before a parity calculation. Signed-off-by:
Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Neil Brown authored
Some size fields were "int" instead of "sector_t". Signed-off-by:
-
Antonino Daplas authored
This patch fixes some of the drivers' fb_blank() implementation which got the usage of the VESA_* constants incorrectly and converts them to use the new FB_BLANK-* constants. I'm not sure if what I did is correct for all drivers, so maintainers, please review. (Note: For most of the drivers, FB_BLANK_NORMAL is treated as FB_BLANK_UNBLANK, but returns a nonzero so fbcon will do a soft_blank). Signed-off-by:
Antonino Daplas <adaplas@pol.net> Signed-off-by:
-
Antonino Daplas authored
This patch converts most drivers to use the new FB_BLANK_* constants. These drivers have correct fb_blank() implementations. Signed-off-by:
-
Antonino Daplas authored
The VESA_* constants in fb.h used for power management of the display is confusing to use. The constants seems to be meant for userspace, because within the kernel (vt and fbdev), the constants have to be incremented by 1. Implementation of fb_blank() varies from driver to driver: - if-else on blank/!blank - switch case on hardcoded numbers - switch case on the constants + 1 - switch -1, case on constants as is - switch case on the constants as is (broken) To make usage clearer, new constants are defined in fb.h: FB_BLANK_UNBLANK = VESA_UNBLANKING = 0; FB_BLANK_NORMAL = VESA_UNBLANKING + 1 = 1; FB_BLANK_VSYNC_SUSPEND = VESA_VSYNC_SUSPEND + 1 = 2; FB_BLANK_HSYNC_SUSPEND = VESA_HSYNC_SUSPEND + 1 = 3; FB_BLANK_POWERDOWN = VESA_POWERDOWN + 1 = 4; Other changes: - generic blanking code in fbcon.c (for drivers without an fb_blank hook) which either sets the palette to all black, or clear the screen with black. - make fb_display an unexportable symbol Signed-off-by:
-
Antonino Daplas authored
The function set_con2fb_map() is getting very big. Split it into its component functions. Signed-off-by:
-
Antonino Daplas authored
Set color depth to 8 if in pseudocolor in vesafb. The CLUT size, previously saved as {red|green|blue}.length, is now private to vesafb. Signed-off-by: -
Antonino Daplas authored
The hardware cursor implementation in i810fb broke sometime during 2.6. Until this is fixed, temporarily use soft_cursor(). Signed-off-by:
-
Antonino Daplas authored
The current code in rivafb will not accept modes other than 640x480-60 if the the EDID block is absent. This patch changes the behavior to the opposite, if without an EDID, rivafb will accept all modelines coming from userspace (2.4 behavior). Signed-off-by:
-
Antonino Daplas authored
Convert direct pointer manipulation to NV_RD*/NV_WR* in nv_driver.c Signed-off-by:
-
Jens Axboe authored
The direct-io code currently returns -EIO if someone tries to read past the end of a block device. Change it to shorten the read and to return the number of bytes which were actually read. Signed-off-by:
Jens Axboe <axboe@suse.de> Signed-off-by:
-
Gerd Knorr authored
The patch below removes an unused function from media/video/bw-qcam.c Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
Gerd Knorr <kraxel@bytesex.org> Signed-off-by:
-
Gerd Knorr authored
Fix for the msp3400 module: make the initial carrier scan (after loading the driver) work. Signed-off-by:
-
Gerd Knorr authored
Convert v4l1-compat module to new-style insmod options. Signed-off-by:
-
Gerd Knorr authored
Convert the ir-common module to new-style insmod options. Signed-off-by:
-
Gerd Knorr authored
Convert leftover insmod options to new-style. Signed-off-by:
-
Gerd Knorr authored
Adapt saa7134 driver to video-buf changes. Signed-off-by:
-
Gerd Knorr authored
This is a cx88 driver update, changes: * adapt to video-buf changes. * add support for a new card. * use the new video-buf-dvb module. The dvb stuff doesn't build yet as it depends on some cutting-edge code from the linuxtv cvs and is tagged as 'BROKEN' because of that. The patch also removes all trailing whitespaces. I've a script to remove them from my sources now, that should kill those no-op whitespace changes in my patches after merging this initial cleanup. Signed-off-by:
-
Gerd Knorr authored
This is a update for the saa7134 driver, changes: * adapt to the video-buf changes. * add new cards. * split mpeg encoder card support to separare module (saa7134-empress), as preparation for the dvb support which also uses the MPEG capabilities of the card. * started working on dvb support (not functional yet, also marked 'BROKEN'). * convert insmod options to new-style. The patch also removes all trailing whitespaces. I've a script to remove them from my sources now, that should kill those no-op whitespace changes in my patches after merging this initial cleanup. Signed-off-by:
-
Gerd Knorr authored
This is an update for the bttv driver, changes: * adapt to video-buf changes. * convert to new-style insmod options. * drop some obsolete junk. Signed-off-by:
-
Gerd Knorr authored
Adds a new helper module for simple dvb budget cards without hardware filtering capabilities (which just pass the complete transport stream via DMA and let the dvb core sort everything else). Will initially be used by saa7134 + cx88 drivers. Signed-off-by:
-
Gerd Knorr authored
This is one more interface fix for the video-buf.c module, the first attempt on that wasn't that clever. Instead of passing the driver private data through all function calls I've just made that an element of the videobuf_queue struct which is passed around everythere _anyway_. That removes some reduncancy, should be less error prone and gain me some points on rusty's interface design scala ;) It also fixes the tvtime crashes which where caused by overviewing one place to fixup in the first attempt. Signed-off-by:
-
Tom Rini authored
The following patch against 2.6.10-rc1 fixes the brain damage that was found in the CPM2 uart driver. Previously, if 8250 was configured in, it would use one set of numbers (which at the time didn't conflict with anything, but have since been officially given to the Motorola i.MX driver) and if 8250 wasn't in, it would masquerade as it. The following switches us over to 204/46...49 (Which is still unclaimed). Signed-off-by:
Tom Rini <trini@kernel.crashing.org> Cc: <rmk@arm.linux.org.uk> Signed-off-by:
-
Olaf Kirch authored
A while ago, we fixed a problem in statfs on 64bit system that caused it to return EOVERFLOW when the number of files reported by the underlying file system was -1 (which happens for NFS for instance). The problematic code was this: if (sizeof ubuf->f_blocks == 4) { if ((kbuf->f_blocks | kbuf->f_bfree | kbuf->f_bavail | kbuf->f_files | kbuf->f_ffree) & 0xffffffff00000000ULL) return -EOVERFLOW; ... } The problem was fixed by explicitly allowing f_files and f_ffree to be -1. The same problem exists in fs/compat.c, and the attached patch fixes it in a similar manner. Signed-Off-By:Olaf Kirch <okir@suse.de> Signed-off-by:
-
Oleg Drokin authored
The patch below renames struct reserve_window_node* and rsv_window_add() function to struct ext3_reserve_window_node* and ext3_rsv_window_add(). This eases the task of having several ext3-derived filesystem drivers (with different capabilities) in kernel. Signed-off-by:
-
Bob Breuer authored
I found a solution for the HyperSPARC DMA problems in 2.6. This allows my SS20 with HyperSPARCs to boot to single user. It's not efficient, but I hope it points out whats needed for a proper fix. Seems that the iotlb entries need to flushed to ram or uncached since the iommu changes between 2.5.60 and 2.5.70. The second part seems to be needed to allow consistent sbus dma mappings to be cached on HyperSPARC. I have also tested this change on 2.4.27 with no noticeable difference. Acked-by:
William Irwin <wli@holomorphy.com> Signed-off-by:
-
Nickolai Zeldovich authored
When an ext3 partition is mounted and then quickly unmounted, the journal thread never gets around to checking the JFS_UNMOUNT flag (it immediately goes into a loop waiting for a new sequence number), causing the umount process to hang in journal_kill_thread(). The problem can be easily reproduced by roughly the following steps: dd if=/dev/zero of=/tmp/qf bs=1024k count=10 yes | mke2fs -j /tmp/qf losetup /dev/loop0 /tmp/qf mkdir /mnt/qf mount -t ext3 /dev/loop0 /mnt/qf ; umount /mnt/qf The patch below moves the check for JFS_UNMOUNT to the beginning of the journal thread loop, thereby preventing this race condition. Signed-off-by:
-
Hidetoshi Seto authored
NPTL has 3 control counters (total/wake/woken). so NPTL can know: "how many threads enter to wait"(total), "how many threads receive wake signal"(wake), and "how many threads exit waiting"(woken). Abstraction of pthread_cond_wait and pthread_cond_signal are: A01 pthread_cond_wait { A02 timeout = 0; A03 lock(counters); A04 total++; A05 val = get_from(futex); A06 unlock(counters); A07 A08 sys_futex(futex, FUTEX_WAIT, val, timeout); A09 A10 lock(counters); A11 woken++; A12 unlock(counters); A13 } B01 pthread_cond_signal { B02 lock(counters); B03 if(total>wake) { /* if there is waiter */ B04 wake++; B05 update_val(futex); B06 sys_futex(futex, FUTEX_WAKE, 1); B07 } B08 unlock(counters); B09 } What we have to notice is: FUTEX_WAKE could be called before FUTEX_WAIT have called (at A07). In such case, FUTEX_WAKE will fail if there is no thread in waitqueue. However, since pthread_cond_signal do not only wake++ but also update_val(futex), next FUTEX_WAIT will fail with -EWOULDBLOCK because the val passed to WAIT is now not equal to updated val. Therefore, as the result, it seems that the WAKE wakes the WAIT. === The bug will appear if 2 pair of wait & wake called at (nearly)once: * Assume 4 threads, wait_A, wait_B, wake_X, and wake_Y * counters start from [total/wake/woken]=[0/0/0] * the val of futex starts from (0), update means inclement of the val. * there is no thread in waitqueue on the futex. [simulation] wait_A: calls pthread_cond_wait: total++, prepare to call FUTEX_WAIT with val=0. # status: [1/0/0] (0) queue={}(empty) # wake_X: calls pthread_cond_signal: no one in waitqueue, just wake++ and update futex val. # status: [1/1/0] (1) queue={}(empty) # wait_B: calls pthread_cond_wait: total++, prepare to call FUTEX_WAIT with val=1. # status: [2/1/0] (1) queue={}(empty) # wait_A: calls FUTEX_WAIT with val=0: after queueing, compare val. 0!=1 ... this should be blocked... # status: [2/1/0] (1) queue={A} # wait_B: calls FUTEX_WAIT with val=1: after queueing, compare val. 1==1 ... OK, let's schedule()... # status: [2/1/0] (1) queue={A,B} (B=sleeping) # wake_Y: calls pthread_cond_signal: A is in waitqueue ... dequeue A, wake++ and update futex val. # status: [2/2/0] (2) queue={B} (B=sleeping) # wait_A: end of FUTEX_WAIT with val=0: try to dequeue but already dequeued, return anyway. # status: [2/2/0] (2) queue={B} (B=sleeping) # wait_A: end of pthread_cond_wait: woken++. # status: [2/2/1] (2) queue={B} (B=sleeping) # This is bug: wait_A: wakeup wait_B: sleeping wake_X: wake A wake_Y: wake A again if subsequent wake_Z try to wake B: wake_Z: calls pthread_cond_signal: since total==wake, do nothing. # status: [2/2/1] (2) queue={B} (B=sleeping) # If wait_C comes, B become to can be woken, but C... This bug makes the waitqueue to trap some threads in it all time. ==== > - According to man of futex: > "If the futex was not equal to the expected value, the operation > returns -EWOULDBLOCK." > but now, here is no description about the rare case: > "returns 0 if the futex was not equal to the expected value, but > the process was woken by a FUTEX_WAKE call." > this behavior on rare case causes the hang which I found. So to avoid this problem, my patch shut up the window that you said: > The patch certainly looks sensible - I can see that without the patch, > there is a window in which this process is pointlessly queued up on the > futex and that in this window a wakeup attempt might do a bad thing. ===== In short: There is an un-documented behavior of futex_wait. This behavior misleads NPTL to wake a thread doubly, as the result, causes an application hang. Signed-off-by:Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>, Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it> Cc: Ulrich Drepper <drepper@redhat.com> Using NPTL, getpid() sometimes delivers the wrong pid, since it uses the one buffered in TLS from previous calls. This buffered pid isn't discarded, when a child is created by a clone(). So, as a workaround, UML should use a direct kernel call to bypass the lib. Also, I (Paolo) went replacing all remaining calls of getpid() with os_getpid(), to make sure they use the syscall and not the normal glibc definition. Signed-off-by:Bodo Stroesser <bstroesser@fujitsu-siemens.com> Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it> Signed-off-by:
-
Mikael Starvik authored
Changed maintainer for CRIS architecture to Mikael Starvik. Signed-off-by:
Mikael Starvik <starvik@axis.com> Signed-off-by:
-
Mikael Starvik authored
Update Makefiles under drivers/ to compile CRIS drivers. Signed-off-by:
-
Mikael Starvik authored
Move drivers from arch/cris/arch-v10/drivers/ to drivers/. Signed-off-by:
-
Mikael Starvik authored
Handled console setup arguments on kernel command line. Signed-off-by:
-
Mikael Starvik authored
Added profiler. Optimized MMU refill handling. Improved multiple interrupt handling. Signed-off-by:
-
Mikael Starvik authored
USB host driver for CRIS. Signed-off-by:
-
Mikael Starvik authored
Updated IDE driver for Linux 2.6.9. Signed-off-by:
-
Mikael Starvik authored
Use generic MII interface. Signed-off-by:
-
Mikael Starvik authored
Updates for 2.6.9 in basic character based drivers. Signed-off-by:
-
Mikael Starvik authored
Configuration and build updates for 2.6.9. Signed-off-by:
-
Andrew Morton authored
arch/x86_64/ia32/ia32_aout.c: In function `load_aout_binary': arch/x86_64/ia32/ia32_aout.c:400: error: `IA32_STACK_TOP' undeclared (first use in this function) Cc: <ak@muc.de> Signed-off-by:
-
