ichwd for ICH8

[John Baldwin]

On Friday 10 August 2007 07:05:30 am Dag-Erling Smørgrav wrote:
> Mike Tancsa <mike at sentex.net> writes:
> > At 11:55 AM 8/8/2007, Dag-Erling Smørgrav wrote:
> > > Mike Tancsa <mike at sentex.net> writes:
> > > > Dag-Erling Smørgrav <des at des.no> writes:
> > > > > I've tested the driver under -CURRENT on a couple more machines, 
with
> > > > > the same result everywhere: it probes and attaches and seems to work
> > > > > fine, but the box does not reboot.
> > > > kldload ichwd, watchdogd -t 20;killall -9 watchdogd and nada ?
> > >
> > > Precisely.
> > >
> > > > I can boot one of my working RELENG_6 boxes on current and test if you
> > > > think it is some version issue.
> > >
> > > That would be great!
> >
> > Very strange indeed.  My RELENG_6 box reboots just fine with your
> > version and the version from the PR.  However, the box fails to reboot
> > running with a CURRENT kernel on either version of the watchdog.
> >
> > On a chance, I tried a trick I used to have to do ages ago in order to
> > get the driver to work.  I added
> >
> > debug.acpi.disabled="sysresource"
> >
> > to /boot/loader.conf
> >
> > and then it worked on the CURRENT kernel.  i.e. kldload
> > /tmp/ichwd.ko,watchdogd -t 20;killall -9 
> > watchdogd.... ~20 sec later, the box reboots running a CURRENT.
> > Without that in loader.conf, the box does not reboot.
> >
> > I _dont_ have to add debug.acpi.disabled="sysresource" on RELENG_6 on
> > the same box for the ichwd to work as expected.
> >
> > dmesg.txt attached the for same machine-- running CURRENT, one from 
RELENG_6
> 
> Let's ask the ACPI folks if they know what's up...  To summarize, the
> ichwd driver (both the in-tree version and the new version available
> from http://people.freebsd.org/~des/software/) works fine in RELENG_6
> but fails silently (i.e. attaches and seems to work, but the machine
> does not reboot) in HEAD.
> 
> There is one thing I think might be related.  To quote my own comments
> from the code:
> 
>  * The WDT is programmed through I/O registers in the ACPI I/O space.
>  * Intel swears it's always at offset 0x60, so we use that.
> 
> But perhaps it isn't?  Or perhaps access to the TCO registers silently
> fails due to the ACPI sysresource code?  Perhaps the ichwd driver should
> access them through ACPI, instead of doing direct I/O?

Don't use ~0ul for the end address, but use the real one.  However, the 
resource management in this driver is all wrong.  What it should be doing, is 
to identify as a child of 'isab' and create a child device of 'isab'.  It 
should then allocate the appropriate BAR from the 'isab' device (the isab 
driver can "proxy" alloc_resource requests from direct children to its bars 
just like the vgapci(4) device) and use that single BAR resource for I/O.  
However, just fixing the end address to be appropriate should fix the driver 
for now.

-- 
John Baldwin