Date: Sat, 14 Jul 2007 00:11:23 +0200 (CEST) From: "Gelsema, P \(Patrick\)" <gelsemap@superhero.nl> To: "Scott Long" <scottl@samsco.org> Cc: "Gelsema, P \(Patrick\)" <gelsemap@superhero.nl> Subject: Re: Difference between 6.2 and 7.0 Adaptec 39320D - 7.0 performing less Message-ID: <1084.10.202.77.103.1184364683.squirrel@webmail.superhero.nl> In-Reply-To: <462CDDA5.9080304@samsco.org> References: <200704162247.29909.gelsemap@superhero.nl> <16295.195.50.100.20.1176825375.squirrel@www.superhero.nl> <4624F4C3.30006@samsco.org> <200704182222.32069.gelsemap@superhero.nl> <462684E0.20105@samsco.org> <9987.195.50.100.20.1176979371.squirrel@www.superhero.nl> <46277B98.7080007@samsco.org> <2712.195.50.100.20.1176996182.squirrel@www.superhero.nl> <462A7CCB.6020302@samsco.org> <1193.10.202.77.103.1177345281.squirrel@webmail.superhero.nl> <462CDDA5.9080304@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, April 23, 2007 18:24, Scott Long wrote:
> Gelsema, P (Patrick) wrote:
>> On Sat, April 21, 2007 23:06, Scott Long wrote:
>>> Gelsema, P (Patrick) wrote:
>>>> 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@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)
>>>>>>>> @ /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
>>>>
>>> Regarding the speed problem, can you try the following change?
>>>
>>> ====
>>> //depot/projects/scottl-camlock/src/sys/dev/aic7xxx/aic79xx_osm.c#18 -
>>> /home/scottl/p4/camlock/src/sys/dev/aic7xxx/aic79xx_osm.c ====
>>> @@ -579,7 +579,7 @@
>>> } else {
>>> cpi->target_sprt = 0;
>>> }
>>> - cpi->hba_misc = 0;
>>> + cpi->hba_misc = PIM_SEQSCAN;
>>> cpi->hba_eng_cnt = 0;
>>> cpi->max_target = (ahd->features & AHD_WIDE) ? 15 : 7;
>>> cpi->max_lun = AHD_NUM_LUNS_NONPKT - 1;
>>>
>>> Scott
>>>
>> Tested, no success. Disk still recognised at 160MB/s and half the Mhz
>> (80).
>> I have tested 7-Current now with 3 different Disks (all seagate brand)
>> and all of them recognised with only half the speed. When I insert the
>> 6.2Release they get recognised at 320MB.
>>
>> Rgds,
>>
>> Patrick
>>
>
> Ok, I'll work on putting in a knob to turn off DV. I plan to completely
> re-write the DV code anyways. Thanks for testing and helping out. I'll
> let you know when I have something more to test.
>
> Scott
>
Hi Scott,
Finally I was able to buy a proper SCSI cable. QUite hard to get one from
the normal computershops. Anyways, I still have the same problem. Disks
still recognised as 160MB instead of 320. I am also having problems now
installing Current on AMD64 with 4GB of memory. Seems to be something with
memoryhole. Anyways.. I did a verbose boot and I've put the results on my
webserver. http://www.superhero.nl/messages
Hope this helps.
Also, any suggestions why I get mangled entry panics or after rebuilding
world/kernel I am unable to mount the root system? I believe it has
something to do with the memory hole, but am not sure..
Rgds,
Patrick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1084.10.202.77.103.1184364683.squirrel>