for the convenience of rc.d. Now it has happily lived there for quite
a while. So move the pkill(1) source files from usr.bin to bin, too.
Approved by: gad
The syscons code disabled scroll lock inside sc_cnputs() if it's going
to print a system message. The code currently wants to process any TTY
output data as well, but we cannot do this, because the TTY lock is a
sleep mutex, while cnputs() picks up a spin mutex.
Disable the code for now. It solves a panic when a console message is
printed while scroll lock is enabled. One solution would be to
initialize a task structure here.
Reported by: Paul B. Mahol <onemda gmail com>
from umodem and ufoma.
With these changes, umodem kinda works for me now. It certainly gets
past the "tip" bug that I found earlier where 115200 wasn't a valid
baud rate. This was "broken" in the mpsafetty commit, but in reality,
umodem was always broken.
When I imported the MPSAFE TTY code, I added the -p flag to sh(1)'s
ulimit, but I forgot to document it in the appropriate manual page.
Requested by: stefanf
translation. It turns out this is useful for applications which require
source port randomization for security (i.e. dns servers).
Discussed with: secteam
Requested by: mlaier
MFC after: 2 weeks
errata of USIII and beyond (USIII erratum #19, USIII+ erratum #1,
USIIIi erratum #1).
- Use the cheetah PA mask in {d,i}tlb_va_to_pa_sun4u() for USIII
and beyond. This is done so that these functions will still mask
the debug bits of spitfire-class CPUs once we increase TD_PA_BITS
to match the number of bits used for the PA by cheetah-class CPUs.
- Change {d,i}tlb_enter_sun4u() to also set TLB_CTX_KERNEL as the
context of the mappings entered. This is more or less cosmetic as
TLB_CTX_KERNEL is 0.
- Now that we have to distinguish between different sun4u CPUs in
the loader anyway, no longer do trial and error when reading the
portid property.
first one. U-boot, for example, uses the second register to store
MAC.[1]
- Use random MAC address if none configured instead of failing.
Submitted by: Bjorn Konig <bkoenig@alpha-tierchen.de> [1]
Reviewed by: imp
Approved by: kib (mentor)
MFC after: 1 week
lock tracking and checks, doing just the former ones.
- Fix a bug where sysctl utility was printing crazy values when setting a
new value for debug.witness.watch [0]
[0] Reported by: yongari
- In the current design, when a TTY decreases its baud rate, it tries to
shrink the queues. This may not always be possible, because it will
not free any blocks that are still filled with data.
Change the TTY queues to store a `quota' value as well, which means it
will not free any blocks when changing the baud rate, but when placing
blocks back into the queue. When the amount of blocks exceeds the
quota, they get freed.
It also fixes some edge cases, where TIOCSETA during read()/
write()-calls could actually make the queue a tiny bit bigger than in
normal cases.
- Don't leak blocks of memory when calling TIOCSETA when the device
driver abandons the TTY while allocating memory.
- Create ttyoutq_init() and ttyinq_init() to initialize the queues,
instead of initializing them by hand. The new TTY snoop driver also
creates an outq, so it's good to have a proper interface to do this.
Obtained from: //depot/projects/mpsafetty/...
anholt thinks that he added this check as part of some regression testing,
but it is failing at least some of the time. I don't want to remove it
just yet. I added a bit of debugging to help identify the issue.
Approved by: kib
wind up with the incorrect checksum on the wire when transmitted via
devices that do checksum offloading.
PR: kern/119635
Reviewed by: rwatson
MFC after: 5 days
stopped nor the waiting state and also no other means to check
whether the receiver is idle (see also r163774), we have no choice
than to call mii_tick(9) unconditionally even in the case of the
DC_REDUCED_MII_POLL handling as far as the RX side is concerned.
This isn't necessarily worse than checking whether RX is idle
though because unlike as with TX we're racing with the hardware,
which might receive packets any time while we poll the MII, anyway.
Reported and tested by: Jacob Owens
Reviewed by: yongari
MFC after: 3 days
