Mark Kettenis <mark.kettenis <at> xs4all.nl> writes:
>
> > From: enuhtac <enuhtac_lists <at> gmx.de>
> > Date: Sun, 8 Feb 2015 11:17:47 +0000 (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 -0000 1.30
> +++ acpimadt.c 8 Feb 2015 23:38:47 -0000
> <at> <at> -359,7 +359,8 <at> <at> 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--;
>
>
Yes, this removes the kernel panic.
Thanks, Mark :-)
But unfortunately this does not affect the "ehci_sync_hc: tsleep() = 35"
error.
Strangely it seams that "35" means that the code has been compiled without
the macro "_KERNEL" being defined (in this case "tsleep" is a macro that
expands to "35"). I do not yet understand this but I will dig into it. Also
there's a lot to find on this error message on google. Maybe I will find a
fix. Only all posts I've read so far report this error only when using an
mp kernel. For me it occurs when using the sp kernel (the mp version still
leads to a total freeze).
