Weird CAM-ATA behaviour (8.0-RC1): disk cloning

[Kamigishi Rei]

Hello,

I just noticed something weird in my device list (actually, I noticed it
in "glabel status" output, but then confirmed via camcontrol devlist): I
got a 7th HDD, ada6, which is, surprisingly, ada0.

This is how it appeared (I've checked the logs):

Oct 27 01:26:38 ameagari sudo: fujibayashi : TTY=pts/3 ;
PWD=/usr/home/fujibayashi ; USER=root ; COMMAND=/sbin/camcontrol rescan
0:0:1
Oct 27 01:26:38 ameagari kernel: (aprobe0:ahcich0:0:0:1): SIGNATURE: 0000
Oct 27 01:26:38 ameagari kernel: ada6 at ahcich0 bus 0 target 0 lun 1
Oct 27 01:26:38 ameagari kernel: ada6: <ST3500320AS SD15> ATA/ATAPI-8
SATA 2.x device
Oct 27 01:26:38 ameagari kernel: ada6: 300.000MB/s transfers
Oct 27 01:26:38 ameagari kernel: ada6: 476940MB (976773168 512 byte
sectors: 16H 63S/T 16383C)
Oct 27 01:26:38 ameagari kernel: ada6: Native Command Queueing enabled
Oct 27 01:26:38 ameagari kernel: GEOM_MIRROR: Cannot add disk ada6 to
gm0 (error=17).

While I know I made a mistake there (specifying 0:0:1 instead of 1:0:0),
is this behaviour really correct? I don't see why we should add a
'cloned' disk device on a rescan of LUNs that do not really exist in the
first place.

This is repeatable and I can create as many clones as I want (by doing
"camcontrol rescan X:Y:Z" where Y and Z can vary and X is the AHCI bus
number):

Oct 31 04:15:55 ameagari sudo: fujibayashi : TTY=pts/3 ; PWD=/usr/src ;
USER=root ; COMMAND=/sbin/camcontrol rescan 0:1:1
Oct 31 04:15:55 ameagari kernel: (aprobe0:ahcich0:0:1:1): SIGNATURE: 0000
Oct 31 04:15:55 ameagari kernel: ada7 at ahcich0 bus 0 target 1 lun 1
Oct 31 04:15:55 ameagari kernel: ada7: <ST3500320AS SD15> ATA/ATAPI-8
SATA 2.x device
Oct 31 04:15:55 ameagari kernel: ada7: 300.000MB/s transfers
Oct 31 04:15:55 ameagari kernel: ada7: 476940MB (976773168 512 byte
sectors: 16H 63S/T 16383C)
Oct 31 04:15:55 ameagari kernel: ada7: Native Command Queueing enabled
Oct 31 04:15:55 ameagari kernel: GEOM_MIRROR: Cannot add disk ada7 to
gm0 (error=17).
Oct 31 04:15:55 ameagari kernel: GEOM: ada7s1: geometry does not match
label (255h,63s != 16h,63s).


Here's camcontrol output before rescan of 0:1:1:

fujibayashi@ameagari /usr/src % sudo camcontrol devlist -v
scbus0 on ahcich0 bus 0:
<ST3500320AS SD15>                 at scbus0 target 0 lun 0 (pass0,ada0)
<ST3500320AS SD15>                 at scbus0 target 0 lun 1 (ada6,pass6)
<>                                 at scbus0 target -1 lun -1 ()
scbus1 on ahcich1 bus 0:
<ST3500320AS SD15>                 at scbus1 target 0 lun 0 (pass1,ada1)
<>                                 at scbus1 target -1 lun -1 ()
scbus2 on ahcich2 bus 0:
<WDC WD5000AACS-00G8B0 05.04C05>   at scbus2 target 0 lun 0 (pass2,ada2)
<>                                 at scbus2 target -1 lun -1 ()
scbus3 on ahcich3 bus 0:
<ST3500320AS SD15>                 at scbus3 target 0 lun 0 (pass3,ada3)
<>                                 at scbus3 target -1 lun -1 ()
scbus4 on ahcich4 bus 0:
<ST3750330AS SD15>                 at scbus4 target 0 lun 0 (pass4,ada4)
<>                                 at scbus4 target -1 lun -1 ()
scbus5 on ahcich5 bus 0:
<ST3750330AS SD15>                 at scbus5 target 0 lun 0 (pass5,ada5)
<>                                 at scbus5 target -1 lun -1 ()
scbus-1 on xpt0 bus 0:
<>                                 at scbus-1 target -1 lun -1 (xpt0)


fujibayashi@ameagari /usr/src % uname -a
FreeBSD ameagari.fujibayashi.jp 8.0-RC1 FreeBSD 8.0-RC1 #29 r198327: Fri
Oct 23 05:29:41 JST 2009    
root@...:/usr/obj/usr/src/sys/Ameagari  amd64

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

[Alexander Motin-3]

Kamigishi Rei wrote:

> I just noticed something weird in my device list (actually, I noticed it
> in "glabel status" output, but then confirmed via camcontrol devlist): I
> got a 7th HDD, ada6, which is, surprisingly, ada0.
>
> This is how it appeared (I've checked the logs):
>
> Oct 27 01:26:38 ameagari sudo: fujibayashi : TTY=pts/3 ;
> PWD=/usr/home/fujibayashi ; USER=root ; COMMAND=/sbin/camcontrol rescan
> 0:0:1
> Oct 27 01:26:38 ameagari kernel: (aprobe0:ahcich0:0:0:1): SIGNATURE: 0000
> Oct 27 01:26:38 ameagari kernel: ada6 at ahcich0 bus 0 target 0 lun 1
> Oct 27 01:26:38 ameagari kernel: ada6: <ST3500320AS SD15> ATA/ATAPI-8
> SATA 2.x device
> Oct 27 01:26:38 ameagari kernel: ada6: 300.000MB/s transfers
> Oct 27 01:26:38 ameagari kernel: ada6: 476940MB (976773168 512 byte
> sectors: 16H 63S/T 16383C)
> Oct 27 01:26:38 ameagari kernel: ada6: Native Command Queueing enabled
> Oct 27 01:26:38 ameagari kernel: GEOM_MIRROR: Cannot add disk ada6 to
> gm0 (error=17).
>
> While I know I made a mistake there (specifying 0:0:1 instead of 1:0:0),
> is this behaviour really correct? I don't see why we should add a
> 'cloned' disk device on a rescan of LUNs that do not really exist in the
> first place.
>
> This is repeatable and I can create as many clones as I want (by doing
> "camcontrol rescan X:Y:Z" where Y and Z can vary and X is the AHCI bus
> number):

Interesting effect.

CAM ATA implementation doesn't use LUNs, in fact it ignores them. Also
you may scan PMP port's target IDs when not PMP present with alike
effect, as without PMP present nobody handles FIS port field. Probably
we need some per-bus local storage (at SIM or may be XPT) to keep
device's current status, reported by PMP driver.

Thank you.

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

[Alexander Motin-3]

Alexander Motin wrote:

> Kamigishi Rei wrote:
>> I just noticed something weird in my device list (actually, I noticed it
>> in "glabel status" output, but then confirmed via camcontrol devlist): I
>> got a 7th HDD, ada6, which is, surprisingly, ada0.
>>
>> This is how it appeared (I've checked the logs):
>>
>> Oct 27 01:26:38 ameagari sudo: fujibayashi : TTY=pts/3 ;
>> PWD=/usr/home/fujibayashi ; USER=root ; COMMAND=/sbin/camcontrol rescan
>> 0:0:1
>> Oct 27 01:26:38 ameagari kernel: (aprobe0:ahcich0:0:0:1): SIGNATURE: 0000
>> Oct 27 01:26:38 ameagari kernel: ada6 at ahcich0 bus 0 target 0 lun 1
>> Oct 27 01:26:38 ameagari kernel: ada6: <ST3500320AS SD15> ATA/ATAPI-8
>> SATA 2.x device
>> Oct 27 01:26:38 ameagari kernel: ada6: 300.000MB/s transfers
>> Oct 27 01:26:38 ameagari kernel: ada6: 476940MB (976773168 512 byte
>> sectors: 16H 63S/T 16383C)
>> Oct 27 01:26:38 ameagari kernel: ada6: Native Command Queueing enabled
>> Oct 27 01:26:38 ameagari kernel: GEOM_MIRROR: Cannot add disk ada6 to
>> gm0 (error=17).
>>
>> While I know I made a mistake there (specifying 0:0:1 instead of 1:0:0),
>> is this behaviour really correct? I don't see why we should add a
>> 'cloned' disk device on a rescan of LUNs that do not really exist in the
>> first place.
>>
>> This is repeatable and I can create as many clones as I want (by doing
>> "camcontrol rescan X:Y:Z" where Y and Z can vary and X is the AHCI bus
>> number):
>
> Interesting effect.

By the way it is not an ATA-specific problem. Here is ahc SCSI:

%camcontrol devlist
<HP HP35470A T503>                at scbus0 target 1 lun 0 (sa0,pass0)
<HP HP35470A T503>                at scbus0 target 1 lun 256 (pass3,sa2)
<HP HP35470A T503>                at scbus0 target 17 lun 0 (pass2,sa1)

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

[Scott Long-2]

On Oct 31, 2009, at 1:39 AM, Alexander Motin wrote:

> Alexander Motin wrote:
>> Kamigishi Rei wrote:
>>> I just noticed something weird in my device list (actually, I  
>>> noticed it
>>> in "glabel status" output, but then confirmed via camcontrol  
>>> devlist): I
>>> got a 7th HDD, ada6, which is, surprisingly, ada0.
>>>
>>> This is how it appeared (I've checked the logs):
>>>
>>> Oct 27 01:26:38 ameagari sudo: fujibayashi : TTY=pts/3 ;
>>> PWD=/usr/home/fujibayashi ; USER=root ; COMMAND=/sbin/camcontrol  
>>> rescan
>>> 0:0:1
>>> Oct 27 01:26:38 ameagari kernel: (aprobe0:ahcich0:0:0:1):  
>>> SIGNATURE: 0000
>>> Oct 27 01:26:38 ameagari kernel: ada6 at ahcich0 bus 0 target 0  
>>> lun 1
>>> Oct 27 01:26:38 ameagari kernel: ada6: <ST3500320AS SD15> ATA/
>>> ATAPI-8
>>> SATA 2.x device
>>> Oct 27 01:26:38 ameagari kernel: ada6: 300.000MB/s transfers
>>> Oct 27 01:26:38 ameagari kernel: ada6: 476940MB (976773168 512 byte
>>> sectors: 16H 63S/T 16383C)
>>> Oct 27 01:26:38 ameagari kernel: ada6: Native Command Queueing  
>>> enabled
>>> Oct 27 01:26:38 ameagari kernel: GEOM_MIRROR: Cannot add disk ada6  
>>> to
>>> gm0 (error=17).
>>>
>>> While I know I made a mistake there (specifying 0:0:1 instead of  
>>> 1:0:0),
>>> is this behaviour really correct? I don't see why we should add a
>>> 'cloned' disk device on a rescan of LUNs that do not really exist  
>>> in the
>>> first place.
>>>
>>> This is repeatable and I can create as many clones as I want (by  
>>> doing
>>> "camcontrol rescan X:Y:Z" where Y and Z can vary and X is the AHCI  
>>> bus
>>> number):
>>
>> Interesting effect.
>
> By the way it is not an ATA-specific problem. Here is ahc SCSI:
>
> %camcontrol devlist
> <HP HP35470A T503>                at scbus0 target 1 lun 0 (sa0,pass0)
> <HP HP35470A T503>                at scbus0 target 1 lun 256  
> (pass3,sa2)
> <HP HP35470A T503>                at scbus0 target 17 lun 0  
> (pass2,sa1)
>

It's not finding these on it's own is, it?  Rather, you're forcing it  
to scan a particular bus:target:lun, yes?  The problem here isn't that  
it's seeing phantom devices, it's that you're overflowing the ranges  
for the fields and getting wrap-around.  I don't know if the SIM or  
the XPT should be doing the range checking, and I don't know if  
checking was done in the past but is now broken.  I can't say that  
this problem is the same ATA.

Scott

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