... again, that's why I'm suggesting they post some further details,
such as the disassembly in question.
The contents of /etc/src.cnof and /etc/make.conf would be useful too,
as well as a verbose dmesg just to make sure devices and CPU flags are
all there.
Who knows, it could be some corner case
on 04/02/2013 23:06 Adrian Chadd said the following:
> I'm not the right person for it, but I think it's worth wrapping up
> all my requested details in a PR so Those Who Know can take a peek.
>
> Especially if it boils down to the choice of compiler. Who knows what
> other weird corner issues peo
I'm not the right person for it, but I think it's worth wrapping up
all my requested details in a PR so Those Who Know can take a peek.
Especially if it boils down to the choice of compiler. Who knows what
other weird corner issues people will see with clang compiling their
drivers?
Adrian
_
on 04/02/2013 21:11 Adrian Chadd said the following:
> On 30 January 2013 13:03, Andriy Gapon wrote:
>> on 28/01/2013 16:30 Andriy Gapon said the following:
>>> is there any reasonable explanation for getting an NMI while trying to read
>>> acpi
>>> timer r
On 30 January 2013 13:03, Andriy Gapon wrote:
> on 28/01/2013 16:30 Andriy Gapon said the following:
>> is there any reasonable explanation for getting an NMI while trying to read
>> acpi
>> timer register?
>> Note: this happens only after ACPI suspend/resume.
>
&g
on 28/01/2013 16:30 Andriy Gapon said the following:
> is there any reasonable explanation for getting an NMI while trying to read
> acpi
> timer register?
> Note: this happens only after ACPI suspend/resume.
An update.
This happens only with clang compiled kernel, gcc compiled
Guys,
is there any reasonable explanation for getting an NMI while trying to read acpi
timer register?
Note: this happens only after ACPI suspend/resume.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman
7 matches
Mail list logo