"vm_fault: fault on nofault entry, addr: %lx" panic. The problem was a
stale PTE in the TLB that marked the page as not present, even though
we had a good PTE in the VHPT. We typically don't yet insert PTEs in
the TLB. We do that lazily. The CPU will look for the PTE in the VHPT
when there's no PTE in the TLB. Unfortunately this doesn't handle the
case of the stale PTE in the TLB. The quick fix is to invalidate the
TLB (sloppily) when the VHPT doesn't contain a valid PTE. This is also
the only case that may cause a PTE in the TLB that marks a page as
non-present.
When in inetd mode, this prevents bogus messages from
appearing on the control channel. When running as a
daemon, we shouldn't write to the terminal we used to
have at all.
PR: bin/74823
MFC after: 1 week
four different locations on a prospective filesystem.
If we found none, we forgot to invalidate the four buffers, thus the
following sequence would fails:
(md0 = blank disk)
mount /dev/md0 /mnt
(fails, no superblocks)
newfs /dev/md0
(writes using physio which does not go through buffercache).
mount /dev/md0 /mnt
(still fails, the four cached buffers still contain no superblocks)
Found by: ru
between object code generated without the flag but it makes sense and might
make a difference in the future.
PR: kern/53008
Submitted by: Jens Rehsack rehsack at liwing de
without Open Firmware:
- The PCI data structure of some HME PROMs contains a non-zero interface
revision in the class code. Thus remove the checks for matching class
code and PCI data structure length and revsion. These were pretty much
useless anyway as we only really need the pointer to the VPD which is
located before the structure length and revision fields.
- On Sun QFE (Quad FastEthernet) cards read the Nth MAC-address for the
Nth HME controller instead of always the first one for all four HMEs. [1]
- Improve the comment describing the used VPD format to better reflect
reality.
- Minor clean-up.
Prodded by: joerg [1]
ia64) was not the result of a change in the vector operations. It
was caused by the NFS locking code using a FIFO and those bypassing
the vnode. This indirectly caused the panic. The NFS locking code
has been changed.
Requested by: phk
on ia64) was not the result of a change in the vector operations. It
was caused by the NFS locking code using a FIFO and those bypassing
the vnode. This indirectly caused the panic. The NFS locking code has
been changed.
Requested by: phk
Transcription of the Bell Communications Research Colloquium Seminar
7 March 1986 by J. F. Kaiser:
There are wavelengths that people cannot see, there are
sounds that people cannot hear, and maybe computers have thoughts
that people cannot think.
ia64) was not the result of a change in the vector operations. It
was caused by the NFS locking code using a FIFO and those bypassing
the vnode. This indirectly caused the panic. The NFS locking code has
been changed.
Requested by: phk
on ia64) was not the result of a change in the vector operations. It
was caused by the NFS locking code using a FIFO and those bypassing
the vnode. This indirectly caused the panic. The NFS locking code has
been changed.
Requested by: phk
device numbers. In particular, this should fix
a bug where archiving a device node with a very
large minor number would sometimes overflow and
corrupt the major number.
Thanks to: Ben Mesander
MFC after: 7 days
