ACPI breaks network, old AMD K6, just FYI

[John Baldwin]

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 at 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