From natedac@daconcepts.dyndns.org  Tue Mar 20 20:30:37 2001
Return-Path: <natedac@daconcepts.dyndns.org>
Received: from daconcepts.dyndns.org (wks-166-129-114.kscable.com [24.166.129.114])
	by hub.freebsd.org (Postfix) with ESMTP id 11F2737B72D
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 20 Mar 2001 20:30:37 -0800 (PST)
	(envelope-from natedac@daconcepts.dyndns.org)
Received: (from natedac@localhost)
	by daconcepts.dyndns.org (8.11.3/8.11.3) id f2L4PaF00923;
	Tue, 20 Mar 2001 22:25:36 -0600 (CST)
	(envelope-from natedac)
Message-Id: <200103210425.f2L4PaF00923@daconcepts.dyndns.org>
Date: Tue, 20 Mar 2001 22:25:36 -0600 (CST)
From: natedac@kscable.com
Reply-To: natedac@kscable.com
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: XFreee86 4.0.x panics kernel -- UPDATE
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         25958
>Category:       i386
>Synopsis:       Xfree86's savage and vesa drivers can panic the kernel!
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    msmith
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 20 20:40:01 PST 2001
>Closed-Date:    Mon Apr 29 01:28:12 PDT 2002
>Last-Modified:  Mon Apr 29 01:28:12 PDT 2002
>Originator:     Nate Dannenberg
>Release:        FreeBSD 4.3-BETA i386
>Organization:
n/a
>Environment:

System: FreeBSD piccolo 4.3-BETA FreeBSD 4.3-BETA #1: Fri Mar 16 16:32:20 CST 2001 natedac@piccolo.daconcepts.dyndns.org:/usr/src/sys/compile/PICCOLO i386

IBM Aptiva - 550 MHz Athlon, 96M ram, Number Nine SR9 video (Savage4 
chipset, 8M) on the AGP port (never thought to mention this), ESS Solo1 
sound.

>Description:

Using the X 4.0.2 "savage" and "vesa" video drivers causes a kernel panic.  
Using the "vga" driver, however ugly the display is, does not panic the 
kernel.

The last time I tried 4.0.2 before this latest attempt, I also tried the
"i128" driver, which the website says is a Number Nine driver.  It didn't
work either, causing a kernel panic/reboot.  Elsewhere in the website it
clarifies that this driver is intended for Imagine-128 chipsets.

More information will follow as I learn more about X 4.0.2, including 
further bug reports, if they seem necessary.

>How-To-Repeat:

You'll probably need an IBM Aptiva and/or a Number Nine SR9 video card 
(which is out of production anyway).  Compile X 4.0.2 from ports, create a 
config file with xf86cfg, and substitute either the "savage" or "vesa" 
driver in place of the "vga" driver in the file.

Try to start X either as root, or with Xwrapper, and it should panic the 
kernel (at least, it causes the system to reboot, you never actually get 
to see the kernel messages as the console does not switch back to where 
the messages are appearing).

You may also be able to crash the machine simply by running xf86cfg 
without the -textmode switch.  In my setup, this will crash the machine.

If you force text mode with the above mentioned switch, xf86cfg does 
create a config file which does work, albeit only in 320x240/8-bit and 
640x480/4-bit modes.

>Fix:

No idea.  Using the "vga" driver provides a temporary solution, however by 
the nature of the vga driver, no accelleration or high-quality displays 
are available in this mode.
>Release-Note:
>Audit-Trail:

From: Nate Dannenberg <natedac@kscable.com>
To: <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: ports/25958: Xfree86 s3 savage and vesa drivers can panic the
 kernel
Date: Sat, 24 Mar 2001 20:10:15 -0600 (CST)

 I have come up with additional information regarding this problem, in that
 I now know how to get FreeBSD to provide the crash information for me at
 startup, via it's crashdump feature (see dumpon(8) and savecore(8)).
 
 The problem was that XFree86 4.0.2 (and 4.0.3) will crash my system, an
 IBM Aptiva (550 MHz Athlon, 96M Ram, Number Nine SR9 with S3 Savage4
 chipset and 8M ram), if I use the "savage" or "vesa" drivers.  Using the
 "vga" driver provides a temporary solution, however it's not a suitable
 replacement due to the very nature of plain VGA modes.
 
 ----- Text Import Begin -----
 
 su-2.04# gdb -k
 GNU gdb 4.18
 Copyright 1998 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you
 are
 welcome to change it and/or distribute copies of it under certain
 conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for
 details.
 This GDB was configured as "i386-unknown-freebsd".
 (kgdb) symbol-file kernel
 Reading symbols from kernel...(no debugging symbols found)...done.
 (kgdb) exec-file /usr/crash/kernel.0
 (kgdb) core-file /usr/crash/vmcore.0
 IdlePTD 3465216
 initial pcb at 2ba4a0
 panicstr: general protection fault
 panic messages:
 ---
 Fatal trap 9: general protection fault while in kernel mode
 instruction pointer     = 0x8:0xc024b4a3
 stack pointer           = 0x10:0xc76a9cf0
 frame pointer           = 0x10:0xc76a9d10
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = resume, IOPL = 3
 current process         = 344 (XFree86)
 interrupt mask          = none
 trap number             = 9
 panic: general protection fault
 syncing disks... 30 29 21 10
 done
 Uptime: 11m46s
 dumping to dev #ad/0x20001, offset 205184
 dump ata0: resetting devices .. done
 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71
 70 69
  68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45
 44 43 4
 2 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18
 17 16
 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
 ---
 #0  0xc013ebba in dumpsys ()
 (kgdb) where
 #0  0xc013ebba in dumpsys ()
 #1  0xc013e9db in boot ()
 #2  0xc013ed58 in poweroff_wait ()
 #3  0xc02575bd in trap_fatal ()
 #4  0xc0256fcb in trap ()
 #5  0xc024b4a3 in i686_mrstoreone ()
 #6  0xc024b3e9 in i686_mrstore ()
 #7  0xc024ba21 in i686_mrset ()
 #8  0xc0252a81 in mem_range_attr_set ()
 #9  0xc02529fd in mem_ioctl ()
 #10 0xc02528b4 in mmioctl ()
 #11 0xc017545e in spec_ioctl ()
 #12 0xc0175189 in spec_vnoperate ()
 #13 0xc0209a3d in ufs_vnoperatespec ()
 #14 0xc0171a44 in vn_ioctl ()
 #15 0xc014d10e in ioctl ()
 #16 0xc0257869 in syscall2 ()
 #17 0xc0249b95 in Xint0x80_syscall ()
 #18 0x8091059 in ?? ()
 #19 0x80955c7 in ?? ()
 #20 0x87760dd in ?? ()
 #21 0x8758e32 in ?? ()
 #22 0x806b7cc in ?? ()
 #23 0x80bab12 in ?? ()
 #24 0x806b045 in ?? ()
 (kgdb) quit
 
 I'll provide more information if I can, as I write this, I have a new
 kernel compiling to include within it the debugging symbols and the
 debugger itself (my existing copy lacks these items).
 
 
 -- 
  /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~___~~~~~\
 |  natedac@kscable.com              //Z@|___  |
 |  http://home.kscable.com/natedac |'(__ [_<  |
  \_C64/C128_-_What's_*YOUR*_hobby?__\___|____/
 

From: natedac@kscable.com
To: freebsd-gnats-submit@FreeBSD.org, natedac@kscable.com
Cc:  
Subject: Re: ports/25958: Xfree86's savage and vesa drivers
Date: Tue, 27 Mar 2001 12:53:25 -0600 (CST)

 I've managed to get some new info about this problem.  I managed to get a
 proper debug kernel built and have extracted some information from it
 using gdb as per the handbook.  You may want to delete the panic message 
 and other information I posted earlier, it's incomplete anyways.
 
 bash-2.04# gdb -k kernel.debug /usr/crash/vmcore.2
 GNU gdb 4.18
 Copyright 1998 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you 
 are
 welcome to change it and/or distribute copies of it under certain 
 conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for 
 details.
 This GDB was configured as "i386-unknown-freebsd"...
 IdlePTD 3457024
 initial pcb at 2ba4c0
 panicstr: general protection fault
 panic messages:
 ---
 Fatal trap 9: general protection fault while in kernel mode
 instruction pointer     = 0x8:0xc024b4b3
 stack pointer           = 0x10:0xc76b4cf0
 frame pointer           = 0x10:0xc76b4d10
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = resume, IOPL = 3
 current process         = 330 (XFree86)
 interrupt mask          = none
 trap number             = 9
 panic: general protection fault
 
 syncing disks... 33 32 23 12
 done
 Uptime: 3m14s
 dumping to dev #ad/0x20001, offset 205184
 dump ata0: resetting devices .. done
 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 
 70 69
  68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 
 44 43 4
 2 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 
 17 16
 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
 ---
 #0  dumpsys () at ../../kern/kern_shutdown.c:469
 469             if (dumping++) {
 (kgdb) where
 #0  dumpsys () at ../../kern/kern_shutdown.c:469
 #1  0xc013e9db in boot (howto=256) at ../../kern/kern_shutdown.c:309
 #2  0xc013ed58 in poweroff_wait (junk=0xc028e1c5, howto=-957278880)
     at ../../kern/kern_shutdown.c:556
 #3  0xc02575cd in trap_fatal (frame=0xc76b4cb0, eva=0)
     at ../../i386/i386/trap.c:951
 #4  0xc0256fdb in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
       tf_edi = -1, tf_esi = -1, tf_ebp = -949269232, tf_isp = -949269284,
       tf_ebx = -1, tf_edx = -1, tf_ecx = 592, tf_eax = -1, tf_trapno = 9,
       tf_err = 0, tf_eip = -1071336269, tf_cs = 8, tf_eflags = 77974,
       tf_esp = 65535, tf_ss = 0}) at ../../i386/i386/trap.c:613
 #5  0xc024b4b3 in i686_mrstoreone (arg=0xc02d7ed4)
     at ../../i386/i386/i686_mem.c:290
 #6  0xc024b3f9 in i686_mrstore (sc=0xc02d7ed4)
     at ../../i386/i386/i686_mem.c:253
 #7  0xc024ba31 in i686_mrset (sc=0xc02d7ed4, mrd=0xc09d81e0, 
 arg=0xc76b4eb0)
     at ../../i386/i386/i686_mem.c:489
 #8  0xc0252a91 in mem_range_attr_set (mrd=0xc09d81e0, arg=0xc76b4eb0)
     at ../../i386/i386/mem.c:439
 #9  0xc0252a0d in mem_ioctl (dev=0xc02b8ebc, cmd=2148298035,
     data=0xc76b4eac "\b", flags=3, p=0xc6f11560)
     at ../../i386/i386/mem.c:402
 #10 0xc02528c4 in mmioctl (dev=0xc02b8ebc, cmd=2148298035,
     data=0xc76b4eac "\b", flags=3, p=0xc6f11560)
     at ../../i386/i386/mem.c:338
 #11 0xc017544e in spec_ioctl (ap=0xc76b4de8)
     at ../../miscfs/specfs/spec_vnops.c:306
 #12 0xc0175179 in spec_vnoperate (ap=0xc76b4de8)
     at ../../miscfs/specfs/spec_vnops.c:119
 #13 0xc0209a09 in ufs_vnoperatespec (ap=0xc76b4de8)
     at ../../ufs/ufs/ufs_vnops.c:2391
 #14 0xc0171a34 in vn_ioctl (fp=0xc0acd740, com=2148298035,
     data=0xc76b4eac "\b", p=0xc6f11560) at vnode_if.h:429
 #15 0xc014d0fe in ioctl (p=0xc6f11560, uap=0xc76b4f80) at 
 ../../sys/file.h:178
 #16 0xc0257879 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
       tf_edi = 983040, tf_esi = 65536, tf_ebp = -1077937884,
       tf_isp = -949268524, tf_ebx = -1077937912, tf_edx = 673607984,
       tf_ecx = 141856768, tf_eax = 54, tf_trapno = 12, tf_err = 2,
       tf_eip = 673244900, tf_cs = 31, tf_eflags = 12951, tf_esp = 
 -1077937976,
       tf_ss = 47}) at ../../i386/i386/trap.c:1150
 #17 0xc0249ba5 in Xint0x80_syscall ()
 #18 0x8091059 in ?? ()
 #19 0x80955c7 in ?? ()
 #20 0x872a0dd in ?? ()
 #21 0x8710e32 in ?? ()
 #22 0x806b7cc in ?? ()
 #23 0x80bab12 in ?? ()
 #24 0x806b045 in ?? ()
 (kgdb) up 4
 #4  0xc0256fdb in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
       tf_edi = -1, tf_esi = -1, tf_ebp = -949269232, tf_isp = -949269284,
       tf_ebx = -1, tf_edx = -1, tf_ecx = 592, tf_eax = -1, tf_trapno = 9,
       tf_err = 0, tf_eip = -1071336269, tf_cs = 8, tf_eflags = 77974,
       tf_esp = 65535, tf_ss = 0}) at ../../i386/i386/trap.c:613
 613                     trap_fatal(&frame, eva);
 (kgdb) quit
 

From: natedac@kscable.com
To: freebsd-gnats-submit@FreeBSD.org, natedac@kscable.com
Cc:  
Subject: Re: ports/25958: Xfree86's savage and vesa drivers%2
Date: Tue, 27 Mar 2001 16:02:52 -0600 (CST)

 Problem has been solved by a workaround in the kernel source.  Thanks to 
 the help of some of the guys on #BSDcode on EFnet (hi BigSpoon!).  
 Apparently MTRR doesn't work on this paricular processor, an AMD 550 MHz 
 Athlon, or the kernel is somehow detecting it wrong.  XFree86 
 4.4.x obviously is trying to use this feature somehow, and that was 
 causing a kernel panic.
 
 Temporary Workaround:
 
 At line 572 of /sys/i386/i386/i686_mem.c, comment out the commands that 
 attempt to detect the MTRR facility, like this:
 
 ---- snip ----
 
 static void
 i686_mem_drvinit(void *unused)
    
 {
 
     /* Try for i686 MTRRs */
 /*
     if ((cpu_feature & CPUID_MTRR) &&
         ((cpu_id & 0xf00) == 0x600) &&
         ((strcmp(cpu_vendor, "GenuineIntel") == 0) ||
         (strcmp(cpu_vendor, "AuthenticAMD") == 0))) {
         mem_range_softc.mr_op = &i686_mrops;
     }
   
 */
     
 } 
 

From: Nate Dannenberg <natedac@kscable.com>
To: <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: ports/25958: Xfree86's savage and vesa drivers%2
Date: Tue, 27 Mar 2001 16:14:57 -0600 (CST)

 On Tue, 27 Mar 2001 natedac@kscable.com wrote:
 
 > Athlon, or the kernel is somehow detecting it wrong.  XFree86
 > 4.4.x obviously is trying to use this feature somehow, and that was
 > causing a kernel panic.
 
 Erm... make that 4.0.x (i.e. 4.0.2, 4.0.3)
 
 -- 
  /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~___~~~~~\
 |  natedac@kscable.com              //Z@|___  |
 |  http://home.kscable.com/natedac |'(__ [_<  |
  \_C64/C128_-_What's_*YOUR*_hobby?__\___|____/
 

From: natedac@kscable.com
To: freebsd-gnats-submit@FreeBSD.org, natedac@kscable.com
Cc: natedac@kscable.com, jhb@FreeBSD.org
Subject: Re: ports/25958: Xfree86's savage and vesa drivers%2
Date: Wed, 28 Mar 2001 00:51:49 -0600 (CST)

 Thanks to lots of help from BigSpoon on #BSDcode/EFnet (jhb@FreeBSD.org),
 here's a more proper way to fix the MTRR problem that plages some machines
 like mine.  This will allow the MTRR support to be disabled at will either
 in /boot/loader.conf or at the boot prompt.  It appears that today the
 copy of this file sitting on ftp.freebsd.org has been changed slightly (so
 a patch/diff against my week-old copy would be of little use anyways ;-)
 
 Anyways, here we go:
 
 Edit /usr/src/sys/i386/i386/i686_mem.c
 
 Somewhere near the start of the file, add these two lines:
 
 ------------------------------------------------------------------------------
    static int mtrrs_disabled;
    TUNABLE_INT_DECL("machdep.mtrrs_disabled", 0, mtrrs_disabled);
 ------------------------------------------------------------------------------
 
 Then, go to the end of the file, and make these changes to 
 i686_mem_drvinit()...
 
 ------------------------------------------------------------------------------
    static void
    i686_mem_drvinit(void *unused)
 
    {
 
    /* First, check if the user wants to allow MTRR at all */
 
    if (mtrrs_disabled) { return; }
 
        /* Ok, MTRR is allowed, so try for i686 MTRRs */
 
        if ((cpu_feature & CPUID_MTRR) &&
           ((cpu_id & 0xf00) == 0x600) &&
           ((strcmp(cpu_vendor, "GenuineIntel") == 0) ||
           (strcmp(cpu_vendor, "AuthenticAMD") == 0))) {
           mem_range_softc.mr_op = &i686_mrops;
        }
    }
 -----------------------------------------------------------------------------
 
 Finally, add a line to /boot/loader.conf to disable the MTRR support if 
 you need to (leaving it out or mis-spelling the variable name will cause 
 MTRR support to be detected and enabled normally):
 
 machdep.mtrrs_disabled = 1
 
 I guess at this point, the original PR should remain open until the bug is
 solved in a more formal manner, but this seems to be an effective
 workaround.  So far, I haven't seen any ill effects from disabling MTRR's.
Responsible-Changed-From-To: freebsd-ports->jmz 
Responsible-Changed-By: lioux 
Responsible-Changed-When: Tue Apr 10 19:34:46 PDT 2001 
Responsible-Changed-Why:  
Over to maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25958 
Responsible-Changed-From-To: jmz->jhb 
Responsible-Changed-By: jhb 
Responsible-Changed-When: Thu Aug 2 14:21:40 PDT 2001 
Responsible-Changed-Why:  
This is more about needing to disable MTRR's on buggy processors which is a 
kernel issue, not a ports issue. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25958 
Responsible-Changed-From-To: jhb->msmith 
Responsible-Changed-By: jhb 
Responsible-Changed-When: Fri Nov 16 15:29:23 PST 2001 
Responsible-Changed-Why:  
Mike wants it so he can fix the missing holes in our K7 MTRR support. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25958 
State-Changed-From-To: open->closed 
State-Changed-By: dwmalone 
State-Changed-When: Mon Apr 29 01:26:44 PDT 2002 
State-Changed-Why:  
I believe the patches that I recently committed to -current and -stable 
should resolve this issue. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25958 
>Unformatted:
