On Mon, 28 Feb 2005, Poul-Henning Kamp wrote:
I think you can trust sos@ to not do anything to the stuff in the tree
until he sticks the new stuff in there, so testing his patches like he
asked for is better use of your time.
Nate's patch looks straightforward enough to me. I'd like to see it in
On Tue, 29 Mar 2005, Karl Denninger wrote:
1.42: When resubmitting a timed out request, reset donecount.
1.41: Reset timeout when we are back from interrupt.
1.40: Correct logical error, result was that retries wasn't always made but
failure reported instead.
1.39: Do not retry on reques
On Tue, 29 Mar 2005, Karl Denninger wrote:
Pretty sure its the requeue (e.g. 1.40 and 1.42).
Isolate the specific change please.
--
10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00
___
freebsd-stable@freebsd.org mailing list
http://lis
On Tue, 29 Mar 2005, Karl Denninger wrote:
245a252
request->donecount = 0;
Without the last delta the requeue doesn't happen at all.
So you're saying that this change:
1.42: When resubmitting a timed out request, reset donecount.
produces the problem?
--
10 40 80 C0 00 FF FF FF FF
On Wed, 30 Mar 2005, Karl Denninger wrote:
Removing the FIRST delta, which is:
218a219,221
if (!dumping)
callout_reset(&request->callout, request->timeout * hz,
(timeout_t*)ata_timeout, request);
appears to get rid of the crashes while not harming data integr
On Thu, 31 Mar 2005, Karl Denninger wrote:
What do you expect the patch to do, given that removing the delta
appears to fix the instability problem?
I expect the patch to properly stop the callout.
--
10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00
On Thu, 31 Mar 2005, Karl Denninger wrote:
Would you prefer me to validate that path before or after I attempt to
validate that removing the first delta fixes the crashes on my
production machine? (Reason for the question is that the latter will
require most of the rest of the day and evening,
Ok, I've committed code from -CURRENT that should correctly deal with this
situation.
Let me know.
(and thanks for tracking this down.)
--
10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00
___
freebsd-stable@freebsd.org mailing list
h
On Mon, 28 Feb 2005, Poul-Henning Kamp wrote:
I think you can trust sos@ to not do anything to the stuff in the tree
until he sticks the new stuff in there, so testing his patches like he
asked for is better use of your time.
Nate's patch looks straightforward enough to me. I'd like to see it
On Sat, 9 Nov 2002, Andrew Atrens wrote:
> ... I still do find it a bit worrying that XFree86-cvs doesn't work
Its not worrying, its expected.
Our port has patches that have not yet been contributed back to the
XFree86 CVS tree.
--
| Matthew N. Dodd | '78 Datsun 280Z | &
then I need to figure out how to
catch this condition.
You need to get 3c5x9cfg.exe and run it. I have a feeling that your
EEPROM may have some corruption or something. Also, pull your card and
erase any markings in the test area of the card.
ftp://ftp.3com.com/pub/nic/3c5x9/3c5x9x.exe is the 3c5x9
I geuss I could buy 2 more NE2000 clones, but I have a ton of these
> 3C509's from work where they are converting to 100MHZ.
>
> Cany anyone sugest any way to help debug this problem. I would be happy
> to do anything that will help in getting this fixed.
>
s well.
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever |
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
13 matches
Mail list logo
