Yes, it looks like a new BIOS addresses this problem. One more question, is there a way to write the new BIOS out from linux on this motherboard? I'm pretty sure its the Tyan Thunder i7500 (S2720). It uses amiflash.zip.
GO
On Wednesday 18 September 2002 09:16, Jim Garlick wrote:
We had this exact problem on E7000-based Supermicro motherboards. It is a hardware problem with the way the motherboard initializes the P64H2 PCI controller on power-up that requires a BIOS workaround. (Intel improperly documented the requirements when the motherboards were designed, then after the fact issued an update to the P64H2 specification).
We were able to get a new BIOS from supermicro that fixes this. Linux Networx (Eric) is also doing LinuxBIOS for these boards and has the workaround implemented as well.
Jim
On Wed, 18 Sep 2002, GNUOrder wrote:
I was working on trying to get this box to turn on DMA for the drives and we get an error: We used the stock 2.4.18-3smp kernel from redhat 7.3 and also 2.4.19 from source. The motherboard is a dual P4 tyan, I didn't catch the model number.
We double checked the DMA settings and enabled an ugly hack (their term), still no go. From what it looks like, there is something with the ide controller at boot time that prevents the kernel from being able to set DMA.
From lspci: 00:1f.1 IDE interface: Intel Corp. 82801CA IDE U100 (rev 02) From dmesg: PCI: Device 00:1f.1 not available because of resource collisions
ICH3: (ide_setup_pci_device:) Could not enabledevice.
Does this look like a problem with BIOS or could this chipset be one that linux doesn't fully support yet? The customer bought it and had it sent to the server farm that will be hosting it so its not available to either of us. Yes, I know, why aren't we using scsi for a server. I would if I could.
GO
<Jerle> [root@taenaria root]# hdparm -d1 /dev/hda <Jerle> /dev/hda: <Jerle> setting using_dma to 1 (on) <Jerle> HDIO_SET_DMA failed: Operation not permitted <Jerle> using_dma = 0 (off) <Jerle> [root@taenaria root]# <[GNU]Order> type lspci <Jerle> [root@taenaria root]# lspci <Jerle> 00:00.0 Host bridge: Intel Corp. e7500 DRAM Controller (rev 02) <Jerle> 00:02.0 PCI bridge: Intel Corp. e7500 HI_B Virtual PCI-to-PCI Bridge (F0) (rev 02) <Jerle> 00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02) <Jerle> 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA PCI Bridge (rev 42) <Jerle> 00:1f.0 ISA bridge: Intel Corp. 82801CA ISA Bridge (LPC) (rev 02) <Jerle> 00:1f.1 IDE interface: Intel Corp. 82801CA IDE U100 (rev 02) <Jerle> 00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02) <Jerle> 01:02.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) <Jerle> 01:03.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 0c) <Jerle> 02:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03) <Jerle> 02:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03) <Jerle> 02:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03) <Jerle> 02:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03) <Jerle> 04:01.0 Ethernet controller: Intel Corp. 82544EI Gigabit Ethernet Controller (rev 02) <Jerle> PCI: Device 00:1f.1 not available because of resource collisions <Jerle> ICH3: (ide_setup_pci_device:) Could not enable device. <[GNU]Order> with lspci you got that last error? <Jerle> no, that was out of the dmesg <[GNU]Order> oh <Jerle> Just reprinting for reference. <[GNU]Order> the resource collisions one too? <Jerle> yes _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios