linux-stable.git/drivers/block, branch linux-2.6.30.y Linux kernel stable tree virtio_blk: don't bounce highmem requests 2009-09-24T15:27:28+00:00 Christoph Hellwig hch@lst.de 2009-09-11T22:49:19+00:00 98d53d73e1a28f0f55de4141ef91799aba0507b6 commit 4eff3cae9c9809720c636e64bc72f212258e0bd5 upstream virtio_blk: don't bounce highmem requests By default a block driver bounces highmem requests, but virtio-blk is perfectly fine with any request that fit into it's 64 bit addressing scheme, mapped in the kernel virtual space or not. Besides improving performance on highmem systems this also makes the reproducible oops in __bounce_end_io go away (but hiding the real cause). Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 4eff3cae9c9809720c636e64bc72f212258e0bd5 upstream

virtio_blk: don't bounce highmem requests

By default a block driver bounces highmem requests, but virtio-blk is
perfectly fine with any request that fit into it's 64 bit addressing scheme,
mapped in the kernel virtual space or not.

Besides improving performance on highmem systems this also makes the
reproducible oops in __bounce_end_io go away (but hiding the real cause).

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
floppy: fix lock imbalance 2009-07-20T03:38:54+00:00 Jiri Slaby jirislaby@gmail.com 2009-06-30T18:41:44+00:00 adb49b219d3199a39f5894431012b3c2e3bedee0 commit 8516a500029890a72622d245f8ed32c4e30969b7 upstream. A crappy macro prevents us unlocking on a fail path. Expand the macro and unlock appropriatelly. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 8516a500029890a72622d245f8ed32c4e30969b7 upstream.

A crappy macro prevents us unlocking on a fail path.

Expand the macro and unlock appropriatelly.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
xen/blkfront: fix warning when deleting gendisk on unplug/shutdown 2009-05-19T06:27:42+00:00 Ian Campbell ian.campbell@citrix.com 2009-05-19T06:27:42+00:00 31a14400e8f365e5d4d1a0b2a1ef4d5405d6091e Currently blkfront gives a warning when hot unplugging due to calling del_gendisk() with interrupts disabled (due to blkif_io_lock). WARNING: at kernel/softirq.c:124 local_bh_enable+0x36/0x84() Modules linked in: xenfs xen_netfront ext3 jbd mbcache xen_blkfront Pid: 13, comm: xenwatch Not tainted 2.6.29-xs5.5.0.13 #3 Call Trace: [<c012611c>] warn_slowpath+0x80/0xb6 [<c0104cf1>] xen_sched_clock+0x16/0x63 [<c0104710>] xen_force_evtchn_callback+0xc/0x10 [<c0104e32>] check_events+0x8/0xe [<c0104d9b>] xen_restore_fl_direct_end+0x0/0x1 [<c0103749>] xen_mc_flush+0x10a/0x13f [<c0105bd2>] __switch_to+0x114/0x14e [<c011d92b>] dequeue_task+0x62/0x70 [<c0123b6f>] finish_task_switch+0x2b/0x84 [<c0299877>] schedule+0x66d/0x6e7 [<c0104710>] xen_force_evtchn_callback+0xc/0x10 [<c0104710>] xen_force_evtchn_callback+0xc/0x10 [<c012a642>] local_bh_enable+0x36/0x84 [<c022f9a7>] sk_filter+0x57/0x5c [<c0233dae>] netlink_broadcast+0x1d5/0x315 [<c01c6371>] kobject_uevent_env+0x28d/0x331 [<c01e7ead>] device_del+0x10f/0x120 [<c01e7ec6>] device_unregister+0x8/0x10 [<c015f86d>] bdi_unregister+0x2d/0x39 [<c01bf6f4>] unlink_gendisk+0x23/0x3e [<c01ac946>] del_gendisk+0x7b/0xe7 [<d0828c19>] blkfront_closing+0x28/0x6e [xen_blkfront] [<d082900c>] backend_changed+0x3ad/0x41d [xen_blkfront] We can fix this by calling del_gendisk() later in blkfront_closing, after releasing blkif_io_lock. Since the queue is stopped during the interrupts disabled phase I don't think there is any danger of an event occuring between releasing the blkif_io_lock and deleting the disk. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: Jens Axboe <jens.axboe@oracle.com> 
Currently blkfront gives a warning when hot unplugging due to calling
del_gendisk() with interrupts disabled (due to blkif_io_lock).

WARNING: at kernel/softirq.c:124 local_bh_enable+0x36/0x84()
Modules linked in: xenfs xen_netfront ext3 jbd mbcache xen_blkfront
Pid: 13, comm: xenwatch Not tainted 2.6.29-xs5.5.0.13 #3
Call Trace:
 [<c012611c>] warn_slowpath+0x80/0xb6
 [<c0104cf1>] xen_sched_clock+0x16/0x63
 [<c0104710>] xen_force_evtchn_callback+0xc/0x10
 [<c0104e32>] check_events+0x8/0xe
 [<c0104d9b>] xen_restore_fl_direct_end+0x0/0x1
 [<c0103749>] xen_mc_flush+0x10a/0x13f
 [<c0105bd2>] __switch_to+0x114/0x14e
 [<c011d92b>] dequeue_task+0x62/0x70
 [<c0123b6f>] finish_task_switch+0x2b/0x84
 [<c0299877>] schedule+0x66d/0x6e7
 [<c0104710>] xen_force_evtchn_callback+0xc/0x10
 [<c0104710>] xen_force_evtchn_callback+0xc/0x10
 [<c012a642>] local_bh_enable+0x36/0x84
 [<c022f9a7>] sk_filter+0x57/0x5c
 [<c0233dae>] netlink_broadcast+0x1d5/0x315
 [<c01c6371>] kobject_uevent_env+0x28d/0x331
 [<c01e7ead>] device_del+0x10f/0x120
 [<c01e7ec6>] device_unregister+0x8/0x10
 [<c015f86d>] bdi_unregister+0x2d/0x39
 [<c01bf6f4>] unlink_gendisk+0x23/0x3e
 [<c01ac946>] del_gendisk+0x7b/0xe7
 [<d0828c19>] blkfront_closing+0x28/0x6e [xen_blkfront]
 [<d082900c>] backend_changed+0x3ad/0x41d [xen_blkfront]

We can fix this by calling del_gendisk() later in blkfront_closing, after
releasing blkif_io_lock. Since the queue is stopped during the interrupts
disabled phase I don't think there is any danger of an event occuring between
releasing the blkif_io_lock and deleting the disk.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
xen/blkfront: allow xenbus state transition to Closing->Closed when not Connected 2009-05-19T06:25:48+00:00 Ian Campbell ian.campbell@citrix.com 2009-05-19T06:25:48+00:00 28afea5b2ffaa48f4f43d22ae8edcc384c05df80 This situation can occur when attempting to attach a block device whose backend is an empty physical CD-ROM driver. The backend in this case will go directly from the Initialising state to Closing->Closed. Previously this would result in a NULL pointer deref on info->gd (xenbus_dev_fatal does not return as a1a15ac5 seems to expect) Cc: stable@kernel.org Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Jens Axboe <jens.axboe@oracle.com> 
This situation can occur when attempting to attach a block device whose
backend is an empty physical CD-ROM driver. The backend in this case
will go directly from the Initialising state to Closing->Closed.
Previously this would result in a NULL pointer deref on info->gd
(xenbus_dev_fatal does not return as a1a15ac5 seems to expect)

Cc: stable@kernel.org
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
hd: fix locking 2009-04-28T18:24:20+00:00 Tejun Heo tj@kernel.org 2009-04-28T03:38:33+00:00 0191944282e84931f92915b5f06b348a92dac7e1 hd dance around local irq and HD_IRQ enable without achieving much. It ends up transferring data from irq handler with both local irq and HD_IRQ disabled. The only place it actually does something is while transferring the first block of a request which it does with HD_IRQ disabled but local irq enabled. Unfortunately, the dancing is horribly broken from locking POV. IRQ and timeout handlers access block queue without grabbing the queue lock and running the driver in SMP configuration crashes the whole machine pretty quickly. Remove meaningless irq enable/disable dancing and add proper locking in issue, irq and timeout paths. Signed-off-by: Tejun Heo <tj@kernel.org> 
hd dance around local irq and HD_IRQ enable without achieving much.
It ends up transferring data from irq handler with both local irq and
HD_IRQ disabled.  The only place it actually does something is while
transferring the first block of a request which it does with HD_IRQ
disabled but local irq enabled.

Unfortunately, the dancing is horribly broken from locking POV.  IRQ
and timeout handlers access block queue without grabbing the queue
lock and running the driver in SMP configuration crashes the whole
machine pretty quickly.

Remove meaningless irq enable/disable dancing and add proper locking
in issue, irq and timeout paths.

Signed-off-by: Tejun Heo <tj@kernel.org>
mg_disk: fix CONFIG_LBD=y warning 2009-04-28T18:24:20+00:00 Bartlomiej Zolnierkiewicz bzolnier@gmail.com 2009-04-28T03:38:33+00:00 0d9f346fb0cd6d6fc70827c5396a0d83939530e4 drivers/block/mg_disk.c: In function ‘mg_dump_status’: drivers/block/mg_disk.c:265: warning: format ‘%ld’ expects type ‘long int’, but argument 2 has type ‘sector_t’ [ Impact: kill build warning ] Cc: unsik Kim <donari75@gmail.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org> 
drivers/block/mg_disk.c: In function ‘mg_dump_status’:
drivers/block/mg_disk.c:265: warning: format ‘%ld’ expects type ‘long int’, but
argument 2 has type ‘sector_t’

[ Impact: kill build warning ]

Cc: unsik Kim <donari75@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
mg_disk: fix locking 2009-04-28T18:24:19+00:00 Tejun Heo tj@kernel.org 2009-04-28T03:38:32+00:00 39f36b47caae1443eb37c34c6def108bb79f8d25 IRQ and timeout handlers call functions which expect locked queue lock without locking it. Fix it. While at it, convert 0s used as null pointer constant to NULLs. [ Impact: fix locking, cleanup ] Signed-off-by: Tejun Heo <tj@kernel.org> Cc: unsik Kim <donari75@gmail.com> 
IRQ and timeout handlers call functions which expect locked queue lock
without locking it.  Fix it.

While at it, convert 0s used as null pointer constant to NULLs.

[ Impact: fix locking, cleanup ]

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: unsik Kim <donari75@gmail.com>
umem: fix request_queue lock warning 2009-04-24T06:54:21+00:00 Sage Weil sage@newdream.ne 2009-04-23T06:37:58+00:00 f3c737de8f57b5ce756010c2175f7d574194b30d The umem driver issues two warnings on boot, due to blk_plug_device() and blk_remove_plug() being called without q->queue_lock held. Starting with e48ec690 (block: extend queue_flag bitops), the queue_flag_* functions warn if q->queue_lock doesn't appear to be locked. In fact, q->queue_lock is NULL (though that apparently isn't otherwise a problem as the driver is using card->lock for everything). Although blk_init_queue() with take a request_fn_proc and spinlock_t*, there isn't a corresponding init helper that takes a make_request_fn. Setting queue_lock to &card->lock explicitly seems to work fine for me. The warning goes away and the device appears to behave. [ 1.531881] v2.3 : Micro Memory(tm) PCI memory board block driver [ 1.538136] umem 0000:02:01.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 [ 1.545018] umem 0000:02:01.0: Micro Memory(tm) controller found (PCI Mem Module (Battery Backup)) [ 1.554176] umem 0000:02:01.0: CSR 0xfc9ffc00 -> 0xffffc200013d0c00 (0x100) [ 1.561279] umem 0000:02:01.0: Size 1048576 KB, Battery 1 Disabled (FAILURE), Battery 2 Disabled (FAILURE) [ 1.571114] umem 0000:02:01.0: Window size 16777216 bytes, IRQ 20 [ 1.577304] umem 0000:02:01.0: memory NOT initialized. Consider over-writing whole device. [ 1.585989] umema:<4>------------[ cut here ]------------ [ 1.591775] WARNING: at include/linux/blkdev.h:492 blk_plug_device+0x6d/0x106() [ 1.592025] Hardware name: H8SSL [ 1.592025] Modules linked in: [ 1.592025] Pid: 1, comm: swapper Not tainted 2.6.29 #8 [ 1.592025] Call Trace: [ 1.592025] [<ffffffff8023c994>] warn_slowpath+0xd3/0xf2 [ 1.592025] [<ffffffff8025a5b5>] ? save_trace+0x3f/0x9b [ 1.592025] [<ffffffff8025a68b>] ? add_lock_to_list+0x7a/0xba [ 1.592025] [<ffffffff8025e609>] ? validate_chain+0xb3b/0xce8 [ 1.592025] [<ffffffff80441556>] ? mm_make_request+0x27/0x59 [ 1.592025] [<ffffffff80441556>] ? mm_make_request+0x27/0x59 [ 1.592025] [<ffffffff8025ef04>] ? __lock_acquire+0x74e/0x7b9 [ 1.592025] [<ffffffff8025a70e>] ? get_lock_stats+0x34/0x5e [ 1.592025] [<ffffffff8025a746>] ? put_lock_stats+0xe/0x27 [ 1.592025] [<ffffffff80441556>] ? mm_make_request+0x27/0x59 [ 1.592025] [<ffffffff803ad165>] blk_plug_device+0x6d/0x106 [ 1.592025] [<ffffffff80441575>] mm_make_request+0x46/0x59 [ 1.592025] [<ffffffff803ac2d9>] generic_make_request+0x335/0x3cf [ 1.592025] [<ffffffff8027fcc7>] ? mempool_alloc_slab+0x11/0x13 [ 1.592025] [<ffffffff8027fdce>] ? mempool_alloc+0x45/0x101 [ 1.592025] [<ffffffff8025a746>] ? put_lock_stats+0xe/0x27 [ 1.592025] [<ffffffff803adda5>] submit_bio+0x10a/0x119 [ 1.592025] [<ffffffff802c8d00>] submit_bh+0xe5/0x109 [ 1.592025] [<ffffffff802cbf43>] block_read_full_page+0x2aa/0x2cb [ 1.592025] [<ffffffff802cf4c4>] ? blkdev_get_block+0x0/0x4c [ 1.592025] [<ffffffff805c90a8>] ? _spin_unlock_irq+0x36/0x51 [ 1.592025] [<ffffffff80286836>] ? __lru_cache_add+0x92/0xb2 [ 1.592025] [<ffffffff802cf008>] blkdev_readpage+0x13/0x15 [ 1.592025] [<ffffffff8027de06>] read_cache_page_async+0x90/0x134 [ 1.592025] [<ffffffff802ceff5>] ? blkdev_readpage+0x0/0x15 [ 1.592025] [<ffffffff802f5f1c>] ? adfspart_check_ICS+0x0/0x16c [ 1.592025] [<ffffffff8027deb8>] read_cache_page+0xe/0x45 [ 1.592025] [<ffffffff802f5170>] read_dev_sector+0x2e/0x93 [ 1.592025] [<ffffffff802f5f44>] adfspart_check_ICS+0x28/0x16c [ 1.592025] [<ffffffff8025d427>] ? trace_hardirqs_on+0xd/0xf [ 1.592025] [<ffffffff802f5f1c>] ? adfspart_check_ICS+0x0/0x16c [ 1.592025] [<ffffffff802f59c5>] rescan_partitions+0x168/0x2fb [ 1.592025] [<ffffffff802ceae9>] __blkdev_get+0x259/0x336 [ 1.592025] [<ffffffff803ca1e2>] ? kobject_put+0x47/0x4b [ 1.592025] [<ffffffff802cebd1>] blkdev_get+0xb/0xd [ 1.592025] [<ffffffff802f5773>] register_disk+0xc4/0x12b [ 1.592025] [<ffffffff803b2a7b>] add_disk+0xc3/0x12d [ 1.592025] [<ffffffff808a1d4a>] ? mm_init+0x0/0x1a5 [ 1.592025] [<ffffffff808a1e73>] mm_init+0x129/0x1a5 [ 1.592025] [<ffffffff808a1d4a>] ? mm_init+0x0/0x1a5 [ 1.592025] [<ffffffff80209056>] _stext+0x56/0x130 [ 1.592025] [<ffffffff80274932>] ? register_irq_proc+0xae/0xca [ 1.592025] [<ffffffff802f0000>] ? proc_pid_lookup+0xb4/0x18b [ 1.592025] [<ffffffff8087f975>] kernel_init+0x132/0x18b [ 1.592025] [<ffffffff8020d17a>] child_rip+0xa/0x20 [ 1.592025] [<ffffffff8020cb40>] ? restore_args+0x0/0x30 [ 1.592025] [<ffffffff8087f843>] ? kernel_init+0x0/0x18b [ 1.592025] [<ffffffff8020d170>] ? child_rip+0x0/0x20 [ 1.592025] ---[ end trace 7150b3b86da74e1e ]--- [ 1.889858] ------------[ cut here ]------------[ve_plug+0x5f/0x91() [ 1.893848] Hardware name: H8SSL [ 1.893848] Modules linked in: [ 1.893848] Pid: 1, comm: swapper Tainted: G W 2.6.29 #8 [ 1.893848] Call Trace: [ 1.893848] [<ffffffff8023c994>] warn_slowpath+0xd3/0xf2 [ 1.893848] [<ffffffff805c8411>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 1.893848] [<ffffffff8020cb40>] ? restore_args+0x0/0x30 [ 1.893848] [<ffffffff80254245>] ? __atomic_notifier_call_chain+0x0/0xb2 [ 1.893848] [<ffffffff805c90a3>] ? _spin_unlock_irq+0x31/0x51 [ 1.893848] [<ffffffff805c90bf>] ? _spin_unlock_irq+0x4d/0x51 [ 1.893848] [<ffffffff8044157d>] ? mm_make_request+0x4e/0x59 [ 1.893848] [<ffffffff8025a70e>] ? get_lock_stats+0x34/0x5e [ 1.893848] [<ffffffff8025a75d>] ? put_lock_stats+0x25/0x27 [ 1.893848] [<ffffffff80441504>] ? mm_unplug_device+0x25/0x50 [ 1.893848] [<ffffffff803acf23>] blk_remove_plug+0x5f/0x91 [ 1.893848] [<ffffffff8044150f>] mm_unplug_device+0x30/0x50 [ 1.893848] [<ffffffff803ab74a>] blk_unplug+0x78/0x7d [ 1.893848] [<ffffffff803ab75c>] blk_backing_dev_unplug+0xd/0xf [ 1.893848] [<ffffffff802c853c>] block_sync_page+0x4a/0x4c [ 1.893848] [<ffffffff8027da1c>] sync_page+0x44/0x4d [ 1.893848] [<ffffffff805c66fd>] __wait_on_bit_lock+0x42/0x8a [ 1.893848] [<ffffffff8027d9d8>] ? sync_page+0x0/0x4d [ 1.893848] [<ffffffff8027d9c4>] __lock_page+0x64/0x6b [ 1.893848] [<ffffffff802508db>] ? wake_bit_function+0x0/0x2a [ 1.893848] [<ffffffff8027de4a>] read_cache_page_async+0xd4/0x134 [ 1.893848] [<ffffffff802ceff5>] ? blkdev_readpage+0x0/0x15 [ 1.893848] [<ffffffff802f5f1c>] ? adfspart_check_ICS+0x0/0x16c [ 1.893848] [<ffffffff8027deb8>] read_cache_page+0xe/0x45 [ 1.893848] [<ffffffff802f5170>] read_dev_sector+0x2e/0x93 [ 1.893848] [<ffffffff802f5f44>] adfspart_check_ICS+0x28/0x16c [ 1.893848] [<ffffffff8025d427>] ? trace_hardirqs_on+0xd/0xf [ 1.893848] [<ffffffff802f5f1c>] ? adfspart_check_ICS+0x0/0x16c [ 1.893848] [<ffffffff802f59c5>] rescan_partitions+0x168/0x2fb [ 1.893848] [<ffffffff802ceae9>] __blkdev_get+0x259/0x336 [ 1.893848] [<ffffffff803ca1e2>] ? kobject_put+0x47/0x4b [ 1.893848] [<ffffffff802cebd1>] blkdev_get+0xb/0xd [ 1.893848] [<ffffffff802f5773>] register_disk+0xc4/0x12b [ 1.893848] [<ffffffff803b2a7b>] add_disk+0xc3/0x12d [ 1.893848] [<ffffffff808a1d4a>] ? mm_init+0x0/0x1a5 [ 1.893848] [<ffffffff808a1e73>] mm_init+0x129/0x1a5 [ 1.893848] [<ffffffff808a1d4a>] ? mm_init+0x0/0x1a5 [ 1.893848] [<ffffffff80209056>] _stext+0x56/0x130 [ 1.893848] [<ffffffff80274932>] ? register_irq_proc+0xae/0xca [ 1.893848] [<ffffffff802f0000>] ? proc_pid_lookup+0xb4/0x18b [ 1.893848] [<ffffffff8087f975>] kernel_init+0x132/0x18b [ 1.893848] [<ffffffff8020d17a>] child_rip+0xa/0x20 [ 1.893848] [<ffffffff8020cb40>] ? restore_args+0x0/0x30 [ 1.893848] [<ffffffff8087f843>] ? kernel_init+0x0/0x18b [ 1.893848] [<ffffffff8020d170>] ? child_rip+0x0/0x20 [ 1.893848] ---[ end trace 7150b3b86da74e1f ]--- Signed-off-by: Sage Weil <sage@newdream.net> Signed-off-by: Jens Axboe <jens.axboe@oracle.com> 
The umem driver issues two warnings on boot, due to blk_plug_device() and
blk_remove_plug() being called without q->queue_lock held.  Starting with
e48ec690 (block: extend queue_flag bitops), the queue_flag_* functions
warn if q->queue_lock doesn't appear to be locked.  In fact, q->queue_lock
is NULL (though that apparently isn't otherwise a problem as the driver is
using card->lock for everything).

Although blk_init_queue() with take a request_fn_proc and spinlock_t*,
there isn't a corresponding init helper that takes a make_request_fn.
Setting queue_lock to &card->lock explicitly seems to work fine for me.
The warning goes away and the device appears to behave.

[    1.531881] v2.3 : Micro Memory(tm) PCI memory board block driver
[    1.538136] umem 0000:02:01.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[    1.545018] umem 0000:02:01.0: Micro Memory(tm) controller found (PCI Mem Module (Battery Backup))
[    1.554176] umem 0000:02:01.0: CSR 0xfc9ffc00 -> 0xffffc200013d0c00 (0x100)
[    1.561279] umem 0000:02:01.0: Size 1048576 KB, Battery 1 Disabled (FAILURE), Battery 2 Disabled (FAILURE)
[    1.571114] umem 0000:02:01.0: Window size 16777216 bytes, IRQ 20
[    1.577304] umem 0000:02:01.0: memory NOT initialized. Consider over-writing whole device.
[    1.585989]  umema:<4>------------[ cut here ]------------
[    1.591775] WARNING: at include/linux/blkdev.h:492 blk_plug_device+0x6d/0x106()
[    1.592025] Hardware name: H8SSL
[    1.592025] Modules linked in:
[    1.592025] Pid: 1, comm: swapper Not tainted 2.6.29 #8
[    1.592025] Call Trace:
[    1.592025]  [<ffffffff8023c994>] warn_slowpath+0xd3/0xf2
[    1.592025]  [<ffffffff8025a5b5>] ? save_trace+0x3f/0x9b
[    1.592025]  [<ffffffff8025a68b>] ? add_lock_to_list+0x7a/0xba
[    1.592025]  [<ffffffff8025e609>] ? validate_chain+0xb3b/0xce8
[    1.592025]  [<ffffffff80441556>] ? mm_make_request+0x27/0x59
[    1.592025]  [<ffffffff80441556>] ? mm_make_request+0x27/0x59
[    1.592025]  [<ffffffff8025ef04>] ? __lock_acquire+0x74e/0x7b9
[    1.592025]  [<ffffffff8025a70e>] ? get_lock_stats+0x34/0x5e
[    1.592025]  [<ffffffff8025a746>] ? put_lock_stats+0xe/0x27
[    1.592025]  [<ffffffff80441556>] ? mm_make_request+0x27/0x59
[    1.592025]  [<ffffffff803ad165>] blk_plug_device+0x6d/0x106
[    1.592025]  [<ffffffff80441575>] mm_make_request+0x46/0x59
[    1.592025]  [<ffffffff803ac2d9>] generic_make_request+0x335/0x3cf
[    1.592025]  [<ffffffff8027fcc7>] ? mempool_alloc_slab+0x11/0x13
[    1.592025]  [<ffffffff8027fdce>] ? mempool_alloc+0x45/0x101
[    1.592025]  [<ffffffff8025a746>] ? put_lock_stats+0xe/0x27
[    1.592025]  [<ffffffff803adda5>] submit_bio+0x10a/0x119
[    1.592025]  [<ffffffff802c8d00>] submit_bh+0xe5/0x109
[    1.592025]  [<ffffffff802cbf43>] block_read_full_page+0x2aa/0x2cb
[    1.592025]  [<ffffffff802cf4c4>] ? blkdev_get_block+0x0/0x4c
[    1.592025]  [<ffffffff805c90a8>] ? _spin_unlock_irq+0x36/0x51
[    1.592025]  [<ffffffff80286836>] ? __lru_cache_add+0x92/0xb2
[    1.592025]  [<ffffffff802cf008>] blkdev_readpage+0x13/0x15
[    1.592025]  [<ffffffff8027de06>] read_cache_page_async+0x90/0x134
[    1.592025]  [<ffffffff802ceff5>] ? blkdev_readpage+0x0/0x15
[    1.592025]  [<ffffffff802f5f1c>] ? adfspart_check_ICS+0x0/0x16c
[    1.592025]  [<ffffffff8027deb8>] read_cache_page+0xe/0x45
[    1.592025]  [<ffffffff802f5170>] read_dev_sector+0x2e/0x93
[    1.592025]  [<ffffffff802f5f44>] adfspart_check_ICS+0x28/0x16c
[    1.592025]  [<ffffffff8025d427>] ? trace_hardirqs_on+0xd/0xf
[    1.592025]  [<ffffffff802f5f1c>] ? adfspart_check_ICS+0x0/0x16c
[    1.592025]  [<ffffffff802f59c5>] rescan_partitions+0x168/0x2fb
[    1.592025]  [<ffffffff802ceae9>] __blkdev_get+0x259/0x336
[    1.592025]  [<ffffffff803ca1e2>] ? kobject_put+0x47/0x4b
[    1.592025]  [<ffffffff802cebd1>] blkdev_get+0xb/0xd
[    1.592025]  [<ffffffff802f5773>] register_disk+0xc4/0x12b
[    1.592025]  [<ffffffff803b2a7b>] add_disk+0xc3/0x12d
[    1.592025]  [<ffffffff808a1d4a>] ? mm_init+0x0/0x1a5
[    1.592025]  [<ffffffff808a1e73>] mm_init+0x129/0x1a5
[    1.592025]  [<ffffffff808a1d4a>] ? mm_init+0x0/0x1a5
[    1.592025]  [<ffffffff80209056>] _stext+0x56/0x130
[    1.592025]  [<ffffffff80274932>] ? register_irq_proc+0xae/0xca
[    1.592025]  [<ffffffff802f0000>] ? proc_pid_lookup+0xb4/0x18b
[    1.592025]  [<ffffffff8087f975>] kernel_init+0x132/0x18b
[    1.592025]  [<ffffffff8020d17a>] child_rip+0xa/0x20
[    1.592025]  [<ffffffff8020cb40>] ? restore_args+0x0/0x30
[    1.592025]  [<ffffffff8087f843>] ? kernel_init+0x0/0x18b
[    1.592025]  [<ffffffff8020d170>] ? child_rip+0x0/0x20
[    1.592025] ---[ end trace 7150b3b86da74e1e ]---
[    1.889858] ------------[ cut here ]------------[ve_plug+0x5f/0x91()
[    1.893848] Hardware name: H8SSL
[    1.893848] Modules linked in:
[    1.893848] Pid: 1, comm: swapper Tainted: G        W  2.6.29 #8
[    1.893848] Call Trace:
[    1.893848]  [<ffffffff8023c994>] warn_slowpath+0xd3/0xf2
[    1.893848]  [<ffffffff805c8411>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[    1.893848]  [<ffffffff8020cb40>] ? restore_args+0x0/0x30
[    1.893848]  [<ffffffff80254245>] ? __atomic_notifier_call_chain+0x0/0xb2
[    1.893848]  [<ffffffff805c90a3>] ? _spin_unlock_irq+0x31/0x51
[    1.893848]  [<ffffffff805c90bf>] ? _spin_unlock_irq+0x4d/0x51
[    1.893848]  [<ffffffff8044157d>] ? mm_make_request+0x4e/0x59
[    1.893848]  [<ffffffff8025a70e>] ? get_lock_stats+0x34/0x5e
[    1.893848]  [<ffffffff8025a75d>] ? put_lock_stats+0x25/0x27
[    1.893848]  [<ffffffff80441504>] ? mm_unplug_device+0x25/0x50
[    1.893848]  [<ffffffff803acf23>] blk_remove_plug+0x5f/0x91
[    1.893848]  [<ffffffff8044150f>] mm_unplug_device+0x30/0x50
[    1.893848]  [<ffffffff803ab74a>] blk_unplug+0x78/0x7d
[    1.893848]  [<ffffffff803ab75c>] blk_backing_dev_unplug+0xd/0xf
[    1.893848]  [<ffffffff802c853c>] block_sync_page+0x4a/0x4c
[    1.893848]  [<ffffffff8027da1c>] sync_page+0x44/0x4d
[    1.893848]  [<ffffffff805c66fd>] __wait_on_bit_lock+0x42/0x8a
[    1.893848]  [<ffffffff8027d9d8>] ? sync_page+0x0/0x4d
[    1.893848]  [<ffffffff8027d9c4>] __lock_page+0x64/0x6b
[    1.893848]  [<ffffffff802508db>] ? wake_bit_function+0x0/0x2a
[    1.893848]  [<ffffffff8027de4a>] read_cache_page_async+0xd4/0x134
[    1.893848]  [<ffffffff802ceff5>] ? blkdev_readpage+0x0/0x15
[    1.893848]  [<ffffffff802f5f1c>] ? adfspart_check_ICS+0x0/0x16c
[    1.893848]  [<ffffffff8027deb8>] read_cache_page+0xe/0x45
[    1.893848]  [<ffffffff802f5170>] read_dev_sector+0x2e/0x93
[    1.893848]  [<ffffffff802f5f44>] adfspart_check_ICS+0x28/0x16c
[    1.893848]  [<ffffffff8025d427>] ? trace_hardirqs_on+0xd/0xf
[    1.893848]  [<ffffffff802f5f1c>] ? adfspart_check_ICS+0x0/0x16c
[    1.893848]  [<ffffffff802f59c5>] rescan_partitions+0x168/0x2fb
[    1.893848]  [<ffffffff802ceae9>] __blkdev_get+0x259/0x336
[    1.893848]  [<ffffffff803ca1e2>] ? kobject_put+0x47/0x4b
[    1.893848]  [<ffffffff802cebd1>] blkdev_get+0xb/0xd
[    1.893848]  [<ffffffff802f5773>] register_disk+0xc4/0x12b
[    1.893848]  [<ffffffff803b2a7b>] add_disk+0xc3/0x12d
[    1.893848]  [<ffffffff808a1d4a>] ? mm_init+0x0/0x1a5
[    1.893848]  [<ffffffff808a1e73>] mm_init+0x129/0x1a5
[    1.893848]  [<ffffffff808a1d4a>] ? mm_init+0x0/0x1a5
[    1.893848]  [<ffffffff80209056>] _stext+0x56/0x130
[    1.893848]  [<ffffffff80274932>] ? register_irq_proc+0xae/0xca
[    1.893848]  [<ffffffff802f0000>] ? proc_pid_lookup+0xb4/0x18b
[    1.893848]  [<ffffffff8087f975>] kernel_init+0x132/0x18b
[    1.893848]  [<ffffffff8020d17a>] child_rip+0xa/0x20
[    1.893848]  [<ffffffff8020cb40>] ? restore_args+0x0/0x30
[    1.893848]  [<ffffffff8087f843>] ? kernel_init+0x0/0x18b
[    1.893848]  [<ffffffff8020d170>] ? child_rip+0x0/0x20
[    1.893848] ---[ end trace 7150b3b86da74e1f ]---

Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
USB: add reset endpoint operations 2009-04-17T17:50:27+00:00 David Vrabel david.vrabel@csr.com 2009-04-08T17:36:28+00:00 3444b26afa145148951112534f298bdc554ec789 Wireless USB endpoint state has a sequence number and a current window and not just a single toggle bit. So allow HCDs to provide a endpoint_reset method and call this or clear the software toggles as required (after a clear halt, set configuration etc.). usb_settoggle() and friends are then HCD internal and are moved into core/hcd.h and all device drivers call usb_reset_endpoint() instead. If the device endpoint state has been reset (with a clear halt) but the host endpoint state has not then subsequent data transfers will not complete. The device will only work again after it is reset or disconnected. Signed-off-by: David Vrabel <david.vrabel@csr.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Wireless USB endpoint state has a sequence number and a current
window and not just a single toggle bit.  So allow HCDs to provide a
endpoint_reset method and call this or clear the software toggles as
required (after a clear halt, set configuration etc.).

usb_settoggle() and friends are then HCD internal and are moved into
core/hcd.h and all device drivers call usb_reset_endpoint() instead.

If the device endpoint state has been reset (with a clear halt) but
the host endpoint state has not then subsequent data transfers will
not complete. The device will only work again after it is reset or
disconnected.

Signed-off-by: David Vrabel <david.vrabel@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
brd: fix cacheflushing 2009-04-15T10:10:13+00:00 Nick Piggin npiggin@suse.de 2009-04-15T08:32:07+00:00 c2572f2b4ffc27ba79211aceee3bef53a59bb5cd brd is missing a flush_dcache_page. On 2nd thoughts, perhaps it is the pagecache's responsibility to flush user virtual aliases (the driver of course should flush kernel virtual mappings)... but anyway, there already exists cache flushing for one direction of transfer, so we should add the other. Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Jens Axboe <jens.axboe@oracle.com> 
brd is missing a flush_dcache_page. On 2nd thoughts, perhaps it is the
pagecache's responsibility to flush user virtual aliases (the driver of
course should flush kernel virtual mappings)... but anyway, there
already exists cache flushing for one direction of transfer, so we
should add the other.

Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>