uhci.c: -r1.82
uhcivar.h: -r1.22
date: 2000/01/26 10:04:39; author: augustss; state: Exp;
Try to avoid accessing the HC if it is dead. Suggested by mycroft.
revision 1.125
date: 2000/09/23 21:00:10; author: augustss; state: Exp; lines: +19 -3
Avoid "bandwidth reclamation" for control transfers. The kue device chokes
on it.
uhci.c: -r1.124
uhcireg.h: -r1.13
date: 2000/08/13 18:20:14; author: augustss; state: Exp;
Fix race condition when unlinking xfers. Thanks to IWAMOTO Toshihiro
<iwamoto@sat.t.u-tokyo.ac.jp> for analyzing the problem and suggesting a fix.
Fixes PR 10662.
uhci.c: -r1.123 (and a tiny bit of -r1.92)
uhcivar.h: -r1.32
date: 2000/08/13 16:18:09; author: augustss; state: Exp;
Implement what in Intel-speech is known as "bandwidth
reclamation". It means that we continously poll USB devices
that have a pending transfer instead of polling just once
every ms. This speeds up some transfers at the expense of
using more PCI bandwidth.
uchireg.h: -r1.12
uchi.c: -r1.121
date: 2000/07/23 19:43:38; author: augustss; state: Exp;
Be a little more explicit and careful about setting links in TDs and QHs.
prior ICP Vortex models. This driver was developed by Achim Leubner
of Intel (previously with ICP Vortex) and Boji Kannanthanam of Intel.
Submitted by: "Kannanthanam, Boji T" <boji.t.kannanthanam@intel.com>
MFC after: 2 weeks
likely looking rate calculation.
Install interrupt handler before calling ich_init as the initialization
occasionally generates spurious interrupts.
These changes are derived from cg's work in progress version of this
driver.
at insert time. When asking gibbs for approval for an MFC, this was
his reply:
1) It leaks memory if it can't allocate a path.
2) It defers allocation of aic->path until the call to scan the
bus. This means the path may be NULL when an interrupt occurs
prior to the call to scan the bus (stray bus reset for instance),
which will lead to a panic.
3) The driver in current doesn't recover from the failure to allocate
aic->path. The driver doesn't check during normal operation if
the path is NULL, so again a panic will result.
4) aic_cam_rescan calls malloc with M_WAITOK. aic_cam_rescan is called
from attach where it isn't necessarily safe to sleep.
5) And most importantly, it co-opts the xpt_periph from the driver level.
This was never part of the design (xpt_periph used to be static). Making
a call of this type may completely confuse the XPT if other XPT operations
are ongoing.
In the long term, Justin and Warner agreed to implement solution where
CAM itself will initiate the bus rescan if a new bus is added. For
the time being (and in particular in light of the upcoming 4.5
release), we now have camcontrol available on the boot floppy, and can
have pccardd initiate the rescan through it.
previous commit, it should always print due to lack of {} around the
second line in the if statement. The message should likely say
something more like "There's no hardware responding at this IRQ.
Device not present (or disbaled)," but that is too long. We generally
don't give elementary advise in device driver messages anyway. Be
that as it may, the problem with it printing all the time should be
corrected.
One to notify the system that the MTU for VLAN can be 1500 so the vlan
will automatically be configured with a 1500 MTU the other is to ignore
the error case if the received frame is to long.
The frame size notification came from code in the SIS driver, and
the support for long frames derived from the NetBSD Tulip driver.
Tested on: 4 port D-Link adapter DFE-570TX 4 Intel 21143
Netgear card with 82c169 PNIC 10/100BaseTX
Reviewed by: ru (manpage), wpaul (not objected to), archie
Approved by: imp
Obtained from: NetBSD
o Remove bogus flags that aren't used (if we need them in the future, we can
add them back).
o Add support for the TI-1031. This is the only YENTA compatible PCI-PCMCIA
bridge that I'm aware of (all the others are PCIC on a PCI bus, which is
different).
Seigo Tanimura (tanimura) posted the initial delta.
I've polished it quite a bit reducing the need for locking and
adapting it for KSE.
Locks:
1 mutex in each filedesc
protects all the fields.
protects "struct file" initialization, while a struct file
is being changed from &badfileops -> &pipeops or something
the filedesc should be locked.
1 mutex in each struct file
protects the refcount fields.
doesn't protect anything else.
the flags used for garbage collection have been moved to
f_gcflag which was the FILLER short, this doesn't need
locking because the garbage collection is a single threaded
container.
could likely be made to use a pool mutex.
1 sx lock for the global filelist.
struct file * fhold(struct file *fp);
/* increments reference count on a file */
struct file * fhold_locked(struct file *fp);
/* like fhold but expects file to locked */
struct file * ffind_hold(struct thread *, int fd);
/* finds the struct file in thread, adds one reference and
returns it unlocked */
struct file * ffind_lock(struct thread *, int fd);
/* ffind_hold, but returns file locked */
I still have to smp-safe the fget cruft, I'll get to that asap.
instead of relying on the previous filters to be present.
Back out r1.125, as a reset is needed to unload any existing microcode,
(which clears the multicast addresses), as it is superceded by this change.
mutex releases to not require flags for the cases when preemption is
not allowed:
The purpose of the MTX_NOSWITCH and SWI_NOSWITCH flags is to prevent
switching to a higher priority thread on mutex releease and swi schedule,
respectively when that switch is not safe. Now that the critical section
API maintains a per-thread nesting count, the kernel can easily check
whether or not it should switch without relying on flags from the
programmer. This fixes a few bugs in that all current callers of
swi_sched() used SWI_NOSWITCH, when in fact, only the ones called from
fast interrupt handlers and the swi_sched of softclock needed this flag.
Note that to ensure that swi_sched()'s in clock and fast interrupt
handlers do not switch, these handlers have to be explicitly wrapped
in critical_enter/exit pairs. Presently, just wrapping the handlers is
sufficient, but in the future with the fully preemptive kernel, the
interrupt must be EOI'd before critical_exit() is called. (critical_exit()
can switch due to a deferred preemption in a fully preemptive kernel.)
I've tested the changes to the interrupt code on i386 and alpha. I have
not tested ia64, but the interrupt code is almost identical to the alpha
code, so I expect it will work fine. PowerPC and ARM do not yet have
interrupt code in the tree so they shouldn't be broken. Sparc64 is
broken, but that's been ok'd by jake and tmm who will be fixing the
interrupt code for sparc64 shortly.
Reviewed by: peter
Tested on: i386, alpha
hw.midi.debug and hw.midi.seq.debug to 1 to enable debug log.
- Make debug messages human-frendly.
- Implement /dev/music.
- Add a timer engine required by /dev/music.
- Fix nonblocking I/O.
- Fix the numbering of midi and synth devices.
firmware to delay completion of commands so that it can attempt to batch
a bunch of completions at once- either returning 16 bit handles in mailbox
registers, or in a resposne queue entry that has a whole wad of 16 bit handles.
Distinguish between 2300 and 2312 chipsets- if only because the revisions
on the chips have different meanings.
Add more instrumentation plus ISP_GET_STATS and ISP_CLR_STATS ioctls.
Run up the maximum number of response queue entities we'll look at
per interrupt.
If we haven't set HBA role yet, always return success from isp_fc_runstate.
MFC after: 2 weeks
