ichwd for ICH8
Dag-Erling Smørgrav
des at des.no
Fri Aug 10 12:35:11 PDT 2007
John Baldwin <jhb at freebsd.org> writes:
> 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.
So basically, the quick fix is this?
sc->tco_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->tco_rid,
pmbase + TCO_BASE, pmbase + TCO_BASE + TCO_LEN, TCO_LEN,
RF_ACTIVE | RF_SHAREABLE);
The man page isn't entirely clear on whether end is the last address in
the range or the first address beyond the range.
DES
--
Dag-Erling Smørgrav - des at des.no
More information about the freebsd-acpi
mailing list