port-i386/43284: gpio panic

[prlw1%cam.ac.uk@localhost]

>Number:         43284
>Category:       port-i386
>Synopsis:       gpio enabled kernels don't boot
>Confidential:   no
>Severity:       critical
>Priority:       low
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 10 15:35:00 +0000 2010
>Originator:     Patrick Welche
>Release:        NetBSD/i386
>Organization:
        
>Environment:
i386 kernel compiled with
gpio*   at ichlpcib?
or gpiosim
and not DIAGNOSTIC

systems with the following ichlpcib:
Intel 82801FBM ICH6M LPC Interface Bridge (rev. 0x03)
Intel 82801DB LPC Interface Bridge (rev. 0x02)

(though same happens with gpiosim and no ichlpcib, so probably
irrelevant)
>Description:
When booting an i386 kernel with gpio but not DIAGNOSTIC, booting stops with:

gpio0 at ichlpcib0: 64 pins
uvm_fault(0xc08165c0, 0, 1) -> 0xe

All OK if you enable DIAGNOSTIC, or disable gpio.

The commit which makes the difference between panic and no panic is:

sys/kern/subr_autoconf.c, sys/sys/device.h
revision 1.201
date: 2010/02/15 20:20:34;  author: dyoung;  state: Exp;  lines: +12 -7
Extract a subroutine, const char *cfdata_ifattr(cfdata_t cf), that
returns the name of the interface attribute that associates cf with
its parent.  Use cfdata_ifattr() at several sites in the autoconf
code.

(kernel from 2010.02.15.00.00.00 boots, but 2010.02.15.21.00.00 doesn't,
the other files changed are in arm, sparc64 and irix so irrelevant to i386)

But, I just took today's kernel source (5.99.29), and manually reverted
the above commit, and the kernel doesn't boot. disabling gpio allows it to
boot.

>How-To-Repeat:
Build an i386 kernel with gpio and no DIAGNOSTIC from code after 15 Feb 2010.
(Then boot -c the same kernel, and "disable gpio" - it will work.)
>Fix:
Unknown: it looks as though this is some sort of timing bug. All
the code in the "offending" commit above does is add the time it
takes to make a function call - depending on the whim of the
compiler, that may not even be true.  Adding DIAGNOSTIC adds printfs,
so also changes timings. So after all this, I'm still not sure of
the root cause of the panic.