memory. Since we only now ever "return(0)", just return (void)
instead.
Cleanup all uses of rf_ShutdownCreate() to not worry about
it ever failing. Shaves another 600 bytes off of an i386 GENERIC kernel.
dynamically allocated variable-sized array (dagArray). Convert code
to use the new linked list stuff instead of the array stuff (the ratio
of one dagList per stripe still applies). The big advantage is in
being able to more efficiently allocate the dagLists on-the-fly, and
not have to know the size(s) of the array beforehand.
free()d memory will be referenced through
usbd_add_dev_event(USB_EVENT_DEVICE_DETACH)->
usbd_fill_deviceinfo()
later.
might need more review, but at least it doesn't crash on
amd64 anymore
and external interrupt handlers should be completely
unrelated.
For now, just remove the obvious culprit in the nibble/ps2
case to make NTP pps signal capturing work again.
External handlers should be passed to the lower level,
and they should have full power and responsibility if
they are installed, and their lavel should be selected
by the frontend.
Being here, comment out <machine/intr.h> - it is not
used yet, and do some more conmetic cleanup.
OS needs such a hack, and the same drive works fine on Suns -- and is much
more likely to be a bug in the host adapter driver (which is corroborated by
the PQUIRK_NOLUNS).
to only call pckbc_machdep_cnattach() if this is present. This allows
pckbc_machdep_cnattach() to be omitted entirely on most ports, where it only
returns ENXIO anyway.
The devices with this attribute at the moment are pc(4) on i386 and bebox, and
pckbc on sparc, where pckbc_machdep_cnattach() mysteriously returns 0 rather
than ENXIO.
called with every buffer written through spec_strategy().
Used by fss(4). Future file-system-internal snapshots will need them too.
Welcome to 1.6ZK
Approved by: Jason R. Thorpe <thorpej@netbsd.org>
of bounds, then complain and recover by freeing all of the descriptors.
That will usually provoke additional complaints---see the next
paragraph.
If the firmware returns to us an RSS descriptor that is in-bounds
but out of service (id_node == NULL), then gripe and get out of
the interrupt handler. ***This will still leak RSS descriptors.***
I'm working on a better solution. Possibly I will just free all of
the descriptors.
bug report from Simon Burge: the firmware seems to lock up.
If rate-adaptation is disabled on a Lucent card, then do all the
rate-adaptation work *except* for writing the new transmit rate,
since I suspect that is what locks-up the firmware.
and writes of the EEPROM are too fast so invalid data is returned. So we
increase the DELAY()s. The right thing would be to check a ready bit
on the E^2 if such a thing exists. (checked by potr)
via ioctl; drop the traditional device minor mapping for those in favour
of setting via lptctl(8)
introduce notion of 'control' device (minor bit 0x100 set); ATM this
device always skips the priming, which allows device open even with
disconnected printer
this also changes the default for interrupt use - polling is used
by default now
When creating a package element via "Store(0xXXX, Index(ArgX, 0xXXX))",
be sure to increment the refcount of the argument so it is not
prematurely deleted. This is a workaround and may appear in a different
form in ACPI-CA. This fixes battery evaluation on Thinkpads that was
broken by fixing the Dell battery state.
Submitted by: Luming Yu <luming.yu at intel.com>
audio device interface:
1) When attempting to match the appropriate mixer control, we weren't
checking the class label, but only the second level label, so for
devices that had both an "inputs.cd" and a "record.cd", for example,
we could never do the right thing except by chance. For this reason,
evidently, all the record masters were labeled (by the underlying
drivers) either "record.record" or "record.volume", to distinguish
from "outputs.master". We'll now accept "record.master", and document
that as the the new preferred way.
2) More importantly, the model was deficient. Selecting a port on many
chips completely disables most of the level controls, which doesn't play
nice with other applications which are trying to use the interface. Now,
selecting a port simply sets which mixer input control shall be changed,
setting state in the audio layer. In other words, the "mixerout" port
is really selected all the time, enabling the final stage mixer, and
setting "gain" sets the level of the appropriate input. It should be
possible for separate applications to each control the mic, dac, and cd
inputs at the same time using this interface, simply by reiterating their
port selections with each change, but applications that don't bother to
do that aren't any worse off than they were before.
The user is expected to set the master output with another application,
dedicated to that task. Though it is now meaningful to select "no port"
with the audio device interface, to manipulate the master output, there's
no particular reason for an audio device consumer to do that. (I added
the capability in order to restore the initial state of the audio device,
for testing purposes. It might also be useful to users of broken binary-
only applications.)
Observe that the mixer device interface (and so, "mixerctl") still
retains all capabilities, including the ability to set the actual input
port on the chip, overriding the level controls. No change is being made
to the mixer device interface. The mixer device simply presents all the
controls on the chip, with no attempt at abstraction, so there are no
bugs there.
The upshot is, that applications that have been trying to use the audio
device interface to change the volume, such as mplayer, now "just work".
I've tested these changes extensively with "eso" and "eap" since first
proposing them on tech-kern last January, and somewhat with "esm" and a
few others. This closes both PR kern/10221, and PR kern/17159.
the recently introduced files.ppbus.
Also, let the mvme68k port use it's own lpt implementation for now,
so define USE_ALT_LPT option in std.memv68k.
This makes the mvme68k kernels configure and build again.
VOP_STRATEGY(bp) is replaced by one of two new functions:
- VOP_STRATEGY(vp, bp) Call the strategy routine of vp for bp.
- DEV_STRATEGY(bp) Call the d_strategy routine of bp->b_dev for bp.
DEV_STRATEGY(bp) is used only for block-to-block device situations.
with ACPI and PNPBIOS attachments; move it to new atppc_isadma.[ch]
and g/c previous atppc_isa_subr.[ch]
move attppc_isa_softc struct definition to atppc_isa.c, and reorganize
the attachment somewhat for better readability; also g/c detach support code
From PR kern/13702 from Charles Carvalho. Tested on alpha and
i386 with a Laipac TF10 PPS-capable GPS. The com.c change was
copied wholesale from Charles' z8530tty.c patch.
give it back if we don't need it. If we don't allocate it before
we take our lock, LOCKDEBUG (rightfully) complains that we're trying
to grab something from the pool with PR_WAITOK. This code (and the
PR_WAITOK in particular) really needs to be revisited at some point.
found empiricaly that (at least on bcm5700s) the Rx coalesce and bd
counts cannot be updated on-the-fly; attempting to do so (even at
splhigh()) causes weird behaviour.
Instead, add a softc flag to record that the desired softc values for
Rx-interrupt thresholds have changed; check that boolean in the interrupt
routine. If set, apply the new values there and clear the flag.
BGE_MISC_TIMER register definition, and more bit definitions for
HCC-mode. (I would credit individuals, but the attributions are buried
deep in my own tree.)
12160 Firmware Version 10.04.41 (10:30 Mar 21, 2003)
2200 Firmware Version 2.02.06 (08:39 Jun 26, 2003)
2300 Firmware Version 3.02.15 (08:26 Jul 21, 2003)
Matt's done some testing with it, and I've also tested on a very basic
setup with a QLA 2310 and a tower of 4 FC drives.
Unfortunately, there doesn't seem to be any change log for the firmware.
* lpt device is defined in MI place (dev/ppbus/files.ppbus), dev/ic/lpt.c
is included there too; dev/ic/lpt.c is not included if ppbus is
configured or if there is alternative platform lpt (like for pc532)
* g/c MD lpt definitions and custom puc/upc attachments,
glue moved to conf/files and dev/pci/files.pci respectively; remove
device lpt definition from dev/isa/files.isa
* add ppbus parport attribute, atppc device attachments, adjust plip and lpt
glue
* lpt device is defined in MI place (dev/ppbus/files.ppbus), dev/ic/lpt.c
is included there too; dev/ic/lpt.c is not included if ppbus is
configured or if there is alternative platform lpt (like for pc532)
* g/c MD lpt definitions and custom puc/upc attachments,
glue moved to conf/files and dev/pci/files.pci respectively; remove
device lpt definition from dev/isa/files.isa
* add ppbus parport attribute, atppc device attachments, adjust plip and lpt
glue
This bit will be set if the clock lost power (and may therefore
not have the correct time). If this bit is set, the stored time
does not advance. So, when setting the clock, if that bit is set,
we simply clear it. It might be nice in some applications to pass
the information up a few layers if the bit is set when we read the
register initially. For now, though, we ignore it.
within the configuration descriptor, not the class specific interface
descriptor. The Edirol UM-1SX now successfully attaches and works as
a standard USB MIDI interface when the "advanced driver" switch is set
to "off".
systems that don't have a dedicated feeper. It's up to MD code to enable
this by having the "audiobell" attribute and calling audiobell() at the
appropriate moment.
Code for making noise in the kernel from Richard Earnshaw. Simple synthesizer
design from the RISC OS Programmer's Reference manual.
handling was changed in net80211 framework.
This fix wiconfig -D awi0 to work again for DS phys.
XXX FH phys takes 20 seconds to complete scan, so wiconfig timed out.
skrueger-at-europe-dot-com. (It turns out that the mutex used to
serve two different purposes, not just one, and for its current use,
it's actually miss-named. Will fix that some other time.)
Tested on macppc by HATANO Hiromichi.
Note I guess this bug could be fixed only adding one htole32(),
but I'd rather clean up endianness handling:
- Use htole32() only to accesses against DMA descriptors.
- Don't use uint32_t union member with htole32()/le32toh()
to access uint8_t/uint16_t descriptors.
- Add le32toh() in some DPRINTF.
(XXX: strictly speaking, bus_dmamap_sync() is needed for these DPRINTF)
- Document the kernel thread.
- Rename some functions and variables.
- Return EROFS where appropriate.
- Use shifts instead of 64-bit divide.
- Use a simple_lock to make it MP-safe.
- Add M_CANFAIL to malloc to avoid panic on large cluster size.
- Allow sparse file for backing store and use VOP_BALLOC() to allocate
space. Default size of backing store is the size of the file system.
suspending.
Move vfs_write_suspend() and vfs_write_resume() from kern/vfs_vnops.c
to kern/vfs_subr.c.
Change vnode write gating in ufs/ffs/ffs_softdep.c (from FreeBSD).
When vnodes are throttled in softdep_trackbufs() check for
file system suspension every 10 msecs to avoid a deadlock.
Collapse the related variables down to zero. That means 'flags' is 0
as well. Nuke the extraction macros, a bunch of the variables, and replace
'flags' as well.
when the link condition changes by returning.
Note that hostap mode still does not work in atw, and ADMtek has
told me that the hardware will not support it, but I remain hopeful.
The compiler already knew that these chunks of code
could never be reached (since lu_flag was always 0), so it
already ignored them.
No functional changes.
rf_enableAtomicRMW changes.]
Cleanup rf_enableAtomicRMW and its use. According to the comments, we
can't set this to anything other than zero anyway. Shaves off another
900 bytes. lu_flag's days are numbered now, as are the middle
parameters of RF_CREATE_PARAM3.
can't set this to anything other than zero anyway. Shaves off another
900 bytes. lu_flag's days are numbered now, as are the middle
parameters of RF_CREATE_PARAM3.
debugging printf, and in rf_netbsdkintf.c. We can do the calculations
inside of RF_DEBUG_RECON for the one debugging printf, and only
perform the percentCompleted calculation "on demand" in the
rf_netbsdkintf.c case. Shaves a few more bytes off an i386 GENERIC
kernel, and ever-so-slightly decreases the amount of work performed
during a reconstruct.
rf_DecrAccessesCountState wasn't in the correct spot in
RF_AccessState_e. Following up on that has resulted in one other
correction. Changing orderings of these states is tricky, and
shouldn't be attempted without some thorough analysis. For the
changes committed, the following analysis is offerred:
1) RAIDframe uses a little state machine to take care of building,
executing, and processing the DAGs used to direct IO.
2) The rf_DecrAccessesCountState state is handled by the function
rf_State_DecrAccessCount(). The purpose of this state is to
decrement the number of "accesses-in-flight".
3) rf_Cleanup_State is handled by rf_State_Cleanup(). Its job is to
do general cleanup of DAG arrays and any stripe locks.
4) DefaultStates[] in rf_layout.c indicates that the right spot
for rf_DecrAccessesCountState is just before rf_Cleanup_State.
Analysis of code for both states indicates that the order doesn't
matter too much, although rf_State_DecrAccessCount() should probably
take place *after* rf_State_Cleanup() to be more correct.
5) Comments in rf_State_ProcessDAG() indicates that the next state
should be rf_Cleanup_State. However: it attempts to get there by using
desc->state++;
which actually takes it to just rf_DecrAccessesCountState! This turned
out to be OK before, since rf_Cleanup_State would follow right after,
and all would be taken careof (albeit in arguably the "less correct"
order).
6) With the current ordering, if we head directly to rf_Cleanup_State
(as we do, for example, if multiple components fail in a RAID 5 set),
then we'll actually miss going trough rf_DecrAccessesCountState), and
could end up never being able to reach quiescence! Perhaps not too
big of a deal, given that the RAID set is pretty much toast by that
point at which such a drastic state change happens, but might as well
have this correct.
The changes made are:
1) Since having rf_State_DecrAccessCount() come after
rf_State_Cleanup() is just fine, change rf_layout.c to reflect that
rf_DecrAccessesCountState comes after rf_Cleanup_State (i.e. they swap
positions in the state list). This means that going to
rf_Cleanup_State after bailing on a failed DAG access will do all the
right things -- the state will get cleaned up, and then the access
counts will get decremented properly. The comment in
rf_State_ProcessDAG() is now actually correct -- the next state *will*
be rf_Cleanup_State.
2) Move rf_DecrAccessesCountState in RF_AccessState_e to just after
rf_CleanupState. This puts RF_AccessState_e in sync with
DefaultStates[]. Fortunately, these states are rarely referred to by
name, and so this change ends up being mostly cosmetic -- it really
only fixes cleanup behaviour for the recent "Failed to create a DAG"
changes.
with flow control being applied. It is simpler and no more problematic to
accept the data and drop it if we hit a resource limit than to expect the
Bluetooth device to do anything about it (which it won't).
oster