according to POSIX, not to mention the fact that it doesn't make sense
(and hence isn't really implemented). This causes the fifo_misc
regression test to succeed.
that don't obviously fit into create, open, and io. For now, add only a
regression test to make sure that lseek() fails with ESPIPE (which it
doesn't).
file descriptor. Otherwise, the read end of a fifo might return that it
is writable (which it isn't).
Only poll the fifo for write events if the fifo attached to a writable
file descriptor. Otherwise, the write end of a fifo might return that
it is readable (which it isn't).
In the event that a file is FREAD|FWRITE (which is allowed by POSIX, but
has undefined behavior), we poll for both.
MFC after: 3 days
to poll the write socket for, the fifo polling code proceeded to poll
for the complete set of events. Use 'levents' instead of 'events' as
the argument to poll, and only poll the write socket if there is
interest in write events.
MFC after: 3 days
while sleeping to allocate fifo state: due to using the vnode lock to
serialize access to a fifo during open, it shouldn't happen (tm).
MFC after: 3 days
In case this causes trouble for some other chipsets add a comment how to
proceed. If we don't get bugreports, this should be removed after a while
(some releases?).
PR: 56617 [1], 29465, 39260, 40574, 68225
Submitted by: Matthew E. Gove <mgove@comcast.net> [1]
Apologies to everyone who has run portsnap in 7.0-CURRENT since
Tuesday; if there is a file "/.portsnap.INDEX" on your system, you can
delete it (or even better, move it to /usr/ports/.portsnap.INDEX).
Big pointy hat to: cperciva
Reported that things weren't working properly: Aleksander Fafula
believe that there are PC98 systems with an OPTi chip.
I don't know enough about this special PC architecture to be sure about
this, so let's find out by letting people with such a system complain in
case this commit breaks the sound system for them. It's easy to revert
then.
PR: 45673
Submitted by: Watanabe Kazuhiro <CQG00620@nifty.ne.jp>
same as today: do no power management. 1 means be conservative about
what you power down (any device class that has caused problems gets
added here). 2 means be agressive about what gets powered down (any
device class that's fundamental to the system is here). 3 means power
them all down, reguardless. The default is 1.
The effect in the default system is to add mass storage devices to the
list that we don't power down. From all the pciconf -l lists that
I've seen for the aac and amr issue, the bad device has been a mass
storage device class.
This is an attempt at a compromise between the very small number of
systems that have extreme issues with powerdown, and the very large
number of systems that gain real benefits from powerdown (I get about
20% more battery life when I attach a minimal set of drivers on my
Sony). Hopefully it will strike the proper balance.
MFC After: 3 days (before next beta)
