to 32k swamped the controller causing firmware hangs. Instead, round
requests smaller than 64k up to the next power of 2 as a general rule.
To handle the one known special case of a command that accepts a 12k
buffer returning a 24k-ish reply, round requests between 8k and 16k up
to 32k rather than 16k. The result is that commands less than 8k should
now be rounded up to a smaller size (either 4k or 8k) rather than 32k.
PR: kern/155658
Tested by: Andreas Longwitz
MFC after: 1 week
a 4kb buffer if a request uses a buffer size of 0. (The Linux ioctl path
already did this.)
PR: kern/155658
Submitted by: Andreas Longwitz
MFC after: 1 week
assumes for small buffers (< 64k) that the OS driver is actually using
a buffer rounded up to the next power of 2. It also assumes that the
buffer is at least 4k in size. Furthermore, there is at least one
known instance of megarc sending a request with a 12k buffer where the
firmware writes out a 24k-ish reply.
To workaround the data corruption triggered by this "feature", ensure
that buffers for user commands use a minimum size of 32k, and that
buffers between 32k and 64k use a 64k buffer.
PR: kern/155658
Submitted by: Andreas Longwitz longwitz incore de
Reviewed by: scottl
MFC after: 1 week
The newbus lock is responsible for protecting newbus internIal structures,
device states and devclass flags. It is necessary to hold it when all
such datas are accessed. For the other operations, softc locking should
ensure enough protection to avoid races.
Newbus lock is automatically held when virtual operations on the device
and bus are invoked when loading the driver or when the suspend/resume
take place. For other 'spourious' operations trying to access/modify
the newbus topology, newbus lock needs to be automatically acquired and
dropped.
For the moment Giant is also acquired in some key point (modules subsystem)
in order to avoid problems before the 8.0 release as module handlers could
make assumptions about it. This Giant locking should go just after
the release happens.
Please keep in mind that the public interface can be expanded in order
to provide more support, if there are really necessities at some point
and also some bugs could arise as long as the patch needs a bit of
further testing.
Bump __FreeBSD_version in order to reflect the newbus lock introduction.
Reviewed by: ed, hps, jhb, imp, mav, scottl
No answer by: ariff, thompsa, yongari
Tested by: pho,
G. Trematerra <giovanni dot trematerra at gmail dot com>,
Brandon Gooch <jamesbrandongooch at gmail dot com>
Sponsored by: Yahoo! Incorporated
Approved by: re (ksmith)
compiled into the main AMR driver. It's code that is nice to have but not
required for normal operation, and it is reported to cause problems for some
people.
After I removed all the unit2minor()/minor2unit() calls from the kernel
yesterday, I realised calling minor() everywhere is quite confusing.
Character devices now only have the ability to store a unit number, not
a minor number. Remove the confusion by using dev2unit() everywhere.
This commit could also be considered as a bug fix. A lot of drivers call
minor(), while they should actually be calling dev2unit(). In -CURRENT
this isn't a problem, but it turns out we never had any problem reports
related to that issue in the past. I suspect not many people connect
more than 256 pieces of the same hardware.
Reviewed by: kib
- Improve error handling for load operations.
- Fix a memory corruption bug when using certain linux management apps.
- Allocate all commands up front to avoid OOM deadlocks later on.
T_DIRECT filtering so that disk drives can be attached via the
pass driver. Add CAM locking. Don't mark CAM commands as SG64
since the hardware isn't designed to deal with 64-bit passthru
commands. Hopefully the bounce buffer changes that were done
for the management/ioctl interface are robust enough to handle
this deficiency for CAM as well.
instead of doing the first load with the BUS_DMA_NOWAIT flag. On 4.x with
PAE and > 4gb of RAM this proved disastrous if there weren't enough bounce
pages as amr_mapcmd() would return failure but the callback would later
fire once enough bounce pages were available and would then overwrite
another command's S/G list.
MFC after: 3 days
Submitted by: scottl (4.x version)
Reviewed by: scottl (port from 4.x to HEAD)
from the amr_linux. This simplifies the amr_linux shim and puts the
smarts into amr.c.
I tested this with 2 amr controllers in one box. It seems to work
okay with them.
The real problem was that ioctl handlers needed to call amr_wait_command()
with the list lock held. This not only solves the completion race, it also
prevents bounce buffer corruption that could arise from amr_start() being
called without the proper locks held.
Discussed with: ps
MFC After: 3 days
the completion of the command can occur before tsleep is called and
the command ends up blocking forever since the wakeup has already
been called.
Submitted by: ups
routines.
- Add or replace cpu_spinwait() with DELAY(1) to a few of the busy
loops when reading from the controller to work around firmware bugs
which can crash the controller.
This is important with MegaLib, when issuing a GET_REBUILD_PROG since
it returns an error if the drive is not in rebuild state.
This will be MFC'ed shortly.
Submitted by: ps
Reviewed by: scottl
Found by: ambrisko
1. Implement a large set of ioctl shims so that the Linux management apps
from LSI will work. This includes infrastructure to support adding, deleting
and rescanning arrays at runtime. This is based on work from Doug Ambrosko,
heavily augmented by LSI and Yahoo.
2. Implement full 64-bit DMA support. Systems with more than 4GB of RAM
can now operate without the cost of bounce buffers. Cards that cannot do
64-bit DMA will automatically revert to using bounce buffers. This option
can be forced off by setting the 'hw.amr.force_sg32" tunable in the loader.
It should only be turned off for debugging purposes. This work was sponsored
by Yahoo.
3. Streamline the command delivery and interrupt handler paths after
much discussion with Dell and LSI. The logic now closely matches the
intended design, making it both more robust and much faster. Certain
i/o failures under heavy load should be fixed with this.
4. Optimize the locking. In the interrupt handler, the card can be checked
for completed commands without any locks held, due to the handler being
implicitely serialized and there being no need to look at any shared data.
Only grab the lock to return the command structure to the free pool. A
small optimization can still be made to collect all of the completions
together and then free them together under a single lock.
Items 3 and 4 significantly increase the performance of the driver. On an
LSI 320-2X card, transactions per second went from 13,000 to 31,000 in my
testing with these changes. However, these changes are still fairly
experimental and shouldn't be merged to 6.x until there is more testing.
Thanks to Doug Ambrosko, LSI, Dell, and Yahoo for contributing towards
this.
with no associated data. Also revert previous changes that allocate off
of the stack instead of using malloc, as it's not needed. Many thanks to
LSI for investigating and fixing these problems.
Submitted by: rajeshpr @ lsil . com
- Introduce the amr_io_lock to control access to command queues, bio queues,
and the hardware.
- Eliminate the taskqueue and do all completion processing in the ithread.
- Assign a static slot number to each command instead of doing a linear
search for free slots each time a command is needed.
- Modify the interrupt handler to more closely match what Linux does, for
safety.
properly support bounce buffers and resource shortages. This allows the
driver to work properly and reliably with more than 4GB of RAM. Of the
three data paths that exist in the driver, (block, CAM, ioctl), the ioctl
path has not been well tested with these changes due to difficulty with
finding an application that uses it that actually works.
Sponsored by: The FreeBSD Foundation and FreeBSD Systems, Inc.
