| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
may want to shut down here but the chance of BIOS vendors getting this
wrong is high. They're only supposed to announce this when all batteries
hit their critical level but past experience indicates we should be
conservative about this for now.
|
|
|
|
|
| |
C3. Instead, flush caches before entering C3. This may be slower but
provides good power savings.
|
|
|
|
|
|
| |
This removes the last MD portion of acpi_cpu.c.
MFC after: 2 weeks
|
|
|
|
| |
Noticed by: ru@ (and likely tinderbox, I haven't checked)
|
|
|
|
|
|
| |
for machines with 2.88M floppies.
Reviewed By: phk
|
| |
|
|
|
|
|
|
| |
since I believe it is now MI, but that hasn't been done yet).
Reviewed by: dds
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Trade off granularity to reduce overhead, since the current model
doesn't appear to reduce contention substantially: move to a single
harvest mutex protecting harvesting queues, rather than one mutex
per source plus a mutex for the free list.
- Reduce mutex operations in a harvesting event to 2 from 4, and
maintain lockless read to avoid mutex operations if the queue is
full.
- When reaping harvested entries from the queue, move all entries from
the queue at once, and when done with them, insert them all into a
thread-local queue for processing; then insert them all into the
empty fifo at once. This reduces O(4n) mutex operations to O(2)
mutex operations per wakeup.
In the future, we may want to look at re-introducing granularity,
although perhaps at the granularity of the source rather than the
source class; both the new and old strategies would cause contention
between different instances of the same source (i.e., multiple
network interfaces).
Reviewed by: markm
|
|
|
|
|
|
| |
The AHCI part is not supported yet, but is in the works.
5.3 RC1 candidate
|
| |
|
|
|
|
| |
in FreeBSD probe mechanism.
|
|
|
|
|
|
|
|
|
|
|
| |
be used to announce various system activity.
The auxio device provides auxiliary I/O functions and is found on various
SBus/EBus UltraSPARC models. At present, only front panel LED is
controlled by this driver.
Approved by: jake (mentor)
Reviewed by: joerg
Tested by: joerg
|
|
|
|
|
|
| |
not really an error.
Submitted by: Gerrit Nagelhout
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with acpi but the timer runs twice as fast. Note that the main problem
(system doesn't work properly with acpi disabled) should be fixed separately.
Changes:
* Add a quirk to disable the timer
* Merge the P5A and P5A-B quirks since they appear to be based on the
same ASL.
PR: i386/72450
Tested by: Kevin Oberman <oberman es.net>
MFC after: 3 days
|
|
|
|
|
|
|
| |
Do not tell the hardware to send when there were no packets enqueued.
Found and reviewed by: green
MFC after: 1 days
|
|
|
|
| |
New device names are {tty,cua}G$(adapter)$(port)[.lock,.init]
|
|
|
|
| |
Reviewed by: jmallett
|
|
|
|
|
|
|
|
| |
This also adds support for bigger disks on the controller I have access to,
and maybe others if I understood the adhoc methods used on those.
Those with more PC98 bigdrive controllers it is hereby invited to add/fix
support for those in geom_pc98.c and not using #ifdef PC98 all over the place.
|
|
|
|
| |
OK'd by: dds
|
|
|
|
| |
the model etc fields from identify.
|
| |
|
| |
|
|
|
|
|
| |
The interchannel locking for PC98 needed to be updated to match the
rest of the locking in ATA.
|
|
|
|
|
|
|
| |
allocate unallocated memory resources from the top 32MB of the address
space rather than the top 2GB. While the latter works on some
chipsets, it fails badly on others. 32MB is more conservative and
matches what cheap harware from this era is hardwired to pass.
|
|
|
|
|
|
|
|
| |
table. acpidump(8) concatenates the body of the DSDT and SSDTs so an
edited ASL will contain all the necessary information. We can't use a
completely empty table since ACPI-CA reports this as a problem.
MFC after: 3 days
|
|
|
|
| |
Also divorce this driver from the sio driver.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
+ * 9: 0x3f0-0x3f3,0x3f4-0x3f5,0x3f7
This requires only one change to support. Rather than keying on the
size of the resource being 2, instead key off the end & 7 being 3.
This covers the same cases that the size of 2 would catch, but also
covers the new above case.
In addition, I think it is clearer to use the end in preference to the
size and start for case #8 as well. Turns two tests into one, and
catches no other cases.
Make minor commentary changes to deal with new case #9.
# This change is specifically minimal to allow easy MFC. A more
# extensive change will go into current once I've had a chance to test
# it on a lot of hardware...
|
|
|
|
| |
enabled, but not 3D.
|
| |
|
|
|
|
|
| |
Device names {cua,tty}R%r[.init,.lock] clashes with pty(4) driver
and allows for only 32 ports. This should probably be revisited.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(Atmel at76c503a http://vitsch.net/bsd/atuwi)
o AINCOMM AWU2000B
o ATMEL WL1130USB
PR: kern/72195
Submitted by: Daan Vreeken [PA4DAN] <Danovitsch@Vitsch.net>
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
| |
data endpoints. The control endpoint doesn't need read/write/poll
operations, and more importantly, the thread counts should be
separate so that the control endpoint can properly reference itself
while deleting and recreating the data endpoints.
* Add some macros that handle referencing/releasing devices, and use them
for sleeping/woken-up and open/close operations as apppropriate.
* Use d_purge for FreeBSD, and a loop testing the open status for all
the endpoints for NetBSD and OpenBSD, so that when the device is
detached, the right thing always happens.
|
|
|
|
|
|
|
|
|
|
| |
restart the current waiting transfer. If this isn't done, the device's
next transfer (that we would like to do a short read on) is going to
return an error -- for short transfer.
* For bulk transfer endpoints, restore the maximum transfer length each
time a transfer is done, or the first short transfer will make all the
rest that size or smaller.
* Remove impossibilities (malloc(M_WAITOK) == NULL, &var == NULL).
|
|
|
|
| |
from userland to get the debugging definitions.
|
|
|
|
|
|
|
|
|
|
|
| |
New device names are "{tty|cua}A$(card)$(port)[.init|.lock]"
Put a portname in the port structure if SI_DEBUG is defined to avoid
need to inspect minor number to construct name..
Constify some strings.
Remove duplicated DBG_ #defines.
|
|
|
|
| |
RI does not seem to be supported.
|
|
|
|
|
|
|
|
|
|
| |
is a no-op on little endian architectures, but fixes getting the MAC
address for some dc(4) cards on big endian architectures.
This is a RELENG_5 candidate.
Tested by: gallatin (powerpc), marius (sparc64)
First version of the patch written by: gallatin
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The driver doesn't look any less safe without Giant than with, and works
with IS_MPSAFE set to 1 here, so others should probably test it as such.
|
| |
|
|
|
|
| |
Submitted by: Manfred Antar <null@pozo.com>
|
|
|
|
|
|
|
|
|
|
|
| |
people have reported problems (stickyness, aiming difficulty) which is proving
difficult to fix, so this will default to disable until sometime after 5.3R.
To enable Synaptics support, set the 'hw.psm.synaptics_support=1' tunable.
MT5 candidate.
Approved by: njl
|
|
|
|
|
|
| |
ioctl.
Reported by: Christer Oberg <christer.oberg@deprotect.com>
|
|
|
|
|
|
|
|
|
| |
in the actual _FDE parsing. If the failure occurs earlier such as in
fdc_attach() then don't try to probe any drives.
MFC after: 3 days
Reviewed by: njl
Tested by: Christian Laursen xi at borderworlds dot dk
|
|
|
|
|
|
|
|
| |
This might fix some of the trouble around em(4) filling up its buffers.
Submitted by: mtm
Pointy hat to: mlaier
MFC after: 2 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to make sure the pipe is ready. Some devices apparently don't support
the clear stall command however. So what happens when you issue such
devices a clear stall command? Typically, the command just times out.
This, at least, is the behavior I've observed with two devices that
I own: a Rio600 mp3 player and a T-Mobile Sidekick II.
It used to be that after the timeout expired, the pipe open operation
would conclude and you could still access the device, with the only
negative effect being a long delay on open. But in the recent past,
someone added code to make the timeout a fatal error, thereby breaking
the ability to communicate with these devices in any way.
I don't know exactly what the right solution is for this problem:
presumeably there is some way to determine whether or not a device
supports the 'clear stall' command beyond just issuing one and waiting
to see if it times out, but I don't know what that is. So for now,
I've added a special case to the error checking code so that the
timeout is once again non-fatal, thereby letting me use my two
devices again.
|