Hi,
I'm seeing fetch hang under AMD64/RELENG_6 when fetching data
from several different sites. An i386 machinem sitting next to it
running current from a few weeks back is not showing this problem
when fetching the same files. The failing machine is a Dell 2850
with an em0 device. We have a T-
Hmm. Seems we close the window unexpectedly and the remote side doesn't
retransmit when we open it. FreeBSD's acks stop once the window is fully
open... aren't the acks supposed to retried longer? If not, shouldn't
fetch eventually see a socket close event instead of hanging forever?
A similar
> My dell Sc430 Server with Freebsd 5.4 gives soon after a reboot and minimal
> harddisk actions (erase a file or directory) strange messages concerning
> Adaptec SCSI adapter:
>From what I can tell from the full card dump state, the 39320 attempted
to send 77 transactions to your drive during a s
--On Friday, August 19, 2005 12:20 AM +0200 Hutterer Robert
<[EMAIL PROTECTED]> wrote:
Thank you very much for the reaction (about a dozen user reported similar
problems the last month -but there seems no answer/solution)
From what I can tell from the full card dump state, the 39320 attempted
>My old kernel, vintage 4.1.1, works fine with my three old Adaptec SCSI host
>bus adapters, two AHA1742A's and an AHA2842VL (yes, it's an old motherboard).
This was actually fixed a while back (week ago?) for EISA adapters. If
you card still doesn't work, please let me know.
--
Justin
To
>With a 4.3-BETA kernel from today (and also with one from a month or
>two ago) I can easily induce a panic by trying to copy an audio CD
>from an ATAPI drive to a SCSI disk on an ahc controller using this
>command:
The panic looks familiar, but I can't quite recall what the bug was.
Can you try
>Here is the current output from dmesg, let me know if this is not enough.
This looks like the bug I MFCed a fix for this morning. Please CVSup
again and resend output if the problem persists.
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the bod
>>
>> ahc: Data Parity Error Detected during address or write data phase
>> PCI Interupt at seqaddr=0x8 <- this also alternates with 0x9o
>>
>
>there seem to be some issues with the ahc driver in 4.3-BETA and BETA2
>see the "ahc invalidating pack" thread for some details.
>some fixes were just
>> This looks like a device issue. From what the controller can tell,
>> the jaz drive never re-selects us after taking a command and disconnecting.
>
>I had the same errors on my root drive (SEAGATE ST318404LW) too, I
>just didn't get to capture it.
I was only able to come to that conclusion by
