i386 to dev/acpi_support. In theory, these devices could be found
other than in i386 machines only as amd64 becomes more popular. These
drivers don't appear to do anything i386 specific, so move them to
dev/acpi_support. Move config lines to files so that those
architectures that don't support kernel modules can build them into
the kernel. At the same time, rename acpi_snc to acpi_sony to follow
the lead of all the other specialty devices.
connects to the keyboard and mouse and needs some special treatment.
Until this is fully understood, implemented and tested, simply avoid
probing the second Z8530. This is also what the zs(4) driver does.
table with console settings, we now only need to know at which
address the UART lives. Leaving the baudrate unspecified results
in us using the baudrate at which the UART operates. This removes
one parameter that can interfere with a successful installation
out of the box.
current baudrate setting. Use this ioctl() when we don't know the
baudrate of the sysdev (as represented by a 0 value). When the
ioctl() fails, e.g. when the backend hasn't implemented it or the
hardware doesn't provide the means to determine its current baudrate
setting, we invalidate the baudrate setting by setting it to -1.
None of the backends currently implement the new ioctl().
A baudrate we consider insane is silently replaced with 0. When the
baudrate is 0, we will not try to program the hardware. Instead we
leave the communication speed unaltered, maximizing the chance to
have a working console. Obviously this means we allow specifying a
0 baudrate for exactly that purpose.
- Because em_encap() can now fail in a way that leaves us without an
mbuf chain, potentially set *m_headp to NULL if that happens, so that
the caller can do the right thing. This case can occur when we try
to prepend the vlan header mbuf but can't allocate additional memory.
- Modify the caller of em_encap() to detect a NULL m_head and not try
to queue the mbuf if that happens.
- When em_encap() fails, make sure to call bus_dmamap_destroy() to
clean up.
but sk(4) is so prevalent on AMD64 motherboards we need to reduce the number
of round trips in the mailing lists trying to get sufficient information to
make sure we've got a handle on all the problems and are working towards
making sk(4) solid.
Submitted by: bz
isn't worth adding to the modules lists that we have to hard code for
this to work. Since we print PID right away, we have a trace point
already.
Minor knf while I'm here.
to a cdev and a devsw, doing all the relevant checks along the way.
Add the check to see if fp->f_vnode->v_rdev differs from our cached
fp->f_data copy of our cdev. If it does the device was revoked and
we return ENXIO.
Use this in all the places where sleeping with the lock held is not
an issue.
The distinction will become significant once we finalize the exact
lock-type to use for this kind of case.
return EINVAL rather than setting error, and don't free sops
unconditionally. The first change was merged accidentally as part of
the larger set of changes to introduce MAC labels and access control,
and potentially lead to continued processing of a request even after
it was determined to be invalid. The second change was due to changes
in the semaphore code since the original work was performed.
Pointed out by: truckman
models of laptops, which are essentially the same as the normal
ones, as far as acpi_asus is concerned[1]
o Use the above as an excuse to reshuffle the mess I made of the
probe function when I originally wrote it.
Reported by: Soeren Larsen <soeren@whiteswan.dk>
and has been broken twice:
- in the beginning of div_output() replace KASSERT with assignment, as
it was in rev. 1.83. [1] [to be MFCed]
- refactor changes introduced in rev. 1.100: do not prepend a new tag
unconditionally. Before doing this check whether we have one. [2]
A small note for all hacking in this area:
when divert socket is not a real userland, but ng_ksocket(4), we receive
_the same_ mbufs, that we transmitted to socket. These mbufs have rcvif,
the tags we've put on them. And we should treat them correctly.
Discussed with: mlaier [1]
Silence from: green [2]
Reviewed by: maxim
Approved by: julian (mentor)
MFC after: 1 week
This makes it possible to have more than one address with the same prefix.
The first address added is used for the route. On deletion of an address
with IFA_ROUTE set, we try to find a "fallback" address and hand over the
route if possible.
I plan to MFC this in 4 weeks, hence I keep the - now obsolete - argument to
in_ifscrub as it must be considered KAPI as it is not static in in.c. I will
clean this after the MFC.
Discussed on: arch, net
Tested by: many testers of the CARP patches
Nits from: ru, Andrea Campi <andrea+freebsd_arch webcom it>
Obtained from: WIDE via OpenBSD
MFC after: 1 month
