Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking

On 04.09.2013 00:48, Olivier Cochard-Labbé wrote:
> On Tue, Sep 3, 2013 at 8:10 PM, Outback Dingo <outbackdingo_at_gmail.com> wrote:
>> Can anyone confirm how well tested/stable this patch set might be?? if
>> theres positive input i have a zoo of dev machines i could load it on, to
>> help further it.
>> Just checking to see how widely its been tested,
>
> I've installed this patch on 3 differents machines there status after
> about 12hours:
> - SUN FIRE X4170 M2 (amd64: r255178) with 6 SAS harddrives in one big
> zraid (LSI MegaSAS Gen2 controller): Used for generating package with
> poudriere… no probleme since;
> - HAL/Fujitsu SPARC64-V (sparc64: r255178) with two SCSI-3 disks in
> gmirror: Used for generating package with poudriere too… no probleme
> since;

I've forgot to mention, but GEOM direct dispatch is now active only on 
x86 because GET_STACK_USAGE macro now defined only there and I wanted to 
stay on a safe side. On other archs GEOM works in old queued way. 
Somebody should port that small macro to other archs. But that is still 
interesting data point. Thanks.

> - HP EliteBook 8460p (amd64: r255188) with DVD replaced by a second
> hardrive (where fbsd is installed): It crash just after the message
> "GEOM: new disk ada1" during boot
>
> screenshot of the crash screen:
> http://goo.gl/tW1VIx
>
> A little more information:
> addr2line -e /boot/kernel/kernel.symbols 0xffffffff8083abd3
> /usr/src/sys/geom/geom_io.c:129

Unfortunately I can't reproduce that and have not enough clues. It may 
be specific to some GEOM class. Could you describe/show all GEOM 
topology, file systems, etc. you have there?
gpart show
sysctl kern.geom.confxml
...

Thank you!

-- 
Alexander Motin