On Thu, Nov 11, 2004 at 03:51:00PM +0300, Artem K. Jouravsky wrote:
> 3ware Storage Controller device driver for Linux v1.02.00.037.
> 3w-xxxx: No cards found.
> 
> [root@athena root]# lspci
> 00:00.0 Host bridge: ServerWorks CNB20HE Host Bridge (rev 23)
> 00:00.1 PCI bridge: ServerWorks CNB20LE Host Bridge (rev 01)
> 00:00.2 Host bridge: ServerWorks CNB20HE Host Bridge (rev 01)
> 00:00.3 Host bridge: ServerWorks CNB20HE Host Bridge (rev 01)
> 00:01.0 VGA compatible controller: Alliance Semiconductor Corporation ProMotion AT3D (rev 02)
> 00:03.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
> 00:05.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01)
> 00:05.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01)
> 00:06.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
> 00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 51)
> 00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller
> 00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 04)
> 
> В выводе lspci его, как видно, просто _нет_. Между тем, при загрузке
> машины его отлично видно вместе с дисками. 

Это известная проблема, проявляющаяся на материнских платах с чипсетами
ServerWorks.  На многих таких машинах DSDT в BIOS не вполне соответствует
спецификации ACPI, в результате часть PCI-устройств оказывается
недоступна.  Пара таких плат уже была занесена в blacklist в ядре.

Загрузка с параметром pci=noacpi должна устранить эту проблему.  Кстати,
в dmesg на 2.4.26 в такой ситуации должно было появиться сообщение:

	Wrong _BBN value, please reboot and using option 'pci=noacpi'

Если есть возможность, пожалуйста, проверьте, как ведёт себя в этом
отношении ядро 2.4.27-std из Сизифа.  В этом ядре были сделаны некоторые
изменения в поддержке ACPI, которые, предположительно, должны обходить эту
проблему.  Просто установите это ядро, загрузите без указания опции
pci=noacpi и пришлите вывод dmesg.