while doing the block store workaround so we restore the correct
floating-point registers state in case of nested floating-point
operations resulting from nested interrupts. This allows the
VIS-based block copy/zero functions to be used on machines
requiring this workaround. Alternatively, we could take care of
saving the floating-point registers here, which would be more
inefficiently though and also involves turning off interrupts.
- It turns out that the SCZ_PCI_DMA_SYNC register doesn't work
like the TOMXMS_PCI_DMA_SYNC_PEND one (but more like the
corresponding register in of Hummingbird and Sabre bridges)
and writing the INO of the respective device to it causes a
Safari bus error. However, due to the Schizo errata I-23,
SCZ_PCI_DMA_SYNC can't be used as intended either, so remove
consistent DMA syncing for Schzio bridges for now, which means
that add-on cards with non-"sun4u compliant" (whatever that
means exactly) PCI-PCI-bridges should be avoided until the
proper workaround is implemented. [1]
Reported by: Michael Moll [1]
V9 stack bias so we no longer need to add it in db_backtrace()
and stack_capture() respectively. This also reverts r182018,
which kludged around the resulting unaligned access.
- Sync the sun4v versions of db_trace.c and stack_machdep.c with
the sparc64 ones and fix some style bugs.
MFC after: 3 days
controllers and it seems to work just fine with at least an
add-on SAS3080X. While at it, remove the commented out ncr(4)
as it doesn't even use bus_dma(9), which isn't worth fixing
though as sym(4) already supports a superset of the controllers
driven by ncr(4).
JBus to PCI 2.2 bridges. In theory, this driver should also handle
`XMITS' Fireplane/Safari to PCI-X bridges but due to lack of access
to such hardware, support for these hasn't be fleshed out, yet.
After I removed all the unit2minor()/minor2unit() calls from the kernel
yesterday, I realised calling minor() everywhere is quite confusing.
Character devices now only have the ability to store a unit number, not
a minor number. Remove the confusion by using dev2unit() everywhere.
This commit could also be considered as a bug fix. A lot of drivers call
minor(), while they should actually be calling dev2unit(). In -CURRENT
this isn't a problem, but it turns out we never had any problem reports
related to that issue in the past. I suspect not many people connect
more than 256 pieces of the same hardware.
Reviewed by: kib
to the C99 style. At least, it is easier to read sysent definitions
that way, and search for the actual instances of sigcode etc.
Explicitely initialize sysentvec.sv_maxssiz that was missed in most
sysvecs.
No objection from: jhb
MFC after: 1 month
consists of CPUs running at different speeds, for driving hardclock as
these timers in turn are driven at frequencies as low as 5MHz, resulting
in bad granularity compared to the TICK timers. However, don't employ
the workaround for the BlackBird erratum #1 when using the TICK timer
on machines with cheetah-class CPUs for performance reasons.
Reported by: Florian Smeets
could trigger an error interrupt that we can't actually to do anything
against as soon as enabling the error handlers.
While at it don't bother about writing only to the write-one-to-clear
bits when clearing error bits.
disable interrupts and loop forever with these.
- Hide all MP-related bits in <machine/smp.h> underneath #ifdef SMP.
- Inline ipi_all_but_self(9) and ipi_selected(9). We don't expose any
additional bits but save a few cycles by doing so.
- Remove ipi_all(9), which actually only called panic(9). It can't be
implemented natively anyway and having it removed at least causes
MI users to fail already fail when linking.
Safari- and JBus-based machines. Currently the main purpose of
these drivers is debugging of the resource allocation on nexus(4)
and the register content of these devices though.
the locked entry in it16 slot 0, which typically is occupied by the
PROM, and manually entering locked entries in slots != 0.
Thanks to Hubert Feyrer for donating the Blade 2000 this change was
developed on.
for all three contexts and configure the dt512_1 to hold 4MB pages for
them (e.g. for direct mappings).
This might allow for additional optimization by using the faulting
page sizes provided by AA_DMMU_TAG_ACCESS_EXT for bypassing the page
size walker for the dt512 in the superpage support code.
Submitted by: nwhitehorn (initial patch)
to synchronization needed after stores to internal ASIs in order
to make side-effects visible. This mainly requires the MEMBAR #Sync
after such stores to be replaced with a FLUSH. We use KERNBASE as
the address to FLUSH as it is guaranteed to not trap. Actually,
the USII synchronization rules also already require a FLUSH in
pretty much all of the cases changed.
We're also hitting an additional USIII synchronization rule which
requires stores to AA_IMMU_SFSR to be immediately followed by a DONE,
FLUSH or RETRY. Doing so triggers a RED state exception though so
leave the MEMBAR #Sync. Linux apparently also has gotten away with
doing the same for quite some time now, apart from the fact that
it's not clear to me why we need to clear the valid bit from the
SFSR in the first place.
Reviewed by: nwhitehorn
the ncr53c9x.c core where it actually belongs so future front-ends
don't need to add it.
o Use the correct OFW property when looking for the initiator ID of the
SBus device.
o Don't specify an alignment when creating the parent DMA tag for
SUNW,fas; their DMA engine doesn't require an alignment constraint
and it's no inherited by the child DMA tags anyway (which probably
is a bug though).
o Drop the superfluous sc_maxsync and use sc_minsync instead. The
former apparently was added due to a confusion with the maximum
frequency used in cam(4), which basically corresponds to the
inverse of minimum sync period.
o Merge ncr53c9x.c from NetBSD:
1.116: NCRDMA_SETUP() should be called before NCR_SET_COUNT() and
NCRCMD_DMA command in ncr53c9x_select().
1.125: free allocated resources on detach.
o Static'ize ncr53c9x_action(), ncr53c9x_init() and ncr53c9x_reset()
as these are not required outside of ncr53c9x.c.
o In ncr53c9x_attach() don't leak the device mutex in case attaching
fails.
o Register an asynchronous notification handler so in case cam(4)
reports a lost device we can cancel outstanding commands and
restore the default parameters for the target in question.
o For FAS366 correctly support 16-bit target IDs and let it know
that we use 32-bit transfers.
o Overhaul the negotiation of transfer settings. This includes
distinguishing between current and goal transfer settings of the
target so we can renegotiate their goal settings when necessary
and correcting the order in which tagged, wide and synchronous
transfers are negotiated.
o If we are requesting sense, force a renegotiation if we are
currently using anything different from asynchronous at 8 bit
as the target might have lost our transfer negotiations.
o In case of an XPT_RESET_BUS just directly call ncr53c9x_init()
instead of issuing a NCRCMD_RSTSCSI, which in turn will issue an
interrupt that is treated as an unexpected SCSI bus reset by
ncr53c9x_intr() and thus calls ncr53c9x_init(). Remove the now
no longer used ncr53c9x_scsi_reset().
o Correct an off-by-one error when setting cpi->max_lun.
o In replace printf(9) with device_printf(9) calls where appropriate
and in ncr53c9x_action() remove some unnecessarily verbose messages.
o In ncr53c9x_sched() use TAILQ_FOREACH() instead of reimplementing
it and consolidate two tagging-related target info checks into one.
o In ncr53c9x_done() set the CAM status to CAM_SCSI_STATUS_ERROR when
appropriate, respect CAM_DIS_AUTOSENSE and teach it to return SCSI
status information.
o In ncr53c9x_dequeue() ensure the tags are cleared.
o Use ulmin() instead of min() where appropriate.
o In ncr53c9x_msgout() consistently use the reset label.
o When we're interrupted during a data phase and the DMA engine is
still active, don't panic but reset the core and the DMA engine as
this should be sufficient. Also, the typical problem for triggering
this was the lack of renegotiation when requesting sense.
o Correctly handle DEVICE RESETs.
o Adapt the locking of esp(4) to MPSAFE cam(4). This includes moving
the calls of lsi64854_attach() to the bus front-ends so it can pass
the esp(4) mutex to bus_dma_tag_create(9).
o Change the LSI64854 driver to not create a DMA tag and map for the
Ethernet channel as le(4) will handle these on its own as well as
sync and unload the DMA maps for the SCSI and parallel port channel
after a DMA transfer.
o Cam(4)'ify some NetBSD-centric comments.
o Use bus_{read,write}_*(9) instead of bus_space_{read,write}_*(9)
and take advantage of rman_get_rid(9) in order to save some softc
members.
Reviewed by: scottl
MFC after: 1 month
table. This is required in order to set obp-control-relinquished
within the PROM, allowing to safely read the OFW translations node.
Without this, f.e. a `ofwdump -ap` triggers a fatal reset error or
worse things on machines based on USIII and beyond.
In theory this should allow to remove touching %tba in cpu_setregs(),
in practice we seem to currently face a chicken and egg problem when
doing so however.
to 43 bits so update TD_PA_BITS accordingly. For the most part this
increase is transparent to the existing code except for when reading
the physical address from ASI_{D,I}TLB_DATA_ACCESS_REG, which we
only do in the loader and which was already adjusted in r182478, or
from the OFW translations node.
While at it, ensure we are only taking valid OFW mapping entries
into account.
frequencies (and having different cache sizes) so use the STICK
(System TICK) timer, which was introduced due to this and is
driven by the same frequency across all CPUs, instead of the
TICK timer, whose frequency varies with the CPU clock, to drive
hardclock. We try to use the STICK counter with all CPUs that are
USIII or beyond, even when not necessary due to identical CPUs,
as we can can also avoid the workaround for the BlackBird erratum
#1 there. Unfortunately, using the STICK counter currently causes
a hang with USIIIi MP machines for reasons unknown, so we still
use the TICK timer there (which is okay as they can only consist
of identical CPUs).
- Given that we only (try to) synchronize the (S)TICK timers of APs
with the BSP during startup, we could end up spinning forever in
DELAY(9) if that function is migrated to another CPU while we're
spinning due to clock drift afterwards, so pin to the CPU in order
to avoid migration. Unfortunately, pinning doesn't work at the
point DELAY(9) is required by the low-level console drivers, yet,
so switch to a function pointer, which is updated accordingly, for
implementing DELAY(9). For USIII and beyond, this would also allow
to easily use the STICK counter instead of the TICK one here,
there's no benefit in doing so however.
While at it, use cpu_spinwait(9) for spinning in the delay-
functions. This currently is a NOP though.
- Don't set the TICK timer of the BSP to 0 during at startup as
there's no need to do so.
- Implement cpu_est_clockrate().
- Unfortunately, USIIIi-based machines don't provide a timecounter
device besides the STICK and TICK counters (well, in theory the
Tomatillo bridges have a performance counter that can be (ab)used
as timecounter by configuring it to count bus cycles, though unlike
the performance counter of Schizo bridges, the Tomatillo one is
broken and counts Sun knows what in this mode). This means that
we've to use a (S)TICK counter for timecounting, which has the old
problem of not being in sync across CPUs, so provide an additional
timecounter function which binds itself to the BSP but has an
adequate low priority.
sizes (and running at different frequencies) so move the cacheinfo
to the PCPU data. While at it, remove some redundant and/or unused
members from struct cacheinfo.
- In sparc64_init don't assume the first CPU node we find in the OFW
device tree is the BSP.
in order to avoid the invasive probes done by identify-routines of
ISA drivers, which may access unassigned addresses or those of
unrelated devices and thus in turn can trigger master/target aborts
as revealed by r182108 and ahc(4). I think that this is also the
cause of the hang previously seen on B100 blades during boot.
Bypassing isa_probe_children(9) also avoids adding ISA hints, which
just can be wrong for sparc64.
Reported by: gavin
in the kernel and copying it out, causing a panic when faulting on a
nofault entry. Handle this case gracefully by letting the kernel copy
functions return EFAULT instead. As such this change addresses the
same problem as r154721 does for i386.
MFC after: 3 days
In syscall, always make a copy of parameters from trapframe, this
becauses some syscalls using set_mcontext can sneakily change
parameters and later when those syscalls references parameters,
they will wrongly use register values in mcontext_t.
PR: 72998
MFC after: 3 days
the latency based on the Min_Gnt register so use the algorithm found
in OpenSolaris as they probably know how to interpret the value Sun
puts into these registers (previously, the latency calculated for
66MHz was most likely wrong) and for bridges additionally set up the
secondary latency register. Also set up the bridge control register
the way it's done in OpenSolaris. As the latency register don't apply
to PCI-Express and the bridge control setup wasn't tested on sun4v
(besides most likely not being needed), expand the #ifndef SUN4V
accordingly.
MFC after: 3 days
- Provide module dependency information.
- Static'ize ebus_release_resource() in order to match prototype.
- Remove outdated and/or obsolete comments.
- Fix whitespace bugs.
MFC after: 3 days
on the presence of fhc(4) instead; we by far don't support all of
the functionality provide by the clock board but in general it's
an integral part of FireHose-based systems which shouldn't be
possible to omit.
ukbd(4) does and that emulation was enabled by default, all three of
them work together with kbdmux(4) out of the box just fine.
- Fix some whitespace bugs.
MFC after: 3 days
The last half year I've been working on a replacement TTY layer for the
FreeBSD kernel. The new TTY layer was designed to improve the following:
- Improved driver model:
The old TTY layer has a driver model that is not abstract enough to
make it friendly to use. A good example is the output path, where the
device drivers directly access the output buffers. This means that an
in-kernel PPP implementation must always convert network buffers into
TTY buffers.
If a PPP implementation would be built on top of the new TTY layer
(still needs a hooks layer, though), it would allow the PPP
implementation to directly hand the data to the TTY driver.
- Improved hotplugging:
With the old TTY layer, it isn't entirely safe to destroy TTY's from
the system. This implementation has a two-step destructing design,
where the driver first abandons the TTY. After all threads have left
the TTY, the TTY layer calls a routine in the driver, which can be
used to free resources (unit numbers, etc).
The pts(4) driver also implements this feature, which means
posix_openpt() will now return PTY's that are created on the fly.
- Improved performance:
One of the major improvements is the per-TTY mutex, which is expected
to improve scalability when compared to the old Giant locking.
Another change is the unbuffered copying to userspace, which is both
used on TTY device nodes and PTY masters.
Upgrading should be quite straightforward. Unlike previous versions,
existing kernel configuration files do not need to be changed, except
when they reference device drivers that are listed in UPDATING.
Obtained from: //depot/projects/mpsafetty/...
Approved by: philip (ex-mentor)
Discussed: on the lists, at BSDCan, at the DevSummit
Sponsored by: Snow B.V., the Netherlands
dcons(4) fixed by: kan
virtualization work done by Marko Zec (zec@).
This is the first in a series of commits over the course
of the next few weeks.
Mark all uses of global variables to be virtualized
with a V_ prefix.
Use macros to map them back to their global names for
now, so this is a NOP change only.
We hope to have caught at least 85-90% of what is needed
so we do not invalidate a lot of outstanding patches again.
Obtained from: //depot/projects/vimage-commit2/...
Reviewed by: brooks, des, ed, mav, julian,
jamie, kris, rwatson, zec, ...
(various people I forgot, different versions)
md5 (with a bit of help)
Sponsored by: NLnet Foundation, The FreeBSD Foundation
X-MFC after: never
V_Commit_Message_Reviewed_By: more people than the patch
no particular reason for them to be implemented in assembler and
having them in C allows easier extension as well as using more C
macros and {d,i}tlb_slot_max rather than hard-coding magic (and
actually spitfire-only) values.
- Fix the compilation of pmap_print_tte().
- Change pmap_print_tlb() to use ldxa() rather than re-rolling it
inline as well as TLB_DAR_SLOT and {d,i}tlb_slot_max rather than
hardcoding magic (and actually spitfire-only) values.
- While at it, suffix the above mentioned functions with "_sun4u" to
underline they're architecture-specific.
- Use __FBSDID and macros instead of magic values in locore.S.
- Remove unused includes and smp_stack in locore.S.
As clearly mentioned on the mailing lists, there is a list of drivers
that have not been ported to the MPSAFE TTY layer yet. Remove them from
the kernel configuration files. This means people can now still use
these drivers if they explicitly put them in their kernel configuration
file, which is good.
People should keep in mind that after August 10, these drivers will not
work anymore. Even though owners of the hardware are capable of getting
these drivers working again, I will see if I can at least get them to a
compilable state (if time permits).
into a single "__asm"-statement as GCC doesn't guarantee their
consecutive output even when using consecutive "__asm __volatile"-
statement for them. Remove the otherwise unnecessary "__volatile". [1]
- The inline assembler instructions used here alter the condition
codes so add them to the clobber list accordingly.
- The inline assembler instructions used here uses output operands
before all input operands are consumed so add appropriate modifiers.
Pointed out by: bde [1]
MFC after: 2 weeks
