last in the list rather than first.
This makes the resouces print in the 4.x order rather than the 5.x order
(eg fdc0 at 0x3f0-0x3f5,0x3f7 is 4.x, but 0x3f7,0x3f0-0x3f5 is 5.x). This
also means that the pci code will once again print the resources in BAR
ascending order.
same value as the previous ioctls so no binary change. Also, make a few
style changes to reduce diffs to my tree.
Loosely based on code from: Hans Petter Selasky
system have been attached, but no later. This ensures that we do
not explore ohci or uhci busses before the companion echi controller
has been initialised, so it should fix the problem of multi-speed
USB devices getting attached as USB 1 devices first and then
re-attached as USB 2.
Some further changes are needed on architectures that do not currently
allow hooks to be inserted before configure_final() - alpha, ia64,
powerpc and sparc64. On these architectures the exploration will
now be delayed until the usb kthread runs.
Do our best to plug some memory leaks (VPD data, jumbo memory buffer,...).
Log if we cannot free because memory still in use[1].
Change locking to avoid ''acquiring duplicate lock of same
type: "network driver"'' and potential deadlock. Also seems to fix LOR #063.
[1] This change does not solve problems if buffers are still in use when
unloading if_sk.ko. There is ongoing work which will address jumbogram
allocations in a more general way.
PR: kern/75677 (with changes, no mii fixes in here)
Tested by: net, Antoine Brodin (slightly different version)
Approved by: rwatson (mentor)
MFC after: 5 days
Obtained from: NetBSD if_sk.c rev. 1.11
* Take PHY out of reset for Yukon Lite Rev. A3.
Submitted by: postings on net@ in thread "skc0: no PHY found", 2005-02-22
Tested by: net
Approved by: rwatson (mentor)
MFC after: 5 days
if the interface is marked RUNNING.
Obtained from: NetBSD if_sk.c rev. 1.12
* 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 elicits the DHCPACK.
Obtained from: OpenBSD if_sk.c rev. 1.56
* Additional locking changes in sk_ioctl.
PR: kern/61296 should see improvements by the last two.
Approved by: rwatson (mentor)
MFC after: 5 days
doing that in bfe_stop().
This should fix a panic recently reported on -current occuring when taking
device down then up. In the original implementation, an "ifconfig bfe0 down"
triggers bfe_stop(), which also destroys all TX/RX descriptor dmamaps. Hence
the subsequent "ifconfig bfe0 up" would force the device to use those
already-released dmamap and thus panic the kernel.
PR: kern/77804
Submitted by: Frank Mayhar <frank at exit dot com>
Reviewed by: dmlb, sam (mentor)
Tested by: Phil <pcasidy at casidy dot com>, myself
MFC after: 1 week
that we free that resource. All the other resources are freed in
their own routine, but since we haven't saved a pointer to this one,
it is leaked. This is the failure case that lead to the sio ports
that weren't working, I think.
cleared if the host controller retries the transfer and is successful,
but we were interpreting these bits as indicating a fatal error.
Ignore these error bits, and instead use the HALTED bit to determine
if the transfer failed. Also update the USBD_STALLED detection to
ignore these bits.
Obtained from: OpenBSD
between passes over a QH. Previously the accesses to a QH were
bunched together in time, so the interval was often much longer
than intended. This now appears to match the diagrams in the EHCI
spec, so remove the XXX comment.
a serial console anyway because input-device is set to keyboard and
output-device is set to screen but no keyboard is plugged in don't
assume that a device node for the input-device alias exists. While
this is true for RS232 keyboards (the node of the SCC and UART
respectively which controls the keyboard doesn't disappear when no
keyboard is plugged in) this assumption breaks for USB keyboards.
It's most likely also not true for PS/2 keyboards but OFW doesn't
reliably switch to a serial console when the potential keyboard is
a PS/2 one which isn't plugged in so this couldn't be verified
properly.
Reported by: Will Andrews <will@csociety.org>, obrien
MFC after: 1 week
to syncrhonize access to the data as a result. This makes the pps
less likely to miss the 1ms pulse that I'm feeding it, but not
entirely reliable yet on my 133MHz P5.
Reviewed by: phk
unknown (since my sony vaio didn't :-(.
Instead, fix the problem described by 1.49 in a different way: just
add the two calls I'd hoped I'd avoid in 1.49 by doing the (wrong)
gymnastics there. While 1.49 is a good direction to go in, each step
of the way should work :-(.
resources. When allocating 6 ports for a 4 port range isa code
returns an error. I'm not sure yet why this is the case, but suspect
it is just a non-regularity in how the resource allocation code works
which should be corrected. Use 1 as the ports size in this case.
However, in the hints case, we have to specify the length, so use 6 in
that case. I believe that this is also acpi friendly.
Also, complain when we can't allocate FDOUT register space. Right now we
silently fail when we can't. This failure is referred to above.
When there's no resource for FDCTL, go ahead and allocate one by hand.
Many PNPBIOS tables don't list this resource, and our hints mechanism also
doesn't cover that range. If we can't allocate it, whine, but fake up
something. Before, we were always bogusly faking it and no one noticed
the sham (save the original author who has now fixed his private shame).
asks that each buffer be (2048 * 256) bytes long. I suspect that alignment
isn't a real requirement since busdma only recently started honoring it. The
size is also bogus. Fix both of these and stop busdma from trying to
exhaust the system memory pool with bounce pages.
Submitted by: Kevin Oberman
MFC After: 7 days
- Fix a bug in the same condition where we forgot to drop the ACPI pcib
lock. This fixes hangs after the pcib0 attach on some machines.
Tested by: sos (2)
ever working correctly: the code was linking the QHs together but
then immediately overwriting the "next" pointers. Oops. Also
initialise qh_endphub, since the EHCI spec says that we should
always set the pipe multiplier field to something sensible.
This appears to make basic split transactions work, so enable split
transactions for control, bulk and interrupt pipes (split isochronous
transfers are not yet implemented). It should now be possible to
use USB1 devices even when they are connected through a USB2 hub.
from an mbuf into the fxp_encap() function, as done in other drivers.
- Don't waste time calling bus_dmamap_load_mbuf() if we know the mbuf
chain is too long to fit in a TX descriptor, call m_defrag() first.
- Convert fxp(4) to use bus_dmamap_load_mbuf_sg().
at some point result in a status event being triggered (it should
be a link down event: the Microsoft driver design guide says you
should generate one when the NIC is initialized). Some drivers
generate the event during MiniportInitialize(), such that by the
time MiniportInitialize() completes, the NIC is ready to go. But
some drivers, in particular the ones for Atheros wireless NICs,
don't generate the event until after a device interrupt occurs
at some point after MiniportInitialize() has completed.
The gotcha is that you have to wait until the link status event
occurs one way or the other before you try to fiddle with any
settings (ssid, channel, etc...). For the drivers that set the
event sycnhronously this isn't a problem, but for the others
we have to pause after calling ndis_init_nic() and wait for the event
to arrive before continuing. Failing to wait can cause big trouble:
on my SMP system, calling ndis_setstate_80211() after ndis_init_nic()
completes, but _before_ the link event arrives, will lock up or
reset the system.
What we do now is check to see if a link event arrived while
ndis_init_nic() was running, and if it didn't we msleep() until
it does.
Along the way, I discovered a few other problems:
- Defered procedure calls run at PASSIVE_LEVEL, not DISPATCH_LEVEL.
ntoskrnl_run_dpc() has been fixed accordingly. (I read the documentation
wrong.)
- Similarly, the NDIS interrupt handler, which is essentially a
DPC, also doesn't need to run at DISPATCH_LEVEL. ndis_intrtask()
has been fixed accordingly.
- MiniportQueryInformation() and MiniportSetInformation() run at
DISPATCH_LEVEL, and each request must complete before another
can be submitted. ndis_get_info() and ndis_set_info() have been
fixed accordingly.
- Turned the sleep lock that guards the NDIS thread job list into
a spin lock. We never do anything with this lock held except manage
the job list (no other locks are held), so it's safe to do this,
and it's possible that ndis_sched() and ndis_unsched() can be
called from DISPATCH_LEVEL, so using a sleep lock here is
semantically incorrect. Also updated subr_witness.c to add the
lock to the order list.
Change fhc(4) to use IRQ numbers instead of RIDs for allocating the
IRQs of children. This works similar to e.g. sbus(4), i.e. add the
IRQ resources as fully specified to the resource lists of the children,
allocate them like normal. When establishing the interrupt search the
interrupt maps of the children for a matching INO to determine which
map we need to write the fully specified interrupt number to and to
enable the mapping (before the RID was used to indicate which interrupt
map to use).
- dev/puc/puc.c:
Revert rev. 1.38, with the above change fhc(4) no longer needs special
treatment for allocating IRQs.
Thanks to: joerg for providing access to an E3500
modulating the STPCLK# pin based on the duty cycle. Since p4tcc uses the
same mechanism (but internal to the CPU), we triggered a hang on some
systems at low frequencies when both were in use. Now, disable
acpi_throttle when p4tcc is also present.
Tested by: Kevin Oberman
with no associated data. Also revert previous changes that allocate off
of the stack instead of using malloc, as it's not needed. Many thanks to
LSI for investigating and fixing these problems.
Submitted by: rajeshpr @ lsil . com
a vlan interface attached to a fxp(4) card when it has not been
initialized yet. We now set the links from our internel TX descriptor
structure to the TX command blocks at attach time rather than at init
time. While I'm here, slightly improve the style in fxp_attach().
PR: kern/78112
Reported by: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> and others
Tested by: flz, Gavin Atkinson <gavin.atkinson@ury.york.ac.uk>
MFC after: 1 week
place.
This moves the dependency on GCC's and other compiler's features into
the central sys/cdefs.h file, while the individual source files can
then refer to #ifdef __COMPILER_FEATURE_FOO where they by now used to
refer to #if __GNUC__ > 3.1415 && __BARC__ <= 42.
By now, GCC and ICC (the Intel compiler) have been actively tested on
IA32 platforms by netchild. Extension to other compilers is supposed
to be possible, of course.
Submitted by: netchild
Reviewed by: various developers on arch@, some time ago
set the interrupt handler to be INTR_MPSAFE now that xpt_done() can be
called without Giant. Giant is still on the top half of the driver and
the timeout handlers.
with shared IRQs in case the bus code, MD interrupt code, etc. permits.
Together with sys/sparc64/sparc64/intr_machdep.c rev. 1.21 this fixes
an endless loop in uart_intr() when using the second NS16550 on the ISA
bus of sparc64 machines.
- Destroy the hardware mutex on detach and in case attaching fails.
Approved by: marcel
Failure to do this will result in following ata_pio_read() calls walking
off the end of the read buffer.
This resolves the "memory modified after free" panics common with Thinkpads
and CD/DVD drives.
Submitted by: Nate Lawson <nate AT root.org>
idle the 'mask' variable could be set to 0, resulting in the timeout loop
running for the full 31 seconds.
Handling this case eliminates long hangs on resume on some systems.
Submitted by: Nate Lawson <nate AT root.org>
and the X1034A (quad HME; QFE) cards the X1033A (single HME) don't have a
PCI-PCI-bridge so we can't rely on the PCI slot number being useable as
index for the network address to read from the VPD on the latter. Use
the end tag to determine whether it is a QFE VPD with 4 NAs and only use
the slot number as index in this case.
- Remove a useless check.
Prodded by: joerg
Additional testing by: joerg
MFC after: 1 day
o usb_subr.c, add delta 1.119:
Move usb_get_string() and make it public.
o usbdi.c, bring on par with 1.106, this includes:
- Make an iterator abstraction for looping through all descriptors.
- Whine about not being able to figure out default language if we are debugging.
- Move usb_get_string() and make it public.
o usbdi.h, bring on par with 1.64, this includes:
- Make an iterator abstraction for looping through all descriptors.
- Move usb_get_string() and make it public.
o usbdi_util.c, bring on par with 1.42, this includes:
- Add usbd_get_protocol().
- Use NULL instead of 0.
- Fix (mostly harmless) typo.
- Move utility routine from uirda.c to usbdi_util.c.
o usbdi_util.h, bring on par with 1.31, this includes:
- Add usbd_get_protocol().
- Move utility routine from uirda.c to usbdi_util.c.
MFC after: 3 days
is particularly useful when VESA is available (either `options VESA'
or load the vesa module), as BIOSes in some notebooks may correctly
save and restore LCD panel settings using VESA in cases where calling
the video BIOS POST is not effective. On some systems it may also
be necessary to set the hw.acpi.reset_video sysctl to 0.
yet I only changed one of them. So when we loaded drivers, we'd fail
to allocate resources correct.
This pointed out that we were doing the wrong thing when we failed to
attach a child. We released all the resources and almost deleted the
child. Instead, we should keep the resources allocated so when/if a
driver is loaded, we can go w/o having to allocate them. We use
pci_cfg_save/restore to restore the BARs with these resources.
This seems to fix the problems that we were seeing that I thought
might have magically gone away in the last revision of cardbus.c (but
really didn't).
Noticed by: avatar (nicely done!)
testing it to know whether we should enable the 82503 serial mode...
Move code to the right location and disallow the use of the 82503
serial mode if the sc->revision field is 0 again. This makes fxp(4)
work correctly with ATMEL 350 93C46 cards (3 port 82559 based with a
82555 PHY), as well as with the older ATMEL 220 93C46 (same flavour)
and with the even older 10Mbps-only 82557 cards with the 82503 serial
interface.
Tested by: Andre Albsmeier <andrer@albsmeier.net>, krion
MFC after: 2 weeks
SMP systems. It appears all drivers except ichss should attach to each
CPU and that settings should be performed on each CPU. Add comments about
this. Also, add a guard for p4tcc's identify method being called more than
once.
uart(4) to support the Zilog 8530 SCCs which hang off of a FireHose
bus on Sun E4000/E5000 class machines.
Beside the fact that a puc_fhc.c would just be a copy of puc_sbus.c
with s,sbus,fhc,g the reason why the declaration for fhc(4) was
sticked into puc_sbus.c is that both of these front-ends for puc(4)
will go away once there is a scc(4).
Discussed with: marcel
Tested by: hrs, kris
MFC after: 3 days
both a scc(4) is under way and fhc(4) will be change to use INOs this
shouldn't stay in HEAD for too long but we need a MFC-able solution
for FreeBSD 5.4.
Discussed with: marcel
Tested by: hrs, kris
MFC after: 3 days
for a given device in some circumstances, so move the PDO creation
to the attach routine so we don't end up creating two PDOs.
Also, when we skip the call to ndis_convert_res() in if_ndis.c:ndis_attach(),
initialize sc->ndis_block->nmb_rlist to NULL. We don't explicitly zero
the miniport block, so this will make sure ndis_unload_driver() does
the right thing.
when we create a PDO, the driver_object associated with it is that
of the parent driver, not the driver we're trying to attach. For
example, if we attach a PCI device, the PDO we pass to the NdisAddDevice()
function should contain a pointer to fake_pci_driver, not to the NDIS
driver itself. For PCI or PCMCIA devices this doesn't matter because
the child never needs to talk to the parent bus driver, but for USB,
the child needs to be able to send IRPs to the parent USB bus driver, and
for that to work the parent USB bus driver has to be hung off the PDO.
This involves modifying windrv_lookup() so that we can search for
bus drivers by name, if necessary. Our fake bus drivers attach themselves
as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them
using those names.
The individual attachment stubs now create and attach PDOs to the
parent bus drivers instead of hanging them off the NDIS driver's
object, and in if_ndis.c, we now search for the correct driver
object depending on the bus type, and use that to find the correct PDO.
With this fix, I can get my sample USB ethernet driver to deliver
an IRP to my fake parent USB bus driver's dispatch routines.
- Add stub modules for USB support: subr_usbd.c, usbd_var.h and
if_ndis_usb.c. The subr_usbd.c module is hooked up the build
but currently doesn't do very much. It provides the stub USB
parent driver object and a dispatch routine for
IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at
the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub
compiles, but is not hooked up to the build yet. I'm putting
these here so I can keep them under source code control as I
flesh them out.
chipset. Add support for this card. Office Max has them on sale and
I was surprised that we didn't have it in our supported list when I
plugged it in...
IRQ 0 and not an ExtINT pin. The MADT enumerators ignore the PC-AT flag
and ignore overrides that map IRQ 0 to pin 2 when this quirk is present.
- Add a block comment above the quirks to document each quirk so that we
can use more verbose descriptions quirks.
MFC after: 2 weeks
It is _never_ OK to find a vnode from a struct cdev because you have
no way of telling if you get the right one. You might be in jail or
chroot for instance.
modes, systems may take longer. If the status values don't match, try
matching just the lowest 8 bits if no bits above 8 are set in the desired
value. The IBM R32 has other bits set in the status register that are
irrelevant to the expected value.
the switch. Other interim tests (i.e., for minimum runtime) could
invalidate the start time. This fixes transitions to cooler states in that
now they go to the next active state (_AC0 -> _AC1) instead of going
straight to off (_AC0 -> off).
Submitted by: Alexandre "Sunny" Kovalenko (Alex.Kovalenko / verizon.net)
locks held, specify the ACPI_ISR flag to keep it from acquiring any more
mutexes (which could potentially sleep.) This should fix "could sleep"
warning messages on the following path:
msleep()
AcpiOsWaitSemaphore()
AcpiUtAcquireMutex()
AcpiDisableGpe()
EcGpeHandler()
AcpiEvGpeDispatch()
AcpiEvGpeDetect()
AcpiEvGpeDetect()
AcpiEvSciXruptHandler()
possible that the same packet would show up multiple times. This poses some
constraints on the TBD locking for snc(4) (see comment).
Obtained from: DragonFlyBSD
Submitted by: Joerg Sonnenberger
Reviewed by: rwatson
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.
