dmesg diff, followed by full dmesg with 2nd patch applied. No panic,
at least in the time it took to grab the dmesg and reboot.
Devin
1c1
< OpenBSD 5.9-beta (GENERIC.MP) #10: Fri Jan 8 09:00:37 MST 2016
---
OpenBSD 5.9-beta (GENERIC.MP) #11: Fri Jan 8 10:37:00 MST 2016
18c18
< cpu0: Intel(R
Firstly diff, secondly all dmesg from unmodified and modified with yours patch
kernel.
OpenBSD-current amd64 with source code updated using
cvs -d$CVSROOT up -D "2016-01-07 05:00" -Pd
diff -u /katalogDmesg/nieZmodyfikowaneAcpiMark/dmesg.log
/katalogDmesg/zmodyfikowaneAcpiMark/dmesg.log
--- /
On Thu, Jan 07, 2016 at 06:28 +0100, Pablo Méndez Hernández wrote:
> Hi team,
>
> On Thu, Dec 31, 2015 at 10:05 PM, Philip Guenther wrote:
> > On Wed, 30 Dec 2015, Mark Kettenis wrote:
> > ...
> >> Updated diff. Once again the ACPI standard is ambiguous and/or violated
> >> by the hardware vendo
Hi team,
On Thu, Dec 31, 2015 at 10:05 PM, Philip Guenther wrote:
> On Wed, 30 Dec 2015, Mark Kettenis wrote:
> ...
>> Updated diff. Once again the ACPI standard is ambiguous and/or violated
>> by the hardware vendors. This should fix at least the ports Dell r620
>> that naddy@ told me about.
>
On Wed, 30 Dec 2015, Mark Kettenis wrote:
...
> Updated diff. Once again the ACPI standard is ambiguous and/or violated
> by the hardware vendors. This should fix at least the ports Dell r620
> that naddy@ told me about.
Here's the diff of dmesgs with-vs-without this diff on my yoga12:
@@ -41
> Date: Wed, 30 Dec 2015 14:21:11 +0100 (CET)
> From: Mark Kettenis
>
> It seems more and more server machines ship in a "64-bit"
> configuration where the BIOS assigns addresses above the 4GB mark to
> 64-bit BARs. We have a hack in arch/amd64/pci_machdep.c:pci_init_extents()
> to deal with som
It seems more and more server machines ship in a "64-bit"
configuration where the BIOS assigns addresses above the 4GB mark to
64-bit BARs. We have a hack in arch/amd64/pci_machdep.c:pci_init_extents()
to deal with some of these configurations:
/*
* ...