allocate a short port range in some alpha configurations.
Submitted by: "Andrew M. Miklic" <miklic@udlkern.fc.hp.com>,
Mark Abene <phiber@radicalmedia.com>
only does IPv4 as our syslogd only does IPv4. I dunno if the KAME
people have any plans for syslogd).
PR: 19821
Submitted by: Nick Hilliard <nick@iol.ie>
Reviewed by: sheldonh
whitespace changes, which should not be a problem because this
is only the second revision of the file and translators are
unlikely to have gotten started yet.
Reviewed by: abial
when we're done reading it (makes checking things easier).
Before calling isp_notify_ack make sure we're at RUNSTATE-
elsewise we can be responding to LIPs or SCSI bus resets
before we've finished some of the wiring.
we need a function that tells the Qlogic f/w that a target mode command
is done, so increase the resource count for that lun. Add in a timeout
function to kick the putback again if we fail to do it the first time (we
may not have the request queue space for ATIO push). Split the function
isp_handle_platform_ctio into two parts so that the timeout function for
the ATIO push or isp_handle_platform_ctio can inform CAM that the requested
CTIO(s) are now done.
Clean up (cough) residual handling. What we need for Fibre Channel
is to preserve the at_datalen field from the original incoming ATIO
so we can calculate a 'true' residual. Unfortunately, we're not
guaranteed to get that back from CAM. We'll *try* to find it hiding
in the periph_priv field (layering violation)- but if an ATIO was
passed in from user land- forget it. This means that we'll probably
get residuals wrong for Fibre Channel commands we're completing
with an error. It's too late to 4.1 release to fix this- too bad.
Luckily the only device we'd really care about this occurring on
is a tape device and they're still so rare as FC attached devices
that this can be considered an untested combination anyway.
Remove all CCINCR usage (resource autoreplenish). When we've proved
to ourself that things are working properly, we can add it back
in.
Make sure we propage 'suggested' sense data from the incoming ATIO
into the created system ATIO- and set sense_len appropriately.
Correctly propagate tag values.
Fall back to the model of generating (well, the functions in isp_pci.c
do the work) multiple CTIOs based upon what we get from XPT. Instead
of being able to pair Qlogic generated ATIOs with CAM ATIOs, and then
to pair CAM CTIOs with Qlogic CTIOs, we have to take the CTIO passed
to us from XPT, and if it implies that we have to generate extra
Qlogic CTIOs, so be it. This means that we have to wait until the
last CTIO in a sequence we generated completes before calling xpt_done.
Executive summary- target mode actually now pretty much works well
enough to tell folks about.
interfaces. The original resource_find() returned a pointer to an internal
resource table entry. resource_find_hard() dereferences the actual
passed in value (oops!) - effectively trashing random memory due to
the pointer being passed in with a random initial value.
Submitted by: bde
up cam_fill_ctio usage to passed atio flags. Clear periph_priv area
of new ctio so if the kernel is dumb enough to look at them (this is
a SECURITY hole) the panic will be obvious instead of subtle.
pthread_cond_signal(), pthread_cond_broadcast(), and pthread_cond_timedwait().
Do not dump core in pthread_cond_timedwait() (due to a NULL pointer
dereference) if attempting to wait on an uninitialized condition variable.
PR: bin/18099
libfetch features (fetchRestartCalls, fetchXGet()).
Since it doesn't make much sense to have m_flag and r_flag set at the same
time, and it can actually cause trouble in some cases, die if they're both
set.
Set the SA_RESETHAND flag for SIGINT so that when we've caught one, we can
kill ourselves with a second SIGINT (thus notifying our parent of our tragic
fate) instead of just exiting.
These changes fix several problems that would show up when fetching ports,
as well as speeding up HTTP transfers quite a bit (at least for relatively
small files).
Most of these changes were prompted by an interaction problem with an HTTP
server called SWS-1.0, which exhibited two bugs, the first of which prevented
fetch from working around the second (the first was not sending content-type
in reply to HEAD requests, the second was sending garbage after the end of
the requested file).
fetchStat*(). In most cases, either fetchGet*() or fetchXGet*() is a wrapper
around the other; in all cases, calling fetchGet*() is identical to calling
fetchXGet*() with the second argument set to NULL.
outside the loop inspects it to determine whether or not we succeeded in
retrieving the requested document. This fixes a bug where fetchGetHTTP()
would return a FILE with an invalid file descriptor if it hit the redirect
limit without locating the requested document.
or not interrupted system calls will be restarted. This fixes a bug where
fetch(1) would hang (potentially forever) if a server stopped responding,
because the signal handler would absorb the user's efforts to interrupt the
transfer.
some reason, mboot.bootinst is not initialized to NULL at the beginning
of the program, then the last commit to this would try to free whatever
bogus address is in it.
- Restore the behavior of free()'ing the mboot.bootinst buffer after we
abuse it to determine the sector size of the disk (as clearly noted in
the comments). Properly fix the double free() bug by setting the pointer
to NULL after we free it.
There is a number of devices that are compliant, of which the 3Com 5605 is
has been verified to work.
The driver is not perfect yet, but should be able to get you somewhere.
The driver was originally written by Lennart Augustsson, but Mike Smith
and Mike Meyer <mwm@mired.org> did the porting.
3.3volt PCI/cardbus chipsets similar to the 98715 (and they have
512-bit hash tables). Also update the man page to mention the 98727/98732
and the SOHOware SFA110A Rev B4 card with the 98715AEC-C chip.
lock against themselves, causing infinite spinning. Brian Feldman
found this problem when testing with Mozilla and supplied the fix,
which I have revised slightly.
Here is the failure scenario. A thread calls dlopen() and acquires
the writer lock. While the thread still holds the lock, a signal
is delivered and caught. The signal handler tries to call a function
which hasn't been bound yet. It thus enters the dynamic linker
and tries to acquire the reader lock. Since the writer lock is
already held, it will spin forever in the signal handler. The
thread holding the lock won't be able to progress and release the
lock.
The solution is to block almost all signals while holding the
exclusive lock.
A similar problem could conceivably occur in the opposite order.
Namely, a thread is holding the reader lock and then a signal
handler calls dlopen() or dlclose() and spins waiting for the writer
lock. We deal with this administratively by proclaiming that signal
handlers aren't allowed to call dlopen() or dlclose(). Actually
we don't have to proclaim a thing, since signal handlers aren't
allowed to call any system functions except those which are explicitly
permitted.
Submitted by: Brian Fundakowski Feldman <green>
