Re: dfly hangs about a minute on the boot up when it's trying to search after SATA disks.

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Matthew Dillon wrote:

>     xpt is CAM related.  Several other people have had this same issue.
>     It is believed to be a software issue with the way CAM waits for
>     non-SCSI devices to attach to it.  Until I added the code that displayed
>     the warnings, nobody knew why their machine was taking so long to boot.
>     We haven't tracked the issue down yet (it is non-fatal so it hasn't been
>     a high priority).  If someone would like to investigate further, please
>     be my guest!
>
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>
>
>
> :dfly hangs about a minute on the boot up when it's trying to recognise my 
> :SATA controller.But i have disabled my SiL 3112 SATA conroller in bios but 
> :it's searching anyway. i got a warning message after the acd0 on the boot up 
> :too. i have pasted a bit from my dmesg in here too.

*SNIP*

This is not only 'non-fatal' it is out of our hands.

Once the ROM BIOS has been invoked on these economy
items, whether after MB BIOS POST and before DFLY
MBR boot,  or (second go-round) by DFLY ACPI workings
after MBR++,  it will run it's own binary, to it's own
timing parameters, before returning.

Problem exists on any OS that does its own scanning.
And there is nothing we can do to change that, save
skipping the device in ACPI if it is not intended
for our use.

DragonFly ACPI tools already provide for that,
but the pre-DragonFly MBR cycle will *still* run.

Bill

NNNN