This bug manifested itself after repeated device arrivals and
departures. The root of the problem was that the last entry in the
reply array wasn't initialized/allocated. So every time we got
around to that event, we had a bogus address.
There were a couple more problems with the code that are also fixed:
- The reply mechanism was being treated as sequential (indexed by
sc->replycurindex) even though the spec says that the driver
should use the ReplyFrameAddress field of the post queue
descriptor to figure out where the reply is. There is no
guarantee that the reply descriptors will be used in sequential
order.
- The second word of the reply post queue descriptor wasn't being
checked in mps_intr_locked() to make sure that it wasn't
0xffffffff. So the driver could potentially come across a
partially DMAed descriptor.
- The number of replies allocated was one less than the actual
size of the queue. Instead, it was the size of the number of
replies that can be used at one time. (Which is one less than
the size of the queue.)
mps.c: When initializing the entries in the reply free
queue, make sure we initialize the full number that
we tell the chip we have (sc->fqdepth), not the
number that can be used at any one time (sc->num_replies).
When allocating replies, make sure we allocate the
number of replies that we've told the chip exist,
not just the number that can be used simultaneously.
Use the ReplyFrameAddress field of the post queue
descriptor to figure out which reply is being
referenced. This is what the spec says to do, and
the spec doesn't guarantee that the replies will be
used in order.
Put a check in to verify that the reply address passed
back from the card is valid. (Panic if it isn't, we'll
panic when we try to deference the reply pointer in any
case.)
In mps_intr_locked(), verify that the second word of the
post queue descriptor is not 0xffffffff in addition to
verifying that the unused flag is not set, so we can
make sure we didn't get a partially DMAed descriptor.
Remove references to sc->replycurindex, it isn't needed
now.
mpsvar.h: Remove replycurindex from the softc, it isn't needed now.
Reviewed by: scottl
functionality is the same, a difference is that the DS1775 has a better
precision than the LM75. But we do not use it in our setup. Make the
LM75 work the same as the DS1775.
Fix a typo in device_set_desc.
Tested by: Paul Mather <paul at gromit dlib vt edu>
Approved by: nwhitehorn (mentor)
pointer where data is to be returned by ibask() (currently unimplemented),
while __retval holds the value returned by the libgpib ibfoo() functions.
The confusion resulted in the ibfoo() functions returning an uninitialized
value except in situations where the GPIB activity has been terminated
abnormally.
MFC after: 3 days
re-arming the watchdog timeout.
Sponsored by: Sandvine Incorporated
Submitted by: Mark Johnston <mjohnston at sandvine dot com>
Reviewed by: des
MFC after: 10 days
AX88772 controllers. ASIX added a new feature for AX88178/AX88772
controllers which allows combining multiple TX frames into a single
big frame. This was to overcome one of USB limitation where it
can't generate more than 8k interrupts/sec which in turn means USB
ethernet controllers can not send more than 8k packets per second.
Using ASIX's feature greatly enhanced TX performance(more than 3~4
times) compared to 7.x driver. However it seems r184610 removed
boundary checking for buffered frames which in turn caused
instability issues under certain conditions. In addition, using
ASIX's feature triggered another issue which made USB controller
hang under certain conditions. Restarting ethernet controller
didn't help under this hang condition and unplugging and replugging
the controller was the only solution. I believe there is a silicon
bug in TX frame combining feature on AX88178/AX88772 controllers.
To address these issues, reintroduce the boundary checking for both
AX88178 and AX88772 after copying a frame to USB buffer and do not
use ASIX's multiple frame combining feature. Instead, use USB
controller's multi-frame transmit capability to enhance TX
performance as suggested by Hans[1].
This should fix a long standing axe(4) instability issues reported
on AX88772 and AX88178 controllers. While I'm here remove
unnecessary TX frame length check since upper stack always
guarantee the size of a frame to be less than MCLBYTES.
Special thanks to Derrick Brashear who tried numerous patches
during last 4 months and waited real fix with patience. Without
this enthusiastic support, patience and H/W donation I couldn't fix
it since I was not able to trigger the issue on my box.
Suggested by: hselasky [1]
Tested by: Derrick Brashear (shadow <> gmail dot com>
H/W donated by: Derrick Brashear (shadow <> gmail dot com>
PR: usb/140883
isn't configurable in a meaningful way. This is for ifconfig(8) or
other tools not to change code whenever IFT_USB-like interfaces are
registered at the interface list.
Reviewed by: brooks
No objections: gavin, jkim
looking to see if there is an existing IRQ resource for a given IRQ
provided by the BIOS and using that RID if so. Otherwise, allocate a new
RID for the new IRQ.
Reviewed by: mav (a while ago)
max_request_segments * PAGE_SIZE if the I/O is page-aligned; the
largest I/O we can guarantee will work is PAGE_SIZE less than that.
This unbreaks 'diskinfo -t'.
as an association ID is set any scan is supposed to be a background scan.
This implies that the firmware will switch back to the associated channel
after a certain threshold, though, we are not notified about that. We
currently catch this case by a timer which will reset the firmware after
a 'scan timeout', though, upper layers are not notified about that and
will simply hang until manual intervention. Fix this by resetting the
firmware's knowledge about any association on RUN -> ASSOC and
!INIT -> SCAN transitions.
Tested by: Zhihao Yuan <lichray at gmail.com>
MFC after: 1 week
- Do not call iwn_calib_reset() for monitor mode. We do not want to query
information and do runtime calibration while in monitor mode. Poking the
firmware with adjustments for calibration results in firmware asserts.
This could happened on RUN -> RUN transition only.
- Adjust blink rate for monitor mode. It's supposed to not freak out and
turn off after a while.
- While here, remove one useless assignment of calib.state, it gets
overwritten later in the function.
Submitted by: Brandon Gooch <jamesbrandongooch at gmail.com>
MFC after: 1 week
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
longer requested of the boot firmware. Instead of sending those results
to the runtime firmware the firmware is told to do the DC calibration
itself.
MFC after: 1 week
the size can be smaller than the constant when you are
doing HW TAGGING, and you still need to process this
packet in a normal way. I'm not sure where the notion
to just return came from, but its wrong.
MFC after: 3 days
Second, correct the discard/refresh_mbufs code to behave
more like igb, there have been panics due to discards and
this should fix them.
MFC after: 3 days
finding. The test to compare the mbuf m_len against
a fixed value and then returning needs to be removed.
When using VLANS and doing HW_TAGGING, and IPV6, the
ICMP6 packets actually fail this condition, the constant
assumes that the tag is IN the frame, and its not, so
the length is actually tiny. Furthermore, I'm not sure
what the point was to just return??
MFC after: 3 days
the controller to workaround silicon bug of i82557. Each reset will
re-establish link which in turn triggers MII status change
callback. The callback will try to reconfigure controller if the
controller is not i82557 to enable flow-control. This caused
endless link UP/DOWN when the workaround was enabled on non-i82557
controller.
To fix the issue, apply RX lockup workaround only for i82557.
Previously it blindly checked undocumented EEPROM location such
that it sometimes enabled the workaround for other controllers. At
this time, only i82557 is known to have the silicon bug.
This fixes a regression introduced in r215906 which enabled flow
control support for all controllers except i82557.
Reported by: Karl Denninger (karl <> denninger dot net)
Tested by: Karl Denninger (karl <> denninger dot net)
MFC after: 3 days
or detached. Normally it should be changed through user land ioctl(2)
system calls but it looks there's no apps for USB and no need.
With this patch, libpcap would detect the usbus interfaces correctly and
tcpdump(1) could dump the USB packets into PCAP format with -w option.
However it couldn't print the output to console because there's no
printer-routine at tcpdump(1).
This includes support in the kernel, camcontrol(8), libcam and the mps(4)
driver for SMP passthrough.
The CAM SCSI probe code has been modified to fetch Inquiry VPD page 0x00
to determine supported pages, and will now fetch page 0x83 in addition to
page 0x80 if supported.
Add two new CAM CCBs, XPT_SMP_IO, and XPT_GDEV_ADVINFO. The SMP CCB is
intended for SMP requests and responses. The ADVINFO is currently used to
fetch cached VPD page 0x83 data from the transport layer, but is intended
to be extensible to fetch other types of device-specific data.
SMP-only devices are not currently represented in the CAM topology, and so
the current semantics are that the SIM will route SMP CCBs to either the
addressed device, if it contains an SMP target, or its parent, if it
contains an SMP target. (This is noted in cam_ccb.h, since it will change
later once we have the ability to have SMP-only devices in CAM's topology.)
smp_all.c,
smp_all.h: New helper routines for SMP. This includes
SMP request building routines, response parsing
routines, error decoding routines, and structure
definitions for a number of SMP commands.
libcam/Makefile: Add smp_all.c to libcam, so that SMP functionality
is available to userland applications.
camcontrol.8,
camcontrol.c: Add smp passthrough support to camcontrol. Several
new subcommands are now available:
'smpcmd' functions much like 'cmd', except that it
allows the user to send generic SMP commands.
'smprg' sends the SMP report general command, and
displays the decoded output. It will automatically
fetch extended output if it is available.
'smppc' sends the SMP phy control command, with any
number of potential options. Among other things,
this allows the user to reset a phy on a SAS
expander, or disable a phy on an expander.
'smpmaninfo' sends the SMP report manufacturer
information and displays the decoded output.
'smpphylist' displays a list of phys on an
expander, and the CAM devices attached to those
phys, if any.
cam.h,
cam.c: Add a status value for SMP errors
(CAM_SMP_STATUS_ERROR).
Add a missing description for CAM_SCSI_IT_NEXUS_LOST.
Add support for SMP commands to cam_error_string().
cam_ccb.h: Rename the CAM_DIR_RESV flag to CAM_DIR_BOTH. SMP
commands are by nature bi-directional, and we may
need to support bi-directional SCSI commands later.
Add the XPT_SMP_IO CCB. Since SMP commands are
bi-directional, there are pointers for both the
request and response.
Add a fill routine for SMP CCBs.
Add the XPT_GDEV_ADVINFO CCB. This is currently
used to fetch cached page 0x83 data from the
transport later, but is extensible to fetch many
other types of data.
cam_periph.c: Add support in cam_periph_mapmem() for XPT_SMP_IO
and XPT_GDEV_ADVINFO CCBs.
cam_xpt.c: Add support for executing XPT_SMP_IO CCBs.
cam_xpt_internal.h: Add fields for VPD pages 0x00 and 0x83 in struct
cam_ed.
scsi_all.c: Add scsi_get_sas_addr(), a function that parses
VPD page 0x83 data and pulls out a SAS address.
scsi_all.h: Add VPD page 0x00 and 0x83 structures, and a
prototype for scsi_get_sas_addr().
scsi_pass.c: Add support for mapping buffers in XPT_SMP_IO and
XPT_GDEV_ADVINFO CCBs.
scsi_xpt.c: In the SCSI probe code, first ask the device for
VPD page 0x00. If any VPD pages are supported,
that page is required to be implemented. Based on
the response, we may probe for the serial number
(page 0x80) or device id (page 0x83).
Add support for the XPT_GDEV_ADVINFO CCB.
sys/conf/files: Add smp_all.c.
mps.c: Add support for passing in a uio in mps_map_command(),
so we can map a S/G list at once.
Add support for SMP passthrough commands in
mps_data_cb(). SMP is a special case, because the
first buffer in the S/G list is outbound and the
second buffer is inbound.
Add support for warning the user if the busdma code
comes back with more buffers than will work for the
command. This will, for example, help the user
determine why an SMP command failed if busdma comes
back with three buffers.
mps_pci.c: Add sys/uio.h.
mps_sas.c: Add the SAS address and the parent handle to the
list of fields we pull from device page 0 and cache
in struct mpssas_target. These are needed for SMP
passthrough.
Add support for the XPT_SMP_IO CCB. For now, this
CCB is routed to the addressed device if it supports
SMP, or to its parent if it does not and the parent
does. This is necessary because CAM does not
currently support SMP-only nodes in the topology.
Make SMP passthrough support conditional on
__FreeBSD_version >= 900026. This will make it
easier to MFC this change to the driver without
MFCing the CAM changes as well.
mps_user.c: Un-staticize mpi_init_sge() so we can use it for
the SMP passthrough code.
mpsvar.h: Add a uio and iovecs into struct mps_command for
SMP passthrough commands.
Add a cm_max_segs field to struct mps_command so
that we can warn the user if busdma comes back with
too many segments.
Clear the cm_reply when a command gets freed. If
it is not cleared, reply frames will eventually get
freed into the pool multiple times and corrupt the
pool. (This fix is from scottl.)
Add a prototype for mpi_init_sge().
sys/param.h: Bump __FreeBSD_version to 900026 for the for the
inclusion of the XPT_GDEV_ADVINFO and XPT_SMP_IO
CAM CCBs.
versions of FreeBSD. In fact we are already missing a lot of conditional
code necessary to support older versions of FreeBSD, including alternatives
for vital functionality not yet provided by the respective subsystem back
then (see for example r199663). So this change shouldn't actually break
this driver on versions of FreeBSD that were supported before. Besides,
this driver also isn't maintained as an multi-release version outside of
the main repository, so removing the conditional code shouldn't be a
problem in that regard either.
- Sprinkle some more const on tables.
hence existing applications like webcamd are expecting that.
This problem was introduced by SVN change 214221 where cdev=
was replaced by ugen= by accident. Solve this problem by
redefining cdev= in devd notifications.
MFC after 3 days.
Approved by: thompsa (mentor)
i.e. alignment, max_address, max_iosize and segsize (only max_address is
thought to have an negative impact regarding this issue though), after
calling ata_dmainit() either directly or indirectly so these values have
no effect or at least no effect on the DMA tags and the defaults are used
for the latter instead. So change the drivers to set these parameters
up-front and ata_dmainit() to honor them.
Reviewd by: mav
MFC after: 1 month
