ChangeSet@1.1136.1.75 2003-12-07 21:20:48-02:00 willy at debian.org [PATCH] Remove broken file lock accounting On Mon, Jul 01, 2002 at 11:13:55PM +0100, Matthew Wilcox wrote: > The file lock accounting code is horribly broken (and I wrote it, I > should know). I think the best solution to 2.4 is simply to delete it, > at least for BSD-style flocks. > > Patch to follow. Note that 2.5 has the same issue, but I'll fix it > differently there. Here's the patch for 2.4: - --- linux-2.4.23/fs/locks.c.orig Tue Dec 9 00:11:23 2003 +++ linux-2.4.23/fs/locks.c Tue Dec 9 00:13:00 2003 @@ -135,15 +135,9 @@ static kmem_cache_t *filelock_cache; /* Allocate an empty lock structure. */ - -static struct file_lock *locks_alloc_lock(int account) +static struct file_lock *locks_alloc_lock(void) { - - struct file_lock *fl; - - if (account && current->locks >= current->rlim[RLIMIT_LOCKS].rlim_cur) - - return NULL; - - fl = kmem_cache_alloc(filelock_cache, SLAB_KERNEL); - - if (fl) - - current->locks++; - - return fl; + return kmem_cache_alloc(filelock_cache, SLAB_KERNEL); } /* Free a lock which is not in use. */ @@ -153,7 +147,6 @@ BUG(); return; } - - current->locks--; if (waitqueue_active(&fl->fl_wait)) panic("Attempting to free lock with active wait queue"); @@ -220,7 +213,7 @@ /* Fill in a file_lock structure with an appropriate FLOCK lock. */ static struct file_lock *flock_make_lock(struct file *filp, unsigned int type) { - - struct file_lock *fl = locks_alloc_lock(1); + struct file_lock *fl = locks_alloc_lock(); if (fl == NULL) return NULL; @@ -358,7 +351,7 @@ /* Allocate a file_lock initialised to this type of lease */ static int lease_alloc(struct file *filp, int type, struct file_lock **flp) { - - struct file_lock *fl = locks_alloc_lock(1); + struct file_lock *fl = locks_alloc_lock(); if (fl == NULL) return -ENOMEM; @@ -721,7 +714,7 @@ size_t count) { struct file_lock *fl; - - struct file_lock *new_fl = locks_alloc_lock(0); + struct file_lock *new_fl = locks_alloc_lock(); int error; if (new_fl == NULL) @@ -881,8 +874,8 @@ * We may need two file_lock structures for this operation, * so we get them in advance to avoid races. */ - - new_fl = locks_alloc_lock(0); - - new_fl2 = locks_alloc_lock(0); + new_fl = locks_alloc_lock(); + new_fl2 = locks_alloc_lock(); error = -ENOLCK; /* "no luck" */ if (!(new_fl && new_fl2)) goto out_nolock; @@ -1488,7 +1481,7 @@ int fcntl_setlk(unsigned int fd, unsigned int cmd, struct flock *l) { struct file *filp; - - struct file_lock *file_lock = locks_alloc_lock(0); + struct file_lock *file_lock = locks_alloc_lock(); struct flock flock; struct inode *inode; int error; @@ -1644,7 +1637,7 @@ int fcntl_setlk64(unsigned int fd, unsigned int cmd, struct flock64 *l) { struct file *filp; - - struct file_lock *file_lock = locks_alloc_lock(0); + struct file_lock *file_lock = locks_alloc_lock(); struct flock64 flock; struct inode *inode; int error; ChangeSet@1.1136.1.68 2003-12-06 16:25:16-02:00 wli at holomorphy.com [PATCH] Fixup smb_boot_cpus(): Fix HT detection bug On Wed, Dec 03, 2003 at 06:41:36PM -0500, Ethan Weinstein wrote: > Ok, setting CONFIG_NR_CPUS=8 does indeed solve the HT issue, looks like > it was the numbering scheme: Something like this might do the trick. NR_CPUS is already checked indirectly via max_cpus. - -- wli - --- linux-2.4.23/arch/i386/kernel/smpboot.c.orig Tue Dec 9 00:27:10 2003 +++ linux-2.4.23/arch/i386/kernel/smpboot.c Tue Dec 9 00:27:23 2003 @@ -1106,7 +1106,7 @@ */ Dprintk("CPU present map: %lx\n", phys_cpu_present_map); - - for (bit = 0; bit < NR_CPUS; bit++) { + for (bit = 0; bit < BITS_PER_LONG; bit++) { apicid = cpu_present_to_apicid(bit); /* don't try to boot BAD_APICID */ ChangeSet@1.1136.1.73 2003-12-07 15:10:38-02:00 mikulas at cuni.cz [PATCH] from -aa tree: Fix potential fsync() race condition > 00_ll_rw_block-sync-race-1 first appeared in 2.4.21pre4aa3 - 470 bytes > > Add lock_page in ll_rw_block to fix a fs race > condition. Fix suggested by Mikulas Patocka. Yes. You have two inodes placed in the same buffer. Process 1 modifies inode 1 and calls fsync on it. fsync initiates write of the block. ll_rw_block returns, write is in progress. Process 2 modifies inode 2 and calls fsync on it. Filesystem calls ll_rw_block write on the same buffer. ll_rw_block immediatelly returns, because it sees there is already IO on the buffer (there used to be something like if (buffer_locked(bh)) return;). Process 2 waits on buffer. The write finished. Both processes are waken up. Both processes return out of fsync function. Process 2 returns from fsync while it did not write its inode modification to disk --- it waited on process 1's write. - --- linux-2.4.23/drivers/block/ll_rw_blk.c~ Tue Dec 9 00:17:12 2003 +++ linux-2.4.23/drivers/block/ll_rw_blk.c Tue Dec 9 00:17:12 2003 @@ -1377,9 +1377,7 @@ for (i = 0; i < nr; i++) { struct buffer_head *bh = bhs[i]; - - /* Only one thread can actually submit the I/O. */ - - if (test_and_set_bit(BH_Lock, &bh->b_state)) - - continue; + lock_buffer(bh); /* We have the buffer lock */ atomic_inc(&bh->b_count); ChangeSet@1.1136.73.4 2003-12-02 12:02:00-02:00 neilb at unsw.edu.au [PATCH] Drop module count if lockd reclaimer thread failed to start. - --- linux-2.4.23/fs/lockd/clntlock.c~ Tue Dec 9 00:35:29 2003 +++ linux-2.4.23/fs/lockd/clntlock.c Tue Dec 9 00:35:29 2003 @@ -188,7 +188,8 @@ nlmclnt_prepare_reclaim(host, newstate); nlm_get_host(host); MOD_INC_USE_COUNT; - - kernel_thread(reclaimer, host, CLONE_SIGNAL); + if(kernel_thread(reclaimer, host, CLONE_SIGNAL) < 0) + MOD_DEC_USE_COUNT; } } ChangeSet@1.1136.1.65 2003-12-05 15:53:34-02:00 mikpe at se [PATCH] fix reboot/no_idt bug When compiling 2.4.23 with gcc-3.3.2, gcc generates the following warning for arch/i386/kernel/process.c: process.c: In function `machine_restart': process.c:427: warning: use of memory input without lvalue in asm operand 0 is deprecated The warning identifies a real bug. no_idt is passed to lidt with an "m" constraint, which requires an l-value. Since no_idt is faked as an array, gcc creates an anonymous variable pointing to no_idt and passes that to lidt(*), so at runtime lidt sees the wrong address. Not good. (The bug, while real, is unlikely to trigger since it sits in an infrequently used path in the reboot code.) The fix is to make no_idt a struct (and thus an l-lvalue) like the other gdt/idt descriptors. This patch is a backport of the fix Linus made for the same bug in 2.6.0-test4. [Andi: x86-64 appears to have the same bug] (*) Verified by inspection of the assembly code. /Mikael - --- linux-2.4.23/arch/i386/kernel/process.c.orig Tue Dec 9 00:29:52 2003 +++ linux-2.4.23/arch/i386/kernel/process.c Tue Dec 9 00:30:46 2003 @@ -153,7 +153,6 @@ __setup("idle=", idle_setup); - -static long no_idt[2]; static int reboot_mode; int reboot_thru_bios; @@ -224,7 +223,8 @@ unsigned long long * base __attribute__ ((packed)); } real_mode_gdt = { sizeof (real_mode_gdt_entries) - 1, real_mode_gdt_entries }, - -real_mode_idt = { 0x3ff, 0 }; +real_mode_idt = { 0x3ff, 0 }, +no_idt = { 0, 0 }; /* This is 16-bit protected mode code to disable paging and the cache, switch to real mode and jump to the BIOS reset code. ChangeSet@1.1136.78.2 2003-12-07 12:43:34-02:00 wli at holomorphy.com [PATCH] out_of_memory() locking On Sun, Nov 30, 2003 at 08:18:02AM -0800, William Lee Irwin III wrote: > (1) the timestamps/etc. weren't locked, and when cpus raced, it caused > false OOM kills > (2) the mm could go away while scanning the tasklist, causing the thing > to try to kill kernel threads > Here's a preliminary backport (please do _NOT_ apply until I or someone > tests it) for you to comment on. Basically, do you want (1) and (2) > split out, is the basic thing okay, etc.? out_of_memory()'s operational variables are not locked, and can be reset by multiple cpus simultaneously, causing false OOM kills. This patch adds an oom_lock to out_of_memory() to protect its operational variables. - -- wli - --- linux-2.4.23/mm/oom_kill.c.orig Tue Dec 9 00:20:47 2003 +++ linux-2.4.23/mm/oom_kill.c Tue Dec 9 00:24:20 2003 @@ -202,6 +202,11 @@ */ void out_of_memory(void) { + /* + * oom_lock protects out_of_memory()'s static variables. + * It's a global lock; this is not performance-critical. + */ + static spinlock_t oom_lock = SPIN_LOCK_UNLOCKED; static unsigned long first, last, count, lastkill; unsigned long now, since; @@ -211,6 +216,7 @@ if (nr_swap_pages > 0) return; + spin_lock(&oom_lock); now = jiffies; since = now - last; last = now; @@ -229,14 +235,14 @@ */ since = now - first; if (since < HZ) - - return; + goto out_unlock; /* * If we have gotten only a few failures, * we're not really oom. */ if (++count < 10) - - return; + goto out_unlock; /* * If we just killed a process, wait a while @@ -245,17 +251,25 @@ */ since = now - lastkill; if (since < HZ*5) - - return; + goto out_unlock; /* * Ok, really out of memory. Kill something. */ lastkill = now; + + /* oom_kill() can sleep */ + spin_unlock(&oom_lock); oom_kill(); + spin_lock(&oom_lock); reset: - - first = now; + if (first < now) + first = now; count = 0; + +out_unlock: + spin_unlock(&oom_lock); } #endif /* Unused file */ ChangeSet@1.1136.1.61 2003-12-01 12:43:59-07:00 davidm at com[helgaas] ia64: Fix a bug in sigtramp() which corrupted ar.rnat when unwinding across a signal trampoline (in user space). Reported by Laurent Morichetti. arch/ia64/kernel/gate.S@1.11 2003-12-01 05:43:29-07:00 davidm at com[helgaas] (__kernel_sigtramp): Replace usage of p8 with p1. We must use a preserved predicate for the .spillsp.p directive, otherwise, the predicate may have been clobbered by the time the unwinder looks at it. Fortunately, we can just use p1 because the entire pr register is already saved/restored by the kernel. - --- linux-2.4.23/arch/ia64/kernel/gate.S~ Tue Dec 9 00:46:11 2003 +++ linux-2.4.23/arch/ia64/kernel/gate.S Tue Dec 9 00:46:11 2003 @@ -88,10 +88,10 @@ ld8 r15=[base1] // get address of new RBS base (or NULL) cover // push args in interrupted frame onto backing store ;; - - cmp.ne p8,p0=r15,r0 // do we need to switch the rbs? + cmp.ne p1,p0=r15,r0 // do we need to switch rbs? (note: pr is saved by kernel) mov.m r9=ar.bsp // fetch ar.bsp - - .spillsp.p p8, ar.rnat, RNAT_OFF+SIGCONTEXT_OFF - -(p8) br.cond.spnt setup_rbs // yup -> (clobbers r14, r15, and r16) + .spillsp.p p1, ar.rnat, RNAT_OFF+SIGCONTEXT_OFF +(p1) br.cond.spnt setup_rbs // yup -> (clobbers p8, r14, r15, and r16) back_from_setup_rbs: alloc r8=ar.pfs,0,0,3,0 ld8 out0=[base0],16 // load arg0 (signum) @@ -130,8 +130,8 @@ ld8 r15=[base0],(CFM_OFF-BSP_OFF) // fetch sc_ar_bsp and advance to CFM_OFF mov r14=ar.bsp ;; - - cmp.ne p8,p0=r14,r15 // do we need to restore the rbs? - -(p8) br.cond.spnt restore_rbs // yup -> (clobbers r14-r18, f6 & f7) + cmp.ne p1,p0=r14,r15 // do we need to restore the rbs? +(p1) br.cond.spnt restore_rbs // yup -> (clobbers p8, r14-r18, f6 & f7) ;; back_from_restore_rbs: adds base0=(FR6_OFF+SIGCONTEXT_OFF),sp ChangeSet@1.1136.73.2 2003-12-02 11:58:06-02:00 neilb at unsw.edu.au [PATCH] Make root a special case for per-user process limits. This is needed because when a setuid-root program calls setuid(0) to become really-root, p->user becomes root_user, but ->rlim stays as the original user's limit, and now the process cannot fork - becuase root has more processes than the original user had. The real problem is that NPROC is not really a per-process limit, but its a per-user limit, and including it with the rlim structure was not a good idea :-( This fix is already in 2.6 - --- linux-2.4.23/kernel/fork.c.orig Tue Dec 9 00:38:16 2003 +++ linux-2.4.23/kernel/fork.c Tue Dec 9 00:38:59 2003 @@ -669,6 +669,7 @@ * than the amount of processes root is running. -- Rik */ if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur + && p->user != &root_user && !capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE)) goto bad_fork_free; As per http://lkml.org/lkml/2003/12/1/150 diff -urN --exclude=CVS --exclude=.cvsignore linux-2.4.23/include/linux/mc146818rtc.h linux-cvs-2.4.23/include/linux/mc146818rtc.h - --- linux-2.4.23/include/linux/mc146818rtc.h 2001-11-22 20:46:58.000000000 +0100 +++ linux-cvs-2.4.23/include/linux/mc146818rtc.h 2003-11-28 15:09:41.000000000 +0100 @@ -98,4 +98,12 @@ #define BIN_TO_BCD(val) ((val)=(((val)/10)<<4) + (val)%10) #endif +#ifndef RTC_IO_EXTENT +#define RTC_IO_EXTENT 0x10 /* Only really two ports, but... */ +#endif + +#ifndef RTC_IOMAPPED +#define RTC_IOMAPPED 1 /* Default to I/O mapping. */ +#endif + #endif /* _MC146818RTC_H */ - From linux-kernel@vger.kernel.org Thu Dec 18 21:50:26 2003 Date: Tue, 16 Dec 2003 15:59:16 +0000 From: Linux Kernel Mailing List To: bk-commits-24@vger.kernel.org Subject: [PATCH] duplicate PID fix ChangeSet 1.1302, 2003/12/16 13:59:16-02:00, t-kochi@bq.jp.nec.com [PATCH] duplicate PID fix Hello Marcelo, This fix was sent to lkml in April, and was merged to -ac tree, but is not merged in the main tree yet. Please consider taking this in. Without this, duplicate pids can be allocated, which will make one of them unkillable (signals are deliverd to only one of them), and this can be exploitable (I don't know for sure, but maybe, like brk() ;) This situation happens only when all pid space is full. Usually, users cannot fork processes more than 32768 (PID_MAX), but default user limit of max processes can be more than PID_MAX on large memory machines such as 64bit platforms (although it's adjustable by threads-max sysctl). This patch modifies common code and affects all architectures, but modifies code only executed when no pid is available, so it doesn't hurt any normal path anyway. (BTW, once I sent this patch to Rusty's Trivial patch monkey, but his reply was non-trivial, and he also said this is scary ;) The details are described below: In get_pid(), an available pid is searched through all task_structs even when there is no available pid. If a new pid is not available, the kernel exits the loop with static variable 'next_safe' untouched, which usually is no problem. spin_lock(&lastpid_lock); beginpid = last_pid; if((++last_pid) & 0xffff8000) { last_pid = 300; /* Skip daemons etc. */ goto inside; } if(last_pid >= next_safe) { inside: next_safe = PID_MAX; read_lock(&tasklist_lock); repeat: for_each_task(p) { if(p->pid == last_pid || p->pgrp == last_pid || p->tgid == last_pid || p->session == last_pid) { <= (A) if(++last_pid >= next_safe) { <= (B) if(last_pid & 0xffff8000) last_pid = 300; next_safe = PID_MAX; } if(unlikely(last_pid == beginpid)) <= (C) goto nomorepids; goto repeat; } if(p->pid > last_pid && next_safe > p->pid) next_safe = p->pid; if(p->pgrp > last_pid && next_safe > p->pgrp) next_safe = p->pgrp; if(p->tgid > last_pid && next_safe > p->tgid) next_safe = p->tgid; if(p->session > last_pid && next_safe > p->session) next_safe = p->session; } In a rare case, both (B) and (C) can be true and then, next_safe will remain PID_MAX (32768). If that happens, following get_pid() will always succeed until last_pid reaches 32768 and there may be many duplicate pids. For example, this happens when * PID space are full (300-32767 are all occupied) * the last pid allocated is 10000 * task list chain is like: ...(pids < 9999), 9999, ...(pids 300~9998, 10001~32767)... , 10000 The loop starts searching an available pid with beginpid=10000 and last_pid=10001. last_pid is incremented until it gets PID_MAX and then wraps around to 300, then is incremented again. At the point that p->pid=9999 is found in tasklist (condition (A)), last_pid = 9999 next_safe <= 9998 therefore condition (B) is true, and then last_pid = 10000 next_safe = PID_MAX and then, condition (C) is also true, and exits the loop. To protect this case is simple; when the condition (C) is true, set next_safe to 0 or any safe value to guarantee that a free pid will be searched through next time. Thanks, # This patch includes the following deltas: # ChangeSet 1.1301 -> 1.1302 # kernel/fork.c 1.31 -> 1.32 # fork.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletion(-) diff -Nru a/kernel/fork.c b/kernel/fork.c - --- a/kernel/fork.c Tue Dec 16 09:02:43 2003 +++ b/kernel/fork.c Tue Dec 16 09:02:43 2003 @@ -114,8 +114,10 @@ last_pid = 300; next_safe = PID_MAX; } - - if(unlikely(last_pid == beginpid)) + if(unlikely(last_pid == beginpid)) { + next_safe = 0; goto nomorepids; + } goto repeat; } if(p->pid > last_pid && next_safe > p->pid) - - To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - From linux-kernel@vger.kernel.org Thu Dec 18 21:43:15 2003 Date: Mon, 15 Dec 2003 04:44:43 +0000 From: Linux Kernel Mailing List To: bk-commits-24@vger.kernel.org Subject: [PPC64] Fix save_flags/restore_flags on iSeries. ChangeSet 1.1270.3.9, 2003/12/15 15:44:43+11:00, engebret@us.ibm.com [PPC64] Fix save_flags/restore_flags on iSeries. # This patch includes the following deltas: # ChangeSet 1.1270.3.8 -> 1.1270.3.9 # arch/ppc64/kernel/misc.S 1.8 -> 1.9 # misc.S | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff -Nru a/arch/ppc64/kernel/misc.S b/arch/ppc64/kernel/misc.S - --- a/arch/ppc64/kernel/misc.S Mon Dec 15 07:03:59 2003 +++ b/arch/ppc64/kernel/misc.S Mon Dec 15 07:03:59 2003 @@ -69,16 +69,14 @@ _GLOBAL(__no_use_save_flags) mfspr r4,SPRG3 lbz r3,PACAPROCENABLED(r4) + /* shift into position of MSR.EE */ + sldi r3,r3,15 blr - -/* void __no_use_restore_flags(unsigned long flags) */ +/* void __no_use_restore_flags(unsigned long flags) */ _GLOBAL(__no_use_restore_flags) - -/* - - * Just set/clear the MSR_EE bit through restore/flags but do not - - * change anything else. This is needed by the RT system and makes - - * sense anyway. - - * -- Cort - - */ + /* shift from position of MSR.EE */ + srdi r3,r3,15 mfspr r6,SPRG3 lbz r5,PACAPROCENABLED(r6) /* Check if things are setup the way we want _already_. */ @@ -104,6 +102,8 @@ lbz r3,PACAPROCENABLED(r5) li r4,0 stb r4,PACAPROCENABLED(r5) + /* shift into position of MSR.EE */ + sldi r3,r3,15 blr /* Done */ _GLOBAL(__no_use_sti) - - To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - From linux-kernel@vger.kernel.org Thu Dec 18 21:41:34 2003 Date: Fri, 12 Dec 2003 20:18:04 +0000 From: Linux Kernel Mailing List To: bk-commits-24@vger.kernel.org Subject: [PATCH] USB: MCT-U232 Patch for cts ChangeSet 1.1289, 2003/12/12 12:18:04-08:00, marr@flex.com [PATCH] USB: MCT-U232 Patch for cts Brief Patch Description: Fix a problem in the 'mct_u232' driver whereby output data gets held up in the USB/RS-232 adapter for RS-232 devices which don't assert the 'CTS' signal. Background: The Belkin F5U109 is a 9-pin USB/RS-232 adapter that is supported by the existing 'mct_u232' kernel module.  Recently, I've been testing it under the 2.4.22 (Slackware 9.1) kernel and the 2.6.0-test9 kernel. I've connected a Garmin 'GPS35 TracPak' GPS receiver (RS-232 interface) and an ordinary RS-232 external modem to my PC's USB port via the Belkin F5U109 adapter. Problem: Although _reads_ from either of the RS-232 devices mentioned above work fine via the Belkin adapter, _writes_ to the GPS receiver are not being seen by the GPS.  Writes to the modem, however, work perfectly. Aside: The 'Linux USB Users' archives show that at least one other person (circa May 2002) had the exact same problem I'm having, but it sounds like no solution was ever determined because the person in question just bought a different USB/RS-232 adapter. Investigation: Using the 'seyon' terminal emulator in Linux and a crude hardware RS-232 "breakout box" that I hacked together, I've determined that the problem is related to the RTS/CTS RS-232 hardware handshaking. After further investigation, I've concluded that RS-232 devices which do not assert the 'Clear To Send' ('CTS') signal prevent the Belkin F5U109 adapter from transmitting data to the RS-232 device when the current (version 1.1) 'mct_u232' module is used. The data gets "queued up" (up to a point -- 16 bytes, I think) in the adapter but never transmitted. Since this GPS receiver works perfectly (reads and writes) when connected to a PC running W98se using the same Belkin adapter and the Belkin-supplied Windows driver, the Linux driver became suspect. After some testing with SniffUSB, I found that the Windows driver sends a couple of unique undocumented USB 'device requests' that the Linux driver does not. As it turns out, the second of those 2 requests is critical in making the adapter transmit data to a device which doesn't assert 'CTS'. For completeness, the Windows driver in use was determined from the 'Device Manager', 'Driver File Details' page:    U2SPORT.VXD    Provider: Magic Control Technology    File version: 1.21P.0104 for Win98/Me Solution: My patch adds the 2 missing USB 'device request' commands right after a baud-change command. This mimics the operation of the W98 driver. Unfortunately, after much testing, I found no other operation (besides a baud-change request) under Windows that triggers either of these 2 'device request' commands. This makes it impossible to fully document the behavior of these requests, but I've made entries for them alongside the others in the 'mct_u232.h' file. Purely for clarity, the patch also modifies various comments in 'mct_u232.h', mostly to reflect proper sizes of the various 'USB Device Request' fields per the USB 1.1 specification. The patch also updates the version number of the driver, corrects a minor typographical error, and documents a difference in the length of the data in a 'baud rate change' command for certain adapters which use a coded baud-rate rather than the conventional RS-232 baud rate divisor. # This patch includes the following deltas: # ChangeSet 1.1288 -> 1.1289 # drivers/usb/serial/mct_u232.c 1.18 -> 1.19 # drivers/usb/serial/mct_u232.h 1.3 -> 1.4 # mct_u232.c | 37 +++++++++++++++++++++- mct_u232.h | 101 ++++++++++++++++++++++++++++++++++++++++++++++++------------- 2 files changed, 116 insertions(+), 22 deletions(-) diff -Nru a/drivers/usb/serial/mct_u232.c b/drivers/usb/serial/mct_u232.c - --- a/drivers/usb/serial/mct_u232.c Mon Dec 15 07:03:29 2003 +++ b/drivers/usb/serial/mct_u232.c Mon Dec 15 07:03:29 2003 @@ -24,6 +24,11 @@ * Basic tests have been performed with minicom/zmodem transfers and * modem dialing under Linux 2.4.0-test10 (for me it works fine). * + * 04-Nov-2003 Bill Marr + * - Mimic Windows driver by sending 2 USB 'device request' messages + * following normal 'baud rate change' message. This allows data to be + * transmitted to RS-232 devices which don't assert the 'CTS' signal. + * * 10-Nov-2001 Wolfgang Grandegger * - Fixed an endianess problem with the baudrate selection for PowerPC. * @@ -85,7 +90,7 @@ /* * Version Information */ - -#define DRIVER_VERSION "v1.1" +#define DRIVER_VERSION "v1.2" #define DRIVER_AUTHOR "Wolfgang Grandegger " #define DRIVER_DESC "Magic Control Technology USB-RS232 converter driver" @@ -201,6 +206,7 @@ { unsigned int divisor; int rc; + unsigned char zero_byte = 0; divisor = cpu_to_le32(mct_u232_calculate_baud_rate(serial, value)); rc = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0), MCT_U232_SET_BAUD_RATE_REQUEST, @@ -210,6 +216,35 @@ if (rc < 0) err("Set BAUD RATE %d failed (error = %d)", value, rc); dbg("set_baud_rate: value: %d, divisor: 0x%x", value, divisor); + + /* Mimic the MCT-supplied Windows driver (version 1.21P.0104), which + always sends two extra USB 'device request' messages after the + 'baud rate change' message. The actual functionality of the + request codes in these messages is not fully understood but these + particular codes are never seen in any operation besides a baud + rate change. Both of these messages send a single byte of data + whose value is always zero. The second of these two extra messages + is required in order for data to be properly written to an RS-232 + device which does not assert the 'CTS' signal. */ + + rc = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0), + MCT_U232_SET_UNKNOWN1_REQUEST, + MCT_U232_SET_REQUEST_TYPE, + 0, 0, &zero_byte, MCT_U232_SET_UNKNOWN1_SIZE, + WDR_TIMEOUT); + if (rc < 0) + err("Sending USB device request code %d failed (error = %d)", + MCT_U232_SET_UNKNOWN1_REQUEST, rc); + + rc = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0), + MCT_U232_SET_UNKNOWN2_REQUEST, + MCT_U232_SET_REQUEST_TYPE, + 0, 0, &zero_byte, MCT_U232_SET_UNKNOWN2_SIZE, + WDR_TIMEOUT); + if (rc < 0) + err("Sending USB device request code %d failed (error = %d)", + MCT_U232_SET_UNKNOWN2_REQUEST, rc); + return rc; } /* mct_u232_set_baud_rate */ diff -Nru a/drivers/usb/serial/mct_u232.h b/drivers/usb/serial/mct_u232.h - --- a/drivers/usb/serial/mct_u232.h Mon Dec 15 07:03:29 2003 +++ b/drivers/usb/serial/mct_u232.h Mon Dec 15 07:03:29 2003 @@ -57,6 +57,21 @@ #define MCT_U232_SET_MODEM_CTRL_REQUEST 10 /* Set Modem Control Register (MCR) */ #define MCT_U232_SET_MODEM_CTRL_SIZE 1 +/* This USB device request code is not well understood. It is transmitted by + the MCT-supplied Windows driver whenever the baud rate changes. +*/ +#define MCT_U232_SET_UNKNOWN1_REQUEST 11 /* Unknown functionality */ +#define MCT_U232_SET_UNKNOWN1_SIZE 1 + +/* This USB device request code is not well understood. It is transmitted by + the MCT-supplied Windows driver whenever the baud rate changes. + + Without this USB device request, the USB/RS-232 adapter will not write to + RS-232 devices which do not assert the 'CTS' signal. +*/ +#define MCT_U232_SET_UNKNOWN2_REQUEST 12 /* Unknown functionality */ +#define MCT_U232_SET_UNKNOWN2_SIZE 1 + /* * Baud rate (divisor) */ @@ -137,22 +152,31 @@ * Baud rate (divisor) * ------------------- * - - * BmRequestType: 0x4 (0100 0000B) - - * bRequest: 0x5 - - * wValue: 0x0 - - * wIndex: 0x0 - - * wLength: 0x4 + * BmRequestType: 0x40 (0100 0000B) + * bRequest: 0x05 + * wValue: 0x0000 + * wIndex: 0x0000 + * wLength: 0x0004 * Data: divisor = 115200 / baud_rate * + * SniffUSB observations (Nov 2003): Contrary to the 'wLength' value of 4 + * shown above, observations with a Belkin F5U109 adapter, using the + * MCT-supplied Windows98 driver (U2SPORT.VXD, "File version: 1.21P.0104 for + * Win98/Me"), show this request has a length of 1 byte, presumably because + * of the fact that the Belkin adapter and the 'Sitecom U232-P25' adapter + * use a baud-rate code instead of a conventional RS-232 baud rate divisor. + * The current source code for this driver does not reflect this fact, but + * the driver works fine with this adapter/driver combination nonetheless. + * * * Line Control Register (LCR) * --------------------------- * - - * BmRequestType: 0x4 (0100 0000B) 0xc (1100 0000B) - - * bRequest: 0x7 0x6 - - * wValue: 0x0 - - * wIndex: 0x0 - - * wLength: 0x1 + * BmRequestType: 0x40 (0100 0000B) 0xc0 (1100 0000B) + * bRequest: 0x07 0x06 + * wValue: 0x0000 + * wIndex: 0x0000 + * wLength: 0x0001 * Data: LCR (see below) * * Bit 7: Divisor Latch Access Bit (DLAB). When set, access to the data @@ -186,18 +210,18 @@ * * SniffUSB observations: Bit 7 seems not to be used. There seem to be two bugs * in the Win98 driver: the break does not work (bit 6 is not asserted) and the - - * sticky parity bit is not cleared when set once. The LCR can also be read + * stick parity bit is not cleared when set once. The LCR can also be read * back with USB request 6 but this has never been observed with SniffUSB. * * * Modem Control Register (MCR) * ---------------------------- * - - * BmRequestType: 0x4 (0100 0000B) - - * bRequest: 0xa - - * wValue: 0x0 - - * wIndex: 0x0 - - * wLength: 0x1 + * BmRequestType: 0x40 (0100 0000B) + * bRequest: 0x0a + * wValue: 0x0000 + * wIndex: 0x0000 + * wLength: 0x0001 * Data: MCR (Bit 4..7, see below) * * Bit 7: Reserved, always 0. @@ -226,11 +250,11 @@ * Modem Status Register (MSR) * --------------------------- * - - * BmRequestType: 0xc (1100 0000B) - - * bRequest: 0x2 - - * wValue: 0x0 - - * wIndex: 0x0 - - * wLength: 0x1 + * BmRequestType: 0xc0 (1100 0000B) + * bRequest: 0x02 + * wValue: 0x0000 + * wIndex: 0x0000 + * wLength: 0x0001 * Data: MSR (see below) * * Bit 7: Data Carrier Detect (CD). Reflects the state of the DCD line on the @@ -285,6 +309,41 @@ * SniffUSB observations: the LSR is returned as second byte on the interrupt-in * endpoint 0x83 to signal error conditions. Such errors have been seen with * minicom/zmodem transfers (CRC errors). + * + * + * Unknown #1 + * ------------------- + * + * BmRequestType: 0x40 (0100 0000B) + * bRequest: 0x0b + * wValue: 0x0000 + * wIndex: 0x0000 + * wLength: 0x0001 + * Data: 0x00 + * + * SniffUSB observations (Nov 2003): With the MCT-supplied Windows98 driver + * (U2SPORT.VXD, "File version: 1.21P.0104 for Win98/Me"), this request + * occurs immediately after a "Baud rate (divisor)" message. It was not + * observed at any other time. It is unclear what purpose this message + * serves. + * + * + * Unknown #2 + * ------------------- + * + * BmRequestType: 0x40 (0100 0000B) + * bRequest: 0x0c + * wValue: 0x0000 + * wIndex: 0x0000 + * wLength: 0x0001 + * Data: 0x00 + * + * SniffUSB observations (Nov 2003): With the MCT-supplied Windows98 driver + * (U2SPORT.VXD, "File version: 1.21P.0104 for Win98/Me"), this request + * occurs immediately after the 'Unknown #1' message (see above). It was + * not observed at any other time. It is unclear what other purpose (if + * any) this message might serve, but without it, the USB/RS-232 adapter + * will not write to RS-232 devices which do not assert the 'CTS' signal. * * * Flow control - - To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - From cel@citi.umich.edu Thu Dec 18 22:13:19 2003 Date: Thu, 18 Dec 2003 16:34:58 -0500 (EST) From: Chuck Lever To: Marcelo Tosatti Cc: Linux Kernel Mailing List , Trond Myklebust , Steve Dickson , greg.marsden@oracle.com Subject: [PATCH] NFS O_DIRECT offset wrap bug hi marcelo- here's an obvious mistake i made in the NFS O_DIRECT implementation. a missing type cast causes the offset of direct read and write requests to wrap at 4GB. please include this in 2.4.24-pre2. as far as i can tell, this is not a problem for 2.6 NFS O_DIRECT. diff -X ../dont-diff -Naurp 00-stock/fs/nfs/direct.c 01-direct-offset/fs/nfs/direct.c - --- 00-stock/fs/nfs/direct.c 2003-08-25 07:44:43.000000000 -0400 +++ 01-direct-offset/fs/nfs/direct.c 2003-12-18 16:28:20.000000000 -0500 @@ -354,7 +354,7 @@ nfs_direct_IO(int rw, struct file *file, size_t count = iobuf->length; struct dentry *dentry = file->f_dentry; struct inode *inode = dentry->d_inode; - - loff_t offset = blocknr << inode->i_blkbits; + loff_t offset = (loff_t) blocknr << inode->i_blkbits; switch (rw) { case READ: - Chuck Lever - -- corporate: personal: - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - From linux-kernel@vger.kernel.org Thu Dec 18 21:47:47 2003 Date: Mon, 15 Dec 2003 05:42:19 +0000 From: Linux Kernel Mailing List To: bk-commits-24@vger.kernel.org Subject: [PPC64] Fix compile error in arch/ppc64/kernel/pmc.c. ChangeSet 1.1270.3.10, 2003/12/15 16:42:19+11:00, paulus@quango.ozlabs.ibm.com [PPC64] Fix compile error in arch/ppc64/kernel/pmc.c. # This patch includes the following deltas: # ChangeSet 1.1270.3.9 -> 1.1270.3.10 # arch/ppc64/kernel/pmc.c 1.5 -> 1.6 # include/asm-ppc64/mmu.h 1.4 -> 1.5 # arch/ppc64/kernel/pmc.c | 5 ++--- include/asm-ppc64/mmu.h | 3 ++- 2 files changed, 4 insertions(+), 4 deletions(-) diff -Nru a/arch/ppc64/kernel/pmc.c b/arch/ppc64/kernel/pmc.c - --- a/arch/ppc64/kernel/pmc.c Mon Dec 15 07:04:01 2003 +++ b/arch/ppc64/kernel/pmc.c Mon Dec 15 07:04:01 2003 @@ -74,7 +74,6 @@ page_table_lock : SPIN_LOCK_UNLOCKED}; extern spinlock_t hash_table_lock[]; - -extern inline unsigned long get_lock_slot(unsigned long vpn); char * ppc64_pmc_stab(int file) @@ -241,7 +240,7 @@ lock_slot = get_lock_slot(vpn); rpn = pa >> PAGE_SHIFT; - - spin_lock(&hash_table_lock[lock_slot].lock); + spin_lock(&hash_table_lock[lock_slot]); /* Get a pointer to the linux page table entry for this page * allocating pmd or pte pages along the way as needed. Note * that the pmd & pte pages are not themselfs bolted. @@ -266,7 +265,7 @@ *ptep = pte; - - spin_unlock(&hash_table_lock[lock_slot].lock); + spin_unlock(&hash_table_lock[lock_slot]); } spin_unlock(&btmalloc_mm.page_table_lock); diff -Nru a/include/asm-ppc64/mmu.h b/include/asm-ppc64/mmu.h - --- a/include/asm-ppc64/mmu.h Mon Dec 15 07:04:01 2003 +++ b/include/asm-ppc64/mmu.h Mon Dec 15 07:04:01 2003 @@ -180,7 +180,7 @@ extern HTAB htab_data; #include - -#include +#include typedef struct { spinlock_t lock; } ____cacheline_aligned hash_table_lock_t; @@ -191,6 +191,7 @@ unsigned long prpn, unsigned hash, void * ptep, unsigned hpteflags, unsigned bolted ); +unsigned long get_lock_slot(unsigned long vpn); #define PD_SHIFT (10+12) /* Page directory */ #define PD_MASK 0x02FF - - To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - From linux-kernel@vger.kernel.org Thu Dec 18 21:48:23 2003 Date: Mon, 15 Dec 2003 03:20:20 +0000 From: Linux Kernel Mailing List To: bk-commits-24@vger.kernel.org Subject: [PPC64] Fix smp_call_function so we don't crash if an IPI is very late. ChangeSet 1.1270.3.2, 2003/12/15 14:20:20+11:00, olof@austin.ibm.com [PPC64] Fix smp_call_function so we don't crash if an IPI is very late. # This patch includes the following deltas: # ChangeSet 1.1270.3.1 -> 1.1270.3.2 # arch/ppc64/kernel/smp.c 1.4 -> 1.5 # smp.c | 18 +++++++++++++++--- 1 files changed, 15 insertions(+), 3 deletions(-) diff -Nru a/arch/ppc64/kernel/smp.c b/arch/ppc64/kernel/smp.c - --- a/arch/ppc64/kernel/smp.c Mon Dec 15 07:03:47 2003 +++ b/arch/ppc64/kernel/smp.c Mon Dec 15 07:03:47 2003 @@ -564,6 +564,7 @@ ret = 0; out: + call_data = NULL; HMT_medium(); spin_unlock_bh(&call_lock); return ret; @@ -571,9 +572,20 @@ void smp_call_function_interrupt(void) { - - void (*func) (void *info) = call_data->func; - - void *info = call_data->info; - - int wait = call_data->wait; + void (*func) (void *info); + void *info; + int wait; + + + /* call_data will be NULL if the sender timed out while + * waiting on us to receive the call. + */ + if (!call_data) + return; + + func = call_data->func; + info = call_data->info; + wait = call_data->wait; /* * Notify initiating CPU that I've grabbed the data and am - - To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - From linux-kernel@vger.kernel.org Thu Dec 18 21:45:37 2003 Date: Sun, 14 Dec 2003 05:52:29 +0000 From: Linux Kernel Mailing List To: bk-commits-24@vger.kernel.org Subject: [SPARC32]: Fix build after asm/system.h include was added to linux/spinlock.h ChangeSet 1.1270.1.7, 2003/12/13 21:52:29-08:00, davem@nuts.ninka.net [SPARC32]: Fix build after asm/system.h include was added to linux/spinlock.h - Do not include asm/oplib.h in system.h - Remove system.h's halt() macro, prom_halt() is equivalent so replace the two users of halt() with that. - Put 'romvec' extern decl where it belongs, in openprom.h Based upon a patch from Rob Radez. # This patch includes the following deltas: # ChangeSet 1.1270.1.6 -> 1.1270.1.7 # include/asm-sparc/openprom.h 1.1 -> 1.2 # include/asm-sparc/system.h 1.7 -> 1.8 # arch/sparc/kernel/devices.c 1.4 -> 1.5 # include/asm-sparc/oplib.h 1.3 -> 1.4 # arch/sparc/kernel/ioport.c 1.8 -> 1.9 # arch/sparc/kernel/devices.c | 2 +- arch/sparc/kernel/ioport.c | 2 +- include/asm-sparc/openprom.h | 2 ++ include/asm-sparc/oplib.h | 3 --- include/asm-sparc/system.h | 4 ---- 5 files changed, 4 insertions(+), 9 deletions(-) diff -Nru a/arch/sparc/kernel/devices.c b/arch/sparc/kernel/devices.c - --- a/arch/sparc/kernel/devices.c Mon Dec 15 07:03:40 2003 +++ b/arch/sparc/kernel/devices.c Mon Dec 15 07:03:40 2003 @@ -72,7 +72,7 @@ if (linux_num_cpus == 0) { printk("No CPU nodes found, cannot continue.\n"); /* Probably a sun4e, Sun is trying to trick us ;-) */ - - halt(); + prom_halt(); } printk("Found %d CPU prom device tree node(s).\n", linux_num_cpus); } diff -Nru a/arch/sparc/kernel/ioport.c b/arch/sparc/kernel/ioport.c - --- a/arch/sparc/kernel/ioport.c Mon Dec 15 07:03:40 2003 +++ b/arch/sparc/kernel/ioport.c Mon Dec 15 07:03:40 2003 @@ -760,7 +760,7 @@ default: printk("ioport_init: cpu type %d is unknown.\n", sparc_cpu_model); - - halt(); + prom_halt(); }; } diff -Nru a/include/asm-sparc/openprom.h b/include/asm-sparc/openprom.h - --- a/include/asm-sparc/openprom.h Mon Dec 15 07:03:40 2003 +++ b/include/asm-sparc/openprom.h Mon Dec 15 07:03:40 2003 @@ -169,6 +169,8 @@ int (*v3_cpuresume)(unsigned int whichcpu); }; +extern struct linux_romvec *romvec; + /* Routines for traversing the prom device tree. */ struct linux_nodeops { int (*no_nextnode)(int node); diff -Nru a/include/asm-sparc/oplib.h b/include/asm-sparc/oplib.h - --- a/include/asm-sparc/oplib.h Mon Dec 15 07:03:40 2003 +++ b/include/asm-sparc/oplib.h Mon Dec 15 07:03:40 2003 @@ -11,9 +11,6 @@ #include #include - -/* The master romvec pointer... */ - -extern struct linux_romvec *romvec; - - /* Enumeration to describe the prom major version we have detected. */ enum prom_major_version { PROM_V0, /* Original sun4c V0 prom */ diff -Nru a/include/asm-sparc/system.h b/include/asm-sparc/system.h - --- a/include/asm-sparc/system.h Mon Dec 15 07:03:40 2003 +++ b/include/asm-sparc/system.h Mon Dec 15 07:03:40 2003 @@ -10,7 +10,6 @@ #ifdef __KERNEL__ #include - -#include #include #include #include @@ -51,9 +50,6 @@ extern unsigned long empty_bad_page; extern unsigned long empty_bad_page_table; extern unsigned long empty_zero_page; - - - -extern struct linux_romvec *romvec; - -#define halt() romvec->pv_halt() /* When a context switch happens we must flush all user windows so that * the windows of the current process are flushed onto its stack. This - - To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - From linux-kernel@vger.kernel.org Thu Dec 18 21:38:26 2003 Date: Fri, 12 Dec 2003 18:18:02 +0000 From: Linux Kernel Mailing List To: bk-commits-24@vger.kernel.org Subject: [PATCH] USB: fix bug when errors happen in ioedgeport driver ChangeSet 1.1286, 2003/12/12 10:18:02-08:00, tchen@on-go.com [PATCH] USB: fix bug when errors happen in ioedgeport driver # This patch includes the following deltas: # ChangeSet 1.1285 -> 1.1286 # drivers/usb/serial/io_edgeport.c 1.26 -> 1.27 # io_edgeport.c | 12 ++++++++---- 1 files changed, 8 insertions(+), 4 deletions(-) diff -Nru a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c - --- a/drivers/usb/serial/io_edgeport.c Mon Dec 15 07:03:23 2003 +++ b/drivers/usb/serial/io_edgeport.c Mon Dec 15 07:03:23 2003 @@ -1468,15 +1468,19 @@ urb->transfer_flags |= USB_QUEUE_BULK; urb->dev = edge_serial->serial->dev; + /* decrement the number of credits we have by the number we just sent */ + edge_port->txCredits -= count; + edge_port->icount.tx += count; + status = usb_submit_urb(urb); if (status) { /* something went wrong */ dbg("%s - usb_submit_urb(write bulk) failed", __FUNCTION__); edge_port->write_in_progress = FALSE; - - } else { - - /* decrement the number of credits we have by the number we just sent */ - - edge_port->txCredits -= count; - - edge_port->icount.tx += count; + + /*revert the count if something bad happened...*/ + edge_port->txCredits += count; + edge_port->icount.tx -= count; } dbg("%s wrote %d byte(s) TxCredit %d, Fifo %d", __FUNCTION__, count, edge_port->txCredits, fifo->count); } - - To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - From linux-kernel@vger.kernel.org Thu Dec 18 21:39:10 2003 Date: Fri, 12 Dec 2003 18:18:22 +0000 From: Linux Kernel Mailing List To: bk-commits-24@vger.kernel.org Subject: [PATCH] USB: fix io_edgeport driver alignment issues. ChangeSet 1.1287, 2003/12/12 10:18:22-08:00, tchen@on-go.com [PATCH] USB: fix io_edgeport driver alignment issues. # This patch includes the following deltas: # ChangeSet 1.1286 -> 1.1287 # drivers/usb/serial/io_fw_boot2.h 1.3 -> 1.4 # drivers/usb/serial/io_fw_down2.h 1.3 -> 1.4 # drivers/usb/serial/io_fw_down.h 1.3 -> 1.4 # drivers/usb/serial/io_fw_boot.h 1.3 -> 1.4 # io_fw_boot.h | 2 +- io_fw_boot2.h | 2 +- io_fw_down.h | 2 +- io_fw_down2.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff -Nru a/drivers/usb/serial/io_fw_boot.h b/drivers/usb/serial/io_fw_boot.h - --- a/drivers/usb/serial/io_fw_boot.h Mon Dec 15 07:03:25 2003 +++ b/drivers/usb/serial/io_fw_boot.h Mon Dec 15 07:03:25 2003 @@ -17,7 +17,7 @@ unsigned short Addr; unsigned short Len; unsigned char Data[0]; - - }; + } __attribute__ ((packed)); struct edge_firmware_version_info { unsigned char MajorVersion; diff -Nru a/drivers/usb/serial/io_fw_boot2.h b/drivers/usb/serial/io_fw_boot2.h - --- a/drivers/usb/serial/io_fw_boot2.h Mon Dec 15 07:03:25 2003 +++ b/drivers/usb/serial/io_fw_boot2.h Mon Dec 15 07:03:25 2003 @@ -17,7 +17,7 @@ unsigned short Addr; unsigned short Len; unsigned char Data[0]; - - }; + } __attribute__ ((packed)); struct edge_firmware_version_info { unsigned char MajorVersion; diff -Nru a/drivers/usb/serial/io_fw_down.h b/drivers/usb/serial/io_fw_down.h - --- a/drivers/usb/serial/io_fw_down.h Mon Dec 15 07:03:25 2003 +++ b/drivers/usb/serial/io_fw_down.h Mon Dec 15 07:03:25 2003 @@ -17,7 +17,7 @@ unsigned short Addr; unsigned short Len; unsigned char Data[0]; - - }; + } __attribute ((packed)); struct edge_firmware_version_info { unsigned char MajorVersion; diff -Nru a/drivers/usb/serial/io_fw_down2.h b/drivers/usb/serial/io_fw_down2.h - --- a/drivers/usb/serial/io_fw_down2.h Mon Dec 15 07:03:25 2003 +++ b/drivers/usb/serial/io_fw_down2.h Mon Dec 15 07:03:25 2003 @@ -17,7 +17,7 @@ unsigned short Addr; unsigned short Len; unsigned char Data[0]; - - }; + } __attribute__ ((packed)); struct edge_firmware_version_info { unsigned char MajorVersion; - - To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - From linux-kernel@vger.kernel.org Sun Dec 28 14:33:44 2003 Date: Sun, 07 Dec 2003 18:27:17 +0000 From: Linux Kernel Mailing List To: bk-commits-24@vger.kernel.org Subject: [wireless airo] Delay MIC activation to prevent Oops ChangeSet 1.1136.73.7, 2003/12/07 13:27:17-05:00, achirica@telefonica.net [wireless airo] Delay MIC activation to prevent Oops # This patch includes the following deltas: # ChangeSet 1.1136.73.6 -> 1.1136.73.7 # drivers/net/wireless/airo.c 1.62 -> 1.63 # airo.c | 7 ++----- 1 files changed, 2 insertions(+), 5 deletions(-) diff -ruN linux-2.4.23.mine/drivers/net/wireless/airo.c linux-2.4.23/drivers/net/wireless/airo.c - --- linux-2.4.23.mine/drivers/net/wireless/airo.c 2003-11-28 11:26:20.000000000 -0700 +++ linux-2.4.23/drivers/net/wireless/airo.c 2003-12-28 22:30:56.064562029 -0700 @@ -2476,11 +2476,8 @@ OUT4500( apriv, EVACK, EV_MIC ); #ifdef MICSUPPORT if (test_bit(FLAG_MIC_CAPABLE, &apriv->flags)) { - - if (down_trylock(&apriv->sem) != 0) { - - set_bit(JOB_MIC, &apriv->flags); - - wake_up_interruptible(&apriv->thr_wait); - - } else - - micinit (apriv); + set_bit(JOB_MIC, &apriv->flags); + wake_up_interruptible(&apriv->thr_wait); } #endif } - From linux-kernel@vger.kernel.org Sun Dec 28 14:34:44 2003 Date: Sun, 07 Dec 2003 18:27:13 +0000 From: Linux Kernel Mailing List To: bk-commits-24@vger.kernel.org Subject: [wireless airo] Fix PCI registration ChangeSet 1.1136.73.6, 2003/12/07 13:27:13-05:00, achirica@telefonica.net [wireless airo] Fix PCI registration # This patch includes the following deltas: # ChangeSet 1.1136.73.5 -> 1.1136.73.6 # drivers/net/wireless/airo.c 1.61 -> 1.62 # airo.c | 13 ++----------- 1 files changed, 2 insertions(+), 11 deletions(-) diff -ruN linux-2.4.23.mine/drivers/net/wireless/airo.c linux-2.4.23/drivers/net/wireless/airo.c - --- linux-2.4.23.mine/drivers/net/wireless/airo.c 2003-12-28 22:32:51.418220092 -0700 +++ linux-2.4.23/drivers/net/wireless/airo.c 2003-12-28 22:33:04.226400129 -0700 @@ -1034,7 +1034,6 @@ #define FLAG_802_11 7 #define FLAG_PENDING_XMIT 9 #define FLAG_PENDING_XMIT11 10 - -#define FLAG_PCI 11 #define JOB_MASK 0x1ff0000 #define JOB_DIE 16 #define JOB_XMIT 17 @@ -4639,7 +4638,6 @@ return -ENODEV; pci_set_drvdata(pdev, dev); - - set_bit (FLAG_PCI, &((struct airo_info *)dev->priv)->flags); return 0; } @@ -4669,7 +4667,7 @@ #ifdef CONFIG_PCI printk( KERN_INFO "airo: Probing for PCI adapters\n" ); - - pci_module_init(&airo_driver); + pci_register_driver(&airo_driver); printk( KERN_INFO "airo: Finished probing for PCI adapters\n" ); #endif @@ -4681,22 +4679,15 @@ static void __exit airo_cleanup_module( void ) { - - int is_pci = 0; while( airo_devices ) { printk( KERN_INFO "airo: Unregistering %s\n", airo_devices->dev->name ); - -#ifdef CONFIG_PCI - - if (test_bit(FLAG_PCI, &((struct airo_info *)airo_devices->dev->priv)->flags)) - - is_pci = 1; - -#endif stop_airo_card( airo_devices->dev, 1 ); } remove_proc_entry("aironet", proc_root_driver); - - if (is_pci) { #ifdef CONFIG_PCI - - pci_unregister_driver(&airo_driver); + pci_unregister_driver(&airo_driver); #endif - - } } #ifdef WIRELESS_EXT - From linux-kernel@vger.kernel.org Sun Dec 28 14:37:12 2003 Date: Sun, 28 Dec 2003 20:09:56 +0000 From: Linux Kernel Mailing List To: bk-commits-24@vger.kernel.org Subject: Daniel Lux: Fix IDE busy-wait race ChangeSet 1.1344, 2003/12/28 18:09:56-02:00, marcelo@logos.cnet Daniel Lux: Fix IDE busy-wait race # This patch includes the following deltas: # ChangeSet 1.1343 -> 1.1344 # drivers/ide/ide-iops.c 1.7 -> 1.8 # ide-iops.c | 16 ++++++++++++---- 1 files changed, 12 insertions(+), 4 deletions(-) diff -Nru a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c - --- a/drivers/ide/ide-iops.c Sun Dec 28 13:01:41 2003 +++ b/drivers/ide/ide-iops.c Sun Dec 28 13:01:41 2003 @@ -664,11 +664,19 @@ if ((stat = hwif->INB(IDE_STATUS_REG)) & BUSY_STAT) { local_irq_set(flags); timeout += jiffies; - - while ((stat = hwif->INB(IDE_STATUS_REG)) & BUSY_STAT) { + stat = hwif->INB(IDE_STATUS_REG); + while (stat & BUSY_STAT) { if (time_after(jiffies, timeout)) { - - local_irq_restore(flags); - - *startstop = DRIVER(drive)->error(drive, "status timeout", stat); - - return 1; + /* + * do one more status read in case we were interrupted between last + * stat = hwif->INB(IDE_STATUS_REG) and time_after(jiffies, timeout) + * in wich case the timeout might have been shorter than specified. + */ + if ((stat = hwif->INB(IDE_STATUS_REG)) & BUSY_STAT) { + local_irq_restore(flags); + *startstop = DRIVER(drive)->error(drive, "status timeout", stat); + return 1; + } } } local_irq_restore(flags); - - To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - From linux-kernel@vger.kernel.org Sun Dec 28 14:37:46 2003 Date: Sun, 28 Dec 2003 20:14:56 +0000 From: Linux Kernel Mailing List To: bk-commits-24@vger.kernel.org Subject: Fix IDE busywait merge ChangeSet 1.1345, 2003/12/28 18:14:56-02:00, marcelo@logos.cnet Fix IDE busywait merge # This patch includes the following deltas: # ChangeSet 1.1344 -> 1.1345 # drivers/ide/ide-iops.c 1.8 -> 1.9 # ide-iops.c | 2 ++ 1 files changed, 2 insertions(+) diff -Nru a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c - --- a/drivers/ide/ide-iops.c Sun Dec 28 13:01:43 2003 +++ b/drivers/ide/ide-iops.c Sun Dec 28 13:01:43 2003 @@ -678,6 +678,8 @@ return 1; } } + else + stat = hwif->INB(IDE_STATUS_REG); } local_irq_restore(flags); } - - To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - From linux-kernel@vger.kernel.org Sun Dec 28 14:36:33 2003 Date: Mon, 22 Dec 2003 18:41:06 +0000 From: Linux Kernel Mailing List To: bk-commits-24@vger.kernel.org Subject: [PATCH] Initialize ioc3_timer before use ChangeSet 1.1339, 2003/12/22 16:41:06-02:00, ralf@linux-mips.org [PATCH] Initialize ioc3_timer before use # This patch includes the following deltas: # ChangeSet 1.1338 -> 1.1339 # drivers/net/ioc3-eth.c 1.15 -> 1.16 # ioc3-eth.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -ruN linux-2.4.23.mine/drivers/net/ioc3-eth.c linux-2.4.23/drivers/net/ioc3-eth.c - --- linux-2.4.23.mine/drivers/net/ioc3-eth.c 2003-08-25 05:44:42.000000000 -0600 +++ linux-2.4.23/drivers/net/ioc3-eth.c 2003-12-28 22:39:33.291078118 -0700 @@ -1552,11 +1552,11 @@ #endif spin_lock_init(&ip->ioc3_lock); + init_timer(&ip->ioc3_timer); ioc3_stop(ip); ioc3_init(ip); - - init_timer(&ip->ioc3_timer); ioc3_mii_init(ip); if (ip->phy == -1) { - From linux-kernel@vger.kernel.org Sun Dec 28 14:29:04 2003 Date: Mon, 22 Dec 2003 11:32:50 +0000 From: Linux Kernel Mailing List To: bk-commits-24@vger.kernel.org Subject: [PATCH] Fix RAID1 blocksize check ChangeSet 1.1313, 2003/12/22 09:32:50-02:00, neilb@cse.unsw.edu.au [PATCH] Fix RAID1 blocksize check On Saturday December 20, zaitcev@redhat.com wrote: > In drivers/md/raid1.c, raid1_sync_request contains the following: > > block_nr = sector_nr; > bsize = 512; > while (!(block_nr & 1) && bsize < PAGE_SIZE > && (block_nr+2)*(bsize>>9) < (mddev->sb->size *2)) { > block_nr >>= 1; > bsize <<= 1; > } > > Suppose that a mirror is 4K in size. The code above produces > reads (and writes) of the following offsets and sizes: > 0K[2K], 2K[1K], 3K[0.5K], 3.5K[0.5K] > > The above is correct, but it makes the RAID1 completely unuseable > on s390, because I/O with sizes less than 4K is not supported. > I would like the attached patch applied to correct the issue. Yes, I agree. Marcelo, could you please apply this patch. The '<' test is just to make sure a request of 2*bsize at block_nr will still fit within the size of the device, so a <= is appropriate. NeilBrown # This patch includes the following deltas: # ChangeSet 1.1312 -> 1.1313 # drivers/md/raid1.c 1.16 -> 1.17 # raid1.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Nru a/drivers/md/raid1.c b/drivers/md/raid1.c - --- a/drivers/md/raid1.c Mon Dec 22 04:03:08 2003 +++ b/drivers/md/raid1.c Mon Dec 22 04:03:08 2003 @@ -1436,7 +1436,7 @@ block_nr = sector_nr; bsize = 512; while (!(block_nr & 1) && bsize < PAGE_SIZE - - && (block_nr+2)*(bsize>>9) < (mddev->sb->size *2)) { + && (block_nr+2)*(bsize>>9) <= (mddev->sb->size *2)) { block_nr >>= 1; bsize <<= 1; } - - To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html