preserve the upper bits of the first data byte.
While here, shorten a few nearby lines.
PR: kern/152768
Reported by: Sascha Wildner saw of online.de
Reviewed by: scottl
MFC after: 1 week
controllers. Controller, array, and drive status can be checked, basic
attributes can be changed, and arrays and spares can be created and deleted.
Controller firmware can also be flashed.
This does not replace MegaCLI, found in ports, as that is officially sanctioned
and supported by LSI and includes vastly more functionality. However, mfiutil
is open source and guaranteed to provide basic functionality, which can be
especially useful if you have a problem and can't get MegaCLI to work.
Approved by: re
Obtained from: Yahoo! Inc.
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)
modularize it so that new transports can be created.
Add a transport for SATA
Add a periph+protocol layer for ATA
Add a driver for AHCI-compliant hardware.
Add a maxio field to CAM so that drivers can advertise their max
I/O capability. Modify various drivers so that they are insulated
from the value of MAXPHYS.
The new ATA/SATA code supports AHCI-compliant hardware, and will override
the classic ATA driver if it is loaded as a module at boot time or compiled
into the kernel. The stack now support NCQ (tagged queueing) for increased
performance on modern SATA drives. It also supports port multipliers.
ATA drives are accessed via 'ada' device nodes. ATAPI drives are
accessed via 'cd' device nodes. They can all be enumerated and manipulated
via camcontrol, just like SCSI drives. SCSI commands are not translated to
their ATA equivalents; ATA native commands are used throughout the entire
stack, including camcontrol. See the camcontrol manpage for further
details. Testing this code may require that you update your fstab, and
possibly modify your BIOS to enable AHCI functionality, if available.
This code is very experimental at the moment. The userland ABI/API has
changed, so applications will need to be recompiled. It may change
further in the near future. The 'ada' device name may also change as
more infrastructure is completed in this project. The goal is to
eventually put all CAM busses and devices until newbus, allowing for
interesting topology and management options.
Few functional changes will be seen with existing SCSI/SAS/FC drivers,
though the userland ABI has still changed. In the future, transports
specific modules for SAS and FC may appear in order to better support
the topologies and capabilities of these technologies.
The modularization of CAM and the addition of the ATA/SATA modules is
meant to break CAM out of the mold of being specific to SCSI, letting it
grow to be a framework for arbitrary transports and protocols. It also
allows drivers to be written to support discrete hardware without
jeopardizing the stability of non-related hardware. While only an AHCI
driver is provided now, a Silicon Image driver is also in the works.
Drivers for ICH1-4, ICH5-6, PIIX, classic IDE, and any other hardware
is possible and encouraged. Help with new transports is also encouraged.
Submitted by: scottl, mav
Approved by: re
- Fix to ioctl path in which the length could be 0 which means
no data in/out from LSI.
- Fix to ioctl path in which the data in the sense data space
of the ioctl packet is a really a pointer to some location in
user-space. From LSI re-worked a bit by me.
- Add HW support for next gen cards from LSI.
Thanks to LSI for their support!
Submitted by: jhb, LSI
MFC after: 3 days
- Each log entry contains a text description in the "description" field of
the entry. The existing decode logic always ended up duplicating
information that was already in the description string. This made the
logs overly verbose. Now we just print out the description string.
- Add some simple parsing of the timestamp and event classes.
Reviewed by: ambrisko, scottl
MFC after: 2 weeks
- Fetch events from the controller in batches of 15 rather than a single
event at a time.
- When fetching events from the controller, honor the event class and
locale settings (via hw.mfi tunables). This also allows the firmware to
skip over unwanted log entries resulting in fewer requests to the
controller if there many unwanted log entries since the last clean
shutdown.
- Don't drop the driver mutex while decoding an event.
- If we get an error other than MFI_STAT_NOT_FOUND (basically EOF for
hitting the end of the event log) then emit a warning and bail on
processing further log entries.
Reviewed by: ambrisko, scottl
MFC after: 2 weeks
on amd64. Note the only difference is the iovec32 part so I use the
native structure for everything else.
Also I plan to MFC all the changes in -current to 7-stable and 6-stable
shortly since I've been running them. This does not include the cam
changes.
MFC after: 3 days
down some DCMD's without any data. Thanks to Dell and LSI for helping
to provide clues to figure out this problem. Now MegaCli can upgrade
the firmware and should work identical when run on Linux.
Reviewed by: scottl, LSI
MFC after: 1 day
is actually a circular log. Deal with it rolling around. Fortunately,
the log area is big and I haven't seen any roll over yet. Update and
get rid of the obsolete comment.
- Don't leak the config lock if detach() fails due to the controller char
dev being open.
- Close a race between detach() and a process opening the controller char
dev.
MFC after: 1 week
Approved by: re (bmah)
now takes a device_t to be the parent of the bus that is being created.
Most SIMs have been updated with a reasonable argument, but a few exceptions
just pass NULL for now. This argument isn't used yet and the newbus
integration likely won't be ready until after 7.0-RELEASE.
- In the ioctl path let command get queued up and return
when complete _without_ blocking the driving waiting for
the response. This way the driver doesn't "lock up" for
~30s during a flash command. Submitted by scottl.
- Add a guard so that if a DCMD of 0 is sent down the ioctl
path don't send it to the controller. Return with a
status of OK. This is a little strange since MegaCli
doesn't seem to like something and will issue some DCMD
of 0. This doesn't happen under Linux. So the emulation
needs to be improved but I'm not sure what. Another strange
thing is that when a DCMD of 0 gets issued under i386 the
controller returns OK but in amd64 the context is messed
up.
- Add a guard so the context has to be with-in the legal
limit so we get a reasonable error assertion versus random
panic.
It's going to be a challenge to figure out why MegaCli is not totally
happy and then sends some bogus commands. This means that flashing
firmware via the Linux tool won't work since it generates a DCMD of
0 when it should be opening the firmware for a flash update. Without
this problem flashing works fine. This means there is no publicly
available tool to upgrade the RAID firmware under FreeBSD right now.
I plan to MFC all of the mfi changes to 6.X shortly. This might not
include the SCSI pass-through changes.
Submitted by: scottl
Reviewed by: scottl
MFC after: 3 days
1) s/mi/mfi/ in FreeBSD ioctl path
2) add in "\n" on various failure messages
3) cap the length of time to abort an AEN command
4) fix passing sense data back to user to make Dell's Linux firmware
upgrade tool happy.
5) bump the MFI_POLL_TIMEOUT_SECS from 10s to 50s since the
firmware flash command can take ~40s to return.
This is some clean-up and enables RAID firmware to updated via Dell's
tool. Note Dell's tool requires the updates to the Linux emulator
that has been done in -current with TLS etc.
I need to discuss with scottl how to better submit mfi commands to
the firmware via the ioctl path so we don't do it in polled mode.
after calling mfi_mapcmd is no longer needed, so long as the MFI_CMD_POLLED
flag is set. This change eliminates the possibility of a polled command
getting posted twice to the driver. This is turn fixes panics on shutdown
when INVARIANTS is set.
Sponsored by: Ironport
- Add a translation so the Linux ioctl's don't conflict with
the FreeBSD definition.
- Assume Linux 32bit emulation on amd64.
This was tested on i386 and amd64 with the 32bit Linux MegaCli.
Eventually we should do a 32bit native FreeBSD translation app.
- Fix the locking protocol to eliminate races between normal I/O and AENs.
- Various small improvements and usability tweaks.
Sponsored by: IronPort
Portions Submitted by: Doug Ambrisko
