bfe_init_locked() wasn't sufficient to bring the chip back to life, it also
required a call to bfe_chip_reset() during resume.
Tested by: Stepan Zastupov +redchrom at gmail+
MFC after: 1 week
archs. [1]
- Instead of bus_space_{read,write}*(rman_get_bustag(), rman_get_bushandle())
use bus_{read,write}*() for efficiency.
Reported by: Peter Losher [1]
Tested on: i386, sparc64
MFC after: 2 weeks
made to accommodate the chip being in promiscuous mode while
offloading VLAN tag processing to the hardware. We can now
properly handle the absence of VLAN tags from hardware stripping.
Reviewed by: rwatson, andre
MFC after: 1 month
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
and provied an isp_control entry point so that the outer layers can
do PLOGI/LOGO explicitly. Add MS IOCB support. This completes the cycle
for base support for SMI-S.
This allows us to play nicely on SANs when we have target mode
enabled in f/w but have neither the scsi_targbh enabled or
scsi_targ with a target enabled.
accidentally truncating off the VLAN tag field in the TX descriptor. Fix
this by splitting up the vlan_tag and flags fields into separate fields,
and handling them appropriately.
Sponsored by: Ironport
MFC After: 3 days
descriptor's mbuf pointer to see if the transmit ring is full. The
mbuf pointer is set only in the last descriptor of a
multi-descriptor packet. By relying on the mbuf pointers of the
earlier descriptors, the driver would sometimes overwrite a
descriptor belonging to a packet that wasn't completed yet. Also,
tx_chain_prod wasn't updated inside the loop, causing the wrong
descriptor to be checked after the first iteration. The upshot of
all this was the loss of some transmitted packets at medium to high
packet rates.
In bce_tx_encap, remove a couple of old statements that shuffled
around the tx_mbuf_map pointers. These now correspond 1-to-1 with
the transmit descriptors, and they are not supposed to be changed.
Correct a couple of inaccurate comments.
MFC after: 1 month
Only complain about FC Reponse errors if they're nonzero.
Shorten some PortID printouts for local loop.
Add an internal isp_xcmd_t data structure which we'll use for some
CT-Passthru support as part of adding SMI-S.
- 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.
gone device timers and zombie state entries. There are tunables
that can be used to select a number of parameters.
loop_down_limit - how long to wait for loop to come back up before
declaring
all devices dead (default 300 seconds)
gone_device_time- how long to wait for a device that has appeared
to leave the loop or fabric to reappear (default 30 seconds)
Internal tunables include (which should be externalized):
quick_boot_time- how long to wait when booting for loop to come up
change_is_bad- whether or not to accept devices with the same
WWNN/WWPN that reappear at a different PortID as being the 'same'
device.
Keen students of some of the subtle issues here will ask how
one can keep devices from being re-accepted at all (the answer
is to set a gone_device_time to zero- that effectively would
be the same thing).
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.
Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months
our own watchdog that piggybacks on the em_local_timer() routine.
We suppose that the if_timer/if_watchdog interface should be
obsoleted, since it doesn't fit the modern SMP network stack.
NIC drivers should create their own watchdogs, that check and
clear the timers always holding driver's lock.
In collaboration with: jfv, scottl
- Only call iwi_stop() if we got far enough along in iwi_attach() to
alloc an ifnet.
- Release the firmware after stopping the interface and detaching the
ifnet.
MFC after: 1 month
Reviewed by: sam
to be switched to is saved in sc->delayed_next_scr and
the actual switch is performed later. It was possible
to get into the endless loop when attempting to switch
to a closed vty (which is not allowed and beep-alerted
when attempted) and when the visual beep was in effect.
This caused sc->delayed_next_scr to never be reset and
endless attempts to switch to a closed vty and endless
visual beeping. How to repeat:
- boot into single-user
- run "kbdcontrol -b visual"
- quickly press Alt+F2 two times
PR: kern/68016
X-MFC after: 6.2-RELEASE
specific privilege names to a broad range of privileges. These may
require some future tweaking.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
as we have no use for that info. Instead let this function return the
keyboard ID and verify at its invocation in sunkbd_configure() that we're
talking to a Sun type 4/5/6 keyboard, i.e. a keyboard supported by this
driver.
- Add an option SUNKBD_EMULATE_ATKBD whose code is based on the respective
code in ukbd(4) and like UKBD_EMULATE_ATSCANCODE causes this driver to
emit AT keyboard/KB_101 compatible scan codes in K_RAW mode as assumed by
kbdmux(4). Unlike UKBD_EMULATE_ATSCANCODE, SUNKBD_EMULATE_ATKBD also
triggers the use of AT keyboard maps and thus allows to use the map files
in share/syscons/keymaps with this driver at the cost of an additional
translation (in ukbd(4) this just is the way of operation).
- Implement an option SUNKBD_DFLT_KEYMAP, which like the equivalent options
of the other keyboard drivers allows to specify the default in-kernel
keyboard map. For obvious reasons this made to only work when also using
SUNKBD_EMULATE_ATKBD.
- Implement sunkbd_check(), sunkbd_check_char() and sunkbd_clear_state(),
which are also required for interoperability with kbdmux(4).
- Implement K_CODE mode and FreeBSD keypad compose.
- As a minor hack define KBD_DFLT_KEYMAP also in the !SUNKBD_EMULATE_ATKBD
case so we can obtain fkey_tab from <dev/kbd/kbdtables.h> rather than
having to duplicate it and #ifdef some more code.
- Don't use the TX-buffer for writing the two command bytes for setting the
keyboard LEDs as this consequently requires a hardware FIFO that is at
least two bytes in depth, which the NMOS-variant of the Zilog SCCs doesn't
have. Thus use an inlined version of uart_putc() to consecutively write
the command bytes (a cleaner approach would be to do this via the soft
interrupt handler but that variant wouldn't work while in ddb(4)). [1]
- Fix some minor style(9) bugs.
PR: 90316 [1]
Reviewed by: marcel [1]
BIO_READ/BIO_WRITE is sent to vnode-backed provider (BIO_DELETE or
BIO_FLUSH).
Reported by: ceri
Add support for BIO_FLUSH to vnode-backed md(4) devices based on
VOP_FSYNC().
- Test the mac_type rather than if_hwassist (since ifp doesn't exist yet)
to determine if the adapter supports TSO and thus to change the sizes
for the bus_dma tag.
Reviewed by: glebius
during detach() similar to other NIC drivers rather than allocating them
during init() and freeing them during stop():
- Move creation of tx bus_dma tag amd maps and tx_buffer_area from
em_setup_transmit_structures() to em_allocate_transmit_structures().
- Call em_allocate_xxx_structures() in em_attach().
- Only call em_free_xxx_structures() in em_detach().
- Change em_setup_xxx_structures() to free any existing tx or rx buffers
and in the case of rx repopulate the ring with newer buffers.
Reviewed by: jfv
the EOP descriptor in the first descriptor of the packet. And then
in em_txeof() search for DD bits set only in the EOP descriptors,
embedding the cleanup of all packet's descriptors into inner loop.
This change is important for future chips, where DD bit is going
to be set only on the EOP descriptors.
Submitted by: jfv
Details:
o if_em.c changes:
- Added several new PCI ids.
- Check em_check_phy_reset_block() before doing SIOCSIFMEDIA ioctl.
- Don't touch TARC registers, they are now handled in shared
code in if_em_hw.c.
- Move RDH and RDT setting to the end of
em_initialize_receive_unit().
- Declare em_read_pcie_cap_reg(), now empty.
o if_em_hw.c dropped in from vendor, then restored rev. 1.15.
o if_em_hw.h dropped in from vendor, then modified:
- Added RX overrun interrupt flag to interrupt enable mask.
- Remove declarations of em_io_read(), em_io_write().
Approved by: jfv
the CAM_NEW_TRAN_CODE that has been in the tree for some years now.
This first step consists solely of adding to or correcting
CAM_NEW_TRAN_CODE pieces in the kernel source tree such
that a both a GENERIC (at least on i386) and a LINT build
with CAM_NEW_TRAN_CODE as an option will compile correctly
and run (at least with some the h/w I have).
After a short settle time, the other pieces (making
CAM_NEW_TRAN_CODE the default and updating libcam
and camcontrol) will be brought in.
This will be an incompatible change in that the size of structures
related to XPT_PATH_INQ and XPT_{GET,SET}_TRAN_SETTINGS change
in both size and content. However, basic system operation and
basic system utilities work well enough with this change.
Reviewed by: freebsd-scsi and specific stakeholders
only those bars that had addresses assigned by the BIOS and where the
bridges were properly programmed. Now even unprogrammed ones work.
This was needed for sun4v. We still only implement up to 2GB memory
ranges, even for 64-bit bars. PCI standards at least through 2.2 say
that this is the max (or 1GB is, I only know it is < 32bits).
o Always define pci_addr_t as uint64_t. A pci address is always 64-bits,
but some hosts can't address all of them.
o Preserve the upper half of the 64-bit word during resource probing.
o Test to make sure that 64-bit values can fit in a u_long (true on some
platforms, but not others). Don't use those that can't.
o minor pedantry about data sizes.
o Better bridge resource reporting in bootverbose case.
o Minor formatting changes to cope with different data types on different
platforms.
Submitted by: jmg, with many changes by me to fully support 64-bit
addresses.
Though it is named after overclocking tool for ASUS motherboards,
it is not capable to change clock ratio or CPU core voltage.
This driver exports Templature, Power output voltage, Fan RPM under
dev.acpi_aiboost.0.*.
Descriptions for these values are set to sysctl describe, which can be
get by sysctl -d.
in #ifdef __NO_STRICT_ALIGNMENT rather than #ifdef __i386__. This
means that amd64 now also uses the optimized code. [1]
While at it, fix a nearby style(9) bug.
- Remove the hw.dc_quick SYSCTL, which allowed to turn off the above
mentioned optimization, as like the equivalent and already removed
- In dc_setcfg() suppress printing a warning when forcing the receiver
and transceiver to idle state times out for chips where the status
bits in question just never change (observed in detail with DM9102A)
and therefore the warning would be highly likely false positive. [2]
- In dc_ifmedia_sts() add a missing DC_UNLOCK().
Tested by: Hans-Joerg Sirtl on amd64 [1]
PR: 82681 [2]
Obtained from: NetBSD tlp(4) [2]
MFC after: 1 week
Rename MAX_SAMPLE_RATES macro to OSS_MAX_SAMPLE_RATES. The old
macro clashed with those used in other applications and libaries
(ex: RtAudio). 4Front responded by updating their spec, so we
will follow suit.
Submitted by: ryanb
Noticed by: pointyhat/kris
new device support, and it is hoped a more stable driver for 6.2. RELEASE.
This checkin was discussed and approved today by RE, scottl, jhb, and pdeuskar
keyboard is attached only after the system has already booted.
If USB keyboard is also present, and there's no kbdmux(4), the problem
has been hiding itself because as soon as we get to multi-user, the
USB keyboard becomes an active keyboard (see devd.conf), thus marking
atkbd inactive and letting the old code initialize the keyboard.
With kbdmux(4), or if there's no USB keyboard, the atkbd keyboard is
always active, whether it's physically attached or not, thus it never
initialized itself properly on a physical attach.
To fix this, move block that initialized the keyboard on attach upper
so it doesn't depend on the (KBD_IS_ACTIVE(kbd) && KBD_IS_BUSY(kbd))
condition. Also move KBD_FOUND_DEVICE() a few lines upper so that
KDSETLED and KDSETREPEAT that follow it propagate to the controller.
MFC after: 3 days
: revision 1.27
: date: 2000/05/28 12:43:24; author: ache; state: Exp; lines: +3 -2
: Manipulate with AltGR Led (really CapsLock Led) only in K_XLATE mode, because
: all other modes not set ALKED flag and it means that CapsLock always turned
: off for them.
: Real bug example is X11 which never turn on CapsLock with Russian keyboard.
:
: PR: 18651
: Submitted by: "Mike E. Matsnev" <mike@po.cs.msu.su>
MFC after: 3 days
and TCP checksum offloading fine, it only has a problem with IP checksums on
IP fragments.. Barring a fix or workaround available from the hardware, the
real solution would be to have finer grained control in the stack over what
can and cannot be assisted in hardware.
yet to be investigated circumstances. If that happens truncate to the number
of rates that the firmware supports.
Found by: Jeremie Le Hen
Obtained from: OpenBSD (w/ changes)
MFC after: 3 days
kept unused in the ring. This check should probably be moved up to
bce_start_locked at some point, as it'll make the loop up there slightly
more efficient, and will eliminate a costly set of busdma operations when
the ring is full. But this works for now.
This makes all of my UDP torture tests work. I'll cautiously say that
it might even work for other users now. Feedback is appreciated.
If the length is zero, catch this early, instead of making dflen go negative
and letting bad things happen... We also check to see if RV (checksum) is
0, and handle that has a checksum failure...
Properly handle checksum failures by not processing read-write VPD data,
and removing all the found read-only data...
Tested by: oleg (dflen going negative)
should be easily adapted to SD 2.0 (aka SDHC), SDIO, MMC and MMCplus
cards. At the present time, there's only one bridge driver for the
ARM9 based Atmel AT91RM9200.
