From owner-freebsd-current@FreeBSD.ORG Thu Sep 23 20:35:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C51D16A4CE for ; Thu, 23 Sep 2004 20:35:12 +0000 (GMT) Received: from smart.eusc.inter.net (smart.eusc.inter.net [213.73.101.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id D49BF43D53 for ; Thu, 23 Sep 2004 20:35:11 +0000 (GMT) (envelope-from msch@snafu.de) Received: from dial-76-134.de.inter.net ([213.73.76.134] helo=current.best-eng.de) by smart.eusc.inter.net with esmtp (Exim 3.36 #4) id 1CAaJ3-00021q-00 for current@freebsd.org; Thu, 23 Sep 2004 22:35:10 +0200 Received: from current.best-eng.de (localhost.best-eng.de [127.0.0.1]) by current.best-eng.de (8.13.1/8.13.1) with ESMTP id i8NKZ9m1001141 for ; Thu, 23 Sep 2004 22:35:09 +0200 (CEST) (envelope-from msch@snafu.de) Received: from localhost (localhost [[UNIX: localhost]]) by current.best-eng.de (8.13.1/8.13.1/Submit) id i8NKZ84E001140 for current@freebsd.org; Thu, 23 Sep 2004 22:35:08 +0200 (CEST) (envelope-from msch@snafu.de) X-Authentication-Warning: current.best-eng.de: matthias set sender to msch@snafu.de using -f From: Matthias Schuendehuette Organization: Micro$oft-free Zone To: current@freebsd.org Date: Thu, 23 Sep 2004 22:35:08 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409232235.08683.msch@snafu.de> X-Mailman-Approved-At: Fri, 24 Sep 2004 12:05:54 +0000 Subject: IRQ-Routing for 5.3-BETA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: msch@snafu.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2004 20:35:12 -0000 Hello, I have serious problems with the new IRQ-outing code since Aug 11, 16:00 UTC. For some reasons I don't understand, the new code uses IRQ10 instead of IRQ9 on my system, which breaks my internet connection thru my ISA ISDN-Card. The old code report the following IRQs for PCI-Devices: \_SB_.PCI0.LNKA irq 9: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.1.0 \_SB_.PCI0.LNKB irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.1.1 \_SB_.PCI0.LNKC irq 12: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.1.2 \_SB_.PCI0.LNKD irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.1.3 which leeds later on to: pcib0: matched entry for 0.1.INTA (src \_SB_.PCI0.LNKA) pcib0: slot 1 INTA is routed to irq 9 pcib1: slot 0 INTA is routed to irq 9 found-> vendor=0x10de, dev=0x0110, revid=0xa1 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=9 The new code instead reports: pcib0: matched entry for 0.1.INTA (src \_SB_.PCI0.LNKA) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \_SB_.PCI0.LNKA (references 8, priority 175018): interrupts: 10 5 11 7 6 4 3 12 15 14\ 1 penalty: 1280 1330 2720 6280 6280 6280 6280 6360 51280\ 51280101280 atpic: Programming IRQ10 as level/low pcib0: slot 1 INTA routed to irq 10 via \_SB_.PCI0.LNKA pcib1: slot 0 INTA is routed to irq 10 found-> vendor=0x10de, dev=0x0110, revid=0xa1 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=10 How come???!!! Why gets this PCI-bridge a different IRQ? IRQ10 is not available for PCI devices, it is marked as "Legacy ISA" in the BIOS setup and this was respected all the time. I tried "PnP-OS YES/NO" in the BIOS, but this didn't change anything. I don't believe that the BIOS is buggy because this board (EPoX 8KTA2) had worked with the FreeBSD ACPI code for some time now without any problems. Is there a way to tell the ACPI-Code *not* to use IRQxx via a 'hint.acpi.xxx'? Is there anything else I can do to avoid this new behaviour? -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F