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_at_hulk.superhero.nl:/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)
>>>> _at_ /usr/src/sys/cam/cam_periph.c:559
>>>> Apr 18 22:08:22 hulk kernel: 2nd 0xffffffff80977f20 Giant (Giant)
>>>> _at_ /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