deserves its own internet memes). The trick is to force all available,
unused pins (that being advertised as "speaker") to behave as microphone
pins instead.
Reported / Tested by: Dmitry Kutsenko <kutsenko.truebsd.org>
MFC after: 3 days
move most offload functionality from NIC to TOE
factor out all socket and inpcb direct access
factor out access to locking in incpb, pcbinfo, and sockbuf
as the former is becoming deprecated and exhibits some extraneous
Giant-locking. The new callout(9) is declared MPSAFE, so it may
improve concurrency.
Tested by: matteo
Silence from: wpaul
MFC after: 1 month
explicitly select write locking for all use of the inpcb mutex.
Update some pcbinfo lock assertions to assert locked rather than
write-locked, although in practice almost all uses of the pcbinfo
rwlock main exclusive, and all instances of inpcb lock acquisition
are exclusive.
This change should introduce (ideally) little functional change.
However, it lays the groundwork for significantly increased
parallelism in the TCP/IP code.
MFC after: 3 months
Tested by: kris (superset of committered patch)
This avoids calling busdma in the request processing path which caused a traumatic performance degradation.
Allocation has be postponed to after we know how many devices we possible can have on portmulitpliers to save some space.
clearing MSI enable bit for MSI capable hardwares resulted in Tx
problems. MSI enable bit is set only when MSI is requested from
user.
Tested by: remko
- Fix speaker issues with Dell Vostro 1500 (GPIO0)
Tested by: John Wright <jwright.gmail.com>
- Apply ridiculous quirk on Asus A8X series (A8JC, A8M, A8xx, etc). These
different laptop series share simmilar pci id, hardware codecs, etc.
but works differently. A slight difference in connection type for
widget #26 is used to differentiate it.
Tested by: eric baumbach <embaumbach.gmail.com>
- Apply GPIO0 quirk for ASUS G2K laptop
- Sort ASUS ids accordingly.
Submitted by: jkim
MFC after: 3 days
TX traffic to sit in the send chain until a received packet kick
started the interrupt handler. This would cause extremely slow
performance when used with NFS over UDP.
- Removed untested polling code.
- Updated copyright year in the file header.
- Removed inadvertent ^M's created by DOS text editor.
MFC after: 2 weeks
be handled by chn_abort() and chn_start() alone. This should fix
few issues with single duplex hardware (mostly) or pre virtual record
(RELENG 6) under WINE emulation and possibly others that using
SNDCTL_DSP_SETTRIGGER.
MFC after: 3 days
The problem is that the PM support is part of a much larger WIP here, but due to popular demand I decided to get some of it imported.
Also I forgot the mention:
HW sponsored by: Vitsch Electronics / VEHosting
I've taken a slightly different approach than is used with the ICH8 controllers
in that each controller is not identified individually (eg USB A, USB B, etc).
Instead I've given then same description to each one even though the device ID
differs. This can easily be changed if desired, or ICH8 (and any others using
that approach) can be made to work as this does.
Support is working on the Silicon Image SiI3124/3132.
Support is working on some AHCI chips but far from all.
Remember this is WIP, so test reports and (constructive) suggestions are welcome!
commands can be written to /dev/psm%d and status can be read back from it.
- Reflect the change in psm(4) and bump version for ports.
MFC after: 1 week
Because of this we were not getting further interrupts for link state
changes, thus never went into iface UP state and thus could not transmit.
The only way out of this was an incoming packet generating an rx interrupt
and making us call into bge_link_upd.
Up to rev. 1.101, in bge_start_locked, we only returned instantly
if there was 'no link AND nothing queued for tx'. So with a packet queued
for tx, we hit the register scrubbing at the end of bge_start_locked
and were out fine. We simply lost a packet or two but got the interrupts
need to get into UP state.
With rev. 1.102 this was turned into 'if there is no link OR there is
nothing to send' (correct behaviour) and as long as there is no link
we never hit the register scrubbing and consequently never got the link UP.
What we do now is force an interrupt at the end of bge_ifmedia_upd_locked
so we will call bge_link_upd, clear the link state attention and get
further interrupts.
This helps to get the iface UP on an idle network or at least to get
it UP faster not depending on an rx intr anymore.
In case you could not get a DHCP lease or it took very long,
it was because of this.
It is unknown which chips are affected by this. ASIC rev. 0x2003 was the
most popular trouble candidate.
At least the fiber cards should have been working fine.
Which register to scrub is currently under discussion. The comitted
solution was tested and found to work for a lot of setups. It might
not help with MSI.
The reason why we end up in such a situation is entirely unknown.
PR: kern/111804
Tested by: phk, scottl at Y!
MFC after: 14 days
part of detecting the media. Explicitly ensure that we don't send it to
bpf(4) as bpf(4) isn't setup yet. This worked by accident before the bpf
interface stuff was reworked to avoid other races (bpf_peers_present, etc.)
but now it needs an explicit check to avoid a panic.
MFC after: 3 days
PR: kern/120915
and the igb driver static in the kernel. But it also reflects
some other bug fixes in my development stream at Intel.
PR 122373 is also fixed in this code.
to trip a bug causing the latter to return a zeroed struct
aac_adapter_info. This causes two issues. One is cosmetic only --
a verbose boot prints information about the controller, and shows all
zero:
aac0: Unknown processor 0MHz, 0MB memory (0MB cache, 0MB execution),
unknown battery platform
The second problem is that the firmware version information is stored
away for aac_rev_check, for userland tools (like aaccli) to query via
the FSACTL_MINIPORT_REV_CHECK and FSACTL_LNX_MINIPORT_REV_CHECK ioctls.
When aaccli encounters this issue it prints
Command Error: <The current AFAAPI.DLL is too old to work with the
current controller software.>
Move the RequestSupplementAdapterInfo call after RequestAdapterInfo,
which seems to fix both problems.
abstraction as the RAID and CAM modules, making it nearly impossible
for enough initialization to be done in time for the RAID module to
know whether to attach. On top of this, no reset was being done on
the controller on attach, in violation of the spec. Additionally,
the port enable step was being deferred to the end of the attach
process, long after it should have been done to ensure reliable
operation from the controller. Fix all of these with a few hacks
to force the "attach" and "enable" steps of the core module early
on, and ensure that a reset and port enable also happens early on.
In the future, the driver needs to be refactored to eliminate the
core module abstraction, clean up withe reset/enable steps, and
defer event messages until all of the modules are available to
recieve them.
offload bugs by manual padding for short IP/UDP frames. Unfortunately
it seems that these workaround does not work reliably on newer PCIe
variants of RealTek chips.
To workaround the hardware bug, always pad short frames if Tx IP
checksum offload is requested. It seems that the hardware has a
bug in IP checksum offload handling. NetBSD manually pads short
frames only when the length of IP frame is less than 28 bytes but I
chose 60 bytes to safety. Also unconditionally set IP checksum
offload bit in Tx descriptor if any TCP or UDP checksum offload is
requested. This is the same way as Linux does but it's not
mentioned in data sheet.
Obtained from: NetBSD
Tested by: remko, danger
these days, so de-generalize the acquire_timer/release_timer api
to just deal with speakers.
The new (optional) MD functions are:
timer_spkr_acquire()
timer_spkr_release()
and
timer_spkr_setfreq()
the last of which configures the timer to generate a tone of a given
frequency, in Hz instead of 1/1193182th of seconds.
Drop entirely timer2 on pc98, it is not used anywhere at all.
Move sysbeep() to kern/tty_cons.c and use the timer_spkr*() if
they exist, and do nothing otherwise.
Remove prototypes and empty acquire-/release-timer() and sysbeep()
functions from the non-beeping archs.
This eliminate the need for the speaker driver to know about
i8254frequency at all. In theory this makes the speaker driver MI,
contingent on the timer_spkr_*() functions existing but the driver
does not know this yet and still attaches to the ISA bus.
Syscons is more tricky, in one function, sc_tone(), it knows the hz
and things are just fine.
In the other function, sc_bell() it seems to get the period from
the KDMKTONE ioctl in terms if 1/1193182th second, so we hardcode
the 1193182 and leave it at that. It's probably not important.
Change a few other sysbeep() uses which obviously knew that the
argument was in terms of i8254 frequency, and leave alone those
that look like people thought sysbeep() took frequency in hertz.
This eliminates the knowledge of i8254_freq from all but the actual
clock.c code and the prof_machdep.c on amd64 and i386, where I think
it would be smart to ask for help from the timecounters anyway [TBD].
Removed dead code that assumed that M_TRYWAIT can return NULL; it's not true
since the advent of MBUMA.
Reviewed by: arch
There are ongoing disputes as to whether we want to switch to directly using
UMA flags M_WAITOK/M_NOWAIT for mbuf(9) allocation.
- Correct the maxsize parameter when creating the mbufs busdma tag to
reflect the actual requirement of dc(4).
- Move the KASSERT in dc_newbuf() to the right spot.
- Also convert the TX side to take advantage of bus_dmamap_load_mbuf_sg(9).
- Move the comment regarding dc_start_locked() to the right spot.
MFC after: 2 weeks
- Resource allocation in aac_alloc (moved from from aac_init)
- Interrupt setup in aac_setup_intr (from aac_attach)
- Container probing in aac_get_container_info (from aac_startup and
aac_handle_aif)
- Firmware status check moved to aac_check_firmware from aac_init
multi-descriptor transmission attempt. Datasheet said nothing about
this requirements. This should fix a long-standing VLAN hardware
tagging issues with re(4).
Reported by: Giulio Ferro ( auryn AT zirakzigil DOT org )
Tested by: Giulio Ferro ( auryn AT zirakzigil DOT org )
exhaustion is encountered. There was a fix made previously for this
problem but the solution (breaking out of the receive loop) does not
seem to work. mbuf reuse strategy is already adopted by other drivers
such as if_bge. The problem was recreated and the patch is also
verified in the same test environment.
putting the correct size in the fib header. Presumably the older firmware
silently ignored a bad size field.
(This change tested with a 3805 controller. Passthrough devices were
created when running firmware build 12814, but not 15323 or later. With
this change they're created for both old and new firmware versions.)
Submitted by: Adaptec
FSACTL_LNX_SEND_LARGE_FIB, and FSACTL_LNX_SEND_RAW_SRB, and correct size
checks on FIBs passed in from userspace. Both changes were obtained from
Adaptec's driver build 15317. Adaptec's commandline RAID tool arcconf uses
these ioctls when creating a RAID-10 array (and probably other operations
too).
work on architectures with a write-back cache as the PIO writes end up
in the cache which the sync(BUS_DMASYNC_POSTREAD) in usb_transfer_complete
then discards; compensate in the xfer methods that do PIO by pushing the
writes out of the cache before usb_transfer_complete is called.
This fixes USB on xscale and likely other places.
Sponsored by: hobnob
Reviewed by: cognet, imp
MFC after: 1 month
all uses) involve a read but usbd_start_transfer only does a PREWRITE; change
this to BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE as I'm not sure if any
users do write+read.
Reviewed by: cognet, imp
MFC after: 1 month
