From owner-freebsd-current Sat Jun 26 8:41:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from smtp2.mindspring.com (smtp2.mindspring.com [207.69.200.32]) by hub.freebsd.org (Postfix) with ESMTP id 6245D14BE6 for ; Sat, 26 Jun 1999 08:41:27 -0700 (PDT) (envelope-from brdean@mindspring.com) Received: from vger.foo.com (user-2ivf0b9.dialup.mindspring.com [165.247.129.105]) by smtp2.mindspring.com (8.8.5/8.8.5) with ESMTP id LAA11851 for ; Sat, 26 Jun 1999 11:41:24 -0400 (EDT) Received: (from bsd@localhost) by vger.foo.com (8.9.3/8.9.3) id LAA16019; Sat, 26 Jun 1999 11:41:27 -0400 (EDT) (envelope-from bsd) From: Brian Dean Message-Id: <199906261541.LAA16019@vger.foo.com> Subject: kernel panic w/regard to setting io permissions bitmap To: freebsd-current@freebsd.org Date: Sat, 26 Jun 1999 11:41:26 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm chasing down a panic that occurs when you call 'i386_set_ioperm()' in -current (19990625-SNAP). This call worked correctly in the 19990426-SNAP. I first noticed the problem with the 6/10 snap and it's still with us as of the 6/25 snap. The panic occurs at 'swtch_com+0x6e: ltr %si'. At the time, %si is 0x20, which indexes to what appears to be a busy tss (type=01011b) with a limit of 0x67. That instruction generates a general protection fault with an error code of 0. The current process was Idle. After piecing together the base address from the descriptor (which should point to the tss), and examining its contents, it seems as though the tss is not valid, i.e., it is composed of all zeros except for esp0 and ss0 (which appear to have reasonable values) and for the io map base address, which is 0x0068 which would seem to indicate that this tss does not have an io permission bitmap. If this is correct and I didn't mess something up when piecing all this together by hand, that would explain the GP(0) fault because the segment registers were zero, which would point them to an invalid GDT entry. Perhaps someone could reproduce this and double check me? Also ... I think I could analyze this better if I could break into the debugger and set a break point *before* the panic, and start tracing at the i386_set_ioperm() routine and follow what happens from there. Is there a function call that I can insert at the appropriate place to force dropping into the kernel debugger? I can't remote debug from my second machine right now because they are running kernels that are a few months apart, and I can't upgrade my other system at the moment. Could someone point me in the right direction in this regard (dropping to the debugger before the panic)? Thanks, -Brian -- Brian Dean brdean@mindspring.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message