From owner-freebsd-current  Sat Jun 17 20:14:15 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id CD96637B5A9
	for <current@FreeBSD.ORG>; Sat, 17 Jun 2000 20:14:11 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id UAA69035;
	Sat, 17 Jun 2000 20:14:09 -0700 (PDT)
	(envelope-from dillon)
Date: Sat, 17 Jun 2000 20:14:09 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200006180314.UAA69035@apollo.backplane.com>
To: Donn Miller <dmmiller@cvzoom.net>
Cc: "Jordan K. Hubbard" <jkh@zippy.osd.bsdi.com>,
	Peter Wemm <peter@netplex.com.au>, van.woerkom@netcologne.de,
	current@FreeBSD.ORG
Subject: Re: GENERIC from today does not detect system console on my box 
References:  <Pine.BSF.4.21.0006172153090.299-100000@lc210.cvzoom.net>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:>     My test box, with a pristine 5.x kernel, crashes on boot... it only
:>     gets a few lines in, prints the amount of memory the machine has,
:>     and BEWM.  Low memory page fault.
:
:I saw the same thing myself.  It turns out, though, that I was using 
:
:COPTFLAGS= -march=pentium -Os -pipe
:
:to compile my kernel.  When I used the stock opt flags of
:
:COPTFLAGS= -O -pipe
:
:to compile my kernel, my machine booted OK.  It appears as though some

    Yes, that works for me.  But I don't think it's the optimizer that's
    causing the problem.

    Even though I couldn't get a stack backtrace I was able to look at the
    stack in hex, and wonud up with:

    c02347f0 t none_saver
    c02347f8 T sc_probe_unit
    c0234844 t scvidprobe
    c0234870 t sckbdprobe
    c02348a0 t adapter_name

    Fault at 0x60	( IP = 0x60 ... indirect jump through NULL obviously)
    0xc0333f04
    0xc0333f24
    ...
    0xc023485b  <-------	inside scvidprobe
    ...
    0xc02a9aa0  <-------	sc_consdev structure
    ...
    0xc0333f4c
    ...

    It looks like sccnattach() is calling scvidprobe() and scvidprobe()
    is then:

0xc023484b <scvidprobe+7>:      cmpl   $0x0,0x10(%ebp)
0xc023484f <scvidprobe+11>:     setne  %al
0xc0234852 <scvidprobe+14>:     movzbl %al,%eax
0xc0234855 <scvidprobe+17>:     push   %eax
0xc0234856 <scvidprobe+18>:     call   0xc0229c90 <vid_configure>    <----****
0xc023485b <scvidprobe+23>:     push   %ebx
0xc023485c <scvidprobe+24>:     push   $0xc0282682
0xc0234861 <scvidprobe+29>:     call   0xc0229b4c <vid_find_adapter>

    Calling vid_configure and vid_configure is dying.

    The list is generated from a linker_set ... one of those special linker
    lists.

    Something's broken the list.... maybe the DATA_SET macro is something ilke
    that.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message