<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/block, branch v2.6.16.54</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/block?h=v2.6.16.54</id>
<link rel='self' href='https://git.amat.us/linux/atom/block?h=v2.6.16.54'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2007-04-20T22:13:30Z</updated>
<entry>
<title>elevator: move clearing of unplug flag earlier</title>
<updated>2007-04-20T22:13:30Z</updated>
<author>
<name>Linas Vepstas</name>
<email>linas@austin.ibm.com</email>
</author>
<published>2007-04-20T22:13:30Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=908991f13837d34a445fc313e44fd7b6dbb5c5c9'/>
<id>urn:sha1:908991f13837d34a445fc313e44fd7b6dbb5c5c9</id>
<content type='text'>
A flag was recently added to the elevator code to avoid
performing an unplug when reuests are being re-queued.
The goal of this flag was to avoid a deep recursion that
can occur when re-queueing requests after a SCSI device/host
reset.  See http://lkml.org/lkml/2006/5/17/254

However, that fix added the flag near the bottom of a case
statement, where an earlier break (in an if statement) could
transport one out of the case, without setting the flag.
This patch sets the flag earlier in the case statement.

I re-discovered the deep recursion recently during testing;
I was told that it was a known problem, and the fix to it was
in the kernel I was testing. Indeed it was ... but it didn't
fix the bug. With the patch below, I no longer see the bug.

Signed-off by: Linas Vepstas &lt;linas@austin.ibm.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@suse.de&gt;
Signed-off-by: Adrian Bunk &lt;bunk@stusta.de&gt;
</content>
</entry>
<entry>
<title>scsi: clear garbage after CDBs on SG_IO</title>
<updated>2006-12-17T20:32:00Z</updated>
<author>
<name>Tejun Heo</name>
<email>htejun@gmail.com</email>
</author>
<published>2006-12-17T20:32:00Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=961428b9aed2ee9cf631d16f1620640cd54a4557'/>
<id>urn:sha1:961428b9aed2ee9cf631d16f1620640cd54a4557</id>
<content type='text'>
ATAPI devices transfer fixed number of bytes for CDBs (12 or 16).  Some
ATAPI devices choke when shorter CDB is used and the left bytes contain
garbage.  Block SG_IO cleared left bytes but SCSI SG_IO didn't.  This patch
makes SCSI SG_IO clear it and simplify CDB clearing in block SG_IO.

Signed-off-by: Tejun Heo &lt;htejun@gmail.com&gt;
Acked-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Adrian Bunk &lt;bunk@stusta.de&gt;
</content>
</entry>
<entry>
<title>block layer: elv_iosched_show should get elv_list_lock</title>
<updated>2006-11-29T13:04:14Z</updated>
<author>
<name>Vasily Tarasov</name>
<email>vtaras@openvz.org</email>
</author>
<published>2006-11-29T13:04:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b46d1f7bcd9db417ce46463de3bbbb095fe8013a'/>
<id>urn:sha1:b46d1f7bcd9db417ce46463de3bbbb095fe8013a</id>
<content type='text'>
elv_iosched_show function iterates other elv_list,
hence elv_list_lock should be got.

Also the question is: in elv_iosched_show, elv_iosched_store
q-&gt;elevator-&gt;elevator_type construction is used without locking q-&gt;queue_lock.
Is it expected?..

Signed-off-by: Vasily Tarasov &lt;vtaras@openvz.org&gt;
Acked-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Adrian Bunk &lt;bunk@stusta.de&gt;
</content>
</entry>
<entry>
<title>block: Fix bad data direction in SG_IO</title>
<updated>2006-11-29T13:01:40Z</updated>
<author>
<name>Jens Axboe</name>
<email>jens.axboe@oracle.com</email>
</author>
<published>2006-11-29T13:01:40Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=18ff15828e2912b6d68a0481e01cd1ec34eb19e6'/>
<id>urn:sha1:18ff15828e2912b6d68a0481e01cd1ec34eb19e6</id>
<content type='text'>
Contrary to what the name misleads you to believe, SG_DXFER_TO_FROM_DEV
is really just a normal read seen from the device side.

This patch fixes http://lkml.org/lkml/2006/10/13/100

Signed-off-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Adrian Bunk &lt;bunk@stusta.de&gt;
</content>
</entry>
<entry>
<title>BLOCK: Fix bounce limit address check</title>
<updated>2006-08-07T19:26:18Z</updated>
<author>
<name>Andi Kleen</name>
<email>ak@suse.de</email>
</author>
<published>2006-08-07T19:26:18Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3d6cf29b3f117605c66583b9145f53d39c695a6e'/>
<id>urn:sha1:3d6cf29b3f117605c66583b9145f53d39c695a6e</id>
<content type='text'>
This fixes some OOMs on 64bit systems with &lt;4GB of RAM when accessing
the cdrom.

Do a safer check for when to enable DMA. Currently we enable ISA DMA
for cases that do not need it, resulting in OOM conditions when ZONE_DMA
runs out of space.

Signed-off-by: Andi Kleen &lt;ak@suse.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@suse.de&gt;
Signed-off-by: Adrian Bunk &lt;bunk@stusta.de&gt;
</content>
</entry>
<entry>
<title>[PATCH] limit request_fn recursion</title>
<updated>2006-05-20T22:00:31Z</updated>
<author>
<name>Jens Axboe</name>
<email>axboe@suse.de</email>
</author>
<published>2006-05-11T06:20:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7984c7b5a2ccd821caeab3d751e0941ca5e8b8d1'/>
<id>urn:sha1:7984c7b5a2ccd821caeab3d751e0941ca5e8b8d1</id>
<content type='text'>
Don't recurse back into the driver even if the unplug threshold is met,
when the driver asks for a requeue. This is both silly from a logical
point of view (requeues typically happen due to driver/hardware
shortage), and also dangerous since we could hit an endless request_fn
-&gt; requeue -&gt; unplug -&gt; request_fn loop and crash on stack overrun.

Also limit blk_run_queue() to one level of recursion, similar to how
blk_start_queue() works.

This patch fixed a real problem with SLES10 and lpfc, and it could hit
any SCSI lld that returns non-zero from it's -&gt;queuecommand() handler.

Signed-off-by: Jens Axboe &lt;axboe@suse.de&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] Simplify proc/devices and fix early termination regression</title>
<updated>2006-05-01T19:03:43Z</updated>
<author>
<name>Andrew Morton</name>
<email>akpm@osdl.org</email>
</author>
<published>2006-04-21T08:51:36Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=692c0509fd0719406f8f781d9a9f2e19aa6b7c0a'/>
<id>urn:sha1:692c0509fd0719406f8f781d9a9f2e19aa6b7c0a</id>
<content type='text'>
Repair /proc/devices early-termination regression.

2.6.16 broke /proc/devices.  An application often gets an
EOF before the end of data is reached, if that application
uses a series of short read(2)s to access the data.  I have
used read buffers of varying sizes with varying degrees
of unsuccess (larger sizes get further into the data than
smaller sizes, following a simple pattern).  It appears
that the only safe way to get the data is to use a single
read buffer larger than all the data in /proc/devices.

The following example demonstates the problem:

    # dd if=/proc/devices bs=1
    Character devices:
      1 mem
    27+0 records in
    27+0 records out

This patch is a backport of the fix recently accepted to
Linus's tree:

    commit 68eef3b4791572ecb70249c7fb145bb3742dd899
    [PATCH] Simplify proc/devices and fix early termination regression

It replaces the complex, state-machine algorithm introduced
in 2.6.16 with a simple algorithm, modeled on the implementation
of /proc/interrupts.

[akpm@osdl.org: cleanups, simplifications]

Signed-off-by: Joe Korty &lt;joe.korty@ccur.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
<entry>
<title>[PATCH] block: disable block layer bouncing for most memory on 64bit systems</title>
<updated>2006-03-09T02:10:31Z</updated>
<author>
<name>Andi Kleen</name>
<email>ak@suse.de</email>
</author>
<published>2006-03-09T01:57:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5ee1af9f519e6dc5a7d7912e87a1aaec857c8818'/>
<id>urn:sha1:5ee1af9f519e6dc5a7d7912e87a1aaec857c8818</id>
<content type='text'>
The low level PCI DMA mapping functions should handle it in most cases.

This should fix problems with depleting the DMA zone early. The old
code used precious GFP_DMA memory in many cases where it was not needed.

Signed-off-by: Andi Kleen &lt;ak@suse.de&gt;
Cc: Jens Axboe &lt;axboe@suse.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] cfq-iosched: slice expiry fixups</title>
<updated>2006-02-28T08:38:02Z</updated>
<author>
<name>Jens Axboe</name>
<email>axboe@suse.de</email>
</author>
<published>2006-02-28T08:35:11Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7b14e3b52fe5a2fb1dfa2f1f7dae4fd5f7d3fc47'/>
<id>urn:sha1:7b14e3b52fe5a2fb1dfa2f1f7dae4fd5f7d3fc47</id>
<content type='text'>
During testing of SLES10, we encountered a hang in the CFQ io scheduler.
Turns out the deferred slice expiry logic is buggy, so remove that for
now.  We could be left with an idle queue that would never wake up.  So
kill that logic, always expire immediately.  Also fix a potential timer
race condition.

Patch looks bigger than it is, because it moves a function.

Signed-off-by: Jens Axboe &lt;axboe@suse.de&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://brick.kernel.dk/data/git/linux-2.6-block</title>
<updated>2006-02-08T15:58:18Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@g5.osdl.org</email>
</author>
<published>2006-02-08T15:58:18Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b7ed1de0ae4edb3fd2c53fa3dd7e6f104beb6d00'/>
<id>urn:sha1:b7ed1de0ae4edb3fd2c53fa3dd7e6f104beb6d00</id>
<content type='text'>
</content>
</entry>
</feed>
