from ATAPI requests. If CAM debugging is enabled, also mark ATAPI
requests with ATA_R_DEBUG flag.
(atapi_cb): Report ATAPI timeouts to the CAM layer.
Fix incorrect debugging traces in the presence of ATAPI errors.
PR: kern/103602
MFC after: 2 weeks
CAM rescan if the ATAPI device entries have not changed.
The ATAPI bus may be reset for a variety of reasons, including any time an
ATAPI request times out. It is not necessary to rescan at the CAM level
in such a case, unless a device has appeared or disappeared, or has
otherwise changed.
PR: kern/103602
MFC after: 2 weeks
ATAPI request, do not clear the ATA_R_DEBUG flag. This allows a request
marked as requiring debug traces to produce these traces also during
the completion of the autosense processing.
Reviewed by: sos
MFC after: 2 weeks
tokens into the common isp_osinfo structure instead of being
in bus specific structures. This allows us to implement
a SYNC_REG MEMORYBARRIER call (using bus_space_barrier)
and also reduce the amount of bus specific wrapper structure
usages in isp_pci && isp_sbus.
MFC after: 3 days
their latest Compaq V3000 BIOS (revision F.22). As a result, analog CD
connectivity is gone to the oblivion. Even if they decide to fix it in
future revisions, the damage has been done.
excessive interrupt clock timer reset, screwing interrupt generation
for already active channels. Track moving DMA pointer and call buffer
interrupt on each blocksize boundary.
PR: kern/109791
MFC after: 3 days
- Remove some excessive parentheses around shift operators.
- Use macro instead of magic number where it is applicable.
- Change lower-case hexdecimals to upper cases to match wpaul's style.
- Revert some unnecessary line wraps and changes from the previous commit.
Pointed out by: bde
sun4v nexus(4) in turn is based on):
o Change nexus(4) to manage the resources of its children so the
respective device drivers don't need to figure them out of OFW
themselves.
o Change nexus(4) to provide the ofw_bus KOBJ interface instead of
using IVARs for supplying the OFW node and the subset of standard
properties of its children. Together with the previous change this
also allows to fully take advantage of newbus in that drivers like
fhc(4), which attach on multiple parent busses, no longer require
different bus front-ends as obtaining the OFW node and properties
as well as resource allocation works the same for all supported
busses. As such this change also is part 4/4 of allowing creator(4)
to work in USIII-based machines as it allows this driver to attach
on both nexus(4) and upa(4). On the other hand removing these IVARs
breaks API compatibility with the powerpc nexus(4) but which isn't
that bad as a) sparc64 currently doesn't share any device driver
hanging off of nexus(4) with powerpc and b) they were no longer
compatible regarding OFW-related extensions at the pci(4) level
since quite some time.
o Provide bus_get_dma_tag methods in nexus(4) and its children in
order to handle DMA tags in a hierarchical way and get rid of the
sparc64_root_dma_tag kludge. Together with the previous two items
this changes also allows to completely get rid of the nexus(4)
IVAR interface. It also includes:
- pushing the constraints previously specified by the nexus_dmatag
down into the DMA tags of psycho(4) and sbus(4) as it's their
IOMMUs which induce these restrictions (and nothing at the
nexus(4) or anything that would warrant specifying them there),
- fixing some obviously wrong constraints of the psycho(4) and
sbus(4) DMA tags, which happened to not actually be used with
the sparc64_root_dma_tag kludge in place and therefore didn't
cause problems so far,
- replacing magic constants for constraints with macros as far
as it is obvious as to where they come from.
This doesn't include taking advantage of the newbus way to get
the parent DMA tags implemented by this change in order to divorce
the IOTSBs of the PCI and SBus IOMMUs or for implementing the
workaround for the DMA sync bug in Sabre (and Tomatillo) bridges,
yet, though.
o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus
by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied
from ofw_upa.h) and renaming its content, which actually applies to
all of Fireplane/Safari, JBus and UPA (in the host bus case), as
appropriate.
o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for
allocating the device info for the children of nexus(4). This is
done in order to not need to export M_NEXUS when deriving drivers
for subordinate busses from the nexus(4) class.
o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so
we can derive subclasses from it.
o Const'ify the nexus_excl_name and nexus_excl_type arrays as well
as add 'associations' and 'rsc', which are pseudo-devices without
resources and therefore of no real interest for nexus(4), to the
former.
o Let the nexus(4) device memory rman manage the entire 64-bit address
space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as
Fireplane/Safari- and JBus-based machines use multiple ranges,
which can't be as easily divided as in the case of UPA (limiting
the address space only served for sanity checking anyway).
o Use M_WAITOK instead of M_NOWAIT when allocating the device info
for children of nexus(4) in order to give one less opportunity
for adding devices to nexus(4) to fail.
o While adapting the drivers affected by the above nexus(4) changes,
change them to take advantage of rman_get_rid() instead of caching
the RIDs assigned to allocated resources, now that the RIDs of
resources are correctly set.
o In iommu(4) and nexus(4) replace hard-coded functions names, which
actually became outdated in several places, in panic strings and
status massages with __func__. [1]
o Use driver_filter_t in prototypes where appropriate.
o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and
sbus(4) as I changed considerable amounts of these drivers as well
as added a bunch of new features, workarounds for silicon bugs etc.
o Fix some white space nits.
Due to lack of access to Exx00 hardware, these changes, i.e. central(4)
and fhc(4), couldn't be runtime tested on such a machine. Exx00 are
currently reported to panic before trying to attach nexus(4) anyway
though.
PR: 76052 [1]
Approved by: re (kensmith)
never correct as CAM has no real understanding of it, and will just immediately
retry the command. This leads to undesirable cycling of the camisr as well as
a high possibility for the command to exhaust its retries before the driver
can get around to servicing it.
The better fix, as demonstrated here, is to freeze the simq and mark the
command as needing to be tried. Then when driver can service the command,
the simq gets unfrozen. This is correct, and documented here to help reduce
the mystery. However, it also points out a shortcoming in CAM error handling
that makes writing drivers harder.
Submitted by: Erich Chen
for processing frames from the power save queue when operating
in ap mode. This is especially noticeable for realtime data going
to devices like voip phones.
Submitted by: "J.R. Oldroyd" <jr@opal.com>
MFC after: 2 weeks
EC occasionally times out and provides bogus values (3000C). This change
prevents those systems from prematurely shutting down while we work on the
underlying problem. Also, bump the sanity value to 0...200C from 0...150C.
Add some comments to explain how 10 was picked. 20 was completely
arbitrary, at least 10 has some reasoning behind it.
Also, update the comments about how long we sleep to reflect the new,
shorter timeout we use.
If these drivers are setting M_VLANTAG because they are stripping the
layer 2 802.1Q headers, then they need to be re-inserting them so any
bpf(4) peers can properly decode them.
It should be noted that this is compiled tested only.
MFC after: 3 weeks
to a READ_CAPACITY request rather than the maximum sector (off by one
problem). This causes a huge cascade of errors as the geom tasting
code tries to read the last sector (which isn't really there in the
face of this error). automated tools that manipulate disk labels and
such also have issues.
Create a new quirk READ_CAPACITY_OFFBY1 and add a quirk for the
SanDISK ImageMate that I have that suffers from this problem (the
SDDR-31). It intercepts the READ_CAPACITY response and adjusts it
from number of sectors to max sector for devices with this quirk.
Reading the Linux source suggests that there are a host of
other devices with this issue, including iPods and some popular
cameras. I've not added quirks for them, since I don't have the
devices in front of me to test.
it is initialized; use path instead.
This change fixes a panic when using atapicam in conjunction with CAMDEBUG,
which has been described under kern/103602.
Thanks to Josh Carroll <josh.carroll@gmail.com> for providing the traces
that allowed identifying this problem.
PR: kern/103602
MFC after: 1 week
case where it asynchronously exits burst mode on its own. Handle different
values of hz in sleep loop. Provide more debugging options to tune EC
behavior. These tunables/sysctls may be temporary and are not for user
access if the EC is working properly. Burst mode is now on by default for
testing and the poll interval has been increased from 100 to 500 us and
total timeout from 100 to 500 ms.
Hopefully this should be the first step of addressing reports of timeout
errors during battery or thermal access, especially on HP/Compaq laptops.
It is reasonably stable and should not cause a loss of functionality or
performance on systems that were previously working. Testing shows an
increase of responsiveness by ~75% on one system.
PR: kern/98171
(external) microphone pin tend to screw it. Internal microphone (found
on several laptops) still need high VRef.
Tested by: Pietro Cerutti <pietro.cerutti@gmail.com>
lenix <irc.freenode.net>
an ICB. This shows up on card restarts, and usually for
2200-2300 cards. What happens is that we start up,
attempting to acquire a hard address. We end up instead
being an F-port topology, which reports out a loop id
of 0xff (or 0xffff for 2K Login f/w). Then, if we restart,
we end up telling the card to go off an acquire this loop
address, which the card then rejects. Bah.
Compilation fixes from Solaris port.
changes. This should ease the job of maintaining codebase since much
of the regression tests are done across os versions.
- bus_setup_intr() -> snd_setup_intr().
triggers a KASSERT) or local variables. In the case of kern_ndis, the
tsleep() actually used a common sleep address (curproc) making it
susceptible to a premature wakeup.
Use bus_get_dma_tag() to obtain the parent DMA tag to make the drivers
a little bit more non-ia32/amd64 friendly.
There is no man page for bus_get_dma_tag, so this is modelled after
rev. 1.62 of src/sys/dev/sound/pci/es137x.c by marius.
Inspired by: commit by marius
attachment of new devices that arrive (and we notice them
via async Fibre Channel events). We've always had the
right thing (of sorts) happen when devices go away- this
is the corollary function that makes multipath failover
actually work.
MFC after: 2 weeks
early, we haven't set board type, so we can't correctly check for
some options. Fix this by splitting option setting/getting into
generic, pci and then later board specific, option setting/getting.
This was noticed when setting 'iid' (or 'hard loop id') didn't work
all of a sudden.
Noticed by: Mike Drangula (thanks!) via Jung-uk Kim (thanks!)
addition of SerDes support. According to the docs, the 5706C and 5708C
phys are supposed to use the same MII model that is separate from the
SerDes parts, but the 5706C actually uses the MII model of the SerDes
parts. To fix this, readd the old 5706C entry to miidevs and add a
special check in brgphy_probe() for phys that match the 5706C ID. If
the phy is supported by the gentbi(4) driver, then it's a SerDes phy, so
we fail the probe and let gentbi(4) grab it. Otherwise, it's a 5706C phy,
so we let brgphy(4) grab it.
In coordination with: dwhite
treated as multicast frames and filtered, but when only when "adopting"
running firmware. By "adopting", I mean using pre-existing firmware
loaded from eeprom at PCI reset, rather than firmware loaded by the
driver.
non consecutively numbered ports.
This should fix current SATA problems.
Support AHCI chips where the ports are not consecutively numbered as in
some incarnations of the ICH8 chip.
and make it print under debug.iwi control same as other debugging stuff.
Remove the device_printf() in iwi_ioctl() and replace with this:
/*
* wait until pending iwi_cmd() are completed, to avoid races
* that could cause problems.
*/
while (sc->flags & IWI_FLAG_BUSY)
msleep(sc, &sc->sc_mtx, 0, "iwiioctl", hz);
This at least prevents what has become an almost systematic failure for my
system, presumably due to a previous iwi_cmd() not complete yet by the
time iwi_ioctl() is called.
It has been pointed to my attention that the real problem could be
calling ieee80211_ioctl() with the lock held. If that is true,
there might still be a possibility for a race condition e.g. an
interrupt coming while the ioctl is sleeping.
Need to investigate further on what changes are required to release
the lock before calling ieee80211_ioctl
+ do not release the dma-ble region used for downloading firmware.
This should fix the problems that some people were seeing, due to
memory becoming too fragmented which prevented subsequent allocations
of a suitable contiguous region of memory;
+ document the firmware format and usage in if_iwivar.h
+ use a loop to allocate the four tx rings, instead of replicating
the body of the loop.
+ add debugging code IWI_LOCK_ASSERT() to detect missing locks.
These only do a printf, and should go away once we figure out why
the driver sometimes freezes the system due to a (yet unidentified)
race condition.
+ add a device_printf() in iwi_ioctl() in certain conditions
(see comment in the code). This helps preventing the race condition
mentioned above, and makes the system survive. This printf will
also go away once fixing this bug is completed.
+ change iwi_getfw() to return 0 on success, 1 on error, consistently
with other functions.
+ fix the argument of a sizeof() in iwi_get_firmware()
+ use le32toh() to access little-endian fields
+ simplify error handling in iwi_load_firmware() and iwi_init_locked()
The bugs fixed by this commit (the freezing one especially) are serious
enough to call for a quick MFC
MFC after: 3 days
(1) change debounce period from 1s to 250ms. This appears to be fine and
speeds things up a little.
(2) In the middle of cbb_pcic_power_disable_socket we write 0 to the EXCA_INTR
register to put the card into reset. However, this turns off CSC
interrupts for TI bridges (and maybe others). So no further card
insertion events would be noticed. To compensate, after we've gone
through the entire power down sequence, turn on EXCA_INTR_ENABLE so
that CSC events happen.
#2 should fix the 'dead slot' problem that has been reported after
card ejection (but only 16-bit cards).
a version that i posted earlier on the -current mailing list,
and subsequent feedback received.
The core of the change is just in sys/firmware.h and kern/subr_firmware.c,
while other files are just adaptation of the clients to the ABI change
(const-ification of some parameters and hiding of internal info,
so this is fully compatible at the binary level).
In detail:
- reduce the amount of information exported to clients in struct firmware,
and constify the pointer;
- internally, document and simplify the implementation of the various
functions, and make sure error conditions are dealt with properly.
The diffs are large, but the code is really straightforward now (i hope).
Note also that there is a subtle issue with the implementation of
firmware_register(): currently, as in the previous version, we just
store a reference to the 'imagename' argument, but we should rather
copy it because there is no guarantee that this is a static string.
I realised this while testing this code, but i prefer to fix it in
a later commit -- there is no regression with respect to the past.
Note, too, that the version in RELENG_6 has various bugs including
missing locks around the module release calls, mishandling of modules
loaded by /boot/loader, and so on, so an MFC is absolutely necessary
there. I was just postponing it until this cleanup to avoid doing
things twice.
MFC after: 1 week
device pointers. They don't change as the children device drivers
come and go. Rather, check to see if the device is attached where we
would have checked ! NULL. This solves many asymmetries in the code
that likely could lead to crashes when loading/unloading cbb without
one or more of the expected children's driver not present.
o When detaching all children, try really hard to get all the children
list before giving up. This is based on an observation by hans petter
selasky in his usb p4 branch.
o When rescanning devices after a driver is added, abort if we can't get
the child list with a message.
o when rescanning devices, if the reprobe/attach is successful, save the
device for cardbus/pccard.
Unlike other GigEs Yukon II always set VLAN bit when it detects VLAN
tagged packet regardless of H/W VLAN processing configuration state.
So it need to check IFCAP_VLAN_HWTAGGING bit to know whether driver
is configured to take advantage of H/W VLAN processing. If H/W VLAN
processing was disabled don't adjust received packet length such that
subsequent validation logic works for software VLAN processing.
Reported by: bms
Tested by: bms
blacklist a bunch of old chipsets. If a system contains a PCI-PCI bridge
that supports PCI-X, assume the chipset supports PCI-X. If a system
contains a PCI-express root port, assume the chipset supports PCI-express.
If the chipset doesn't support either PCI-X or PCI-express, then blacklist
it by default. We should now only need to explicitly blacklist PCI-X or
PCI-express chipsets that don't properly handle MSI.
broke the method as all the MSI-X table indices were off by one in
the backend MD code.
- Fix a cosmetic nit in the bootverbose printf in pci_alloc_msix_method().
Bugfix for the Realtek PHY driver... an RTL8201L standalone PHY
needs different handling than the integrated ones in terms of
speed detection. There was a bogus test based on the parent
device driver name string controlling which speed register to
query. That test began failing when the rl driver was split into
separate rl and re drivers some time ago. Apparently nobody ever
noticed because the buggy code only executes if NWAY negotiation
failed. Since we happen to be testing with an ancient dumb hub
rather than a modern switch, we found it.
To fix it all, have the attach() routine notice whether we're
dealing with an integrated PHY or an RTL8201L and store that info
in a struct accessible to the status() routine that needs to know
which register to query.
I touched up the fixes because they were relative to RELENG_6 and to
bring a few nits into line with style(9).
MFC After: 2 weeks
Submitted by: Ian Lepore
tunable allowing automatic parsing of VPD data to be disabled. The
default is left as-is; if you are having problems with hard hangs at boot
due to VPD, try setting hw.pci.enable_vpd=0. A proper architectural
solution has been under discussion for some time, but this allows me to
boot my test machines in the mean time.
Submitted by: bz
Head nod: jmg
The patch from the PR was a little outdated w/regards to the
Vodafone vendor string.
PR: kern/106033
Submitted by: Volker Werth <volker_AT_vwsoft.com>
MFC in: 3 days
to set_controller_command_byte() call; by issueing a Read Mode Byte
command, the touchpad is in Absolute Mode again.
This problem occursed at least on Asus V6V laptops.
approval, change the copyright statement to point at him instead of
"FreeBSD, Inc".
Encouraged by: rwatson
Reviewed by: imp
Discussed with and approved by: orion
description here. The fix in the PR isn't necessary at all for memory
leaks, but we weren't setting the device description.
While I'm here, remove some of the obfuscating macros in attach.
PR: 108719
PR/108719, but there's a simpler fix: free it after it is used, and
then get rid of the redundant frees this causes. Other leaks in this
PR not yet fixed.
While I'm here, remove NetBSD/OpenBSD code and some of the portability
#defines that were getting in the way of understanding this code. The
devinfo bug was harder to spot because one needed to know that
device_set_desc_copy() was used inside of one of them (one that didn't
take an argument!).
Prefer device_printf(sc->sc_dev, "...") to printf("%s:...",
device_get_nameunit(sc->sc_dev)). This saves almost 300 bytes.
PR: 108719
Submitted by: Antoine Brodin
/usr/share/examples/etc/bsd-style-copyright. I've fixed a
few minor wording and formatting differences.
Approved by: luigi, Hannu Savolainen <hannu@opensound.com>
buffer resizing, etc.) that was here since eon. Free all (unmanaged)
allocated buffer through sndbuf_destroy() in case we forgot to call
sndbuf_free(). For a managed buffer (mostly hw specific managed buffer),
either provide CHANNEL_FREE() method with appropriate return value to
invoke semi-automatic sndbuf_free() or simply do it on their own. If
everything is failed, sndbuf_destroy() will come to the rescue as a
final measure.
MFC after: 3 days
for pci_cfg_restore() to be exported. It was tested using a
hackily accessed pci_cfg_restore().
- Add ifmedia_removeall() to mxge_detach() in order to stop leaking
an ifaddr
- Fix a small acounting bug introduced by the locking code shuffle
which could cause spurious watchdog resets now that we have a
watchdog.
Sponsored by: Myricom
locking in preparation for adding a watchdog handler (callouts must
not use sleepable locks). This required shuffling memory and
interrupt allocation to the attach routine rather than if_ioctl so as
to avoid potential sleeps while bringing up the interface.
- initialize ifq_drv_maxlen correctly
- mark the interface as jumbo capable
- keep stats on the number of times the hw transmit queue filled and
was restarted.
/usr/share/examples/etc/bsd-style-copyright. I've fixed a
few minor wording and formatting differences.
Approved by: matk, Hannu Savolainen <hannu@opensound.com>
Reviewed by: imp
unsolicited pin sense event and need manual control to turn off speaker
volume while attaching headphone.
Tested by: Ingeborg Hellemo <Ingeborg.Hellemo@cc.uit.no>
Disable global Acer + ALC883 headphone automute settings since there are
few models that does not respect this and causing broken behaviour.
Reported/Tested by: Pavel Argentov <argentoff@rtelekom.ru>
When the disk has an error, it will now print SMART
instead of 'Unknown CMD'.
PR: kern/93368
Submitted by: Garry Belka <garry at NetworkPhysics dot COM>
Approved by: sos
blade systems, such as the Dell 1955 and the Intel SBXD132.
Development hardware for this work was provided by Broadcom and iXsystems.
A SBXD132 blade for testing was provided by Iron Systems.
apparently be confused by short TCP segments that have been manually
padded to the minimum ethernet frame size. The driver does short frame
padding in software as a workaround for a bug in the 8169 PCI devices
that causes short IP fragments to be corrupted due to an apparent
conflict between the hardware autopadding and hardware IP checksumming.
To fix this, we avoid software padding for short TCP segments, since
the hardware seems to autopad and checksum these correctly (even the
older 8169 NICs get these right). Short UDP packets appear to be
handled correctly in all cases. This should work around the IP header
checksum bug in the 8169 while not tripping the TCP checksum bug in
the 8111B/8168B and 8101E.
addresses shall access invalid descriptor DMA addresses on PCIe
hardwares and then panicked the system.
To fix it set descriptor DMA addresses before enabling Tx and Rx
such that hardware can see valid descriptor DMA addresses. Also
set RL_EARLY_TX_THRESH before starting Tx and Rx.
Reported by: steve.tell AT crashmail DOT de
Tested by: steve.tell AT crashmail DOT de
Obtained from: NetBSD
MFC after: 1 week
- First off, device drivers really do need to know if they are allocating
MSI or MSI-X messages. MSI requires allocating powerof2() messages for
example where MSI-X does not. To address this, split out the MSI-X
support from pci_msi_count() and pci_alloc_msi() into new driver-visible
functions pci_msix_count() and pci_alloc_msix(). As a result,
pci_msi_count() now just returns a count of the max supported MSI
messages for the device, and pci_alloc_msi() only tries to allocate MSI
messages. To get a count of the max supported MSI-X messages, use
pci_msix_count(). To allocate MSI-X messages, use pci_alloc_msix().
pci_release_msi() still handles both MSI and MSI-X messages, however.
As a result of this change, drivers using the existing API will only
use MSI messages and will no longer try to use MSI-X messages.
- Because MSI-X allows for each message to have its own data and address
values (and thus does not require all of the messages to have their
MD vectors allocated as a group), some devices allow for "sparse" use
of MSI-X message slots. For example, if a device supports 8 messages
but the OS is only able to allocate 2 messages, the device may make the
best use of 2 IRQs if it enables the messages at slots 1 and 4 rather
than default of using the first N slots (or indicies) at 1 and 2. To
support this, add a new pci_remap_msix() function that a driver may call
after a successful pci_alloc_msix() (but before allocating any of the
SYS_RES_IRQ resources) to allow the allocated IRQ resources to be
assigned to different message indices. For example, from the earlier
example, after pci_alloc_msix() returned a value of 2, the driver would
call pci_remap_msix() passing in array of integers { 1, 4 } as the
new message indices to use. The rid's for the SYS_RES_IRQ resources
will always match the message indices. Thus, after the call to
pci_remap_msix() the driver would be able to access the first message
in slot 1 at SYS_RES_IRQ rid 1, and the second message at slot 4 at
SYS_RES_IRQ rid 4. Note that the message slots/indices are 1-based
rather than 0-based so that they will always correspond to the rid
values (SYS_RES_IRQ rid 0 is reserved for the legacy INTx interrupt).
To support this API, a new PCIB_REMAP_MSIX() method was added to the
pcib interface to change the message index for a single IRQ.
Tested by: scottl
sparc64 GENERIC and the sound device drivers known working on sparc64
to use bus_get_dma_tag() to obtain the parent DMA tag so we can get rid
of the sparc64_root_dma_tag kludge eventually. Except for ath(4), sk(4),
stge(4) and ti(4) these changes are runtime tested (unless I booted up
the wrong kernels again...).
These are shared-memory variants based on Am79C90-compatible chips
that apart from the missing DMA engine are similar to the 'ledma'
variant including using a (pseudo-)bus/device for the buffer that
the actual LANCE device hangs off from. The performance of these is
close to that of the 'ledma' one, like expected at a few times the
CPU load though.
unlike documented may not take effect without an initialization. So
don't invoke (*sc_mediachange) directly in lance_mediachange() but
go through lance_init_locked(). It's suboptimal to impose this for
all chips but given that besides the affected PCI bus front-end the
only other front-end which supports media selection is and likely
ever will be the 'ledma' front-end I see not enough reason to break
the in-driver API for this (though one could argue both ways here).
front of isp_init so we can read NVRAM even if we're role ISP_NONE.
Prepare for reintroduction of channels (for FC) for N-Port
Virtualization.
Fix a botch in handle assignment that caused us to nuke one device
when a new one arrives and end up with two devices with the same
identity in the virtual target mapping table.
ifmedia_init() invocation. IFM_IMASK makes only sense here when all of
the maxium of 32 PHYs on each one MII bus support disjoint sets of media,
which generally isn't the case (though it would be nice if we had a way
to let NIC drivers indicate that for the few card models where the PHY
configuration is known/fixed and IFM_IMASK actually makes sense).
- Add and use a miibus_print_child() for the bus_print_child method which
additionally prints the PHY number (which actually is the PHY address)
so one can figure out the media instance <-> PHY number mapping from the
PHY driver attach output. This is intented to be usefull in situations
where the addresses of the PHYs on the bus are known (f.e. of internal/
integrated PHYs) so one can feed the appropriate media instance number
to ifconfig(8) (with the upcoming change for ifconfig(8)).
This is more or less inspired by the NetBSD mii_print().
multiple PHYs. In case some PHYs currently driven by ukphy(4) exhibit
problems when isolating due to incomplete implementations or silicon bugs
we'll need to add specific drivers for these. Looking at NetBSD and
OpenBSD I don't expect problems here though (quite the contrary; we still
seem to set MIIF_NOISOLATE without good reason in a bunch of PHY drivers).
- Fix a style(9) whitespace nit.
capability rather than hardcoded offsets for a particular card. While
I'm here, expand the constants some.
- Change the ahd(4) driver to use pci_find_extcap() to locate the PCI-X
capability to keep up with the first change.
Reviewed by: scottl, gibbs (earlier version)
that can be used to check whether receive data is ready, i.e. whether
the subsequent call of uart_poll() should return a char, and unlike
uart_poll() doesn't actually receive data.
- Remove the device-specific implementations of uart_poll() and implement
uart_poll() in terms of uart_getc() and the newly added uart_rxready()
in order to minimize code duplication.
- In sunkbd(4) take advantage of uart_rxready() and use it to implement
the polled mode part of sunkbd_check() so we don't need to buffer a
potentially read char in the softc.
- Fix some mis-indentation in sunkbd_read_char().
Discussed with: marcel
the newly added DEV_EISA. This is done so that these back-ends can
be compiled on platforms not providing in{b,w,l}()/out{b,w,l}() and
friends (but may wish to use them together with bus front-ends other
than the EISA one).
total size of all input reports is < 6.
PR: usb/106435
Submitted by: Eygene Ryabinkin <rea-fbsd@codelabs.ru>
Approved by: emax (mentor)
MFC after: 3 days
The separate bus front-end was inherited from the OpenBSD creator(4),
which at that time had a mainbus(4) (for USI/II machines, which use
an UPA interconnection bus as the nexus) and an upa(4) (for USIII
machines, which use a subordinate/slave UPA bus hanging off from the
Fireplane/Safari interconnection bus) front-end. With FreeBSD and
newbus there is/will be no need to have two separate bus front-ends
for these busses, so we can easily coallapse the shared front-end
and the back-end into a single source file (note that the FreeBSD
creator_upa.c was misnomer anyway; based on what it actually attached
to that should have been creator_nexus.c), actually OpenBSD meanwhile
also has moved to a shared front-end and a single source file. Due
to the low-level console support creator.c also wasn't free from bus
related things before.
While at it, also split sys/sparc64/creator/creator.h into a
sys/dev/fb/creatorreg.h that only contains register macros and move
the structures to the top of sys/dev/fb/creator.c as suggested by
style(9) so creator(4) is no longer scattered over two directories.
- Use OF_decode_addr()/sparc64_fake_bustag() to obtain the bus tags and
handles for the low-level console support instead of hardcoding
support for AFB/FFB hanging off from nexus(4) only. This is part 2/4
of allowing creator(4) to work in USIII machines (which have a UPA
bus hanging off from the Fireplane/Safari bus reflected by the nexus),
which already makes it work as the low-level console there.
- Allocate resources in the bus attach routine regardless of whether
creator(4) is used as for the low-level console and thus the required
bus tags and handles have been already obtained or not so the resources
are marked as taken in the respective RMAN.
- For both obtaining the bus tags and handles for the low-level console
support as well as allocating the corresponding resources in the
regular bus attach routine don't bother to get all for the maximum of
24 register banks but only (for) the two tag/handle pairs required for
providing the video interface for syscons(4) support. If we can't
allocate the rest of them just limit the memory range accessible via
creator_fb_mmap() accordingly.
- Sanity check the memory range spanned by the first and last resources
and the resources in between as far as possible, as the XFree86/Xorg
sunffb(4) expects to be able to access the whole region, even though
the backing resources are actually non-continuous. Limit and check
the memory range accessible via creator_fb_mmap() accordingly.
- Reduce the size of buffers for OFW properties to what they actually
need to hold.
- Rename some tables to creator_<foo> for consistency.
- Also for the sizes in the creator_fb_mmap() mapping table entries use
macros for consistency, add macros for the remaining register banks
for completeness.
operation as it ran out of free descriptors or if there are too many
segments in the first place, call bus_dmamap_unload() in order to
unload the already loaded segments.
For trying to map the defragmented mbuf (chain) in re_encap() this
introduces re_dma_map_desc() setting arg.rl_maxsegs to 0 as a new
failure mode. Previously we just ignored this case, corrupting our
view of the TX ring.
o In re_txeof():
- Don't clear IFF_DRV_OACTIVE unless there are at least 4 free TX
descriptors. Further down the road re_encap() will bail if there
aren't at least 4 free TX descriptors, causing re_start() to
abort and prepend the dequeued mbuf again so it makes no sense
to pretend we could process mbufs again when in fact we won't.
While at it replace this magic 4 with a macro RL_TX_DESC_THLD
throughout this driver.
- Don't cancel the watchdog timeout as soon as there's at least one
free TX descriptor but instead only if all descriptors have been
handled. It's perfectly normal, especially in the DEVICE_POLLING
case, that re_txeof() is called when only a part of the enqueued
TX descriptors have been handled, causing the watchdog to be
disarmed prematurely.
o In re_encap():
- If m_defrag() fails just drop the packet like other NIC drivers
do. This should only happen when there's a mbuf shortage, in which
case it was possible to end up with an IFQ full of packets which
couldn't be processed as they couldn't be defragmented as they
were taking up all the mbufs themselves. This includes adjusting
re_start() to not trying to prepend the mbuf (chain) if re_encap()
has freed it.
- Remove dupe initialization of members of struct rl_dmaload_arg to
values that didn't change since trying to process the fragmented
mbuf chain.
While at it remove an unused member from struct rl_dmaload_arg.
o In re_start() remove a abandoned, banal comment. The corresponding
code was moved to re_attach() some time ago.
With these changes re(4) now survives one day (until stopped) of
hammering out packets here.
Reviewed by: yongari
MFC after: 2 weeks
- Retire the PCI_SUB*_1 constants and don't try to read a subvendor ID out
of them. There isn't a standard subvendor ID field for PCI-PCI bridges.
Instead, the dword at offset 0x34 is actually mostly reserved except for
the LSB which is the capabilities pointer.
- Add support for the PCI-PCI bridge subvendor ID capability (13) and use
it to set the subvendor ID for PCI-PCI bridges.
MFC after: 1 month
functions. The idea is taken from OpenBSD.
- Set/clear jumbo frame configurations for bge(4).
- Re-add BCM5750 PHY workaround for bce(4), which was mistakenly removed
from the previous commit.
- Move some PHY bug detections from brgphy.c to if_bge.c.
- Do not penalize working PHYs.
- Re-arrange bge_flags roughly by their categories.
- Fix minor style(9) nits.
PR: kern/107257
Obtained from: OpenBSD
Tested by: Mike Hibler <mike at flux dot utah dot edu>
o eliminate assumptions that half/quarter rate channels on exist in 11a
o handle frequency mapping between hal and net80211; hal gives us freq's
in the range 2422..2437 that we remap
MFC after: 1 month
bridge if it doesn't pass MSI messages up correctly. We set the flag
in pcib_attach() if the device ID is disabled via a PCI quirk.
- Disable MSI for devices behind the AMD 8131 HT-PCIX bridge. Linux has
the same quirk.
Tested by: no one despite repeated calls for testers
laptops.
Tested by: [1] Lion G. <liontanker@hotmail.com>
[2] Pietro Cerutti <pietro.cerutti@gmail.com>
Specialized mixer initialization for STAC9221, much like STAC9220.
Tested by: Devon H. O'Dell
- Set MIIF_NOLOOP as loopback doesn't work with this PHY. The MIIF_NOLOOP
flag currently triggers nothing but hopefully will be respected by
mii_phy_setmedia() later on.
- Use MII_ANEGTICKS instead of 5.
- Remove an unused macro.
- Fix some whitespace nits.
MFC after: 1 week
- In exphy_service() for the MII_TICK case don't bother to check whether
the currently selected media is of type IFM_AUTO as auto-negotiation
doesn't need to be kicked anyway.
- Remove #if 0'ed unapplicable code.
- Fix some whitespace nits.
MFC after: 1 week
and thus the FX_DIS pin indicates fibre media. This is part 1/2 of
adding support for the 100baseFX interface/port of AT-2700 series
adaptors.
Idea from: NetBSD
MFC after: 1 week
indices when manually adding media. Some of these I've missed while
converting drivers to take advantage of said fuctions recently,
others where longstanding bugs.
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
that piggybacks on bce_tick() callout.
- Instead of unconditionally resetting the controller, try to
skip the reset in case we got a pause frame, like em(4) did.
- Lock bce_tick() using callout_init_mtx().
Discussed with/Reviewed by: glebius, scottl, davidch
not needed if the proper ordering is done in attach and shutdown.
Remove usage of if_timer/watchdog and roll my own by piggybacking
off the tick() function.
Use the new usb system to allocate task queues instead of using
the system wide thread for taskqueues.
for usb. I hope that this will eventually be used for generic devices
that need full fledged blocking threads for event processing.
Create a taskqueue:
void usb_ether_task_init(device_t, int, struct usb_taskqueue *);
Enqueue a task:
void usb_ether_task_enqueue(struct usb_taskqueue *, struct task *);
Wait for all tasks queued to complete:
void usb_ether_task_drain(struct usb_taskqueue *, struct task *);
Destroy the taskqueue:
void usb_ether_task_destroy(struct usb_taskqueue *);
link state changes. Instead, build new speed/duplex/flow-control
settings from the values reported from PHY.
This should fix speed/duplex/flow-control mismatches between GMAC and
PHY which resulted in very poor Rx performance due to lots of
out-of-order packet delivery.
Reported by: Arno J. Klaassen <arno AT heho DOT snv DOT jussieu DOT fr>
Tested by: Arno J. Klaassen <arno AT heho DOT snv DOT jussieu DOT fr>
modern dual-core systems as well.
- Parse the _CST packages for each cpu and track all the states individually,
on a per-cpu basis.
- Revert to generic FADT/P_BLK based Cx control if the _CST package
is not present on all cpus. In that case, the new driver will
still support per-cpu Cx state handling. The driver will determine the
highest Cx level that can be supported by all the cpus and configure the
available Cx state based on that.
- Fixed the case where multiple cpus in the system share the same
registers for Cx state handling. To do that, added a new flag
parameter to the acpi_PkgGas and acpi_bus_alloc_gas functions that
enable the caller to add the RF_SHAREABLE flag. This flag could also be
useful to other callers (acpi_throttle?) in the tree but this change is
not yet made.
- For Core Duo cpus, both cores seems to be taken out of C3 state when
any one of the cores need to transition out. This broke the short sleep
detection logic. It is disabled now if there is more than one cpu in
the system for now as it fixed it in my case. This quirk may need to
be re-enabled later differently.
- Added support to control cx_lowest on a per-cpu basis. There is still
a generic cx_lowest to enable changing cx_lowest for all cpus with a single
sysctl and for ease of use. Sample output for the new sysctl:
dev.cpu.0.cx_supported: C1/1 C2/1 C3/57
dev.cpu.0.cx_lowest: C3
dev.cpu.0.cx_usage: 0.00% 43.16% 56.83%
dev.cpu.1.cx_supported: C1/1 C2/1 C3/57
dev.cpu.1.cx_lowest: C3
dev.cpu.1.cx_usage: 0.00% 45.65% 54.34%
hw.acpi.cpu.cx_lowest: C3
This work was done by Stephane E. Potvin with some simple reworking by
myself. Thank you.
Submitted by: Stephane E. Potvin <sepotvin / videotron.ca>
MFC after: 2 weeks
revision 1.98 is NOT merged, because FreeBSD does not support this
syntax.
revision 1.99 is NOT merged, "const poisoning" part is not applicable
to FreeBSD. There is no variable shadowing, GCC can't find
this one (but there are others)
revision 1.100 is NOT merged, because it was null patch (no changes)
revision 1.101 is NOT merged, there is no BIT() macro in FreeBSD
revision 1.102 is merged
revision 1.103 is partially merged. There is no ai.ifaceh in FreeBSD
revision 1.104 is NOT merged
revision 1.105 is merged
revision 1.106 is not merged, because of rev. 1.107
revision 1.107 is a backuout of 1.106
Submitted by: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru>
---snip---
New features:
1. Optional multichannel recording (32 channels on Live!, 64 channels
on Audigy).
All channels are 16bit/48000Hz/mono, format is fixed.
Half of them are copied from sound output, another half can be
used to record any data from DSP. What should be recorded is
hardcoded in DSP code. In this version it records dummy data, but
can be used to record all DSP inputs, for example..
Because there are no support of more-than-stereo sound streams
multichannell stream is presented as one 32(64)*48000 Hz 16bit mono
stream.
Channel map:
SB Live! (4.0/5.1)
offset (words) substream
0x00 Front L
0x01 Front R
0x02 Digital Front L
0x03 Digital Front R
0x04 Digital Center
0x05 Digital Sub
0x06 Headphones L
0x07 Headphones R
0x08 Rear L
0x09 Rear R
0x0A ADC (multi-rate recording) L
0x0B ADC (multi-rate recording) R
0x0C unused
0x0D unused
0x0E unused
0x0F unused
0x10 Analog Center (Live! 5.1) / dummy (Live! 4.0)
0x11 Analog Sub (Live! 5.1) / dummy (Live! 4.0)
0x12..-0x1F dummy
Audigy / Audigy 2 / Audigy 2 Value / Audigy 4
offset (words) substream
0x00 Digital Front L
0x01 Digital Front R
0x02 Digital Center
0x03 Digital Sub
0x04 Digital Side L (7.1 cards) / Headphones L (5.1 cards)
0x05 Digital Side R (7.1 cards) / Headphones R (5.1 cards)
0x06 Digital Rear L
0x07 Digital Rear R
0x08 Front L
0x09 Front R
0x0A Center
0x0B Sub
0x0C Side L
0x0D Side R
0x0E Rear L
0x0F Rear R
0x10 output to AC97 input L (muted)
0x11 output to AC97 input R (muted)
0x12 unused
0x13 unused
0x14 unused
0x15 unused
0x16 ADC (multi-rate recording) L
0x17 ADC (multi-rate recording) R
0x18 unused
0x19 unused
0x1A unused
0x1B unused
0x1C unused
0x1D unused
0x1E unused
0x1F unused
0x20..0x3F dummy
Fixes:
1. Do not assign negative values to variables used to index emu_cards
array. This array was never accessed when index is negative, but
Alexander (netchild@) told me that Coverity does not like it.
After this change emu_cards[0] should never be used to identify
valid sound card.
2. Fix off-by-one errors in interrupt manager. Add more checks there.
3. Fixes to sound buffering code now allows driver to use large playback
buffers.
4. Fix memory allocation bug when multichannel recording is not
enabled.
5. Fix interrupt timeout when recording with low bitrate (8kHz).
Hardware:
1. Add one more known Audigy ZS card to list. Add two cards with
PCI IDs betwen old known cards and new one.
Other changes:
1. Do not use ALL CAPS in messages.
Incomplete code:
1. Automute S/PDIF when S/PDIF signal is lost.
Tested on i386 only, gcc 3.4.6 & gcc41/gcc42 (syntax only).
---snip---
This commits enables a little bit of debugging output when the driver is
loaded as a module. I did a cross-build test for amd64.
The code has some style issues, this will be addressed later.
The multichannel recording part is some work in progress to allow playing
around with it until the generic sound code is better able to handle
multichannel streams.
This is supposed to fix
CID: 171187
Found by: Coverity Prevent
Submitted by: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru>
server.
Don't complain about a hard loop id of 0xffff- we get this in
point-to-point topologies with the 2300 and 2K Login firmware.
Up the timeout on register FC4 types commands.
- Rename confusing AGP_INTEL_I845_MCHCFG to AGP_INTEL_I845_AGPM.
- Move E7205 and E7505 from i8x5 to i8x0 family. It probably worked
because the actual offset is the same.
In fact, all three families have the bit at the exact same place. Only
differences are name and width of the registers, i.e., NBXCFG (0x50, dword),
RDCR (0x51, byte), AGPM (0x51, byte), MCHCFG (0x50, word) depending on
the family of the chipsets.
a spin mutex since it doesn't have an INTR_FAST interrupt handler.
Beyond that the driver is still under Giant anyway.
- Remove unneeded locking during attach across operations that can't be
called with locks held (such as bus_dma_tag_create()).
MFC after: 1 week
Not objected to by: scottl
start working with third party usb modules, where sometimes it
is not easy to set the inclusion order so that there are no multiple
inclusions, yet you want to compile with high WARNS levels).
I am not sure if there is a standard for having a leading and/or trailing _
in the macro name, the usb code seems to use both.
There are still several unprotected headers here so it might be useful
to do the same thing on other files as well as the need arises.
MFC After: 3 days
semantics.
- Stop testing bpf pointers for NULL. In some cases use
bpf_peers_present() and then call the function directly inside the
conditional block instead of the macro.
- For places where the entire conditional block is the macro, remove the
test and make the macro unconditional.
- Use BPF_MTAP() in if_pfsync on FreeBSD instead of an expanded version of
the old semantics.
Reviewed by: csjp (older version)
o change handling of regdomain-related mib knobs so they can be set
post-attach: regdomain, countrycode, outdoor, and xchanmode; the
hal will not permit changing the regdomain but we expose it for now
o on regdomain/countrycode change recalculate the channel list and
push it to the net80211 layer (NB: looks to need more tweaking)
o setup rate tables for half/quarter rate channels
o honor half/quarter rate channel configs when changing channels
o honor half/quarter rate channel configs when setting the slot time
o use hack/nonstandard channel numbering scheme for the public safety
band to avoid overlapping 2.4G channels on dual-band cards
o remove setup of ic_sup_rates; the net80211 layer can do this for us
and it simplifies handling of half/quarter rate channels
Tested only in Public Safety Band with cards that have RF5112.
bge_intr(). Some of them are used in bge_poll(). Simplify by only
initializing these for polling mode and not toggling them when switching
modes. This also fixes missing synchronization with the coalescing
engine in the toggling.
The problem was that I was acquiring the driver sx lock and then waiting
for a taskqueue to drain, however the taskqueue itself would try to
acquire the lock as well leading to a deadlock.
To fix the problem roll my own exclusive lock that allows for lock
cancellation. This is a normal exclusive lock, however if someone
marks it as "dead" then all waiters who request an error return will
get back an error instead of continuing to wait for the lock.
In this particular case, the shutdown and detach functions kill the
lock while the async task thread tries to acquire the lock but will
abort if the lock returns an error.
The other option was to drop the driver lock mid-detach and mid-shutdown,
mid-detach was a ok, however mid-shutdown was not.
While I'm here, fix a bug in what appears to be the mii link status
word in the softc going out to lunch. Explicitly set the status
word to 1 after initializing the mii. This would result in an interface
that would never respond to "if_start" requests as the mii interface
would always look down.
return an error since it returns a count of battery devices in the system.
Set it to 0 explicitly, since it is the only switch branch that doesn't set
it.
# I guess no one uses it.
would be able to work with aac(4).
This approach is used by some other drivers as well. However, we
need a more generic way to do this in order to avoid having to
special case headers in individual drivers for each platform.
Obtained from: Adaptec (version b11518)
Approved by: scottl
been handled instead of when at least one descriptor was just handled.
For bge, it is normal to get a txeof when only a small fraction of the
queued tx descriptors have been handled, so the bug broke the watchdog
in a usual case.
- moved the synchronizing bus read to after the bus write for the first
interrupt ack so that it actually synchronizes everything necessary.
We were acking not only the status update that triggered the interrupt
together with any status updates that occurred before we got around
to the bus write for the ack, but also any status updates that occur
after we do the bus write but before the write reaches the device.
The corresponding race for the second interrupt ack resulted in
sometimes returning from the interrupt handler with acked but
unserviced interrupt events. Such events then remain unserviced
until further events cause another interrupt or the watchdog times
out.
The race was often lost on my 5705, apparently since my 5705 has broken
event coalescing which causes a status update for almost every packet,
so another status update is quite likely to occur while the interrupt
handler is running. Watchdog timeouts weren't very noticeable,
apparently because bge_txeof() has one of the usual bugs resetting the
watchdog.
- don't disable device interrupts while bge_intr() is running. Doing this
just had the side effects of:
- entering a device mode in which different coalescing parameters apply.
Different coalescing parameters can be used to either inhibit or
enhance the chance of getting another status update while in the
interrupt handler. This feature is useless with the current
organization of the interrupt handler but might be useful with a
taskqueue handler.
- giving a race for ack+reenable/return. This cannot be handled
by simply rearranging the order of bus accesses like the race for
ack+keepenable/entry. It is necessary to sync the ack and then
check for new events.
- taking longer, especially with the extra code to avoid the race on
ack+reenable/return.
Reviewed by: ru, gleb, scottl
re_watchdog() in order to avoid races accessing if_timer.
- Use bus_get_dma_tag() so re(4) works on platforms requiring it.
- Remove invalid BUS_DMA_ALLOCNOW when creating the parent DMA tag
and the tags that are used for static memory allocations.
- Don't bother to set if_mtu to ETHERMTU, ether_ifattach() does that.
- Remove an unused variable in re_intr().
watchdog timer in dc_txeof() in case there are still unhandled
descriptors as dc_poll() invokes dc_poll() unconditionally.
Otherwise this would result in the watchdog timer constantly being
being reloaded and thus circumvent that the watchdog ever fires in
the DEVICE_POLLING case.
Pointed out by: bde
- Do not repeatedly read vendor/device IDs while probing.
- Remove redundant bzero(3) for softc. device_get_softc(9) does it for free[1].
Reviewed by: glebius
Suggested by: glebius[1]
- If we want mii_phy_add_media() to add 1000baseT media, we need to
supply sc->mii_extcapabilities.
- Fix formatting when announcing autonegotiation support.
