Date: Wed, 11 Aug 2004 15:01:23 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-current@FreeBSD.org Cc: Nate Lawson <nate@root.org> Subject: Re: cvs commit: src/sys/dev/acpica acpi_pci_link.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c acpi_pcibvar.h Message-ID: <200408111501.23593.jhb@FreeBSD.org> In-Reply-To: <411A5A12.2070404@root.org> References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAAThZ4MpwZjU%2BKndAha//XewEAAAAA@telia.com> <411A5A12.2070404@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 11 August 2004 01:40 pm, Nate Lawson wrote: > Daniel Eriksson wrote: > > Nate Lawson wrote: > >> Modified files: > >> sys/dev/acpica acpi_pci_link.c acpi_pcib.c > >> acpi_pcib_acpi.c acpi_pcib_pci.c > >> acpi_pcibvar.h > >> Log: > >> Re-work ACPI PCI IRQ routing (_PRT, link devices). The old > >>approach was > >> incomplete in that the PRT routing was not aware of link > >>programming. > >> Fix this by doing all routing through the link devices. > > > > This(?) breaks interrupt routing pretty badly on ASUS A7V600-X (VIA > > KT-600 chipset). > > > > A kernel/userland from 2004.08.09.13.00.00 works just fine (sorry, no > > dmesg available right now), but a kernel/userland from > > 2004.08.11.15.00.00 breaks routing of interrupts to (at least) two > > HighPoint RocketRAID 454 cards. > > > > Below is part of the dmesg from a boot with ACPI on. Does it matter that > > "PnP OS installed" is turned off in the BIOS? I will run some more tests > > later tonight and report the results here. This is just a FYI that > > something might be broken... > > That may affect it. Let me know. > > > atapci0: <HighPoint HPT374 (channel 0+1) UDMA133 controller> port > > 0xb400-0xb4ff,0xb800-0xb803,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 irq > > 11 atapci1: <HighPoint HPT374 (channel 2+3) UDMA133 controller> port > > 0x9800-0x98ff,0xa000-0xa003,0xa400-0xa407,0xa800-0xa803,0xb000-0xb007 irq > > 11 ahc0: <Adaptec 29160 Ultra160 SCSI adapter> port 0x9400-0x94ff mem > > 0xed800000-0xed800fff irq 3 at device 12.0 on pci0 > > atapci2: <HighPoint HPT374 (channel 0+1) UDMA133 controller> port > > 0x7800-0x78ff,0x8000-0x8003,0x8400-0x8407,0x8800-0x8803,0x9000-0x9007 irq > > 10 atapci3: <HighPoint HPT374 (channel 2+3) UDMA133 controller> port > > 0x6000-0x60ff,0x6400-0x6403,0x6800-0x6807,0x7000-0x7003,0x7400-0x7407 irq > > 10 at device 14.1 on pci0 > > atapci4: <VIA 6420 SATA150 controller> port > > 0x4000-0x40ff,0x4400-0x440f,0x4800-0x4803,0x5000-0x5007,0x5400-0x5403,0x5 > >800 -0x5807 irq 5 at device 15.0 on pci0 > > atapci5: <VIA 8237 UDMA133 controller> port > > 0x3800-0x380f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 14 at device 15.1 > > on pci0 > > ata0: at 0x1f0 irq 14 on atapci5 > > ata1: at 0x170 irq 15 on atapci5 > > I need the dmesg output from boot -v to see the link priority settings. He's using an I/O APIC. These are probably all entries that don't have a link device but just a hardwired global interrupt number. Did you test that case? -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408111501.23593.jhb>