Date: Sat, 24 Jan 1998 15:26:55 +0100 (MET) From: Ugo Paternostro <paterno@dsi.UNIFI.IT> To: Nate Williams <nate@mt.sri.com> Cc: freebsd-mobile@FreeBSD.ORG Subject: Re: Cirrus Logic PD6729 Message-ID: <XFMail.980124152655.paterno@dsi.UNIFI.IT> In-Reply-To: <199801230503.WAA19888@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23-Jan-98 Nate Williams wrote about "Re: Cirrus Logic PD6729":
> The error would probably occur even if you didn't compile DDB. Also,
No, this behavior first showed up when I added "options DDB" in the kernel
config.
> did config blow away everything so that the compile was done from
> scratch?
It said so... shouldn't I trust it? :)
>> debugger. Almost any command (but help) prints something like "Panic... blah
>> blah blah". I tried a trace, but it gives no useful information. What should
>
> *grin* Read the handbook on kernel debugging, that should be a big help
> and can give you more information than I can provide in email.
Well, if I enter the debugger by pressing CTRL-ALT-ESC and then I give a
"Trace" command, I can see the stack trace (it starts form _Debugger(...) and
so on), but if I wait the panic and ask for a trace, I simply see something
like this (I marked with "==>" my commands) (WARNING: hand copied from the
console, may contain errors):
----------------------------------------------------------------------------
[...some information is missing due to the limited screen length...]
fault code = supervisor read, page not present
instruction pointer = 0x8:0x10
stack pointer = 0x10:0xf01ebef4
frame pointer = 0x10:0xf01ebf44
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask =
kernel: type 12 trap, code=0
Stopped at 0x10:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x10
fault code = supervisor read, page not present
instruction pointer = 0x8:0xf01b7808
stack pointer = 0x10:0xf01ebd68
frame pointer = 0x10:0xf01ebd6c
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask =
kernel: type 12 trap, code=0
==> db> trace
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x10
fault code = supervisor read, page not present
instruction pointer = 0x8:0xf01b7808
stack pointer = 0x10:0xf01ebca4
frame pointer = 0x10:0xf01ebca8
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask =
kernel: type 12 trap, code=0
==> db> show reg
[...some information is missing due to the limited screen length...]
eax 0xc0000400
ecx 0xf261bf14
edx 0x3e0
ebx 0xf01fef00 _r_hook+0xd4
esp 0xf01ebef4 _etext+0x2654
ebp 0xf01ebf44 _etext+0x26a4
esi 0xf018f140 _inserted
edi 0xc0000000
eip 0x10
efl 0x10286
0x10:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x10
fault code = supervisor read, page not present
instruction pointer = 0x8:0xf01b7808
stack pointer = 0x10:0xf01ebc90
frame pointer = 0x10:0xf01ebc90
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask =
kernel: type 12 trap, code=0
==> db> panic
panic: from debugger
Debugger("panic")
Stopped at 0x10:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x10
fault code = supervisor read, page not present
instruction pointer = 0x8:0xf01b7808
stack pointer = 0x10:0xf01ebd68
frame pointer = 0x10:0xf01ebd6c
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask =
kernel: type 12 trap, code=0
==> db> panic
panic: from debugger
dumping to dev 30001, offset 0
dump device bad
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
----------------------------------------------------------------------------
without any stack trace: it seems that the debugger itself is panicing, right
after accessing location 0x10. Please note that the IP points to that location.
Reading the edx value, I could guess it just did or it is going to do and I/O
to that port, and, from the reference to r_hook, I could guess it is something
related to APM (this would also explain why somethimes the machine goes in
sleep mode when I remove the PCMCIA card). BTW, insert() is the function where
it should print "Card inserted, slot 0" (that it never prints on the second
boot).
Unfortunately, I do not know the code enough to use this little information.
Could you please help me?
>> Should I force the pccard driver to use irq 9 for the chip?
>
> You can't force the pccard driver to use irq 9 unfortunately. That's
> one of the (known) problems with the current setup. :(
What about modifying pccard/pcic.c and initializing the pcic_irq variable to
(say) 9 ? I know this is not "The Solution For Everybody", but I wanted to try,
and it seemed to work, but crashed when it loaded the OSS driver... sigh
It crashed also when I reconfigured OSS to use irq 5...
>> P.S.: I have a problem with the anti-spam behavior of sendmail at
>
> Send email to freefall the same way you send email to me. :)
Nope: I now masquerade :)
> Nate
Bye, UP
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980124152655.paterno>