- if the dates didn't match, fetch would append the received file to the
existing file instead of replacing it.
- if the local file was complete and up-to-date, fetch would miscalculate
the expected size and report a failure instead of a success, because it
had no way of knowing that the server was actually resending the entire
file since the requested offset was invalid.
than requested. Instead, inform the caller of the real offset by modifying
the offset field in the original struct url, and let him decide how to handle
the situation.
otherwise, the ng_ether.ko KLD will never be unloadable after
all Ethernet interfaces are detached, as it should be, because
of the lingering extra reference.
Submitted by: "Yevmenkin, Maksim N, CSCIO" <myevmenkin@att.com>
due to a paucity of IRQs. I have some reservations about this, so I'm
not going to MFC this just yet. I'm doing this to see how many
problems it causes so we can do this in 4.2. I've been seeing hangs
on my laptop from time to time, but sometimes it was not in polling
mode, other tmies it was. Don't know if this is one problem or more
than one.
Requested by: Sean O Connell
lock up under moderate to heavy load.
The status & command fields share a 32-bit longword. The programming
API of the eepro apparently requires that you update the command field
of a transmit slot that you've already given to the card. This means
the card could be updating the status field of the same longword at
the same time. Since alphas can only operate on 32-bit chunks of
memory, both the status & command fields are loaded from memory &
operated on in registers when the following line of C is executed:
sc->cbl_last->cb_command &= ~FXP_CB_COMMAND_S;
The race is caused by the card DMA'ing up the status at just the wrong
time -- after it has been loaded into a register & before it has been
written back. The old value of the status is written back, clobbering
the status the card just DMA'ed up. The fact that the card has sent
this frame is missed & the transmit engine appears to hang.
Luckily, as numerous people on the freebsd-alpha list pointed out, the
load-locked/store-conditional instructions used by the atomic
functions work with respect changes in memory due to I/O devices. We
now use them to safely update the command field.
Tested by: Bernd Walter <ticso@mail.cicely.de>
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
errors that plagued those cards with XFree86 4.0. They have two memory
ranges as well as an IO port range to them. Also cleaned up the three
warning messages that I got, from inb(), outb() and linuxulator. Also, I
noticed that the DRI and Glide support for the Voodoo4 and 5 has been
placed upon linux.3dfx.com, too bad they haven't released the tech docs
yet. Apparently, they are still pushing glide for all of us, so I will try
and add support once those tech docs are up.
binaries we just installed. This allows a future upgrade target to
install a new system without intermediate reboots and also
prevents conflicts for parallel make runs where we might exec a
binary that's being installed at the same time.
