both NPTL and old linuxthreads behaviour depending on process needs.
Apply to exit_group(), getpid() and getppid() to share them between
compat linux32 (non NPTL) and compat linux (NPTL) on amd64.
ok by manu and christos
writes they might issue to be delayed which keeps us from deadlocking
- don't splhigh() in cuda_intr() - usually we're there already. Instead do
the splhigh()/splx() dance when we're polling
- remove some leftover debugging gunk
flag. This ensures that -j<N> isn't accidentally inherited from the
environment, because the "--- foo ---" headers printed with -j<N> would
interfere with parsing the output.
From John Nielsen on freebsd-mobile.
Not tested, but almost certainly better than attaching as ugen.
FreeBSD has a UQ_ASSUME_CM_OVER_DATA quirk for this device; I can't
figure out what that means.
an unknown msg_type is received.
* Check the received packet size.
* Use strncpy() instead of strlcpy() so that we don't
send gibberish from the stack.
* No need to bind().
* htons()/htonl() use uint16_t/uint32_t not u_short/u_long.
* Sprinkle const.
* Use EXIT_FAILURE instead of 1.
* Use err(), errx().
* Use calloc() instead of malloc()+memset().
* timedc:
* Non-terminated hostnames or unknown tsp_type could
cause a crash due to out-of-bounds reads in msite().
* Check the received packet size.
* Merged duplicated code into functions.
* Moved variables into the relevant scopes.
* Use connect() so that only the receiver can reply,
send()/recv() can be used and rejected packets
are immediately noticed by recv() instead of causing
timeouts.
* Updated manpage.
Most Cardbus bridges supported by pccbb(4) fire a power-cycle
interrupt when the power state of a cardslot changes from 'off' to
'on'. TI bridges fire a power-cycle interrupt on both on->off and
off->on changes.
When pccbb_power() powered-down a cardslot, it did not wait around
for the power-cycle interrupt. When pccbb_power() powered-up a
cardslot, it did wait for the interrupt. If a pccbb_power(UP)
followed a pccbb_power(DOWN) very closely, pccbb_power() used to
interpret the power-cycle interrupt for the up->down transition as
"power-up complete," read the power-state bit and, finding that
power had NOT been activated, complain, "cbb0: power on failed?"
Then pccbb_power() exited before power-activation was complete,
falsely indicating that the power-activation *was* complete. After
that, a driver attach/enable routine would blithely configure a
card that was not fully powered-up. An operator who ran a command
such as 'ifconfig rtw0 down up' or 'ifconfig ath0 down up' would
read 'cbb0: power on failed?' in the system log, and their NIC
would misbehave.
This excerpt from a comment in the source should suffice to explain
how I fixed the bug,
/*
* Wait as long as 200ms for a power-cycle interrupt. If
* interrupts are enabled, but the socket has already
* changed to the desired status, keep waiting for the
* interrupt. "Consuming" the interrupt in this way keeps
* the interrupt from prematurely waking some subsequent
* pccbb_power call.
And this explains why this patch will work for Ricoh bridges that
do not fire an interrupt on the on->off transition:
* XXX Not every bridge interrupts on the ->OFF transition.
* XXX That's ok, we will time-out after 200ms.
*
* XXX The power cycle event will never happen when attaching
* XXX a 16-bit card. That's ok, we will time-out after
* XXX 200ms.
*/
M. Warner Losh and Charles M. Hannum provided valuable input on
this patch.
and also include files don't have mismatched .if/.endif
It has been suggested that make used to have this test, but I can't
remember removing any code that might have performed it.
jmcneill