1. 20 11月, 2009 2 次提交
  2. 19 11月, 2009 1 次提交
  3. 18 11月, 2009 4 次提交
  4. 17 11月, 2009 2 次提交
  5. 14 11月, 2009 3 次提交
  6. 13 11月, 2009 2 次提交
  7. 10 11月, 2009 3 次提交
  8. 08 11月, 2009 4 次提交
  9. 07 11月, 2009 3 次提交
    • T
      ALSA: hda - Don't initialize CORB/RIRB for single_cmd mode · 1a696978
      Takashi Iwai 提交于
      So far, CORB/RIRB still remains even if the driver is switched to the
      single_cmd mode.  The specification says that this should be disabled,
      but I hoped this isn't the case; indeed most devices worked together with
      CORB/RIRB.
      
      However, Poulsbo (US15W) seems problematic with this setup, and it
      requires to disable CORB/RIRB when single_cmd is used.
      
      Now this patch disables CORB/RIRB initialization when the single_cmd
      mode is used.  Also the unsolicited event is disabled because it can't
      work without RIRB.
      Reported-and-tested-by: NTroy Kisky <troy.kisky@boundarydevices.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      1a696978
    • J
      ALSA: usb-audio: fix combine_word problem · f4950882
      Julian Anastasov 提交于
      Fix combine_word problem where first octet is not
      read properly. The only affected place seems to be the
      INPUT_TERMINAL type. Before now, sound controls can be created
      with the output terminal's name which is a fallback mechanism
      used only for unknown input terminal types. For example,
      Line can wrongly appear as Speaker. After the change it
      should appear as Line.
      
      	The side effect of this change can be that users
      can expect the wrong control name in their scripts or
      programs while now we return the correct one.
      
      	Probably, these defines should use get_unaligned_le16 and
      friends.
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Cc: <stable@kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      f4950882
    • T
      sound: Replace old style lock initializer · 70edc800
      Thomas Gleixner 提交于
      SPIN_LOCK_UNLOCKED is deprecated. Use __SPIN_LOCK_UNLOCKED instead.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      70edc800
  10. 06 11月, 2009 4 次提交
  11. 05 11月, 2009 2 次提交
  12. 04 11月, 2009 8 次提交
  13. 03 11月, 2009 2 次提交
    • L
      Merge branch 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6 · 38dc6345
      Linus Torvalds 提交于
      * 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6:
        PM: Remove some debug messages producing too much noise
        PM: Fix warning on suspend errors
        PM / Hibernate: Add newline to load_image() fail path
        PM / Hibernate: Fix error handling in save_image()
        PM / Hibernate: Fix blkdev refleaks
        PM / yenta: Split resume into early and late parts (rev. 4)
      38dc6345
    • I
      Correct nr_processes() when CPUs have been unplugged · 1d510750
      Ian Campbell 提交于
      nr_processes() returns the sum of the per cpu counter process_counts for
      all online CPUs. This counter is incremented for the current CPU on
      fork() and decremented for the current CPU on exit(). Since a process
      does not necessarily fork and exit on the same CPU the process_count for
      an individual CPU can be either positive or negative and effectively has
      no meaning in isolation.
      
      Therefore calculating the sum of process_counts over only the online
      CPUs omits the processes which were started or stopped on any CPU which
      has since been unplugged. Only the sum of process_counts across all
      possible CPUs has meaning.
      
      The only caller of nr_processes() is proc_root_getattr() which
      calculates the number of links to /proc as
              stat->nlink = proc_root.nlink + nr_processes();
      
      You don't have to be all that unlucky for the nr_processes() to return a
      negative value leading to a negative number of links (or rather, an
      apparently enormous number of links). If this happens then you can get
      failures where things like "ls /proc" start to fail because they got an
      -EOVERFLOW from some stat() call.
      
      Example with some debugging inserted to show what goes on:
              # ps haux|wc -l
              nr_processes: CPU0:     90
              nr_processes: CPU1:     1030
              nr_processes: CPU2:     -900
              nr_processes: CPU3:     -136
              nr_processes: TOTAL:    84
              proc_root_getattr. nlink 12 + nr_processes() 84 = 96
              84
              # echo 0 >/sys/devices/system/cpu/cpu1/online
              # ps haux|wc -l
              nr_processes: CPU0:     85
              nr_processes: CPU2:     -901
              nr_processes: CPU3:     -137
              nr_processes: TOTAL:    -953
              proc_root_getattr. nlink 12 + nr_processes() -953 = -941
              75
              # stat /proc/
              nr_processes: CPU0:     84
              nr_processes: CPU2:     -901
              nr_processes: CPU3:     -137
              nr_processes: TOTAL:    -954
              proc_root_getattr. nlink 12 + nr_processes() -954 = -942
                File: `/proc/'
                Size: 0               Blocks: 0          IO Block: 1024   directory
              Device: 3h/3d   Inode: 1           Links: 4294966354
              Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
              Access: 2009-11-03 09:06:55.000000000 +0000
              Modify: 2009-11-03 09:06:55.000000000 +0000
              Change: 2009-11-03 09:06:55.000000000 +0000
      
      I'm not 100% convinced that the per_cpu regions remain valid for offline
      CPUs, although my testing suggests that they do. If not then I think the
      correct solution would be to aggregate the process_count for a given CPU
      into a global base value in cpu_down().
      
      This bug appears to pre-date the transition to git and it looks like it
      may even have been present in linux-2.6.0-test7-bk3 since it looks like
      the code Rusty patched in http://lwn.net/Articles/64773/ was already
      wrong.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1d510750