and intr_polarity enums for passing around interrupt trigger modes and
polarity rather than using the magic numbers 0 for level/low and 1 for
edge/high.
- Convert the mptable parsing code to use the new ELCR wrapper code rather
than reading the ELCR directly. Also, use the ELCR settings to control
both the trigger and polarity of EISA IRQs instead of just the trigger
mode.
- Rework the MADT's handling of the ACPI SCI again:
- If no override entry for the SCI exists at all, use level/low trigger
instead of the default edge/high used for ISA IRQs.
- For the ACPI SCI, use level/low values for conforming trigger and
polarity rather than the edge/high values we use for all other ISA
IRQs.
- Rework the tunables available to override the MADT. The
hw.acpi.force_sci_lo tunable is no longer supported. Instead, there
are now two tunables that can independently override the trigger mode
and/or polarity of the SCI. The hw.acpi.sci.trigger tunable can be
set to either "edge" or "level", and the hw.acpi.sci.polarity tunable
can be set to either "high" or "low". To simulate hw.acpi.force_sci_lo,
set hw.acpi.sci.trigger to "level" and hw.acpi.sci.polarity to "low".
If you are having problems with ACPI either causing an interrupt storm
or not working at all (e.g., the power button doesn't turn invoke a
shutdown -p now), you can try tweaking these two tunables to find the
combination that works.
IRQ is edge triggered or level triggered. For ISA interrupts, we assume
that edge triggered interrupts are always active high and that level
triggered interrupts are always active low.
- Don't disable an edge triggered interrupt in the PIC. This avoids
outb instructions to the actual PIC for traditional ISA IRQs such as
IRQ 1, 6, 14, and 15. (Fast interrupts such as IRQs 0 and 8 don't mask
their source, so this doesn't change anything for them.)
- For MCA systems we assume that all interrupts are level triggered and
thus need masking. Otherwise, we probe the ELCR. If it exists we trust
what it tells us regarding which interrupts are level triggered. If it
does not exist, we assume that IRQs 0, 1, 2, and 8 are edge triggered
and that all other IRQs are level triggered and need masking.
- Instruct the ELCR mini-driver to restore its saved state during resume.
register controlled the trigger mode and polarity of EISA interrupts.
However, it appears that most (all?) PCI systems use the ELCR to manage
the trigger mode and polarity of ISA interrupts as well since ISA IRQs used
to route PCI interrupts need to be level triggered with active low
polarity. We check to see if the ELCR exists by sanity checking the value
we get back ensuring that IRQS 0 (8254), 1 (atkbd), 2 (the link from the
slave PIC), and 8 (RTC) are all clear indicating edge trigger and active
high polarity.
This mini-driver will be used by the atpic driver to manage the trigger and
polarity of ISA IRQs. Also, the mptable parsing code will use this mini
driver rather than examining the ELCR directly.
systems. The fts.h here is an exact copy of include/fts.h (except for
an initial explanatory comment and the revision tags, of course). The
fts.c here is slightly modified from lib/libc/gen/fts.c so it can
compile correctly on non-FreeBSD systems.
violate POLA a little less by not requiring exactly two spaces in front
of the entry (and silently discarding any non-matching entry). We now
recognize anything starting with a letter followed by a colon as the
first non-space chars as a partition entry.
depending on namespace pollution in <sys/stat.h>. struct bintime is
only needed to satisfy leakage of kernel interfaces to userland and
namespace bugs in those interfaces...
not as a pending interrupt status, but as a matter of status quo.
Consequently, when there's no data to be transmitted the condition
is not cleared and uart_intr() is stuck in an infinite loop trying
to clear the UART_IPEND_TXIDLE status.
The z8530_bus_ipend() function is changed to return idle only once
after having sent any data.
The root cause for this problem is that we cannot use the interrupt
status bits of the SCC itself. The register that holds the interrupt
status can only be accessed by channel A and holds the status for
both channels. Using the interrupt status register would complicate
the driver because we need to synchronize access to the SCC between
the channels.
Elementary testing: marius
labeling new mbufs created from sockets/inpcbs in IPv4. This helps avoid
the need for socket layer locking in the lower level network paths
where inpcb locks are already frequently held where needed. In
particular:
- Use the inpcb for label instead of socket in raw_append().
- Use the inpcb for label instead of socket in tcp_output().
- Use the inpcb for label instead of socket in tcp_respond().
- Use the inpcb for label instead of socket in tcp_twrespond().
- Use the inpcb for label instead of socket in syncache_respond().
While here, modify tcp_respond() to avoid assigning NULL to a stack
variable and centralize assertions about the inpcb when inp is
assigned.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, McAfee Research
lookup for the label tag fails, return NULL rather than something close
to NULL. This scenario occurs if mbuf header labeling is optional and
a policy requiring labeling is loaded, resulting in some mbufs having
labels and others not. Previously, 0x14 would be returned because the
NULL from m_tag_find() was not treated specially.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, McAfee Research
to print the MAC label of the current process. "-M" selected as that's
what is used in Trusted IRIX.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, McAfee Research
returns okay when HW probe fails. This happens when comconsole flag is
set but VGA console is used instead.
Back out requested by: bde (He will be looking at other solutions from scratch)
test the label pointer for NULL before testing the label slot for
permitted values. When loading mac_test dynamically with conditional
mbuf labels, the label pointer may be NULL if the mbuf was
instantiated while labels were not required on mbufs by any policy.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, McAfee Research
synchronization protecting against dynamic load and unload of MAC
policies, and instead simply blocks load and unload. In a static
configuration, this allows you to avoid the synchronization costs
associated with introducing dynamicism.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, McAfee Research
This little thing can cause a deadlock, because taste mechanism start
to work after creation of ggate provider and I/O requests are sent from
other classes from the g_event thread, so number of pending events isn't 0.
Now ggatec(8) start second handshake and ggated(8) is trying to open
GEOM provider (for example md(4)) and it can't, because it hangs on
g_waitidle() in g_dev_open(). g_waitidle() cannot finish because
there is a pending read on event queue, and this read can't be
finished, because ggated(8) can't open target device.
GEOM Gate will recover from this deadlock, because requests will
timeout, but it of course isn't the best solution and I don't know
better one for now, so we should avoid opening GEOM providers while
there are pending requests in event queue.
