Help fixing a bug; HP MicroServer N40L; CAM status: Command timeout

[Yudi V]

> The output of dmesg indicates that the drives are of different
> speed capabilities (2 x 300MB/s, 2 x 150MB/s). Are those the
> four ones that occupy the 4 cages (and are probably connected
> to the same controller)?
>
4-bay cage has the 2 Hitachi drives (ada1 and ada0 holds just data in a
2-way mirror on a separate pool) that are on the 3Gbps link and once I sort
out this issue I am going to add two more drives to this pool.

and the Samsung drives (ada2 and ada3 are on the internal sata port and the
eSata link @ 1.5Gbps link in IDE mode) have the OS (again 2-way mirror on a
separate pool)

>
> If you check "dmesg | grep ahci" you can see which controllers
> are available. Using "camcontrol devlist" you can examine how
> the drives are connected to the available buses.
>
> output of  "dmesg | grep ahci"

> =============================
> ahci0: <AMD SB7x0/SB8x0/SB9x0 AHCI SATA controller> port
> 0xd000-0xd007,0xc000-0xc003,0xb000-0xb007,0xa000-0xa003,0x9000-0x900f mem
> 0xfe6ffc00-0xfe6fffff irq 19 at device 17.0 on pci0
> ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported
> ahcich0: <AHCI channel> at channel 0 on ahci0
> ahcich1: <AHCI channel> at channel 1 on ahci0
> ahcich2: <AHCI channel> at channel 2 on ahci0
> ahcich3: <AHCI channel> at channel 3 on ahci0
> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
> ada1 at ahcich2 bus 0 scbus2 target 0 lun 0
>
======================================

output of "camcontrol devlist"
===================================
<Hitachi HDS723030ALA640 MKAOAA10>  at scbus0 target 0 lun 0 (ada0,pass0)
<Hitachi HDS723030ALA640 MKAOAA10>  at scbus2 target 0 lun 0 (ada1,pass1)
<SAMSUNG HM080HI AB100-17>         at scbus4 target 0 lun 0 (ada2,pass2)
<SAMSUNG HM080HI AB100-17>         at scbus4 target 1 lun 0 (ada3,pass3)
======================================================

>
>
> > so how to make sure I include the patch?
>
> Download it and apply it using the "patch" command, for
> example "patch < /tmp/the-patch-file".
>

I will try this and post back later.

>
>
> >  I will reread the docs and try rebuilding the kernel again.
>
> If you have confirmed that v11 works for you, why not use the
> current snapshot? It already seems quite stable...
>

confirmed v11 does not have this issue, I installed it on the same system
in a different dataset and it works fine but I am not brave enough to run a
developmental version on a file server.
I am struggling to fix  a single bug and imagine the grief I will have to
face if I encounter an issue with  v11.


-- 
Kind regards,
Yudi