From owner-freebsd-mobile Sat Jan 24 06:31:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA14109 for freebsd-mobile-outgoing; Sat, 24 Jan 1998 06:31:29 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from cesit1.unifi.it (cesit1.unifi.it [150.217.1.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA14102 for ; Sat, 24 Jan 1998 06:31:26 -0800 (PST) (envelope-from ugo@dsi.UNIFI.IT) Received: from aguirre.dsi.unifi.it by CESIT1.UNIFI.IT (PMDF V5.0-4 #3688) id <01ISRDDKS8PC000VWR@CESIT1.UNIFI.IT> for freebsd-mobile@FreeBSD.ORG; Sat, 24 Jan 1998 15:31:20 +0100 (MET) Received: from dsi.unifi.it (com9.unifi.it) by aguirre.dsi.unifi.it (4.1/SMI-4.1) id AA13563; Sat, 24 Jan 1998 15:36:14 +0100 Received: from pegasus.home.net (pegasus.home.net [192.168.1.3]) by dsi.unifi.it (8.8.8/8.8.8) with ESMTP id PAA28948; Sat, 24 Jan 1998 15:26:56 +0100 (MET envelope-from ugo) Received: (from ugo@localhost) by pegasus.home.net (8.8.8/8.8.7) id PAA00964; Sat, 24 Jan 1998 15:26:56 +0100 (MET) Date: Sat, 24 Jan 1998 15:26:55 +0100 (MET) From: Ugo Paternostro Subject: Re: Cirrus Logic PD6729 In-reply-to: <199801230503.WAA19888@mt.sri.com> To: Nate Williams Cc: freebsd-mobile@FreeBSD.ORG Message-id: Organization: Not an organization MIME-version: 1.0 X-Mailer: XFMail 1.2 [p0] on FreeBSD Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 8bit X-Priority: 3 (Normal) Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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