1. 27 May, 2004 18 commits
    • Don Fry's avatar
      [PATCH] pcnet32: fix bogus carrier errors with 79c973 · a8807fa8
      Don Fry authored
      The 79C973 version of the pcnet32 chipset would report all transmit
      operations as being sent with a carrier error.  The root cause was
      writing reserved bits in bcr33.  It caused the 973 to report xmit
      as errors, and caused 975 and 976 to hard hang when reading bcr34.
      
      My thanks to Bruce Penrod for his help in finding the cause of this
      bug.
      a8807fa8
    • Don Fry's avatar
      [PATCH] pcnet32: limit frames received during interrupt. · 3385606e
      Don Fry authored
      The current code will allow an infinite number of frames to be received
      during one interrupt.  Tested ia32 and ppc64.
      3385606e
    • Don Fry's avatar
      [PATCH] pcnet32: remove timer and complexity. · 5d3c8230
      Don Fry authored
      This removes the timer I recently added, and the 'ltint' interrupt
      mitigation from the 79C971 and 79C972. It did not improve performance,
      added complexity, and was a bad idea in hind sight.
      5d3c8230
    • Don Fry's avatar
      [PATCH] pcnet32: fix boundary comparison bug. · e932fecf
      Don Fry authored
      This patch fixes a boundary condition.  It is possible to get an
      interrupt and have the transmit queue completely full.  Without this
      the driver will leak skb's and pci maps (if the arch supports them).
      e932fecf
    • Don Fry's avatar
      [PATCH] pcnet32: correct 79C976 variant string. · 1ac65768
      Don Fry authored
      This patch correctly identifies the 79C976 as a PCnet/PRO not a FAST III.
      1ac65768
    • Don Fry's avatar
      [PATCH] pcnet32: avoid hard hang with some chip variants. · ea8cba88
      Don Fry authored
      This patch fixes a hard hang with 79C975 and 79C976 chip variants when
      dumping BCR register #34.
      ea8cba88
    • Don Fry's avatar
      [PATCH] pcnet32: add static to two routines. · 741948bc
      Don Fry authored
      This patch adds 'static' to two routines.  The prototype has static but
      the instantiation did not.
      741948bc
    • Andrew Morton's avatar
      [PATCH] nfsd: deleting symlinks over nfs causes oops on unmount · 3d61e387
      Andrew Morton authored
      From: "J. Bruce Fields" <bfields@fieldses.org>
      From: Neil Brown <neilb@cse.unsw.edu.au>
      
      This fixes an oops on unmount (failure of the assertation at
      fs/ext3/super.c:421).  Probably reproduceable just by creating and deleting a
      single symlink over nfs and then unmounting the exported filesystem.
      
      Recent change to fh_compose means dentry reference is *not* consumed, and so
      usually has to be explicitly dput afterwards.  One usage was missed in that
      patch, so this dput is needed.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      3d61e387
    • Andrew Morton's avatar
      [PATCH] Print backtrace for bad vfree() · 3b15e36b
      Andrew Morton authored
      From: Andi Kleen <ak@suse.de>
      
      Only the printk alone is not too useful, print the backtrace too.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      3b15e36b
    • Andrew Morton's avatar
      [PATCH] swsusp documentation updates · 39d51810
      Andrew Morton authored
      From: Pavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      39d51810
    • Andrew Morton's avatar
      [PATCH] CPU Hotplug: restore Idle task's priority during CPU_DEAD notification · faf898a6
      Andrew Morton authored
      From: Srivatsa Vaddagiri <vatsa@in.ibm.com>
      
      Fix a CPU Hotplug problem wherein idle task's "->prio" value is not
      restored to MAX_PRIO during CPU_DEAD handling.  Without this patch, once a
      CPU is offlined and then later onlined, it becomes "more or less" useless
      (does not run any task other than its idle task!)
      
      Ingo said:
      
        The __setscheduler() call is (technically) incorrect because in the
        SCHED_NORMAL case the prio should be zero.  So it's a bit cleaner to set up
        the static priority to MAX_PRIO and then revert the policy to SCHED_NORMAL
        via __setscheduler().
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      faf898a6
    • Andrew Morton's avatar
      [PATCH] remove message: POSIX conformance testing by UNIFIX · 4ffa43b8
      Andrew Morton authored
      From: "Randy.Dunlap" <rddunlap@osdl.org>
      
      Remove the outdated "POSIX conformance testing by UNIFIX" message.
      
      There is a general desire to reduce the quantity of noisy and/or
      outdated kernel boot-time messages...
      
      Suggested by Andi Kleen.
      
      Ulrich's (old) comments:
      http://www.nsa.gov/selinux/list-archive/0107/0525.cfm
      
      Certifying Linux (Linux Journal):
      http://www.linuxjournal.com/article.php?sid=0131
      
      Agreed by Tim Bird, no dissenters that I heard of:
      http://marc.theaimsgroup.com/?l=linux-kernel&m=108362954024749&w=2Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      4ffa43b8
    • Andrew Morton's avatar
      [PATCH] wdt.c warning fix · 58e03379
      Andrew Morton authored
      drivers/char/watchdog/wdt.c: In function `wdt_init':
      drivers/char/watchdog/wdt.c:638: warning: label `outrbt' defined but not used
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      58e03379
    • Andrew Morton's avatar
      [PATCH] Fix the setting of file->f_ra on block-special files · 1c211088
      Andrew Morton authored
      We need to set file->f_ra _after_ calling blkdev_open(), when inode->i_mapping
      points at the right thing.  And we need to get it from
      inode->i_mapping->host->i_mapping too, which represents the underlying device.
      
      Also, don't test for null file->f_mapping in the O_DIRECT checks.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      1c211088
    • Andrew Morton's avatar
      [PATCH] Set d_bucket correctly for anonymous dentries · 59a6ce4f
      Andrew Morton authored
      From: Neil Brown <neilb@cse.unsw.edu.au>
      
      In researching the oopses reported in bug #2761, Neil came up with:
      
      I have found one problem, but it isn't particularly new and I cannot
       see how it would be related.
      
      When d_alloc_anon creates an anonymous dentry, it is put on a special hash
      chain for anonymous dentries (sb->s_anon), but d_bucket is set to 
      
         d_hash(parent, name_hash)
      
      If, when it is eventually moved to a proper name, that hash value is the same
      as the final hash value, it will not be moved to the right bucket, and so it
      not be accessible by name.  This patch should fix it.
      
      
      
      anonymous dentries have their own private hash "bucket" (sb->s_anon) and so
      d_bucket should be set to a unique (impossible) address, else d_move will
      get confused.
      Signed-off-by: default avatarNeil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      59a6ce4f
    • Andrew Morton's avatar
      [PATCH] posix locks oops fix · ab31c400
      Andrew Morton authored
      From: Andreas Gruenbacher <agruen@suse.de>
      
      There is a race between unshare_files() and the following steal_locks().
      As a consequence, steal_locks() may steal some additional FL_POSIX locks
      that don't belong to the current thread.  This triggers a BUG in
      locks_remove_flock().
      
      In detail, the current thread shares its files struct with other threads.
      This causes unshare_files() to associate the current thread with a copy of
      its files_struct.  The copy shares all file objects with the original files
      struct.  In the time between unshare_files() and steal_locks(), another
      thread creates a new file and a FL_POSIX lock on it.  The current thread
      gets into steal_locks() and takes over all FL_POSIX locks that refer to the
      previous files_struct, including the new lock.  We do
      put_files_struct(original files_struct).  This causes the file handle to
      the new file to be closed.  We get into locks_remove_posix() and miss the
      lock, because its fl_owner field now refers to the new files_struct. 
      Finally we get into locks_remove_flock(), and stumble upon the lock.
      
      While looking into this bug report I gathered the following data with a
      SUSE kernel (oops and LKCD dump from Chris):
      
      kernel BUG at fs/locks.c:1736!
      invalid operand: 0000 [#1]
      SMP
      CPU:    0
      EIP:    0060:[<c01844fb>]    Tainted: G  U
      EFLAGS: 00010246   (2.6.5-0-testing)
      EIP is at locks_remove_flock+0x8b/0x130
      eax: f7b89998   ebx: f61df3fc   ecx: f61df354   edx: 00000000
      esi: f61df354   edi: f6702b80   ebp: f6179c24   esp: f6179c08
      ds: 007b   es: 007b   ss: 0068
      Process owcimomd (pid: 1713, threadinfo=f6178000 task=f66d0d60)
      Stack: c1e1fdac c1e1fdac f7fe83c0 00000296 f6702b80 f7fe87c0 f61df354 f6179c3c
             c016ce00 f61ddadc f6702b80 00000000 f6703b00 f6179c54 c0168b1f c0000000
             0000026f 00000012 f6703b00 f6179c6c c0124ba7 00000001 f6179e5c f6179d88
      Call Trace:
       [<c016ce00>] __fput+0x30/0x120
       [<c0168b1f>] filp_close+0x4f/0x90
       [<c0124ba7>] put_files_struct+0x67/0xc0
       [<c019d285>] load_elf_binary+0x3f5/0x1596
       [<c018a5af>] update_atime+0x9f/0xc0
       [<c01478fd>] __generic_file_aio_read+0x1cd/0x200
       [<c0145060>] file_read_actor+0x0/0xd0
       [<c01784b7>] search_binary_handler+0x97/0x270
       [<c017a072>] do_execve+0x172/0x200
       [<c0105fb2>] sys_execve+0x32/0x70
       [<c0107e21>] sysenter_past_esp+0x52/0x71
      
      Code: 0f 0b c8 06 eb 74 35 c0 eb db b8 00 e0 ff ff 21 e0 8b 10 8b
      
      put_files_struct+0x67 is equivalent to fs/binfmt_elf.c:681 in 2.6.6
      
      current->files == fl->fl_owner
      fl->fl_file = 0xf6702b80 (a valid struct file)
      
      current->files =
        max_fds=32
        max_fdset=1024
        next_fd=3
        fd=[0xf6927080 0xf6951b80  0xf6951b80 0 ...]
      
      Here's a proposed fix.  As a side effect, steal_locks no longer walks the
      global list of locks, but only the locks of all open inodes.
      
      What are the reasons (other than historic ones) for not getting rid of
      fl_owner and using fl_pid instead, by the way?  I think that would clean up
      the whole mess with file locks a bit.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      ab31c400
    • Andrew Morton's avatar
      [PATCH] ppc32: fix 'make O=...' · df6d6035
      Andrew Morton authored
      From: Tom Rini <trini@kernel.crashing.org>
      
      Fix arch/ppc/boot/ so that everything now works with 'make O='.
      
      Partially by: Geoffrey LEVAND <geoffrey.levand@am.sony.com>.
      Signed-off-by: default avatarTom Rini <trini@kernel.crashing.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      df6d6035
    • Andrew Morton's avatar
      [PATCH] ppc64 kernel hackers can't spell · 8634c9f3
      Andrew Morton authored
      From: Anton Blanchard <anton@samba.org>
      
      From: Dave Hansen
      
      This patch is obviously of the utmost importance.  It probably doesn't matter
      as much for kernel error messages, but one of these mistakes is in a
      user-readable /proc file.  
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarDave Hansen <haveblue@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      8634c9f3
  2. 26 May, 2004 7 commits
  3. 25 May, 2004 15 commits