like a valid range. We already do this in the memory case (although
the code there is somewhat different than the I/o case because we have
to deal with different kinds of memory). Since most laptops don't
have non-subtractive bridges, this wasn't seen in practice.
Evidentally the Compaq R3000 hits this problem with PC Cards.
Some minor style fixes while I'm here.
Submitted by: Jung-uk Kim
driver. This used to be handled by cpufreq_drv_settings() but it's
useful to get the type/flags separately from getting the settings.
(For example, you don't have to pass an array of cf_setting just to find
the driver type.)
Use this new method in our in-tree drivers to detect reliably if acpi_perf
is present and owns the hardware. This simplifies logic in drivers as well
as fixing a bug introduced in my last commit where too many drivers attached.
are equal to PCCARD_TPCE_FS_MEMSPACE_NONE, memspace will be zero, so
testing for this case inside of the if statement results in dead code.
We'd fail to set a value to zero that's already zero (since it is
initialized to 0 indirectly) with this code being there. Well, except
in the very rare case that we have a card that has a defualt entry
that includes a memory space followed by one that has no memory space
(these are extremely rare, I don't recall ever having seen one :-).
Fix this by setting num_memspace to 0 in a more appropriate place.
Submitted by: Coverity Prevent analysis tool
than the generic ne-2000 string. This should have no effect on the
actual support of the parts, just reporting what the part was.
Also, rename a few functins and symbols to reflect a more generic
part support that grew out of the early specific support.
or just offering info. In the former case, we don't probe/attach to allow
the ACPI driver precedence. A refinement of this would be to actually
use the info provided by acpi_perf(4) to get the real CPU clock rates
instead of estimating them but since all systems that support both
acpi_perf(4) and ichss(4) export the control registers to acpi_perf(4),
it can just handle the registers on its own.
aic7xxx.c:
Allow print_reg() to be called with a NULL column.
aic79xx.c:
Correct new usage of SCB_GET_TAG().
aic7xxx.c:
Fix stray ahd that snuck in here.
close holes in detecting busfrees that occur after a packetized target
transitions to a non-packetized phase. The most common case where this
occurs is when a target is externally reset so the controller believes
a packetzied negotiation agreement is still in effect. Unfortunately,
disabling this feature seems to cause problems for the 7901B. Re-enable
ehanced busfree detection for this part until I can get my hands on a
samble to figure out if the old workaround is necessary and, if so, how
to make it work correctly.
Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx)
deserves a big thanks for submitting initial patches to make it
work. I have mangled his contributions appropriately.
The main gotcha with Windows/x86-64 is that Microsoft uses a different
calling convention than everyone else. The standard ABI requires using
6 registers for argument passing, with other arguments on the stack.
Microsoft uses only 4 registers, and requires the caller to leave room
on the stack for the register arguments incase the callee needs to
spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall
and _fastcall, all routines on Windows/x86-64 uses the same convention.
This unfortunately means that all the functions we export to the
driver require an intermediate translation wrapper. Similarly, we have
to wrap all calls back into the driver binary itself.
The original patches provided macros to wrap every single routine at
compile time, providing a secondary jump table with a customized
wrapper for each exported routine. I decided to use a different approach:
the call wrapper for each function is created from a template at
runtime, and the routine to jump to is patched into the wrapper as
it is created. The subr_pe module has been modified to patch in the
wrapped function instead of the original. (On x86, the wrapping
routine is a no-op.)
There are some minor API differences that had to be accounted for:
- KeAcquireSpinLock() is a real function on amd64, not a macro wrapper
around KfAcquireSpinLock()
- NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole
NDIS_BUFFER API a bit to accomodate this.
Bugs fixed along the way:
- IoAllocateMdl() always returned NULL
- kern_windrv.c:windrv_unload() wasn't releasing private driver object
extensions correctly (found thanks to memguard)
This has only been tested with the driver for the Broadcom 802.11g
chipset, which was the only Windows/x86-64 driver I could find.
and into the bus front ends. For ISA and C-BUS cards, we always need
to grab it. For PC Card, already committed, we need to do some sanity
checking on the data that's in the ROMs before we decide that they are
OK to use. The PC Card code has already been committed and is
independent of this code (which also has to work on NE-1000 cards,
assuming that those cards still work :-).
with the latest changes. They actually have valid ROM data at location
0 of memory, just like a real NE-2000 ISA card. Use this data, if
the ROM passes a few basic tests, as an additional source for the MAC
address. Prefer the CIS over this source, but have it take precidence
over falling back to reading the attribtue memory.
o Minor cleanup of a few devices that we match on based on CIS string.
bridge between OLDCARD and NEWCARD for drivers to inquire after the
function number (eg, 0, 1, 2). Nobody ever used it, so retire it
with honors. NEWCARD never implemented it, and the same information
can be obtained by the pccard_get_function_number().
MFC After: 3 days
proper way, or at least the same way that NetBSD and Linux do things
(I've been unable to obtain datasheets for these parts to know for
sure). This has some marginal improvement in the DL10022 and DL10019
cards that I have. Also, report which type, exactly.
# There's one or two ed cards that I have which still don't work, but I think
# that's due to MII losage on the card that's not presently compensated
# for in the MII drivers.
tree since 2003/02/20, and I recently cleaned it up. I'd even closed
the PR that I obtained this from Fri Jul 18 23:25:08 MDT 2003 since
I looked at my p4 tree.
PR: 46889
Submitted by: HASEGAWA Tomoki
memory disk is larger than the number of available sf_bufs, this improves
performance on SMPs by eliminating interprocessor TLB shootdowns. For
example, with 6656 sf_bufs, the default on my test machine, and a 256MB
swap-backed memory disk, I see the command
"dd if=/dev/md0 of=/dev/null bs=64k" achieve ~489MB/sec with the default,
shared mappings, and ~587MB/sec with CPU private mappings.
base transfer speed to CAM. The actual value used (40MB/s) is fairly
arbitrary, but assumes the same 33% overhead as was implied by the
1MB/s figure we used for USB1 devices.
are not added to the list(s) of available settings. However, other drivers
can call the CPUFREQ_DRV_SETTINGS() method on those devices directly to
get info about available settings.
Update the acpi_perf(4) driver to use this flag in the presence of
"functional fixed hardware." Thus, future drivers like Powernow can
query acpi_perf for platform info but perform frequency transitions
themselves.
throttling, neglecting to do this kept the sysctls from appearing.
Attach an acpi_throttle device to each CPU that supports it.
Don't add a device if the P_BLK is invalid or if _PTC is not present.
This removes extraneous probe/attach failure messages on some machines.
Make the cpu throttle state local to the softc to account for partial
successes when changing the clock rate on MP machines.
for nodes hanging off of Central (untested), FireHose (untested) and
PCI (tested) busses.
- Add an additional parameter to OF_decode_addr() which specifies the
index of the register bank to decode.
These should allow to eventually add support for the Z8530 hanging off of
FireHose to uart(4) and to write support for PCI-based graphics adapters.
Suggested by: tmm (back in '03)
o Add a fallback location for the MAC address. Most of the early ne2000
PC Cards were built from the same parts, so most of them have the same
address in the CIS to grab the MAC from. Use this address as our
fallback if we don't find anything better.
o Add printf, in bootverbose, noting the MAC addresses that we find along
the way.
# Better sanity checking of the MAC address is needed. Will have to
# investigate using/creating a centralized function to do this as a number
# of other PC Card drivers each have their own ad-hoc tests.
1. Dependency on netgraph module was broken (wrong version).
2. Netgraph node type was never destroyed on unload. This
was masked by problem #1.
Fixed both by using NETGRAPH_INIT(). Now netgraph node type
is created on module load, as in the rest of netgraph modules.
at some offset. Unlike newer cards, the MAC address wasn't part of
the CIS as a specific FUNCE. These older cards were having their MAC
address show up as 0:2:4:6:8:a because that's what's in the ROM
locations that would be there in a real ne2000.
This patch allows one to specify the offset for the MAC address for
these cards. Specify one for the IBM Ethernet II card, as it is one
that has this problem. One shouldn't specify this unless the MAC
address really isn't in the CIS at all.
Side note: The novell probe likely shouldn't read the MAC address, and
that should be moved to the bus specific attach routine(s), maybe as a
convenience function in if_ed_novell.c.
My IBM Ethernet II (aka Info Mover) now has a believable MAC address.
are NOVELL NE2000 with just a tiny quirk that's non vendor specific.
Instead, use the chip_type of DL100XX instead. This is more inline
with how the AX88190 support was added, and seems a little cleaner.
pessmize the error recover path through edintr by calling these
functions, rather than expanding it inline. This error path already
does a lot in it, so an extra function call will be lost in the noise.
It also happens rarely.
while (complicated-expr)
continune;
in preference to
while (complicated-expr);
since the code generated is identical, and the former is easier to read,
especially for complicated-expr that reach to the end of the line...
Older cards have it reversed.
Also, use some already defined values instead of magic numbers.
PR: 73324
Submitted by: arne_woerner@yahoo.com
MFC after: 1 week
fix the problem with device discovery seen by some people.
2. Change to make 3ware CLI/3DM work on amd64.
3. Fix a potential problem that could cause the driver to do strlen(NULL) when
using older firmware.
Reviewed by:scottl
probing the novell ne[12]000 cards. It should be its own thing, ala
how we do the dl100xx support doing its own thing at the right time.
For the moment, it is just a function, which makes the mainline of the
generic probe easier to follow.
Also, correct a couple of comments that looked wrong.
# there may be a bug in setting up gwether, in that we set
# sc->rec_page_stop based on memsize, rather than sc->mem_size, so if
# these two are different, then the rec_page_stop will be wrong. I'm
# hesitant to fix it without real hardware to test with. Since
# gwether isn't in the hardware list of the man page nor in the commit
# messages, it is hard to know for sure.
and wd80x3 support. Make the obscure ISA cards optional, and add
those options to NOTES on i386 (note: the ifdef around the whole code
is for module building). Tweak pc98 ed support to include wd80x3 too.
Add goo for alpha too.
The affected cards are the 3Com 3C503, HP LAN+ and SIC (whatever that
is). I couldn't find any of these for sale on ebay, so they are
untested. If you have one of these cards, and send it to me, I'll
ensure that you have no future problems with it...
Minor cleanups as well by using functions rather than cut and paste
code for some probing operations (where the function call overhead is
lost in the noise).
Remove use of kvtop, since they aren't required anymore. This driver
needs to get its memory mapped act together, however, and use bus
space. It doesn't right now.
This reduces the size of if_ed.ko from about 51k to 33k on my laptop.
same as the LINKSYS COMBO_ECARD (which also seems to be the same as
another linksys product that also has a modem, but I can't find that
one at the moment). Remove the PCM100, since it is now no longer
used.
o The COMBO_ECARD comes in many flavors, it seems, so probe both the DL10019
and the AX88x90 on it. Since this seems to work with no ill effects, maybe
the probing should happen more generally rather than being table driven.
Need to think more about this.
o Remove PCM100 because it is duplicative (the ETHERFAST is the pcm100 and
apparently has the same IDs). It was here for NetBSD because they match
up an expected MAC address OID, but since we don't bother with that, we
don't need to be so finely discriminating.
o Minor style nit.
if_ed_isa.c, and they seem to not be helpful anymore.
o Fix style issues from de-Pification.
o change from _isa_ to _cbus_ to the largest extent possible to reflect that
this is really for cbus, not isa.
o Use ANSI function definitions.
o Use ed_clear_memory
o eliminate kvtop
Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can
simulate driver stacking.
In Windows, each loaded driver image is attached to a DRIVER_OBJECT
structure. Windows uses the registry to match up a given vendor/device
ID combination with a corresponding DRIVER_OBJECT. When a driver image
is first loaded, its DriverEntry() routine is invoked, which sets up
the AddDevice() function pointer in the DRIVER_OBJECT and creates
a dispatch table (based on IRP major codes). When a Windows bus driver
detects a new device, it creates a Physical Device Object (PDO) for
it. This is a DEVICE_OBJECT structure, with semantics analagous to
that of a device_t in FreeBSD. The Windows PNP manager will invoke
the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT
and the PDO.
The AddDevice() function then creates a new DRIVER_OBJECT structure of
its own. This is known as the Functional Device Object (FDO) and
corresponds roughly to a private softc instance. The driver uses
IoAttachDeviceToDeviceStack() to add this device object to the
driver stack for this PDO. Subsequent drivers (called filter drivers
in Windows-speak) can be loaded which add themselves to the stack.
When someone issues an IRP to a device, it travel along the stack
passing through several possible filter drivers until it reaches
the functional driver (which actually knows how to talk to the hardware)
at which point it will be completed. This is how Windows achieves
driver layering.
Project Evil now simulates most of this. if_ndis now has a modevent
handler which will use MOD_LOAD and MOD_UNLOAD events to drive the
creation and destruction of DRIVER_OBJECTs. (The load event also
does the relocation/dynalinking of the image.) We don't have a registry,
so the DRIVER_OBJECTS are stored in a linked list for now. Eventually,
the list entry will contain the vendor/device ID list extracted from
the .INF file. When ndis_probe() is called and detectes a supported
device, it will create a PDO for the device instance and attach it
to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call
our NdisAddDevice() handler to create the FDO. The NDIS miniport block
is now a device extension hung off the FDO, just as it is in Windows.
The miniport characteristics table is now an extension hung off the
DRIVER_OBJECT as well (the characteristics are the same for all devices
handled by a given driver, so they don't need to be per-instance.)
We also do an IoAttachDeviceToDeviceStack() to put the FDO on the
stack for the PDO. There are a couple of fake bus drivers created
for the PCI and pccard buses. Eventually, there will be one for USB,
which will actually accept USB IRP.s
Things should still work just as before, only now we do things in
the proper order and maintain the correct framework to support passing
IRPs between drivers.
Various changes:
- corrected the comments about IRQL handling in subr_hal.c to more
accurately reflect reality
- update ndiscvt to make the drv_data symbol in ndis_driver_data.h a
global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it.
- Obtain the softc pointer from the miniport block by referencing
the PDO rather than a private pointer of our own (nmb_ifp is no
longer used)
- implement IoAttachDeviceToDeviceStack(), IoDetachDevice(),
IoGetAttachedDevice(), IoAllocateDriverObjectExtension(),
IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(),
IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(),
IoInitializeIrp()
- fix a few mistakes in the driver_object and device_object definitions
- add a new module, kern_windrv.c, to handle the driver registration
and relocation/dynalinkign duties (which don't really belong in
kern_ndis.c).
- made ndis_block and ndis_chars in the ndis_softc stucture pointers
and modified all references to it
- fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they
work correctly with the new driver_object mechanism
- changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver()
(which is now deprecated)
- used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines
instead of kludged up alloc/free routines
- added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
Make the special hp versions match the general ones. Also use fixed
types in the WD80x3_generic probe, and change callers' arrays to
match. Fix a couple of minor style issues by using newstyle function
definitions in a couple places.
if_ed and rename it to ed_detach(). Tell other busses to use this
routine for detach.
Since I don't actually have any non-pccard ed hardware I can test
with, I've only tested with my pccards.
More improvements in this area likely are possible.
Prodded by: rwatson
copying data to a temporary buffer before the I/O, but also copying that
temporary buffer back to the original data location after the I/O. When
you're dumping kernel heap and stack and protected pages, this is very
very bad.
A belated thanks to Robert Watson for donating hardware for this (and future)
work.
MFC after: 3 days
practice (which we seem to mostly follow in the tree). Move the
$FreeBSD$ tag to its more proper place after all copyright and license
notices. Add '-' to the copyright notice for Christian E. Hopps so my
copyright script picks it up.
resulting in a size_t due to C's rules of arithmetic. Rather than
bogusly cast the result to a uint8_t, fix the printf format specifier
to have a 'z' modifier which tells the compiler that the sizes really
do match.
It turns out that change 1.75 was incorrect to assume that this
'really' was a 8bit quantity. It isn't. Although the hardware
appears to limit things to < 256, it would be a bug that should be
caught by debug printf it it were. Casting it to uint8_t would have
lost this useful information.
Aslo add 'z' to a nearby debug statement that's never compiled in.
They have nothing at all to do with CIS parsing.
Remove some unused funce parsing: nothing used the results.
Use more of pccard_cis.h's deifnitions for the cardbus specific cis
parsing we do. More work is needed in this area.
This reduces the size of the cardbus module by 380 bytes or so...
doing it in the cpu driver. The previous code was incorrect anyway since
this value controls Px states, not throttling as the comment said. Since
we didn't support Px states before, there was no impact. Also, note that
we delay the write to SMI_CMD until after booting is complete since it
sometimes triggers a change in the frequency and we want to have all
drivers ready to detect/handle this.
uses the i8237 without trying to emulate the PC architecture move
the register definitions for the i8237 chip into the central include
file for the chip, except for the PC98 case which is magic.
Add new isa_dmatc() function which tells us as cheaply as possible
if the terminal count has been reached for a given channel.
devclass. As pointed out by dfr@, devclasses don't have to share the same
linkage if multiple drivers have the same name. Newbus should match the
devclasses based on name and allocate non-conflicting unit numbers.
the PERF_CTRL register in our probe method so that we can tell earlier
that another driver should handle this device due to FFixedHW. This avoids
scaring users when attach failed when we really wanted probe to fail.
type. This is needed if the resource is to be released later. The RID is
still also present, though less necessary since rman_get_rid() can be used
to obtain it from the resource.
settings as exported via the ACPI _PSS method. OEMs use this interface
to encapsulate chipset or processor-specific methods (e.g., SpeedStep or
Powernow) and export their settings in a standard way. On systems that
have valid ACPI Performance states and a hardware-specific driver (e.g.,
ichss), acpi_perf(4) is preferred.
release) the sio spin mutex, as use of synchronization primitives in
the debugger can result in substantial problems. With this patch in
place entering the debugger via a serial console is made
substantially more reliable.
MFC after: 1 week
Tested by: kris
Discussed with: bde
The cause of "Duplicate mbuf free panic" is in the programming
error of hme_load_txmbuf(). The code path of the panic is the
following.
1. Due to unknown reason DMA engine was freezed. So TX descritors
of HME become full and the last failed attempt to transmit a
packet had set its associated mbuf address to hme_txdesc
structure. Also the failed packet is requeued into interface
queue structure in order to retrasmit it when there are more
available TX descritors.
2. Since DMA engine was freezed, if_timer starts to decrement its
counter. When if_timer expires it tries to reset HME. During
the reset phase, hme_meminit() is called and it frees all
associated mbuf with descriptors. The last failed mbuf is also
freed here.
3. After HME reset completed, HME starts to retransmit packets
by dequeing the first packet in interface queue.(Note! the
packet was already freed in hme_meminit()!)
4. When a TX completion interrupt is posted by the HME, driver
tries to free the successfylly transmitted mbuf. Since the
mbuf was freed in step2, now we get "Duplicate mbuf free panic".
However, the real cause is in DMA engine freeze. Since no fatal
errors reported via interrupts, there might be other cause of
the freeze. I tried hard to understand the cause of DMA engine
freeze but couldn't find any clues. It seems that the freeze
happens under very high network loads(e.g. 7.5-8.0 MB/s TX speed).
Though this fix is not enough to eliminate DMA engine freeze it's
better than panic.
Reported by: jhb via sparc64 ML
CIS, weren't actually used anywhere (other than the generic PC Card
code when certain variables are defined). They aren't used in NetBSD
either. Make things simpler by removing them. Change PLANEX_2 to
PLANEX and tweak wi and owi to use that instead. The PLANEX id seems
to actually be pci ID assigned to planex, not its pcmcia id. Ooops.
I don't know if this is a reporting error from where this entry came
from, or if it is a mistake on PLANEX's part. I suspect the latter,
as ACTIONTEC and NEWMEDIA made the same mistake (although new media
may be because it uses an advansys chip inside). Make a note of this
in the file. The 0xc entires may be JEITA assigned, so note that as
well.
# This leaves just 3 entries that are totally unknown: airvast, archos
# and edimax although the arivast number is the same assigned to
# avertec in usb...
This driver implements "unaddressed listen only mode", which is what
printers and plotters commonly do on GP-IB busses.
This means that you can capture print/plot like output from your
instruments by configuring them as necessary (good luck!) and
cat -u /dev/gpib0l > /tmp/somefile
Since there is no way to know when no more output is comming you
will have to ctrl-C the cat process when it is done (that is why
the -u is important).
The presence or absence of a keyboard does not change whether an
UART is designed as a keyboard port or not and thus whether we
can use the port as a TTY or not.
We now call sunkbd_attach() even when we didn't previously find
a keyboard. Emit a useful message stating that no keyboard was
found, but don't do anything else.
MFC after: 5 days
ServeRAID 4 - 7 models right now. Support for older cards is possible, but
I don't have any hardware to experiment with.
Thanks to Jack Hammer at Adaptec for providing debugging hints.
Sponsored by: ImproWare AG, Switzerland
engineering the pending interrupt sources from the current
state of the controller. For channel A we can always read the
interrupt pending register (RR3). For channel B we can read
the interrupt vector register (RR2) because it contains the
modified vector and thus includes the interrupt source.
Since we currently need puc(4) for the Z8530, we know that
the interrupt handler for both channels will be called and
thus that RR3 will always be read at least once, even if ch A
has no pending interrupt.
NOTE: The modified interrupt vector has no value that represent
a lack of pending interrupt for channel B. That is, the
value read when no interrupts are pending is the same as the
value for the special receive condition. Fortunately, we don't
actually have to depend on that interrupt source. This does
mean that we need to properly handle the overflow condition,
when we read received character from the chip.
o The DSR signal is represented by the SYNC bit in the external
status register (RR0). We now properly track DSR.
o It's save to enable the external/status interrupt source. We
now get interrupts when line signals (DSR, DCD or CTS) change.
Problems fixes:
o interrupt storms.
o blocked open(2).
o lack of (hardware) flow control.
o unable to report DSR.
MFC after: 5 days
providing special version of CDIOCREADSUBCHANNEL ioctl(), which assumes that
result has to be placed into kernel space not user space. In the long run
more generic solution has to be designed WRT emulating various ioctl()s
that operate on userspace buffers, but right now there is only one such
ioctl() is emulated, so that it makes little sense.
MFC after: 2 weeks
thought. I'm unsure why I thought this was the case, but it
definitely isn't for this card. If another card with the other ID
makes an appearance, then we'll add a second entry for it.
# With this change my Olicom OC2220 is now working again, since I make
# this commit with that device. :-)
EtherJet, the interrupt is selected in the eeprom based on the layout
of the PC Card board. Since this is encoded into the EEPROM, and has
no relationship to the IRQ that the pccard bridge routes the PC Card's
interrupt pin to.
As such, stop writing to that register. This gets my EtherJet working.
# The eeprom reading code appears to be totally wrong for my EtherJet
# card. This causes the card to bogusly detect the media options
# available.
significant clean up and optimizations:
- don't call bioq_disksort() on every command, the hardware will do that for
us.
- remove all of the complicated bio deferral code. bio's that can't be
serviced immediately can just wait on the bioq.
- Only reserve one command object for doing control commands to the card.
This simplifies a lot of code and significantly reduces the size of the
command struct.
- Allocate commands out of a slab instead of embedding them into the softc.
- Call the command action method directly instead of having ips_get_free_cmd()
call it indirectly.
MFC After: 1 week
null-modem tty device emulate the speed settings faithfully.
The speed is emulated independently for the two directions, using
the slower of the local sides ispeed and the remote sides ospeed.
The emulated speed takes settings of bits/char, parity and stopbit
into account.
Inspired by: The BSD-DK Editor Celebrity Deathmatch Contest
the interface when going to toggle VLAN support for
internal reasons. If the IFCAP_VLAN_HWTAGGING bit is
cleared, we should rely on the (re)init routine to turn
VLAN support off and never touch the relevant hardware bits.
This applies to other capability bits, too. The user
obviously has a reason for clearing a capability bit,
e.g., if his particular NIC is buggy and hangs if a
certain hardware capability is turned on even for a
fraction of a second.
The flag adapter->em_insert_vlan_header still is set or
reset irrespective of the IFCAP_VLAN_HWTAGGING setting,
as before, in order to handle the case when a user sets
promiscuous mode on an interface first and later turns
its IFCAP_VLAN_HWTAGGING bit on.
This change might look orthogonal to rev#1.85, but in fact
it is not. It introduces bugfixes that hopefully will make
implementing the general scheme mentioned in the commit
message of rev#1.85 easier.
configuration: it appears to work properly in the non-promiscuous case, but
we've not yet implemented a more general solution that maintains full
functionality with promiscuous mode enabled. While my hope is that we can
get one implemented soon, this will improve functionality substantially in
the mean time.
MFC after: 3 days
AX88190 ones, but that one only minorly):
o don't set flags in the match routine. They appear to be cleared
when probe/attach is called. Before this change, they were
always treated as a simple ne2000, which would fail to get the
right NIC address.
o Lookup device again in the probe routine and probe based on the
cards that you see.
o Detect and report the DL10022 seprately from the DL10019 cards.
While I'm here:
o remove a bad printf
o change another bad printf to device_printf.
o minor style(9) formatting tweaks.
# note: a lot of OEM entries are in the ed_pccard_products such that we can
# likely remove, or collapse, many of them.
This makes all of my DL100xx cards at least probe the ethernet address
correctly, which it wasn't doing before. I can't seem to locate my
AX88xxx based cards, so those haven't been tested, but they were
busted before the change so they can't be any worse now...
address, and additional information. Then the printing of the
ethernet address was moved into ether_attach, and so we were printing
orphaned information about the card. Now the probe message is
prefixed by edX:. Prepare for it to move under bootverbose, but don't
move it there yet (the || 1 trick).
versions of the Racore PC Card Ethernet card. Rearrange to reflect
this reality. This ejects IODATA from 0x1bf, which belongs to Racore.
Thanks to Wilko for providing me with a dumpcis for the DEPCM card.
Also, added Nextcom Nexthawk card from NetBSD
o mark rx frames including FCS in the payload with the
IEEE80211_RADIOTAP_F_FCS flag
o remove hack to copy 802.11 headers with padding out of line; instead mark
the frames with IEEE80211_RADIOTAP_F_DATAPAD and require applications to
do the work
o split precalculated radiotap flags into tx+rx now that they can be different
Note the full usefulness of these changes depends on updates to applications
that process radiotap data.
o don't reclaim any previous beacon state in ath_beacon_alloc; do it
explicitly in ath_newstate
o reference count the node held in the beacon frame state block
o process ibss merge more intelligently; let the state machine do the
right thing instead of explicitly setting the new bssi id
o explicitly stop tx dma before doing beacon setup to handle the ibss
merge case
USB device support):
- Convert all of my locally chosen function names to their actual
Windows equivalents, where applicable. This is a big no-op change
since it doesn't affect functionality, but it helps avoid a bit
of confusion (it's now a lot easier to see which functions are
emulated Windows API routines and which are just locally defined).
- Turn ndis_buffer into an mdl, like it should have been. The structure
is the same, but now it belongs to the subr_ntoskrnl module.
- Implement a bunch of MDL handling macros from Windows and use them where
applicable.
- Correct the implementation of IoFreeMdl().
- Properly implement IoAllocateMdl() and MmBuildMdlForNonPagedPool().
- Add the definitions for struct irp and struct driver_object.
- Add IMPORT_FUNC() and IMPORT_FUNC_MAP() macros to make formatting
the module function tables a little cleaner. (Should also help
with AMD64 support later on.)
- Fix if_ndis.c to use KeRaiseIrql() and KeLowerIrql() instead of
the previous calls to hal_raise_irql() and hal_lower_irql() which
have been renamed.
The function renaming generated a lot of churn here, but there should
be very little operational effect.
NetBSD went this route a while ago. FreeBSD originally tried this to
cope with multifunction cards. However, it turns out that we're
better off not worrying about the function number, and instead worry
about the function type for the function. This has worked well in
NetBSD, and all FreeBSD's relevant drivers have been converted.
# I'll rework the macros that specify them shortly, as soon as I can
# come up with a good, compatible way to deal...
Use the correct number of handles for multihandle returns.
Very, very, rarely on some SMP systems we've seen an 'unstable' type
in the response queue. I dunno whether or not it's a bug in our
handling, or whether there's a cache incoherency issue, but
try to guard against it.
MFC after: 2 weeks
in mddestroy() to properly free already allocated memory.
This fixes a panic when we want to create too big memory backed device
with preallocate memory (-o reserve).
- Remove redundant { }.
MFC after: 1 week
address, nor do we need the alignment requirements, so eliminate them.
This likely means that we can now collapse some of the entries as we
have no need of them anymore (they match other entries and were there
only to get the right attr memory offset of the enet addr).
cards work. These changes depend on the expanded funce parsing that
just was committed to pccard_cis.c. In NetBSD the ethernet address
was read out of attr memory directly. We rely on the kernel pccard
parser to pulll this information out of what appears to be an obsolete
funce with the information in it.
# I'm still getting the no rx interrupt sometimes with some hub/switches
# for reasons unknown... But usually only one and only when dhclient
# runs.
as type 0, rather than the usualy type 4. Assume that this format is
from an old standard and go with it. The Fujitsu FMV-186A and Silicom
Ethernet cards I have both have tuples with this format, and they are
both pretty old cards.
# if somebody knows for sure, please let me know.
aware of any fe based cards that do anything except network (well,
maybe the fujitsu scsi/lan card, but I've only seen two of those on
ebay in the last 3 years).
virtual COM port. This makes the use of the Dell OpenManage tools on FreeBSD
considerably easier, and is based on Chuck Cranor's original patch for 4.6.
Reviewed by: imp
Tested by: dpk at dpk dot net
MFC after: 1 week
o rework pll setup code to follow h/w specification
o add hint.hifn.X.pllconfig to specify reference clock setup
requirements; default is pci66 which means the clock is
derived from the PCI bus clock and the card resides in a
66MHz slot
Tested on 7955 and 7956 cards; support for 7954 cards not enabled
since we have no cards to test against.
In collaboration with Poul-Henning Kamp.
Reviewed by: phk
MFC after: 1 week
Rather than have a twisty maze of special case allocations, move
instead to a data driven allocation. This should be the most robust
way to cope with the resource problems that the multiplicity of ways
of encoding 5 registers that have the misfortune of not being a power
of 2 nor contiguous.
Also, make it less impossible that pccard will work. I've not been able
to get my libretto floppy working, but it now fails later than before.
phk and I had similar ideas on this during the 5.3 release cycle, but
it wasn't until recently that I could test more than one allocation
scenario.
MFC After: 1 month (5.4 if possible, 5.5 if not)
producers rather than consumers as new-bus resources only handle consumed
resources. We already do this for the other ACPI resource types that
support the producer/consumer attribute.
object (/) rather than the pci bus object when walking the _PRT to force
attach devices. We already look up relative to the root object when doing
interrupt routing.
Suggested by: njl
For such devices, we require _PRS to exist and we warn if any of the
resources in _PRS are not IRQ resources (since we'll have no way of knowing
which of those resources to use without a working _CRS). When it does
come time to set resources, we build up a resource buffer from scratch
as we do for devices with _CRS that only have IRQ resources.
- Fix a bug with setting extended IRQ resources where we set the IRQ value
in the wrong resource structure meaning that whichever IRQ was listed in
_PRS was used instead. This might fix some weird issues on certain boxes
where IRQs > 16 don't seem to work when using ACPI.
- Fix a bug with how we walked the resource buffer after _SRS to call
config_intr() in that the 'end' variable was not properly updated, so we
could either terminate the loop early or loop after the end of the
buffer.
Tested by: pjd
o increase the max per-frame tx descriptor count and the number of tx
buffers for forthcoming fast frame support
o correct the max scatter/gather count; it cannot be larger than the
max(tx,rx,beacon) descriptor counts
(fix imported from madwifi by Takanori Watanabe)
o eliminate save/restore of pci registers handled by the system
o eliminate duplicate zero of the softc (noted by njl)
o consolidate common code
MFC after: 1 week
for the vast majority of our cards. However, they are critically
needed to distinguish different fe based PC Cards (the FMV-182 from
the 182A) which need to be treated differently (the ethernet address
is loaded not from the standard CIS-based ethernet tuples, but from
differing locations in attribute space based on the version string in
CIS3. This should have no impact for other users of this function.
- Introduce the amr_io_lock to control access to command queues, bio queues,
and the hardware.
- Eliminate the taskqueue and do all completion processing in the ithread.
- Assign a static slot number to each command instead of doing a linear
search for free slots each time a command is needed.
- Modify the interrupt handler to more closely match what Linux does, for
safety.
read the ethernet address from the attribute space hasn't been
implemented. Also add flags for the MBH10302. The flags and maddr
fields will be used when reading from the attribute space...
allows my 3com cards to work again. It appears that this code was
once there, but I removed it when I added the alignment issues.
MFC After: 5 days
PR: 70639 (and likely others)
o Implement a shiny new algorithm to keep track of finger movement at
slow speeds. This dramatically reduces the level of questionable
language from users trying to resize windows.
o Properly catch the many extra buttons and dials which manufacturers
are known to screw onto Synaptics touchpad controllers. Currently,
up to seven buttons are known to work, more should work too.
o Add a number of sysctls allowing one to tune the driver to taste in
a simple way:
# Should the extra buttons act as axes or as middle button
hw.psm.synaptics.directional_scrolls
# These control the 'stickiness' at low speeds
hw.psm.synaptics.low_speed_threshold
hw.psm.synaptics.min_movement
hw.psm.synaptics.squelch_level
PR: kern/75725
Submitted by: Jason Kuri <jay@oneway.com>
MFC after: 1 month
fe1: <EAGLE Technology NE200 ETHERNET LAN MBH10302 04>
As reported by Sean Shapira. This appears to be working. Eagle used
Fujitsu's vendor number, with a product number of 4 (which is the same
as the vendor number, which is a little suspect). Since there's no
apparent conflict, go ahead and use it.
Submitted by: Sean Shapira
card, and works with that driver. However, Eagle is using Fujitsu's
vendor number and a product code of 4, which seems a little odd.
Still, there's no conflicts...
1/ doesn't matter on most of our architectures
2/ will never happen unless we start queueing multiple trasactions
to a single endpoint at one time (which we do not allow yet).
If anyone has a big_endian machine with EHCI they might check this
if they are having problems with EHCI but it's unlikely even there..
Submitted by: Hans Petter Selasky <hselasky@c2i.net>
MFC after: 3 days
place device objects in \ (in this case, PCI links.) Work around this by
starting our probe from \. To avoid attaching system scope objects,
explicitly skip them. (I think it's an ACPI-CA bug that \_SB and \_TZ have
device and thermal object types.) Thanks to pjd@ for testing.
MFC after: 2 weeks
to be the same as Boca Research Turbo Serial 654 (4 serial port).
While add the 8 port variants as well.
Submitted by: sten@blinkenlights.nl
PR: kern/75793
MFC after: 1 week
The main changes are:
1. Use of multiple bus dma tags.
2. Timing of CAM requests by the driver.
3, Firmware interface change relating to retrieving AEN's.
4. Removal of twa_intrhook.
5. Bundling of latest firmware with BBU capability.
Reviewed by:re
Approved by:re
interface as well. This is not an expected revision id per the
datasheet, but unfortunately there are such cards out there with
a 82557 chipset, and they want to use the 82503.
PR: kern/75739
Reported by: Andre Albsmeier <andre.albsmeier@siemens.com>
o Move the sysctls under debug.psm.* and hw.psm.* making them a bit
clearer and more consistent with other drivers.
o Remove the debug.psm_soft_timeout sysctl. It was introduced many
moons ago in r1.64 but never referenced anywhere.
o Introduce hw.psm.tap_threshold and hw.psm.tap_timeout to control
the behaviour of taps on touchpads. People might like to fiddle
with these if tapping seems to slow or too fast for them.
o Add debug.psm.loglevel as a tunable so that verbosity can be set
easily at boot-time (to watch probes and such) without having to
compile a kernel with options PSM_DEBUG=N.
