LOR in Jan16 -CUR, ACPI related possibly
Ketrien I. Saihr-Kenchedra
ketrien at error404.nls.net
Sun Jan 16 02:06:57 PST 2005
Apologies for the lack of debug, but the workspace around here is really
a disaster area, and console's acting up. I tried to get a dump, no go
even w/call doadump. kgdb's not working again either, go figure. (I have
related work that gave occasion to find this LOR.)
Sorry for the seeming lack of detail; I really have no way to accurately
transcribe this at the moment. It is 100% reproducible at least, but does
not panic() the system. It's as simple as kldload if_pcn,
kldunload if_pcn, LOR.
1st pcn (Network driver) sys/pci/if_pcn.c:1385
2nd ACPI root bus sys/dev/acpica/acpi.c:1050
Now, on a similar note, I'm currently working on the pcn(4) driver, and
encountered a not-dissimilar LOR versus ACPI again, this on load. I was
able to debug that one somewhat, but not scribble much down. This LOR
does panic() the system.
1st pcn 2nd ACPI root bus
My code uses mdodd@'s changes to probe(), which, contrary to wording,
does still lock out of necessity, but has not exhibited LOR before. The
flow is unchaged up to the LOR occurance, which appears to occur at
ether_ifattach(). I'm still rooting around to see if it _is_ occuring
earlier, but it doesn't look like it. This one, I can't reproduce so
well, due to a panic in uma that keeps popping up.
Afraid I'm a little stuck on this one; I'm still trying to get gdb
working without success. Any chance someone could take a look at this?
Thanks, as usual.
-Ketrien I. Saihr-Kenchedra
<Scythe> caps lock is not your friend.
<Scythe> In fact, it is your mortal enemy and it made very
disparaging remarks about your mother.
More information about the freebsd-current