Pete Carah wrote:
> > Known problem... see the -current archives.

It *is* a known problem.

> > You are attaching twice: once because of ACPI, and again
> > because of the "hints".  You need to comment the entries
> > out of your hints file to make them not get attached twice.

It's just not this one, since ACPI fails differently.

> Actually not; You missed my comment that the DMESG was WITHOUT
> the ACPI module loaded; my real problem was a panic long before the serial
> probes.  These pnp messages may be entries in hints twice?

No.  They are PnP detected devices being detected twice.

Since you posted this message to -current, I just assumed you
had upgraded to the latest code, and thus were using ACPI (this
is the same thing that ended up confusing Mike Smith, who also
made the mistake in correcting me to say that ACPI was being
loaded twice on your system).

The general form of the problem is:

        1)      PnP BIOS tells FreeBSD about the devices
        2)      The device.hints tells FreeBSD about the

See the -current list archives for details; look for "Subject:"
of "Re: unknown PNP hardware".

> Apparently the AMD chipset is not served correctly by this ACPI code;
> I have this panic on one system and clock problems on another
> (Aladdin chipset; not that I love Acer) the clock runs almost exactly twice
> speed with the new ACPI; correctly without.)
> I saw a major acpi update come through this evening so I'm trying
> again...
> (that is, if strfmon and amd compile :-)

There is another known problem with ACER and ACPI timers,
which is most properly fixed, as Mike pointed out, by the
code checking to see if the timer is insane, and if it is,
discarding it and not using it and going the old route

A "quick hack", which was iscussed but not implemented at
the time I read the message about it, would be to disable
the ACPI timer (thinking about this, it should be possible
to implement at boot time via sysctl to select the timer
without the problem, but I have not tested this, and the
timecounter code is rather opaque, in that it templates
into hidden state containers which are not really globally
accessible [made zero system call time functions hard, but
not impossible, to write).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to