1. 04 6月, 2008 1 次提交
  2. 03 6月, 2008 2 次提交
  3. 31 5月, 2008 14 次提交
  4. 30 5月, 2008 23 次提交
    • H
      acpi: fix sparse const errors · e3aa51fe
      Harvey Harrison 提交于
      In this case we want a constant pointer to constant chars:
      
      drivers/misc/thinkpad_acpi.c:3824:19: error: Just how const do you want this type to be?
      
      Like the error says.
      
      drivers/misc/thinkpad_acpi.c:3863:19: error: Just how const do you want this type to be?
      drivers/misc/thinkpad_acpi.c:3864:19: error: Just how const do you want this type to be?
      drivers/misc/thinkpad_acpi.c:3865:19: error: Just how const do you want this type to be?
      drivers/misc/thinkpad_acpi.c:3866:19: error: Just how const do you want this type to be?
      Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
      Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e3aa51fe
    • D
      Input: gtco - fix double kfree in error handling path · 501a5250
      Dmitry Torokhov 提交于
      The code would try to free 'report' twice upon input_register_device()
      failure.
      Reported-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      501a5250
    • M
      [S390] tape: fix race with stack local wait_queue_head_t. · 4657fb8a
      Martin Schwidefsky 提交于
      A wait_event call with a stack local wait_queue_head_t structure that is
      used to do the wake up for the wait_event is inherently racy. After the
      wait_event finished the wake_up call might not have completed yet.
      Replace the stack local wait_queue_head_t in tape_do_io and
      tape_do_io_interruptible with a per device wait queue.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      4657fb8a
    • M
      [S390] 3270: fix race with stack local wait_queue_head_t. · 54ad6412
      Martin Schwidefsky 提交于
      A wait_event call with a stack local wait_queue_head_t structure that is
      used to do the wake up for the wait_event is inherently racy. After the
      wait_event finished the wake_up call might not have completed yet.
      Remove the stack local wait_queue_head_t from raw3270_start_init and
      use the global raw3270_wait_queue instead.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      54ad6412
    • S
      [S390] dasd: use a generic wait_queue for sleep_on · c80ee724
      Stefan Haberland 提交于
      Use a generic wait_queue to prevent the wait_queue in dasd_sleep_on_
      functions from being referenced by callback_data while it does not
      exist any more.
      Signed-off-by: NStefan Haberland  <stefan.haberland@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      c80ee724
    • H
      [S390] sclp_vt220: fix scheduling while atomic bug. · d4820e44
      Heiko Carstens 提交于
      The driver incorrectly assumed that putchar will only be called from
      schedulable process context and therefore blocked and waited if no
      free output buffers where available.
      Since putchar may also be called from BH context this may lead to
      deadlocks.
      To fix this just return the number of characters accepted and let the
      upper layer handle the rest.
      
      The console write function will busy wait (sclp_sync_wait) until a
      buffer is available again.
      
      Cc: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      d4820e44
    • H
      [S390] Fix section mismatch warnings. · 67060d9c
      Heiko Carstens 提交于
      This fixes the last remaining section mismatch warnings in s390
      architecture code. It reveals also a real bug introduced by... me
      with git commit 2069e978
      ("[S390] sparsemem vmemmap: initialize memmap.")
      
      Calling the generic vmemmap_alloc_block() function to get initialized
      memory is a nice idea, however that function is __meminit annotated
      and therefore the function might be gone if we try to call it later.
      This can happen if a DCSS segment gets added.
      
      So basically revert the patch and clear the memmap explicitly to fix
      the original bug.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      67060d9c
    • M
      [S390] tape: Fix race condition in tape block device driver · f71ad62a
      Michael Holzheu 提交于
      Due to incorrect function call sequence it can happen that a tape block
      request is finished before the request is taken from the block request queue.
      
      The following sequence leads to that condition:
       * tapeblock_start_request() -> start CCW program
       * Request finishes -> IO interrupt
       * tapeblock_end_request()
       * end_that_request_last()
      
      If blkdev_dequeue_request() has not been called before end_that_request_last(),
      a kernel bug is triggered in end_that_request_last() because the request is
      still queued. To solve that problem blkdev_dequeue_request() has to be called
      before starting the CCW program.
      Signed-off-by: NMichael Holzheu <holzheu@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      f71ad62a
    • R
      virtio: force callback on empty. · b4f68be6
      Rusty Russell 提交于
      virtio allows drivers to suppress callbacks (ie. interrupts) for
      efficiency (no locking, it's just an optimization).
      
      There's a similar mechanism for the host to suppress notifications
      coming from the guest: in that case, we ignore the suppression if the
      ring is completely full.
      
      It turns out that life is simpler if the host similarly ignores
      callback suppression when the ring is completely empty: the network
      driver wants to free up old packets in a timely manner, and otherwise
      has to use a timer to poll.
      
      We have to remove the code which ignores interrupts when the driver
      has disabled them (again, it had no locking and hence was unreliable
      anyway).
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      b4f68be6
    • C
      virtio_net: another race with virtio_net and enable_cb · 52a3a05f
      Christian Borntraeger 提交于
      Hello Rusty,
      
      seems that we still have a problem with virtio_net and the enable_cb callback.
      During a long running network stress tests with virtio and got the following
      oops:
      
      ------------[ cut here ]------------
      kernel BUG at drivers/virtio/virtio_ring.c:230!
      illegal operation: 0001 [#1] SMP
      Modules linked in:
      CPU: 0 Not tainted 2.6.26-rc2-kvm-00436-gc94c08b-dirty #34
      Process netserver (pid: 2582, task: 000000000fbc4c68, ksp: 000000000f42b990)
      Krnl PSW : 0704c00180000000 00000000002d0ec8 (vring_enable_cb+0x1c/0x60)
                 R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
      Krnl GPRS: 0000000000000000 0000000000000000 000000000ef3d000 0000000010009800
                 0000000000000000 0000000000419ce0 0000000000000080 000000000000007b
                 000000000adb5538 000000000ef40900 000000000ef40000 000000000ef40920
                 0000000000000000 0000000000000005 000000000029c1b0 000000000fea7d18
      Krnl Code: 00000000002d0ebc: a7110001           tmll    %r1,1
                 00000000002d0ec0: a7740004           brc     7,2d0ec8
                 00000000002d0ec4: a7f40001           brc     15,2d0ec6
                >00000000002d0ec8: a517fffe           nill    %r1,65534
                 00000000002d0ecc: 40103000           sth     %r1,0(%r3)
                 00000000002d0ed0: 07f0               bcr     15,%r0
                 00000000002d0ed2: e31020380004       lg      %r1,56(%r2)
                 00000000002d0ed8: a7480000           lhi     %r4,0
      Call Trace:
      ([<000000000029c0fc>] virtnet_poll+0x290/0x3b8)
       [<0000000000333fb8>] net_rx_action+0x9c/0x1b8
       [<00000000001394bc>] __do_softirq+0x74/0x108
       [<000000000010d16a>] do_softirq+0x92/0xac
       [<0000000000139826>] irq_exit+0x72/0xc8
       [<000000000010a7b6>] do_extint+0xe2/0x104
       [<0000000000110508>] ext_no_vtime+0x16/0x1a
      Last Breaking-Event-Address:
       [<00000000002d0ec4>] vring_enable_cb+0x18/0x60
      
      I looked into the virtio_net code for some time and I think the following
      scenario happened. Please look at virtnet_poll:
      [...]
              /* Out of packets? */
              if (received < budget) {
                      netif_rx_complete(vi->dev, napi);
                      if (unlikely(!vi->rvq->vq_ops->enable_cb(vi->rvq))
                          && napi_schedule_prep(napi)) {
                              vi->rvq->vq_ops->disable_cb(vi->rvq);
                              __netif_rx_schedule(vi->dev, napi);
                              goto again;
                      }
              }
      
      If an interrupt arrives after netif_rx_complete, a second poll routine can run
      on a different cpu. The second check for napi_schedule_prep would prevent any
      harm in the network stack, but we have called enable_cb possibly after the
      disable_cb in skb_recv_done.
      
      static void skb_recv_done(struct virtqueue *rvq)
      {
              struct virtnet_info *vi = rvq->vdev->priv;
              /* Schedule NAPI, Suppress further interrupts if successful. */
              if (netif_rx_schedule_prep(vi->dev, &vi->napi)) {
                      rvq->vq_ops->disable_cb(rvq);
                      __netif_rx_schedule(vi->dev, &vi->napi);
              }
      }
      
      That means that the second poll routine runs with interrupts enabled, which is
      ok, since we can handle additional interrupts. The problem is now that the
      second poll routine might also call enable_cb, triggering the BUG.
      
      The only solution I can come up with, is to remove the BUG statement in
      enable_cb - similar to disable_cb. Opinions or better ideas where the oops
      could come from?
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      52a3a05f
    • R
      virtio: An entropy device, as suggested by hpa. · f7f510ec
      Rusty Russell 提交于
      Note that by itself, having a "hardware" random generator does very
      little: you should probably run "rngd" in your guest to feed this into
      the kernel entropy pool.
      
      Included:
      	virtio_rng: dont use vmalloced addresses for virtio
      
      	If virtio_rng is build as a module, random_data is an address
      	in vmalloc space. As virtio expects guest real addresses, this
      	can cause any kind of funny behaviour, so lets allocate
      	random_data dynamically with kmalloc.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      f7f510ec
    • C
      virtio_blk: allow read-only disks · 3ef53609
      Christian Borntraeger 提交于
      Hello Rusty,
      
      sometimes it is useful to share a disk (e.g. usr). To avoid file system
      corruption, the disk should be mounted read-only in that case. This patch
      adds a new feature flag, that allows the host to specify, if the disk should
      be considered read-only.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      3ef53609
    • R
      virtio: set device index in common code. · b769f579
      Rusty Russell 提交于
      Anthony Liguori points out that three different transports use the virtio code,
      but each one keeps its own counter to set the virtio_device's index field.  In
      theory (though not in current practice) this means that names could be
      duplicated, and that risk grows as more transports are created.
      
      So we move the selection of the unique virtio_device.index into the common code
      in virtio.c, which has the side-benefit of removing duplicate code.
      
      The only complexity is that lguest and S/390 use the index to uniquely identify
      the device in case of catastrophic failure before register_virtio_device() is
      called: now we use the offset within the descriptor page as a unique identifier
      for the printks.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chris Lalancette <clalance@redhat.com>
      Cc: Anthony Liguori <anthony@codemonkey.ws>
      b769f579
    • R
      virtio: virtio_pci should not set bus_id. · 5610bd15
      Rusty Russell 提交于
      The common virtio code sets the bus_id, overriding anything virtio_pci
      sets anyway.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chris Lalancette <clalance@redhat.com>
      Cc: Anthony Liguori <anthony@codemonkey.ws>
      5610bd15
    • R
      virtio: bus_id for devices should contain 'virtio' · 2ad3cfba
      Rusty Russell 提交于
      Chris Lalancette <clalance@redhat.com> points out that virtio.c sets all device
      names to '0', '1', etc, which looks silly in /proc/interrupts.  We change this
      from '%d' to 'virtio%d'.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chris Lalancette <clalance@redhat.com>
      Cc: Anthony Liguori <anthony@codemonkey.ws>
      2ad3cfba
    • C
      Fix crash in virtio_blk during modprobe ; rmmod ; modprobe · ac9d463a
      Chris Lalancette 提交于
      Fix a modprobe virtio_blk ; rmmod virtio_blk ; modprobe virtio_blk crash; this
      was basically because we weren't doing "del_gendisk()" in the remove path.
      Signed-off-by: NChris Lalancette <clalance@redhat.com>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (moved del_gendisk up)
      ac9d463a
    • R
      lguest: use ioremap_cache, not ioremap · e27810f1
      Rusty Russell 提交于
      Thanks to Jon Corbet & LWN.  Only took me a day to join the dots.
      
      Host->Guest netcat before (with unnecessily large receive buffers):
      1073741824 bytes (1.1 GB) copied, 24.7528 seconds, 43.4 MB/s
      
      After:
      1073741824 bytes (1.1 GB) copied, 17.6369 seconds, 60.9 MB/s
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      e27810f1
    • S
      driver-core: prepare for 2.6.27 api change by adding dev_set_name · 413c239f
      Stephen Rothwell 提交于
      Create the dev_set_name function now so that various subsystems can
      start changing over to it before other changes in 2.6.27 will make it
      compulsory.
      
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      413c239f
    • G
      Revert "USB: EHCI: fix performance regression" · bb7e6984
      Greg Kroah-Hartman 提交于
      This reverts commit fa38dfcc.
      
      It wasn't really a regression and David and Alan are still working
      through the issues reported.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bb7e6984
    • L
      USB: fsl_usb2_udc: fix recursive lock · 185e3dea
      Li Yang 提交于
      UDC needs to release lock before calling out to gadget driver, since
      it may need to reenter.  The change fixes kernel BUG observed on rt
      kernel.
      
      > kernel BUG at kernel/rtmutex.c:683!
      > stopped custom tracer.
      > Oops: Exception in kernel mode, sig: 5 [#1]
      > PREEMPT MPC834x ITX
      > NIP: c021629c LR: c0216270 CTR: 00000000
      > REGS: df761d70 TRAP: 0700   Not tainted  (2.6.23.9-rt13)
      > MSR: 00021032 <ME,IR,DR>  CR: 28000022  XER: 00000000
      > TASK = df632080[241] 'IRQ-38' THREAD: df760000
      > GPR00: 00000001 df761e20 df632080 00000000 11111111 00000000 df761e6c
      > 00000000
      > GPR08: df761e48 00000000 df761e50 00000000 80000000 ede5cdde 1fffd000
      > 00800000
      > GPR16: ffffffff 00000000 007fff00 00000040 00000000 007ffeb0 00000000
      > 1fff8b08
      > GPR24: 00000000 00000026 00000000 df79a320 c026b2e8 c02240bc 00009032
      > df79a320
      > NIP [c021629c] rt_spin_lock_slowlock+0x9c/0x200
      > LR [c0216270] rt_spin_lock_slowlock+0x70/0x200
      > Call Trace:
      > [df761e20] [c0216270] rt_spin_lock_slowlock+0x70/0x200 (unreliable)
      > [df761e90] [c0182828] fsl_ep_disable+0xcc/0x154
      > [df761eb0] [c0184d30] eth_reset_config+0x88/0x1d0
      > [df761ed0] [c0184ec0] eth_disconnect+0x48/0x64
      > [df761ef0] [c01831a4] reset_queues+0x60/0x78
      > [df761f00] [c0183b74] fsl_udc_irq+0x9b8/0xa58
      > [df761f50] [c003ef30] handle_IRQ_event+0x64/0x100
      > [df761f80] [c003f758] thread_simple_irq+0x6c/0xc8
      > [df761fa0] [c003f888] do_irqd+0xd4/0x2e4
      > [df761fd0] [c0032284] kthread+0x50/0x8c
      > [df761ff0] [c000f9b4] kernel_thread+0x44/0x60
      Signed-off-by: NLi Yang <leoli@freescale.com>
      Cc: Eugene T. Bordenkircher <Eugene_Bordenkircher@selinc.com>
      Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      185e3dea
    • M
      USB: usb-serial: option: Don't match Huawei driver CD images · a7f3872c
      Michael Karcher 提交于
      Add the interface info matching to all Huawei cards, as they all also
      contain a Mass Storage Device interface (usually containing Windows
      drivers) which should not get bound by this driver.
      
      See also drivers/usb/storage/unusual_devs.h
      Signed-off-by: NMichael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a7f3872c
    • S
      USB: pl2303: another product ID · 4be2fa18
      Steve Murphy 提交于
      I've just got a USB GPRS/EDGE modem branded Manufacturer Micromax Model
      MMX610U (see http://www.airtel.in/level2_t3data.aspx?path=1/106/179)
      working by adding another product ID to pl2303.  Modem info reports same
      module as  Max Arnold's i.e.SIMCOM SIM600  but  with product ID 0x0612
      (cf Ox0611).
      
      From: Steve Murphy <steve@gnusis.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4be2fa18
    • R
      USB: add another scanner quirk · 598eff6d
      René Rebe 提交于
      Like the HP53{00,70} scanner other devices of the OEM Avision require
      the USB_QUIRK_STRING_FETCH_255 to correct set a configuration with
      "recent" Linux kernels.
      Signed-off-by: NRené Rebe <rene@exactcode.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      598eff6d
新手
引导
客服 返回
顶部