1. 30 1月, 2008 6 次提交
    • T
      x86: nuke a ton of dead hpet code · 02456c70
      Thomas Gleixner 提交于
      No users, just ballast
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      02456c70
    • B
      x86: assign IRQs to HPET timers, fix · 37a47db8
      Balaji Rao 提交于
      Looks like IRQ 31 is assigned to timer 3, even without the patch!
      I wonder who wrote the number 31. But the manual says that it is
      zero by default.
      
      I think we should check whether the timer has been allocated an IRQ before
      proceeding to assign one to it.  Here is a patch that does this.
      Signed-off-by: NBalaji Rao <balajirrao@gmail.com>
      Tested-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      37a47db8
    • B
      x86: assign IRQs to HPET timers · e3f37a54
      Balaji Rao 提交于
      The userspace API for the HPET (see Documentation/hpet.txt) did not work. The
      HPET_IE_ON ioctl was failing as there was no IRQ assigned to the timer
      device. This patch fixes it by allocating IRQs to timer blocks in the HPET.
      
      arch/x86/kernel/hpet.c |   13 +++++--------
      drivers/char/hpet.c    |   45 ++++++++++++++++++++++++++++++++++++++-------
      include/linux/hpet.h   |    2 +-
      3 files changed, 44 insertions(+), 16 deletions(-)
      Signed-off-by: NBalaji Rao <balajirrao@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      e3f37a54
    • L
      Mostly revert "e1000/e1000e: Move PCI-Express device IDs over to e1000e" · 5b10ca19
      Linus Torvalds 提交于
      The new e1000e driver is apparently not yet suitable for general use, so
      mark it experimental, and re-instate all the PCI-Express device IDs in
      the old and stable e1000 driver so that people (namely me) can continue
      to use a driver that actually works.
      
      Auke & co have been appraised of the situation.
      
      Cc: Auke Kok <auke-jan.h.kok@intel.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5b10ca19
    • J
      cciss: fix bug in overriding ->data_len before completion · e7d9dc9c
      Jens Axboe 提交于
      For BLOCK_PC requests, we need that length for completing the request.
      Andrew Vasquez <andrew.vasquez@qlogic.com> reported the following
      oops
      
      Hitting a consistent BUG() with recent Linus' linux-2.6.git:
      
      	[   12.941428] ------------[ cut here ]------------
      	[   12.944874] kernel BUG at drivers/block/cciss.c:1260!
      	[   12.944874] invalid opcode: 0000 [1] SMP
      	[   12.944874] CPU 0
      	[   12.944874] Modules linked in:
      	[   12.944874] Pid: 0, comm: swapper Not tainted 2.6.24 #43
      	[   12.944874] RIP: 0010:[<ffffffff8039e43d>]  [<ffffffff8039e43d>] cciss_softirq_done+0xbc/0x1bf
      	[   12.944874] RSP: 0018:ffffffff8063aed0  EFLAGS: 00010202
      	[   12.944874] RAX: 0000000000000001 RBX: ffff8100cf800010 RCX: ffff81042f1253b0
      	[   12.944874] RDX: ffff81042de398f0 RSI: ffff81042de398f0 RDI: 0000000000000001
      	[   12.944874] RBP: ffff81042daa0000 R08: ffff81042f1253b0 R09: 0000000000000001
      	[   12.944874] R10: 00000000000000fe R11: 0000000000000000 R12: 0000000000000002
      	[   12.944874] R13: 0000000000000001 R14: ffff8100cf800000 R15: ffff81042de398f0
      	[   12.944874] FS:  0000000000000000(0000) GS:ffffffff805bb000(0000) knlGS:0000000000000000
      	[   12.944874] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      	[   12.944874] CR2: 00002afed7eea340 CR3: 000000042dbba000 CR4: 00000000000006e0
      	[   12.944874] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      	[   12.944874] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      	[   12.944874] Process swapper (pid: 0, threadinfo ffffffff805f4000, task ffffffff805624a0)
      	[   12.944874] Stack:  0000000000000000 ffffffff8063af10 0000000000000001 ffffffff80632d60
      	[   12.944874]  0000000000000000 000000000000000a ffffffff805bb900 ffffffff8032038f
      	[   12.944874]  ffffffff8063af10 ffffffff8063af10 ffffffff805bb940 ffffffff802346b4
      	[   12.944874] Call Trace:
      	[   12.944874]  <IRQ>  [<ffffffff8032038f>] blk_done_softirq+0x69/0x78
      	[   12.944874]  [<ffffffff802346b4>] __do_softirq+0x6f/0xd8
      	[   12.944874]  [<ffffffff8020c45c>] call_softirq+0x1c/0x30
      	[   12.944874]  [<ffffffff8020e347>] do_softirq+0x30/0x80
      	[   12.944874]  [<ffffffff8020e409>] do_IRQ+0x72/0xd9
      	[   12.944874]  [<ffffffff8020a50a>] mwait_idle+0x0/0x46
      	[   12.944874]  [<ffffffff8020a3da>] default_idle+0x0/0x3d
      	[   12.944874]  [<ffffffff8020b7e1>] ret_from_intr+0x0/0xa
      	[   12.944874]  <EOI>  [<ffffffff8020a54c>] mwait_idle+0x42/0x46
      	[   12.944874]  [<ffffffff8020a481>] cpu_idle+0x6a/0xae
      	[   12.944874]
      	[   12.944874]
      	[   12.944874] Code: 0f 0b eb fe 48 8d 85 d8 c0 00 00 48 89 04 24 48 89 c7 e8 e5
      	[   12.944874] RIP  [<ffffffff8039e43d>] cciss_softirq_done+0xbc/0x1bf
      	[   12.944874]  RSP <ffffffff8063aed0>
      	[   12.944903] ---[ end trace e9c631603f90d22f ]---
      
      which is caused by blk_end_request() returning 'not done' for a request,
      since it gets asked to complete zero bytes.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      e7d9dc9c
    • J
      xsysace: end request handling fix · 9bf72259
      Jens Axboe 提交于
      In ace_fsm_dostate(), the variable 'i' was used only for passing
      sector size of the request to end_that_request_first().
      So I removed it and changed the code to pass the size in bytes
      directly to __blk_end_request()
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      9bf72259
  2. 29 1月, 2008 34 次提交