- Move MD files into <arch>/<arch>.
- Move bus dependent files into <arch>/<bus>.
Rename some files to more suitable names.
Repo-copied by: peter
Discussed with: imp
of swi. This allows us to use the taskqueue_thread_* functions instead of
rolling our own. It also avoids a double trip through the queue.
Submitted by: njl
Reviewed by: sam
the same time.
Fix if_ndis_pccard.c so that it sets sc->ndis_dobj and sc->ndis_regvals.
Correct IMPORT_SFUNC() macros for the READ_PORT_BUFFER_xxx() routines,
which take 3 arguments, not 2.
This fixes it so that the Windows driver for my Cisco Aironet 340 PCMCIA
card works again. (Yes, I know the an(4) driver supports this card natively,
but it's the only PCMCIA device I have with a Windows XP driver.)
The core console code checks this field when a console is added and
emits a warning if it's empty. In practice the warning is harmless for
uart(4), because the cn_name is filled in as soon as the device name is
known; which is when the device is enumerated.
To avoid the warning, to avoid possible complications caused by emitting
the warning without there (possibly) being a console selected yet and to
avoid complications when the UART isn't found during bus enumeration, we
just preset the cn_name field here to the name of the driver.
Remove unused fields from ndis_miniport_block.
Fix a bug in KeFlushQueuedDpcs() (we weren't calculating the kq pointer
correctly).
In if_ndis.c, clear the IFF_RUNNING flag before calling ndis_halt_nic().
Add some guards in kern_ndis.c to avoid letting anyone invoke ndis_get_info()
or ndis_set_info() if the NIC isn't fully initialized. Apparently, mdnsd
will sometimes try to invoke the ndis_ioctl() routine at exactly the
wrong moment (to futz with its multicast filters) when the interface
comes up, and can trigger a crash unless we guard against it.
- Remove the old task threads from kern_ndis.c and reimplement them in
subr_ntoskrnl.c, in order to more properly emulate the Windows DPC
API. Each CPU gets its own DPC queue/thread, and each queue can
have low, medium and high importance DPCs. New APIs implemented:
KeSetTargetProcessorDpc(), KeSetImportanceDpc() and KeFlushQueuedDpcs().
(This is the biggest change.)
- Fix a bug in NdisMInitializeTimer(): the k_dpc pointer in the
nmt_timer embedded in the ndis_miniport_timer struct must be set
to point to the DPC, also embedded in the struct. Failing to do
this breaks dequeueing of DPCs submitted via timers, and in turn
breaks cancelling timers.
- Fix a bug in KeCancelTimer(): if the timer is interted in the timer
queue (i.e. the timeout callback is still pending), we have to both
untimeout() the timer _and_ call KeRemoveQueueDpc() to nuke the DPC
that might be pending. Failing to do this breaks cancellation of
periodic timers, which always appear to be inserted in the timer queue.
- Make use of the nmt_nexttimer field in ndis_miniport_timer: keep a
queue of pending timers and cancel them all in ndis_halt_nic(), prior
to calling MiniportHalt(). Also call KeFlushQueuedDpcs() to make sure
any DPCs queued by the timers have expired.
- Modify NdisMAllocateSharedMemory() and NdisMFreeSharedMemory() to keep
track of both the virtual and physical addresses of the shared memory
buffers that get handed out. The AirGo MIMO driver appears to have a bug
in it: for one of the segments is allocates, it returns the wrong
virtual address. This would confuse NdisMFreeSharedMemory() and cause
a crash. Why it doesn't crash Windows too I have no idea (from reading
the documentation for NdisMFreeSharedMemory(), it appears to be a violation
of the API).
- Implement strstr(), strchr() and MmIsAddressValid().
- Implement IoAllocateWorkItem(), IoFreeWorkItem(), IoQueueWorkItem() and
ExQueueWorkItem(). (This is the second biggest change.)
- Make NdisScheduleWorkItem() call ExQueueWorkItem(). (Note that the
ExQueueWorkItem() API is deprecated by Microsoft, but NDIS still uses
it, since NdisScheduleWorkItem() is incompatible with the IoXXXWorkItem()
API.)
- Change if_ndis.c to use the NdisScheduleWorkItem() interface for scheduling
tasks.
With all these changes and fixes, the AirGo MIMO driver for the Belkin
F5D8010 Pre-N card now works. Special thanks to Paul Robinson
(paul dawt robinson at pwermedia dawt net) for the loan of a card
for testing.
Have pmcstat(8) and pmccontrol(8) use these APIs.
Return PMC class-related constants (PMC widths and capabilities)
with the OP GETCPUINFO call leaving OP PMCINFO to return only the
dynamic information associated with a PMC (i.e., whether enabled,
owner pid, reload count etc.).
Allow pmc_read() (i.e., OPS PMCRW) on active self-attached PMCs to
get upto-date values from hardware since we can guarantee that the
hardware is running the correct PMC at the time of the call.
Bug fixes:
- (x86 class processors) Fix a bug that prevented an RDPMC
instruction from being recognized as permitted till after the
attached process had context switched out and back in again after
a pmc_start() call.
Tighten the rules for using RDPMC class instructions: a GETMSR
OP is now allowed only after an OP ATTACH has been done by the
PMC's owner to itself. OP GETMSR is not allowed for PMCs that
track descendants, for PMCs attached to processes other than
their owner processes.
- (P4/HTT processors only) Fix a bug that caused the MI and MD
layers to get out of sync. Add a new MD operation 'get_config()'
as part of this fix.
- Allow multiple system-mode PMCs at the same row-index but on
different CPUs to be allocated.
- Reject allocation of an administratively disabled PMC.
Misc. code cleanups and refactoring. Improve a few comments.
theoretically unload pci bridges or pci drivers. It will also allow
detach to work if one needed to detach a subtree.
This is inspired by looking at the p4 commits from bms to his 5.4
tree, but I didn't look at the final results.
for the VGA I/O or memory ranges, when it's not within the default
ranges decoded by the bridge. When allocation for VGA addresses is
attempted, check that the bridge has the VGA Enable bit set before
allowing it.
As such, newbusified VGA drivers can allocate their resources when
the VGA adapter is behind a PCI-to-PCI bridge.
Reviewed by: imp@, jhb@
Only allow a process to use the x86 RDPMC instruction if it has
allocated and attached a PMC to itself.
Inform the MD layer of the "pseudo context switch out" that needs
to be done when the last thread of a process is exiting.
fact that access to RR0 does not need a prior write to the register
index because the index always reverts to 0 after the indexed register
has been accessed.
Typically when a RR or WR is to accessed, one programs the index (which
is a write to the control register), followed by a read or write to the
actual indexed register (a read pr write to the same control register).
When this non-atomic sequence is interrupted after having written the
index and low-level console I/O is done in that situation, the write to
program the index will actually write to the indexed register and nuke
state. This almost always yields a wedge.
By not programming the index register and instead just reading from RR0,
the worst case scenario is non-fatal. For if we don't actually read from
RR0 but some other register we get an invalid status, which may lead us
to conclude that the transit data register is empty when it's not or that
the receive data register contains data when it doesn't. Hence, we may
lose an output character or get a sporadic input character, but given
the situation this is a non-issue.
Full serialization is not possible due to the fact that this code needs
to work from DDB and before mutex initialization has happened.
In collaboration with: kris@, marius@
Tested by: kris@
MFC after: 1 day
X-MFC: 5.4-RELEASE candidate
during a data phase. Before, we would try to recover the autosense, but
the DMA engine would still be active with interrupted transfer, and we'd
quickly spiral out of control and cause massive data corruption. For now,
just reset the chip and cancel everything. The better solution is to
cancel the DMA operation, but there is no clear way to do that right now.
The data corruption problem is severe enough to warrant this fix in the
interim. Thanks to Kris Kenneway to sacrificing countless filesystems to
this bug.
MFC After: 3 days
on boards with VIA gigE controllers that are embedded in VIA chipsets.
Presumably, they don't have an external EEPROM and store the MAC
address somewhere else. To get around this, force an autoload and
read the station address from the RX filter registers instead.
This has been tested to work on both embedded and standalone
controllers.
While there also check for failed device_add_child calls.
Found by: Coventry Analysis tool[1].
Submitted by: sam[1]
Approved by: pjd (mentor)
MFC after: 1 week
here on in, if_ndis.ko will be pre-built as a module, and can be built
into a static kernel (though it's not part of GENERIC). Drivers are
created using the new ndisgen(8) script, which uses ndiscvt(8) under
the covers, along with a few other tools. The result is a driver module
that can be kldloaded into the kernel.
A driver with foo.inf and foo.sys files will be converted into
foo_sys.ko (and foo_sys.o, for those who want/need to make static
kernels). This module contains all of the necessary info from the
.INF file and the driver binary image, converted into an ELF module.
You can kldload this module (or add it to /boot/loader.conf) to have
it loaded automatically. Any required firmware files can be bundled
into the module as well (or converted/loaded separately).
Also, add a workaround for a problem in NdisMSleep(). During system
bootstrap (cold == 1), msleep() always returns 0 without actually
sleeping. The Intel 2200BG driver uses NdisMSleep() to wait for
the NIC's firmware to come to life, and fails to load if NdisMSleep()
doesn't actually delay. As a workaround, if msleep() (and hence
ndis_thsuspend()) returns 0, use a hard DELAY() to sleep instead).
This is not really the right thing to do, but we can't really do much
else. At the very least, this makes the Intel driver happy.
There are probably other drivers that fail in this way during bootstrap.
Unfortunately, the only workaround for those is to avoid pre-loading
them and kldload them once the system is running instead.
16C950. Adding it here doesn't unlock any of the cool 16C950 features
(like the 128 byte fifo, the different prescalor, etc), but it does
seem to get it working for me in light testing.
Card Provided by: Ihsan Dogan
pumping data despite our scsi data counters being at 0, something has
gone massively wrong. The consequence of happily ignoring this is more
DMA phase errors and a disk full of spammed sectors. Instead, panic on
the first occurance to hopefully limit the damage.
MFC After: 3 days
latest 82550 and 82551 chipsets (revision IDs 0x0e, 0x0f and 0x10).
We were only enabling it for revisions 0x0c and 0x0d, now it's
enabled for any 8255x NIC with a revision ID bigger than 0x0c. It
should be safe, and this is what Intel does in their open source
driver.
MFC after: 2 weeks
Tested by: Pavel Lobach lobach_pavel at mail dot ru
This also removes the warning timeout on the taskqueues stalling as
I'm tired of getting ATA error reports for problems in other parts ;)
Misc cosmetic and comment cleanups now we are here.
number of task threads to start on boot. Go back to a default of 3
threads to work around lost battery state problems. Users that need
a setting of 1 can set this via the tunable. I am investigating the
underlying issues and this tunable can be removed once they are solved.
MFC after: 2 days
includes the MD header for us. Do not include <machine/specialreg.h>
as it is not a header file that can be included from MI files. It
is included from <machine/pmc_mdep.h> if so needed and possible.
Ok'd: jkoshy@
ioctls are now handled explicitly, but we can't really do anything
with them unless the NIC is up (trying to get/set a parameter when
the NDIS driver isn't running always yields an error). If something
invokes either of these ioctls and the NIC isn't initialized, punt
to the default ieee80211_ioctl() routine.
While we wait for holds to be released, print a list of who holds us
back once per second.
Use the new KPI from GEOM instead of vfs_mount.c calling g_waitidle().
Use the new KPI also from ata.
With ATAmkIII's newbusification, ata could narrowly miss the window
and ad0 would not exist when we tried to mount root.
dc0: MII without any PHY!
We have to enable the connection to the MII first. Doing so fixes the
problem cards without breaking the older, working cards.
Bad card provided by: deischen
- ncr53c9x.c:
1.108: Remove unreachable break after return and goto statements.
1.109: avoid strong words; use 'screw' instead
1.110: Fix some typos. From Tom Cosgrove via jmc@openbsd.
1.114: nuke trailing whitespace
1.107 was already merged, 1.112 and 1.113 are not relevant for FreeBSD.
1.111 is a functional change and will be merged later.
- ncr53c9xreg.h:
1.12: DMA, not dma nor Dma.
1.13: Fix some typos. From Tom Cosgrove via jmc@openbsd.
1.14: nuke trailing whitespace
- ncr53c9xvar.h:
1.43: Fix some typos. From Tom Cosgrove via jmc@openbsd.
1.44: Constify.
1.42 and 1.46 were already merged, 1.45 is not relevant for FreeBSD.
- Merge esp_sbus.c rev. 1.31 from NetBSD: nuke trailing whitespace.
Rev. 1.28 and 1.30 were already merged, 1.29 is not relevant for FreeBSD.
- Remove unused headers.
- Use BUS_PROBE_DEFAULT.
- Use __func__ instead of hardcoded function names in error messages.
- Correct some comments.
- Correct some function declarations to match their prototypes.
- Some style(9) fixes (don't use function calls in initializers; indentation).
- Zero the allocated structs to avoid problems with uninitialized members.
- Remove the ifdef'ed out SBus interrupt priority code and the hook for
ncr53c9x_reset(), remove the unused SBus interrupt priority member from
esp_softc. On FreeBSD setting the SBus interrupt priority is entirely done
in sbus(4) and the reset function isn't even really used in NetBSD.
- s,dma,DMA, in comments.
- Make the code fit in 80 columns.
this buffer anyway so the constraint that it had to be DMA capable only
caused pain when devices failed to aquire the memory. Use a regular
malloc instead with sndbuf_setup.
Approved by: tanimura (mentor)
- Split core DRM routines back into their own module, rather than using the
nasty templated system like before.
- Development-class R300 support in radeon driver (requires userland pieces, of
course).
- Mach64 driver (haven't tested in a while -- my mach64s no longer fit in the
testbox). Covers Rage Pros, Rage Mobility P/M, Rage XL, and some others.
- i915 driver files, which just need to get drm_drv.c fixed to allow attachment
to the drmsub device. Covers i830 through i915 integrated graphics.
- savage driver files, which should require minimal changes to work. Covers the
Savage3D, Savage IX/MX, Savage 4, ProSavage.
- Support for color and texture tiling and HyperZ features of Radeon.
Thanks to: scottl (much p4 handholding)
Jung-uk Kim (helpful prodding)
PR: [1] kern/76879, [2] kern/72548
Submitted by: [1] Alex, lesha at intercaf dot ru
[2] Shaun Jurrens, shaun at shamz dot net
This allows to attach to the children (ATA devices) even without a
driver being attached. This allows atapi-cam to do its work both
with and without the pure ATAPI driver being present.
ATA patches by /me
ATAPI-cam pathes by Thomas
printf's during a verbose boot is more intuitive (the BAR listings and
interrupt routing info now comes after the config header dump rather than
just before it).
Save a memory dereference in the ISR by passing this in directly.
Calling pps_capture is MP safe for all other operations on struct
pps_state, so there's no need to aquire the lock before we do this,
even from a fast ISR. Avoid dereferencing sc->ppbus until after
pps_capture is called as well. These actions reduce somewhat the
cache effects that cause variance in interrupt times. On an
especially slow test machine (300MHz Cyrix GXm), this reduces the
interrupt latency about about 10% (from 21us to 19us) and helps a
little with the variance (although most of the variance seems to be
caused by lots of interrupt masking).
This also happens fixes one or two of bde's style issues.
we start turning any of them back on again. This works around a bug in
some BIOSen that alias two different link devices for APIC vs ATPIC modes
onto the same physical hardware link.
Submitted by: njl
Tested by: Antoine Brodin antoine dot brodin at laposte dot net
pcib_route_interrupt interface. Since there's only one interrupt pin
in the CardBus form factor, everybody gets to share it. Implement
cbb_route_interrupt to return the interrupt we have.
Suggested by: bms
Otherwise, busses that implement the pcib interface that forget to
implement pcib_route_interrupt would return EIO, which the caller
interprets as 'use interrupt 6'. This is likely the cause of much of
the grief that we had when I enabled power modes for the cardbus
bridge, since the card needed to reroute the interrupt to it and it
was getting 6 which was d by the pccbb sanity checks.
3ware's 9xxx series controllers. This corresponds to
the 9.2 release (for FreeBSD 5.2.1) on the 3ware website.
Highlights of this release are:
1. The driver has been re-architected to use a "Common Layer"
(all tw_cl* files), which is a consolidation of all OS-independent
parts of the driver. The FreeBSD OS specific portions of the
driver go into an "OS Layer" (all tw_osl* files).
This re-architecture is to achieve better maintainability, consistency
of behavior across OS's, and better portability to new OS's (drivers
for new OS's can be written by just adding an OS Layer that's specific
to the OS, by complying to a "Common Layer Programming Interface" API.
2. The driver takes advantage of multiple processors.
3. The driver has a new firmware image bundled, the new features of which
include Online Capacity Expansion and multi-lun support, among others.
More details about 3ware's 9.2 release can be found here:
http://www.3ware.com/download/Escalade9000Series/9.2/9.2_Release_Notes_Web.pdf
Since the Common Layer is used across OS's, the FreeBSD specific include
path for header files (/sys/dev/twa) is not part of the #include pre-processor
directive in any of the source files. For being able to integrate twa into
the kernel despite this, Makefile.<arch> has been changed to add the include
path to CFLAGS.
Reviewed by: scottl
problems here, it became clear we were being too complex.
o Don't keep track of resources in two places
o Use resource_list_purge instead of rolling our own
o Just reassign the ownership of the resource, rather than freeing it
and reallocating it.
o Fix compile problems when sizeof(u_long) != sizeof(int)
this code:
o rid is stored in the resource, so don't bother keeping track of it here.
o Implement memory space
o Don't try to activate 'memory card' CFEs. This is type memory, as opposed
to the memory resource.
resource_list_find. Check to make sure that rle is not NULL and panic
if it is (but it appears that resource_list_add already panics, so I'm
not entirely sure it is necessary now).
Add a test to make sure we have a interrupt resource when we're
disabling it. This is also a cannot happen, but the extra care
shoudln't hurt.
Found by: Coventry tool via sam@
whether or not the receive pipe is stopped. This ensures that we
do not attempt to start the same transfer twice, and it allows
ucomstop() to skip the restarting of the read pipe if it was not
originally running, such as when called indirectly from ucomreadcb().
PR: kern/79420
MFC after: 1 day
layer, but with a twist.
The twist has to do with the fact that Microsoft supports structured
exception handling in kernel mode. On the i386 arch, exception handling
is implemented by hanging an exception registration list off the
Thread Environment Block (TEB), and the TEB is accessed via the %fs
register. The problem is, we use %fs as a pointer to the pcpu stucture,
which means any driver that tries to write through %fs:0 will overwrite
the curthread pointer and make a serious mess of things.
To get around this, Project Evil now creates a special entry in
the GDT on each processor. When we call into Windows code, a context
switch routine will fix up %fs so it points to our new descriptor,
which in turn points to a fake TEB. When the Windows code returns,
or calls out to an external routine, we swap %fs back again. Currently,
Project Evil makes use of GDT slot 7, which is all 0s by default.
I fully expect someone to jump up and say I can't do that, but I
couldn't find any code that makes use of this entry anywhere. Sadly,
this was the only method I could come up with that worked on both
UP and SMP. (Modifying the LDT works on UP, but becomes incredibly
complicated on SMP.) If necessary, the context switching stuff can
be yanked out while preserving the convention calling wrappers.
(Fortunately, it looks like Microsoft uses some special epilog/prolog
code on amd64 to implement exception handling, so the same nastiness
won't be necessary on that arch.)
The advantages are:
- Any driver that uses %fs as though it were a TEB pointer won't
clobber pcpu.
- All the __stdcall/__fastcall/__regparm stuff that's specific to
gcc goes away.
Also, while I'm here, switch NdisGetSystemUpTime() back to using
nanouptime() again. It turns out nanouptime() is way more accurate
than just using ticks(). On slower machines, the Atheros drivers
I tested seem to take a long time to associate due to the loss
in accuracy.
systems that boot with this value at the lowest setting. Change the
default boot config back to "leave frequency as BIOS set it". Also, fix
buglet where acpi_throttle wouldn't be used if p4tcc was present but
disabled by the user.
MFC after: 1 week
Affects to people WITH an AD1888 codec, the system will output to the port
labeled "speaker" instead of microphone. System will work the same in
multiple operating systems.
If people are currently using their systems with this codec they will need
to swap their output ports.
I have _not_ checked audio input or line input (basically, I have checked
nothing other than line-out).
I believe this is an appropriate change, it makes us consistent with
documentation, and other operating systems. Furthermore, this feature
(playing) is the vast majority of sound activities, so if this makes is
right for playback and wrong for recording... playback is more important,
and we can fix recoding in the future without worries of screwing people
again in the future (since we'll be "right" on the playback).
Submitted by: David Cross
