<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/scsi/aacraid, branch v2.6.23</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>[SCSI] aacraid: prevent panic on adapter resource failure</title>
<updated>2007-08-04T14:46:43+00:00</updated>
<author>
<name>Salyzyn, Mark</name>
<email>mark_salyzyn@adaptec.com</email>
</author>
<published>2007-08-02T19:38:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=2b053729a84b6aac197df51b8729bc9fec743bff'/>
<id>2b053729a84b6aac197df51b8729bc9fec743bff</id>
<content type='text'>
If the driver fails to allocate the contiguous (DMAable) memory for
system reasons, we fail to load the instance, but then we try to free
the &lt;nul&gt; allocation in the cleanup code and we get a panic in
pci_free_consistent(). This is reported against an older kernel, hope
this is relevant for latest/greatest.

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If the driver fails to allocate the contiguous (DMAable) memory for
system reasons, we fail to load the instance, but then we try to free
the &lt;nul&gt; allocation in the cleanup code and we get a panic in
pci_free_consistent(). This is reported against an older kernel, hope
this is relevant for latest/greatest.

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] aacraid: fix Sunrise Lake reset handling</title>
<updated>2007-07-28T14:11:32+00:00</updated>
<author>
<name>Salyzyn, Mark</name>
<email>mark_salyzyn@adaptec.com</email>
</author>
<published>2007-07-27T14:29:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9859c1aa7e16822c574e1be89d61fbfe6188b50f'/>
<id>9859c1aa7e16822c574e1be89d61fbfe6188b50f</id>
<content type='text'>
The patch is *much* smaller than the description. I am attempting to
answer to those that want to understand an issue that was reported in
May this year.

If a Sunrise Lake based card that requires an alternate reset mechanism
is set up to ignore the commanded IOP_RESET it reports 0x00000010
(IOP_RESET ignored) instead of 0x3803000F (use alternate reset mechanism
to reset all cores), and thus the reset platform function decides to
switch to IOP_RESET_ALWAYS because the reset platform function
parameters indicate that we *need* to reset the card. IOP_RESET_ALWAYS
then responds with the 0x3803000F return code, but alas we treat this as
an error instead of using the alternate reset mechanism (put a 0x03 into
the register offset 0x38). The reset fails, but the fact that the
IOP_RESET_ALWAYS command was issued has put the card in a purposeful
shutdown state in preparation for the alternate hardware reset to be
applied. Yuck.

IOP_RESET is ignored in internal production cards, typically to ensure
that we catch all adapter lockup issues without the driver progressing
further, so this would not appear to be a field issue and thus this
patch was destined to be only in the internal Adaptec source tree.
IOP_RESET_ALWAYS is reserved for
kexec/kdump/FirmwareUpdate/AutomatedTestFrames so we did not function as
expected in any case. Also in the past we have had OEMs specifically
request that cards not be resetable after a BlinkLED/FirmwareAssert for
one reason or another and To head off the possibility that the Sunrise
Lake based cards would suffer a similar fate, we propose the enclosed
fix.

Yinghai Lu of SUN had a pre-production card with IOP_RESET disabled when
he reported an issue to the linux kernel list back in May regarding a
kexec problem resulting from this reset being ignore. His fix was to
update the Firmware to one that did not ignore the IOP_RESET. Previous
kernels did not attempt to reset the adapter and that is why it surfaced
as a regression in his hands.

The current list of aacraid based cards that use Sunrise Lake:

9005:0285:9005:02b5     Adaptec 5445
9005:0285:9005:02b6     Adaptec 5805
9005:0285:9005:02b7     Adaptec 5085
9005:0285:9005:02c3     Adaptec 51205
9005:0285:9005:02c4     Adaptec 51605
9005:0285:9005:02ce     Adaptec 51245
9005:0285:9005:02cf     Adaptec 51645
9005:0285:9005:02d0     Adaptec 52445
9005:0285:9005:02d1     Adaptec 5405
9005:0285:9005:02b8     ICP     ICP5445SL
9005:0285:9005:02b9     ICP     ICP5085SL
9005:0285:9005:02ba     ICP     ICP5805SL
9005:0285:9005:02c5     ICP     ICP5125SL
9005:0285:9005:02c6     ICP     ICP5165SL
9005:0285:108e:7aac     SUN     STK RAID REM
9005:0285:108e:0286     SUN     STK RAID INT
9005:0285:108e:0287     SUN     STK RAID EXT
9005:0285:108e:7aae     SUN     STK RAID EM

All of these are publicly released with IOP_RESET enabled. So there is
no immediate need for this patch.

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The patch is *much* smaller than the description. I am attempting to
answer to those that want to understand an issue that was reported in
May this year.

If a Sunrise Lake based card that requires an alternate reset mechanism
is set up to ignore the commanded IOP_RESET it reports 0x00000010
(IOP_RESET ignored) instead of 0x3803000F (use alternate reset mechanism
to reset all cores), and thus the reset platform function decides to
switch to IOP_RESET_ALWAYS because the reset platform function
parameters indicate that we *need* to reset the card. IOP_RESET_ALWAYS
then responds with the 0x3803000F return code, but alas we treat this as
an error instead of using the alternate reset mechanism (put a 0x03 into
the register offset 0x38). The reset fails, but the fact that the
IOP_RESET_ALWAYS command was issued has put the card in a purposeful
shutdown state in preparation for the alternate hardware reset to be
applied. Yuck.

IOP_RESET is ignored in internal production cards, typically to ensure
that we catch all adapter lockup issues without the driver progressing
further, so this would not appear to be a field issue and thus this
patch was destined to be only in the internal Adaptec source tree.
IOP_RESET_ALWAYS is reserved for
kexec/kdump/FirmwareUpdate/AutomatedTestFrames so we did not function as
expected in any case. Also in the past we have had OEMs specifically
request that cards not be resetable after a BlinkLED/FirmwareAssert for
one reason or another and To head off the possibility that the Sunrise
Lake based cards would suffer a similar fate, we propose the enclosed
fix.

Yinghai Lu of SUN had a pre-production card with IOP_RESET disabled when
he reported an issue to the linux kernel list back in May regarding a
kexec problem resulting from this reset being ignore. His fix was to
update the Firmware to one that did not ignore the IOP_RESET. Previous
kernels did not attempt to reset the adapter and that is why it surfaced
as a regression in his hands.

The current list of aacraid based cards that use Sunrise Lake:

9005:0285:9005:02b5     Adaptec 5445
9005:0285:9005:02b6     Adaptec 5805
9005:0285:9005:02b7     Adaptec 5085
9005:0285:9005:02c3     Adaptec 51205
9005:0285:9005:02c4     Adaptec 51605
9005:0285:9005:02ce     Adaptec 51245
9005:0285:9005:02cf     Adaptec 51645
9005:0285:9005:02d0     Adaptec 52445
9005:0285:9005:02d1     Adaptec 5405
9005:0285:9005:02b8     ICP     ICP5445SL
9005:0285:9005:02b9     ICP     ICP5085SL
9005:0285:9005:02ba     ICP     ICP5805SL
9005:0285:9005:02c5     ICP     ICP5125SL
9005:0285:9005:02c6     ICP     ICP5165SL
9005:0285:108e:7aac     SUN     STK RAID REM
9005:0285:108e:0286     SUN     STK RAID INT
9005:0285:108e:0287     SUN     STK RAID EXT
9005:0285:108e:7aae     SUN     STK RAID EM

All of these are publicly released with IOP_RESET enabled. So there is
no immediate need for this patch.

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] aacraid: add SCSI SYNCHONIZE_CACHE range checking</title>
<updated>2007-07-28T14:09:07+00:00</updated>
<author>
<name>Salyzyn, Mark</name>
<email>mark_salyzyn@adaptec.com</email>
</author>
<published>2007-07-27T13:48:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b90f90d2303f27b9b241ab78419a07b41de5ac62'/>
<id>b90f90d2303f27b9b241ab78419a07b41de5ac62</id>
<content type='text'>
Customer running an application that issues SYNCHRONIZE_CACHE calls
directly noticed the broad stroke of the current implementation in the
aacraid driver resulting in multiple applications feeding I/O to the
storage causing the issuing application to stall for long periods of
time. By only waiting for the current WRITE commands, rather than all
commands, to complete; and those that are in range of the
SYNCHRONIZE_CACHE call that would associate more tightly with the
issuing application before telling the Firmware to flush it's dirty
cache, we managed to reduce the stalling. The Firmware itself still
flushes all the dirty cache associated with the array ignoring the
range, it just does so in a more timely manner.

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Customer running an application that issues SYNCHRONIZE_CACHE calls
directly noticed the broad stroke of the current implementation in the
aacraid driver resulting in multiple applications feeding I/O to the
storage causing the issuing application to stall for long periods of
time. By only waiting for the current WRITE commands, rather than all
commands, to complete; and those that are in range of the
SYNCHRONIZE_CACHE call that would associate more tightly with the
issuing application before telling the Firmware to flush it's dirty
cache, we managed to reduce the stalling. The Firmware itself still
flushes all the dirty cache associated with the array ignoring the
range, it just does so in a more timely manner.

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] aacraid: draw line in sand, sundry cleanup and version update</title>
<updated>2007-07-27T13:13:28+00:00</updated>
<author>
<name>Salyzyn, Mark</name>
<email>mark_salyzyn@adaptec.com</email>
</author>
<published>2007-07-26T18:20:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c835e3727b87115f98c612a5ecb8882826d2537e'/>
<id>c835e3727b87115f98c612a5ecb8882826d2537e</id>
<content type='text'>
Minor unimportant cuttings from the floor bundled in with a version
stamp update. Only controversial change is the dropping of Alan Cox
copyright on the nark.c module since that file has no code written by
him in it.

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Minor unimportant cuttings from the floor bundled in with a version
stamp update. Only controversial change is the dropping of Alan Cox
copyright on the nark.c module since that file has no code written by
him in it.

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] aacraid: sysfs adapter reset/status format change.</title>
<updated>2007-07-23T21:58:43+00:00</updated>
<author>
<name>Salyzyn, Mark</name>
<email>mark_salyzyn@adaptec.com</email>
</author>
<published>2007-07-23T14:13:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=bbf17d6483a7feb4c1eeef9fd553976d4f394e4c'/>
<id>bbf17d6483a7feb4c1eeef9fd553976d4f394e4c</id>
<content type='text'>
We need to newline terminate responses from nodes within the sysfs tree,
the Adapter status value reported by the reset adapter node is adjusted.

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We need to newline terminate responses from nodes within the sysfs tree,
the Adapter status value reported by the reset adapter node is adjusted.

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] aacraid: Fix security hole</title>
<updated>2007-07-23T21:52:30+00:00</updated>
<author>
<name>Alan Cox</name>
<email>alan@lxorguk.ukuu.org.uk</email>
</author>
<published>2007-07-23T13:51:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=60395bb60e0b5e4e0808ac8eb07a92f6c9cdea1f'/>
<id>60395bb60e0b5e4e0808ac8eb07a92f6c9cdea1f</id>
<content type='text'>
On the SCSI layer ioctl path there is no implicit permissions check for
ioctls (and indeed other drivers implement unprivileged ioctls). aacraid
however allows all sorts of very admin only things to be done so should
check.

Signed-off-by: Alan Cox &lt;alan@redhat.com&gt;
Acked-by: "Salyzyn, Mark" &lt;mark_salyzyn@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On the SCSI layer ioctl path there is no implicit permissions check for
ioctls (and indeed other drivers implement unprivileged ioctls). aacraid
however allows all sorts of very admin only things to be done so should
check.

Signed-off-by: Alan Cox &lt;alan@redhat.com&gt;
Acked-by: "Salyzyn, Mark" &lt;mark_salyzyn@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] aacraid: add vpd to inquiry</title>
<updated>2007-07-18T16:17:48+00:00</updated>
<author>
<name>Salyzyn, Mark</name>
<email>mark_salyzyn@adaptec.com</email>
</author>
<published>2007-07-17T18:01:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=88e2f98e1b3eb27ae708daa3b37dd50f3f06c952'/>
<id>88e2f98e1b3eb27ae708daa3b37dd50f3f06c952</id>
<content type='text'>
Report VPD inquiry page 0x80 with an unique array creation serial
number (CUID). When an array is created, the metadata stored on the
physical drives gets an unique serial number. This serial number
remains constant through array morphing or migration to other
controllers.  This patch is a forward port and modification to survive
morphing and migration operations, of a similar piece of
(un-attributed author) code added to the SLES10 SP1 aacraid driver.

To test the results of the patch, observe that /dev/disk/by-id/
entries will show up for the arrays resulting from the udev rules.
Also, as per the udev rules, 'scsi_id -g -x -a -s /block/sd? -d
/dev/sd?'  will report the ID_SERIAL as constructed from the inquiry
data.

It was reported to me that the 'ADPT' leading the serial number was bad
form, that the inquiry vendor field was enough to differentiate the
storage uniquely. Subsequent search found that another Adaptec AAC based
driver reported the 8 hex serial number only without such adornments, so
dropped ADPT to match. Resubmitting the patch with this alteration.

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Report VPD inquiry page 0x80 with an unique array creation serial
number (CUID). When an array is created, the metadata stored on the
physical drives gets an unique serial number. This serial number
remains constant through array morphing or migration to other
controllers.  This patch is a forward port and modification to survive
morphing and migration operations, of a similar piece of
(un-attributed author) code added to the SLES10 SP1 aacraid driver.

To test the results of the patch, observe that /dev/disk/by-id/
entries will show up for the arrays resulting from the udev rules.
Also, as per the udev rules, 'scsi_id -g -x -a -s /block/sd? -d
/dev/sd?'  will report the ID_SERIAL as constructed from the inquiry
data.

It was reported to me that the 'ADPT' leading the serial number was bad
form, that the inquiry vendor field was enough to differentiate the
storage uniquely. Subsequent search found that another Adaptec AAC based
driver reported the 8 hex serial number only without such adornments, so
dropped ADPT to match. Resubmitting the patch with this alteration.

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] aacraid: incorrect dma mapping mask during blinkled recover or user initiated reset</title>
<updated>2007-07-18T16:17:41+00:00</updated>
<author>
<name>Salyzyn, Mark</name>
<email>mark_salyzyn@adaptec.com</email>
</author>
<published>2007-07-17T15:15:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9ad5204d68a3b48b92907d88d1c28d33fde6ba2a'/>
<id>9ad5204d68a3b48b92907d88d1c28d33fde6ba2a</id>
<content type='text'>
Incorrect dma mask was used for blinkled (firmware assert) recovery or
user initiated reset during initialization portion. Ensure that all
callers of aac_fib_map_free null out the fib allocation references to
prevent multiple free. Although serious sounding, no reports of these
problems have surfaced...

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Incorrect dma mask was used for blinkled (firmware assert) recovery or
user initiated reset during initialization portion. Ensure that all
callers of aac_fib_map_free null out the fib allocation references to
prevent multiple free. Although serious sounding, no reports of these
problems have surfaced...

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] aacraid: correct valid container response in management ioctl</title>
<updated>2007-07-18T16:17:33+00:00</updated>
<author>
<name>Salyzyn, Mark</name>
<email>mark_salyzyn@adaptec.com</email>
</author>
<published>2007-07-17T14:59:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=fd622b1b4ef976fab4d2ac1cd5c8f4aece805765'/>
<id>fd622b1b4ef976fab4d2ac1cd5c8f4aece805765</id>
<content type='text'>
During an Adapter Initiated scan request, the query disk ioctl reports a
value of 2 rather than 1 for the valid field. This presents a problem
for some legacy management applications.

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
During an Adapter Initiated scan request, the query disk ioctl reports a
value of 2 rather than 1 for the valid field. This presents a problem
for some legacy management applications.

Signed-off-by: Mark Salyzyn &lt;aacraid@adaptec.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@SteelEye.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6</title>
<updated>2007-07-15T23:51:54+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@woody.linux-foundation.org</email>
</author>
<published>2007-07-15T23:51:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=bc06cffdec85d487c77109dffcd2f285bdc502d3'/>
<id>bc06cffdec85d487c77109dffcd2f285bdc502d3</id>
<content type='text'>
* master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (166 commits)
  [SCSI] ibmvscsi: convert to use the data buffer accessors
  [SCSI] dc395x: convert to use the data buffer accessors
  [SCSI] ncr53c8xx: convert to use the data buffer accessors
  [SCSI] sym53c8xx: convert to use the data buffer accessors
  [SCSI] ppa: coding police and printk levels
  [SCSI] aic7xxx_old: remove redundant GFP_ATOMIC from kmalloc
  [SCSI] i2o: remove redundant GFP_ATOMIC from kmalloc from device.c
  [SCSI] remove the dead CYBERSTORMIII_SCSI option
  [SCSI] don't build scsi_dma_{map,unmap} for !HAS_DMA
  [SCSI] Clean up scsi_add_lun a bit
  [SCSI] 53c700: Remove printk, which triggers because of low scsi clock on SNI RMs
  [SCSI] sni_53c710: Cleanup
  [SCSI] qla4xxx: Fix underrun/overrun conditions
  [SCSI] megaraid_mbox: use mutex instead of semaphore
  [SCSI] aacraid: add 51245, 51645 and 52245 adapters to documentation.
  [SCSI] qla2xxx: update version to 8.02.00-k1.
  [SCSI] qla2xxx: add support for NPIV
  [SCSI] stex: use resid for xfer len information
  [SCSI] Add Brownie 1200U3P to blacklist
  [SCSI] scsi.c: convert to use the data buffer accessors
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (166 commits)
  [SCSI] ibmvscsi: convert to use the data buffer accessors
  [SCSI] dc395x: convert to use the data buffer accessors
  [SCSI] ncr53c8xx: convert to use the data buffer accessors
  [SCSI] sym53c8xx: convert to use the data buffer accessors
  [SCSI] ppa: coding police and printk levels
  [SCSI] aic7xxx_old: remove redundant GFP_ATOMIC from kmalloc
  [SCSI] i2o: remove redundant GFP_ATOMIC from kmalloc from device.c
  [SCSI] remove the dead CYBERSTORMIII_SCSI option
  [SCSI] don't build scsi_dma_{map,unmap} for !HAS_DMA
  [SCSI] Clean up scsi_add_lun a bit
  [SCSI] 53c700: Remove printk, which triggers because of low scsi clock on SNI RMs
  [SCSI] sni_53c710: Cleanup
  [SCSI] qla4xxx: Fix underrun/overrun conditions
  [SCSI] megaraid_mbox: use mutex instead of semaphore
  [SCSI] aacraid: add 51245, 51645 and 52245 adapters to documentation.
  [SCSI] qla2xxx: update version to 8.02.00-k1.
  [SCSI] qla2xxx: add support for NPIV
  [SCSI] stex: use resid for xfer len information
  [SCSI] Add Brownie 1200U3P to blacklist
  [SCSI] scsi.c: convert to use the data buffer accessors
  ...
</pre>
</div>
</content>
</entry>
</feed>
