Re: Difference between 6.2 and 7.0 Adaptec 39320D - 7.0 performing less

On Thu, April 19, 2007 16:24, Scott Long wrote:
Gelsema, P (Patrick) wrote:
On Wed, April 18, 2007 22:51, Scott Long wrote:
Gelsema, P (Patrick) wrote:
On Tuesday 17 April 2007 18:24, Scott Long wrote:
Gelsema, P (Patrick) - FreeBSD wrote:
On Tue, April 17, 2007 16:45, Scott Long wrote:
Gelsema, P (Patrick) - FreeBSD wrote:
<SNAP></SNAP>

The 39320D is a finicky card. I don't recall putting in the code
that
would downshift the speed like this, but it wouldn't surprise me if
it
is a side effect of the system going slower. Anyways, it sounds
like
you're a good candidate/victim for the MPSAFE locking changes that
I
just made to the SCSI layer and the ahc/ahd drivers. Would you
mind
testing it out (just update to the latest 7-CURRENT sources) and
let
me
know how it works for you?
<SNAP></SNAP>

Is building world/kernel sufficient as test or do you want me to do
more
tests?
Any amount of testing that you can do is appreciated. Even verifying
that it boots is helpful =-)
Cvsupped this evening at about 6.15 UTC time (20:15 CET zone)
FreeBSD hulk.superhero.nl 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Apr
18
21:56:58 CEST 2007
root@xxxxxxxxxxxxxxxxx:/usr/obj/usr/src/sys/GENERIC
amd64

After buildworld and the whole lot the computer boots fine, however
the
disk
is still detected as only 160.00MB/s.

I do get the following crash. It seems to be related to pressing
scroll
lock
on the console and hitting the page up/down buttons. When I just log
on
locally or remotely it seems to be ok. When I hit the scroll lock key
before
or after logging on I get the below crash.

Apr 18 22:08:22 hulk kernel: lock order reversal: (Giant after
non-sleepable)
Apr 18 22:08:22 hulk kernel: 1st 0xffffff007b413358 ahd_lock
(ahd_lock)
@ /usr/src/sys/cam/cam_periph.c:559
Apr 18 22:08:22 hulk kernel: 2nd 0xffffffff80977f20 Giant (Giant)
@ /usr/src/sys/vm/vm_contig.c:590
Apr 18 22:08:22 hulk kernel: KDB: stack backtrace:
Apr 18 22:08:22 hulk kernel: db_trace_self_wrapper() at
db_trace_self_wrapper+0x3a
Apr 18 22:08:22 hulk kernel: witness_checkorder() at
witness_checkorder+0x4f9
Apr 18 22:08:22 hulk kernel: _mtx_lock_flags() at _mtx_lock_flags+0x75
Apr 18 22:08:22 hulk kernel: contigmalloc() at contigmalloc+0x63
Apr 18 22:08:22 hulk kernel: bus_dmamem_alloc() at
bus_dmamem_alloc+0x8d
Apr 18 22:08:22 hulk kernel: ahd_alloc_scbs() at ahd_alloc_scbs+0x32a
Apr 18 22:08:22 hulk kernel: ahd_get_scb() at ahd_get_scb+0x69
Apr 18 22:08:22 hulk kernel: ahd_action() at ahd_action+0x47c
Apr 18 22:08:22 hulk kernel: xpt_run_dev_sendq() at
xpt_run_dev_sendq+0x1ae
Apr 18 22:08:22 hulk kernel: xpt_action() at xpt_action+0x4d3
Apr 18 22:08:22 hulk kernel: dastart() at dastart+0x211
Apr 18 22:08:22 hulk kernel: xpt_run_dev_allocq() at
xpt_run_dev_allocq+0xf4
Apr 18 22:08:22 hulk kernel: dastrategy() at dastrategy+0x78
Apr 18 22:08:22 hulk kernel: g_disk_start() at g_disk_start+0xe6
Apr 18 22:08:22 hulk kernel: g_io_schedule_down() at
g_io_schedule_down+0x189
Apr 18 22:08:22 hulk kernel: g_down_procbody() at g_down_procbody+0x7a
Apr 18 22:08:22 hulk kernel: fork_exit() at fork_exit+0xaa
Apr 18 22:08:22 hulk kernel: fork_trampoline() at fork_trampoline+0xe
Apr 18 22:08:22 hulk kernel: --- trap 0, rip = 0, rsp =
0xffffffffac102d30,
rbp = 0 ---

Is this information sufficient? If not please let me know what more is
required.

Rgds,

Patrick

Thanks for the info. Fixing this problem is going to be a royal pain.
You can probably get around it by disabling WITNESS and INVARIANTS.

Scott

The computer seems to remain working even with the crash. Disabling
WINTNESS and INVARIANTS only disables the checking but not the actual
problem, is that correct?

If you want I can provide you full SSH access to the box to make working
on the fix of this problem easier? I am not using this box for anything
else than just toying, getting a better understanding. Just let me know.
HTH.


Thanks for the offer. I have tons of hardware, I just didn't think to
check the adaptec drivers on amd64 specifically. On i386 they don't
trigger the warning (though they do still have the same problem) so I
didn't notice it.

In case you require it later on, just let me know. It is the least I can
do after bombarding you with mails ;-)


Also the disk is still detected as only 160.00MB/s, any thought about
this?


I'll look into this as well. Actually, it might be a result of the
simple domain validation code that was added to 7-current a while back.
DV is both very tricky to implement and very tricky to predict in
operation, so what you're seeing might be a bug or it might be a
legitimate problem with your disk or cables.

Ok. The drive is brand new, the cable a bit less. But this is something I
can easily test. I got a Maxtor disk spare, I will install 7.0 on that
one. Cable is going to be a bit more cumbersome as I don't have any spare.
That might have to wait till late next week.

Rgds,

Patrick

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"