Date: Thu, 06 Sep 2001 23:23:57 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Pete Carah <pete@ns.altadena.net> Cc: current@freebsd.org Subject: Re: ACPI problems Message-ID: <3B9867FD.E3E764FA@mindspring.com> References: <200109070448.f874mkX21174@ns.altadena.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 devices 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 instead. 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B9867FD.E3E764FA>