linux-toradex.git/drivers/block, branch v2.6.27.43

floppy: fix lock imbalance

2009-07-20T03:45:00+00:00

commit 8516a500029890a72622d245f8ed32c4e30969b7 upstream.

A crappy macro prevents us unlocking on a fail path.

Expand the macro and unlock appropriatelly.

Signed-off-by: Jiri Slaby 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

floppy: request and release only the ports we actually use

2009-07-02T23:31:45+00:00

commit 5a74db06cc8d36a325913aa4968ae169f997a466 upstream.

The floppy driver requests an I/O port it doesn't need, and sometimes this
causes a conflict with a motherboard device reported by PNPBIOS.

This patch makes the floppy driver request and release only the ports it
actually uses.  It also factors out the request/release stuff and the
io-ports list so they're all in one place now.

The current floppy driver uses only these ports:

    0x3f2 (FD_DOR)
    0x3f4 (FD_STATUS)
    0x3f5 (FD_DATA)
    0x3f7 (FD_DCR/FD_DIR)

but it requests 0x3f2-0x3f5 and 0x3f7, which includes the unused port
0x3f3.

Some BIOSes report 0x3f3 as a motherboard resource.  The PNP system driver
reserves that, which causes a conflict when the floppy driver requests
0x3f2-0x3f5 later.

Philippe reported that this conflict broke the floppy driver between
2.6.11 and 2.6.22.  His PNPBIOS reports these devices:

    $ cat 00:07/id 00:07/resources	# motherboard device
    PNP0c02
    state = active
    io 0x80-0x80
    io 0x10-0x1f
    io 0x22-0x3f
    io 0x44-0x5f
    io 0x90-0x9f
    io 0xa2-0xbf
    io 0x3f0-0x3f1
    io 0x3f3-0x3f3

    $ cat 00:03/id 00:03/resources	# floppy device
    PNP0700
    state = active
    io 0x3f4-0x3f5
    io 0x3f2-0x3f2

Reference:
    http://lkml.org/lkml/2009/1/31/162

Signed-off-by: Bjorn Helgaas 
Signed-off-by: Philippe De Muyter 
Reported-by: Philippe De Muyter 
Tested-by: Philippe De Muyter 
Cc: Adam M Belay 
Cc: Robert Hancock 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

floppy: provide a PNP device table in the module.

2009-07-02T23:31:44+00:00

commit 83f9ef463bcb4ba7b4fee1d6212fac7d277010d3 upstream.

The missing device table means that the floppy module is not auto-loaded,
even when the appropriate PNP device (0700) is found.

We don't actually use the table in the module, since the device doesn't
have a struct pnp_driver, but it's sufficient to cause an alias in the
module that udev/modprobe will use.

Signed-off-by: Scott James Remnant 
Signed-off-by: Tim Gardner 
Cc: Bjorn Helgaas 
Cc: Philippe De Muyter 
Acked-by: Kay Sievers 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

xen/blkfront: use blk_rq_map_sg to generate ring entries

2009-03-17T00:53:01+00:00

commit 9e973e64ac6dc504e6447d52193d4fff1a670156 upstream.

On occasion, the request will apparently have more segments than we
fit into the ring. Jens says:

> The second problem is that the block layer then appears to create one
> too many segments, but from the dump it has rq->nr_phys_segments ==
> BLKIF_MAX_SEGMENTS_PER_REQUEST. I suspect the latter is due to
> xen-blkfront not handling the merging on its own. It should check that
> the new page doesn't form part of the previous page. The
> rq_for_each_segment() iterates all single bits in the request, not dma
> segments. The "easiest" way to do this is to call blk_rq_map_sg() and
> then iterate the mapped sg list. That will give you what you are
> looking for.

> Here's a test patch, compiles but otherwise untested. I spent more
> time figuring out how to enable XEN than to code it up, so YMMV!
> Probably the sg list wants to be put inside the ring and only
> initialized on allocation, then you can get rid of the sg on stack and
> sg_init_table() loop call in the function. I'll leave that, and the
> testing, to you.

[Moved sg array into info structure, and initialize once. -J]

Signed-off-by: Jens Axboe 
Signed-off-by: Jeremy Fitzhardinge 
Cc: Sven Köhler 
Signed-off-by: Greg Kroah-Hartman

aoe: ignore vendor extension AoE responses

2009-03-17T00:52:43+00:00

commit b6d6c5175809934e04a606d9193ef04924a7a7d9 upstream.

The Welland ME-747K-SI AoE target generates unsolicited AoE responses that
are marked as vendor extensions.  Instead of ignoring these packets, the
aoe driver was generating kernel messages for each unrecognized response
received.  This patch corrects the behavior.

Signed-off-by: Ed Cashin 
Reported-by: 
Tested-by: 
Cc: Alex Buell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

nbd: fix I/O hang on disconnected nbds

2009-02-17T17:46:15+00:00

commit 4d48a542b42747c36a5937447d9c3de7c897ea50 upstream.

Fix a problem that causes I/O to a disconnected (or partially initialized)
nbd device to hang indefinitely.  To reproduce:

# ioctl NBD_SET_SIZE_BLOCKS /dev/nbd23 514048
# dd if=/dev/nbd23 of=/dev/null bs=4096 count=1

...hangs...

This can also occur when an nbd device loses its nbd-client/server
connection.  Although we clear the queue of any outstanding I/Os after the
client/server connection fails, any additional I/Os that get queued later
will hang.

This bug may also be the problem reported in this bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=12277

Testing would need to be performed to determine if the two issues are the
same.

This problem was introduced by the new request handling thread code ("NBD:
allow nbd to be used locally", 3/2008), which entered into mainline around
2.6.25.

The fix, which is fairly simple, is to restore the check for lo->sock
being NULL in do_nbd_request.  This causes I/O to an uninitialized nbd to
immediately fail with an I/O error, as it did prior to the introduction of
this bug.

Signed-off-by: Paul Clements 
Reported-by: Jon Nelson 
Acked-by: Pavel Machek 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

cciss: fix problem that deleting multiple logical drives could cause a panic

2009-01-14T17:44:06+00:00

commit d8a0be6ab7ba1ffa43e7ea0dcdde3e8b68d4f762 upstream.

Fix problem that deleting multiple logical drives could cause a panic.

It fixes a panic which can be easily reproduced in the following way: Just
create several "arrays," each with multiple logical drives via hpacucli,
then delete the first array, and it will blow up in deregister_disk(), in
the call to get_host() when it tries to dig the hba pointer out of a NULL
queue pointer.

The problem has been present since my code to make rebuild_lun_table
behave better went in.

Signed-off-by: Stephen M. Cameron 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

cpqarry: fix return value of cpqarray_init()

2008-11-13T17:56:03+00:00

commit 2197d18ded232ef6eef63cce57b6b21eddf1b7b6 upstream.

As reported by Dick Gevers on Compaq ProLiant:

Oct 13 18:06:51 dvgcpl kernel: Compaq SMART2 Driver (v 2.6.0)
Oct 13 18:06:51 dvgcpl kernel: sys_init_module: 'cpqarray'->init
suspiciously returned 1, it should follow 0/-E convention
Oct 13 18:06:51 dvgcpl kernel: sys_init_module: loading module anyway...
Oct 13 18:06:51 dvgcpl kernel: Pid: 315, comm: modprobe Not tainted
2.6.27-desktop-0.rc8.2mnb #1
Oct 13 18:06:51 dvgcpl kernel:  [] ? printk+0x18/0x1e
Oct 13 18:06:51 dvgcpl kernel:  [] sys_init_module+0x155/0x1c0
Oct 13 18:06:51 dvgcpl kernel:  [] syscall_call+0x7/0xb
Oct 13 18:06:51 dvgcpl kernel:  =======================

Make it return 0 on success and -ENODEV if no array was found.

Reported-by: Dick Gevers 
Signed-off-by: Andrey Borzenkov 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

cciss: new hardware support

2008-11-13T17:55:57+00:00

commit 77ca7286d10b798e4907af941f29672bf484db77 upstream

cciss: new hardware support

Add support for 2 new SAS/SATA controllers.

Signed-off-by: Mike Miller 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

cciss: fix sysfs broken symlink regression

2008-11-13T17:55:56+00:00

commit 404443081ce5e6f68b5f7eda16c959835ff200c0 upstream

Regression introduced by commit 6ae5ce8e8d4de666f31286808d2285aa6a50fa40
("cciss: remove redundant code").

This patch fixes a broken symlink in sysfs that was introduced by the
above commit.  We broke it in 2.6.27-rc on or about 20080804.  Some
installers are broken if this symlink does not exist and they may not
detect the logical drives configured on the controller.  It does not
require being backported into 2.6.26.x or earlier kernels.

Signed-off-by: Mike Miller 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman