Date: Wed, 16 Jan 2008 14:29:46 -0800 From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI breaks network, old AMD K6, just FYI Message-ID: <478E855A.7000809@root.org> In-Reply-To: <200801161534.31030.jhb@freebsd.org> References: <op.t4zp2oinhalquq@windowspc> <200801161056.01396.jhb@freebsd.org> <op.t409e2jchalquq@windowspc> <200801161534.31030.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Wednesday 16 January 2008 12:26:52 pm Michael Ross wrote: >> Am 16.01.2008, 16:54 Uhr, schrieb John Baldwin <jhb@freebsd.org>: >> >>>>> Is your network device getting interrupts (vmstat -i)? >>>>> >>>> No. >>> That's your problem then. :) Can you obtain a full dmesg from a verbose >>> boot >>> along with your asl and post them somewhere? >>> >> http://www.triplefork.net/montana-acpi/dmesg_acpi_enabled >> http://www.triplefork.net/montana-acpi/montana.asl >> http://www.triplefork.net/montana-acpi/sysctl_acpi_enabled >> >> http://www.triplefork.net/montana-acpi/dmesg_acpi_disabled > > Try setting 'debug.acpi.block_bad_io=1' from the loader. John is referring to this section of dmesg: > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 1 3 4 5 6 7 10 11 12 14 15 > Validation 0 11 N 0 1 3 4 5 6 7 10 11 12 14 15 > acpi: bad read from port 0x4d1 (8) > acpi: bad write to port 0x4d1 (8), val 0x2 > After Disable 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 9 N 0 1 3 4 5 6 7 10 11 12 14 15 > Validation 0 9 N 0 1 3 4 5 6 7 10 11 12 14 15 > acpi: bad read from port 0x4d1 (8) > acpi: bad write to port 0x4d1 (8), val 0 > After Disable 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > Validation 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > After Disable 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > Validation 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > After Disable 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 Basically, your AML is poking some PIRQ port directly (a no-no) and making the IRQ invalid. I'm glad that we may have found a system that needs this safety belt since I implemented it a while ago. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?478E855A.7000809>