From owner-freebsd-stable@FreeBSD.ORG Wed Feb 9 08:53:38 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D62916A4CF for ; Wed, 9 Feb 2005 08:53:38 +0000 (GMT) Received: from f17.mail.ru (f17.mail.ru [194.67.57.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 910CA43D31 for ; Wed, 9 Feb 2005 08:53:37 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from mail by f17.mail.ru with local id 1CynbF-000KKI-00; Wed, 09 Feb 2005 11:53:29 +0300 Received: from [81.200.13.122] by win.mail.ru with HTTP; Wed, 09 Feb 2005 11:53:29 +0300 From: dima <_pppp@mail.ru> To: Doug White Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [81.200.13.122] Date: Wed, 09 Feb 2005 11:53:29 +0300 In-Reply-To: <20050208110819.G2666@carver.gumbysoft.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: freebsd-stable@freebsd.org Subject: Re[3]: interrupt routing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dima <_pppp@mail.ru> List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 08:53:38 -0000 >>>> I am preparing a new server for production use. >>>> It contains 2 1000BaseTX NICs and 2 SCSI controllers. >>>> The interrupt assignment performed by ACPI looks kinda strange: >>>> irq24: bge0 ahd0 >>>> irq25: bge1 ahd1 >>>> How can I affect it? I mean I want all the devices use different IRQ lines. >>> >>> What hardware, curiously? Are all of these parts onboard? Can you post >>> the ouptut of 'devconf'? This will show the bus associations for these >>> devices. >> Its Tyan S2882 and all the devices are onboard ones. >> I dont know about devconf ($ locate devconf produces empty output as well) > > Oops, soory, that should be 'devinfo'. But pciconf might tell me what I > want to know. > >> but pciconf results are as follows: >> ahd0@pci2:6:0: class=0x010000 card=0x005e9005 chip=0x801d9005 rev=0x10 hdr=0x00 >> vendor = 'Adaptec Inc' >> device = 'AIC-7902B Ultra320 SCSI Controller' >> class = mass storage >> subclass = SCSI >> ahd1@pci2:6:1: class=0x010000 card=0x005e9005 chip=0x801d9005 rev=0x10 hdr=0x00 >> vendor = 'Adaptec Inc' >> device = 'AIC-7902B Ultra320 SCSI Controller' >> class = mass storage >> subclass = SCSI >> bge0@pci2:9:0: class=0x020000 card=0x164414e4 chip=0x164814e4 rev=0x03 hdr=0x00 >> vendor = 'Broadcom Corporation' >> device = 'BCM5704 NetXtreme Dual Gigabit Adapter' >> class = network >> subclass = ethernet >> bge1@pci2:9:1: class=0x020000 card=0x164414e4 chip=0x164814e4 rev=0x03 hdr=0x00 >> vendor = 'Broadcom Corporation' >> device = 'BCM5704 NetXtreme Dual Gigabit Adapter' >> class = network >> subclass = ethernet > > Ah, so they are all on the same bus. Yuck, performance is going to be > sucky. Bad Tyan, no cookie. That'll also explain the limited number of > interrupts available. I don't think there's anything we can do to help > the situation, sadly. I cannot affect the company equipment purchase policy either :/ 2 more servers on Tyan motherboards perform pretty bad also. >> The server runs i386 version of FreeBSD (5.3-RELEASE-p5) since >> I experienced some problems building ports on amd64 version. > > You probably need to use the hw.physmem="2G" loader tunable to get 5.3-R > installed. Once installed you can upgrade to 5-STABLE which fixes the > problem. Well, I dont experience any problems with the base system (the server has 4G of physical RAM btw). The ports collection isnt amd64-ready though. I compiled some ports patching their makefiles but some of them dont compile at all. Say, I failed to build vnc server from ports (I needed it to install Oracle) the only one I managed to build was an ancient realvnc (3.3.7), but I couldnt connect to it. I tried to compile realvnc 4.x from sources but ran into namespace issues (they were discussed on another thread here regarding some software package; seems to be a buggy gcc). So, Ive given up and happily installed an i386 version. >>> In many cases there are not other IRQs available to route, due to poor >>> BIOS programming, ccorners cut in the physical board layout, etc. >> I think this is the case :/ > >> The BIOS assigned all those devices IRQ10 and there is no way to change >> the settings...