it can fail all too easily. Instead bus_dmamap_load the cached copy and
create the command blocks for the device to load it accordingly.
Thanks to scw and mrg for reviewing this.
Closes PR 29892 (I hope).
Use the newer scan command as this one doesn't crash the firmware when
scanning 802.11a channels.
Thanks to scw and blymn for testing.
Closes PR 31295.
problems when more than one mach64 is present
- check memory BARs in mach64_mmap() and adjust allowed ranges in case
something ( XFree86 for instance ) changed them
- disable 'standard' framebuffer mapping at offset 0 on sparc64 because some
Sun/ATI firmware likes to map PCI resources there. May be necessary on other
64bit architectures as well.
rev 1.56:
Don't initialize the card (and start an autonegotiation!) every time
the IP address changes. Makes 'dhclient sk0' invocations way faster
and more consistant. i.e. one DHCPREQUEST elicts the DHCPACK.
Fix from FreeBSD:
rev 1.109:
Solve "No PHY found" problem for more Yukon Lite variants.
These changes fixed the problem on my sk(4) trying to get an IP
via dhclient(8).
standard scheme:
if (<configured> != <wildcard> && <configured> != <real>)
then fail
else
ask device match function
This is handled by config_stdsubmatch() now.
explicitely by a plain integer array
the length in now known to all relevant parties, so this avoids
duplication of information, and we can allocate that thing in
drivers without hacks
bit 2 or 3. Thanks to Takeshi Nakayama for catching it.
(With this mistake the code was still working for the first channel, because
the reset of the second channel would disable/enable the first one).
is set to NULL, use the generic reset code.
Use this to work around a bug in some Acer IDE controllers (like the
one found in some sparc systems) where a controller disable/enable
is required after a reset to avoid data corruption when Ultra-DMA is
used. Workaround from opensolaris, thanks to Hiroki Sato for testing.
firmware likes to put PCI memory resources into this range, notably a Rage
IIc which puts the 2nd register aperture to 0x2000.
This should allow a few graphics chips to work with XFree86 which previously
failed with something like this:
(WW) ATI: PCI/AGP Mach64 in slot 2:5:0 could not be detected!
No devices to configure. Configuration failed.
Thanks to Florian Stoehr for doing most of the work tracking this down.
- Don't initialise ic_phytype twice and do initialise ic_state.
- announce available rates.
- mark interface down if firmware crashes for the radio transmitter
gets turned off.
back out my change to ieee80211_crypto_encap that made it free its
mbuf argument on error. I had thought it was a bug. It was not.
It's the drivers that are broken. Make an(4), atw(4), ipw(4),
iwi(4), ral(4), rtw(4), ural(4), and wi(4) free the mbuf when
ieee80211_crypto_encap returns NULL. Also, return ath(4) to the
way it was---i.e., free the mbuf.
Thanks to Sam Leffler to pointing out my mistake.
returns EINVAL, indicating that DMA cannot be done for this transfer.
Fall back to PIO in this case.
- Add a geodeide_dma_init() routine that checks to make sure that transfers
start on a 16 byte boundary, returning EINVAL if not. Works around a chip
bug that causes a hard system hang.
Problem reported and patch tested by Erik Fair.
Damien Bergamini, ported and submitted by FUKAUMI Naoki per PR kern/30449
I've modified the USB "ural" driver for recent changes to the NetBSD
ieee80211 framework, possibly not completely, but with an ASUS wireless
adapter I'm getting some signs of life.
Didn't care about pci/cardbus for now, hopefully someone with hardware
will do it.
Stop including dev/pci/files.ath in arch/i386/conf/files.i386,
since we get the same definitions by including dev/pci/files.pci,
now. Remove dev/pci/files.ath.
Add arch/macppc/conf/Makefile.macppc with directives for linking
the Atheros HAL for PowerPC.
In athhal-powerpc-be-eabi.opt_ah.h, #define AH_REGOPS_FUNC 1, since
otherwise the linker complains that the PowerPC HAL cannot link
with register-read/write subroutines.
Add ath(4) to the GENERIC macppc kernel configuration; comment it
out.
This is what the linux driver does, and makes the DGE-550T work without the
STGE_CU_BUG hack. So remove the STGE_CU_BUG hack.
Set bit 0x0020 in STGE_DebugCtrl too, the linux driver does it (the comments
note this as a workaround, without more details. This doesn't seem to make
things worse).
Also initialize STGE_RxDMABurstThresh and STGE_RxDMAUrgentThresh, using
values from the linux driver.
Approved by Jason Thorpe.
while capable of UDMA mode 2, is swamped if you actually go that
fast, which is not good for the other functions on this multifunction
southbridge chip, so limit UDMA to mode 1.
skrll