Re: Switch from legacy ata(4) to CAM-based ATA

Sergey Kandaurov wrote:
> On 6 May 2011 12:33, Alexander Motin <mav_at_freebsd.org> wrote:
>> Sergey Kandaurov wrote:
>>> XENHVM uses it's own naming scheme and can name disks as daN or adN,
>>> depending on virtual block device id. atapci0/ata0/ata1 devices still present
>>> there (such as in Bruce Cran's dmesg), but no any disks attached from it:
>>> instead, all of them hung from device/vbd/N.
>>> [In a non-XENHVM mode they are attached from ataN channels, as usual.]
>>>
>>> /*
>>>  * Translate Linux major/minor to an appropriate name and unit
>>>  * number. For HVM guests, this allows us to use the same drive names
>>>  * with blkfront as the emulated drives, easing transition slightly.
>>>  */
>>>
>>> xenbusb_front0: <Xen Frontend Devices> on xenstore0
>>> xenbusb_back0: <Xen Backend Devices> on xenstore0
>>> xctrl0: <Xen Control Device> on xenstore0
>>> xbd0: 17000MB <Virtual Block Device> at device/vbd/768 on xenbusb_front0
>>> xbd0: attaching as ad0
>>> GEOM: ad0s1: geometry does not match label (16h,63s != 255h,63s).
>>> xbd1: 3812MB <Virtual Block Device> at device/vbd/2048 on xenbusb_front0
>>> xbd1: attaching as da0
>>> xbd2: 114439MB <Virtual Block Device> at device/vbd/2064 on xenbusb_front0
>>> xbd2: attaching as da1
>> OK, interesting question. I have built amd64 XENHVM kernel and booted it
>> under Xen 3.2. As result I've got double set of devices, via both
>> atapci0/ata0 and via blkfront:
>>
>> ada0 at ata0 bus 0 scbus0 target 0 lun 0
>> ada0: <QEMU HARDDISK 0.9.0> ATA-7 device
>> ada0: Serial Number QM00001
>> ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes)
>> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
>> ada0: Previously was known as ad0
>> ada1 at ata0 bus 0 scbus0 target 1 lun 0
>> ada1: <QEMU HARDDISK 0.9.0> ATA-7 device
>> ada1: Serial Number QM00002
>> ada1: 16.700MB/s transfers (WDMA2, PIO 8192bytes)
>> ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
>> ada1: Previously was known as ad1
>> xbd0: 476940MB <Virtual Block Device> at device/vbd/768 on xenbusb_front0
>> xbd0: attaching as ad0
>> xbd1: 476940MB <Virtual Block Device> at device/vbd/832 on xenbusb_front0
>> xbd1: attaching as ad1
>> Both of them were exported to GEOM. Extra set of adX devices caused
>> error messages. What am I doing wrong and why have I got those
>> duplicates? Was I required to remove non-PV drivers from my kernel?
> 
> Doh. This corresponds to errors omitted unintentionally in my previous mail.
> This is right after "xbd2: attaching as da1":
> 
> da0 at sym0 bus 0 scbus2 target 0 lun 0
> da0: <QEMU QEMU HARDDISK 0.10> Fixed Direct Access SCSI-3 device
> da0: 3.300MB/s transfers
> da0: Command Queueing enabled
> da0: 3812MB (7807527 512 byte sectors: 255H 63S/T 485C)
> can't re-use a leaf (led)!
> g_dev_taste: make_dev_p() failed (gp->name=da0, error=17)
> da1 at sym0 bus 0 scbus2 target 1 lun 0
> da1: <QEMU QEMU HARDDISK 0.10> Fixed Direct Access SCSI-3 device
> da1: 3.300MB/s transfers
> da1: Command Queueing enabled
> da1: 114439MB (234372222 512 byte sectors: 255H 63S/T 14588C)
> can't re-use a leaf (led)!
> g_dev_taste: make_dev_p() failed (gp->name=da1, error=17)
> 
> No ada devices detected though.

But you have duplicate daX here. It is just the same, except that you
have different Xen configuration -- disks configured as SCSI instead of ATA.

So the question is the same: how this supposed to work? To me, that
double detection problem seems much more significant then names change.

-- 
Alexander Motin