required information. Problem found and diagnosed by jakllsch@; on some AMD
systems vendors fill _PSS correctly, but do not duplicate the data in XPSS.
this, the structure acpi_pciinfo now tells whether the ACPI
device node is a PCI bridge, a regular PCI device, or both.
Problem reported by jmcneill@, who also suggested the solution.
ok jmcneill@, jruoho@
XXX: This is kind of futile; the only user of the wskbd(4)'s hotkey interface
is hpqlb(4), which is a questionable driver, being, by design,
limited only to the laptop model for which the driver was written.
cursor start register. I think this only accidentally worked for the past
11 years because the start and end scanlines were both set to 0x10.
See also http://www.osdever.net/FreeVGA/vga/crtcreg.htm#0A
kernel module, and can be helpful to generate sysmon_envsys events
when creating/modifying powerd scripts. This will also be used in an
upcoming series of atf tests for sysmon_envsys itself.
- A word "mechanism" was accidently separated in to "me" and "chanism"
in comment.
No functional chanage and I found it while reading if_wm.c yesterday.
control and output switching, through ACPI video extensions.
TODO: use wsconsctl(8) instead of sysctl(8) for brightness control.
ok jruoho@
also discussed with cegger@ and jmcneill@
Make 'physical' element of the struct agp_allocate an uint32_t. This
is similar to what other kernels do (at least Solaris and Linux).
This patch should make xserver work again within an i386 userland in a
64 bits paddr_t world.
Thanks to Iain Hibbert for reporting the break, and providing initial hints.
See http://mail-index.netbsd.org/current-users/2010/09/27/msg014418.html
Clear the any endpoint stall in the interrupt handler. All other
drivers do this and I am pretty sure we need to as well, though I have
yet to see a stall in the handler.
Add support for the Zoom 3095 USB Fax Modem. There are some problems
with this modem:
1) The CS descriptors were placed after all other descriptors rather
than in the Control Interface. This is true in both configurations
and is the issue this patch deals with.
2) Modem audio is not done on the modem. There is a second
configuration with an extra interface (3 interfaces) which presumably
is for handling audio. This patch does not support that.
3) The interrupts are raised a bit slowly. This means that pppd(8)
needs to wait a bit before trying to read from the link (i.e., just
before the get_input() loop in src/dist/pppd/pppd/main.c line 547).
If you don't wait, then DCD will not be detected high before that
first read and get_input() will drop the line. This is not a problem
if you use the "local" option to pppd(8) and ignore DCD, but that is
less than desirable.
4) You apparently have to toggle "RSDL (DCD) option"[1] when you
initialize the modem or you will never see a second DCD high interrupt
when redialing after a disconnect. Without this the pppd(8) "persist"
mode will not work. Presumably, some extra initialization is missing
from the driver for this chipset.
[1] Send the AT commands: AT&C0 followed by AT&C1 - doing it in one
command doesn't work. The AT commands for this modem are at:
http://www.zoom.com/documentation/dial_up/3095F_ATcommands.pdf
one. Fixes a panic reported by njoly@ in private Email
2. Acquire the device before checking whether or not the get_limits
routine exists.
XXX There's still a bug in here somewhere that prevents setting of
XXX limit values after using 'envstat -S'
64 bit integers (eg, sparc). the problem was that the new 64 bit
element on the end was used for the offsetof() (aka size) for the old
structure, but this includes the padding required, thus the ioctl number
was set wrongly.
move all the supporting code for this inside COMPAT_50, with some renaming
to suit, and kill all the external definitions related to it.
tested on i386, amd64 and sparc.
which grew since netbsd 5.0 (hi christos!)
fix a few issues/problems:
- the COMPAT_30 code wasn't used since opt_compat_netbsd.h wasn't included
- move 'struct vnd_ouser' (for COMPAT_30) into vnd.c itself, and call it
'struct vnd_user30'
- same for VNDIOOCGET -> VNDIOCGET30
now 'vnconfig -l' works on -current with a netbsd-5 binary, using i386.
XXX: there is still a potential problem with the old VNDIOOCSET and
VNDIOOCCLR macros on some platforms like sparc. there is padding
between the old vnd_osize member and the new vnd_size member on
platforms that want 64 bit values 64 bit aligned, but are 32 bit
otherwise (like sparc.) 64 bit systems already end up with this
member 64 bit aligned, and should be fine.
this most likely results in the old ioctl numbers being wrong and
the code won't match/run ever (ENOTTY.)
queueing at the scsipi midlayer, and if the midlayer is not requested to
enable tagged queueing, the midlayer will only queue one command to the
adapter driver for each device. The SmartArray adapter is capable of
handling multiple commands, and in the rather common case where there is
no battery backup and no write cache, doing single write commands is very
slow. The SmartArray adapter runs much better when several commands can
be issued to a device.
This has been observed and discussed in several list threads, notably:
http://mail-index.NetBSD.org/netbsd-users/2008/10/01/msg002083.htmlhttp://mail-index.NetBSD.org/tech-kern/2008/11/30/msg003704.html
This also addresses PR kern/39686.
To enable tagged queueing, the adapter driver responds to the midlayer
request to set the transfer mode. However, the SmartArray does not respond
to the SCSI INQUIRY command with an ANSII field of 2 or more, so the
scsipi midlayer will ignore the CmdQue bit in the flags3 field of the
inquiry data. This fix will patch the inquiry data so set the ANSII field
to 2, and responds to the midlayer request to set the transfer mode by
requesting tagged queueing.
In addition, the original port of the driver did not set up the adapter
parameters correctly as mentioned in the second list thread mentioned
above. The adapt_openings is the total number of commands that the
adapter will accept rather than the number of commands divided by the
number of logical drives. Also, the adapt_max_periph is the maximum number
of commands which can be queued per peripheral device, not the number of
logical drives [which in the case of a single logical drive limited the
number of commands queued to 1].
I'm also suppressing an error message for invalid commands if the error
was due to the SCSI_SYNCHRONIZE_CACHE_10 command, since that command is
not supported by the SmartArray adapter, but used with wapbl(4) meta-data
journaling. Setting the ANSII version to 2 to allow enabling tagged queueing
also enables the use of the SCSI_SYNCHRONIZE_CACHE_10 command.
don't use ACPI on BIOS which advertise release years <= 2000. This
can be changed by setting option ACPI_BLACKLIST_YEAR=0 or by setting
acpi_force_load=1.
still matches more boards that just the one with the problem.
Interrupts from the SATA controllers on my MSI K8N Neo3 boards
(which both versions of this quirk matched) are broken when ACPI
is disabled. My board does not exhibit AE_AML_INFINITE_LOOP
problems.
If we want to avoid manually specifying RB_MD2 in boothowto on
pgoyette@'s board, we're going to have to find another way; perhaps
with the DMI strings available from pmf(9).
Anyhow, some boards needing RB_MD2 during boot(8) is in my opinion
better than others needing to set acpi_force_load in ddb or gdb.
Attach an USB device that looks like this:
ugen1 at uhub0 port 2
ugen1: detached
ugen1: at uhub0 port 2 (addr 3) disconnected
When unplugging the device:
usb_transfer_complete: xfer=0xffff80000832a800 not busy 0x00000055
usb_transfer_complete: bad dequeue 0xffff80000832a800 != 0x0
Note that the solution is not optimal. If ichlpcib(4) provides SpeedStep
support, possible I/O resource conflicts may occur with acpicpu(4). Ideally,
as noted for instance in Windows design documents, ichlpcib(4) should never
expose SpeedStep when ACPI is being used. The probability for potential race
conditions is however very small, being limited to few P4-era machines and
being dependent on user actions.
for an unknown notify. (The ACPI drivers should really not print anything
as we now have a global notify handler that can catch the debug information.)
will go backwards; K7 will not be supported already due doubts about
availability and reliability of ACPI during that era. Some unfortunate code
duplication is present (but not overly much). Thanks to cegger@ and jakllsch@
for patiently testing this.
from a callout, so delay was the only option (in those days). Then
the caller was converted to a thread, but left as a delay. It
still may block the scsipi completion thread processing (so I
seriously doubt this code path is executed very often on a live
system).
do the status-check when the comparison value reported by BIOS is not zero.
The uncertainty noted in the previous commit still applies. But if we ever
see a timeout again, it will likely be either a firmware bug or a special
case like the Intel Turbo Boost.
ACPI_NOTIFY_DEVICE_WAKE. Control method power and sleep buttons can
generate this event upon waking from G1 sleep to indicate that it was
responsible for waking the system.
- XPSS spec says that Status{,Mask} and Control{,Mask} buffers are 8 bytes
- use ACPI_GET64 macros instead of memcpy when reading from buffers
This makes acpicpu work again on my VIA C7-M, whose firmware reports
malformed XPSS packages but has a working _PSS
invariant APIC timer or an "ARAT" ("always running APIC timer"). This means
that the APIC timer may keep ticking at the same rate also in deep C-states
with some new or forthcoming Intel CPUs.
Intel processors. The invariance means that TSC runs at a constant rate
during all ACPI state changes. If it is variant, skew may occur and TSC is
generally unsuitable for wall clock services. This is especially relevant
with C-states; with variant TSC, the whole counter may be stopped with states
larger than C1. All x86 CPUs before circa mid-2000s can be assumed to have a
variant time stamp counter.
config_interrupts(9) to be executed. This is necessary because: (a) the
initialization routines must be run only once after interrupts are enabled
and (b) all ACPI CPUs have attached.
driver methods, call the driver's putchar() method to redraw the affected
areas.
For unaccelerated framebuffers where reads are expensive and we can't spare
any memory for a shadow framebuffer. Enabled by setting VCONS_DONT_READ in
scr_flags
- fix colour oddities seen occasionally on sparc64
- try to use firmware DAC wiring until we figure out what's wrong
TODO:
- find out why radeonfb gets the DAC wiring ass-backwards on my xvr-100
while Xorg's radeon driver gets it right
- find out why reverse characters aren't drawn in reverse
tested on macppc and sparc64
Comparable to T-states, this gives effectively a window of available
performance states for passive cooling. An example:
Init: max = 0, min = Pn.
Time j. Time j + 1.
----------- -----------
2000 MHz P0 max P0
P1 P1 max
P2 ==> P2
P3 P3 min
P4 P4
P5 min P5
500 Mhz Pn Pn
----------- -----------
Search: repeat (i = P0; i <= P5) repeat (i = P1; i <= P3)
1. Initialize P-states properly to P0. It is processor-specific
what value we might get without initialization. (Some AMD CPUs
have even specific registers for the state after cold reset.)
2. Following design notes for Windows, set the lowest-power P-state
upon suspend and restore the saved state after resume.
- no need to keep TX/RX mbufs during xfers in struct kue_chain
- check RX packet length more strictly in kue_rxeof()
- make some TX/RX handling in kue_send() and kue_rxeof() more readable
with proper functions
Tested on:
kue0: LINKSYS USB Network Adapter, rev 1.00/2.02, addr 5
dynamic maximum is nonexistent. Unsurprisingly, there is vagueness in the
standards; in ACPI 3.0 and 4.0 it is clearly indicated that also these methods
must be present, but the earlier standards are less stringent. Without too
much effort, at least one old P4-system was located that lacks _PPC.
Instead of specifying a range of supported sample rates based on the lowest
and highest available frequencies, only advertise rates that the codec reports
as working. Let aurateconv take care of the rest.
