As discussed with Robert on IRC, checking the permissions on
/dev/console to see if we can call TIOCCONS could be unreliable. When we
run a chroot() without a devfs instance mounted inside, it won't
actually check the permissions on the device node inside the devfs
instance.
Using the already existing PRIV_TTY_CONSOLE for this seems like a better
idea.
Approved by: rwatson
reading from EEPROM doesn't seem to work on these controllers.
Reported by: Milan Obuch ( freebsd-net at dino dot sk )
Tested by: Milan Obuch ( freebsd-net at dino dot sk )
driver will need more serious help to work with an interrupt driven
path. There's many subtleties in driving the DMA engine with
interrupts in many configurations. Best to not "guess" what the right
way would be and mislead people.
memory allocation. It was change to include the range in the normal
memory area, so these ifdef'd out special cases are no longer useful
to keep around.
the device indicates that it wasn't able to write all the data in the
buffer out.
Ed Schouten doesn't like the idea of a panic here. I think for
production code, we need something better. For right now, while we're
trying to assess the impact of this issue, a panic is OK. So complain
to me, not him if this is hit.
- The vnode has to be locked exclusively before calling insmntque().
- Until I find a way to handle insmntque() failures use VV_FORCEINSMQ flag
to force insmntque() to always succeed.
Reported by: kris, trasz, des, others
Suggested by: kib
Tested by: trasz
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.
As reported by several users on the mailing lists, applications like
screen(1) fail to properly handle ^S and ^Q characters. This was because
MPSAFE TTY didn't implement packet mode (TIOCPKT) yet. Add basic packet
mode support to make these applications work again.
Obtained from: //depot/projects/mpsafetty/...
When I migrated tty_compat.c to MPSAFE TTY, I just hooked it up to the
build and fixed it until it compiled and somewhat worked. It turns out
this was not the smartest thing, because the old TTY layer also had a
field called t_flags, which contained a set of sgtty flags.
This means our current COMPAT_43TTY code overwrites the TTY flags,
causing all strange problems to occur. Fix this code to use a new struct
member called t_compatflags. This commit may cause kern/127054 to be
fixed, but this still has to be tested/confirmed by the originator. It
has to be fixed anyway.
PR: kern/127054
- add new diag commands: devinfo, sysinfo for U-Boot-style details about the system
configuration
- better memory info summary
- style corrections
Obtained from: Semihalf
