On Fri, Mar 01, 2002 at 07:44:25AM +0000, Gerd Knorr wrote: > > Invalid operand 0000 > > =2E.. > > Call Trace [ hexadecimal stack trace which I know is meaningless here ] > > It isn't meaningless, it is the only way to debug that problem. Indeed. I worded it incorrectly. What I meant was that the stack trace in hexadecimal number form was meaningless to display here, with nobody having my kernel and modules loaded on their system and all. > See > Documentation/oops-tracing.txt (and Documentation/serial-console.txt > maybe ...). ~sigh~ Yeah, a serial console is what I was thinking about for getting the Ooops data. I don't have that kind (an RS-232 Xover) of cable here right now though. Can Documentation/oops-tracing.txt really be applied though? It gives instruction when klogd is available to symbolize the addresses, or when ksymoops can be run right after the Ooops. Because I dynamically load modules, is it not likely that if any modules are in the trace, by the time I reboot and can ksymoops the crash data (captured on the serial console for instance) the address pointers will have changed due to the dynamic module loading? > > <6>btaudio : buffer overrun > > > I do nothing with btaudio. > > This simply can't happen if you don't use btaudio. Sorry, again bad wording on my part. I meant that I use the btaudio.o driver that comes with my kernel distribution. I don't "supplant" it with a newer/different version as I do with v4l2 and bttv. I definately do use btaudio when capturing/encoding. b. -- Brian J. Murrell
Attachment:
pgpKX7ewl7l4U.pgp
Description: PGP signature
