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 enable device.
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
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 enable device.
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
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 enable
device.
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
On Wed, 18 Sep 2002, GNUOrder wrote:
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.
if you get a romimage the flash_rom utility can write from linux.
Before running flash_rom you have to do this: setpci -d 8086:2480 4e.b=1 to enable flash writes.
then just flash_rom <romimage>
ron
Ronald G Minnich rminnich@lanl.gov writes:
On Wed, 18 Sep 2002, GNUOrder wrote:
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.
if you get a romimage the flash_rom utility can write from linux.
Before running flash_rom you have to do this: setpci -d 8086:2480 4e.b=1 to enable flash writes.
then just flash_rom <romimage>
Be very, very careful with this. Writing the rom is easy. Finding and setting all of the stupid CMOS type parameters in the romimage is a much more difficult proposition.
Which means the board will probably still require a little bit of keyboard and video attention once you are done.
Eric
On 22 Sep 2002, Eric W. Biederman wrote:
Be very, very careful with this. Writing the rom is easy. Finding and setting all of the stupid CMOS type parameters in the romimage is a much more difficult proposition.
this is true. What we have done here is: - dump cmos with Brian Finley's little cmos reader - flash bios - write cmos with Brian Finley's cmos writer
ron
On Sunday 22 September 2002 21:26, Ronald G Minnich wrote:
On 22 Sep 2002, Eric W. Biederman wrote:
Be very, very careful with this. Writing the rom is easy. Finding and setting all of the stupid CMOS type parameters in the romimage is a much more difficult proposition.
this is true. What we have done here is:
- dump cmos with Brian Finley's little cmos reader
- flash bios
- write cmos with Brian Finley's cmos writer
ron
Well luckly the roms were up to date but unluckly that didn't fix the problem. I ended up solving the problem going back to a 2.4.18 kernel from kernel.org. Something redhat patched their 2.4.18 kernel with is also in 2.4.19 and the fix in the 2.4.19-acX and 2.4.20-acX patches would cause the kernel to lock on boot. We just had to patch the driver to the eepro1000 to it and we were readt to go. thanks for the the advice though. I'm sure linuxbios would be much easier to upgrade remotely.
GO