From j@uriah.heep.sax.de  Sun Sep  7 09:21:29 1997
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA26995
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 7 Sep 1997 09:21:28 -0700 (PDT)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA20609 for FreeBSD-gnats-submit@freebsd.org; Sun, 7 Sep 1997 18:21:27 +0200
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.7/8.8.5) id SAA19531;
	Sun, 7 Sep 1997 18:04:17 +0200 (MET DST)
Message-Id: <199709071604.SAA19531@uriah.heep.sax.de>
Date: Sun, 7 Sep 1997 18:04:17 +0200 (MET DST)
From: J Wunsch <j@uriah.heep.sax.de>
Reply-To: j@uriah.heep.sax.de
To: FreeBSD-gnats-submit@freebsd.org
Subject: ahc(4) in RELENG_2_2 can't do kernel core dumps
X-Send-Pr-Version: 3.2

>Number:         4486
>Category:       kern
>Synopsis:       ahc(4) in RELENG_2_2 can't do kernel core dumps
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Sep  7 09:30:02 PDT 1997
>Closed-Date:    Wed Sep 10 14:31:52 MEST 1997
>Last-Modified:  Fri Sep 12 08:50:01 PDT 1997
>Originator:     J Wunsch
>Release:        FreeBSD 2.2-STABLE i386
>Organization:
interface business GmbH
>Environment:

Any RELENG_2_2 kernel with an ahc(4) driver, and kernel core dumping
enabled.  Observed for at least half a year now.

>Description:

When the kernel tries to dump core on the mentioned system, it starts
to say `dumping ...', but then jams.  The machine needs a hard reset
in order to be freed.

>How-To-Repeat:

Configure a RELENG_2_2 kernel with an ahc(4) driver for kernel core
dumping, and cause a panic.  Calling `panic' from DDB should suffice.

>Fix:
	
Unknown.  Suspecting some problem with interrupts enabled, but the
driver trying to poll the controller.
>Release-Note:
>Audit-Trail:

From: Tor Egge <Tor.Egge@idi.ntnu.no>
To: j@uriah.heep.sax.de
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/4486: ahc(4) in RELENG_2_2 can't do kernel core dumps
Date: Tue, 09 Sep 1997 18:50:44 +0200

 Some S3 cards does not like accesses to the monocrome 
 video memory address region (starting at memory address 0xb8000),
 and the memory dump hangs when dumping that region.
 
 With the following ugly hack/workaround, and defining SDDUMP_HANGS
 as an option in the kernel config file, the kernel will probably be
 able to perform a core dump.
 
 Index: sd.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/scsi/sd.c,v
 retrieving revision 1.95.2.3
 diff -c -r1.95.2.3 sd.c
 *** sd.c	1997/08/11 02:04:09	1.95.2.3
 --- sd.c	1997/08/27 16:57:47
 ***************
 *** 932,937 ****
 --- 932,944 ----
   
   	blknum = dumplo + blkoff;
   	while (num > 0) {
 + #if defined(SDDUMP_HANGS) && defined(__i386__)
 + 		if ((vm_offset_t) addr>=0xa0000 && 
 + 		    (vm_offset_t) addr < 0x100000)
 + 		  pmap_enter(kernel_pmap, (vm_offset_t)CADDR1, trunc_page(0),
 + 		  	  VM_PROT_READ, TRUE);
 + 		else
 + #endif
   		pmap_enter(kernel_pmap, (vm_offset_t)CADDR1, trunc_page(addr),
   			VM_PROT_READ, TRUE);
   		/*
 
State-Changed-From-To: open->closed 
State-Changed-By: joerg 
State-Changed-When: Wed Sep 10 14:31:52 MEST 1997 
State-Changed-Why:  

As suggested by Tor Egge <tegge@idi.ntnu.no>, the actual problem was 
that attempting to dump parts of the adapter memory region (most 
likely the video adapter memory in this case) caused the hang.  Tor's 
suggested workaround has been committed, in a slightly generalized 
form. 

From: Tor Egge <Tor.Egge@idi.ntnu.no>
To: j@uriah.heep.sax.de
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/4486: ahc(4) in RELENG_2_2 can't do kernel core dumps
Date: Fri, 12 Sep 1997 17:49:30 +0200

 I wrote:
 
 > Some S3 cards does not like accesses to the monocrome 
 > video memory address region (starting at memory address 0xb8000),
 > and the memory dump hangs when dumping that region.
 
 Correction:
 
 	0xb8000 is the start of the CGA/EGA/VGA/SVGA video memory. (text mode)
 	0xb0000 is the start of the MGA video memory.
 
 Thus, the memory dump hangs when trying to accessing video memory.
 
 - Tor Egge
>Unformatted:
