run_interrupt_driven_hooks: still waiting... for xpt_config

[Willem Jan Withagen]

Attilio Rao wrote:
> 2010/1/21 Willem Jan Withagen <wjw at digiware.nl>:
>> Willem Jan Withagen wrote:
>>> I'm trying to revive an old dual optern Tyan Tomcat S2875 board. Even
>>> upgraded it to the most recent BIOS. But still no go.
>>> Both with 8.0 and 7.2 RELEASE.
>>>
>>> I've also disabled P1394 and all USB in the BIOS, that did not work
>>> either.
>>> Only thing that is "extra" in the box is a an Areca 1120 controller.
>> Moved the bootable disk to an default SATA port on the MB, and removed the
>> Areca controller.
>> That gets ride of the problem, but it also creates a new problem since I'd
>> like to use the controller to handle a bunch of backup-disks.
>>
>> Suggestions on how to get the Areca controller passed the xpt_config test
>> are welcomed.
> 
> It may be linked to sbp(4) probabilly. Do you have it in your kernel?
> do you want to recompile it without if the answer is yes?
> It would be interesting to try it without ACPI and possibly see, in
> the hang case, on which IRQ (sharing with whatever other source) is.

cd /usr/src/sys/i386/conf
 > grep sbp *
GENERIC:#device         sbp # SCSI over FireWire (Requires scbus and da)
 >

But even a custom build kernel only, keeps hanging on the xpt_config.
Haven't tried without ACPI, but will do so within a moment.

And I'll be willing to compile any type of kernel and or patches that 
you care to suggest. The system is at the moment an idle brick that is 
going to run a 16 disk zfs system for backups. But until I fix this 
Areca problem, that isn't going to happen. And the previous 
backup-server is still up and running. So no pressure there.

So did some reboots....
Disabeling ACPI makes the board not complete the BIOS bootcycle.
It completes the ARECA BIOS, reports intr15. And freezes where normally 
you would get the BIOS summary of what is in the system, after which the 
BIOS boots from a device....

But this suggestion also made be select another PCI slot to try, an that 
slot made it boot.....

Interrupt-wise it also got assigned a different interrupt.
In the non-booting case it was intr19 on pci3 which intr was shared with 
em0.
In the booting case it was intr18 on pci18 which was shared with an 
InterSil 3114 controller.

So this sounds like motherboard BIOS does not play nice with setting up 
the devices???

Thanx for getting me this far and giving the much needed pointer.

--WjW