Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Jan 2011 15:00:45 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        Alexander Motin <mav@freebsd.org>
Cc:        acpi@freebsd.org, "Arno J. Klaassen" <arno@heho.snv.jussieu.fr>
Subject:   Re: Tyan S3992-E: hpet no longer working
Message-ID:  <201101101500.45783.jhb@freebsd.org>
In-Reply-To: <4D2894CA.5010004@FreeBSD.org>
References:  <wpk4ij3u9f.fsf@heho.snv.jussieu.fr> <wppqs7xsy3.fsf@heho.snv.jussieu.fr> <4D2894CA.5010004@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, January 08, 2011 11:46:02 am Alexander Motin wrote:
> Arno J. Klaassen wrote:
> > John Baldwin <jhb@freebsd.org> writes:
> > 
> >> On Thursday, January 06, 2011 5:32:08 pm Arno J. Klaassen wrote:
> >>> John Baldwin <jhb@freebsd.org> writes:
> >>>
> >>>> On Wednesday, January 05, 2011 4:39:24 pm Arno J. Klaassen wrote:
> >>>>> Hello,
> >>>>>
> >>>>> I have (a long-lasting) problem to get hpet attached to a Tyan S3992-E
> >>>>> MB. My last known working kernel is 7.1-PRERELEASE Sep 2 2008" , I
> >>>>> rarely cared about this board for a while...
> >>>>>
> >>>>> At that time the dmesg said :
> >>>>>
> >>>>>
> >>>>>   acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff
> >>>>>   on acpi0
> >>>>>   Timecounter "HPET" frequency 25000000 Hz quality 900
> >>>>>
> >>>>> now it says (debug.acpi.hpet_test="1", debug.acpi.layer="ACPI_TIMER",
> >>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" enabled) :
> >>>>>
> >>>>>   hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed03fff on
> >>>>>   acpi0
> >>>>>   hpet0: vendor 0xffff, rev 0xff, 232831Hz 64bit, 32 timers, legacy route
> >>>>>   hpet0:  t0: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t1: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t2: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t3: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t4: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t5: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t6: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t7: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t8: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t9: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t10: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t11: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t12: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t13: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t14: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t15: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t16: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t17: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t18: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t19: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t20: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t21: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t22: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t23: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t24: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t25: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t26: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t27: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t28: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t29: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t30: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0:  t31: irqs 0xffffffff (31), MSI, 64bit, periodic
> >>>>>   hpet0: 0.000000000: 4294967295 ... 4294967295 = 0
> >>>>>   hpet0: time per call: 0 ns
> >>>>>   hpet0: HPET never increments, disabling
> >>>>>   device_attach: hpet0 attach returned 6
> >>>>>
> >>>>>
> >>>>> Some things strike me :
> >>>>>
> >>>>>   'vendor 0xffff, rev 0xf' and '4294967295 (== 0xffffffff)' as well
> >>>>>     as 232831Hz
> >>>>>
> >>>>>   the change in iomem range :
> >>>>>
> >>>>>       OK : iomem 0xfed00000-0xfed003ff
> >>>>>       KO : iomem 0xfed00000-0xfed03fff
> >>>>>                                   ^^^^
> >>>>>
> >>>>> I can provide full dmesg and/or other extra needed info.
> >>>> Arno sent me his acpidump which includes this:
> >>>>
> >>>>                 Device (HPET)
> >>>>                 {
> >>>>                     Name (_HID, EisaId ("PNP0103"))
> >>>>                     Name (_UID, 0x34)
> >>>>                     Method (_STA, 0, NotSerialized)
> >>>>                     {
> >>>>                         Return (0x0F)
> >>>>                     }
> >>>>
> >>>>                     Method (_CRS, 0, NotSerialized)
> >>>>                     {
> >>>>                         Return (ResourceTemplate ()
> >>>>                         {
> >>>>                             Memory32Fixed (ReadWrite,
> >>>>                                 0xFED00000,         // Address Base
> >>>>                                 0x00004000,         // Address Length
> >>>>                                 )
> >>>>                         })
> >>>>                     }
> >>>>                 }
> >>>>
> >>>> So it does look like we are doing what the DSDT tells us in terms
> >>>> of the memory address.
> >>> yop. That said, I made yet another copy-paste error: the last known
> >>> working kernel is 8.0-CURRENT Mar  1 2009 and the hpet says :
> >>>
> >>>   acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff
> >>>   on acpi0
> >>>   Timecounter "HPET" frequency 14318180 Hz quality 900 
> >>>
> >>> [only the frequency differs, the memory range indeed then was reported as
> >>> 0x400 and not 0x4000 ]
> >>>
> >>>> Arno, are there any BIOS options that mention the HPET or have you updated 
> >>>> your BIOS since you booted the 7.1 kernel?
> >>> yes .. I now use BIOS 1.06 released 06/09/09.
> >>> Can I somehow 'overide' the bios and force the driver to use 0X400 as
> >>> 'Address Length' in order to test if that makes the driver attach again?
> >> Changing the length wouldn't make a difference as we would still read the same 
> >> registers since the start address is identical.  I think the length is 
> >> symptomatic of the BIOS doing something differently that has disabled the 
> >> HPET.
> > 
> > good point : this failure probably is not related to the FreeBSD-driver
> > : in the current BIOS under the submenu 'South Bridge Chipset
> > Configuration', the option to enable the HPET has disappeared (no
> > mention of that in the release-notes), whilst it was present in the
> > original BIOS, *and* disabled by default.
> > 
> > Is it possible to write to some register during hpet_enable() and force
> > the timer to tick, regardless of the BIOS?
> 
> Problem seems not about ticking, but about HPET registers working at
> all. Returning ffh values for everything more probably tells that HPET
> is just not in place where we look for it.

Or that the BIOS has disabled it.  Maybe it is buggy on this motherboard and
newer BIOS revisions always disable it as a result?

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201101101500.45783.jhb>