Re: /upgrade: //install.sub[168]: sleep: Cannot allocate memory
On 2015/02/08 14:14, pe...@bsdly.net wrote: Synopsis:Cannot allocate memory message during upgrade (2015-02-07 snapshot amd64) Thanks for the report, this is known and being investigated.
Re: panic: lapic_set_lvt at boot
I took the ACPI specs and the kernel sources and tried to figure out what's going on. Obviously the Local APIC NMI Structure (aka ACPI_MADT_LAPIC_NMI) entries in the ACPI MADT table contain garbage in the flags field. Also the content of the lint field seems rather strange to me - although I do not know its meaning. This is also the reason for the kernel panic: the kernel sees '171' in this field but expects '0' or '1'. Are there any means to fix this? E.g. can I assume save default values for the flags and lint fields? enuhtac The first sign during the boot process of garbage in the ACPI_MADT_LAPIC_NMI structures mentioned by me earlier are these lines: acpimadt0: bogus nmi for apid 0 acpimadt0: bogus nmi for apid 2 Here the kernel detects wrong values in the flags fields and removes the corresponding ACPI_MADT_LAPIC_NMI entries. A third entry (for apid 1) goes through unnoticed because by chance the flag values are spec conform. Nevertheless the lint entry is bogus which causes the kernel panic later on. The ehci_sync_hc: tsleep() = 35 is probably also a follow up error of the faulty LAPIC setup because the USB driver is waiting for some interrupt to occur which never happens. Still I do not know what to do to fix this issue.
Re: /upgrade: //install.sub[168]: sleep: Cannot allocate memory
On Sun, 8 Feb 2015, pe...@bsdly.net wrote: Synopsis:Cannot allocate memory message during upgrade (2015-02-07 snapshot amd64) ... Description: During upgrade to amd snapshot dated 2015-02-07, the installer pauses for a long time (2 minutes) after the Force checking of clean non-root filesystems prompt (I answered no)i, then displays the message /upgrade: //install.sub[168]: sleep: Cannot allocate memory. Next long pause (approx 30 sec) happens during fetch of the xshare57.tgz set, with identical message displayed. The upgrade does however complete. Thank you for the report. We hit this too and, after some WTH moments, have figured out which change (the increase in size of the stack gap) caused the issue and have backed it out until the underlying dependency (how stack space is accounted) can be fixed. Philip
Re: panic: lapic_set_lvt at boot
From: enuhtac enuhtac_li...@gmx.de
Date: Sun, 8 Feb 2015 11:17:47 + (UTC)
The first sign during the boot process of garbage in the
ACPI_MADT_LAPIC_NMI
structures mentioned by me earlier are these lines:
acpimadt0: bogus nmi for apid 0
acpimadt0: bogus nmi for apid 2
Here the kernel detects wrong values in the flags fields and removes the
corresponding ACPI_MADT_LAPIC_NMI entries. A third entry (for apid 1) goes
through unnoticed because by chance the flag values are spec conform.
Nevertheless the lint entry is bogus which causes the kernel panic later
on.
The ehci_sync_hc: tsleep() = 35 is probably also a follow up error
of the faulty LAPIC setup because the USB driver is waiting for some
interrupt to occur which never happens.
Still I do not know what to do to fix this issue.
Only pin 0 and 1 make sense, so here is a diff that checks for those
values and declares the entry bogus if the pin value is anything else.
Does this fix your problem?
Index: acpimadt.c
===
RCS file: /home/cvs/src/sys/dev/acpi/acpimadt.c,v
retrieving revision 1.30
diff -u -p -r1.30 acpimadt.c
--- acpimadt.c 9 Dec 2014 06:58:29 - 1.30
+++ acpimadt.c 8 Feb 2015 23:38:47 -
@@ -359,7 +359,8 @@ acpimadt_attach(struct device *parent, s
map-ioapic_pin = pin;
map-flags = entry-madt_lapic_nmi.flags;
- if (!acpimadt_cfg_intr(entry-madt_lapic_nmi.flags,
map-redir)) {
+ if ((pin != 0 pin != 1) ||
+ !acpimadt_cfg_intr(entry-madt_lapic_nmi.flags,
map-redir)) {
printf(%s: bogus nmi for apid %d\n,
self-dv_xname, map-cpu_id);
mp_nintrs--;
