On Sun, 7 Jul 2013 03:26:24 -0700, Jeremy Chadwick wrote:
> On Sun, Jul 07, 2013 at 03:51:12PM +1000, Ian Smith wrote:
> > On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote:
> > > On 30 June 2013 07:22, Ian Smith <smi...@nimnet.asn.au> wrote:
> > [..]
> > > > Nothing of note that I can see, if that usb hub-to-bus remapping is
> > > > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus.
> > > > Maybe someone who knows might comment on that?
> > Does noone know what that signifies? Maybe it's not relevant to this.
> It's too vague to know. The error comes from lapic_handle_error(),
> which is a generic/small routine which pulls the local APIC error status
> register. (Note I'm saying APIC, not ACPI -- two different things)
Indeed; I've been familiar with PICs since c.'79. Googling to check
what the 'A' stood for I found this .. from '97 but usefully descriptive
I also found this from March 2011 involving Mike Tancsa, you and jhb@ :)
> apic_vector.S sets this up/makes use of this function, and its done as
> an interrupt handler.
Whether an (unserviced?) interrupt error is related to Adrian's symptom
- apparent total failure of USB reinitialisation on resume, but only if
no USB devices exist in the external slots - remains to be seen. hps@
has just confirmed that it should work the same as on boot, but then
this error was flagged on boot - perhaps it also manifests on resume?
> I think this is one of those situations where you have to know *what* is
> being set up/done at that moment in time for the error code to mean
> something. Maybe booting verbose would give more information as to what
> was being done that lead up to the line.
> I've CC'd John Baldwin who might have some ideas.
Thanks. We have verbose dmesg already. Thread starts (in -stable) at
and amidst some wild goose chases, pointer to verbose dmesg etc is at
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"