linux-2.4.24-updates.patch

   1 ChangeSet@1.1136.1.75  2003-12-07 21:20:48-02:00  willy at debian.org
   2 [PATCH] Remove broken file lock accounting
   3
   4 On Mon, Jul 01, 2002 at 11:13:55PM +0100, Matthew Wilcox wrote:
   5 > The file lock accounting code is horribly broken (and I wrote it, I
   6 > should know).  I think the best solution to 2.4 is simply to delete it,
   7 > at least for BSD-style flocks.
   8 >
   9 > Patch to follow.  Note that 2.5 has the same issue, but I'll fix it
  10 > differently there.
  11
  12 Here's the patch for 2.4:
  13
  14 - --- linux-2.4.23/fs/locks.c.orig      Tue Dec  9 00:11:23 2003
  15 +++ linux-2.4.23/fs/locks.c     Tue Dec  9 00:13:00 2003
  16 @@ -135,15 +135,9 @@
  17  static kmem_cache_t *filelock_cache;
  18
  19  /* Allocate an empty lock structure. */
  20 - -static struct file_lock *locks_alloc_lock(int account)
  21 +static struct file_lock *locks_alloc_lock(void)
  22  {
  23 - -     struct file_lock *fl;
  24 - -     if (account && current->locks >= current->rlim[RLIMIT_LOCKS].rlim_cur)
  25 - -             return NULL;
  26 - -     fl = kmem_cache_alloc(filelock_cache, SLAB_KERNEL);
  27 - -     if (fl)
  28 - -             current->locks++;
  29 - -     return fl;
  30 +       return kmem_cache_alloc(filelock_cache, SLAB_KERNEL);
  31  }
  32
  33  /* Free a lock which is not in use. */
  34 @@ -153,7 +147,6 @@
  35                 BUG();
  36                 return;
  37         }
  38 - -     current->locks--;
  39         if (waitqueue_active(&fl->fl_wait))
  40                 panic("Attempting to free lock with active wait queue");
  41
  42 @@ -220,7 +213,7 @@
  43  /* Fill in a file_lock structure with an appropriate FLOCK lock. */
  44  static struct file_lock *flock_make_lock(struct file *filp, unsigned int type)
  45  {
  46 - -     struct file_lock *fl = locks_alloc_lock(1);
  47 +       struct file_lock *fl = locks_alloc_lock();
  48         if (fl == NULL)
  49                 return NULL;
  50
  51 @@ -358,7 +351,7 @@
  52  /* Allocate a file_lock initialised to this type of lease */
  53  static int lease_alloc(struct file *filp, int type, struct file_lock **flp)
  54  {
  55 - -     struct file_lock *fl = locks_alloc_lock(1);
  56 +       struct file_lock *fl = locks_alloc_lock();
  57         if (fl == NULL)
  58                 return -ENOMEM;
  59
  60 @@ -721,7 +714,7 @@
  61                          size_t count)
  62  {
  63         struct file_lock *fl;
  64 - -     struct file_lock *new_fl = locks_alloc_lock(0);
  65 +       struct file_lock *new_fl = locks_alloc_lock();
  66         int error;
  67
  68         if (new_fl == NULL)
  69 @@ -881,8 +874,8 @@
  70          * We may need two file_lock structures for this operation,
  71          * so we get them in advance to avoid races.
  72          */
  73 - -     new_fl = locks_alloc_lock(0);
  74 - -     new_fl2 = locks_alloc_lock(0);
  75 +       new_fl = locks_alloc_lock();
  76 +       new_fl2 = locks_alloc_lock();
  77         error = -ENOLCK; /* "no luck" */
  78         if (!(new_fl && new_fl2))
  79                 goto out_nolock;
  80 @@ -1488,7 +1481,7 @@
  81  int fcntl_setlk(unsigned int fd, unsigned int cmd, struct flock *l)
  82  {
  83         struct file *filp;
  84 - -     struct file_lock *file_lock = locks_alloc_lock(0);
  85 +       struct file_lock *file_lock = locks_alloc_lock();
  86         struct flock flock;
  87         struct inode *inode;
  88         int error;
  89 @@ -1644,7 +1637,7 @@
  90  int fcntl_setlk64(unsigned int fd, unsigned int cmd, struct flock64 *l)
  91  {
  92         struct file *filp;
  93 - -     struct file_lock *file_lock = locks_alloc_lock(0);
  94 +       struct file_lock *file_lock = locks_alloc_lock();
  95         struct flock64 flock;
  96         struct inode *inode;
  97         int error;
  98 ChangeSet@1.1136.1.68  2003-12-06 16:25:16-02:00  wli at holomorphy.com
  99 [PATCH] Fixup smb_boot_cpus(): Fix HT detection bug
 100
 101 On Wed, Dec 03, 2003 at 06:41:36PM -0500, Ethan Weinstein wrote:
 102 > Ok, setting CONFIG_NR_CPUS=8 does indeed solve the HT issue, looks like
 103 > it was the numbering scheme:
 104
 105 Something like this might do the trick. NR_CPUS is already checked
 106 indirectly via max_cpus.
 107
 108
 109 - -- wli
 110
 111
 112
 113 - --- linux-2.4.23/arch/i386/kernel/smpboot.c.orig      Tue Dec  9 00:27:10 2003
 114 +++ linux-2.4.23/arch/i386/kernel/smpboot.c     Tue Dec  9 00:27:23 2003
 115 @@ -1106,7 +1106,7 @@
 116          */
 117         Dprintk("CPU present map: %lx\n", phys_cpu_present_map);
 118
 119 - -     for (bit = 0; bit < NR_CPUS; bit++) {
 120 +       for (bit = 0; bit < BITS_PER_LONG; bit++) {
 121                 apicid = cpu_present_to_apicid(bit);
 122
 123                 /* don't try to boot BAD_APICID */
 124 ChangeSet@1.1136.1.73  2003-12-07 15:10:38-02:00  mikulas at cuni.cz
 125 [PATCH] from -aa tree: Fix potential fsync() race condition
 126
 127 > 00_ll_rw_block-sync-race-1 first appeared in 2.4.21pre4aa3 - 470 bytes
 128 >
 129 >  Add lock_page in ll_rw_block to fix a fs race
 130 >  condition. Fix suggested by Mikulas Patocka.
 131
 132 Yes. You have two inodes placed in the same buffer.
 133
 134 Process 1 modifies inode 1 and calls fsync on it. fsync initiates write of
 135 the block. ll_rw_block returns, write is in progress.
 136
 137 Process 2 modifies inode 2 and calls fsync on it. Filesystem calls
 138 ll_rw_block write on the same buffer. ll_rw_block immediatelly returns,
 139 because it sees there is already IO on the buffer (there used to be
 140 something like if (buffer_locked(bh)) return;). Process 2 waits on buffer.
 141
 142 The write finished. Both processes are waken up. Both processes return out
 143 of fsync function. Process 2 returns from fsync while it did not write its
 144 inode modification to disk --- it waited on process 1's write.
 145
 146
 147 - --- linux-2.4.23/drivers/block/ll_rw_blk.c~   Tue Dec  9 00:17:12 2003
 148 +++ linux-2.4.23/drivers/block/ll_rw_blk.c      Tue Dec  9 00:17:12 2003
 149 @@ -1377,9 +1377,7 @@
 150         for (i = 0; i < nr; i++) {
 151                 struct buffer_head *bh = bhs[i];
 152
 153 - -             /* Only one thread can actually submit the I/O. */
 154 - -             if (test_and_set_bit(BH_Lock, &bh->b_state))
 155 - -                     continue;
 156 +               lock_buffer(bh);
 157
 158                 /* We have the buffer lock */
 159                 atomic_inc(&bh->b_count);
 160 ChangeSet@1.1136.73.4  2003-12-02 12:02:00-02:00  neilb at unsw.edu.au
 161 [PATCH] Drop module count if lockd reclaimer thread failed to start.
 162
 163 - --- linux-2.4.23/fs/lockd/clntlock.c~ Tue Dec  9 00:35:29 2003
 164 +++ linux-2.4.23/fs/lockd/clntlock.c    Tue Dec  9 00:35:29 2003
 165 @@ -188,7 +188,8 @@
 166                 nlmclnt_prepare_reclaim(host, newstate);
 167                 nlm_get_host(host);
 168                 MOD_INC_USE_COUNT;
 169 - -             kernel_thread(reclaimer, host, CLONE_SIGNAL);
 170 +               if(kernel_thread(reclaimer, host, CLONE_SIGNAL) < 0)
 171 +                       MOD_DEC_USE_COUNT;
 172         }
 173  }
 174
 175 ChangeSet@1.1136.1.65  2003-12-05 15:53:34-02:00  mikpe at se
 176 [PATCH] fix reboot/no_idt bug
 177
 178 When compiling 2.4.23 with gcc-3.3.2, gcc generates the
 179 following warning for arch/i386/kernel/process.c:
 180
 181 process.c: In function `machine_restart':
 182 process.c:427: warning: use of memory input without lvalue in asm operand 0
 183 is deprecated
 184
 185 The warning identifies a real bug. no_idt is passed to
 186 lidt with an "m" constraint, which requires an l-value.
 187 Since no_idt is faked as an array, gcc creates an anonymous
 188 variable pointing to no_idt and passes that to lidt(*),
 189 so at runtime lidt sees the wrong address. Not good.
 190 (The bug, while real, is unlikely to trigger since it
 191 sits in an infrequently used path in the reboot code.)
 192
 193 The fix is to make no_idt a struct (and thus an l-lvalue)
 194 like the other gdt/idt descriptors.
 195
 196 This patch is a backport of the fix Linus made for the
 197 same bug in 2.6.0-test4.
 198
 199 [Andi: x86-64 appears to have the same bug]
 200
 201 (*) Verified by inspection of the assembly code.
 202
 203 /Mikael
 204
 205
 206 - --- linux-2.4.23/arch/i386/kernel/process.c.orig      Tue Dec  9 00:29:52 2003
 207 +++ linux-2.4.23/arch/i386/kernel/process.c     Tue Dec  9 00:30:46 2003
 208 @@ -153,7 +153,6 @@
 209
 210  __setup("idle=", idle_setup);
 211
 212 - -static long no_idt[2];
 213  static int reboot_mode;
 214  int reboot_thru_bios;
 215
 216 @@ -224,7 +223,8 @@
 217         unsigned long long * base __attribute__ ((packed));
 218  }
 219  real_mode_gdt = { sizeof (real_mode_gdt_entries) - 1, real_mode_gdt_entries },
 220 - -real_mode_idt = { 0x3ff, 0 };
 221 +real_mode_idt = { 0x3ff, 0 },
 222 +no_idt = { 0, 0 };
 223
 224  /* This is 16-bit protected mode code to disable paging and the cache,
 225     switch to real mode and jump to the BIOS reset code.
 226 ChangeSet@1.1136.78.2  2003-12-07 12:43:34-02:00  wli at holomorphy.com
 227 [PATCH] out_of_memory() locking
 228
 229 On Sun, Nov 30, 2003 at 08:18:02AM -0800, William Lee Irwin III wrote:
 230 > (1) the timestamps/etc. weren't locked, and when cpus raced, it caused
 231 >  false OOM kills
 232 > (2) the mm could go away while scanning the tasklist, causing the thing
 233 >  to try to kill kernel threads
 234 > Here's a preliminary backport (please do _NOT_ apply until I or someone
 235 > tests it) for you to comment on. Basically, do you want (1) and (2)
 236 > split out, is the basic thing okay, etc.?
 237
 238 out_of_memory()'s operational variables are not locked, and can be
 239 reset by multiple cpus simultaneously, causing false OOM kills.
 240
 241 This patch adds an oom_lock to out_of_memory() to protect its operational
 242 variables.
 243
 244
 245 - -- wli
 246
 247
 248
 249 - --- linux-2.4.23/mm/oom_kill.c.orig   Tue Dec  9 00:20:47 2003
 250 +++ linux-2.4.23/mm/oom_kill.c  Tue Dec  9 00:24:20 2003
 251 @@ -202,6 +202,11 @@
 252   */
 253  void out_of_memory(void)
 254  {
 255 +       /*
 256 +       * oom_lock protects out_of_memory()'s static variables.
 257 +       * It's a global lock; this is not performance-critical.
 258 +       */
 259 +       static spinlock_t oom_lock = SPIN_LOCK_UNLOCKED;
 260         static unsigned long first, last, count, lastkill;
 261         unsigned long now, since;
 262
 263 @@ -211,6 +216,7 @@
 264         if (nr_swap_pages > 0)
 265                 return;
 266
 267 +       spin_lock(&oom_lock);
 268         now = jiffies;
 269         since = now - last;
 270         last = now;
 271 @@ -229,14 +235,14 @@
 272          */
 273         since = now - first;
 274         if (since < HZ)
 275 - -             return;
 276 +               goto out_unlock;
 277
 278         /*
 279          * If we have gotten only a few failures,
 280          * we're not really oom.
 281          */
 282         if (++count < 10)
 283 - -             return;
 284 +               goto out_unlock;
 285
 286         /*
 287          * If we just killed a process, wait a while
 288 @@ -245,17 +251,25 @@
 289          */
 290         since = now - lastkill;
 291         if (since < HZ*5)
 292 - -             return;
 293 +               goto out_unlock;
 294
 295         /*
 296          * Ok, really out of memory. Kill something.
 297          */
 298         lastkill = now;
 299 +
 300 +       /* oom_kill() can sleep */
 301 +       spin_unlock(&oom_lock);
 302         oom_kill();
 303 +       spin_lock(&oom_lock);
 304
 305  reset:
 306 - -     first = now;
 307 +       if (first < now)
 308 +               first = now;
 309         count = 0;
 310 +
 311 +out_unlock:
 312 +       spin_unlock(&oom_lock);
 313  }
 314
 315  #endif /* Unused file */
 316 ChangeSet@1.1136.1.61  2003-12-01 12:43:59-07:00  davidm at com[helgaas]
 317
 318 ia64: Fix a bug in sigtramp() which corrupted ar.rnat when unwinding
 319         across a signal trampoline (in user space).  Reported by
 320         Laurent Morichetti.
 321
 322 arch/ia64/kernel/gate.S@1.11  2003-12-01 05:43:29-07:00  davidm at com[helgaas]
 323
 324 (__kernel_sigtramp): Replace usage of p8 with p1.  We must use a preserved
 325         predicate for the .spillsp.p directive, otherwise, the predicate
 326         may have been clobbered by the time the unwinder looks at it.
 327         Fortunately, we can just use p1 because the entire pr register
 328         is already saved/restored by the kernel.
 329
 330
 331 - --- linux-2.4.23/arch/ia64/kernel/gate.S~     Tue Dec  9 00:46:11 2003
 332 +++ linux-2.4.23/arch/ia64/kernel/gate.S        Tue Dec  9 00:46:11 2003
 333 @@ -88,10 +88,10 @@
 334         ld8 r15=[base1]                                 // get address of new RBS base (or NULL)
 335         cover                           // push args in interrupted frame onto backing store
 336         ;;
 337 - -     cmp.ne p8,p0=r15,r0             // do we need to switch the rbs?
 338 +       cmp.ne p1,p0=r15,r0             // do we need to switch rbs? (note: pr is saved by kernel)
 339         mov.m r9=ar.bsp                 // fetch ar.bsp
 340 - -     .spillsp.p p8, ar.rnat, RNAT_OFF+SIGCONTEXT_OFF
 341 - -(p8) br.cond.spnt setup_rbs          // yup -> (clobbers r14, r15, and r16)
 342 +       .spillsp.p p1, ar.rnat, RNAT_OFF+SIGCONTEXT_OFF
 343 +(p1)   br.cond.spnt setup_rbs          // yup -> (clobbers p8, r14, r15, and r16)
 344  back_from_setup_rbs:
 345         alloc r8=ar.pfs,0,0,3,0
 346         ld8 out0=[base0],16             // load arg0 (signum)
 347 @@ -130,8 +130,8 @@
 348         ld8 r15=[base0],(CFM_OFF-BSP_OFF)       // fetch sc_ar_bsp and advance to CFM_OFF
 349         mov r14=ar.bsp
 350         ;;
 351 - -     cmp.ne p8,p0=r14,r15                    // do we need to restore the rbs?
 352 - -(p8) br.cond.spnt restore_rbs                // yup -> (clobbers r14-r18, f6 & f7)
 353 +       cmp.ne p1,p0=r14,r15                    // do we need to restore the rbs?
 354 +(p1)   br.cond.spnt restore_rbs                // yup -> (clobbers p8, r14-r18, f6 & f7)
 355         ;;
 356  back_from_restore_rbs:
 357         adds base0=(FR6_OFF+SIGCONTEXT_OFF),sp
 358 ChangeSet@1.1136.73.2  2003-12-02 11:58:06-02:00  neilb at unsw.edu.au
 359 [PATCH] Make root a special case for per-user process limits.
 360
 361 This is needed because when a setuid-root program calls
 362 setuid(0) to become really-root, p->user becomes root_user,
 363 but ->rlim stays as the original user's limit, and now
 364 the process cannot fork - becuase root has more processes than
 365 the original user had.
 366
 367 The real problem is that NPROC is not really a per-process limit,
 368 but its a per-user limit, and including it with the rlim structure
 369 was not a good idea :-(
 370
 371 This fix is already in 2.6
 372
 373
 374 - --- linux-2.4.23/kernel/fork.c.orig   Tue Dec  9 00:38:16 2003
 375 +++ linux-2.4.23/kernel/fork.c  Tue Dec  9 00:38:59 2003
 376 @@ -669,6 +669,7 @@
 377          * than the amount of processes root is running. -- Rik
 378          */
 379         if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur
 380 +                     && p->user != &root_user
 381                       && !capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE))
 382                 goto bad_fork_free;
 383
 384 As per http://lkml.org/lkml/2003/12/1/150
 385
 386 diff -urN --exclude=CVS --exclude=.cvsignore linux-2.4.23/include/linux/mc146818rtc.h linux-cvs-2.4.23/include/linux/mc146818rtc.h
 387 - --- linux-2.4.23/include/linux/mc146818rtc.h  2001-11-22 20:46:58.000000000 +0100
 388 +++ linux-cvs-2.4.23/include/linux/mc146818rtc.h        2003-11-28 15:09:41.000000000 +0100
 389 @@ -98,4 +98,12 @@
 390  #define BIN_TO_BCD(val) ((val)=(((val)/10)<<4) + (val)%10)
 391  #endif
 392
 393 +#ifndef RTC_IO_EXTENT
 394 +#define RTC_IO_EXTENT  0x10    /* Only really two ports, but...        */
 395 +#endif
 396 +
 397 +#ifndef RTC_IOMAPPED
 398 +#define RTC_IOMAPPED   1       /* Default to I/O mapping. */
 399 +#endif
 400 +
 401  #endif /* _MC146818RTC_H */
 402 - From linux-kernel@vger.kernel.org Thu Dec 18 21:50:26 2003
 403 Date: Tue, 16 Dec 2003 15:59:16 +0000
 404 From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
 405 To: bk-commits-24@vger.kernel.org
 406 Subject: [PATCH] duplicate PID fix
 407
 408 ChangeSet 1.1302, 2003/12/16 13:59:16-02:00, t-kochi@bq.jp.nec.com
 409
 410         [PATCH] duplicate PID fix
 411
 412         Hello Marcelo,
 413
 414         This fix was sent to lkml in April, and was merged to -ac tree,
 415         but is not merged in the main tree yet.
 416         Please consider taking this in.
 417
 418         Without this, duplicate pids can be allocated, which will make
 419         one of them unkillable (signals are deliverd to only one of them),
 420         and this can be exploitable (I don't know for sure, but maybe,
 421         like brk() ;)
 422
 423         This situation happens only when all pid space is full.
 424         Usually, users cannot fork processes more than 32768 (PID_MAX),
 425         but default user limit of max processes can be more
 426         than PID_MAX on large memory machines such as 64bit
 427         platforms (although it's adjustable by threads-max sysctl).
 428
 429         This patch modifies common code and affects all architectures,
 430         but modifies code only executed when no pid is available,
 431         so it doesn't hurt any normal path anyway.
 432
 433         (BTW, once I sent this patch to Rusty's Trivial patch monkey,
 434         but his reply was non-trivial, and he also said this is
 435         scary ;)
 436
 437         The details are described below:
 438
 439         In get_pid(), an available pid is searched through all task_structs
 440         even when there is no available pid.  If a new pid is not available,
 441         the kernel exits the loop with static variable 'next_safe' untouched,
 442         which usually is no problem.
 443
 444
 445                 spin_lock(&lastpid_lock);
 446                 beginpid = last_pid;
 447                 if((++last_pid) & 0xffff8000) {
 448                         last_pid = 300;         /* Skip daemons etc. */
 449                         goto inside;
 450                 }
 451                 if(last_pid >= next_safe) {
 452         inside:
 453                         next_safe = PID_MAX;
 454                         read_lock(&tasklist_lock);
 455         repeat:
 456                 for_each_task(p) {
 457                         if(p->pid == last_pid   ||
 458                            p->pgrp == last_pid  ||
 459                            p->tgid == last_pid  ||
 460                            p->session == last_pid) {                    <= (A)
 461                                 if(++last_pid >= next_safe) {           <= (B)
 462                                         if(last_pid & 0xffff8000)
 463                                                 last_pid = 300;
 464                                         next_safe = PID_MAX;
 465                                 }
 466                                 if(unlikely(last_pid == beginpid))      <= (C)
 467                                         goto nomorepids;
 468                                 goto repeat;
 469                         }
 470                         if(p->pid > last_pid && next_safe > p->pid)
 471                                 next_safe = p->pid;
 472                         if(p->pgrp > last_pid && next_safe > p->pgrp)
 473                                 next_safe = p->pgrp;
 474                         if(p->tgid > last_pid && next_safe > p->tgid)
 475                                 next_safe = p->tgid;
 476                         if(p->session > last_pid && next_safe > p->session)
 477                                 next_safe = p->session;
 478                 }
 479
 480
 481         In a rare case, both (B) and (C) can be true and then, next_safe
 482         will remain PID_MAX (32768).  If that happens, following get_pid() will
 483         always succeed until last_pid reaches 32768 and there may be many
 484         duplicate pids.
 485
 486         For example, this happens when
 487
 488          * PID space are full (300-32767 are all occupied)
 489          * the last pid allocated is 10000
 490          * task list chain is like:
 491            ...(pids < 9999), 9999, ...(pids 300~9998, 10001~32767)... , 10000
 492
 493         The loop starts searching an available pid with beginpid=10000 and
 494         last_pid=10001.  last_pid is incremented until it gets PID_MAX
 495         and then wraps around to 300, then is incremented again.
 496
 497         At the point that p->pid=9999 is found in tasklist (condition (A)),
 498
 499           last_pid = 9999
 500           next_safe <= 9998
 501
 502         therefore condition (B) is true, and then
 503
 504           last_pid = 10000
 505           next_safe = PID_MAX
 506
 507         and then, condition (C) is also true, and exits the loop.
 508
 509         To protect this case is simple; when the condition (C) is true,
 510         set next_safe to 0 or any safe value to guarantee that a free pid
 511         will be searched through next time.
 512
 513         Thanks,
 514
 515
 516 # This patch includes the following deltas:
 517 #                  ChangeSet    1.1301  -> 1.1302
 518 #              kernel/fork.c    1.31    -> 1.32
 519 #
 520
 521  fork.c |    4 +++-
 522  1 files changed, 3 insertions(+), 1 deletion(-)
 523
 524
 525 diff -Nru a/kernel/fork.c b/kernel/fork.c
 526 - --- a/kernel/fork.c   Tue Dec 16 09:02:43 2003
 527 +++ b/kernel/fork.c     Tue Dec 16 09:02:43 2003
 528 @@ -114,8 +114,10 @@
 529                                                 last_pid = 300;
 530                                         next_safe = PID_MAX;
 531                                 }
 532 - -                             if(unlikely(last_pid == beginpid))
 533 +                               if(unlikely(last_pid == beginpid)) {
 534 +                                       next_safe = 0;
 535                                         goto nomorepids;
 536 +                               }
 537                                 goto repeat;
 538                         }
 539                         if(p->pid > last_pid && next_safe > p->pid)
 540 - -
 541 To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in
 542 the body of a message to majordomo@vger.kernel.org
 543 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 544 - From linux-kernel@vger.kernel.org Thu Dec 18 21:43:15 2003
 545 Date: Mon, 15 Dec 2003 04:44:43 +0000
 546 From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
 547 To: bk-commits-24@vger.kernel.org
 548 Subject: [PPC64] Fix save_flags/restore_flags on iSeries.
 549
 550 ChangeSet 1.1270.3.9, 2003/12/15 15:44:43+11:00, engebret@us.ibm.com
 551
 552         [PPC64] Fix save_flags/restore_flags on iSeries.
 553
 554
 555 # This patch includes the following deltas:
 556 #                  ChangeSet    1.1270.3.8 -> 1.1270.3.9
 557 #       arch/ppc64/kernel/misc.S        1.8     -> 1.9
 558 #
 559
 560  misc.S |   14 +++++++-------
 561  1 files changed, 7 insertions(+), 7 deletions(-)
 562
 563
 564 diff -Nru a/arch/ppc64/kernel/misc.S b/arch/ppc64/kernel/misc.S
 565 - --- a/arch/ppc64/kernel/misc.S        Mon Dec 15 07:03:59 2003
 566 +++ b/arch/ppc64/kernel/misc.S  Mon Dec 15 07:03:59 2003
 567 @@ -69,16 +69,14 @@
 568  _GLOBAL(__no_use_save_flags)
 569         mfspr   r4,SPRG3
 570         lbz     r3,PACAPROCENABLED(r4)
 571 +       /* shift into position of MSR.EE */
 572 +       sldi    r3,r3,15
 573         blr
 574
 575 - -/* void __no_use_restore_flags(unsigned long flags) */
 576 +/* void __no_use_restore_flags(unsigned long flags) */
 577  _GLOBAL(__no_use_restore_flags)
 578 - -/*
 579 - - * Just set/clear the MSR_EE bit through restore/flags but do not
 580 - - * change anything else.  This is needed by the RT system and makes
 581 - - * sense anyway.
 582 - - *    -- Cort
 583 - - */
 584 +       /* shift from position of MSR.EE */
 585 +       srdi    r3,r3,15
 586         mfspr   r6,SPRG3
 587         lbz     r5,PACAPROCENABLED(r6)
 588          /* Check if things are setup the way we want _already_. */
 589 @@ -104,6 +102,8 @@
 590         lbz     r3,PACAPROCENABLED(r5)
 591         li      r4,0
 592         stb     r4,PACAPROCENABLED(r5)
 593 +       /* shift into position of MSR.EE */
 594 +       sldi    r3,r3,15
 595         blr                     /* Done */
 596
 597  _GLOBAL(__no_use_sti)
 598 - -
 599 To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in
 600 the body of a message to majordomo@vger.kernel.org
 601 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 602 - From linux-kernel@vger.kernel.org Thu Dec 18 21:41:34 2003
 603 Date: Fri, 12 Dec 2003 20:18:04 +0000
 604 From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
 605 To: bk-commits-24@vger.kernel.org
 606 Subject: [PATCH] USB: MCT-U232 Patch for cts
 607
 608 ChangeSet 1.1289, 2003/12/12 12:18:04-08:00, marr@flex.com
 609
 610         [PATCH] USB: MCT-U232 Patch for cts
 611
 612         Brief Patch Description:
 613
 614         Fix a problem in the 'mct_u232' driver whereby output data gets held up in the
 615         USB/RS-232 adapter for RS-232 devices which don't assert the 'CTS' signal.
 616
 617         Background:
 618
 619         The Belkin F5U109 is a 9-pin USB/RS-232 adapter that is supported by the
 620         existing 'mct_u232' kernel module.  Recently, I've been testing it under the
 621         2.4.22 (Slackware 9.1) kernel and the 2.6.0-test9 kernel.
 622
 623         I've connected a Garmin 'GPS35 TracPak' GPS receiver (RS-232 interface) and an
 624         ordinary RS-232 external modem to my PC's USB port via the Belkin F5U109
 625         adapter.
 626
 627         Problem:
 628
 629         Although _reads_ from either of the RS-232 devices mentioned above work fine
 630         via the Belkin adapter, _writes_ to the GPS receiver are not being seen by
 631         the GPS.  Writes to the modem, however, work perfectly.
 632
 633         Aside: The 'Linux USB Users' archives show that at least one other person
 634         (circa May 2002) had the exact same problem I'm having, but it sounds like no
 635         solution was ever determined because the person in question just bought a
 636         different USB/RS-232 adapter.
 637
 638         Investigation:
 639
 640         Using the 'seyon' terminal emulator in Linux and a crude hardware RS-232
 641         "breakout box" that I hacked together, I've determined that the problem is
 642         related to the RTS/CTS RS-232 hardware handshaking.
 643
 644         After further investigation, I've concluded that RS-232 devices which do not
 645         assert the 'Clear To Send' ('CTS') signal prevent the Belkin F5U109 adapter
 646         from transmitting data to the RS-232 device when the current (version 1.1)
 647         'mct_u232' module is used. The data gets "queued up" (up to a point -- 16
 648         bytes, I think) in the adapter but never transmitted.
 649
 650         Since this GPS receiver works perfectly (reads and writes) when connected to a
 651         PC running W98se using the same Belkin adapter and the Belkin-supplied
 652         Windows driver, the Linux driver became suspect.
 653
 654         After some testing with SniffUSB, I found that the Windows driver sends a
 655         couple of unique undocumented USB 'device requests' that the Linux driver
 656         does not. As it turns out, the second of those 2 requests is critical in
 657         making the adapter transmit data to a device which doesn't assert 'CTS'.
 658
 659         For completeness, the Windows driver in use was determined from the 'Device
 660         Manager', 'Driver File Details' page:
 661
 662            U2SPORT.VXD
 663            Provider: Magic Control Technology
 664            File version: 1.21P.0104 for Win98/Me
 665
 666         Solution:
 667
 668         My patch adds the 2 missing USB 'device request' commands right after a
 669         baud-change command. This mimics the operation of the W98 driver.
 670
 671         Unfortunately, after much testing, I found no other operation (besides a
 672         baud-change request) under Windows that triggers either of these 2 'device
 673         request' commands. This makes it impossible to fully document the behavior of
 674         these requests, but I've made entries for them alongside the others in the
 675         'mct_u232.h' file.
 676
 677         Purely for clarity, the patch also modifies various comments in 'mct_u232.h',
 678         mostly to reflect proper sizes of the various 'USB Device Request' fields per
 679         the USB 1.1 specification.
 680
 681         The patch also updates the version number of the driver, corrects a minor
 682         typographical error, and documents a difference in the length of the data in
 683         a 'baud rate change' command for certain adapters which use a coded baud-rate
 684         rather than the conventional RS-232 baud rate divisor.
 685
 686
 687 # This patch includes the following deltas:
 688 #                  ChangeSet    1.1288  -> 1.1289
 689 #       drivers/usb/serial/mct_u232.c   1.18    -> 1.19
 690 #       drivers/usb/serial/mct_u232.h   1.3     -> 1.4
 691 #
 692
 693  mct_u232.c |   37 +++++++++++++++++++++-
 694  mct_u232.h |  101 ++++++++++++++++++++++++++++++++++++++++++++++++-------------
 695  2 files changed, 116 insertions(+), 22 deletions(-)
 696
 697
 698 diff -Nru a/drivers/usb/serial/mct_u232.c b/drivers/usb/serial/mct_u232.c
 699 - --- a/drivers/usb/serial/mct_u232.c   Mon Dec 15 07:03:29 2003
 700 +++ b/drivers/usb/serial/mct_u232.c     Mon Dec 15 07:03:29 2003
 701 @@ -24,6 +24,11 @@
 702   *   Basic tests have been performed with minicom/zmodem transfers and
 703   *   modem dialing under Linux 2.4.0-test10 (for me it works fine).
 704   *
 705 + * 04-Nov-2003 Bill Marr <marr at flex dot com>
 706 + *   - Mimic Windows driver by sending 2 USB 'device request' messages
 707 + *     following normal 'baud rate change' message.  This allows data to be
 708 + *     transmitted to RS-232 devices which don't assert the 'CTS' signal.
 709 + *
 710   * 10-Nov-2001 Wolfgang Grandegger
 711   *   - Fixed an endianess problem with the baudrate selection for PowerPC.
 712   *
 713 @@ -85,7 +90,7 @@
 714  /*
 715   * Version Information
 716   */
 717 - -#define DRIVER_VERSION "v1.1"
 718 +#define DRIVER_VERSION "v1.2"
 719  #define DRIVER_AUTHOR "Wolfgang Grandegger <wolfgang@ces.ch>"
 720  #define DRIVER_DESC "Magic Control Technology USB-RS232 converter driver"
 721
 722 @@ -201,6 +206,7 @@
 723  {
 724         unsigned int divisor;
 725          int rc;
 726 +        unsigned char zero_byte = 0;
 727         divisor = cpu_to_le32(mct_u232_calculate_baud_rate(serial, value));
 728          rc = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
 729                               MCT_U232_SET_BAUD_RATE_REQUEST,
 730 @@ -210,6 +216,35 @@
 731         if (rc < 0)
 732                 err("Set BAUD RATE %d failed (error = %d)", value, rc);
 733         dbg("set_baud_rate: value: %d, divisor: 0x%x", value, divisor);
 734 +
 735 +       /* Mimic the MCT-supplied Windows driver (version 1.21P.0104), which
 736 +          always sends two extra USB 'device request' messages after the
 737 +          'baud rate change' message.  The actual functionality of the
 738 +          request codes in these messages is not fully understood but these
 739 +          particular codes are never seen in any operation besides a baud
 740 +          rate change.  Both of these messages send a single byte of data
 741 +          whose value is always zero.  The second of these two extra messages
 742 +          is required in order for data to be properly written to an RS-232
 743 +          device which does not assert the 'CTS' signal. */
 744 +
 745 +       rc = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
 746 +                            MCT_U232_SET_UNKNOWN1_REQUEST,
 747 +                            MCT_U232_SET_REQUEST_TYPE,
 748 +                            0, 0, &zero_byte, MCT_U232_SET_UNKNOWN1_SIZE,
 749 +                            WDR_TIMEOUT);
 750 +       if (rc < 0)
 751 +               err("Sending USB device request code %d failed (error = %d)",
 752 +                   MCT_U232_SET_UNKNOWN1_REQUEST, rc);
 753 +
 754 +       rc = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
 755 +                            MCT_U232_SET_UNKNOWN2_REQUEST,
 756 +                            MCT_U232_SET_REQUEST_TYPE,
 757 +                            0, 0, &zero_byte, MCT_U232_SET_UNKNOWN2_SIZE,
 758 +                            WDR_TIMEOUT);
 759 +       if (rc < 0)
 760 +               err("Sending USB device request code %d failed (error = %d)",
 761 +                   MCT_U232_SET_UNKNOWN2_REQUEST, rc);
 762 +
 763          return rc;
 764  } /* mct_u232_set_baud_rate */
 765
 766 diff -Nru a/drivers/usb/serial/mct_u232.h b/drivers/usb/serial/mct_u232.h
 767 - --- a/drivers/usb/serial/mct_u232.h   Mon Dec 15 07:03:29 2003
 768 +++ b/drivers/usb/serial/mct_u232.h     Mon Dec 15 07:03:29 2003
 769 @@ -57,6 +57,21 @@
 770  #define MCT_U232_SET_MODEM_CTRL_REQUEST        10 /* Set Modem Control Register (MCR) */
 771  #define MCT_U232_SET_MODEM_CTRL_SIZE    1
 772
 773 +/* This USB device request code is not well understood.  It is transmitted by
 774 +   the MCT-supplied Windows driver whenever the baud rate changes.
 775 +*/
 776 +#define MCT_U232_SET_UNKNOWN1_REQUEST   11  /* Unknown functionality */
 777 +#define MCT_U232_SET_UNKNOWN1_SIZE       1
 778 +
 779 +/* This USB device request code is not well understood.  It is transmitted by
 780 +   the MCT-supplied Windows driver whenever the baud rate changes.
 781 +
 782 +   Without this USB device request, the USB/RS-232 adapter will not write to
 783 +   RS-232 devices which do not assert the 'CTS' signal.
 784 +*/
 785 +#define MCT_U232_SET_UNKNOWN2_REQUEST   12  /* Unknown functionality */
 786 +#define MCT_U232_SET_UNKNOWN2_SIZE       1
 787 +
 788  /*
 789   * Baud rate (divisor)
 790   */
 791 @@ -137,22 +152,31 @@
 792   * Baud rate (divisor)
 793   * -------------------
 794   *
 795 - - *   BmRequestType:  0x4 (0100 0000B)
 796 - - *   bRequest:       0x5
 797 - - *   wValue:         0x0
 798 - - *   wIndex:         0x0
 799 - - *   wLength:        0x4
 800 + *   BmRequestType:  0x40 (0100 0000B)
 801 + *   bRequest:       0x05
 802 + *   wValue:         0x0000
 803 + *   wIndex:         0x0000
 804 + *   wLength:        0x0004
 805   *   Data:           divisor = 115200 / baud_rate
 806   *
 807 + *   SniffUSB observations (Nov 2003): Contrary to the 'wLength' value of 4
 808 + *   shown above, observations with a Belkin F5U109 adapter, using the
 809 + *   MCT-supplied Windows98 driver (U2SPORT.VXD, "File version: 1.21P.0104 for
 810 + *   Win98/Me"), show this request has a length of 1 byte, presumably because
 811 + *   of the fact that the Belkin adapter and the 'Sitecom U232-P25' adapter
 812 + *   use a baud-rate code instead of a conventional RS-232 baud rate divisor.
 813 + *   The current source code for this driver does not reflect this fact, but
 814 + *   the driver works fine with this adapter/driver combination nonetheless.
 815 + *
 816   *
 817   * Line Control Register (LCR)
 818   * ---------------------------
 819   *
 820 - - *  BmRequestType:  0x4 (0100 0000B)    0xc (1100 0000B)
 821 - - *  bRequest:       0x7                 0x6
 822 - - *  wValue:         0x0
 823 - - *  wIndex:         0x0
 824 - - *  wLength:        0x1
 825 + *  BmRequestType:  0x40 (0100 0000B)    0xc0 (1100 0000B)
 826 + *  bRequest:       0x07                 0x06
 827 + *  wValue:         0x0000
 828 + *  wIndex:         0x0000
 829 + *  wLength:        0x0001
 830   *  Data:           LCR (see below)
 831   *
 832   *  Bit 7: Divisor Latch Access Bit (DLAB). When set, access to the data
 833 @@ -186,18 +210,18 @@
 834   *
 835   *  SniffUSB observations: Bit 7 seems not to be used. There seem to be two bugs
 836   *  in the Win98 driver: the break does not work (bit 6 is not asserted) and the
 837 - - *  sticky parity bit is not cleared when set once. The LCR can also be read
 838 + *  stick parity bit is not cleared when set once. The LCR can also be read
 839   *  back with USB request 6 but this has never been observed with SniffUSB.
 840   *
 841   *
 842   * Modem Control Register (MCR)
 843   * ----------------------------
 844   *
 845 - - *  BmRequestType:  0x4  (0100 0000B)
 846 - - *  bRequest:       0xa
 847 - - *  wValue:         0x0
 848 - - *  wIndex:         0x0
 849 - - *  wLength:        0x1
 850 + *  BmRequestType:  0x40  (0100 0000B)
 851 + *  bRequest:       0x0a
 852 + *  wValue:         0x0000
 853 + *  wIndex:         0x0000
 854 + *  wLength:        0x0001
 855   *  Data:           MCR (Bit 4..7, see below)
 856   *
 857   *  Bit 7: Reserved, always 0.
 858 @@ -226,11 +250,11 @@
 859   * Modem Status Register (MSR)
 860   * ---------------------------
 861   *
 862 - - *  BmRequestType:  0xc  (1100 0000B)
 863 - - *  bRequest:       0x2
 864 - - *  wValue:         0x0
 865 - - *  wIndex:         0x0
 866 - - *  wLength:        0x1
 867 + *  BmRequestType:  0xc0  (1100 0000B)
 868 + *  bRequest:       0x02
 869 + *  wValue:         0x0000
 870 + *  wIndex:         0x0000
 871 + *  wLength:        0x0001
 872   *  Data:           MSR (see below)
 873   *
 874   *  Bit 7: Data Carrier Detect (CD). Reflects the state of the DCD line on the
 875 @@ -285,6 +309,41 @@
 876   *  SniffUSB observations: the LSR is returned as second byte on the interrupt-in
 877   *  endpoint 0x83 to signal error conditions. Such errors have been seen with
 878   *  minicom/zmodem transfers (CRC errors).
 879 + *
 880 + *
 881 + * Unknown #1
 882 + * -------------------
 883 + *
 884 + *   BmRequestType:  0x40 (0100 0000B)
 885 + *   bRequest:       0x0b
 886 + *   wValue:         0x0000
 887 + *   wIndex:         0x0000
 888 + *   wLength:        0x0001
 889 + *   Data:           0x00
 890 + *
 891 + *   SniffUSB observations (Nov 2003): With the MCT-supplied Windows98 driver
 892 + *   (U2SPORT.VXD, "File version: 1.21P.0104 for Win98/Me"), this request
 893 + *   occurs immediately after a "Baud rate (divisor)" message.  It was not
 894 + *   observed at any other time.  It is unclear what purpose this message
 895 + *   serves.
 896 + *
 897 + *
 898 + * Unknown #2
 899 + * -------------------
 900 + *
 901 + *   BmRequestType:  0x40 (0100 0000B)
 902 + *   bRequest:       0x0c
 903 + *   wValue:         0x0000
 904 + *   wIndex:         0x0000
 905 + *   wLength:        0x0001
 906 + *   Data:           0x00
 907 + *
 908 + *   SniffUSB observations (Nov 2003): With the MCT-supplied Windows98 driver
 909 + *   (U2SPORT.VXD, "File version: 1.21P.0104 for Win98/Me"), this request
 910 + *   occurs immediately after the 'Unknown #1' message (see above).  It was
 911 + *   not observed at any other time.  It is unclear what other purpose (if
 912 + *   any) this message might serve, but without it, the USB/RS-232 adapter
 913 + *   will not write to RS-232 devices which do not assert the 'CTS' signal.
 914   *
 915   *
 916   * Flow control
 917 - -
 918 To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in
 919 the body of a message to majordomo@vger.kernel.org
 920 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 921 - From cel@citi.umich.edu Thu Dec 18 22:13:19 2003
 922 Date: Thu, 18 Dec 2003 16:34:58 -0500 (EST)
 923 From: Chuck Lever <cel@citi.umich.edu>
 924 To: Marcelo Tosatti <marcelo@conectiva.com.br>
 925 Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 926      Trond Myklebust <trond.myklebust@fys.uio.no>,
 927      Steve Dickson <SteveD@redhat.com>, greg.marsden@oracle.com
 928 Subject: [PATCH] NFS O_DIRECT offset wrap bug
 929
 930 hi marcelo-
 931
 932 here's an obvious mistake i made in the NFS O_DIRECT implementation.  a
 933 missing type cast causes the offset of direct read and write requests to
 934 wrap at 4GB.  please include this in 2.4.24-pre2.
 935
 936 as far as i can tell, this is not a problem for 2.6 NFS O_DIRECT.
 937
 938
 939 diff -X ../dont-diff -Naurp 00-stock/fs/nfs/direct.c 01-direct-offset/fs/nfs/direct.c
 940 - --- 00-stock/fs/nfs/direct.c  2003-08-25 07:44:43.000000000 -0400
 941 +++ 01-direct-offset/fs/nfs/direct.c    2003-12-18 16:28:20.000000000 -0500
 942 @@ -354,7 +354,7 @@ nfs_direct_IO(int rw, struct file *file,
 943         size_t count = iobuf->length;
 944         struct dentry *dentry = file->f_dentry;
 945         struct inode *inode = dentry->d_inode;
 946 - -     loff_t offset = blocknr << inode->i_blkbits;
 947 +       loff_t offset = (loff_t) blocknr << inode->i_blkbits;
 948
 949         switch (rw) {
 950         case READ:
 951
 952         - Chuck Lever
 953 - --
 954 corporate:      <cel at netapp dot com>
 955 personal:       <chucklever at bigfoot dot com>
 956
 957 - -
 958 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 959 the body of a message to majordomo@vger.kernel.org
 960 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 961 Please read the FAQ at  http://www.tux.org/lkml/
 962 - From linux-kernel@vger.kernel.org Thu Dec 18 21:47:47 2003
 963 Date: Mon, 15 Dec 2003 05:42:19 +0000
 964 From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
 965 To: bk-commits-24@vger.kernel.org
 966 Subject: [PPC64] Fix compile error in arch/ppc64/kernel/pmc.c.
 967
 968 ChangeSet 1.1270.3.10, 2003/12/15 16:42:19+11:00, paulus@quango.ozlabs.ibm.com
 969
 970         [PPC64] Fix compile error in arch/ppc64/kernel/pmc.c.
 971
 972
 973 # This patch includes the following deltas:
 974 #                  ChangeSet    1.1270.3.9 -> 1.1270.3.10
 975 #       arch/ppc64/kernel/pmc.c 1.5     -> 1.6
 976 #       include/asm-ppc64/mmu.h 1.4     -> 1.5
 977 #
 978
 979  arch/ppc64/kernel/pmc.c |    5 ++---
 980  include/asm-ppc64/mmu.h |    3 ++-
 981  2 files changed, 4 insertions(+), 4 deletions(-)
 982
 983
 984 diff -Nru a/arch/ppc64/kernel/pmc.c b/arch/ppc64/kernel/pmc.c
 985 - --- a/arch/ppc64/kernel/pmc.c Mon Dec 15 07:04:01 2003
 986 +++ b/arch/ppc64/kernel/pmc.c   Mon Dec 15 07:04:01 2003
 987 @@ -74,7 +74,6 @@
 988                                  page_table_lock : SPIN_LOCK_UNLOCKED};
 989
 990  extern spinlock_t hash_table_lock[];
 991 - -extern inline unsigned long get_lock_slot(unsigned long vpn);
 992
 993  char *
 994  ppc64_pmc_stab(int file)
 995 @@ -241,7 +240,7 @@
 996                 lock_slot = get_lock_slot(vpn);
 997                 rpn = pa >> PAGE_SHIFT;
 998
 999 - -             spin_lock(&hash_table_lock[lock_slot].lock);
1000 +               spin_lock(&hash_table_lock[lock_slot]);
1001                 /* Get a pointer to the linux page table entry for this page
1002                  * allocating pmd or pte pages along the way as needed.  Note
1003                  * that the pmd & pte pages are not themselfs bolted.
1004 @@ -266,7 +265,7 @@
1005
1006                 *ptep = pte;
1007
1008 - -             spin_unlock(&hash_table_lock[lock_slot].lock);
1009 +               spin_unlock(&hash_table_lock[lock_slot]);
1010         }
1011
1012         spin_unlock(&btmalloc_mm.page_table_lock);
1013 diff -Nru a/include/asm-ppc64/mmu.h b/include/asm-ppc64/mmu.h
1014 - --- a/include/asm-ppc64/mmu.h Mon Dec 15 07:04:01 2003
1015 +++ b/include/asm-ppc64/mmu.h   Mon Dec 15 07:04:01 2003
1016 @@ -180,7 +180,7 @@
1017  extern HTAB htab_data;
1018
1019  #include <linux/cache.h>
1020 - -#include <asm/spinlock.h>
1021 +#include <linux/spinlock.h>
1022  typedef struct {
1023         spinlock_t lock;
1024  } ____cacheline_aligned hash_table_lock_t;
1025 @@ -191,6 +191,7 @@
1026                         unsigned long prpn, unsigned hash,
1027                         void * ptep, unsigned hpteflags,
1028                         unsigned bolted );
1029 +unsigned long get_lock_slot(unsigned long vpn);
1030
1031  #define PD_SHIFT (10+12)               /* Page directory */
1032  #define PD_MASK  0x02FF
1033 - -
1034 To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in
1035 the body of a message to majordomo@vger.kernel.org
1036 More majordomo info at  http://vger.kernel.org/majordomo-info.html
1037 - From linux-kernel@vger.kernel.org Thu Dec 18 21:48:23 2003
1038 Date: Mon, 15 Dec 2003 03:20:20 +0000
1039 From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
1040 To: bk-commits-24@vger.kernel.org
1041 Subject: [PPC64] Fix smp_call_function so we don't crash if an IPI is very
1042     late.
1043
1044 ChangeSet 1.1270.3.2, 2003/12/15 14:20:20+11:00, olof@austin.ibm.com
1045
1046         [PPC64] Fix smp_call_function so we don't crash if an IPI is very late.
1047
1048
1049 # This patch includes the following deltas:
1050 #                  ChangeSet    1.1270.3.1 -> 1.1270.3.2
1051 #       arch/ppc64/kernel/smp.c 1.4     -> 1.5
1052 #
1053
1054  smp.c |   18 +++++++++++++++---
1055  1 files changed, 15 insertions(+), 3 deletions(-)
1056
1057
1058 diff -Nru a/arch/ppc64/kernel/smp.c b/arch/ppc64/kernel/smp.c
1059 - --- a/arch/ppc64/kernel/smp.c Mon Dec 15 07:03:47 2003
1060 +++ b/arch/ppc64/kernel/smp.c   Mon Dec 15 07:03:47 2003
1061 @@ -564,6 +564,7 @@
1062         ret = 0;
1063
1064   out:
1065 +       call_data = NULL;
1066         HMT_medium();
1067         spin_unlock_bh(&call_lock);
1068         return ret;
1069 @@ -571,9 +572,20 @@
1070
1071  void smp_call_function_interrupt(void)
1072  {
1073 - -     void (*func) (void *info) = call_data->func;
1074 - -     void *info = call_data->info;
1075 - -     int wait = call_data->wait;
1076 +       void (*func) (void *info);
1077 +       void *info;
1078 +       int wait;
1079 +
1080 +
1081 +       /* call_data will be NULL if the sender timed out while
1082 +        * waiting on us to receive the call.
1083 +        */
1084 +       if (!call_data)
1085 +               return;
1086 +
1087 +       func = call_data->func;
1088 +       info = call_data->info;
1089 +       wait = call_data->wait;
1090
1091         /*
1092          * Notify initiating CPU that I've grabbed the data and am
1093 - -
1094 To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in
1095 the body of a message to majordomo@vger.kernel.org
1096 More majordomo info at  http://vger.kernel.org/majordomo-info.html
1097 - From linux-kernel@vger.kernel.org Thu Dec 18 21:45:37 2003
1098 Date: Sun, 14 Dec 2003 05:52:29 +0000
1099 From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
1100 To: bk-commits-24@vger.kernel.org
1101 Subject: [SPARC32]: Fix build after asm/system.h include was added to
1102     linux/spinlock.h
1103
1104 ChangeSet 1.1270.1.7, 2003/12/13 21:52:29-08:00, davem@nuts.ninka.net
1105
1106         [SPARC32]: Fix build after asm/system.h include was added to linux/spinlock.h
1107
1108         - Do not include asm/oplib.h in system.h
1109         - Remove system.h's halt() macro, prom_halt() is equivalent so replace
1110           the two users of halt() with that.
1111         - Put 'romvec' extern decl where it belongs, in openprom.h
1112
1113         Based upon a patch from Rob Radez.
1114
1115
1116 # This patch includes the following deltas:
1117 #                  ChangeSet    1.1270.1.6 -> 1.1270.1.7
1118 #       include/asm-sparc/openprom.h    1.1     -> 1.2
1119 #       include/asm-sparc/system.h      1.7     -> 1.8
1120 #       arch/sparc/kernel/devices.c     1.4     -> 1.5
1121 #       include/asm-sparc/oplib.h       1.3     -> 1.4
1122 #       arch/sparc/kernel/ioport.c      1.8     -> 1.9
1123 #
1124
1125  arch/sparc/kernel/devices.c  |    2 +-
1126  arch/sparc/kernel/ioport.c   |    2 +-
1127  include/asm-sparc/openprom.h |    2 ++
1128  include/asm-sparc/oplib.h    |    3 ---
1129  include/asm-sparc/system.h   |    4 ----
1130  5 files changed, 4 insertions(+), 9 deletions(-)
1131
1132
1133 diff -Nru a/arch/sparc/kernel/devices.c b/arch/sparc/kernel/devices.c
1134 - --- a/arch/sparc/kernel/devices.c     Mon Dec 15 07:03:40 2003
1135 +++ b/arch/sparc/kernel/devices.c       Mon Dec 15 07:03:40 2003
1136 @@ -72,7 +72,7 @@
1137                 if (linux_num_cpus == 0) {
1138                         printk("No CPU nodes found, cannot continue.\n");
1139                         /* Probably a sun4e, Sun is trying to trick us ;-) */
1140 - -                     halt();
1141 +                       prom_halt();
1142                 }
1143                 printk("Found %d CPU prom device tree node(s).\n", linux_num_cpus);
1144         }
1145 diff -Nru a/arch/sparc/kernel/ioport.c b/arch/sparc/kernel/ioport.c
1146 - --- a/arch/sparc/kernel/ioport.c      Mon Dec 15 07:03:40 2003
1147 +++ b/arch/sparc/kernel/ioport.c        Mon Dec 15 07:03:40 2003
1148 @@ -760,7 +760,7 @@
1149         default:
1150                 printk("ioport_init: cpu type %d is unknown.\n",
1151                     sparc_cpu_model);
1152 - -             halt();
1153 +               prom_halt();
1154         };
1155
1156  }
1157 diff -Nru a/include/asm-sparc/openprom.h b/include/asm-sparc/openprom.h
1158 - --- a/include/asm-sparc/openprom.h    Mon Dec 15 07:03:40 2003
1159 +++ b/include/asm-sparc/openprom.h      Mon Dec 15 07:03:40 2003
1160 @@ -169,6 +169,8 @@
1161         int (*v3_cpuresume)(unsigned int whichcpu);
1162  };
1163
1164 +extern struct linux_romvec *romvec;
1165 +
1166  /* Routines for traversing the prom device tree. */
1167  struct linux_nodeops {
1168         int (*no_nextnode)(int node);
1169 diff -Nru a/include/asm-sparc/oplib.h b/include/asm-sparc/oplib.h
1170 - --- a/include/asm-sparc/oplib.h       Mon Dec 15 07:03:40 2003
1171 +++ b/include/asm-sparc/oplib.h Mon Dec 15 07:03:40 2003
1172 @@ -11,9 +11,6 @@
1173  #include <asm/openprom.h>
1174  #include <linux/spinlock.h>
1175
1176 - -/* The master romvec pointer... */
1177 - -extern struct linux_romvec *romvec;
1178 - -
1179  /* Enumeration to describe the prom major version we have detected. */
1180  enum prom_major_version {
1181         PROM_V0,      /* Original sun4c V0 prom */
1182 diff -Nru a/include/asm-sparc/system.h b/include/asm-sparc/system.h
1183 - --- a/include/asm-sparc/system.h      Mon Dec 15 07:03:40 2003
1184 +++ b/include/asm-sparc/system.h        Mon Dec 15 07:03:40 2003
1185 @@ -10,7 +10,6 @@
1186
1187  #ifdef __KERNEL__
1188  #include <asm/page.h>
1189 - -#include <asm/oplib.h>
1190  #include <asm/psr.h>
1191  #include <asm/ptrace.h>
1192  #include <asm/btfixup.h>
1193 @@ -51,9 +50,6 @@
1194  extern unsigned long empty_bad_page;
1195  extern unsigned long empty_bad_page_table;
1196  extern unsigned long empty_zero_page;
1197 - -
1198 - -extern struct linux_romvec *romvec;
1199 - -#define halt() romvec->pv_halt()
1200
1201  /* When a context switch happens we must flush all user windows so that
1202   * the windows of the current process are flushed onto its stack. This
1203 - -
1204 To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in
1205 the body of a message to majordomo@vger.kernel.org
1206 More majordomo info at  http://vger.kernel.org/majordomo-info.html
1207 - From linux-kernel@vger.kernel.org Thu Dec 18 21:38:26 2003
1208 Date: Fri, 12 Dec 2003 18:18:02 +0000
1209 From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
1210 To: bk-commits-24@vger.kernel.org
1211 Subject: [PATCH] USB: fix bug when errors happen in ioedgeport driver
1212
1213 ChangeSet 1.1286, 2003/12/12 10:18:02-08:00, tchen@on-go.com
1214
1215         [PATCH] USB: fix bug when errors happen in ioedgeport driver
1216
1217
1218 # This patch includes the following deltas:
1219 #                  ChangeSet    1.1285  -> 1.1286
1220 #       drivers/usb/serial/io_edgeport.c        1.26    -> 1.27
1221 #
1222
1223  io_edgeport.c |   12 ++++++++----
1224  1 files changed, 8 insertions(+), 4 deletions(-)
1225
1226
1227 diff -Nru a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c
1228 - --- a/drivers/usb/serial/io_edgeport.c        Mon Dec 15 07:03:23 2003
1229 +++ b/drivers/usb/serial/io_edgeport.c  Mon Dec 15 07:03:23 2003
1230 @@ -1468,15 +1468,19 @@
1231         urb->transfer_flags |= USB_QUEUE_BULK;
1232
1233         urb->dev = edge_serial->serial->dev;
1234 +       /* decrement the number of credits we have by the number we just sent */
1235 +       edge_port->txCredits -= count;
1236 +       edge_port->icount.tx += count;
1237 +
1238         status = usb_submit_urb(urb);
1239         if (status) {
1240                 /* something went wrong */
1241                 dbg("%s - usb_submit_urb(write bulk) failed", __FUNCTION__);
1242                 edge_port->write_in_progress = FALSE;
1243 - -     } else {
1244 - -             /* decrement the number of credits we have by the number we just sent */
1245 - -             edge_port->txCredits -= count;
1246 - -             edge_port->icount.tx += count;
1247 +
1248 +               /*revert the count if something bad happened...*/
1249 +               edge_port->txCredits += count;
1250 +               edge_port->icount.tx -= count;
1251         }
1252         dbg("%s wrote %d byte(s) TxCredit %d, Fifo %d", __FUNCTION__, count, edge_port->txCredits, fifo->count);
1253  }
1254 - -
1255 To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in
1256 the body of a message to majordomo@vger.kernel.org
1257 More majordomo info at  http://vger.kernel.org/majordomo-info.html
1258
1259
1260 - From linux-kernel@vger.kernel.org Thu Dec 18 21:39:10 2003
1261 Date: Fri, 12 Dec 2003 18:18:22 +0000
1262 From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
1263 To: bk-commits-24@vger.kernel.org
1264 Subject: [PATCH] USB: fix io_edgeport driver alignment issues.
1265
1266 ChangeSet 1.1287, 2003/12/12 10:18:22-08:00, tchen@on-go.com
1267
1268         [PATCH] USB: fix io_edgeport driver alignment issues.
1269
1270
1271 # This patch includes the following deltas:
1272 #                  ChangeSet    1.1286  -> 1.1287
1273 #       drivers/usb/serial/io_fw_boot2.h        1.3     -> 1.4
1274 #       drivers/usb/serial/io_fw_down2.h        1.3     -> 1.4
1275 #       drivers/usb/serial/io_fw_down.h 1.3     -> 1.4
1276 #       drivers/usb/serial/io_fw_boot.h 1.3     -> 1.4
1277 #
1278
1279  io_fw_boot.h  |    2 +-
1280  io_fw_boot2.h |    2 +-
1281  io_fw_down.h  |    2 +-
1282  io_fw_down2.h |    2 +-
1283  4 files changed, 4 insertions(+), 4 deletions(-)
1284
1285
1286 diff -Nru a/drivers/usb/serial/io_fw_boot.h b/drivers/usb/serial/io_fw_boot.h
1287 - --- a/drivers/usb/serial/io_fw_boot.h Mon Dec 15 07:03:25 2003
1288 +++ b/drivers/usb/serial/io_fw_boot.h   Mon Dec 15 07:03:25 2003
1289 @@ -17,7 +17,7 @@
1290                 unsigned short Addr;
1291                 unsigned short Len;
1292                 unsigned char  Data[0];
1293 - -     };
1294 +       } __attribute__ ((packed));
1295
1296         struct edge_firmware_version_info {
1297                 unsigned char    MajorVersion;
1298 diff -Nru a/drivers/usb/serial/io_fw_boot2.h b/drivers/usb/serial/io_fw_boot2.h
1299 - --- a/drivers/usb/serial/io_fw_boot2.h        Mon Dec 15 07:03:25 2003
1300 +++ b/drivers/usb/serial/io_fw_boot2.h  Mon Dec 15 07:03:25 2003
1301 @@ -17,7 +17,7 @@
1302                 unsigned short Addr;
1303                 unsigned short Len;
1304                 unsigned char  Data[0];
1305 - -     };
1306 +       } __attribute__ ((packed));
1307
1308         struct edge_firmware_version_info {
1309                 unsigned char    MajorVersion;
1310 diff -Nru a/drivers/usb/serial/io_fw_down.h b/drivers/usb/serial/io_fw_down.h
1311 - --- a/drivers/usb/serial/io_fw_down.h Mon Dec 15 07:03:25 2003
1312 +++ b/drivers/usb/serial/io_fw_down.h   Mon Dec 15 07:03:25 2003
1313 @@ -17,7 +17,7 @@
1314                 unsigned short  Addr;
1315                 unsigned short  Len;
1316                 unsigned char   Data[0];
1317 - -     };
1318 +       } __attribute ((packed));
1319
1320         struct edge_firmware_version_info {
1321                 unsigned char   MajorVersion;
1322 diff -Nru a/drivers/usb/serial/io_fw_down2.h b/drivers/usb/serial/io_fw_down2.h
1323 - --- a/drivers/usb/serial/io_fw_down2.h        Mon Dec 15 07:03:25 2003
1324 +++ b/drivers/usb/serial/io_fw_down2.h  Mon Dec 15 07:03:25 2003
1325 @@ -17,7 +17,7 @@
1326                 unsigned short Addr;
1327                 unsigned short Len;
1328                 unsigned char  Data[0];
1329 - -     };
1330 +       } __attribute__ ((packed));
1331
1332         struct edge_firmware_version_info {
1333                 unsigned char  MajorVersion;
1334 - -
1335 To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in
1336 the body of a message to majordomo@vger.kernel.org
1337 More majordomo info at  http://vger.kernel.org/majordomo-info.html
1338 - From linux-kernel@vger.kernel.org Sun Dec 28 14:33:44 2003
1339 Date: Sun, 07 Dec 2003 18:27:17 +0000
1340 From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
1341 To: bk-commits-24@vger.kernel.org
1342 Subject: [wireless airo] Delay MIC activation to prevent Oops
1343
1344 ChangeSet 1.1136.73.7, 2003/12/07 13:27:17-05:00, achirica@telefonica.net
1345
1346         [wireless airo] Delay MIC activation to prevent Oops
1347
1348
1349 # This patch includes the following deltas:
1350 #                  ChangeSet    1.1136.73.6 -> 1.1136.73.7
1351 #       drivers/net/wireless/airo.c     1.62    -> 1.63
1352 #
1353
1354  airo.c |    7 ++-----
1355  1 files changed, 2 insertions(+), 5 deletions(-)
1356
1357
1358 diff -ruN linux-2.4.23.mine/drivers/net/wireless/airo.c linux-2.4.23/drivers/net/wireless/airo.c
1359 - --- linux-2.4.23.mine/drivers/net/wireless/airo.c     2003-11-28 11:26:20.000000000 -0700
1360 +++ linux-2.4.23/drivers/net/wireless/airo.c    2003-12-28 22:30:56.064562029 -0700
1361 @@ -2476,11 +2476,8 @@
1362                         OUT4500( apriv, EVACK, EV_MIC );
1363  #ifdef MICSUPPORT
1364                         if (test_bit(FLAG_MIC_CAPABLE, &apriv->flags)) {
1365 - -                             if (down_trylock(&apriv->sem) != 0) {
1366 - -                                     set_bit(JOB_MIC, &apriv->flags);
1367 - -                                     wake_up_interruptible(&apriv->thr_wait);
1368 - -                             } else
1369 - -                                     micinit (apriv);
1370 +                               set_bit(JOB_MIC, &apriv->flags);
1371 +                               wake_up_interruptible(&apriv->thr_wait);
1372                         }
1373  #endif
1374                 }
1375 - From linux-kernel@vger.kernel.org Sun Dec 28 14:34:44 2003
1376 Date: Sun, 07 Dec 2003 18:27:13 +0000
1377 From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
1378 To: bk-commits-24@vger.kernel.org
1379 Subject: [wireless airo] Fix PCI registration
1380
1381 ChangeSet 1.1136.73.6, 2003/12/07 13:27:13-05:00, achirica@telefonica.net
1382
1383         [wireless airo] Fix PCI registration
1384
1385
1386 # This patch includes the following deltas:
1387 #                  ChangeSet    1.1136.73.5 -> 1.1136.73.6
1388 #       drivers/net/wireless/airo.c     1.61    -> 1.62
1389 #
1390
1391  airo.c |   13 ++-----------
1392  1 files changed, 2 insertions(+), 11 deletions(-)
1393
1394
1395 diff -ruN linux-2.4.23.mine/drivers/net/wireless/airo.c linux-2.4.23/drivers/net/wireless/airo.c
1396 - --- linux-2.4.23.mine/drivers/net/wireless/airo.c     2003-12-28 22:32:51.418220092 -0700
1397 +++ linux-2.4.23/drivers/net/wireless/airo.c    2003-12-28 22:33:04.226400129 -0700
1398 @@ -1034,7 +1034,6 @@
1399  #define FLAG_802_11    7
1400  #define FLAG_PENDING_XMIT 9
1401  #define FLAG_PENDING_XMIT11 10
1402 - -#define FLAG_PCI     11
1403  #define JOB_MASK       0x1ff0000
1404  #define JOB_DIE                16
1405  #define JOB_XMIT       17
1406 @@ -4639,7 +4638,6 @@
1407                 return -ENODEV;
1408
1409         pci_set_drvdata(pdev, dev);
1410 - -     set_bit (FLAG_PCI, &((struct airo_info *)dev->priv)->flags);
1411         return 0;
1412  }
1413
1414 @@ -4669,7 +4667,7 @@
1415
1416  #ifdef CONFIG_PCI
1417         printk( KERN_INFO "airo:  Probing for PCI adapters\n" );
1418 - -     pci_module_init(&airo_driver);
1419 +       pci_register_driver(&airo_driver);
1420         printk( KERN_INFO "airo:  Finished probing for PCI adapters\n" );
1421  #endif
1422
1423 @@ -4681,22 +4679,15 @@
1424
1425  static void __exit airo_cleanup_module( void )
1426  {
1427 - -     int is_pci = 0;
1428         while( airo_devices ) {
1429                 printk( KERN_INFO "airo: Unregistering %s\n", airo_devices->dev->name );
1430 - -#ifdef CONFIG_PCI
1431 - -             if (test_bit(FLAG_PCI, &((struct airo_info *)airo_devices->dev->priv)->flags))
1432 - -                     is_pci = 1;
1433 - -#endif
1434                 stop_airo_card( airo_devices->dev, 1 );
1435         }
1436         remove_proc_entry("aironet", proc_root_driver);
1437
1438 - -     if (is_pci) {
1439  #ifdef CONFIG_PCI
1440 - -             pci_unregister_driver(&airo_driver);
1441 +       pci_unregister_driver(&airo_driver);
1442  #endif
1443 - -     }
1444  }
1445
1446  #ifdef WIRELESS_EXT
1447 - From linux-kernel@vger.kernel.org Sun Dec 28 14:37:12 2003
1448 Date: Sun, 28 Dec 2003 20:09:56 +0000
1449 From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
1450 To: bk-commits-24@vger.kernel.org
1451 Subject: Daniel Lux: Fix IDE busy-wait race
1452
1453 ChangeSet 1.1344, 2003/12/28 18:09:56-02:00, marcelo@logos.cnet
1454
1455           Daniel Lux: Fix IDE busy-wait race
1456
1457
1458 # This patch includes the following deltas:
1459 #                  ChangeSet    1.1343  -> 1.1344
1460 #       drivers/ide/ide-iops.c  1.7     -> 1.8
1461 #
1462
1463  ide-iops.c |   16 ++++++++++++----
1464  1 files changed, 12 insertions(+), 4 deletions(-)
1465
1466
1467 diff -Nru a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c
1468 - --- a/drivers/ide/ide-iops.c  Sun Dec 28 13:01:41 2003
1469 +++ b/drivers/ide/ide-iops.c    Sun Dec 28 13:01:41 2003
1470 @@ -664,11 +664,19 @@
1471         if ((stat = hwif->INB(IDE_STATUS_REG)) & BUSY_STAT) {
1472                 local_irq_set(flags);
1473                 timeout += jiffies;
1474 - -             while ((stat = hwif->INB(IDE_STATUS_REG)) & BUSY_STAT) {
1475 +               stat = hwif->INB(IDE_STATUS_REG);
1476 +               while (stat & BUSY_STAT) {
1477                         if (time_after(jiffies, timeout)) {
1478 - -                             local_irq_restore(flags);
1479 - -                             *startstop = DRIVER(drive)->error(drive, "status timeout", stat);
1480 - -                             return 1;
1481 +                               /*
1482 +                                * do one more status read in case we were interrupted between last
1483 +                                * stat = hwif->INB(IDE_STATUS_REG) and time_after(jiffies, timeout)
1484 +                                * in wich case the timeout might have been shorter than specified.
1485 +                                */
1486 +                               if ((stat = hwif->INB(IDE_STATUS_REG)) & BUSY_STAT) {
1487 +                                       local_irq_restore(flags);
1488 +                                       *startstop = DRIVER(drive)->error(drive, "status timeout", stat);
1489 +                                       return 1;
1490 +                               }
1491                         }
1492                 }
1493                 local_irq_restore(flags);
1494 - -
1495 To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in
1496 the body of a message to majordomo@vger.kernel.org
1497 More majordomo info at  http://vger.kernel.org/majordomo-info.html
1498
1499 - From linux-kernel@vger.kernel.org Sun Dec 28 14:37:46 2003
1500 Date: Sun, 28 Dec 2003 20:14:56 +0000
1501 From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
1502 To: bk-commits-24@vger.kernel.org
1503 Subject: Fix IDE busywait merge
1504
1505 ChangeSet 1.1345, 2003/12/28 18:14:56-02:00, marcelo@logos.cnet
1506
1507           Fix IDE busywait merge
1508
1509
1510 # This patch includes the following deltas:
1511 #                  ChangeSet    1.1344  -> 1.1345
1512 #       drivers/ide/ide-iops.c  1.8     -> 1.9
1513 #
1514
1515  ide-iops.c |    2 ++
1516  1 files changed, 2 insertions(+)
1517
1518
1519 diff -Nru a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c
1520 - --- a/drivers/ide/ide-iops.c  Sun Dec 28 13:01:43 2003
1521 +++ b/drivers/ide/ide-iops.c    Sun Dec 28 13:01:43 2003
1522 @@ -678,6 +678,8 @@
1523                                         return 1;
1524                                 }
1525                         }
1526 +                       else
1527 +                               stat = hwif->INB(IDE_STATUS_REG);
1528                 }
1529                 local_irq_restore(flags);
1530         }
1531 - -
1532 To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in
1533 the body of a message to majordomo@vger.kernel.org
1534 More majordomo info at  http://vger.kernel.org/majordomo-info.html
1535 - From linux-kernel@vger.kernel.org Sun Dec 28 14:36:33 2003
1536 Date: Mon, 22 Dec 2003 18:41:06 +0000
1537 From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
1538 To: bk-commits-24@vger.kernel.org
1539 Subject: [PATCH] Initialize ioc3_timer before use
1540
1541 ChangeSet 1.1339, 2003/12/22 16:41:06-02:00, ralf@linux-mips.org
1542
1543         [PATCH] Initialize ioc3_timer before use
1544
1545
1546
1547 # This patch includes the following deltas:
1548 #                  ChangeSet    1.1338  -> 1.1339
1549 #       drivers/net/ioc3-eth.c  1.15    -> 1.16
1550 #
1551
1552  ioc3-eth.c |    2 +-
1553  1 files changed, 1 insertion(+), 1 deletion(-)
1554
1555
1556 diff -ruN linux-2.4.23.mine/drivers/net/ioc3-eth.c linux-2.4.23/drivers/net/ioc3-eth.c
1557 - --- linux-2.4.23.mine/drivers/net/ioc3-eth.c  2003-08-25 05:44:42.000000000 -0600
1558 +++ linux-2.4.23/drivers/net/ioc3-eth.c 2003-12-28 22:39:33.291078118 -0700
1559 @@ -1552,11 +1552,11 @@
1560  #endif
1561
1562         spin_lock_init(&ip->ioc3_lock);
1563 +       init_timer(&ip->ioc3_timer);
1564
1565         ioc3_stop(ip);
1566         ioc3_init(ip);
1567
1568 - -     init_timer(&ip->ioc3_timer);
1569         ioc3_mii_init(ip);
1570
1571         if (ip->phy == -1) {
1572 - From linux-kernel@vger.kernel.org Sun Dec 28 14:29:04 2003
1573 Date: Mon, 22 Dec 2003 11:32:50 +0000
1574 From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
1575 To: bk-commits-24@vger.kernel.org
1576 Subject: [PATCH] Fix RAID1 blocksize check
1577
1578 ChangeSet 1.1313, 2003/12/22 09:32:50-02:00, neilb@cse.unsw.edu.au
1579
1580         [PATCH] Fix RAID1 blocksize check
1581
1582         On Saturday December 20, zaitcev@redhat.com wrote:
1583         > In drivers/md/raid1.c, raid1_sync_request contains the following:
1584         >
1585         >         block_nr = sector_nr;
1586         >         bsize = 512;
1587         >         while (!(block_nr & 1) && bsize < PAGE_SIZE
1588         >                         && (block_nr+2)*(bsize>>9) < (mddev->sb->size *2)) {
1589         >                 block_nr >>= 1;
1590         >                 bsize <<= 1;
1591         >         }
1592         >
1593         > Suppose that a mirror is 4K in size. The code above produces
1594         > reads (and writes) of the following offsets and sizes:
1595         >  0K[2K], 2K[1K], 3K[0.5K], 3.5K[0.5K]
1596         >
1597         > The above is correct, but it makes the RAID1 completely unuseable
1598         > on s390, because I/O with sizes less than 4K is not supported.
1599         > I would like the attached patch applied to correct the issue.
1600
1601         Yes, I agree.  Marcelo, could you please apply this patch.
1602         The '<' test is just to make sure a request of 2*bsize at block_nr
1603         will still fit within the size of the device, so a <= is appropriate.
1604
1605         NeilBrown
1606
1607
1608 # This patch includes the following deltas:
1609 #                  ChangeSet    1.1312  -> 1.1313
1610 #         drivers/md/raid1.c    1.16    -> 1.17
1611 #
1612
1613  raid1.c |    2 +-
1614  1 files changed, 1 insertion(+), 1 deletion(-)
1615
1616
1617 diff -Nru a/drivers/md/raid1.c b/drivers/md/raid1.c
1618 - --- a/drivers/md/raid1.c      Mon Dec 22 04:03:08 2003
1619 +++ b/drivers/md/raid1.c        Mon Dec 22 04:03:08 2003
1620 @@ -1436,7 +1436,7 @@
1621         block_nr = sector_nr;
1622         bsize = 512;
1623         while (!(block_nr & 1) && bsize < PAGE_SIZE
1624 - -                     && (block_nr+2)*(bsize>>9) < (mddev->sb->size *2)) {
1625 +                       && (block_nr+2)*(bsize>>9) <= (mddev->sb->size *2)) {
1626                 block_nr >>= 1;
1627                 bsize <<= 1;
1628         }
1629 - -
1630 To unsubscribe from this list: send the line "unsubscribe bk-commits-24" in
1631 the body of a message to majordomo@vger.kernel.org
1632 More majordomo info at  http://vger.kernel.org/majordomo-info.html
1633