run_interrupt_driven_hooks: still waiting... for xpt_config
Willem Jan Withagen
wjw at digiware.nl
Thu Jan 21 20:44:38 UTC 2010
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
>>> 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.
> 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
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
Thanx for getting me this far and giving the much needed pointer.
More information about the freebsd-stable