function provided by the driver limits allocations to the page size,
i.e. 4KB on i385 and 8KB on typical 64 bit processors. Since amd64
has 64 bit pointers, but only 4KB pages, an array of pointers that
just fits into one page on all the other processors, does require
2 pages on amd64.
In order to make this driver useful on amd64, the allocation unit
has been increased to 2 pages on amd64 and contigmalloc() is used
instead of malloc(). All other processor types are unaffected by
this change. This modification has only been compile-tested on
amd64, yet, but should just work (FLW).
machine; instead use the intended entry points. There's still
too much incestuous knowledge about the internals of the
802.11 layer but this at least fixes adhoc mode.
suggested by Peter Edwards. This seems to fix my fxp problems and
likely will fix his as well. Use DELAY rather than *sleep because we
can be called from any context.
o catch one place where we were not using ath_chan_change to
switch channels; this fixes a problem where the channel
settings were not being correctly reported in captured packets
o return unique channel identification in the channel flags;
ethereal gets confused if you return merged flags (e.g. ofdm,
cck, and 2Ghz) (this is workaround and should be removed if
we can ever cleanup radiotap consumers)
o correct short/long preamble flag state for rx and treat tx
the same--use a new hwflags array that gives us the data
based on the h/w rate index/cookie
o add gross hack to handle radiotap capture of frames that
come in with hardware padding; should be replaced by a
flag in the radiotap header and more smarts in the apps
that decode radiotap data
o lintval is in ms; must convert to TU's for passing to the hal
o roundup to calculate nexttbtt (should look at current tsf and pull the
calculated nextbtt forward but this'll do for now)
o don't or- in HAL_BEACON_RESET_TSF when doing station timer setup; this
is not needed and messes up the sleep timer calcs, though it's unclear
if it mattered as the hal masks these values before use
Submitted by: Thorsten von Eicken
generic bridge support was biting us more than it helped, whenever a new chipset
came out from a vendor and misprogramming it caused strange hangs or corruption.
[2] Add a large number of PCI IDs based on what the linux drivers support.
Note that the new PCI IDs haven't been tested, they're just *likely* to work.
In particular the VIA AGP 8x chipsets are concerning, due to lack of testing,
possible issues (kern/69953), and not having a nice "does this bridge say it
would do 8x" function. However, this shouldn't make the situation worse, since
these chips would have probed in the past anyway.
to remove a transaction from the async schedule. The previous method didn't
work well and led to the hardware writing to free'd buffers etc, as
it didn't always know that the transaction had been aborted.
Written after consultation with David Brownell who wrote the Linux
EHCI driver.
As part of this give the sqh structure a "previous" pointer.
MFC after: 1 week
rather than a softc pointer (with the bus structure at the start).
This is a non-functional change. It just helps when reading the code to
know that the ehci, ohci and uhci drivers share the bus structure, not the
entire softc.
This allows boot to proceed on a real system until the issue
of calling back into certain OpenFirmware calls (e.g. finddevice)
in thread context is understood.
(this commit only affects psim users, of which I think I am the
only one...)
show file name for 'mdconfig -l -u <x>' command.
This allows to preserve API/ABI compatibility with version 0 (that's why
I changed version number back to 0) and will allow to merge this change
to RELENG_5.
MFC after: 5 days
ADVANCELOGIC->AVANCELOGIC (nothing in the tree uses it, so safe to do)
sort HAGIWARA vendor entry
sort ACTIONTAR vendor entry
Minor change to SYSTEMTALKS vendor entry.
Add $NetBSD$ in a comment at the top
Update copyright dates
Update header comment
Add some of the entries not present in FreeBSD's usbdevs file
Harmonize some descriptions with NetBSD where NetBSD's were shorter
More work needs to happen here, as there's many conflicting vendor
names. There's also more harmonization that can happen before that
problem is tackled.
This was inspired by recent discussions, but none of the patches
posted were consulted to produce this commit. Other, similar ones
will follow.
One of a set of patches submitted by Kazuhito HONDA
to make the usb audio driver a lot more capable.
PR: 75274
Submitted by: Kazuhito HONDA (kazuhito at ph dot noda dot tus dot ac dot jp)
Obtained from: NetBSD (indirectly)
MFC after: 2 weeks
This is part of an ongoing cycle of commits on all the BSDs to
merge the USB vendor and device defintions..
A merge from OpenBSD is still pending.
Submitted by: barry bouwsma (freebsd-misuser@NOSPAM.dyndns.dk)
Obtained from: NetBSD
MFC after: 1 week
multiple IRQs (which is nonsense for _CRS) when the link hasn't been
programmed. Before, this was a KASSERT. A ServerWorks system was
seen returning IRQs of 0, 2 in response to _CRS before link setup.
Thanks to sam@ for quick testing and turnaround on this.
Tested by: sam
datasheet says it is only valid for such chipsets and shouldn't be used
with others. This fixes some 82559 based cards which otherwise only
work at 10Mbit.
MFC after: 5 days
Tested by: krion
In contrast to OpenBSD we enable jumbo frame support
depending on MTU setting (like done for xmac).
Approved by: pjd (mentor)
Obtained from: OpenBSD if_sk.c r1.52 (YU_SMR_MFL_JUMBO flag)
Tested by: Heinz Knocke <knockefreebsd at o2 dot pl>
MFC after: 5 days
there is some hope for the 32-bit management utilities to run. I've used
the cli successfully, but 3dm2 doesn't work for other reasons. Of course,
a native binary of the 3dm2 and cli would be much better, but that doesn't
exist.
o don't encapsulate on tx; the chip expect a raw frame w/o the crypto header
o clear the WEP bit in the 802.11 header on rx so the 802.11 layer doesn't
try to strip the crypto header
o clobber the "drop unencoded frames" state bit when privacy is enabled so
rx'd frames we pass up to the 802.11 layer are not discarded as unencrypted
This stuff will need to be redone if anyone decides to add WPA support.
port during the device probe as this can cause hangs on some machines,
specifically Compaq R3000Z series amd64 laptops. The flag is bit 3, or
0x8.
PR: amd64/67745
Reported by: Neil Winterbauer newntrbr at ucla dot edu, many others
Tested by: ade, astrodog at gmail dot com, many others
MFC after: 1 week
pointers to an integer via uintptr_t.
Fix an apparent bug that caused a compile failure.
ieee80211_iterate_nodes() takes ic->ic_sta as its first argument on the
onoe module. It had just 'ic' here in the same context, which was a
mismatched argument.
of a sizeof, need to use %z to get the correct type on all our platforms.
Also, convert integers<->pointers via uintptr_t.
(I think Sam's instructions were for me to commit this. If I
misunderstood, then I apologize in advance.)
to better keep track of the total amoutn transferred during a
transfer. Seems similar to some code in the NetBSD version.
I notice they have incorporated matches from him so I don't know which
direction it went.
Submitted by: damien.bergamini@free.fr
Obtained from: patches to make the ueagle driver work
MFC after: 1 week
You could turn this off by debug.mpsafenet=0 for full network
stack or via debug.{cp|cx|ctau}.mpsafenet for cp(4), cx(4) and
ctau(4) accordingly.
MFC after: 10 days
Now only things that are different between us and NetBSD show up.
Means that these files are more of NetBSD style in some places but
since thay are NetBSD files, um, that's ok.
Obtained from: NetBSD
MFC after: 1 week
