On Saturday, 17. November 2001 19:35, Andrew Klaassen wrote: > On Sat, Nov 10, 2001 at 05:18:09PM +0100, > > Hans-Peter Jansen wrote: > > With 2 TX2, I got very poor performance on the second ctrl. > > because driven in PIO mode :-( > > I read somewhere that the BIOS versions on each of the > Ultra100TX2 controllers have to be exactly the same for them to > work properly together. You might want to check whether your > cards have different BIOS revisions... > Andrew Klaassen Negative. In further investigations I found the second adapter is sharing it's IRQ with eth0, which is one of the onboard 3Com 3c980-TX 10/100baseTX NICs. I've tried to block the corresponding interrupt, but this fscking BIOS can't select irq lines per PCI slot. It can only block irq's generally?!? I haven't found any options in 3c59x to select an interrupt, either. The question is, could this irq sharing be the reason for the driver to not initialize the device correctly. <4> ide4: BM-DMA at 0x3010-0x3017 -- ERROR, PORT ADDRESSES ALREADY IN USE <4> ide5: BM-DMA at 0x3018-0x301f -- ERROR, PORT ADDRESSES ALREADY IN USE because ioport space seems sane: 1c00-1c7f : 3Com Corporation 3c980-TX 10/100baseTX NIC [Python-T] 1c00-1c7f : 00:0f.0 1c80-1cff : 3Com Corporation 3c980-TX 10/100baseTX NIC [Python-T] (#2) 1c80-1cff : 00:10.0 2010-201f : Promise Technology, Inc. 20268 2010-2017 : ide2 2018-201f : ide3 2020-202f : Promise Technology, Inc. 20268 (#2) 2020-202f : PDC20268 2030-2033 : PCI device 1022:700c (Advanced Micro Devices [AMD]) 2034-2037 : Promise Technology, Inc. 20268 2036-2036 : ide3 2038-203f : Promise Technology, Inc. 20268 2038-203f : ide3 2040-2043 : Promise Technology, Inc. 20268 2042-2042 : ide2 2044-2047 : Promise Technology, Inc. 20268 (#2) 2046-2046 : ide5 2048-204f : Promise Technology, Inc. 20268 2048-204f : ide2 2050-2057 : Promise Technology, Inc. 20268 (#2) 2050-2057 : ide5 2058-205b : Promise Technology, Inc. 20268 (#2) 205a-205a : ide4 2060-2067 : Promise Technology, Inc. 20268 (#2) 2060-2067 : ide4 80e0-80ef : amd756-smbus f000-f00f : Advanced Micro Devices [AMD] AMD-765 [Viper] IDE f000-f007 : ide0 f008-f00f : ide1 Andre, could you please have a look in this issue again. Lots of people are whining because the "multiple promise with poor performance" problem. While reading the cover article from Eric Raymond in Nov. Issue of LJ, I had to admit in the IDE/SCSI question. I would love to prove him wrong, aka. that it's possible/feasable to build real IDE based screamers without messing to much ;-) But surely it will take years to reach the standards of scsi based solutions (disconnect/badblocks). The only positive message in this respect, is that 3ware seems back to IDE controller business. But nobody knows, if/when they change their minds again? Cheers, Hans-Peter
