1. 19 Apr, 2011 1 commit
  2. 14 Apr, 2011 3 commits
  3. 12 Apr, 2011 8 commits
  4. 11 Apr, 2011 1 commit
    • Dave Airlie's avatar
      Merge remote branch 'nouveau/drm-nouveau-fixes' of /ssd/git/drm-nouveau-next into drm-fixes · d85023a3
      Dave Airlie authored
      * 'nouveau/drm-nouveau-fixes' of /ssd/git/drm-nouveau-next:
        drm/nvc0: improve vm flush function
        drm/nv50-nvc0: remove some code that doesn't belong here
        drm/nv50: use "nv86" tlb flush method on everything except 0x50/0xac
        drm/nouveau: quirk for XFX GT-240X-YA
        drm/nv50-nvc0: work around an evo channel hang that some people see
        drm/nouveau: implement init table opcode 0x5c
        drm/nouveau: fix oops on unload with disabled LVDS panel
        nv30: Fix parsing of perf table
        drm/nouveau: correct memtiming table parsing for nv4x
      d85023a3
  5. 09 Apr, 2011 5 commits
  6. 08 Apr, 2011 4 commits
  7. 07 Apr, 2011 16 commits
  8. 06 Apr, 2011 2 commits
    • Hans Rosenfeld's avatar
      x86-32, fpu: Fix FPU exception handling on non-SSE systems · f994d99c
      Hans Rosenfeld authored
      On 32bit systems without SSE (that is, they use FSAVE/FRSTOR for FPU
      context switches), FPU exceptions in user mode cause Oopses, BUGs,
      recursive faults and other nasty things:
      
      fpu exception: 0000 [#1]
      last sysfs file: /sys/power/state
      Modules linked in: psmouse evdev pcspkr serio_raw [last unloaded: scsi_wait_scan]
      
      Pid: 1638, comm: fxsave-32-excep Not tainted 2.6.35-07798-g58a992b9-dirty #633 VP3-596B-DD/VT82C597
      EIP: 0060:[<c1003527>] EFLAGS: 00010202 CPU: 0
      EIP is at math_error+0x1b4/0x1c8
      EAX: 00000003 EBX: cf9be7e0 ECX: 00000000 EDX: cf9c5c00
      ESI: cf9d9fb4 EDI: c1372db3 EBP: 00000010 ESP: cf9d9f1c
      DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068
      Process fxsave-32-excep (pid: 1638, ti=cf9d8000 task=cf9be7e0 task.ti=cf9d8000)
      Stack:
      00000000 00000301 00000004 00000000 00000000 cf9d3000 cf9da8f0 00000001
      <0> 00000004 cf9b6b60 c1019a6b c1019a79 00000020 00000242 000001b6 cf9c5380
      <0> cf806b40 cf791880 00000000 00000282 00000282 c108a213 00000020 cf9c5380
      Call Trace:
      [<c1019a6b>] ? need_resched+0x11/0x1a
      [<c1019a79>] ? should_resched+0x5/0x1f
      [<c108a213>] ? do_sys_open+0xbd/0xc7
      [<c108a213>] ? do_sys_open+0xbd/0xc7
      [<c100353b>] ? do_coprocessor_error+0x0/0x11
      [<c12d5965>] ? error_code+0x65/0x70
      Code: a8 20 74 30 c7 44 24 0c 06 00 03 00 8d 54 24 04 89 d9 b8 08 00 00 00 e8 9b 6d 02 00 eb 16 8b 93 5c 02 00 00 eb 05 e9 04 ff ff ff <9b> dd 32 9b e9 16 ff ff ff 81 c4 84 00 00 00 5b 5e 5f 5d c3 c6
      EIP: [<c1003527>] math_error+0x1b4/0x1c8 SS:ESP 0068:cf9d9f1c
      
      This usually continues in slight variations until the system is reset.
      
      This bug was introduced by commit 58a992b9:
      	x86-32, fpu: Rewrite fpu_save_init()
      Signed-off-by: default avatarHans Rosenfeld <hans.rosenfeld@amd.com>
      Link: http://lkml.kernel.org/r/1302106003-366952-1-git-send-email-hans.rosenfeld@amd.comSigned-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      f994d99c
    • Arjan Mels's avatar
      staging: usbip: bugfix for isochronous packets and optimization · 28276a28
      Arjan Mels authored
      For isochronous packets the actual_length is the sum of the actual
      length of each of the packets, however between the packets might be
      padding, so it is not sufficient to just send the first actual_length
      bytes of the buffer. To fix this and simultanesouly optimize the
      bandwidth the content of the isochronous packets are send without the
      padding, the padding is restored on the receiving end.
      Signed-off-by: default avatarArjan Mels <arjan.mels@gmx.net>
      Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net>
      Cc: Max Vozeler <max@vozeler.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      28276a28