:> Hmm. You are getting a request timeout. Have you ever installed
:> DragonFly on this box before, or made any hardware changes
:> recently?
:> Is it something that worked before but does not work now?
:
:This is a first attempt to install dfly on this machine.
:
:I just thought it would be interesting to see dfly
:running on a dual opteron machine.
:
:Can it be some kind of problem with shared interrupts,
:and if so, how do I check it?
:
:J^2
Well, timeouts are often related to interrupt routing issues. The code
in both our tree and the FreeBSD tree is quite old, and looks
unmaintained. I only see one code fix in the FreeBSD tree that might
have an effect.
Try the patch below and see if that helps. It would also be useful
to get the dmesg from a verbose boot of the CD, and pciconf -l output.
Also, download a FreeBSD-current ISO and see if *it* can talk to your
disks via the mpt device.
If this patch doesn't do it we may be S.O.L. until a developer can get
his hands on a similar system and figure out what the problem is. If
the FreeBSD CD can talk to it then its likely to be related to
interrupt routing (we are somewhat behind in that area).
-Matt
Matthew Dillon
<dillon@backplane.com>
Index: mpt_freebsd.c
===================================================================
RCS file: /cvs/src/sys/dev/disk/mpt/mpt_freebsd.c,v
retrieving revision 1.6
diff -u -r1.6 mpt_freebsd.c
--- mpt_freebsd.c 19 Sep 2004 00:25:57 -0000 1.6
+++ mpt_freebsd.c 20 Mar 2005 22:56:17 -0000
@@ -256,11 +256,13 @@
ntodo = MPT_NSGL(mpt) - 1;
ce->NextChainOffset = (MPT_RQSL(mpt) -
sizeof (SGE_SIMPLE32)) >> 2;
+ ce->Length = MPT_NSGL(mpt)
+ * sizeof(SGE_SIMPLE32);
} else {
ntodo = nleft;
ce->NextChainOffset = 0;
+ ce->Length = ntodo * sizeof (SGE_SIMPLE32);
}
- ce->Length = ntodo * sizeof (SGE_SIMPLE32);
ce->Address = req->req_pbuf +
((char *)se - (char *)mpt_req);
ce->Flags = MPI_SGE_FLAGS_CHAIN_ELEMENT;