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
instructs the driver to avoid using Keyboard Interface Test command.
This command causes problems with some non-compliant hardware, resulting
in machine being abruptly powered down early in the boot process.
Particularly it's known that HP ZV5000 and Compaq R3000Z notebooks
are affected by this problem.
Due to popularity of those models this patch is good MFC5.4 candidate.
PR: 67745
Submitted by: Jung-uk Kim jkim at niksun.com
MFC after: 1 days
- newbus plumbing. Each atapicam bus is a child off of a parent ata channel
bus. This is somewhat of a hack, but allows the ata core to be completely
free of atapicam knowledge.
- No more global lists of softc's and no more groping around in internal ata
structures on each command.
- Giant-free operation of the completion handler.
- Per-bus mutex for protecting the busy list and synchronizing detach.
- Lots of streamlining and dead code elimination, better adherence to the
CAM locking protocol.
This feature still requires that the appropriate atapi-* driver be present
for each atapi device that you want to talk to (i.e. atapi-cd for cdroms).
It does work both compiled into the kernel and as a loadable module.
Reviewed by: thomas, sos
critical_enter() and critical_exit() are now solely a mechanism for
deferring kernel preemptions. They no longer have any affect on
interrupts. This means that standalone critical sections are now very
cheap as they are simply unlocked integer increments and decrements for the
common case.
Spin mutexes now use a separate KPI implemented in MD code: spinlock_enter()
and spinlock_exit(). This KPI is responsible for providing whatever MD
guarantees are needed to ensure that a thread holding a spin lock won't
be preempted by any other code that will try to lock the same lock. For
now all archs continue to block interrupts in a "spinlock section" as they
did formerly in all critical sections. Note that I've also taken this
opportunity to push a few things into MD code rather than MI. For example,
critical_fork_exit() no longer exists. Instead, MD code ensures that new
threads have the correct state when they are created. Also, we no longer
try to fixup the idlethreads for APs in MI code. Instead, each arch sets
the initial curthread and adjusts the state of the idle thread it borrows
in order to perform the initial context switch.
This change is largely a big NOP, but the cleaner separation it provides
will allow for more efficient alternative locking schemes in other parts
of the kernel (bare critical sections rather than per-CPU spin mutexes
for per-CPU data for example).
Reviewed by: grehan, cognet, arch@, others
Tested on: i386, alpha, sparc64, powerpc, arm, possibly more
to see what features they may support before calling identify/probe/attach.
This is necessary because the ACPI 3.0 spec requires driver support be
advertised before running any methods. For now, the flags are as specified
in for the _PDC and _OSC methods but we can support private flags as needed.
Add an implementation of this for acpi_cpu. It checks all its children
(notably cpufreq drivers) and calls the _PDC method to report the results.
