Date: Thu, 17 Jan 2008 15:00:27 -0500 From: John Baldwin <jhb@freebsd.org> To: Nate Lawson <nate@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI breaks network, old AMD K6, just FYI Message-ID: <200801171500.28027.jhb@freebsd.org> In-Reply-To: <478E855A.7000809@root.org> References: <op.t4zp2oinhalquq@windowspc> <200801161534.31030.jhb@freebsd.org> <478E855A.7000809@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 16 January 2008 05:29:46 pm Nate Lawson wrote: > 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'mp4/doc glad that we may have found a system that > needs this safety belt since I implemented it a while ago. It's actually frobbing the ELCR in the _DIS method for the links to mark the IRQ as edge triggered. What is odd is that we should actually be ok even if it does that because we program the ELCR ourselves. Hmm, I bet we only write to the ELCR if we think it is changing though. Yes, that's what you are running into. You could also fix it by editing elcr_write_trigger() in src/sys/i386/isa/elcr.c to remove the 'if (new_status == elcr_status) return;' statement. However, the tunable is actually better as the BIOS can't safely frob these bits in the ELCR. It probably breaks ACPI as ACPI needs IRQ 9 level triggered as well, and apparently the _SRS method isn't updating the ELCR either which it would need to do. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801171500.28027.jhb>