1. 08 3月, 2008 5 次提交
    • B
      ide-cd: mark REQ_TYPE_ATA_PC write requests with REQ_RW flag · b348487f
      Bartlomiej Zolnierkiewicz 提交于
      On Thursday 06 March 2008, walt wrote:
      
      > For me, this commit causes the problem it's intended to fix:
      > 
      > commit 9f10d9ee
      > Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      > Date:   Tue Feb 26 21:50:35 2008 +0100
      > 
      >      ide-cd: fix 'ireason' handling for REQ_TYPE_ATA_PC requests
      > 
      >      This fixes some hangs caused by not finishing the transfer before ending
      >      the request and also makes use of 'ireason == 1' quirk for spurious IRQs.
      > 
      > When I mount a CD there is a long delay, and I see this error message:
      > 
      > hdc: ide_cd_check_ireason: wrong transfer direction!
      > cdrom: failed setting lba address space
      > hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
      > ide: failed opcode was: unknown
      > hdc: drive not ready for command
      > <repeated many times>
      > 
      > When I revert this commit everything works properly again, including
      > CD burning.
      
      It turned out that REQ_TYPE_ATA_PC write requests were not marked as such
      (the previous commit assumed them to be).
      Reported-by: Nwalt <w41ter@gmail.com>
      Tested-by: Nwalt <w41ter@gmail.com>
      Reviewed-by: NBorislav Petkov <petkovbb@googlemail.com>
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      b348487f
    • T
      gigaset: fix Oops on module unload regression · 5d49c101
      Tilman Schmidt 提交于
      The card state mutex was only initialized when a device was connected,
      but used during unload unconditionally, leading to an Oops if a driver
      was loaded and unloaded again without ever connecting a device.
      
      Fix this by initializing the mutex as soon as the structure is allocated.
      Also add a missing mutex unlock revealed in the same execution path.
      
      This fixes a possible Oops in 2.6.25-rc that was introduced by commit
      e468c048 ("Gigaset: permit module
      unload").
      
      Thanks to Roland Kletzing for reporting this problem.
      Signed-off-by: NTilman Schmidt <tilman@imap.cc>
      Tested-by: NRoland Kletzing <devzero@web.de>
      Cc: Hansjoerg Lipp <hjlipp@web.de>
      Cc: Karsten Keil <kkeil@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5d49c101
    • L
      Merge branch 'for-linus' of... · 1d6789c3
      Linus Torvalds 提交于
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel:
        sched: don't allow rt_runtime_us to be zero for groups having rt tasks
        sched: rt-group: fixup schedulability constraints calculation
        sched: fix the wrong time slice value for SCHED_FIFO tasks
        sched: export task_nice
        sched: balance RT task resched only on runqueue
        sched: retain vruntime
      1d6789c3
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86 · 0a9e0703
      Linus Torvalds 提交于
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86:
        x86-boot: don't request VBE2 information
        x86: re-add reboot fixups
        x86: fix typo in step.c
        x86: fix merge mistake in i387.c
        x86: clear DF before calling signal handler
      0a9e0703
    • I
      drivers/char/esp.c: fix bootup lockup · 80d38f9a
      Ingo Molnar 提交于
      randconfig testing found a bootup lockup in drivers/char/esp.c because
      of a spinlock that wasn't correctly initialized.
      
      I'm not sure why it became more prominent in 2.6.25-rc4, the bug seems
      rather old and i've been doing allyesconfig bootups for ages with
      CONFIG_ESP enabled.
      
      This fixes this bootup lockup:
      
       PM: Adding info for No Bus:ttyP63
       ttyP32 at 0x0240 (irq = 0) is an ESP primary port
       BUG: spinlock lockup on CPU#0, swapper/1, f56dd004
       Pid: 1, comm: swapper Not tainted 2.6.25-rc4-sched-devel.git-x86-latest.git #402 [<c03ac6f4>] _raw_spin_lock+0x134/0x140
        [<c08649be>] _spin_lock_irqsave+0x5e/0x80
        [<c0b9fbfe>] ? espserial_init+0x2be/0x6e0
        [<c0b9fbfe>] espserial_init+0x2be/0x6e0
        [<c0b877a3>] kernel_init+0x83/0x260
        [<c0b9f940>] ? espserial_init+0x0/0x6e0
        [<c010416a>] ? restore_nocheck_notrace+0x0/0xe
        [<c0b87720>] ? kernel_init+0x0/0x260
        [<c0b87720>] ? kernel_init+0x0/0x260
        [<c0104507>] kernel_thread_helper+0x7/0x10
        =======================
      
      kzalloc() is not the way to initialize spinlocks anymore.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      80d38f9a
  2. 07 3月, 2008 23 次提交
  3. 06 3月, 2008 12 次提交