From owner-freebsd-stable  Sun Mar  3 01:45:41 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id BAA04953
          for stable-outgoing; Sun, 3 Mar 1996 01:45:41 -0800 (PST)
Received: from asstdc.scgt.oz.au (asstdc.scgt.oz.au [202.14.234.65])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA04942
          for <stable@freebsd.org>; Sun, 3 Mar 1996 01:45:29 -0800 (PST)
Received: (from imb@localhost)
	by asstdc.scgt.oz.au (8.6.12/BSD4.4)
	id UAA00329 for stable@freebsd.org; Sun, 3 Mar 1996 20:44:53 +1100
From: michael butler <imb@scgt.oz.au>
Message-Id: <199603030944.UAA00329@asstdc.scgt.oz.au>
Subject: panic: inconsistent empty queue
To: stable@freebsd.org
Date: Sun, 3 Mar 1996 20:44:53 +1100 (EST)
X-Mailer: ELM [version 2.4 PL24beta]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@freebsd.org
Precedence: bulk

On a recently compiled -stable, I'm seeing either processes hanging with
"getnewbuf" or a "panic: inconsistent empty queue". Usually after running X
and netscape. There's 60+ meg of swap on this machine and 32 meg of RAM so I
don't have any explanations .. anyone ?

	michael

From owner-freebsd-stable  Sun Mar  3 02:35:11 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id CAA08860
          for stable-outgoing; Sun, 3 Mar 1996 02:35:11 -0800 (PST)
Received: from nervosa.com (root@nervosa.com [192.187.228.86])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA08854
          for <stable@freebsd.org>; Sun, 3 Mar 1996 02:35:08 -0800 (PST)
Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.4/nervosa.com.2) with SMTP id CAA03107; Sun, 3 Mar 1996 02:35:03 -0800 (PST)
Date: Sun, 3 Mar 1996 02:35:02 -0800 (PST)
From: invalid opcode <coredump@nervosa.com>
To: Mark Hittinger <bugs@freebsd.netcom.com>
cc: stable@freebsd.org
Subject: Re: termcap probs after make world?
In-Reply-To: <199603030330.VAA28268@freebsd.netcom.com>
Message-ID: <Pine.BSF.3.91.960303023421.2776G-100000@nervosa.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-stable@freebsd.org
Precedence: bulk

On Sat, 2 Mar 1996, Mark Hittinger wrote:

> 
> Anybody having problems with termcap stuff - vanilla tsets and initscr's
> after a 2.1-stable make world?
> 
> Later
> 
> Mark Hittinger
> Netcom/Dallas
> bugs@freebsd.netcom.com
> 

setenv TERMCAP /etc/termcap

this is a known problem.

== Chris Layne =============================================================
== coredump@nervosa.com ================ http://www.nervosa.com/~coredump ==


From owner-freebsd-stable  Sun Mar  3 07:44:59 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id HAA00849
          for stable-outgoing; Sun, 3 Mar 1996 07:44:59 -0800 (PST)
Received: from rich.isdn.bcm.tmc.edu (root@RICH.ISDN.BCM.TMC.EDU [128.249.250.34])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA00844
          for <stable@freebsd.org>; Sun, 3 Mar 1996 07:44:55 -0800 (PST)
Received: from richb.isdn.bcm.tmc.edu (root@richb.isdn.bcm.tmc.edu [128.249.250.35]) by rich.isdn.bcm.tmc.edu (8.6.12/8.6.12) with ESMTP id JAA26783; Sun, 3 Mar 1996 09:44:36 -0600
Received: (rich@localhost) by richb.isdn.bcm.tmc.edu (8.6.12/8.6.12) id JAA03265; Sun, 3 Mar 1996 09:44:34 -0600
Date: Sun, 3 Mar 1996 09:44:34 -0600
Message-Id: <199603031544.JAA03265@richb.isdn.bcm.tmc.edu>
From: Rich Murphey <rich@rich.isdn.bcm.tmc.edu>
To: stable@freebsd.org
CC: imb@scgt.oz.au
In-reply-to: <199603030944.UAA00329@asstdc.scgt.oz.au> (message from michael
	butler on Sun, 3 Mar 1996 20:44:53 +1100 (EST))
Subject: Re: panic: inconsistent empty queue
Reply-to: rich@lamprey.utmb.edu
Sender: owner-stable@freebsd.org
Precedence: bulk

|From: michael butler <imb@scgt.oz.au>
|On a recently compiled -stable, I'm seeing either processes hanging with
|"getnewbuf" or a "panic: inconsistent empty queue". Usually after running X
|and netscape. There's 60+ meg of swap on this machine and 32 meg of RAM so I
|don't have any explanations .. anyone ?

I'm seeing similar panics on -stable.  Reverting to an
older kernel eliminates them for this system and
another similar system (486/eisa).

I've built a kernel with -g, DDB and DODUMP.  If anyone
has suggestions as to what to look for with the
debugger or what to try, I'd apprecate any tips.  I can
also give anyone who is interested access to this
machine.  Rich


ahb2: board not responding
Debugger ("aha1742")
Stopped at Debugger+0x2b: ...
db>c
panic: biodone: buffer no busy
Stopped at Debugger+0x2b: ...
db> call diediedie
...
(no debugging symbols found)...
IdlePTD 20f000
current pcb at 1e31ac
panic: biodone: buffer not busy
#0  0xf019a663 in boot ()
(kgdb) where
#0  0xf019a663 in boot ()
#1  0xf01180d5 in panic ()
#2  0xf019a419 in diediedie ()
#3  0xf010142a in db_fncall ()
#4  0xf010115e in db_command ()
#5  0xf01012dd in db_command_loop ()
#6  0xf0103c78 in db_trap ()
#7  0xf019774a in kdb_trap ()
#8  0xf019f280 in trap ()
#9  0xf0197fb1 in calltrap ()
#10 0xf01180cf in panic ()
#11 0xf012ab55 in biodone ()
#12 0xf0171364 in scsi_done ()
#13 0xf0194a31 in ahb_done ()
#14 0xf01948c2 in ahbintr ()
#15 0xf019901d in Xresume11 ()
#16 0xf010bcf0 in softclock ()
#17 0xf01993cc in splz_swi ()
#18 0xf0174c50 in scsi_strategy ()
#19 0xf0174dcc in sdstrategy ()
#20 0xf01377ec in spec_strategy ()
#21 0xf01849f6 in ufs_strategy ()
#22 0xf012912e in bread ()
#23 0xf017da20 in ffs_read ()
#24 0xf01844fd in ufs_readdir ()
#25 0xf01320ba in getdirentries ()
#26 0xf019fcef in syscall ()
#27 0xf0197ffb in Xsyscall ()
#28 0x803d3bd in ?? ()
#29 0x803ce1b in ?? ()
#30 0x17cf in ?? ()
#31 0x3623 in ?? ()
#32 0x10e8 in ?? ()
(kgdb) 



panic: getnewbuf: inconsistent AGE queue, qindex = 2.
Debugger ("panic")
Stopped at Debugger+0x2b: ...
db> call diediedie
...
IdlePTD 20f000
current pcb at 1e31ac
panic: getnewbuf: inconsistent AGE queue, qindex=%d
#0  0xf019a663 in boot ()
(kgdb) where
#0  0xf019a663 in boot ()
#1  0xf01180d5 in panic ()
#2  0xf0129c49 in getnewbuf ()
#3  0xf012a1be in getblk ()
#4  0xf017ab5d in ffs_balloc ()
#5  0xf017dde5 in ffs_write ()
#6  0xf0132aff in vn_write ()
#7  0xf011959f in write ()
#8  0xf019fcef in syscall ()
#9  0xf0197ffb in Xsyscall ()
#10 0x1b16 in ?? ()
#11 0x18cd in ?? ()
#12 0x10e8 in ?? ()
(kgdb) 

From owner-freebsd-stable  Sun Mar  3 09:56:29 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id JAA05155
          for stable-outgoing; Sun, 3 Mar 1996 09:56:29 -0800 (PST)
Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA05150
          for <stable@freebsd.org>; Sun, 3 Mar 1996 09:56:22 -0800 (PST)
Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id JAA03335; Sun, 3 Mar 1996 09:56:03 -0800
From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com>
Message-Id: <199603031756.JAA03335@GndRsh.aac.dev.com>
Subject: Re: panic: inconsistent empty queue
To: rich@lamprey.utmb.edu
Date: Sun, 3 Mar 1996 09:56:03 -0800 (PST)
Cc: stable@freebsd.org, imb@scgt.oz.au
In-Reply-To: <199603031544.JAA03265@richb.isdn.bcm.tmc.edu> from "Rich Murphey" at Mar 3, 96 09:44:34 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@freebsd.org
Precedence: bulk

> 
> |From: michael butler <imb@scgt.oz.au>
> |On a recently compiled -stable, I'm seeing either processes hanging with
> |"getnewbuf" or a "panic: inconsistent empty queue". Usually after running X
> |and netscape. There's 60+ meg of swap on this machine and 32 meg of RAM so I
> |don't have any explanations .. anyone ?
> 
> I'm seeing similar panics on -stable.  Reverting to an
> older kernel eliminates them for this system and
> another similar system (486/eisa).
> 
> I've built a kernel with -g, DDB and DODUMP.  If anyone
> has suggestions as to what to look for with the
> debugger or what to try, I'd apprecate any tips.  I can
> also give anyone who is interested access to this
> machine.  Rich

I have duplicated this crash here running a 2 week old stable
during a make world, except I don't get the scsi timeout, I drop
right into a panic: getnewbuf: inconsistent AGE queue, qindex = 2,
with a similiar traceback.

Reverting to 2.1-RELEASE on the system eliminated the problem :-(.

I do not see this problem on any of the PCI systems I have been
building so this may be related to the EISA changes and only effecting
EISA systems.

-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD

From owner-freebsd-stable  Sun Mar  3 10:17:09 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA05781
          for stable-outgoing; Sun, 3 Mar 1996 10:17:09 -0800 (PST)
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA05772
          Sun, 3 Mar 1996 10:17:07 -0800 (PST)
Message-Id: <199603031817.KAA05772@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol
To: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
cc: rich@lamprey.utmb.edu, stable@freebsd.org, imb@scgt.oz.au
Subject: Re: panic: inconsistent empty queue 
In-reply-to: Your message of "Sun, 03 Mar 1996 09:56:03 PST."
             <199603031756.JAA03335@GndRsh.aac.dev.com> 
Date: Sun, 03 Mar 1996 10:17:07 -0800
From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
Sender: owner-stable@freebsd.org
Precedence: bulk

>I have duplicated this crash here running a 2 week old stable
>during a make world, except I don't get the scsi timeout, I drop
>right into a panic: getnewbuf: inconsistent AGE queue, qindex = 2,
>with a similiar traceback.
>
>Reverting to 2.1-RELEASE on the system eliminated the problem :-(.
>
>I do not see this problem on any of the PCI systems I have been
>building so this may be related to the EISA changes and only effecting
>EISA systems.

I've thought this too, but I can't understand how a change in the probe
code could cause a buffer problem many hours down the line.  I have a
bt747, aha1742, aha2742, and a aha2842 in my machine here, and as soon as
my disk for 2.1-stalbe returns, I'll try to track this down.  Can you
repro this in a -current environment?  The eisa code is very similar.

>-- 
>Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
>Accurate Automation Company                 Reliable computers for FreeBSD

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================

From owner-freebsd-stable  Sun Mar  3 10:42:47 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA06610
          for stable-outgoing; Sun, 3 Mar 1996 10:42:47 -0800 (PST)
Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA06584
          for <stable@freebsd.org>; Sun, 3 Mar 1996 10:42:31 -0800 (PST)
Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id KAA03395; Sun, 3 Mar 1996 10:42:04 -0800
From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com>
Message-Id: <199603031842.KAA03395@GndRsh.aac.dev.com>
Subject: Re: panic: inconsistent empty queue
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Sun, 3 Mar 1996 10:42:03 -0800 (PST)
Cc: rich@lamprey.utmb.edu, stable@freebsd.org, imb@scgt.oz.au
In-Reply-To: <199603031817.KAA05772@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 3, 96 10:17:07 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@freebsd.org
Precedence: bulk

> 
> >I have duplicated this crash here running a 2 week old stable
> >during a make world, except I don't get the scsi timeout, I drop
> >right into a panic: getnewbuf: inconsistent AGE queue, qindex = 2,
> >with a similiar traceback.
> >
> >Reverting to 2.1-RELEASE on the system eliminated the problem :-(.
> >
> >I do not see this problem on any of the PCI systems I have been
> >building so this may be related to the EISA changes and only effecting
> >EISA systems.
> 
> I've thought this too, but I can't understand how a change in the probe
> code could cause a buffer problem many hours down the line.  I have a
> bt747, aha1742, aha2742, and a aha2842 in my machine here, and as soon as
> my disk for 2.1-stalbe returns, I'll try to track this down.  Can you
> repro this in a -current environment?  The eisa code is very similar.

I don't play with -current here, and right now I do not have the time to
go play with it.  Sorry :-(


-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD

From owner-freebsd-stable  Sun Mar  3 16:33:08 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id QAA22588
          for stable-outgoing; Sun, 3 Mar 1996 16:33:08 -0800 (PST)
Received: from eldorado.net-tel.co.uk (eldorado.net-tel.co.uk [193.122.171.253])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA22579
          for <freebsd-stable@freebsd.org>; Sun, 3 Mar 1996 16:33:02 -0800 (PST)
From: Andrew.Gordon@net-tel.co.uk
Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id AAA22070 for freebsd-stable@freebsd.org; Mon, 4 Mar 1996 00:32:25 GMT
X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; 
        Relayed; Mon,  4 Mar 96  0:28:48 +0000
X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/";
         Relayed; Mon,  4 Mar 96  0:28:46 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; 
        Mon,  4 Mar 96  0:28:46 +0000
X400-MTS-Identifier: 
        ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:28291-960304002846-07D8]
X400-Content-Type: P2-1984 (2)
X400-Originator: Andrew.Gordon@net-tel.co.uk
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: freebsd-stable@freebsd.org
Date: Mon,  4 Mar 96  0:28:46 +0000
Content-Identifier: Re(2): panic: in
Message-Id: <"359-960304003140-C1B5*/G=Andrew/S=Gordon/O=Net-Tel Computer
 Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS>
To: freebsd-stable@freebsd.org
In-Reply-To: <"SunOS:21708-960303190858-7A28*/DD.RFC-822=owner-stable(a)freebsd.org/O=internet/PRMD=NET-TEL/ADMD=GOLD
 400/C=GB/"@MHS>
Subject: Re(2): panic: inconsistent empty queue
Sender: owner-stable@freebsd.org
Precedence: bulk

> >I have duplicated this crash here running a 2 week old stable
> >during a make world, except I don't get the scsi timeout, I drop
> >right into a panic: getnewbuf: inconsistent AGE queue, qindex = 2,
> >with a similiar traceback.
> >
> >Reverting to 2.1-RELEASE on the system eliminated the problem :-(.
> >
> >I do not see this problem on any of the PCI systems I have been
> >building so this may be related to the EISA changes and only effecting
> >EISA systems.
> 
> I've thought this too, but I can't understand how a change in the probe
> code could cause a buffer problem many hours down the line.  I have a
> bt747, aha1742, aha2742, and a aha2842 in my machine here, and as soon as
> my disk for 2.1-stalbe returns, I'll try to track this down.  Can you
> repro this in a -current environment?  The eisa code is very similar.

I have similar symptoms on a couple of systems here (running -current as of
CTM delta src-2.1.0046.gz):

- This machine (486/66 VLB with 2842 SCSI) fails an hour or so into
  'make world' if running -stable kernel; completes OK if running
   kernel.GENERIC from 2.1R

- Another machine (P166 PCI, 3940 SCSI) worked OK with a corresponding
  -stable kernel.

- I am not always seeing panics; more often partial or complete latch-ups.
  In the most interesting case, I was running X with a make world in
  one xterm that had been running overnight, but appeared to have stalled
  (no disc activity).  The shells in the other xterms were perfectly happy,
  and I could ps -ax to see what was going on, 'ls' various other
  directories etc.  However, when I tried to 'ls' in the directory where
  the 'make world' appeared to be working, that process hung up too.


Of course, the fact that it appears to be EISA/VLB versus PCI may be a red
herring, since (at least in my case) the PCI systems tend to have faster CPU
and so the timing will be subsantially different...             

From owner-freebsd-stable  Mon Mar  4 11:32:10 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id LAA21655
          for stable-outgoing; Mon, 4 Mar 1996 11:32:10 -0800 (PST)
Received: from thing.sunquest.com (thing.Sunquest.COM [149.138.1.11])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA21634
          for <stable@freebsd.org>; Mon, 4 Mar 1996 11:32:03 -0800 (PST)
From: tony@thing.sunquest.com
Received: by thing.sunquest.com; id AA21790; Mon, 4 Mar 1996 12:31:16 -0700
Message-Id: <9603041931.AA21790@thing.sunquest.com>
To: stable@freebsd.org
X-Face: ZQe?G+$UQG8,i~KL=gy`<?o:(AZ:6dZbMH]/`C`lsbcBIGcmQmyeWhF\q&E%Hh6PK8oqhi5
 [t#-kli@aa1Pgm^I?qc??t?kjf_&GZz2UXh\Yy8NtB(k!w(usJ"|.N.!C>T:c1bxG<{7ta&{,'$LiA
 !`"u>-"@wkx>yf.z_5<N=AaH{P&FrCwwm94G,Ym'NTF"H"{weMX4~wh
X-Mailer: Rand MH v6.7
Subject: some questions
Date: Mon, 04 Mar 96 12:31:16 -0700
X-Mts: smtp
Sender: owner-stable@freebsd.org
Precedence: bulk


Hi,

I upgraded my system (it had 2.0.5 that Rod installed on it) to 2.1-stable
over the weekend. Been a while since I built a UNIX system from src :-)

Went very smoothly!

I have a couple of questions:

1) I did a find on / /usr to see what old files I still had knocking around
   from 2.0.5.

   Noticed a lot of the /usr/include files had not been touched.

   Did some poking around, noticed that the include Makefile installs 
   conditionally ... 'cmp -s /usr/include/$i $i || install $i ...'

   Clearly my files in /usr/include are upto date, but I was curious what the
   rational behind this conditional installation was, since it's the first
   time I've seen this in a Makefile.

2) In the 'make world', were full dependancies (.depend files) generated ?

   In other words, in future will just the changed decks be built ?

   Assuming no hidden/functional dependancies, is building this way safe, or
   do people usually build from a clean object tree each time ?

3) Are the changes to -stable documented anywhere ? 

   Don't see anything on freebsd-stable. Are the cvs-* lists just for -current
   or are announcements of -stable changes posted there also ?

   It isn't a big deal, except when some functional dependancy which won't be
   handled by the make dependancies is introduced.

4) Is there any documentation on the build process ? Or is share/mk/bsd.README
   about it ?

THANKS!

tony

From owner-freebsd-stable  Mon Mar  4 15:28:47 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id PAA08782
          for stable-outgoing; Mon, 4 Mar 1996 15:28:47 -0800 (PST)
Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA08777
          for <stable@FreeBSD.ORG>; Mon, 4 Mar 1996 15:28:38 -0800 (PST)
Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id KAA14656; Tue, 5 Mar 1996 10:01:10 +1030
From: Michael Smith <msmith@atrad.adelaide.edu.au>
Message-Id: <199603042331.KAA14656@genesis.atrad.adelaide.edu.au>
Subject: Re: some questions
To: tony@thing.sunquest.com
Date: Tue, 5 Mar 1996 10:01:10 +1030 (CST)
Cc: stable@FreeBSD.ORG
In-Reply-To: <9603041931.AA21790@thing.sunquest.com> from "tony@thing.sunquest.com" at Mar 4, 96 12:31:16 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.ORG
Precedence: bulk

tony@thing.sunquest.com stands accused of saying:

> 2) In the 'make world', were full dependancies (.depend files) generated ?

Yes.

>    In other words, in future will just the changed decks be built ?

No.  Normally, 'make world' cleans everything and builds from scratch.
You can get around this by bringing in the 'NOCLEAN' option from -current.
(Or you can hack it into the toplevel Makefile, it's relatively trivial).

>    Assuming no hidden/functional dependancies, is building this way safe, or
>    do people usually build from a clean object tree each time ?

That depends 8)  Fascists with big systems do full builds all the time;
those of us with smaller ones tend to use NOCLEAN more often.  As a general
rule, the dependencies work OK.

> 3) Are the changes to -stable documented anywhere ? 
> 
>    Don't see anything on freebsd-stable. Are the cvs-* lists just for -current
>    or are announcements of -stable changes posted there also ?

The CVS lists are the best place to watch for changes.  -stable is more of
a discussion forum.

>    It isn't a big deal, except when some functional dependancy which won't be
>    handled by the make dependancies is introduced.

This sort of thing is almost always announced along with the CVS commit that
makes it necessary.

> 4) Is there any documentation on the build process ? Or is share/mk/bsd.README
>    about it ?

Ehh 8)  /usr/src/Makefile is about all there is.  Basically, it goes :

- build vital tools
- build & install includes
- build & install libraries
- build everything else
- install everything else
- build and install documentation

There are occasionally bootstrapping races between the 'vital tools' and
the includes that are hard for committers to pick up, and occasionally
'vital tools' are omitted, but as a general rule the process works very
smoothly.  
(eg. upgrade of pre-2.1 -STABLE to feb -STABLE only required one manual
intervention)

> tony

-- 
]] Mike Smith, Software Engineer        msmith@atrad.adelaide.edu.au    [[
]] Genesis Software                     genesis@atrad.adelaide.edu.au   [[
]] High-speed data acquisition and      (GSM mobile) 0411-222-496       [[
]] realtime instrument control          (ph/fax)  +61-8-267-3039        [[
]] Collector of old Unix hardware.      "Where are your PEZ?" The Tick  [[

From owner-freebsd-stable  Mon Mar  4 20:12:32 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id UAA28208
          for stable-outgoing; Mon, 4 Mar 1996 20:12:32 -0800 (PST)
Received: from guppy.pond.net ([205.240.25.2])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA28196
          for <freebsd-stable@freebsd.org>; Mon, 4 Mar 1996 20:12:24 -0800 (PST)
Received: (from ben@localhost) by guppy.pond.net (8.6.12/8.6.9) id UAA14173; Mon, 4 Mar 1996 20:11:24 -0800
Date: Mon, 4 Mar 1996 20:11:24 -0800 (PST)
From: Ben Kirkpatrick <ben@guppy.pond.net>
To: freebsd-stable@freebsd.org
Subject: Stable vs. local changes at ISP
Message-ID: <Pine.BSF.3.91.960304200435.14024A-100000@guppy.pond.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-stable@freebsd.org
Precedence: bulk

   Gotta couple questions that I couldn't seem to find answers to in the
mailing list archives...
   1) By using sup to update the src tree here, will I indanger some of
the local changes we've made? (i.e. des and 16char usernames)
   2) make world sometimes causes problems on a running system, possibly
updating libs before the appropriate binaries and rebuilding kernel. (i.e.
w, and who always act funny)
   3) Any comment on this idea:  We do system maint on sunday nights.
Would it be acceptable/safe to run sup and make the day before, and have
it actually install while in single-user mode?  How do you postpone the
install step?

Thank you,

--Ben Kirkpatrick (BK416); The Pond; Cascade Communications Group, Inc.
Voice:541-302-1295 Fax:541-302-1298 Pager:710-2544 Web: pond.net/~ben


From owner-freebsd-stable  Mon Mar  4 22:46:45 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id WAA16349
          for stable-outgoing; Mon, 4 Mar 1996 22:46:45 -0800 (PST)
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA16334
          for <freebsd-stable@freebsd.org>; Mon, 4 Mar 1996 22:46:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id WAA27002; Mon, 4 Mar 1996 22:46:25 -0800 (PST)
To: Ben Kirkpatrick <ben@guppy.pond.net>
cc: freebsd-stable@freebsd.org
Subject: Re: Stable vs. local changes at ISP 
In-reply-to: Your message of "Mon, 04 Mar 1996 20:11:24 PST."
             <Pine.BSF.3.91.960304200435.14024A-100000@guppy.pond.net> 
Date: Mon, 04 Mar 1996 22:46:25 -0800
Message-ID: <27000.826008385@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-stable@freebsd.org
Precedence: bulk

>    1) By using sup to update the src tree here, will I indanger some of
> the local changes we've made? (i.e. des and 16char usernames)

You probably wouldn't want to do it like that (e.g. yes, it would
endanger your changes).

Instead, sup the CVS tree and check out a copy of -stable somewhere.
Work in this directory and use CVS update to periodically sync your
tree with ours.  CTM will preserve your changes and also notify you
when you've modified something which is now in conflict with us.  It
won't do this in a very pleasant way, mind you (unless you happen to
like lots of regions marked with `<<<<<<' characters in your source
files :-), but it's better than the alternative.

>    2) make world sometimes causes problems on a running system, possibly
> updating libs before the appropriate binaries and rebuilding kernel. (i.e.
> w, and who always act funny)

Yeah, we know.  This is often unavoidable, sorry!

>    3) Any comment on this idea:  We do system maint on sunday nights.
> Would it be acceptable/safe to run sup and make the day before, and have
> it actually install while in single-user mode?  How do you postpone the
> install step?

With a `make world?'  You don't, I'm afraid.

There are two options, that I see:

1. Make a custom version of the world target that doesn't install
   anything, then go find and fix all the other Makefiles which make
   assumptions about various things being in /usr/bin, /usr/include
   and /usr/lib.

   This is a big job, which is why it's been postponed for so long.
   It's an especially nasty problem for the compiler tools if you're
   trying to go for 100% clean "no external dependencies" strategy.

2. Install with DESTDIR pointing somewhere else, then devise a scheme
   whereby you reboot and "swap" to the new populated tree as your
   root.  Keep the old one around for reversion in case it doesn't
   work.

   Making this scheme work actually has other merits - you could
   hypothetically run both 2.1 and 2.2 on the same machine, for
   example.  You'd have to do a chroot() of some sort in
   /sys/kern/init_main.c before running what's typically /sbin/init,
   but it's not undoable.  In fact, I think I'll give it a shot
   right now, just to see what happens.. :-)

						Jordan

From owner-freebsd-stable  Tue Mar  5 05:39:29 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id FAA26023
          for stable-outgoing; Tue, 5 Mar 1996 05:39:29 -0800 (PST)
Received: from asstdc.scgt.oz.au (asstdc.scgt.oz.au [202.14.234.65])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA26003
          Tue, 5 Mar 1996 05:39:20 -0800 (PST)
Received: (from imb@localhost)
	by asstdc.scgt.oz.au (8.6.12/BSD4.4)
	id AAA14678; Wed, 6 Mar 1996 00:38:02 +1100
From: michael butler <imb@scgt.oz.au>
Message-Id: <199603051338.AAA14678@asstdc.scgt.oz.au>
Subject: 2842 and the disappearing file-system :-(
To: stable@freebsd.org, current@freebsd.org
Date: Wed, 6 Mar 1996 00:38:00 +1100 (EST)
X-Mailer: ELM [version 2.4 PL24beta]
Content-Type: text
Sender: owner-stable@freebsd.org
Precedence: bulk

Without warning today, the recurrent collapse of -stable with "panic:
inconsistent xxx queue" managed to trash my root file-system beyond recovery
(/etc et al) and a substantial proportion of anything vaguely near a
file-subsystem root directory (i.e. /var, /usr and /home are all separate
file-systems and all were damaged to varying degrees). I presume that this
was just particularly bad timing as there was significant activity on all of
them at that moment (of the order of ~60 transfers second).

After spending all day at this "game" (picking through a zillion remnants in
lost+found directories and restoring what I could from tape), I've finally
gotten this machine back to the point of being usable .. a fine effort for a
"stable" system, if I might express some of my frustration !

This particular failure, as I mentioned before on the -stable list, is
specific to the VESA controller (2842 rev C). It has never occurred with the
BT542B and I've established that the "cheap" version (i.e. non-enhanced) of
the Amd486DX4 that I'm using is only capable of running its internal cache
in write-thru mode.

My question is this .. since -stable is presently unusable unless I want to
strangle my disk I/O (with news arriving at ~3 articles/second) and -release
too buggy for "heavy-duty" use, is -current likely to be any better ?

	michael

From owner-freebsd-stable  Tue Mar  5 10:15:27 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA12311
          for stable-outgoing; Tue, 5 Mar 1996 10:15:27 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA12295
          Tue, 5 Mar 1996 10:15:23 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08681; Tue, 5 Mar 1996 11:12:05 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199603051812.LAA08681@phaeton.artisoft.com>
Subject: Re: 2842 and the disappearing file-system :-(
To: imb@scgt.oz.au (michael butler)
Date: Tue, 5 Mar 1996 11:12:04 -0700 (MST)
Cc: stable@FreeBSD.org, current@FreeBSD.org
In-Reply-To: <199603051338.AAA14678@asstdc.scgt.oz.au> from "michael butler" at Mar 6, 96 00:38:00 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.org
Precedence: bulk

> Without warning today, the recurrent collapse of -stable with "panic:
> inconsistent xxx queue" managed to trash my root file-system beyond recovery
> (/etc et al) and a substantial proportion of anything vaguely near a
> file-subsystem root directory (i.e. /var, /usr and /home are all separate
> file-systems and all were damaged to varying degrees). I presume that this
> was just particularly bad timing as there was significant activity on all of
> them at that moment (of the order of ~60 transfers second).

Change:
	static int doasyncfree = 1;

To:
	static int doasyncfree = 1;

In /sys/ufs/ffs/ffs_alloc.c.  This will resove the massive crash
problem at some expense in synchronicity (the write clustering
code pretty much sucks).

> This particular failure, as I mentioned before on the -stable list, is
> specific to the VESA controller (2842 rev C). It has never occurred with the
> BT542B and I've established that the "cheap" version (i.e. non-enhanced) of
> the Amd486DX4 that I'm using is only capable of running its internal cache
> in write-thru mode.
> 
> My question is this .. since -stable is presently unusable unless I want to
> strangle my disk I/O (with news arriving at ~3 articles/second) and -release
> too buggy for "heavy-duty" use, is -current likely to be any better ?

Obviously your cache is not being updated correctly as a result of
a DMA completion.

Unfortunately, there is no way to compensate for bad motherboard
wiring of cache notification pins other than to turn off the cache.
All pentium motherboards with Saturn I (mask date prior to April 1994)
chip sets can't maintain cache coherency on PCI -- ever wonder why
the 60MHz Gateway systems were so cheap?  Most VESA systems are worse,
since they do not label information.

Are you sure that the VESA controller is in a master slot?  If it
isn't, the VESA standard makes no guarantees regarding maintenance
of cache coherency.  Note that not all VESA motherboards even *have*
master slots.

For any given VESA system, it is most likely that the connector
closest to the edge of the board is the master slot, if there is
a master slot at all (VESA masters operate by stealing DRAM refresh
cycles to achieve their high speed; you may need to adjust the bus
on time down in the card setup, even if you correctly get it in a
master slot -- Adaptec controllers are known to have aggressive
bus-on times).

In any case, it is a hardware problem related to bus mastering DMA
and VESA, not a BSD problem.

You may want to run an "advanced CMOS setup" or whatever passes for
it in your BIOS, to ensure that you have a master slot and that
mastering is enabled.

You will *probably* need to run the Adaptec "bus-on time" setup, as
described above.  Alternately, jumper more wait states or go for
60 vs. 70ns RAM, etc.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-stable  Tue Mar  5 11:05:23 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id LAA15826
          for stable-outgoing; Tue, 5 Mar 1996 11:05:23 -0800 (PST)
Received: from tfs.com (tfs.com [140.145.250.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA15799
          Tue, 5 Mar 1996 11:05:18 -0800 (PST)
Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP
	id m0tu22o-0003wrC; Tue, 5 Mar 96 11:05 PST
Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id TAA04329; Tue, 5 Mar 1996 19:05:12 GMT
X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol
To: Terry Lambert <terry@lambert.org>
cc: imb@scgt.oz.au (michael butler), stable@FreeBSD.org, current@FreeBSD.org
Subject: Re: 2842 and the disappearing file-system :-( 
In-reply-to: Your message of "Tue, 05 Mar 1996 11:12:04 MST."
             <199603051812.LAA08681@phaeton.artisoft.com> 
Date: Tue, 05 Mar 1996 19:05:10 +0000
Message-ID: <4327.826052710@critter.tfs.com>
From: Poul-Henning Kamp <phk@critter.tfs.com>
Sender: owner-stable@FreeBSD.org
Precedence: bulk

> > Without warning today, the recurrent collapse of -stable with "panic:
> > inconsistent xxx queue" managed to trash my root file-system beyond recover
y
> > (/etc et al) and a substantial proportion of anything vaguely near a
> > file-subsystem root directory (i.e. /var, /usr and /home are all separate
> > file-systems and all were damaged to varying degrees). I presume that this
> > was just particularly bad timing as there was significant activity on all o
f
> > them at that moment (of the order of ~60 transfers second).
> 
> Change:
> 	static int doasyncfree = 1;
> 
> To:
> 	static int doasyncfree = 1;

You forgot to mention that you patented this fix ?

--
Poul-Henning Kamp           | phk@FreeBSD.ORG       FreeBSD Core-team.
http://www.freebsd.org/~phk | phk@login.dknet.dk    Private mailbox.
whois: [PHK]                | phk@ref.tfs.com       TRW Financial Systems, Inc.
Future will arrive by its own means, progress not so.

From owner-freebsd-stable  Tue Mar  5 11:52:59 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id LAA18838
          for stable-outgoing; Tue, 5 Mar 1996 11:52:59 -0800 (PST)
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA18831
          Tue, 5 Mar 1996 11:52:56 -0800 (PST)
Message-Id: <199603051952.LAA18831@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol
To: Terry Lambert <terry@lambert.org>
cc: imb@scgt.oz.au (michael butler), stable@FreeBSD.org, current@FreeBSD.org
Subject: Re: 2842 and the disappearing file-system :-( 
In-reply-to: Your message of "Tue, 05 Mar 1996 11:12:04 MST."
             <199603051812.LAA08681@phaeton.artisoft.com> 
Date: Tue, 05 Mar 1996 11:52:56 -0800
From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
Sender: owner-stable@FreeBSD.org
Precedence: bulk

>> This particular failure, as I mentioned before on the -stable list, is
>> specific to the VESA controller (2842 rev C). It has never occurred with the
>> BT542B and I've established that the "cheap" version (i.e. non-enhanced) of
>> the Amd486DX4 that I'm using is only capable of running its internal cache
>> in write-thru mode.
>> 
>> My question is this .. since -stable is presently unusable unless I want to
>> strangle my disk I/O (with news arriving at ~3 articles/second) and -release
>> too buggy for "heavy-duty" use, is -current likely to be any better ?
>
>Obviously your cache is not being updated correctly as a result of
>a DMA completion.
>

Actually this appears to be a bug in eisaconf as it affects all
eisa scsi controllers at the moment.  I'm looking into it, but the
problem is not obvious and doesn't occur in -current.

>
>					Terry Lambert
>					terry@lambert.org
>---
>Any opinions in this posting are my own and not those of my present
>or previous employers.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================

From owner-freebsd-stable  Tue Mar  5 12:17:33 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA20502
          for stable-outgoing; Tue, 5 Mar 1996 12:17:33 -0800 (PST)
Received: from widget.xmission.com (root@widget.xmission.com [198.60.22.228])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA20474
          Tue, 5 Mar 1996 12:17:23 -0800 (PST)
Received: (from rlenk@localhost) by widget.xmission.com (8.6.12/8.6.12) id NAA06046; Tue, 5 Mar 1996 13:17:05 -0700
From: Ron Lenk <rlenk@widget.xmission.com>
Message-Id: <199603052017.NAA06046@widget.xmission.com>
Subject: Re: 2842 and the disappearing file-system :-(
To: imb@scgt.oz.au (michael butler)
Date: Tue, 5 Mar 1996 13:17:04 -0700 (MST)
Cc: stable@freebsd.org, current@freebsd.org
In-Reply-To: <199603051338.AAA14678@asstdc.scgt.oz.au> from "michael butler" at Mar 6, 96 00:38:00 am
X-Mailer: ELM [version 2.4 PL24 ME8a]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@freebsd.org
Precedence: bulk

> Without warning today, the recurrent collapse of -stable with "panic:
> inconsistent xxx queue" managed to trash my root file-system beyond recovery
> (/etc et al) and a substantial proportion of anything vaguely near a
> file-subsystem root directory (i.e. /var, /usr and /home are all separate
> file-systems and all were damaged to varying degrees). I presume that this
> was just particularly bad timing as there was significant activity on all of
> them at that moment (of the order of ~60 transfers second).

Well, I can tell you that you're not alone in seeing these particular
problems with -stable and the 2842. I've seen the same types of panics
and hang conditions with -stable for the last two months. ( since the
import of the new ahc driver in Jan ) Fortunately, however, I have been
using a 2.1-RELEASE kernel without incident ( up 15 days right now ),
so I haven't seen any spectacular filesystem damage.

In any case, others have mentioned the same kinds of panics, and not
necessarily with the 2842. In particular, people with 1742 controllers
have seen them as well. Rod Grimes mentioned in one message that he
has not seen them on PCI systems, but rather only on EISA systems.
( This would make sense, since the 2842 appears acts like an EISA card )

Anyway, I've vented my frustration in the past, and have been more or
less quiet about things, hoping that someone would come along and fix
the problem. :)

Ron

-- 
Ron Lenk -- rlenk@xmission.com

From owner-freebsd-stable  Tue Mar  5 12:40:04 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA22225
          for stable-outgoing; Tue, 5 Mar 1996 12:40:04 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA22160
          Tue, 5 Mar 1996 12:39:45 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA08976; Tue, 5 Mar 1996 13:35:34 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199603052035.NAA08976@phaeton.artisoft.com>
Subject: Re: 2842 and the disappearing file-system :-(
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Tue, 5 Mar 1996 13:35:34 -0700 (MST)
Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org
In-Reply-To: <199603051952.LAA18831@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 5, 96 11:52:56 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.org
Precedence: bulk

> >> This particular failure, as I mentioned before on the -stable list, is
> >> specific to the VESA controller (2842 rev C). It has never occurred with the
> >> BT542B and I've established that the "cheap" version (i.e. non-enhanced) of
> >> the Amd486DX4 that I'm using is only capable of running its internal cache
> >> in write-thru mode.
> >> 
> >> My question is this .. since -stable is presently unusable unless I want to
> >> strangle my disk I/O (with news arriving at ~3 articles/second) and -release
> >> too buggy for "heavy-duty" use, is -current likely to be any better ?
> >
> >Obviously your cache is not being updated correctly as a result of
> >a DMA completion.
> >
> 
> Actually this appears to be a bug in eisaconf as it affects all
> eisa scsi controllers at the moment.  I'm looking into it, but the
> problem is not obvious and doesn't occur in -current.

He has a VESA controller... brain farts are contagious!


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-stable  Tue Mar  5 12:42:28 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA22516
          for stable-outgoing; Tue, 5 Mar 1996 12:42:28 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA22475
          Tue, 5 Mar 1996 12:42:22 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA08990; Tue, 5 Mar 1996 13:37:02 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199603052037.NAA08990@phaeton.artisoft.com>
Subject: Re: 2842 and the disappearing file-system :-(
To: phk@critter.tfs.com (Poul-Henning Kamp)
Date: Tue, 5 Mar 1996 13:37:02 -0700 (MST)
Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org
In-Reply-To: <4327.826052710@critter.tfs.com> from "Poul-Henning Kamp" at Mar 5, 96 07:05:10 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.org
Precedence: bulk

> > Change:
> > 	static int doasyncfree = 1;
> > 
> > To:
> > 	static int doasyncfree = 1;
> 
> You forgot to mention that you patented this fix ?

Yes.  I claim "trade secret" rights for this line of code, since it's
obvious you applied the fix to the -current source.  8-).

Of course that second '1' is supposed to be a '0'.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-stable  Tue Mar  5 12:46:26 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA22956
          for stable-outgoing; Tue, 5 Mar 1996 12:46:26 -0800 (PST)
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA22951
          for <stable@freebsd.org>; Tue, 5 Mar 1996 12:46:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id MAA04947; Tue, 5 Mar 1996 12:45:52 -0800 (PST)
To: michael butler <imb@scgt.oz.au>
cc: stable@freebsd.org
Subject: Re: 2842 and the disappearing file-system :-( 
In-reply-to: Your message of "Wed, 06 Mar 1996 00:38:00 +1100."
             <199603051338.AAA14678@asstdc.scgt.oz.au> 
Date: Tue, 05 Mar 1996 12:45:52 -0800
Message-ID: <4945.826058752@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-stable@freebsd.org
Precedence: bulk

> gotten this machine back to the point of being usable .. a fine effort for a
> "stable" system, if I might express some of my frustration !

Your frustration is understandable, though please do try to temper it
somewhat with the knowledge that many others are having far better
luck - you seem to have hit upon a hardware combination which is
somewhat pathological, unfortuantely.  I wish it wasn't so easy to do
that on the PC platform, but it kind of is unless you're willing to
select from a very rigidly defined set of components.  I would
personally go out and bury that VESA board at midnight on a full moon,
driving a wooden stake through its center so that it doesn't come back
from the dead, but I can appreciate that you might not have this
option.

Have you talked to Justin Gibbs?

> My question is this .. since -stable is presently unusable unless I want to
> strangle my disk I/O (with news arriving at ~3 articles/second) and -release
> too buggy for "heavy-duty" use, is -current likely to be any better ?

I fail to see how it could be much worse, in your case.. :-)

					Jordan

From owner-freebsd-stable  Tue Mar  5 13:00:06 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id NAA24164
          for stable-outgoing; Tue, 5 Mar 1996 13:00:06 -0800 (PST)
Received: from skiddaw.elsevier.co.uk (skiddaw.elsevier.co.uk [193.131.222.60])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA24118
          Tue, 5 Mar 1996 13:00:01 -0800 (PST)
Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.12/8.6.12) with ESMTP id UAA15854; Tue, 5 Mar 1996 20:58:03 GMT
Received: from tees by snowdon with SMTP (PP); Tue, 5 Mar 1996 20:55:29 +0000
Received: (from dpr@localhost) by tees (SMI-8.6/8.6.12) id UAA03676;
          Tue, 5 Mar 1996 20:58:12 GMT
Date: Tue, 5 Mar 1996 20:58:12 GMT
From: Paul Richards <p.richards@elsevier.co.uk>
Message-Id: <199603052058.UAA03676@tees>
To: imb@scgt.oz.au, terry@lambert.org
Subject: Re: 2842 and the disappearing file-system :-(
Cc: stable@FreeBSD.org, current@FreeBSD.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: f2+qrXxeCIyV2zlga1uyIw==
Sender: owner-stable@FreeBSD.org
Precedence: bulk

>
> Change:
> 	static int doasyncfree = 1;
> 
> To:
> 	static int doasyncfree = 1;

Not one of your most usefull pieces of advice Terry :-)

From owner-freebsd-stable  Tue Mar  5 13:21:35 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id NAA25678
          for stable-outgoing; Tue, 5 Mar 1996 13:21:35 -0800 (PST)
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA25661
          Tue, 5 Mar 1996 13:21:29 -0800 (PST)
Message-Id: <199603052121.NAA25661@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol
To: Terry Lambert <terry@lambert.org>
cc: imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org
Subject: Re: 2842 and the disappearing file-system :-( 
In-reply-to: Your message of "Tue, 05 Mar 1996 13:35:34 MST."
             <199603052035.NAA08976@phaeton.artisoft.com> 
Date: Tue, 05 Mar 1996 13:21:28 -0800
From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
Sender: owner-stable@FreeBSD.org
Precedence: bulk

>> Actually this appears to be a bug in eisaconf as it affects all
>> eisa scsi controllers at the moment.  I'm looking into it, but the
>> problem is not obvious and doesn't occur in -current.
>
>He has a VESA controller... brain farts are contagious!

He has a VESA controller that uses an EISA probe and so is
also affected.

>					Terry Lambert
>					terry@lambert.org
>---
>Any opinions in this posting are my own and not those of my present
>or previous employers.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================

From owner-freebsd-stable  Tue Mar  5 15:03:05 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id PAA04233
          for stable-outgoing; Tue, 5 Mar 1996 15:03:05 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA04206
          Tue, 5 Mar 1996 15:02:56 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA09308; Tue, 5 Mar 1996 15:57:28 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199603052257.PAA09308@phaeton.artisoft.com>
Subject: Re: 2842 and the disappearing file-system :-(
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Tue, 5 Mar 1996 15:57:28 -0700 (MST)
Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org
In-Reply-To: <199603052121.NAA25661@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 5, 96 01:21:28 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.org
Precedence: bulk

> >> Actually this appears to be a bug in eisaconf as it affects all
> >> eisa scsi controllers at the moment.  I'm looking into it, but the
> >> problem is not obvious and doesn't occur in -current.
> >
> >He has a VESA controller... brain farts are contagious!
> 
> He has a VESA controller that uses an EISA probe and so is
> also affected.

Ah.  That's broken. 8-(.  This must be a VESA/EISA box for it to
see the EISA signature and hit the EISA code?


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-stable  Tue Mar  5 15:27:25 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id PAA06139
          for stable-outgoing; Tue, 5 Mar 1996 15:27:25 -0800 (PST)
Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA06119
          Tue, 5 Mar 1996 15:27:21 -0800 (PST)
Received: from venus.mcs.com (root@Venus.mcs.com [192.160.127.92]) by kitten.mcs.com (8.6.12/8.6.9) with SMTP id RAA02881; Tue, 5 Mar 1996 17:27:09 -0600
Received: by venus.mcs.com (/\==/\ Smail3.1.28.1 #28.5)
	id <m0tu68K-000IDUC@venus.mcs.com>; Tue, 5 Mar 96 17:27 CST
Message-Id: <m0tu68K-000IDUC@venus.mcs.com>
Subject: Re: 2842 and the disappearing file-system :-(
To: rlenk@widget.xmission.com (Ron Lenk)
Date: Tue, 5 Mar 1996 17:27:08 -0600 (CST)
From: "Karl Denninger, MCSNet" <karl@mcs.com>
Cc: imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org
In-Reply-To: <199603052017.NAA06046@widget.xmission.com> from "Ron Lenk" at Mar 5, 96 01:17:04 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-stable@freebsd.org
Precedence: bulk

> 
> > Without warning today, the recurrent collapse of -stable with "panic:
> > inconsistent xxx queue" managed to trash my root file-system beyond recovery
> > (/etc et al) and a substantial proportion of anything vaguely near a
> > file-subsystem root directory (i.e. /var, /usr and /home are all separate
> > file-systems and all were damaged to varying degrees). I presume that this
> > was just particularly bad timing as there was significant activity on all of
> > them at that moment (of the order of ~60 transfers second).
> 
> Well, I can tell you that you're not alone in seeing these particular
> problems with -stable and the 2842. I've seen the same types of panics
> and hang conditions with -stable for the last two months. ( since the
> import of the new ahc driver in Jan ) Fortunately, however, I have been
> using a 2.1-RELEASE kernel without incident ( up 15 days right now ),
> so I haven't seen any spectacular filesystem damage.

I have given up on 27xx EISA adapters under FreeBSD.  I get hangs of
different kinds, and a few panics.

1742s and the PCI boards seem to be fine so far.  So long as the PCI
situation holds, we can live with a broken EISA card for *new* machines.

--
--
Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity
Modem: [+1 312 248-0900]     | T1 from $600 monthly; speeds to DS-3 available
Voice: [+1 312 803-MCS1]     | 21 Chicagoland POPs, ISDN, 28.8, much more
Fax: [+1 312 248-9865]       | Email to "info@mcs.net" WWW: http://www.mcs.net/
ISDN - Get it here TODAY!    | Home of Chicago's only FULL Clarinet feed!

From owner-freebsd-stable  Tue Mar  5 15:40:01 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id PAA07282
          for stable-outgoing; Tue, 5 Mar 1996 15:40:01 -0800 (PST)
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA07251
          Tue, 5 Mar 1996 15:39:58 -0800 (PST)
Message-Id: <199603052339.PAA07251@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol
To: Terry Lambert <terry@lambert.org>
cc: imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org
Subject: Re: 2842 and the disappearing file-system :-( 
In-reply-to: Your message of "Tue, 05 Mar 1996 15:57:28 MST."
             <199603052257.PAA09308@phaeton.artisoft.com> 
Date: Tue, 05 Mar 1996 15:39:57 -0800
From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
Sender: owner-stable@FreeBSD.org
Precedence: bulk

>> >> Actually this appears to be a bug in eisaconf as it affects all
>> >> eisa scsi controllers at the moment.  I'm looking into it, but the
>> >> problem is not obvious and doesn't occur in -current.
>> >
>> >He has a VESA controller... brain farts are contagious!
>> 
>> He has a VESA controller that uses an EISA probe and so is
>> also affected.
>
>Ah.  That's broken. 8-(.  This must be a VESA/EISA box for it to
>see the EISA signature and hit the EISA code?

The eisaconf code always probes for eisa ids if it is configured
in your system.  It hasn't caused any conflicts on any system that
I've seen, and since we have at least one device driver that would
have to copy the same probe code in order to work, I decied to make
eisaconf work this way.

>					Terry Lambert
>					terry@lambert.org
>---
>Any opinions in this posting are my own and not those of my present
>or previous employers.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================

From owner-freebsd-stable  Tue Mar  5 16:42:32 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id QAA11292
          for stable-outgoing; Tue, 5 Mar 1996 16:42:32 -0800 (PST)
Received: from freebsd.netcom.com (freebsd.netcom.com [198.211.79.3])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA11286
          for <stable@freebsd.org>; Tue, 5 Mar 1996 16:42:29 -0800 (PST)
Received: by freebsd.netcom.com (8.6.12/SMI-4.1)
	id SAA06065; Tue, 5 Mar 1996 18:46:29 -0600
From: bugs@freebsd.netcom.com (Mark Hittinger)
Message-Id: <199603060046.SAA06065@freebsd.netcom.com>
Subject: Latest sup -stable dies on telnet attempt
To: stable@freebsd.org
Date: Tue, 5 Mar 1996 18:46:28 -0600 (CST)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: owner-stable@freebsd.org
Precedence: bulk


Page fault in kernel mode or silent reboots.

Just sup'ed last night really late and rebuilt.  Saw 5 or 6 mods on the tcp
stuff come in.

I make a ppp connection, things come up.  I telnet, it resolves the name
and attempts to make a connection - *BEWM*.

FYI

Mark Hittinger
Netcom/Dallas
bugs@freebsd.netcom.com

From owner-freebsd-stable  Wed Mar  6 02:29:39 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id CAA07375
          for stable-outgoing; Wed, 6 Mar 1996 02:29:39 -0800 (PST)
Received: from elbereth.blueberry.co.uk ([194.70.52.50])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA07365
          for <stable@freebsd.org>; Wed, 6 Mar 1996 02:29:28 -0800 (PST)
Received: (from nik@localhost) by elbereth.blueberry.co.uk (8.6.12/8.6.12) id KAA02899 for stable@freebsd.org; Wed, 6 Mar 1996 10:26:44 GMT
From: Nik Clayton <nik@blueberry.co.uk>
Message-Id: <199603061026.KAA02899@elbereth.blueberry.co.uk>
Subject: List of sup servers?
To: stable@freebsd.org
Date: Wed, 6 Mar 1996 10:26:43 +0000 (GMT)
X-Mailer: ELM [version 2.4 PL24 ME8a]
Content-Type: text
Sender: owner-stable@freebsd.org
Precedence: bulk

Hi,

Can someone please provide me with a list of sup servers from which
I could sup freebsd-stable?

    http://www.freebsd.org/handbook/handbook202.html#353

suggests looking in /usr/share/examples/sup/README for this list, but that
file doesn't exist on my system.

N
-- 
--+=[ Blueberry Hill                   Blueberry Design                   ]=+--
--+=[ http://www.blueberry.co.uk/      1/9 Chelsea Harbour Design Centre, ]=+--
--+=[ WebMaster@blueberry.co.uk        London, England, SW10 0XE          ]=+--
--+=[            Unix wizardry practiced for fun and profit.              ]ENTP

From owner-freebsd-stable  Wed Mar  6 06:55:03 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id GAA25126
          for stable-outgoing; Wed, 6 Mar 1996 06:55:03 -0800 (PST)
Received: from bsdi.iem.pw.edu.pl (san@bsdi.iem.pw.edu.pl [148.81.77.12])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA25115
          for <freebsd-stable@freefall.freebsd.org>; Wed, 6 Mar 1996 06:54:56 -0800 (PST)
Received: (san@localhost) by bsdi.iem.pw.edu.pl (8.6.12/8.6.12 ) id PAA27778 for freebsd-stable@freefall.freebsd.org; Wed, 6 Mar 1996 15:54:40 +0100
Date: Wed, 6 Mar 1996 15:54:40 +0100
From: Andrzej Tobola <san@iem.pw.edu.pl>
Message-Id: <199603061454.PAA27778@bsdi.iem.pw.edu.pl>
To: freebsd-stable@freefall.freebsd.org
Subject: ps problem
Sender: owner-stable@FreeBSD.ORG
Precedence: bulk


With the latest -stable (I rebuild kernel+libs+ps):

tmp% ps awxl
  UID   PID  PPID CPU PRI NI   VSZ  RSS WCHAN  STAT  TT       TIME COMMAND
    0     0     0   0 -18  0     0    0 sched  DLs   ??    0:00.00  (swapper)
    0     1     0   0  10  0   440   76 wait   Is    ??    0:00.03  (init)
    0     2     0   0 -18  0     0   12 psleep DL    ??    0:00.22  (pagedaemon)
    0     3     0   0  28  0     0   12 psleep DL    ??    0:00.14  (vmdaemon)
    0     4     0   0  -6  0     0   12 update DL    ??    0:00.58  (update)
    0    22     1  14  18  0   216    0 pause  IWs   ??    0:00.01  (adjkerntz)
    0    82     1   0   2  0   184  252 select Is    ??    0:00.15  (syslogd)
    0    90     1 255   2 -12   480  524 select S<s   ??    0:00.35  (xntpd)
    1    94     1   0   2  0   176  172 select Ss    ??    0:00.08  (portmap)
    0   102     1   7   2  0   452    0 select IWs   ??    0:00.01  (mountd)
    0   104     1  14   2  0   240    0 netcon IWs   ??    0:00.01  (nfsd)
    0   106   104  14   2  0   232    0 nfsd   IW    ??    0:00.00  (nfsd)

                                                                    ^^^^^^^^......!!!

-----
at

From owner-freebsd-stable  Wed Mar  6 07:38:59 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id HAA28341
          for stable-outgoing; Wed, 6 Mar 1996 07:38:59 -0800 (PST)
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA28332
          for <stable>; Wed, 6 Mar 1996 07:38:56 -0800 (PST)
Message-Id: <199603061538.HAA28332@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol
To: stable
Subject: Eisaconf woes
Date: Wed, 06 Mar 1996 07:38:55 -0800
From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
Sender: owner-stable@FreeBSD.ORG
Precedence: bulk

Can those of you have problem with hangs in newbuf or panics about
inconsistent buffer queues while using EISA (or EISA like) devices
please try the following patch?  I found this while looking at differences
between -current and -stable.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================

Index: i386/isa/isa.c
===================================================================
RCS file: /usr/cvs/src/sys/i386/isa/isa.c,v
retrieving revision 1.50.4.2
diff -c -r1.50.4.2 isa.c
*** isa.c	1996/01/13 10:46:49	1.50.4.2
--- isa.c	1996/03/06 15:38:21
***************
*** 920,925 ****
--- 920,926 ----
  		if (intr==2) continue;
  		maskptr = intr_mptr[intr];
  		if (!maskptr) continue;
+ 		*maskptr |= 1 << intr;
  		mask = *maskptr;
  		if (mask != intr_mask[intr]) {
  #if 0

From owner-freebsd-stable  Wed Mar  6 09:24:29 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id JAA06289
          for stable-outgoing; Wed, 6 Mar 1996 09:24:29 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA06268
          Wed, 6 Mar 1996 09:24:24 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA11164; Wed, 6 Mar 1996 10:19:46 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199603061719.KAA11164@phaeton.artisoft.com>
Subject: Re: 2842 and the disappearing file-system :-(
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Wed, 6 Mar 1996 10:19:46 -0700 (MST)
Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org
In-Reply-To: <199603052339.PAA07251@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 5, 96 03:39:57 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.org
Precedence: bulk

> >> >> Actually this appears to be a bug in eisaconf as it affects all
> >> >> eisa scsi controllers at the moment.  I'm looking into it, but the
> >> >> problem is not obvious and doesn't occur in -current.
> >> >
> >> >He has a VESA controller... brain farts are contagious!
> >> 
> >> He has a VESA controller that uses an EISA probe and so is
> >> also affected.
> >
> >Ah.  That's broken. 8-(.  This must be a VESA/EISA box for it to
> >see the EISA signature and hit the EISA code?
> 
> The eisaconf code always probes for eisa ids if it is configured
> in your system.  It hasn't caused any conflicts on any system that
> I've seen, and since we have at least one device driver that would
> have to copy the same probe code in order to work, I decied to make
> eisaconf work this way.

So if it checked for the signature word and didn't "eisaconf" without
it, and the probe were duped (or multiply referenced, anyway), then
his problem would go away?

I think EISA probing ought to be limited to EISA bus machines.  Call
me strange.  8-).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-stable  Wed Mar  6 10:00:34 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA09035
          for stable-outgoing; Wed, 6 Mar 1996 10:00:34 -0800 (PST)
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA09029
          Wed, 6 Mar 1996 10:00:31 -0800 (PST)
Message-Id: <199603061800.KAA09029@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol
To: Terry Lambert <terry@lambert.org>
cc: imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org
Subject: Re: 2842 and the disappearing file-system :-( 
In-reply-to: Your message of "Wed, 06 Mar 1996 10:19:46 MST."
             <199603061719.KAA11164@phaeton.artisoft.com> 
Date: Wed, 06 Mar 1996 10:00:31 -0800
From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
Sender: owner-stable@FreeBSD.org
Precedence: bulk

>So if it checked for the signature word and didn't "eisaconf" without
>it, and the probe were duped (or multiply referenced, anyway), then
>his problem would go away?

Depends on if the bug were duped too.   I think I found the real
problem anyway, and it wasn't directly eisaconf's fault.
Update_intr_masks() was broken in stable or its behavior changed
in current, so that when the code was ported back to stable, it
wasn't properly registering its interrupt.

>I think EISA probing ought to be limited to EISA bus machines.  Call
>me strange.  8-).

I think that using anything other than eisaconf for devices that
look and behave like EISA devices is a waste of code and a cludge.
Forcing the 2842 to use our ISA registration routines is certainly
not a better alternative.

>
>
>					Terry Lambert
>					terry@lambert.org
>---
>Any opinions in this posting are my own and not those of my present
>or previous employers.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================

From owner-freebsd-stable  Wed Mar  6 10:02:10 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA09219
          for stable-outgoing; Wed, 6 Mar 1996 10:02:10 -0800 (PST)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.54])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA09190
          Wed, 6 Mar 1996 10:01:58 -0800 (PST)
Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.6.12/8.6.9) id KAA00222; Wed, 6 Mar 1996 10:01:13 -0800
From: "Steven G. Kargl" <sgk@troutmask.apl.washington.edu>
Message-Id: <199603061801.KAA00222@troutmask.apl.washington.edu>
Subject: patch appears to work
To: gibbs@freebsd.org, freebsd-stable@freebsd.org
Date: Wed, 6 Mar 1996 10:01:13 -0800 (PST)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@freebsd.org
Precedence: bulk

Justin,

Your patch to isa.c appears to work.   My EISA system has 
a 1742, 3c509, 24 MB ram, and 61 MB.  The test kernel and
normal configured kernel both pass my test for stability.

As you may recall, without the isa.c patch  I could cause
the system hang or getnewbuf panic with "iozone 32" within
minutes of booting a kernel.  I am happy to report the
patch appears to clear up the problem.

BTW, I am probing the eisa bus prior to the isa.

-- 
Steven G. Kargl     | Phone: 206-685-4677 |
Applied Physics Lab | Fax:   206-543-6785 |
Univ. of Washington |---------------------|
1013 NE 40th St     | FreeBSD 2.x-stable  |
Seattle, WA 98105   |---------------------|

From owner-freebsd-stable  Wed Mar  6 10:07:39 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA09523
          for stable-outgoing; Wed, 6 Mar 1996 10:07:39 -0800 (PST)
Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA09518
          for <stable@freebsd.org>; Wed, 6 Mar 1996 10:07:36 -0800 (PST)
Received: (from imb@localhost)
	by asstdc.scgt.oz.au (8.6.12/BSD4.4)
	id FAA12964; Thu, 7 Mar 1996 05:07:24 +1100
From: michael butler <imb@scgt.oz.au>
Message-Id: <199603061807.FAA12964@asstdc.scgt.oz.au>
Subject: Re: Eisaconf woes
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Thu, 7 Mar 1996 05:07:24 +1100 (EST)
Cc: stable@freebsd.org
In-Reply-To: <199603061538.HAA28332@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 6, 96 07:38:55 am
X-Mailer: ELM [version 2.4 PL24beta]
Content-Type: text
Sender: owner-stable@freebsd.org
Precedence: bulk

> Can those of you have problem with hangs in newbuf or panics about
> inconsistent buffer queues while using EISA (or EISA like) devices please
> try the following patch?  I found this while looking at differences
> between -current and -stable.

This looks _really_ promising .. *thanks* .. I'll have it installed as
soon as I can get this overview expiry to terminate "nicely" :-),

	michael

From owner-freebsd-stable  Wed Mar  6 10:42:03 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA12616
          for stable-outgoing; Wed, 6 Mar 1996 10:42:03 -0800 (PST)
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA12608
          Wed, 6 Mar 1996 10:41:59 -0800 (PST)
Message-Id: <199603061841.KAA12608@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol
To: michael butler <imb@scgt.oz.au>
cc: stable@freebsd.org
Subject: Re: Eisaconf woes 
In-reply-to: Your message of "Thu, 07 Mar 1996 05:07:24 +1100."
             <199603061807.FAA12964@asstdc.scgt.oz.au> 
Date: Wed, 06 Mar 1996 10:41:59 -0800
From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
Sender: owner-stable@freebsd.org
Precedence: bulk

>> Can those of you have problem with hangs in newbuf or panics about
>> inconsistent buffer queues while using EISA (or EISA like) devices please
>> try the following patch?  I found this while looking at differences
>> between -current and -stable.
>
>This looks _really_ promising .. *thanks* .. I'll have it installed as
>soon as I can get this overview expiry to terminate "nicely" :-),
>
>	michael

I've already recieved one success story.  Hopefully it will work
for you too.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================

From owner-freebsd-stable  Wed Mar  6 11:48:03 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id LAA17665
          for stable-outgoing; Wed, 6 Mar 1996 11:48:03 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA17596
          Wed, 6 Mar 1996 11:47:58 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA11641; Wed, 6 Mar 1996 12:43:21 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199603061943.MAA11641@phaeton.artisoft.com>
Subject: Re: 2842 and the disappearing file-system :-(
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Wed, 6 Mar 1996 12:43:21 -0700 (MST)
Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG
In-Reply-To: <199603061800.KAA09029@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 6, 96 10:00:31 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.ORG
Precedence: bulk

> >I think EISA probing ought to be limited to EISA bus machines.  Call
> >me strange.  8-).
> 
> I think that using anything other than eisaconf for devices that
> look and behave like EISA devices is a waste of code and a cludge.
> Forcing the 2842 to use our ISA registration routines is certainly
> not a better alternative.

What about adding a VLB registration phase?

There needs to be a disctinction between need for bounce buffers
anyway... You call the VLB probe if the EISA tag isn't present.

This unkludges a lot of things, including the things that are
kludged by the EISA ID check on non-EISA boxes.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-stable  Wed Mar  6 12:33:15 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA21691
          for stable-outgoing; Wed, 6 Mar 1996 12:33:15 -0800 (PST)
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA21684
          Wed, 6 Mar 1996 12:33:13 -0800 (PST)
Message-Id: <199603062033.MAA21684@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol
To: Terry Lambert <terry@lambert.org>
cc: imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG
Subject: Re: 2842 and the disappearing file-system :-( 
In-reply-to: Your message of "Wed, 06 Mar 1996 12:43:21 MST."
             <199603061943.MAA11641@phaeton.artisoft.com> 
Date: Wed, 06 Mar 1996 12:33:13 -0800
From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
Sender: owner-stable@FreeBSD.ORG
Precedence: bulk

>> >I think EISA probing ought to be limited to EISA bus machines.  Call
>> >me strange.  8-).
>> 
>> I think that using anything other than eisaconf for devices that
>> look and behave like EISA devices is a waste of code and a cludge.
>> Forcing the 2842 to use our ISA registration routines is certainly
>> not a better alternative.
>
>What about adding a VLB registration phase?

Give me a break!  VLB is isa with a 32bit bus as far as probes
go.  I don't know of another VLB card that uses an eisa probe.  In
fact, the probes for VLB devices are usually identical to their
ISA cousins.  So, we may as well use ISA probes for VLB devices 
in the general case.

>There needs to be a disctinction between need for bounce buffers
>anyway... You call the VLB probe if the EISA tag isn't present.

Not at all.  There are EISA motherboards with broken 32bit DMA,
There are VL motherboards with broken 32bit DMA.  There are VL
cards with broken 32bit DMA.  There are EISA cards with broken
32bit DMA.  You can't identify if a VLB motherboard is present, so
having another special VL probe doesn't buy you anything.  Each
device driver is also capable ofenableing bounce buffers if it can
detect broken hardware and the eisa module could even set a flag
for all EISA devices to look at if it had a table of broken
motherboard IDs.  Look at how the bt driver deals with this  to
see exactly why this is not even relevent to this discussion.

>This unkludges a lot of things, including the things that are
>kludged by the EISA ID check on non-EISA boxes.

How are they kludged?  I haven't seen a single report of eisaconf
without detected devices causing problems in a system.  Furthermore,
if you don't have a 2842 or and eisa machine, you can disable the
eisa0 device in your config file.  If you do have a 2842, you'd
have to read the same bytes of the I/O address space, so it buys
you nothing to have a separate probe for it.

>
>
>					Terry Lambert
>					terry@lambert.org
>---
>Any opinions in this posting are my own and not those of my present
>or previous employers.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================

From owner-freebsd-stable  Wed Mar  6 13:21:45 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id NAA25667
          for stable-outgoing; Wed, 6 Mar 1996 13:21:45 -0800 (PST)
Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA25654
          for <freebsd-stable@freefall.freebsd.org>; Wed, 6 Mar 1996 13:21:39 -0800 (PST)
Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id HAA26287; Thu, 7 Mar 1996 07:57:38 +1030
From: Michael Smith <msmith@atrad.adelaide.edu.au>
Message-Id: <199603062127.HAA26287@genesis.atrad.adelaide.edu.au>
Subject: Re: ps problem
To: san@iem.pw.edu.pl (Andrzej Tobola)
Date: Thu, 7 Mar 1996 07:57:37 +1030 (CST)
Cc: freebsd-stable@freefall.freebsd.org
In-Reply-To: <199603061454.PAA27778@bsdi.iem.pw.edu.pl> from "Andrzej Tobola" at Mar 6, 96 03:54:40 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.ORG
Precedence: bulk

Andrzej Tobola stands accused of saying:
> 
> 
> With the latest -stable (I rebuild kernel+libs+ps):

You haven't rebuilt libkvm.  IMHO, this should have been more loudly 
announced, but there was plenty of warning given.

Perhaps there could be a sup MOTD that's emitted by sup when it connects
to the server?  8)

> tmp% ps awxl
>   UID   PID  PPID CPU PRI NI   VSZ  RSS WCHAN  STAT  TT       TIME COMMAND
>     0     0     0   0 -18  0     0    0 sched  DLs   ??    0:00.00  (swapper)
...
> at

-- 
]] Mike Smith, Software Engineer        msmith@atrad.adelaide.edu.au    [[
]] Genesis Software                     genesis@atrad.adelaide.edu.au   [[
]] High-speed data acquisition and      (GSM mobile) 0411-222-496       [[
]] realtime instrument control          (ph/fax)  +61-8-267-3039        [[
]] Collector of old Unix hardware.      "Where are your PEZ?" The Tick  [[

From owner-freebsd-stable  Wed Mar  6 14:59:56 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id OAA06027
          for stable-outgoing; Wed, 6 Mar 1996 14:59:56 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA06007
          Wed, 6 Mar 1996 14:59:51 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA11994; Wed, 6 Mar 1996 15:54:48 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199603062254.PAA11994@phaeton.artisoft.com>
Subject: Re: 2842 and the disappearing file-system :-(
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Wed, 6 Mar 1996 15:54:48 -0700 (MST)
Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG
In-Reply-To: <199603062033.MAA21684@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 6, 96 12:33:13 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.ORG
Precedence: bulk

> How are they kludged?  I haven't seen a single report of eisaconf
> without detected devices causing problems in a system.  Furthermore,
> if you don't have a 2842 or and eisa machine, you can disable the
> eisa0 device in your config file.  If you do have a 2842, you'd
> have to read the same bytes of the I/O address space, so it buys
> you nothing to have a separate probe for it.

Maybe I'm missing something.

Why do you have to have a seperate probe?

Why can't you use the same probe routine address in two "driver instances"?

And wouldn't this fix the interrrupt attach problem introduced by the
eisaconf code in the VLB Adaptec case?

You keep saying you need to duplicate cade -- I don't see it.  I see
that there is a need to duplicate ~32 bytes of data structure to get
an EISA and non-EISA device instance.  Tell me why Im wrong...


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-stable  Wed Mar  6 15:42:45 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id PAA10392
          for stable-outgoing; Wed, 6 Mar 1996 15:42:45 -0800 (PST)
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA10384
          Wed, 6 Mar 1996 15:42:39 -0800 (PST)
Message-Id: <199603062342.PAA10384@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol
To: Terry Lambert <terry@lambert.org>
cc: imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG
Subject: Re: 2842 and the disappearing file-system :-( 
In-reply-to: Your message of "Wed, 06 Mar 1996 15:54:48 MST."
             <199603062254.PAA11994@phaeton.artisoft.com> 
Date: Wed, 06 Mar 1996 15:42:39 -0800
From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
Sender: owner-stable@FreeBSD.ORG
Precedence: bulk

>> How are they kludged?  I haven't seen a single report of eisaconf
>> without detected devices causing problems in a system.  Furthermore,
>> if you don't have a 2842 or and eisa machine, you can disable the
>> eisa0 device in your config file.  If you do have a 2842, you'd
>> have to read the same bytes of the I/O address space, so it buys
>> you nothing to have a separate probe for it.
>
>Maybe I'm missing something.

I would guess you didn't even look.  Have you looked at eisaconf.c?
or aic7770.c?

>Why do you have to have a seperate probe?

RTSL

>Why can't you use the same probe routine address in two "driver instances"?

Eisaconf doesn't work that way at all.

>And wouldn't this fix the interrrupt attach problem introduced by the
>eisaconf code in the VLB Adaptec case?

Because the bug wasn't even in eisaconf.  It was in i386/isa/isa.c.

>You keep saying you need to duplicate cade -- I don't see it.  I see
>that there is a need to duplicate ~32 bytes of data structure to get
>an EISA and non-EISA device instance.  Tell me why Im wrong...

Right now the code for dealing with the 2842 and the 2742 is one
and the same.  To do what you propose would mean adding an isa probe
and doing the same looping through the slots that the eisaconf code does
already, although the 2842 probe would have to do it once for each
card probe instead of just creating the device nodes once like the 
eisaconf code does.  There is simply no reason to break the probe up.
It only adds complexity and code.

>
>
>					Regards,
>					Terry Lambert
>					terry@lambert.org
>---
>Any opinions in this posting are my own and not those of my present
>or previous employers.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================

From owner-freebsd-stable  Wed Mar  6 17:39:14 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id RAA23168
          for stable-outgoing; Wed, 6 Mar 1996 17:39:14 -0800 (PST)
Received: from asstdc.scgt.oz.au (asstdc.scgt.oz.au [202.14.234.65])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA23077
          for <stable@freebsd.org>; Wed, 6 Mar 1996 17:38:34 -0800 (PST)
Received: (from imb@localhost)
	by asstdc.scgt.oz.au (8.6.12/BSD4.4)
	id MAA00738; Thu, 7 Mar 1996 12:37:48 +1100
From: michael butler <imb@scgt.oz.au>
Message-Id: <199603070137.MAA00738@asstdc.scgt.oz.au>
Subject: Re: Eisaconf woes
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Thu, 7 Mar 1996 12:37:47 +1100 (EST)
Cc: stable@freebsd.org
In-Reply-To: <199603061841.KAA12608@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 6, 96 10:41:59 am
X-Mailer: ELM [version 2.4 PL24beta]
Content-Type: text
Sender: owner-stable@freebsd.org
Precedence: bulk

Justin T. Gibbs writes:

> I've already recieved one success story.  Hopefully it will work
> for you too.

Wouldn't you know it .. the local news feed's disk has filled up again so I
don't have a lot of traffic right now :-(. 

However, with the (comparatively light) mail and web-cache load it appears
to be quite solid now, certainly more so than before. Hopefully, it won't be
another 5 days before metro "un-glues" itself .. <sigh>

Thanks again for the fix, it's looking good,

	michael

From owner-freebsd-stable  Thu Mar  7 00:17:13 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id AAA17815
          for stable-outgoing; Thu, 7 Mar 1996 00:17:13 -0800 (PST)
Received: from zodiak.tu.kielce.pl (andrzej@zodiak.tu.kielce.pl [193.59.4.34])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA17796
          for <freebsd-stable@freebsd.com>; Thu, 7 Mar 1996 00:16:48 -0800 (PST)
Received: (from andrzej@localhost) by zodiak.tu.kielce.pl (8.6.12/8.6.9) id JAA01179 for freebsd-stable@freebsd.com; Thu, 7 Mar 1996 09:15:41 +0100
From: Andrzej Szydlo <andrzej@zodiak.tu.kielce.pl>
Message-Id: <199603070815.JAA01179@zodiak.tu.kielce.pl>
To: freebsd-stable@freebsd.com
Date: Thu, 7 Mar 1996 09:15:38 +0100 (MET)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.ORG
Precedence: bulk


subscribe

From owner-freebsd-stable  Thu Mar  7 05:29:34 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id FAA07347
          for stable-outgoing; Thu, 7 Mar 1996 05:29:34 -0800 (PST)
Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA07341
          for <stable@freebsd.org>; Thu, 7 Mar 1996 05:29:25 -0800 (PST)
Received: (from imb@localhost)
	by asstdc.scgt.oz.au (8.6.12/BSD4.4)
	id AAA10562; Fri, 8 Mar 1996 00:29:15 +1100
From: michael butler <imb@scgt.oz.au>
Message-Id: <199603071329.AAA10562@asstdc.scgt.oz.au>
Subject: Re: Eisaconf woes
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Fri, 8 Mar 1996 00:29:15 +1100 (EST)
Cc: stable@freebsd.org
In-Reply-To: <199603061841.KAA12608@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 6, 96 10:41:59 am
X-Mailer: ELM [version 2.4 PL24beta]
Content-Type: text
Sender: owner-stable@freebsd.org
Precedence: bulk

> >This looks _really_ promising .. *thanks* .. I'll have it installed as
> >soon as I can get this overview expiry to terminate "nicely" :-),

> I've already recieved one success story.  Hopefully it will work
> for you too.

If you haven't already, commit it .. I have two (similarly configured)
machines (2842 rev C & 2842 rev E) now running with this patch and none of
the SCSI-related problems previously experienced have recurred. -stable is
once more, thanks ! :-)

	michael

From owner-freebsd-stable  Thu Mar  7 06:12:21 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id GAA09708
          for stable-outgoing; Thu, 7 Mar 1996 06:12:21 -0800 (PST)
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA09703
          Thu, 7 Mar 1996 06:12:19 -0800 (PST)
Message-Id: <199603071412.GAA09703@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol
To: michael butler <imb@scgt.oz.au>
cc: stable@freebsd.org
Subject: Re: Eisaconf woes 
In-reply-to: Your message of "Fri, 08 Mar 1996 00:29:15 +1100."
             <199603071329.AAA10562@asstdc.scgt.oz.au> 
Date: Thu, 07 Mar 1996 06:12:19 -0800
From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
Sender: owner-stable@freebsd.org
Precedence: bulk

>> >This looks _really_ promising .. *thanks* .. I'll have it installed as
>> >soon as I can get this overview expiry to terminate "nicely" :-),
>
>> I've already recieved one success story.  Hopefully it will work
>> for you too.
>
>If you haven't already, commit it .. I have two (similarly configured)
>machines (2842 rev C & 2842 rev E) now running with this patch and none of
>the SCSI-related problems previously experienced have recurred. -stable is
>once more, thanks ! :-)
>
>	michael

Bruce reviewed and committed it for me.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================

From owner-freebsd-stable  Thu Mar  7 08:43:59 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id IAA20428
          for stable-outgoing; Thu, 7 Mar 1996 08:43:59 -0800 (PST)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.54])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA20423
          for <stable@FreeBSD.ORG>; Thu, 7 Mar 1996 08:43:55 -0800 (PST)
Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.6.12/8.6.9) id IAA21167; Thu, 7 Mar 1996 08:43:05 -0800
From: "Steven G. Kargl" <sgk@troutmask.apl.washington.edu>
Message-Id: <199603071643.IAA21167@troutmask.apl.washington.edu>
Subject: Re: Eisaconf woes
To: imb@scgt.oz.au (michael butler)
Date: Thu, 7 Mar 1996 08:43:05 -0800 (PST)
Cc: gibbs@freefall.freebsd.org, stable@FreeBSD.ORG
In-Reply-To: <199603070137.MAA00738@asstdc.scgt.oz.au> from "michael butler" at Mar 7, 96 12:37:47 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.ORG
Precedence: bulk

According to michael butler:
> 
> Justin T. Gibbs writes:
> 
> > I've already recieved one success story.  Hopefully it will work
> > for you too.
> 
> Wouldn't you know it .. the local news feed's disk has filled up again so I
> don't have a lot of traffic right now :-(. 
> 
> However, with the (comparatively light) mail and web-cache load it appears
> to be quite solid now, certainly more so than before. Hopefully, it won't be
> another 5 days before metro "un-glues" itself .. <sigh>
> 
> Thanks again for the fix, it's looking good,
> 

I did a "make world" to stress test my patched system.  I experienced
NO burps, sighs or crashes.

-- 
Steven G. Kargl     | Phone: 206-685-4677 |
Applied Physics Lab | Fax:   206-543-6785 |
Univ. of Washington |---------------------|
1013 NE 40th St     | FreeBSD 2.x-stable  |
Seattle, WA 98105   |---------------------|

From owner-freebsd-stable  Thu Mar  7 08:46:12 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id IAA20618
          for stable-outgoing; Thu, 7 Mar 1996 08:46:12 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA20600
          Thu, 7 Mar 1996 08:46:07 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA14037; Thu, 7 Mar 1996 09:41:17 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199603071641.JAA14037@phaeton.artisoft.com>
Subject: Re: 2842 and the disappearing file-system :-(
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Thu, 7 Mar 1996 09:41:16 -0700 (MST)
Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG
In-Reply-To: <199603062342.PAA10384@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 6, 96 03:42:39 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.ORG
Precedence: bulk

> >> How are they kludged?  I haven't seen a single report of eisaconf
> >> without detected devices causing problems in a system.  Furthermore,
> >> if you don't have a 2842 or and eisa machine, you can disable the
> >> eisa0 device in your config file.  If you do have a 2842, you'd
> >> have to read the same bytes of the I/O address space, so it buys
> >> you nothing to have a separate probe for it.
> >
> >Maybe I'm missing something.
> 
> I would guess you didn't even look.  Have you looked at eisaconf.c?
> or aic7770.c?

You have guessed wrong (don't worry, this is the usual guess, and it's
usually wrong).

> >Why do you have to have a seperate probe?
> 
> RTSL

The *WORST* you would *POSSIBLY* need is an EISA nad an ISA stub
routine.  I *STILL* do not think EISA ID's should be looked for if
the system doesn't claim to be an EISA bus.

We have *one* example if an EISA/VLB driver where this, through the
savings in code necessary to abstract the differences between the
EISA and ISA configurations (which should be the same interface anyway).

And that example is causing problems for people.

> >Why can't you use the same probe routine address in two "driver instances"?
> 
> Eisaconf doesn't work that way at all.

You are (intentionally?) missing the point.

> >And wouldn't this fix the interrrupt attach problem introduced by the
> >eisaconf code in the VLB Adaptec case?
> 
> Because the bug wasn't even in eisaconf.  It was in i386/isa/isa.c.

8-P.

> >You keep saying you need to duplicate cade -- I don't see it.  I see
> >that there is a need to duplicate ~32 bytes of data structure to get
> >an EISA and non-EISA device instance.  Tell me why Im wrong...
> 
> Right now the code for dealing with the 2842 and the 2742 is one
> and the same.  To do what you propose would mean adding an isa probe
> and doing the same looping through the slots that the eisaconf code does
> already, although the 2842 probe would have to do it once for each
> card probe instead of just creating the device nodes once like the 
> eisaconf code does.  There is simply no reason to break the probe up.
> It only adds complexity and code.

1)	The ISA code, unless it's PnP, can't distinguish slots, so it
	would have a damn hard time requiring looping through them.

2)	This is a VLB card, not an ISA card.  I would not suggest
	calling the probe from ISA any more than I would suggest
	calling it from EISA.  It is *NOT* an EISA device.

3)	The ISA code needs to "create device nodes" in a similar
	fashion to EISA for PnP.  This is a case of confusing ISA
	devices that can be mapped by a configuration manager with
	those that can't.  Read the Microsoft PnP document.

What I suggest is calling the probe in multiple locations with two
stub routines: one EISA for eisaconf and one VLB (ISA, barring a
fixed handling of VLB).  If you want to call this "adding an ISA probe",
fine.  It's nowhere near the same order of effort as doing that, IMO.

I can't fault you on the complexity argument: it will add a bit of
logical complexity in the process of providing a logical abstraction.
On the other hand, the abstraction can be made orthoganal so that it
is easier to document and program to for other devices that can then
seperate PnP mapping from driver attachment (substituting ISA PnP for
probing in the same way eisaconf substitutes slot iteration for
probing), so it seems like an acceptable tradeoff to me.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-stable  Thu Mar  7 10:05:58 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA26162
          for stable-outgoing; Thu, 7 Mar 1996 10:05:58 -0800 (PST)
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA26152
          Thu, 7 Mar 1996 10:05:55 -0800 (PST)
Message-Id: <199603071805.KAA26152@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol
To: Terry Lambert <terry@lambert.org>
cc: imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG
Subject: Re: 2842 and the disappearing file-system :-( 
In-reply-to: Your message of "Thu, 07 Mar 1996 09:41:16 MST."
             <199603071641.JAA14037@phaeton.artisoft.com> 
Date: Thu, 07 Mar 1996 10:05:55 -0800
From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
Sender: owner-stable@FreeBSD.ORG
Precedence: bulk

>> I would guess you didn't even look.  Have you looked at eisaconf.c?
>> or aic7770.c?
>
>You have guessed wrong (don't worry, this is the usual guess, and it's
>usually wrong).

Perhaps you read it last night, but you certainly acted as if you
thought eisaconf worked just like isa_configure() in all of your mail
yesturday.

>
>> >Why do you have to have a seperate probe?
>> 
>> RTSL
>
>The *WORST* you would *POSSIBLY* need is an EISA nad an ISA stub
>routine.  I *STILL* do not think EISA ID's should be looked for if
>the system doesn't claim to be an EISA bus.

An eisa and isa stub routine to what? The routine that collects
the IDs?  The routine that matches drivers to ids?  The routinesx
for irq/ioport, etc registration?  It sounds like you want me to
duplicate the probe in aic7770.c, but prepend everything with isa_
instead of eisa_.  All for one card that acts just like an eisa
card?  What a waste of code and effort.

Most isa cards don't care about the eisa ids, so why create yet
another interface to them for the few isa cards that do.  No matter
your aversion to looking for eisa ids in a non eisa machine, it
will have to happen  regardless if you have a 2842 in your machine.
If you don't like it, or don't need it, disable eisa0.

>We have *one* example if an EISA/VLB driver where this, through the
>savings in code necessary to abstract the differences between the
>EISA and ISA configurations (which should be the same interface anyway).
>
>And that example is causing problems for people.

I know of one person who has a conceptual problem with this approach(you).
Show me one person experiencing actual failures after appling the
patch I posted yesturday.

>
>> >Why can't you use the same probe routine address in two "driver instances"?
>> 
>> Eisaconf doesn't work that way at all.
>
>You are (intentionally?) missing the point.

You claim it doesn't add more code by saying I can call the same functions.
I'm saying I can't.  How am I missing the point.

>
>> >And wouldn't this fix the interrrupt attach problem introduced by the
>> >eisaconf code in the VLB Adaptec case?
>> 
>> Because the bug wasn't even in eisaconf.  It was in i386/isa/isa.c.
>
>8-P.

I think everyone who finds a bug and fixes it should get such treatment.

>1)	The ISA code, unless it's PnP, can't distinguish slots, so it
>	would have a damn hard time requiring looping through them.

You know as well as I do that the eisa slot locations are fixed
at 0xz000 for z 0-16.  How do you think the eisaconf code finds the eisa ids?
I don't see how this is relevent (again).

>2)	This is a VLB card, not an ISA card.  I would not suggest
>	calling the probe from ISA any more than I would suggest
>	calling it from EISA.  It is *NOT* an EISA device.

What features does VLB have that make it of any use to differentiate
between VLB and ISA probes?

>3)	The ISA code needs to "create device nodes" in a similar
>	fashion to EISA for PnP.  This is a case of confusing ISA
>	devices that can be mapped by a configuration manager with
>	those that can't.  Read the Microsoft PnP document.

It does need to create nodes, but does that mean that the ISA code 
bperforms a PNP probe and then scans the eisa slot space just to satisfy the
2842?

>What I suggest is calling the probe in multiple locations with two
>stub routines: one EISA for eisaconf and one VLB (ISA, barring a
>fixed handling of VLB).  If you want to call this "adding an ISA probe",
>fine.  It's nowhere near the same order of effort as doing that, IMO.

What probe routine?  Eisa_match?

>I can't fault you on the complexity argument: it will add a bit of
>logical complexity in the process of providing a logical abstraction.
>On the other hand, the abstraction can be made orthoganal so that it
>is easier to document and program to for other devices that can then
>seperate PnP mapping from driver attachment (substituting ISA PnP for
>probing in the same way eisaconf substitutes slot iteration for
>probing), so it seems like an acceptable tradeoff to me.
>

I disagree.

>
>					Regards,
>					Terry Lambert
>					terry@lambert.org
>---
>Any opinions in this posting are my own and not those of my present
>or previous employers.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================

From owner-freebsd-stable  Thu Mar  7 12:42:47 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA06774
          for stable-outgoing; Thu, 7 Mar 1996 12:42:47 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA06754
          Thu, 7 Mar 1996 12:42:38 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA14706; Thu, 7 Mar 1996 13:36:16 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199603072036.NAA14706@phaeton.artisoft.com>
Subject: Re: 2842 and the disappearing file-system :-(
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Thu, 7 Mar 1996 13:36:15 -0700 (MST)
Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG
In-Reply-To: <199603071805.KAA26152@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 7, 96 10:05:55 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.ORG
Precedence: bulk

> >> I would guess you didn't even look.  Have you looked at eisaconf.c?
> >> or aic7770.c?
> >
> >You have guessed wrong (don't worry, this is the usual guess, and it's
> >usually wrong).
> 
> Perhaps you read it last night, but you certainly acted as if you
> thought eisaconf worked just like isa_configure() in all of your mail
> yesturday.

I don't thin so, Quickstraw.

> >The *WORST* you would *POSSIBLY* need is an EISA nad an ISA stub
> >routine.  I *STILL* do not think EISA ID's should be looked for if
> >the system doesn't claim to be an EISA bus.
> 
> An eisa and isa stub routine to what? The routine that collects
> the IDs?  The routine that matches drivers to ids?  The routinesx
> for irq/ioport, etc registration?  It sounds like you want me to
> duplicate the probe in aic7770.c, but prepend everything with isa_
> instead of eisa_.  All for one card that acts just like an eisa
> card?  What a waste of code and effort.

No; I want a dup of the EISA process in the ISA PnP space so that it's
just a case of making a reference to the routines (and *remove* the
"eisa_" designations entirely).

> Most isa cards don't care about the eisa ids, so why create yet
> another interface to them for the few isa cards that do.  No matter
> your aversion to looking for eisa ids in a non eisa machine, it
> will have to happen  regardless if you have a 2842 in your machine.
> If you don't like it, or don't need it, disable eisa0.

That's just the 2842, and it's an ISA driver configuration architecture
problem with the ISA code.

At the very least, we should admit that looking for EISA stuff on a
non-EISA machine is a kludge.

[ ... ]

> I know of one person who has a conceptual problem with this approach(you).

Well, it doesn't seem that many people are thinking in terms of a unified
configuration manager ala Windows95 and WindowsNT.  I expect the number
of people doing so to increase over time as people desire better
autoconfiguration out of FreeBSD.

> Show me one person experiencing actual failures after appling the
> patch I posted yesturday.

The number of people running VLB is ver small... you have given me a
very restricted search space with your demand.

> >You are (intentionally?) missing the point.
> 
> You claim it doesn't add more code by saying I can call the same functions.
> I'm saying I can't.  How am I missing the point.

The point is you *should* be *able* to call the same functions for ISA,
and for PnP, which uses non-invasive probing (unless you have an old
IBM manufactured parallel port card), you *can*.

> >1)	The ISA code, unless it's PnP, can't distinguish slots, so it
> >	would have a damn hard time requiring looping through them.
> 
> You know as well as I do that the eisa slot locations are fixed
> at 0xz000 for z 0-16.  How do you think the eisaconf code finds the eisa ids?
> I don't see how this is relevent (again).

This is a *card* problem, not a generic problem resolved for anthing
other than the Adaptec card by calling the EISA code.

> >2)	This is a VLB card, not an ISA card.  I would not suggest
> >	calling the probe from ISA any more than I would suggest
> >	calling it from EISA.  It is *NOT* an EISA device.
> 
> What features does VLB have that make it of any use to differentiate
> between VLB and ISA probes?

A)	Default settings for driver configurable bus-on times, since VLB
	steals DRAM refresh cycles.  VLB on time needs to be agregated
	and adjusted *down* where necessary.

B)	Use of bounce buffers on bus mastering VLB cards other than
	the *one* detected by the EISA probe by virtue of it's "EISA"
	nature.

As you pointed out previously, *yes*, there are broken EISA and VLB DMA
for > 16M.  If you have a bus master controller already detected, it
is possible to determine if DMA needs to be bounced.  My approach would
be to bounce *all* I/O until it is determined it is safe to not bounce.

This is easier than it appears, since you could use an unused field in
the disklabel, the root FS header, or some other location that defaults
to "0" that says "check for ability to bounce" and gets written to "1"
(always bounce, DMA is limited to 16M) or a "2" (don't bounce, DMA is
OK above 16M) -- and only triggers if there is more than 16M detected
in the machine.

This would make the NiCE HiNT chipset EISA's (the only EISA machines
where this is a problem) and the VLB machines you noted in a pervious
posting *work* instead of *failing* by default.

So the DMA argument doesn't support the EISA/VLB probe argument.


> >3)	The ISA code needs to "create device nodes" in a similar
> >	fashion to EISA for PnP.  This is a case of confusing ISA
> >	devices that can be mapped by a configuration manager with
> >	those that can't.  Read the Microsoft PnP document.
> 
> It does need to create nodes, but does that mean that the ISA code 
> bperforms a PNP probe and then scans the eisa slot space just to satisfy the
> 2842?

No.  I think it is incorrect to use the EISA slot space mechanism to
probe the controller.  The probe includes IRQ, DMA, and other info,
that unless it's a real EISA card, isn't going to be in the EISA
configuration space for VLB... even if such a space exists, the
user didn't run the DOS EISA configuration utility for the card
to set it.  It is at least 75% of the way to an EISA-independent probe.

> >What I suggest is calling the probe in multiple locations with two
> >stub routines: one EISA for eisaconf and one VLB (ISA, barring a
> >fixed handling of VLB).  If you want to call this "adding an ISA probe",
> >fine.  It's nowhere near the same order of effort as doing that, IMO.
> 
> What probe routine?  Eisa_match?

As I said before, you will have to break it out and provide EISA
specific stubs.  For ISA, you have to search the allowable space
(and that is a data issue, as long as the probe is non-invasive).

> >I can't fault you on the complexity argument: it will add a bit of
> >logical complexity in the process of providing a logical abstraction.
> >On the other hand, the abstraction can be made orthoganal so that it
> >is easier to document and program to for other devices that can then
> >seperate PnP mapping from driver attachment (substituting ISA PnP for
> >probing in the same way eisaconf substitutes slot iteration for
> >probing), so it seems like an acceptable tradeoff to me.
> >
> 
> I disagree.

With me agreeing with you on the complexity argument?

-- I was agreeing with you, reluctantly..

Or with my statement about orthogonality in a configuration management
interface?

-- If Microsoft can do it in Windows95, anyone can do it.  Microsoft
   programmers are *not* gods.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-stable  Thu Mar  7 17:52:46 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id RAA25002
          for stable-outgoing; Thu, 7 Mar 1996 17:52:46 -0800 (PST)
Received: from orion.webspan.net (root@orion.webspan.net [206.154.70.41])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA24996
          for <stable@freebsd.org>; Thu, 7 Mar 1996 17:52:43 -0800 (PST)
Received: from orion (scanner@orion [206.154.70.41]) by orion.webspan.net (8.6.12/8.6.9) with SMTP id UAA01762 for <stable@freebsd.org>; Thu, 7 Mar 1996 20:52:26 -0500
Date: Thu, 7 Mar 1996 20:52:26 -0500 (EST)
From: Scanner SOD <scanner@orion.webspan.net>
X-Sender: scanner@orion
To: stable@freebsd.org
Subject: date on march 7th sup sources
Message-ID: <Pine.BSF.3.91.960307205048.1740A-100000@orion>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-stable@freebsd.org
Precedence: bulk


How come after i sup -stable using : sup -i -e stable-supfile
the only sources that are dated march 7th (today) are the kernel sources?
how come ther rest of the sources are not?


Chris Watson, Webspan Inc., 500 West Kennedy Blvd., Lakewood, NJ 08701
Phone: (908) 367-8030 ext. 126, email: scanner@webspan.net
======================================
    FreeBSD 2.1.0 is available now!
--------------------------------------
FreeBSD: Turning PCs into Workstations
======================================



From owner-freebsd-stable  Thu Mar  7 19:16:57 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id TAA02996
          for stable-outgoing; Thu, 7 Mar 1996 19:16:57 -0800 (PST)
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA02977
          Thu, 7 Mar 1996 19:16:53 -0800 (PST)
Message-Id: <199603080316.TAA02977@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol
To: Terry Lambert <terry@lambert.org>
cc: imb@scgt.oz.au, stable@FreeBSD.ORG, current@FreeBSD.ORG
Subject: Re: 2842 and the disappearing file-system :-( 
In-reply-to: Your message of "Thu, 07 Mar 1996 13:36:15 MST."
             <199603072036.NAA14706@phaeton.artisoft.com> 
Date: Thu, 07 Mar 1996 19:16:52 -0800
From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
Sender: owner-stable@FreeBSD.ORG
Precedence: bulk

Again you have decided that if you at first miss the target, to
choose a totally different target for your next attempt.  Lets
remember what started this whole thread...

The 2842VLB SCSI card, a non PnP device, sticks its identifier in
the EISA slot address space for identification.  FreeBSD currently
always looks for these IDs in the EISA slot address space even if
the EISA motherboard ID at 0x0C80 is not found so that it can detect
these cards.

You complained that the EISA code should not probe the slot address
space if the motherboard ID was not found.  And thus this argument
began.

Since then, you've tried to make this into an agument for a configuration
manager.  Well, you have no argument from me for a configuration manager.
In fact I wrote eisaconf with the sole intention of making it a prototype
for a configuration manager that would encompass other device types.

What you will, and have seen me argue against is the need to construct
additional mechanisms into how we probe devices to cover a single
VLB card that was designed to be probed like an EISA device.  Having
more than one way to trigger a scan of the EISA slot address space
for devices is confusing at best, and leads to bugs at worst.  The
probe for EISA devices has proven non-invasive on the 100s of machines
that currently have eisa0 in their config files and the same scan would
be required anyway to support the 2842, so there is no technical
reason to provide an alternate method for triggering the search.
Furthermore, eisaconf must already properly report other ISA cards that
can be configured in "eisa compatibility mode" as living on the ISA
bus (the 3c509 for example) so it is already suited to the task of handing
the 2842 with absolutly no additional code or complexity:

ahc1: <Adaptec 284X SCSI host adapter> at 0x7c00-0x7cff irq 12 on isa

>No; I want a dup of the EISA process in the ISA PnP space so that it's
>just a case of making a reference to the routines (and *remove* the
>"eisa_" designations entirely).

But the 2842 is not a PnP device and forcing the ISA PnP mechanism to
deal with non PnP hardware is a violation of layering in a configuration
manager scenario.  The configuration manager should moderate between
the ISA PnP probe mechanism and the list of "possible probe locations"
provided by ISA devices and their "bus manager".

>> Most isa cards don't care about the eisa ids, so why create yet
>> another interface to them for the few isa cards that do.  No matter
>> your aversion to looking for eisa ids in a non eisa machine, it
>> will have to happen  regardless if you have a 2842 in your machine.
>> If you don't like it, or don't need it, disable eisa0.
>
>That's just the 2842, and it's an ISA driver configuration architecture
>problem with the ISA code.

And yet this was exactly the problem that spurred this thread.

>At the very least, we should admit that looking for EISA stuff on a
>non-EISA machine is a kludge.

Complain to Adaptec.

>> I know of one person who has a conceptual problem with this approach(you).
>
>Well, it doesn't seem that many people are thinking in terms of a unified
>configuration manager ala Windows95 and WindowsNT.  I expect the number
>of people doing so to increase over time as people desire better
>autoconfiguration out of FreeBSD.

Probing the 2842 as an EISA device does not preclude a configuration
manager aproach to solving our current device probe mess.

>> Show me one person experiencing actual failures after appling the
>> patch I posted yesturday.
>
>The number of people running VLB is ver small... you have given me a
>very restricted search space with your demand.

Anyone who currently has eisa0 in there kernel is proving the point that
the probe of the eisa slot address space is non-invasive.  The probe
can't tell if you have a VLB motherboard in order to prevent the probe,
and it can't know if you have a 2842 either without looking, so it always
does the scan.

>> >You are (intentionally?) missing the point.
>> 
>> You claim it doesn't add more code by saying I can call the same functions.
>> I'm saying I can't.  How am I missing the point.
>
>The point is you *should* be *able* to call the same functions for ISA,
>and for PnP, which uses non-invasive probing (unless you have an old
>IBM manufactured parallel port card), you *can*.

The match routines and forcing a scan of the eisa address space makes
no sense in a generic ISA probe (deals with non PnP hardware) configuration
sub-manager.

>> >1)	The ISA code, unless it's PnP, can't distinguish slots, so it
>> >	would have a damn hard time requiring looping through them.
>> 
>> You know as well as I do that the eisa slot locations are fixed
>> at 0xz000 for z 0-16.  How do you think the eisaconf code finds the eisa ids
>?
>> I don't see how this is relevent (again).
>
>This is a *card* problem, not a generic problem resolved for anthing
>other than the Adaptec card by calling the EISA code.

Exactly!  The Adaptec card behaves like an eisa device so you either
have it use the EISA probe mechanism or you have it be an ISA probe
that does the scan itself since it would be a layering violation to
have it call into the EISA probe to force it to scan the slot address
space even if it wasn't an EISA machine, call the eisa match routine
to see if a proper ID was found, and then turn around and register itself
with the ISA device manager.

>> >2)	This is a VLB card, not an ISA card.  I would not suggest
>> >	calling the probe from ISA any more than I would suggest
>> >	calling it from EISA.  It is *NOT* an EISA device.
>> 
>> What features does VLB have that make it of any use to differentiate
>> between VLB and ISA probes?
>
>A)	Default settings for driver configurable bus-on times, since VLB
>	steals DRAM refresh cycles.  VLB on time needs to be agregated
>	and adjusted *down* where necessary.

This is a device driver issue, not a VLB bus issue, since only the
driver knows if it is talking to a VLB card.

>B)	Use of bounce buffers on bus mastering VLB cards other than
>	the *one* detected by the EISA probe by virtue of it's "EISA"
>	nature.
>
>As you pointed out previously, *yes*, there are broken EISA and VLB DMA
>for > 16M.  If you have a bus master controller already detected, it
>is possible to determine if DMA needs to be bounced.  My approach would
>be to bounce *all* I/O until it is determined it is safe to not bounce.

Again, this is not a VLB issue.  I'm all for a generic way to determine
if bounce buffering is necessary, but this wasn't the issue we were 
discussing.

>So the DMA argument doesn't support the EISA/VLB probe argument.

It certainly doesn't support that there should be a separate VLB
probe.  > 16MB dma problems transend busses.

>> >3)	The ISA code needs to "create device nodes" in a similar
>> >	fashion to EISA for PnP.  This is a case of confusing ISA
>> >	devices that can be mapped by a configuration manager with
>> >	those that can't.  Read the Microsoft PnP document.
>> 
>> It does need to create nodes, but does that mean that the ISA code 
>> bperforms a PNP probe and then scans the eisa slot space just to satisfy the
>> 2842?
>
>No.  I think it is incorrect to use the EISA slot space mechanism to
>probe the controller.

Complain to Adaptec.

>The probe includes IRQ, DMA, and other info,
>that unless it's a real EISA card, isn't going to be in the EISA
>configuration space for VLB... even if such a space exists, the
>user didn't run the DOS EISA configuration utility for the card
>to set it.  It is at least 75% of the way to an EISA-independent probe.

For all of the EISA cards that I've added eisaconf probes for, the IRQ,
DMA and most other interresting information is availible in registers
initialized by the the EISA BIOS.  The 2842 has the same registers
availible that the 2742 so it is not an issue.  Think of the 2842
as an EISA card that doesn't have an overlay file and so doesn't store
anything in configuration space.  We can't even read configuration space
yet, but the eisaconf code will have to deal with devices that have
nothing set up there anyway which is simple since it will simply leave
it up to the device driver to interpret the data once the eisaconf code
can provide a means to access it.

>> >What I suggest is calling the probe in multiple locations with two
>> >stub routines: one EISA for eisaconf and one VLB (ISA, barring a
>> >fixed handling of VLB).  If you want to call this "adding an ISA probe",
>> >fine.  It's nowhere near the same order of effort as doing that, IMO.
>> 
>> What probe routine?  Eisa_match?
>
>As I said before, you will have to break it out and provide EISA
>specific stubs.  For ISA, you have to search the allowable space
>(and that is a data issue, as long as the probe is non-invasive).

What is the gain in doing this?

>> >I can't fault you on the complexity argument: it will add a bit of
>> >logical complexity in the process of providing a logical abstraction.
>> >On the other hand, the abstraction can be made orthoganal so that it
>> >is easier to document and program to for other devices that can then
>> >seperate PnP mapping from driver attachment (substituting ISA PnP for
>> >probing in the same way eisaconf substitutes slot iteration for
>> >probing), so it seems like an acceptable tradeoff to me.
>> >
>> 
>> I disagree.
>
>With me agreeing with you on the complexity argument?

No, with your assertion that having the ISA PnP support akin to 
how eisaconf works, solves the 2842 issue.  Coercing the 2842 to
fit into an ISA PnP model (it uses a dip switch block combined
with a "SCSI-Select" utility) is far worse than probing it as an
EISA device as the manufacturer intended.

>					Regards,
>					Terry Lambert
>					terry@lambert.org
>---
>Any opinions in this posting are my own and not those of my present
>or previous employers.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================

From owner-freebsd-stable  Thu Mar  7 19:29:17 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id TAA04202
          for stable-outgoing; Thu, 7 Mar 1996 19:29:17 -0800 (PST)
Received: from rich.isdn.bcm.tmc.edu (root@RICH.ISDN.BCM.TMC.EDU [128.249.250.34])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA04192
          for <stable@FreeBSD.org>; Thu, 7 Mar 1996 19:29:08 -0800 (PST)
Received: (from rich@localhost) by rich.isdn.bcm.tmc.edu (8.6.12/8.6.12) id VAA01748; Thu, 7 Mar 1996 21:29:03 -0600
Date: Thu, 7 Mar 1996 21:29:03 -0600
Message-Id: <199603080329.VAA01748@rich.isdn.bcm.tmc.edu>
From: Rich Murphey <rich@rich.isdn.bcm.tmc.edu>
To: stable@FreeBSD.org
Subject: free vnode isn't
Reply-to: rich@lamprey.utmb.edu
Sender: owner-stable@FreeBSD.org
Precedence: bulk


I've got three crashdumps on today's -stable kernel,
two after 'free vnode isn't' panics and one after a
'page fault' panic this morning on a 486/eisa system.
I hope this help someone.  I still have the dumps if
someone would like me to search for more info in them.
Rich



IdlePTD 1ec000
current pcb at 1df4c4
panic: free vnode isn't
#0  boot (howto=256) at ../../i386/i386/machdep.c:911
(kgdb) where
#0  boot (howto=256) at ../../i386/i386/machdep.c:911
#1  0xf0114303 in panic (fmt=0xf0129c83 "free vnode isn't") at ../../kern/subr_prf.c:124
#2  0xf0129d27 in getnewvnode (tag=VT_UFS, mp=0xf07afa00, vops=0xf077ed00, vpp=0xefbffc8c) at ../../kern/vfs_subr.c:352
#3  0xf01797ce in ffs_vget (mp=0xf07afa00, ino=334651, vpp=0xefbffd08) at ../../ufs/ffs/ffs_vfsops.c:781
#4  0xf017ce40 in ufs_lookup (ap=0xefbffd78) at ../../ufs/ufs/ufs_lookup.c:562
#5  0xf01292b5 in lookup (ndp=0xefbffeec) at ./vnode_if.h:27
#6  0xf0128e02 in namei (ndp=0xefbffeec) at ../../kern/vfs_lookup.c:147
#7  0xf012e643 in vn_open (ndp=0xefbffeec, fmode=1, cmode=420) at ../../kern/vfs_vnops.c:113
#8  0xf012bdbf in open (p=0xf080c900, uap=0xefbfff94, retval=0xefbfff8c) at ../../kern/vfs_syscalls.c:646
#9  0xf0199d6b in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -272639165, tf_esi = -272641016, tf_ebp = -272640992, tf_isp = -272629788, tf_ebx = 9, 
      tf_edx = 1, tf_ecx = 324992, tf_eax = 5, tf_trapno = 658, tf_err = 658, tf_eip = 134693989, tf_cs = 31, tf_eflags = 658, tf_esp = -272641032, 
      tf_ss = 39}) at ../../i386/i386/trap.c:906
#10 0xf019212b in Xsyscall ()
#11 0x7b5d in ?? ()
...

IdlePTD 1ec000
current pcb at 1df4c4
panic: page fault
#0  boot (howto=256) at ../../i386/i386/machdep.c:911
#1  0xf0114303 in panic (fmt=0xf0198fac "page fault") at ../../kern/subr_prf.c:124
#2  0xf0199a9e in trap_fatal (frame=0xefbffdcc) at ../../i386/i386/trap.c:746
#3  0xf0199610 in trap_pfault (frame=0xefbffdcc, usermode=0) at ../../i386/i386/trap.c:668
#4  0xf01992af in trap (frame={tf_es = 16, tf_ds = -2147483632, tf_edi = 0, tf_esi = -259987328, tf_ebp = -272630212, tf_isp = -272630284, 
      tf_ebx = -259987300, tf_edx = -272630196, tf_ecx = 27, tf_eax = -266879064, tf_trapno = 12, tf_err = -272695296, tf_eip = -266879016, 
      tf_cs = -272695288, tf_eflags = 66118, tf_esp = -259987300, tf_ss = -2}) at ../../i386/i386/trap.c:308
#5  0xf01920e1 in calltrap ()
#6  0xf012a6e1 in vrele (vp=0xf080e880) at ./vnode_if.h:576
#7  0xf012a93e in vclean (vp=0xf080e880, flags=0) at ../../kern/vfs_subr.c:1011
#8  0xf012a7bc in vflush (mp=0xf0766a00, skipvp=0x0, flags=2) at ../../kern/vfs_subr.c:937
#9  0xf0179450 in ffs_flushfiles (mp=0xf0766a00, flags=2, p=0xf077e700) at ../../ufs/ffs/ffs_vfsops.c:610
#10 0xf017936e in ffs_unmount (mp=0xf0766a00, mntflags=524288, p=0xf077e700) at ../../ufs/ffs/ffs_vfsops.c:556
#11 0xf0129a11 in vfs_unmountroot (rootfs=0xf0766a00) at ../../kern/vfs_subr.c:200
#12 0xf0129b1a in vfs_unmountall () at ../../kern/vfs_subr.c:240
#13 0xf0194727 in boot (howto=0) at ../../i386/i386/machdep.c:896
#14 0xf0112811 in reboot (p=0xf08a6f00, uap=0xefbfff94, retval=0xefbfff8c) at ../../kern/kern_xxx.c:80
#15 0xf0199d6b in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 0, tf_esi = 1, tf_ebp = -272638292, tf_isp = -272629788, tf_ebx = 2, tf_edx = -1, 
      tf_ecx = -272638416, tf_eax = 55, tf_trapno = 582, tf_err = 582, tf_eip = 7353, tf_cs = 31, tf_eflags = 582, tf_esp = -272638316, tf_ss = 39})
    at ../../i386/i386/trap.c:906
#16 0xf019212b in Xsyscall ()
#17 0x10e8 in ?? ()

IdlePTD 1ec000
current pcb at 1df4c4
panic: free vnode isn't
#0  boot (howto=256) at ../../i386/i386/machdep.c:911
#1  0xf0114303 in panic (fmt=0xf0129c83 "free vnode isn't") at ../../kern/subr_prf.c:124
#2  0xf0129d27 in getnewvnode (tag=VT_UFS, mp=0xf07afa00, vops=0xf077ed00, vpp=0xefbffcc4) at ../../kern/vfs_subr.c:352
#3  0xf01797ce in ffs_vget (mp=0xf07afa00, ino=246374, vpp=0xefbffd40) at ../../ufs/ffs/ffs_vfsops.c:781
#4  0xf017ce40 in ufs_lookup (ap=0xefbffdb0) at ../../ufs/ufs/ufs_lookup.c:562
#5  0xf01292b5 in lookup (ndp=0xefbffe44) at ./vnode_if.h:27
#6  0xf0128e02 in namei (ndp=0xefbffe44) at ../../kern/vfs_lookup.c:147
#7  0xf012ccce in lstat (p=0xf0814c00, uap=0xefbfff94, retval=0xefbfff8c) at ../../kern/vfs_syscalls.c:1268
#8  0xf0199d6b in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -1, tf_esi = 259584, tf_ebp = -272639028, tf_isp = -272629788, tf_ebx = 259660, 
      tf_edx = 259648, tf_ecx = 204800, tf_eax = 190, tf_trapno = 582, tf_err = 582, tf_eip = 42389, tf_cs = 31, tf_eflags = 582, tf_esp = -272639148, 
      tf_ss = 39}) at ../../i386/i386/trap.c:906
#9  0xf019212b in Xsyscall ()
#10 0x79e2 in ?? ()

From owner-freebsd-stable  Fri Mar  8 04:28:58 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id EAA08003
          for stable-outgoing; Fri, 8 Mar 1996 04:28:58 -0800 (PST)
Received: from Root.COM (implode.Root.COM [198.145.90.17])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA07998
          for <stable@FreeBSD.ORG>; Fri, 8 Mar 1996 04:28:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.6.12/8.6.5) with SMTP id EAA00864; Fri, 8 Mar 1996 04:29:16 -0800
Message-Id: <199603081229.EAA00864@Root.COM>
X-Authentication-Warning: implode.Root.COM: Host localhost didn't use HELO protocol
To: rich@lamprey.utmb.edu
cc: stable@FreeBSD.ORG
Subject: Re: free vnode isn't 
In-reply-to: Your message of "Thu, 07 Mar 1996 21:29:03 CST."
             <199603080329.VAA01748@rich.isdn.bcm.tmc.edu> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Fri, 08 Mar 1996 04:29:16 -0800
Sender: owner-stable@FreeBSD.ORG
X-Loop: owner-stable@FreeBSD.ORG
Precedence: bulk

>I've got three crashdumps on today's -stable kernel,
>two after 'free vnode isn't' panics and one after a
>'page fault' panic this morning on a 486/eisa system.
>I hope this help someone.  I still have the dumps if
>someone would like me to search for more info in them.

   Hi Rich...

   Please try out the attached patch and see if it makes the problem go away.
It's basically a patch Bruce came up with the other day that I've modified
slightly and adapted to -stable.

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project

Index: ufs_vnops.c
===================================================================
RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_vnops.c,v
retrieving revision 1.24.4.3
diff -c -r1.24.4.3 ufs_vnops.c
*** 1.24.4.3	1995/10/26 09:17:50
--- ufs_vnops.c	1996/03/08 12:26:31
***************
*** 842,848 ****
  		if ((fcnp->cn_flags & SAVESTART) == 0)
  			panic("ufs_rename: lost from startdir");
  		fcnp->cn_nameiop = DELETE;
! 		(void) relookup(fdvp, &fvp, fcnp);
  		return (VOP_REMOVE(fdvp, fvp, fcnp));
  	}
  	error = VOP_LOCK(fvp);
--- 842,851 ----
  		if ((fcnp->cn_flags & SAVESTART) == 0)
  			panic("ufs_rename: lost from startdir");
  		fcnp->cn_nameiop = DELETE;
! 		VREF(fdvp);
! 		error = relookup(fdvp, &fvp, fcnp);
! 		if (error == 0)
! 			vrele(fdvp);
  		return (VOP_REMOVE(fdvp, fvp, fcnp));
  	}
  	error = VOP_LOCK(fvp);
***************
*** 920,928 ****
--- 923,933 ----
  			goto out;
  		if ((tcnp->cn_flags & SAVESTART) == 0)
  			panic("ufs_rename: lost to startdir");
+ 		VREF(tdvp);
  		error = relookup(tdvp, &tvp, tcnp);
  		if (error)
  			goto out;
+ 		vrele(tdvp);
  		dp = VTOI(tdvp);
  		xp = NULL;
  		if (tvp)
***************
*** 1047,1053 ****
  	fcnp->cn_flags |= LOCKPARENT | LOCKLEAF;
  	if ((fcnp->cn_flags & SAVESTART) == 0)
  		panic("ufs_rename: lost from startdir");
! 	(void) relookup(fdvp, &fvp, fcnp);
  	if (fvp != NULL) {
  		xp = VTOI(fvp);
  		dp = VTOI(fdvp);
--- 1052,1061 ----
  	fcnp->cn_flags |= LOCKPARENT | LOCKLEAF;
  	if ((fcnp->cn_flags & SAVESTART) == 0)
  		panic("ufs_rename: lost from startdir");
! 	VREF(fdvp);
! 	error = relookup(fdvp, &fvp, fcnp);
! 	if (error == 0)
! 		vrele(fdvp);
  	if (fvp != NULL) {
  		xp = VTOI(fvp);
  		dp = VTOI(fdvp);

From owner-freebsd-stable  Fri Mar  8 10:19:41 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA03327
          for stable-outgoing; Fri, 8 Mar 1996 10:19:41 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA03310
          Fri, 8 Mar 1996 10:19:36 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA17284; Fri, 8 Mar 1996 11:13:55 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199603081813.LAA17284@phaeton.artisoft.com>
Subject: Re: 2842 and the disappearing file-system :-(
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Fri, 8 Mar 1996 11:13:55 -0700 (MST)
Cc: terry@lambert.org, imb@scgt.oz.au, stable@FreeBSD.org, current@FreeBSD.org
In-Reply-To: <199603080316.TAA02977@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 7, 96 07:16:52 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.org
X-Loop: owner-stable@FreeBSD.ORG
Precedence: bulk

> Again you have decided that if you at first miss the target, to
> choose a totally different target for your next attempt.  Lets
> remember what started this whole thread...

I have to say that my subtext on this whole thing has always been
the need for an orthoganal configuration management API.  I would
not have said anything, if I hadn't thought that it was going to
hell.

I wish I had known about the 2842 VLB being probed by the EISA probe
code earlier, but we can't all know everything.  This discussion was
not intended to blow up out of proportion as it has done.


> The 2842VLB SCSI card, a non PnP device, sticks its identifier in
> the EISA slot address space for identification.  FreeBSD currently
> always looks for these IDs in the EISA slot address space even if
> the EISA motherboard ID at 0x0C80 is not found so that it can detect
> these cards.
> 
> You complained that the EISA code should not probe the slot address
> space if the motherboard ID was not found.  And thus this argument
> began.

I still maintain this position.

> Since then, you've tried to make this into an agument for a configuration
> manager.  Well, you have no argument from me for a configuration manager.
> In fact I wrote eisaconf with the sole intention of making it a prototype
> for a configuration manager that would encompass other device types.
> 
> What you will, and have seen me argue against is the need to construct
> additional mechanisms into how we probe devices to cover a single
> VLB card that was designed to be probed like an EISA device.  Having
> more than one way to trigger a scan of the EISA slot address space
> for devices is confusing at best, and leads to bugs at worst.  The
> probe for EISA devices has proven non-invasive on the 100s of machines
> that currently have eisa0 in their config files and the same scan would
> be required anyway to support the 2842, so there is no technical
> reason to provide an alternate method for triggering the search.

Let's stop here for a second.

I don't think the major work of the probe for the VLB card is the
scan of the EISA slot address space.  It's getting the configuration
information about the card, and that doesn't take EISA configuration
data to do it.

So I don't think the 2842 should be being found by triggering a scan
of the EISA slot address space.

To put this another way, I shouldn't have to have an eisa0 in my config
file to use a VLB card.  It's confusing -- as confusing as having the
ability to option out the non-optional npx0 device.

I think if we back up and agree that the probe [of configuration
parameters associated with the card] should be seperate from the EISA
slot scan, then we will have made progress.

I don't *want* "an alternate method to trigger the search", I want to
not do the slot search on non-EISA machines.

Yes, this means that there is a need for some additional stub code
to actually find the card, but it doesn't change how the configuration
information is extracted from the card.

> Furthermore, eisaconf must already properly report other ISA cards that
> can be configured in "eisa compatibility mode" as living on the ISA
> bus (the 3c509 for example) so it is already suited to the task of handing
> the 2842 with absolutly no additional code or complexity:
> 
> ahc1: <Adaptec 284X SCSI host adapter> at 0x7c00-0x7cff irq 12 on isa

All things plugged into EISA slots are supposed to be configured,
period.  So it's a non-sequitur to talk about "can be configured" here.

Everything that goes into an EISA slot is capable of having an EISA
configuration file (I have a utility to generate these for ISA cards
that came with my EISA machine; you must enter the IRQ, DRQ, I/O, and
memory address ranges as part of the generation process).  And if it
is in an EISA slot, it *should* have an EISA config.

> >No; I want a dup of the EISA process in the ISA PnP space so that it's
> >just a case of making a reference to the routines (and *remove* the
> >"eisa_" designations entirely).
> 
> But the 2842 is not a PnP device and forcing the ISA PnP mechanism to
> deal with non PnP hardware is a violation of layering in a configuration
> manager scenario.  The configuration manager should moderate between
> the ISA PnP probe mechanism and the list of "possible probe locations"
> provided by ISA devices and their "bus manager".

The dup of the EISA process into the PnP space is an implementation
detail on the implementation of ISA PnP.  As part of the configuration
management, you have to probe the non-relocatable devices for which
you have drivers to determine the existance of "immobile" cards; then
for all mobile cards, you relocate them.

I think the 2842 is in the same category as the WD8013: it's a card
that is software relocatable, but which is not PnP and thus should
probably not be relocated.  It's one of the base line devices that
have a single graph vector for location.

For a real EISA device, it's acceptable to relocate the thing, since
EISA devices are configured per slot and each OS (or BIOS POST for
DOS for the INT 13 hook).  That means any OS that knows about dealing
with EISA the correct way will find the relocated card.

This isn't true of VLB cards, especially VLB cards for boot devices.

I think that the 2842 needs to be probed later than the typical
EISA, PCI, PCMCIA, and PnP ISA devices, like other non-relocatable
devices.  It think it needs to have an invariant configuration graph
vector, *unlike* things which are found by the EISA probe.

I think it is incorrect to probe the thing as an EISA device (are
there any motherboards that have EISA and VLB at the same time?
That would be a good counter-argument...).


> >At the very least, we should admit that looking for EISA stuff on a
> >non-EISA machine is a kludge.
> 
> Complain to Adaptec.

They didn't write the probe code.

I have no problem with them assigning slot space for a VLB card (it's
an artifact of the bus interface ASIC that they used anyway).  What
I do have a problem with is the implied probe order not treating it
as a non-relocatable ISA device because it had been found in EISA
space when we finally get to the point where we can do a graph
reduction topology sort to relocate the relocatable cards.

EISA cards are relocatable.  Relocating ISA or VLB cards that aren't
succeptable to ISA PnP drivers means that the cards could disappear
from DOS or another OS with a hard-coded config.sys line for ATAPI
for a CDROM on that controller, or whatever.

> >Well, it doesn't seem that many people are thinking in terms of a unified
> >configuration manager ala Windows95 and WindowsNT.  I expect the number
> >of people doing so to increase over time as people desire better
> >autoconfiguration out of FreeBSD.
> 
> Probing the 2842 as an EISA device does not preclude a configuration
> manager aproach to solving our current device probe mess.

Wrong.  It identifies it as an EISA device, and EISA devices are
fair game to be relocated by a PnP configuration manager.  Look
at the Windows95 PnP problems that FreeBSD has had with ethernet
cards.  Look at the IRQ 12 collisions that occur for PS/2 mice,
still, on Windows95 hardware with PnP enabled.

> Anyone who currently has eisa0 in there kernel is proving the point that
> the probe of the eisa slot address space is non-invasive.  The probe
> can't tell if you have a VLB motherboard in order to prevent the probe,
> and it can't know if you have a 2842 either without looking, so it always
> does the scan.

It can tell that you don't have an EISA motherboard, which is the same
thing, by negative induction.

The issue is not the invasiveness of the EISA probe; its with the
classification of the card as an EISA card.  And with the requirement
that I have the EISA code configured into a kernel for a non-EISA
system.

> >The point is you *should* be *able* to call the same functions for ISA,
> >and for PnP, which uses non-invasive probing (unless you have an old
> >IBM manufactured parallel port card), you *can*.
> 
> The match routines and forcing a scan of the eisa address space makes
> no sense in a generic ISA probe (deals with non PnP hardware) configuration
> sub-manager.

I agree.  Don't use the slot scan to locate the card; it isn't a
substitute for the majority of the work done by the probe code anyway.
Move the scan identification into an EISA-specific stub, and create
an ISA specific stub for the non-relocatable VLB card.

> >This is a *card* problem, not a generic problem resolved for anthing
> >other than the Adaptec card by calling the EISA code.
> 
> Exactly!  The Adaptec card behaves like an eisa device so you either
> have it use the EISA probe mechanism or you have it be an ISA probe
> that does the scan itself since it would be a layering violation to
> have it call into the EISA probe to force it to scan the slot address
> space even if it wasn't an EISA machine, call the eisa match routine
> to see if a proper ID was found, and then turn around and register itself
> with the ISA device manager.

I think you are stuck on using the fact that it exports EISA slot
data to trigger the probe (the manority of which is not dependent on
the fact that it's "EISA").  I think this is wrong, for the ordering
reasons stated above.

> >> What features does VLB have that make it of any use to differentiate
> >> between VLB and ISA probes?
> >
> >A)	Default settings for driver configurable bus-on times, since VLB
> >	steals DRAM refresh cycles.  VLB on time needs to be agregated
> >	and adjusted *down* where necessary.
> 
> This is a device driver issue, not a VLB bus issue, since only the
> driver knows if it is talking to a VLB card.

The VLB bus is not bridged.  The agregate bus-on time for N VLB cards
going in sequence is the issue for deciding to "tune" the VLB cards
down.

> >So the DMA argument doesn't support the EISA/VLB probe argument.
> 
> It certainly doesn't support that there should be a separate VLB
> probe.  > 16MB dma problems transend busses.

So call it a variant ISA probe.  So call it writing a probe.  Or
abstract the "relocatable" attribute of the 2842 by virtue of
detecting it's not really EISA (using the same code that would be
required for an ISA probe stub), and increase the complexity of the
EISA code by making it do a variant insertion in the configuration
topology graph to tag it as non-relocatable (note: this last approach
strikes me as singularly bogus, and is why I am against using the
EISA code to detect the non-EISA card).

> >No.  I think it is incorrect to use the EISA slot space mechanism to
> >probe the controller.
> 
> Complain to Adaptec.

Again...  I think you are stuck on using the fact that it exports
EISA slot data to trigger the probe (the manority of which is not
dependent on the fact that it's "EISA").  I think this is wrong,
for the ordering reasons stated above.

> >The probe includes IRQ, DMA, and other info,
> >that unless it's a real EISA card, isn't going to be in the EISA
> >configuration space for VLB... even if such a space exists, the
> >user didn't run the DOS EISA configuration utility for the card
> >to set it.  It is at least 75% of the way to an EISA-independent probe.
> 
> For all of the EISA cards that I've added eisaconf probes for, the IRQ,
> DMA and most other interresting information is availible in registers
> initialized by the the EISA BIOS.  The 2842 has the same registers
> availible that the 2742 so it is not an issue.  Think of the 2842
> as an EISA card that doesn't have an overlay file and so doesn't store
> anything in configuration space.  We can't even read configuration space
> yet, but the eisaconf code will have to deal with devices that have
> nothing set up there anyway which is simple since it will simply leave
> it up to the device driver to interpret the data once the eisaconf code
> can provide a means to access it.

Precisely!

Once you can manipulate the configuration space, EISA cards are as
relocatable as ISA PnP cards!  But this VLB ccard, which you lie and
say is an EISA card by virtue of whose probe comes true, can *not*
be relocated!

You have to indirect all EISA configuration space code through the
driver, and then call common routines for *all other drivers*, and
for this one fake an immobile configuration space!  Bletch!  Talk
about unnecessary complexity!

> >As I said before, you will have to break it out and provide EISA
> >specific stubs.  For ISA, you have to search the allowable space
> >(and that is a data issue, as long as the probe is non-invasive).
> 
> What is the gain in doing this?

EISA cards become relocatable within the conflict space.

> No, with your assertion that having the ISA PnP support akin to 
> how eisaconf works, solves the 2842 issue.  Coercing the 2842 to
> fit into an ISA PnP model (it uses a dip switch block combined
> with a "SCSI-Select" utility) is far worse than probing it as an
> EISA device as the manufacturer intended.

The manufacturer intended to avoid having to design VLB ASIC's when
it already had EISA ASIC's.  The manufacturer did not intend for
the BIOS on the machine to use EISA configuration methods to handle
VLB cards when the machine had no EISA slots and therefore doesn't
have EISA-specific BIOS anyway.

The "EISA-ness" of the 2842 is an artifact of sloppy design, not
of engineering intent.


Do you not agree that EISA cards should be relocatable by a resonable
configuration manager that knows EISA?

Or that the 2842, a VLB card, should *not* be relocatable because
there is no standard mechanism for handling an EISA relocation of
a non-EISA card?

Or that the 2842 would have to have a fake configuration space, which
would greatly complicate the configuration space manipulation for
*real* EISA cards?


Look, it's *fine* with me that you call my suggestion "writing an ISA
probe" (even if I think it's possible to reuse most of the code), so
long as the ability to relocate EISA cards is not adversly affected
by the fact that the 2842 lies about being an EISA card.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-stable  Fri Mar  8 15:16:50 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id PAA20967
          for stable-outgoing; Fri, 8 Mar 1996 15:16:50 -0800 (PST)
Received: from who.cdrom.com (who.cdrom.com [192.216.222.3])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA20938
          for <stable@FreeBSD.ORG>; Fri, 8 Mar 1996 15:16:45 -0800 (PST)
Received: from orion.webspan.net (root@orion.webspan.net [206.154.70.41])
          by who.cdrom.com (8.6.12/8.6.11) with ESMTP id NAA01391
          for <stable@freebsd.org>; Fri, 8 Mar 1996 13:36:03 -0800
Received: from orion (scanner@orion [206.154.70.41]) by orion.webspan.net (8.6.12/8.6.9) with SMTP id QAA00320 for <stable@freebsd.org>; Fri, 8 Mar 1996 16:35:33 -0500
Date: Fri, 8 Mar 1996 16:35:33 -0500 (EST)
From: Scanner SOD <scanner@orion.webspan.net>
X-Sender: scanner@orion
To: stable@FreeBSD.ORG
Subject: TELNET with 2.1 stable lost DES function
Message-ID: <Pine.BSF.3.91.960308163356.310A-100000@orion>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-stable@FreeBSD.ORG
X-Loop: owner-stable@FreeBSD.ORG
Precedence: bulk


Can anyone tell me why after finally getting a 2.1-stable system somehwat 
working, my telnet does not support telnet -x anymore
in /usr/lib 3 libraries still -> to libdes* but telnet -x says no DES 
support, did i goof something up?
or is there something i still havent done?
Id really like my DES support back in telnet how can i do this
Thanks,


Chris Watson, Webspan Inc., 500 West Kennedy Blvd., Lakewood, NJ 08701
Phone: (908) 367-8030 ext. 126, email: scanner@webspan.net
======================================
    FreeBSD 2.1.0 is available now!
--------------------------------------
FreeBSD: Turning PCs into Workstations
======================================



From owner-freebsd-stable  Fri Mar  8 15:17:30 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id PAA21235
          for stable-outgoing; Fri, 8 Mar 1996 15:17:30 -0800 (PST)
Received: from who.cdrom.com (who.cdrom.com [192.216.222.3])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA21205
          for <stable@FreeBSD.ORG>; Fri, 8 Mar 1996 15:17:25 -0800 (PST)
Received: from rich.isdn.bcm.tmc.edu (root@RICH.ISDN.BCM.TMC.EDU [128.249.250.34])
          by who.cdrom.com (8.6.12/8.6.11) with ESMTP id HAA26371
          for <stable@FreeBSD.ORG>; Fri, 8 Mar 1996 07:46:59 -0800
Received: (from rich@localhost) by rich.isdn.bcm.tmc.edu (8.6.12/8.6.12) id JAA00382; Fri, 8 Mar 1996 09:46:43 -0600
Date: Fri, 8 Mar 1996 09:46:43 -0600
Message-Id: <199603081546.JAA00382@rich.isdn.bcm.tmc.edu>
From: Rich Murphey <rich@rich.isdn.bcm.tmc.edu>
To: davidg@Root.COM
CC: stable@FreeBSD.ORG
In-reply-to: <199603081229.EAA00864@Root.COM> (message from David Greenman on
	Fri, 08 Mar 1996 04:29:16 -0800)
Subject: Re: free vnode isn't
Reply-to: rich@lamprey.utmb.edu
Sender: owner-stable@FreeBSD.ORG
X-Loop: owner-stable@FreeBSD.ORG
Precedence: bulk

|From: David Greenman <davidg@Root.COM>
|   Please try out the attached patch and see if it makes the problem go away.
|It's basically a patch Bruce came up with the other day that I've modified
|slightly and adapted to -stable.

Drat, nope, I got another 'free vnode isn't' after
installing the patch.  Here's the backtrace.  Rich


IdlePTD 1ec000
current pcb at 1df4c4
panic: free vnode isn't
#0  boot (howto=256) at ../../i386/i386/machdep.c:911
(kgdb) where 
#0  boot (howto=256) at ../../i386/i386/machdep.c:911
#1  0xf0114303 in panic (fmt=0xf0129c83 "free vnode isn't") at ../../kern/subr_prf.c:124
#2  0xf0129d27 in getnewvnode (tag=VT_UFS, mp=0xf07afa00, vops=0xf077ed00, vpp=0xefbffcc4) at ../../kern/vfs_subr.c:352
#3  0xf01797ce in ffs_vget (mp=0xf07afa00, ino=38405, vpp=0xefbffd40) at ../../ufs/ffs/ffs_vfsops.c:781
#4  0xf017ce40 in ufs_lookup (ap=0xefbffdb0) at ../../ufs/ufs/ufs_lookup.c:562
#5  0xf01292b5 in lookup (ndp=0xefbffe44) at ./vnode_if.h:27
#6  0xf0128e02 in namei (ndp=0xefbffe44) at ../../kern/vfs_lookup.c:147
#7  0xf012ccce in lstat (p=0xf091c300, uap=0xefbfff94, retval=0xefbfff8c) at ../../kern/vfs_syscalls.c:1268
#8  0xf0199dab in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -1, tf_esi = 230400, tf_ebp = -272639020, tf_isp = -272629788, tf_ebx = 230472, 
      tf_edx = 230464, tf_ecx = 204800, tf_eax = 190, tf_trapno = 582, tf_err = 582, tf_eip = 42389, tf_cs = 31, tf_eflags = 582, tf_esp = -272639140, 
      tf_ss = 39}) at ../../i386/i386/trap.c:906
#9  0xf019216b in Xsyscall ()
#10 0x79e2 in ?? ()

From owner-freebsd-stable  Fri Mar  8 19:24:04 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id TAA11731
          for stable-outgoing; Fri, 8 Mar 1996 19:24:04 -0800 (PST)
Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA11676
          for <stable@freebsd.org>; Fri, 8 Mar 1996 19:23:56 -0800 (PST)
Received: (from imb@localhost)
	by asstdc.scgt.oz.au (8.6.12/BSD4.4)
	id OAA18397; Sat, 9 Mar 1996 14:23:17 +1100
From: michael butler <imb@scgt.oz.au>
Message-Id: <199603090323.OAA18397@asstdc.scgt.oz.au>
Subject: Re: free vnode isn't
To: rich@lamprey.utmb.edu
Date: Sat, 9 Mar 1996 14:23:16 +1100 (EST)
Cc: stable@freebsd.org
In-Reply-To: <199603080329.VAA01748@rich.isdn.bcm.tmc.edu> from "Rich Murphey" at Mar 7, 96 09:29:03 pm
X-Mailer: ELM [version 2.4 PL24beta]
Content-Type: text
Sender: owner-stable@freebsd.org
X-Loop: owner-stable@FreeBSD.ORG
Precedence: bulk

Rich Murphey writes:

> I've got three crashdumps on today's -stable kernel,
> two after 'free vnode isn't' panics and one after a
> 'page fault' panic this morning on a 486/eisa system.
                                           ^^^^
> I hope this help someone.  I still have the dumps if
> someone would like me to search for more info in them.

If you aren't already using it, sup (or ftp) the new /sys/i386/isa/isa.c and
rebuild your kernel. It fixes all sorts of obscure (eisa/vesa) problems with
just one line :-)

	michael

From owner-freebsd-stable  Fri Mar  8 21:46:47 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id VAA22462
          for stable-outgoing; Fri, 8 Mar 1996 21:46:47 -0800 (PST)
Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA22456
          Fri, 8 Mar 1996 21:46:44 -0800 (PST)
Message-Id: <199603090546.VAA22456@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol
To: Terry Lambert <terry@lambert.org>
cc: stable@FreeBSD.org, current@FreeBSD.org
Subject: Re: The continueing 2842/eisaconf argument
In-reply-to: Your message of "Fri, 08 Mar 1996 11:13:55 MST."
             <199603081813.LAA17284@phaeton.artisoft.com> 
Date: Fri, 08 Mar 1996 21:46:44 -0800
From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
Sender: owner-stable@FreeBSD.org
X-Loop: owner-stable@FreeBSD.ORG
Precedence: bulk

>I have to say that my subtext on this whole thing has always been
>the need for an orthoganal configuration management API.  I would
>not have said anything, if I hadn't thought that it was going to
>hell.
>
>I wish I had known about the 2842 VLB being probed by the EISA probe
>code earlier, but we can't all know everything.  This discussion was
>not intended to blow up out of proportion as it has done.

I maintain that the way that the 2842 is currently probed in no
way gepordizes the ability to create a configuration management
API.  Much of what you say below is simply not true...

>> What you will, and have seen me argue against is the need to construct
>> additional mechanisms into how we probe devices to cover a single
>> VLB card that was designed to be probed like an EISA device.  Having
>> more than one way to trigger a scan of the EISA slot address space
>> for devices is confusing at best, and leads to bugs at worst.  The
>> probe for EISA devices has proven non-invasive on the 100s of machines
>> that currently have eisa0 in their config files and the same scan would
>> be required anyway to support the 2842, so there is no technical
>> reason to provide an alternate method for triggering the search.
>
>Let's stop here for a second.
>
>I don't think the major work of the probe for the VLB card is the
>scan of the EISA slot address space.  It's getting the configuration
>information about the card, and that doesn't take EISA configuration
>data to do it.

EISA configuration data (assuming you mean the stuff accessible through
BIOS calls) is not used by any driver in FreeBSD.  Even if it was
accessible to FreeBSD (and there's no reason it can't be with VM86() or
having the boot blocks save off the data) it would have to be interpreted
by each individual driver in order to be of any use.  So, although eisaconf
may some day provide a mechanism for accessing this data, it certainly
won't attempt processing it on its own.  Every eisa card we support
provides some other way for either read/write or write only access to
the data the driver needs.

>So I don't think the 2842 should be being found by triggering a scan
>of the EISA slot address space.
>
>To put this another way, I shouldn't have to have an eisa0 in my config
>file to use a VLB card.  It's confusing -- as confusing as having the
>ability to option out the non-optional npx0 device.
>
>I think if we back up and agree that the probe [of configuration
>parameters associated with the card] should be seperate from the EISA
>slot scan, then we will have made progress.

It has to be up to each driver to request and then interpret this
information if it makes sense for them to do so.  Many cards could
care less about what's up in configuration space.  The 3c579 is one,
the 2842 is another.  If we have to support EISA devices that don't
want configuration data we can also support VLB devices that doesn't
use configuration space information with no additional complexity.
Its really a question of capability and use.  Just because the Win32
API provides 5 volumes of "capabilities" doesn't mean I use them all.

>I don't *want* "an alternate method to trigger the search", I want to
>not do the slot search on non-EISA machines.
>
>Yes, this means that there is a need for some additional stub code
>to actually find the card, but it doesn't change how the configuration
>information is extracted from the card.

The 2742 and the 2842 will continue to get most of the information
about the card in the exact same way regardless of the availibility
of configuration space data.  You're also not talking about
stub code, but an additional probe that iterates through the slot
address space since the 2842 can't reference the eisa code in your
model since you don't want to have to have eisa0 in your config file.
This is just like going back to the days when we didn't have an eisaconf
and every eisa (or eisa like) driver duplicated this exact scan of
the address space.  Bug fixes to one probe didn't propogate to the
others.  I don't see forcing people to include eisa0 in their 
config files as a problem since config will eventually die a horrible
death, and the aic7xxx lkm will export its lkm dependancy graph so
that if you don't have the eisaconf lkm in your system for some
strange reason, it gives you a nice warning message.  If you can
talk about eisa configuration space, I think its fair for me to say that
config, in its present state, will go away.

>> Furthermore, eisaconf must already properly report other ISA cards that
>> can be configured in "eisa compatibility mode" as living on the ISA
>> bus (the 3c509 for example) so it is already suited to the task of handing
>> the 2842 with absolutly no additional code or complexity:
>> 
>> ahc1: <Adaptec 284X SCSI host adapter> at 0x7c00-0x7cff irq 12 on isa
>
>All things plugged into EISA slots are supposed to be configured,
>period.  So it's a non-sequitur to talk about "can be configured" here.
>
>Everything that goes into an EISA slot is capable of having an EISA
>configuration file (I have a utility to generate these for ISA cards
>that came with my EISA machine; you must enter the IRQ, DRQ, I/O, and
>memory address ranges as part of the generation process).  And if it
>is in an EISA slot, it *should* have an EISA config.

Having an EISA config file doesn't mean that your ISA device responds
to accesses at 0xzc80 and provides an EISA ID.  THe 3c509 does when
its installed in an EISA system and properly configured.  The 1542
does not.  Having the config file is simply a way of aiding the ECU
in telling you where conflicts are or restricing your configuration
settings.  Once the ECU session is over, there's nothing their to
tell FreeBSD about these ISA devices.

>The dup of the EISA process into the PnP space is an implementation
>detail on the implementation of ISA PnP.  As part of the configuration
>management, you have to probe the non-relocatable devices for which
>you have drivers to determine the existance of "immobile" cards; then
>for all mobile cards, you relocate them.
>
>I think the 2842 is in the same category as the WD8013: it's a card
>that is software relocatable, but which is not PnP and thus should
>probably not be relocated.  It's one of the base line devices that
>have a single graph vector for location.
>
>For a real EISA device, it's acceptable to relocate the thing, since
>EISA devices are configured per slot and each OS (or BIOS POST for
>DOS for the INT 13 hook).  That means any OS that knows about dealing
>with EISA the correct way will find the relocated card.
>
>This isn't true of VLB cards, especially VLB cards for boot devices.

You can switch the dip switches on your 2842 all day, and FreeBSD will
still find it.  You can also move your 2742 from slot to slot all day
and FreeBSD will still find it.  Relocating the card doesn't prevent
you from booting from it in either case so long as the card's bios is
enabled.  Booting is a BIOS issue.  I can make a 2742 not bootable
by disabling its BIOS too.

>I think that the 2842 needs to be probed later than the typical
>EISA, PCI, PCMCIA, and PnP ISA devices, like other non-relocatable
>devices.  It think it needs to have an invariant configuration graph
>vector, *unlike* things which are found by the EISA probe.

The 2742 is just as non-relocatable as the 2842.  The 2742 locks out is irq
register after the first time its written to (by the EISA configuration
just after POST).  Most EISA cards can't relocate their I/O range, but the
Buslogic cards can relocate relocate their registers through a range of ISA
compatibily areas.  The point is that the way you deal with registering
relocatability has to be generic so you can deal with devices that vary in
their degrees of flexibility regardless of their bus type.

>I think it is incorrect to probe the thing as an EISA device (are
>there any motherboards that have EISA and VLB at the same time?
>That would be a good counter-argument...).

Many, many EISA 486 systems have VL and EISA slots.  I own one of these
systems.

>> >At the very least, we should admit that looking for EISA stuff on a
>> >non-EISA machine is a kludge.
>> 
>> Complain to Adaptec.
>
>They didn't write the probe code.
>
>I have no problem with them assigning slot space for a VLB card (it's
>an artifact of the bus interface ASIC that they used anyway).  What
>I do have a problem with is the implied probe order not treating it
>as a non-relocatable ISA device because it had been found in EISA
>space when we finally get to the point where we can do a graph
>reduction topology sort to relocate the relocatable cards.

Not all EISA devices are relocatable in the same ways.  I can find
plenty of EISA devices that have the same relocation deficiencies
as the 2842.  This is not a valid argument.

>EISA cards are relocatable.  Relocating ISA or VLB cards that aren't
>succeptable to ISA PnP drivers means that the cards could disappear
>from DOS or another OS with a hard-coded config.sys line for ATAPI
>for a CDROM on that controller, or whatever.

Not all EISA cards are relocatable after their first initialization.
We have to deal with these anyway.

>> Probing the 2842 as an EISA device does not preclude a configuration
>> manager aproach to solving our current device probe mess.
>
>Wrong.  It identifies it as an EISA device, and EISA devices are
>fair game to be relocated by a PnP configuration manager.  Look
>at the Windows95 PnP problems that FreeBSD has had with ethernet
>cards.  Look at the IRQ 12 collisions that occur for PS/2 mice,
>still, on Windows95 hardware with PnP enabled.

No, it identifies it as an ISA device.  And, some non PnP ISA cards
just like some EISA cards (EISA is not PnP BTW), allow you to dynamically
change the IRQ.  So, what's your point?  If we had a configuration manager
we woudn't allow flexible devices to conflict with non-flexible ones
which has absolutly nothing to do with the 2842 being probed through
eisaconf.  The 2842, just like all the other devices using eisaconf
will have to register just what it is that they can have changed and
what they cannot (and the range they can be configured to.  Not all
cards support all IRQs for example).


>> Anyone who currently has eisa0 in there kernel is proving the point that
>> the probe of the eisa slot address space is non-invasive.  The probe
>> can't tell if you have a VLB motherboard in order to prevent the probe,
>> and it can't know if you have a 2842 either without looking, so it always
>> does the scan.
>
>It can tell that you don't have an EISA motherboard, which is the same
>thing, by negative induction.

Assuming EISA and VLB are mutiually exclusive which they are not.

>The issue is not the invasiveness of the EISA probe; its with the
>classification of the card as an EISA card.  And with the requirement
>that I have the EISA code configured into a kernel for a non-EISA
>system.

The 3c509 in eisa configuration mode must be probed through eisaconf
to be found.  It is reported as an ISA device.  The 2842 is also found
through eisaconf and is reported as an ISA device.  Both show up as ISA
device in lsdev too since their kdc parents are kdc_isa.  Where does
the 2842 get classified as an EISA device?

>> >The point is you *should* be *able* to call the same functions for ISA,
>> >and for PnP, which uses non-invasive probing (unless you have an old
>> >IBM manufactured parallel port card), you *can*.
>> 
>> The match routines and forcing a scan of the eisa address space makes
>> no sense in a generic ISA probe (deals with non PnP hardware) configuration
>> sub-manager.
>
>I agree.  Don't use the slot scan to locate the card; it isn't a
>substitute for the majority of the work done by the probe code anyway.
>Move the scan identification into an EISA-specific stub, and create
>an ISA specific stub for the non-relocatable VLB card.

And I either make it always be in your kernel, or make it part of
"eisa0", or I duplicate it.  What a waste.

>> >This is a *card* problem, not a generic problem resolved for anthing
>> >other than the Adaptec card by calling the EISA code.
>> 
>> Exactly!  The Adaptec card behaves like an eisa device so you either
>> have it use the EISA probe mechanism or you have it be an ISA probe
>> that does the scan itself since it would be a layering violation to
>> have it call into the EISA probe to force it to scan the slot address
>> space even if it wasn't an EISA machine, call the eisa match routine
>> to see if a proper ID was found, and then turn around and register itself
>> with the ISA device manager.
>
>I think you are stuck on using the fact that it exports EISA slot
>data to trigger the probe (the manority of which is not dependent on
>the fact that it's "EISA").  I think this is wrong, for the ordering
>reasons stated above.

The ordering reasons don't hold water.  Nothing is gained by postponing
the probe of the 2842.  Its just as "relocatable" as other EISA devices
and its probe is non-invasive (and already performed by the eisaconf code).

>> >> What features does VLB have that make it of any use to differentiate
>> >> between VLB and ISA probes?
>> >
>> >A)	Default settings for driver configurable bus-on times, since VLB
>> >	steals DRAM refresh cycles.  VLB on time needs to be agregated
>> >	and adjusted *down* where necessary.
>> 
>> This is a device driver issue, not a VLB bus issue, since only the
>> driver knows if it is talking to a VLB card.
>
>The VLB bus is not bridged.  The agregate bus-on time for N VLB cards
>going in sequence is the issue for deciding to "tune" the VLB cards
>down.

This as well as most tuning parameters should be left up to the user.
I don't see FreeBSD trying to modify your DRAM refresh rates.  Its
counter intuitive for the user to go in and set the bus on time for
their adapter using the vendor supplied tools for this purpose
(EISA config utility for the 2742, SCSI-Select for the 2842) and
not have the OS honor them.

>> >So the DMA argument doesn't support the EISA/VLB probe argument.
>> 
>> It certainly doesn't support that there should be a separate VLB
>> probe.  > 16MB dma problems transend busses.
>
>So call it a variant ISA probe.  So call it writing a probe.  Or
>abstract the "relocatable" attribute of the 2842 by virtue of
>detecting it's not really EISA (using the same code that would be
>required for an ISA probe stub), and increase the complexity of the
>EISA code by making it do a variant insertion in the configuration
>topology graph to tag it as non-relocatable (note: this last approach
>strikes me as singularly bogus, and is why I am against using the
>EISA code to detect the non-EISA card).

Your making up problems Terry.  Probe order is determined by bus type.
Resource allocation is determined by the relative flexibility of devices
regardless of bus type.

>> For all of the EISA cards that I've added eisaconf probes for, the IRQ,
>> DMA and most other interresting information is availible in registers
>> initialized by the the EISA BIOS.  The 2842 has the same registers
>> availible that the 2742 so it is not an issue.  Think of the 2842
>> as an EISA card that doesn't have an overlay file and so doesn't store
>> anything in configuration space.  We can't even read configuration space
>> yet, but the eisaconf code will have to deal with devices that have
>> nothing set up there anyway which is simple since it will simply leave
>> it up to the device driver to interpret the data once the eisaconf code
>> can provide a means to access it.
>
>Precisely!
>
>Once you can manipulate the configuration space, EISA cards are as
>relocatable as ISA PnP cards!  But this VLB ccard, which you lie and
>say is an EISA card by virtue of whose probe comes true, can *not*
>be relocated!

Bullshit!  ISA PnP cards can relocate their I/O area most EISA cards can't.
Some EISA cards do not allow relocation of anything after the EISA BIOS is
done.  Furthermore, the data up in configuration space doesn't control the
settings of the card.  You have to write to the cards own registers to do
that which FreeBSD already has the capability to do without having access
to configuration space.

>You have to indirect all EISA configuration space code through the
>driver, and then call common routines for *all other drivers*, and
>for this one fake an immobile configuration space!  Bletch!  Talk
>about unnecessary complexity!

This just isn't true.  All devices can call the same functions to
register their resources, but it will only be at attach time that
they will know if they have to change their settings and to what.

>> What is the gain in doing this?
>
>EISA cards become relocatable within the conflict space.

The 2842 doesn't prevent this.

>Do you not agree that EISA cards should be relocatable by a resonable
>configuration manager that knows EISA?

Sure.  Eisaconf is already poised to do this and the 2842 will 
fit right in there.

>Or that the 2842, a VLB card, should *not* be relocatable because
>there is no standard mechanism for handling an EISA relocation of
>a non-EISA card?

Hey, you can change the 2842's IRQ so it will tell that to the
configuration manager.  The 2742 cannot change its IRQ, and it
will tell the configuration manager that.  If you can handle one
case, you can handle the other.

>Or that the 2842 would have to have a fake configuration space, which
>would greatly complicate the configuration space manipulation for
>*real* EISA cards?

eisaconf will never manipulate configuration space directly, ever.
Its not needed to support dynamic configuration of EISA devices.
The 2742 just like the 2842 will not be making any calls into
eisaconf to retrieve information from configuration space, so
it doesn't matter if there is or is not any configuration space
data for the 2742 or the 2842.  Other drivers may have different
requirements.

>					Regards,
>					Terry Lambert
>					terry@lambert.org
>---
>Any opinions in this posting are my own and not those of my present
>or previous employers.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================

From owner-freebsd-stable  Fri Mar  8 22:30:53 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id WAA24860
          for stable-outgoing; Fri, 8 Mar 1996 22:30:53 -0800 (PST)
Received: from rich.isdn.bcm.tmc.edu (root@RICH.ISDN.BCM.TMC.EDU [128.249.250.34])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA24855
          for <stable@freebsd.org>; Fri, 8 Mar 1996 22:30:49 -0800 (PST)
Received: (from rich@localhost) by rich.isdn.bcm.tmc.edu (8.6.12/8.6.12) id AAA00994; Sat, 9 Mar 1996 00:30:29 -0600
Date: Sat, 9 Mar 1996 00:30:29 -0600
Message-Id: <199603090630.AAA00994@rich.isdn.bcm.tmc.edu>
From: Rich Murphey <rich@rich.isdn.bcm.tmc.edu>
To: imb@scgt.oz.au
CC: stable@freebsd.org
In-reply-to: <199603090323.OAA18397@asstdc.scgt.oz.au> (message from michael
	butler on Sat, 9 Mar 1996 14:23:16 +1100 (EST))
Subject: Re: free vnode isn't
Reply-to: rich@lamprey.utmb.edu
Sender: owner-stable@freebsd.org
X-Loop: owner-stable@FreeBSD.ORG
Precedence: bulk

|From: michael butler <imb@scgt.oz.au>
|If you aren't already using it, sup (or ftp) the new /sys/i386/isa/isa.c and
|rebuild your kernel. It fixes all sorts of obscure (eisa/vesa) problems with
|just one line :-)

Yep, thanks, the isa.c fix that Justin provided did fix
certain symtoms with an adaptec 1742 eisa/scsi adapter
here.

But I still see remaining problems even with that fix.
That is, the backtraces I've posted before and those
below are for kernels that have included Justin's isa.c
fix.  Rich



IdlePTD 1ec000
current pcb at 1df4c4
panic: free vnode isn't
#0  boot (howto=256) at ../../i386/i386/machdep.c:911
#1  0xf0114303 in panic (fmt=0xf0129c83 "free vnode isn't") at ../../kern/subr_prf.c:124
#2  0xf0129d27 in getnewvnode (tag=VT_UFS, mp=0xf07afa00, vops=0xf077ed00, vpp=0xefbffcc4) at ../../kern/vfs_subr.c:352
#3  0xf01797ce in ffs_vget (mp=0xf07afa00, ino=38405, vpp=0xefbffd40) at ../../ufs/ffs/ffs_vfsops.c:781
#4  0xf017ce40 in ufs_lookup (ap=0xefbffdb0) at ../../ufs/ufs/ufs_lookup.c:562
#5  0xf01292b5 in lookup (ndp=0xefbffe44) at ./vnode_if.h:27
#6  0xf0128e02 in namei (ndp=0xefbffe44) at ../../kern/vfs_lookup.c:147
#7  0xf012ccce in lstat (p=0xf091c300, uap=0xefbfff94, retval=0xefbfff8c) at ../../kern/vfs_syscalls.c:1268
#8  0xf0199dab in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -1, tf_esi = 230400, tf_ebp = -272639020, tf_isp = -272629788, tf_ebx = 230472, 
      tf_edx = 230464, tf_ecx = 204800, tf_eax = 190, tf_trapno = 582, tf_err = 582, tf_eip = 42389, tf_cs = 31, tf_eflags = 582, tf_esp = -272639140, 
      tf_ss = 39}) at ../../i386/i386/trap.c:906
#9  0xf019216b in Xsyscall ()
#10 0x79e2 in ?? ()


IdlePTD 1ec000
current pcb at 1df4c4
panic: page fault
#0  boot (howto=cannot read proc at 0xf07f6d00
) at ../../i386/i386/machdep.c:911
cannot read proc at 0xf07f6d00


IdlePTD 1ec000
current pcb at 1df4c4
panic: free vnode isn't
#0  boot (howto=256) at ../../i386/i386/machdep.c:911
#1  0xf0114303 in panic (fmt=0xf0129c83 "free vnode isn't") at ../../kern/subr_prf.c:124
#2  0xf0129d27 in getnewvnode (tag=VT_UFS, mp=0xf07ba800, vops=0xf077ed00, vpp=0xefbffcc4) at ../../kern/vfs_subr.c:352
#3  0xf01797ce in ffs_vget (mp=0xf07ba800, ino=355311, vpp=0xefbffd40) at ../../ufs/ffs/ffs_vfsops.c:781
#4  0xf017ce40 in ufs_lookup (ap=0xefbffdb0) at ../../ufs/ufs/ufs_lookup.c:562
#5  0xf01292b5 in lookup (ndp=0xefbffe44) at ./vnode_if.h:27
#6  0xf0128e02 in namei (ndp=0xefbffe44) at ../../kern/vfs_lookup.c:147
#7  0xf012ccce in lstat (p=0xf0922a00, uap=0xefbfff94, retval=0xefbfff8c) at ../../kern/vfs_syscalls.c:1268
#8  0xf0199dab in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -1, tf_esi = 232192, tf_ebp = -272638972, tf_isp = -272629788, tf_ebx = 232268, 
      tf_edx = 232256, tf_ecx = 204800, tf_eax = 190, tf_trapno = 582, tf_err = 582, tf_eip = 42389, tf_cs = 31, tf_eflags = 582, tf_esp = -272639092, 
      tf_ss = 39}) at ../../i386/i386/trap.c:906
#9  0xf019216b in Xsyscall ()
#10 0x79e2 in ?? ()

From owner-freebsd-stable  Sat Mar  9 12:55:48 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA22796
          for stable-outgoing; Sat, 9 Mar 1996 12:55:48 -0800 (PST)
Received: from who.cdrom.com (who.cdrom.com [192.216.222.3])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA22790
          Sat, 9 Mar 1996 12:55:47 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by who.cdrom.com (8.6.12/8.6.11) with ESMTP id MAA13067
          ; Sat, 9 Mar 1996 12:36:38 -0800
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA21251; Sat, 9 Mar 1996 12:40:23 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199603091940.MAA21251@phaeton.artisoft.com>
Subject: Re: The continueing 2842/eisaconf argument
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Sat, 9 Mar 1996 12:40:23 -0700 (MST)
Cc: terry@lambert.org, stable@FreeBSD.org, current@FreeBSD.org
In-Reply-To: <199603090546.VAA22456@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 8, 96 09:46:44 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.org
X-Loop: owner-stable@FreeBSD.ORG
Precedence: bulk

> >I don't think the major work of the probe for the VLB card is the
> >scan of the EISA slot address space.  It's getting the configuration
> >information about the card, and that doesn't take EISA configuration
> >data to do it.
> 
> EISA configuration data (assuming you mean the stuff accessible through
> BIOS calls) is not used by any driver in FreeBSD.  Even if it was
> accessible to FreeBSD (and there's no reason it can't be with VM86() or
> having the boot blocks save off the data) it would have to be interpreted
> by each individual driver in order to be of any use.  So, although eisaconf
> may some day provide a mechanism for accessing this data, it certainly
> won't attempt processing it on its own.  Every eisa card we support
> provides some other way for either read/write or write only access to
> the data the driver needs.

The *only* reason you need the BIOS is to determine the per slot CMOS
area size.  Other than that, all EISA information is accessable as a
memory reference from protected mode.

I think the ability to access/manipulate EISA data is a lot closer
than the ever-out-of-reach-VM86().  If nothing else, the ram area
size *could* be passed via the boot code.

> It has to be up to each driver to request and then interpret this
> information if it makes sense for them to do so.  Many cards could
> care less about what's up in configuration space.  The 3c579 is one,
> the 2842 is another.  If we have to support EISA devices that don't
> want configuration data we can also support VLB devices that doesn't
> use configuration space information with no additional complexity.
> Its really a question of capability and use.

I think this assumes you use real mode/VM86 BIOS calls to get the
configuration data per EISA slot.  That way you would have a built
in stop for non-EISA cards.  If you access via memory reference, as
I would hope would be done, since VM86() seems too far off, then
the stop isn't there.

> The 2742 and the 2842 will continue to get most of the information
> about the card in the exact same way regardless of the availibility
> of configuration space data.  You're also not talking about
> stub code, but an additional probe that iterates through the slot
> address space since the 2842 can't reference the eisa code in your
> model since you don't want to have to have eisa0 in your config file.

Excuse me.  You are saying that iterating through the slot address
space is the only way to detect if the card is present or not?  I
know it is the method that happens to be used currently.  I wasn't
aware that the card was otherwise undetectable.

> I don't see forcing people to include eisa0 in their 
> config files as a problem since config will eventually die a horrible
> death, and the aic7xxx lkm will export its lkm dependancy graph so
> that if you don't have the eisaconf lkm in your system for some
> strange reason, it gives you a nice warning message.  If you can
> talk about eisa configuration space, I think its fair for me to say that
> config, in its present state, will go away.

The use of LKM's for boot drivers requires fallback drivers (in this
case, using VM86(), in other cases using OpenFirmware or PPCBug or the
Mac ROMs, etc.), which don't currently exist.  Further, I think they
require a move to COFF or ELF format so that there can be an associated
segment identification, and the fallbacks can be paged out and the
memory reclaimed, once the device-specific LKM has been loaded.

I think given these dependencies, I think it is also fair for me to
argue for an evolutionary step in that direction.


> Having an EISA config file doesn't mean that your ISA device responds
> to accesses at 0xzc80 and provides an EISA ID.

Correct. I never claimed this.  It does provide a graph entry so that
you don't screw yourself by locating one ISA card in an EISA slot
over top of another by forfeiture of the ability to detect the
non-relocatable resources being used by the ISA card.  That's really
all I'd have it used for as well.


> Having the config file is simply a way of aiding the ECU
> in telling you where conflicts are or restricing your configuration
> settings.  Once the ECU session is over, there's nothing their to
> tell FreeBSD about these ISA devices.

I will agree with the caveat the we are talking about the *current*
ECU code.  I believe the information that it does not have an EISA ID
is sufficient to indicate the cards existance and the need to probe
fixed cards with potentially invasive probes, at least the first
time the hardware is auto-configured.

This would require storing deltas and running a configuration/probe
log, ala Win95, which we need anyway for Lance, Floppy Tape, PS/2
mouse, and other devices which can't be non-invasively probed 100%
of the time (maybe including SIO3 vs. Mach cards).

> You can switch the dip switches on your 2842 all day, and FreeBSD will
> still find it.  You can also move your 2742 from slot to slot all day
> and FreeBSD will still find it.  Relocating the card doesn't prevent
> you from booting from it in either case so long as the card's bios is
> enabled.  Booting is a BIOS issue.  I can make a 2742 not bootable
> by disabling its BIOS too.

It does if I relocate something over top of its address space because
it didn't have a graph entry warning me it was there.

This is the reasoning that was put forth for the probe order changes,
which *have* caused some problems, but have overall been the *right*
thing to do.

> >I think that the 2842 needs to be probed later than the typical
> >EISA, PCI, PCMCIA, and PnP ISA devices, like other non-relocatable
> >devices.  It think it needs to have an invariant configuration graph
> >vector, *unlike* things which are found by the EISA probe.
> 
> The 2742 is just as non-relocatable as the 2842.  The 2742 locks out is irq
> register after the first time its written to (by the EISA configuration
> just after POST).

This is irrelevant.  EISA supports resetting this, in any case, or the
card would be impossible to reconfigure with the Adaptec tools.

The point is that even if an EISA space card has only one potential
space utilization topology, it is intrinsically *different* from an
ISA card because the slot configuration data (which is only present
on real EISA and is not used currently) can be consulted to determine
allowable potential topologies.

> Most EISA cards can't relocate their I/O range, but the
> Buslogic cards can relocate relocate their registers through a range of ISA
> compatibily areas.  The point is that the way you deal with registering
> relocatability has to be generic so you can deal with devices that vary in
> their degrees of flexibility regardless of their bus type.

I agree completely.  But while the per slot data provides this information
for true EISA cards, it does not do so for VLB cards pretending to be
EISA cards.


> >I think it is incorrect to probe the thing as an EISA device (are
> >there any motherboards that have EISA and VLB at the same time?
> >That would be a good counter-argument...).
> 
> Many, many EISA 486 systems have VL and EISA slots.  I own one of these
> systems.

This is seriously damning of my idea to use the EISA tag as a negative
indicator.  It means that there *would* need to be probe code for VLB
cards that pretend to be EISA cards.

But it does not mean that the probe would have to take the form of a
slot iteration.

BTW: I'm curious: how does the thing avoid slot configuration conflicts
in a real EISA system?  How is the VLB "fake-EISA" data exported so as
to not conflict with the real thing?  What if I plug two of these things
into two VLB slots in the same machine?


> Not all EISA devices are relocatable in the same ways.  I can find
> plenty of EISA devices that have the same relocation deficiencies
> as the 2842.  This is not a valid argument.

No, but all *real* EISA devices are detectably relocatable using the
slot configuration data that doesn't exist for VLB devices pretending
to be EISA devices.

This is what I meant when I said the configuration process would have
to dereference this data through the driver so that the VLB card
driver could fake the information that wouldn't exist if the config
attempted to access it directly without the indirection.  I think
this will be a bigger problem than card detection.

> Not all EISA cards are relocatable after their first initialization.
> We have to deal with these anyway.

We can.  But to deal at all, we have to have an idea of the relocatability,
as noted above, and VLB cards pretending to be EISA don't give that.

> No, it identifies it as an ISA device.  And, some non PnP ISA cards
> just like some EISA cards (EISA is not PnP BTW), allow you to dynamically
> change the IRQ.  So, what's your point?  If we had a configuration manager
> we woudn't allow flexible devices to conflict with non-flexible ones
> which has absolutly nothing to do with the 2842 being probed through
> eisaconf.

I agree with this... my point is that EISA configuration should be
autonomously seperable from the rest of the configuration.  The bus
attach should be on a per bus basis, and the lines shouldn't be
blurred by probes that cross over allowed boundries.  I think it
should work on the order of SCSI bus attachment, per bus.

I think it has to for the DEC Alpha AXP/PCI boxes: their ISA is
bridged from the PCI, not vice versa, and I know PReP/CHRP require
this, so machines based on the Motorolla chips have the same issue.
I expect there to be Intel based hardware with the same issues
soon (if it doesn't already exist somewhere).


> >It can tell that you don't have an EISA motherboard, which is the same
> >thing, by negative induction.
> 
> Assuming EISA and VLB are mutiually exclusive which they are not.

Right.  I blew it here.  But this is still resolvable by knowing how
EISA/VLB slot address space export works.  Per my "BTW" questions, above,
it should be possible to use knowledge of how the conflicts are dealt
with to allow detection of the thing as a VLB card.  Other cards
don't care about VLB vs. ISA, except in terms of giving us a hint
as to why the machine is failing that we can then passs on to the
user in terms of bus-on time management.


> The 3c509 in eisa configuration mode must be probed through eisaconf
> to be found.  It is reported as an ISA device.

If it *must* use the EISA probe, then I'd call it a "short EISA device".
That it can also be an ISA device via rejumpering is irrelevant.  It
should probably be reported as an EISA device.

> The 2842 is also found through eisaconf and is reported as an ISA
> device.

I still think this is the wrong place to probe it.

> Both show up as ISA device in lsdev too since their kdc parents
> are kdc_isa.  Where does the 2842 get classified as an EISA device?

By virtue of who makes the graph entry for it.  It has to do with
the wrong guy making the call.  I can make generic assumptions about
real EISA devices based on the per slot memory which is currently
ignored, but shouldn't be (you yourself admit that the current code
can't be the final code).


> >> The match routines and forcing a scan of the eisa address space makes
> >> no sense in a generic ISA probe (deals with non PnP hardware) configuration
> >> sub-manager.
> >
> >I agree.  Don't use the slot scan to locate the card; it isn't a
> >substitute for the majority of the work done by the probe code anyway.
> >Move the scan identification into an EISA-specific stub, and create
> >an ISA specific stub for the non-relocatable VLB card.
> 
> And I either make it always be in your kernel, or make it part of
> "eisa0", or I duplicate it.  What a waste.

It's not a part of your kernel if you leave ISA out.


> >I think you are stuck on using the fact that it exports EISA slot
> >data to trigger the probe (the manority of which is not dependent on
> >the fact that it's "EISA").  I think this is wrong, for the ordering
> >reasons stated above.
> 
> The ordering reasons don't hold water.  Nothing is gained by postponing
> the probe of the 2842.  Its just as "relocatable" as other EISA devices
> and its probe is non-invasive (and already performed by the eisaconf code).

No, the problem with having an ISA (VLB) device probed by the EISA code
is that the EISA code must know it's an ISA device and call a different
registration mechanism for it, since EISA devices will be known to be
relocatable and ISA devices not, in a future version of the device
registration code.  And it is caller dependent, unless you call through
the device code for the registration to allow it to be device dependent.


> >The VLB bus is not bridged.  The agregate bus-on time for N VLB cards
> >going in sequence is the issue for deciding to "tune" the VLB cards
> >down.
> 
> This as well as most tuning parameters should be left up to the user.
> I don't see FreeBSD trying to modify your DRAM refresh rates.  Its
> counter intuitive for the user to go in and set the bus on time for
> their adapter using the vendor supplied tools for this purpose
> (EISA config utility for the 2742, SCSI-Select for the 2842) and
> not have the OS honor them.

Windows95 sets defaults, and you use the "System Properties" dialog's
"Device Manager" tab to do tuning.  You don't use the vendor-supplied
tools, because doing so would not provide a unified control model
to the user.


> Your making up problems Terry.  Probe order is determined by bus type.

Except for the 2842.  Augh.

> Resource allocation is determined by the relative flexibility of devices
> regardless of bus type.

Yes.  And bus existance is seperable for the purposes of causing a
bus attach to occur, and you don't need to attach an EISA bus (or
have the code taking space in the kernel) when you don't have an
EISA bus on your machine.

Ideally, returning to the future you pointed at, the bus attach will
probe the existance of the bus, and load the code for it using VM86()
based I/O, then probe the EISA controller through which it made the
VM86() calls to load the probe code, and then load the controller probe
for the EISA controller (again using VM86()), probe it, and if there,
attach it and unload the VM86() fallback driver.  Subsequent devices
will be loaded through the card-specific driver.


> >Precisely!
> >
> >Once you can manipulate the configuration space, EISA cards are as
> >relocatable as ISA PnP cards!  But this VLB ccard, which you lie and
> >say is an EISA card by virtue of whose probe comes true, can *not*
> >be relocated!
> 
> Bullshit!  ISA PnP cards can relocate their I/O area most EISA cards can't.
> Some EISA cards do not allow relocation of anything after the EISA BIOS is
> done.  Furthermore, the data up in configuration space doesn't control the
> settings of the card.  You have to write to the cards own registers to do
> that which FreeBSD already has the capability to do without having access
> to configuration space.

This goes back to providing a unified device management view.  There
is nothing that says that an intervening reboot might not be required
for the management changes to take effect, or even to allow the use of
invase probes for otherwise unidentifiable hardware.

The ability to change soft configurations on a card that is soft
configurable belongs, properly, in the driver for that card, with
a single common configuration API shared by all drivers and a flag
for whether a reboot is required, etc..

The advantage to doing this type of relocation is that it is possible
to have a relocatable-without-reboot card that conflicts with either
a non-relocatable-card or a relocatable-with-reboot card in its two
available locations.  Better to be able to put up a message about the
conflict and allow the user choose to allow the configuration manager
to reboot the system than to lose 2 of 3 devices to conflicts.


> >You have to indirect all EISA configuration space code through the
> >driver, and then call common routines for *all other drivers*, and
> >for this one fake an immobile configuration space!  Bletch!  Talk
> >about unnecessary complexity!
> 
> This just isn't true.  All devices can call the same functions to
> register their resources, but it will only be at attach time that
> they will know if they have to change their settings and to what.

Then you must make registration variant so that the EISA code registers
the card as an ISA card.

This defeats the ability to seperate out (and discard) the EISA bus
attach code on machines without an EISA bus, in all cases.

It also defeats the ability to detect a go/no-go for EISA configuration
automatically (which you would otherwise do by looking for the EISA tag).
This isn't a problem now, but will be a problem if we allow bus
attachment to be demand-loaded via fallback drivers to cause every
running kernel to be ideally configured for the hardware it is running
on (for instance, I don't want to have EISA or ISA or PCI code in
an MCA machine, and I certainly want the ability to have a "pure PCI"
box).


> >EISA cards become relocatable within the conflict space.
> 
> The 2842 doesn't prevent this.

Requiring the EISA code to probe it prevents discarding the EISA
bus attach, or only performing the bus attach when the bus exists. 8-(.


> >Do you not agree that EISA cards should be relocatable by a resonable
> >configuration manager that knows EISA?
> 
> Sure.  Eisaconf is already poised to do this and the 2842 will 
> fit right in there.

The problem with "just class the 2842 as an EISA card for purposes
of probe" is still the EISA bus attach, which will be mandatory for
all ISA machines, since they potentially have a VLB bus, and we
are changing the meaning from "EISA bus attach" to "EISA or VLB bus
attach".

At least we can ignore the EISA bus attach because EISA is detectable
by the ROM tag... IFF VLB devices are classed as a special case of ISA,
not of EISA, in all cases (including the 2842).


> >Or that the 2842, a VLB card, should *not* be relocatable because
> >there is no standard mechanism for handling an EISA relocation of
> >a non-EISA card?
> 
> Hey, you can change the 2842's IRQ so it will tell that to the
> configuration manager.  The 2742 cannot change its IRQ, and it
> will tell the configuration manager that.  If you can handle one
> case, you can handle the other.

The 2742's ability to change it's IRQ is reflected in the data
from the EISA slot.  For this registration to be automatic rather
than dependent on the driver, it's necessary to seperate the identity
of EISA and VLB cards.

> Its not needed to support dynamic configuration of EISA devices.
> The 2742 just like the 2842 will not be making any calls into
> eisaconf to retrieve information from configuration space, so
> it doesn't matter if there is or is not any configuration space
> data for the 2742 or the 2842.  Other drivers may have different
> requirements.

I think the user configuration utility (if we even consult the user
on conflict resoloutions requiring a reboot, which we probably should)
will need to be able to access this data based on registration class
for the device.  This means making the class variant based on which
bus interface registered it, or setting the same flag in a per driver
basis by making the registration process go through the driver to
occur.  Isn't this an obvious consequence of having a non-EISA card
registered by EISA bus interface code?


Anyway, this discussion is getting into the arcane details of design
of generic configuration management, and has so moved out of the scope
of general interest (I think).

If we want to discuss this further, we should probably take it offline.

I'm more than happy to let you control the code.  I only wanted to
voice my concerns that I believe it is better to spend some extra
code seperating the bus identification from the probe and driver
code for the 2842.  I believe that it will save problems later.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-stable  Sat Mar  9 18:49:53 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id SAA17076
          for stable-outgoing; Sat, 9 Mar 1996 18:49:53 -0800 (PST)
Received: from who.cdrom.com (who.cdrom.com [192.216.222.3])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA17071
          Sat, 9 Mar 1996 18:49:50 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by who.cdrom.com (8.6.12/8.6.11) with ESMTP id SAA15733
          ; Sat, 9 Mar 1996 18:46:20 -0800
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA21251; Sat, 9 Mar 1996 12:40:23 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199603091940.MAA21251@phaeton.artisoft.com>
Subject: Re: The continueing 2842/eisaconf argument
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Sat, 9 Mar 1996 12:40:23 -0700 (MST)
Cc: terry@lambert.org, stable@FreeBSD.ORG, current@FreeBSD.ORG
In-Reply-To: <199603090546.VAA22456@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 8, 96 09:46:44 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@FreeBSD.ORG
X-Loop: owner-stable@FreeBSD.ORG
Precedence: bulk

> >I don't think the major work of the probe for the VLB card is the
> >scan of the EISA slot address space.  It's getting the configuration
> >information about the card, and that doesn't take EISA configuration
> >data to do it.
> 
> EISA configuration data (assuming you mean the stuff accessible through
> BIOS calls) is not used by any driver in FreeBSD.  Even if it was
> accessible to FreeBSD (and there's no reason it can't be with VM86() or
> having the boot blocks save off the data) it would have to be interpreted
> by each individual driver in order to be of any use.  So, although eisaconf
> may some day provide a mechanism for accessing this data, it certainly
> won't attempt processing it on its own.  Every eisa card we support
> provides some other way for either read/write or write only access to
> the data the driver needs.

The *only* reason you need the BIOS is to determine the per slot CMOS
area size.  Other than that, all EISA information is accessable as a
memory reference from protected mode.

I think the ability to access/manipulate EISA data is a lot closer
than the ever-out-of-reach-VM86().  If nothing else, the ram area
size *could* be passed via the boot code.

> It has to be up to each driver to request and then interpret this
> information if it makes sense for them to do so.  Many cards could
> care less about what's up in configuration space.  The 3c579 is one,
> the 2842 is another.  If we have to support EISA devices that don't
> want configuration data we can also support VLB devices that doesn't
> use configuration space information with no additional complexity.
> Its really a question of capability and use.

I think this assumes you use real mode/VM86 BIOS calls to get the
configuration data per EISA slot.  That way you would have a built
in stop for non-EISA cards.  If you access via memory reference, as
I would hope would be done, since VM86() seems too far off, then
the stop isn't there.

> The 2742 and the 2842 will continue to get most of the information
> about the card in the exact same way regardless of the availibility
> of configuration space data.  You're also not talking about
> stub code, but an additional probe that iterates through the slot
> address space since the 2842 can't reference the eisa code in your
> model since you don't want to have to have eisa0 in your config file.

Excuse me.  You are saying that iterating through the slot address
space is the only way to detect if the card is present or not?  I
know it is the method that happens to be used currently.  I wasn't
aware that the card was otherwise undetectable.

> I don't see forcing people to include eisa0 in their 
> config files as a problem since config will eventually die a horrible
> death, and the aic7xxx lkm will export its lkm dependancy graph so
> that if you don't have the eisaconf lkm in your system for some
> strange reason, it gives you a nice warning message.  If you can
> talk about eisa configuration space, I think its fair for me to say that
> config, in its present state, will go away.

The use of LKM's for boot drivers requires fallback drivers (in this
case, using VM86(), in other cases using OpenFirmware or PPCBug or the
Mac ROMs, etc.), which don't currently exist.  Further, I think they
require a move to COFF or ELF format so that there can be an associated
segment identification, and the fallbacks can be paged out and the
memory reclaimed, once the device-specific LKM has been loaded.

I think given these dependencies, I think it is also fair for me to
argue for an evolutionary step in that direction.


> Having an EISA config file doesn't mean that your ISA device responds
> to accesses at 0xzc80 and provides an EISA ID.

Correct. I never claimed this.  It does provide a graph entry so that
you don't screw yourself by locating one ISA card in an EISA slot
over top of another by forfeiture of the ability to detect the
non-relocatable resources being used by the ISA card.  That's really
all I'd have it used for as well.


> Having the config file is simply a way of aiding the ECU
> in telling you where conflicts are or restricing your configuration
> settings.  Once the ECU session is over, there's nothing their to
> tell FreeBSD about these ISA devices.

I will agree with the caveat the we are talking about the *current*
ECU code.  I believe the information that it does not have an EISA ID
is sufficient to indicate the cards existance and the need to probe
fixed cards with potentially invasive probes, at least the first
time the hardware is auto-configured.

This would require storing deltas and running a configuration/probe
log, ala Win95, which we need anyway for Lance, Floppy Tape, PS/2
mouse, and other devices which can't be non-invasively probed 100%
of the time (maybe including SIO3 vs. Mach cards).

> You can switch the dip switches on your 2842 all day, and FreeBSD will
> still find it.  You can also move your 2742 from slot to slot all day
> and FreeBSD will still find it.  Relocating the card doesn't prevent
> you from booting from it in either case so long as the card's bios is
> enabled.  Booting is a BIOS issue.  I can make a 2742 not bootable
> by disabling its BIOS too.

It does if I relocate something over top of its address space because
it didn't have a graph entry warning me it was there.

This is the reasoning that was put forth for the probe order changes,
which *have* caused some problems, but have overall been the *right*
thing to do.

> >I think that the 2842 needs to be probed later than the typical
> >EISA, PCI, PCMCIA, and PnP ISA devices, like other non-relocatable
> >devices.  It think it needs to have an invariant configuration graph
> >vector, *unlike* things which are found by the EISA probe.
> 
> The 2742 is just as non-relocatable as the 2842.  The 2742 locks out is irq
> register after the first time its written to (by the EISA configuration
> just after POST).

This is irrelevant.  EISA supports resetting this, in any case, or the
card would be impossible to reconfigure with the Adaptec tools.

The point is that even if an EISA space card has only one potential
space utilization topology, it is intrinsically *different* from an
ISA card because the slot configuration data (which is only present
on real EISA and is not used currently) can be consulted to determine
allowable potential topologies.

> Most EISA cards can't relocate their I/O range, but the
> Buslogic cards can relocate relocate their registers through a range of ISA
> compatibily areas.  The point is that the way you deal with registering
> relocatability has to be generic so you can deal with devices that vary in
> their degrees of flexibility regardless of their bus type.

I agree completely.  But while the per slot data provides this information
for true EISA cards, it does not do so for VLB cards pretending to be
EISA cards.


> >I think it is incorrect to probe the thing as an EISA device (are
> >there any motherboards that have EISA and VLB at the same time?
> >That would be a good counter-argument...).
> 
> Many, many EISA 486 systems have VL and EISA slots.  I own one of these
> systems.

This is seriously damning of my idea to use the EISA tag as a negative
indicator.  It means that there *would* need to be probe code for VLB
cards that pretend to be EISA cards.

But it does not mean that the probe would have to take the form of a
slot iteration.

BTW: I'm curious: how does the thing avoid slot configuration conflicts
in a real EISA system?  How is the VLB "fake-EISA" data exported so as
to not conflict with the real thing?  What if I plug two of these things
into two VLB slots in the same machine?


> Not all EISA devices are relocatable in the same ways.  I can find
> plenty of EISA devices that have the same relocation deficiencies
> as the 2842.  This is not a valid argument.

No, but all *real* EISA devices are detectably relocatable using the
slot configuration data that doesn't exist for VLB devices pretending
to be EISA devices.

This is what I meant when I said the configuration process would have
to dereference this data through the driver so that the VLB card
driver could fake the information that wouldn't exist if the config
attempted to access it directly without the indirection.  I think
this will be a bigger problem than card detection.

> Not all EISA cards are relocatable after their first initialization.
> We have to deal with these anyway.

We can.  But to deal at all, we have to have an idea of the relocatability,
as noted above, and VLB cards pretending to be EISA don't give that.

> No, it identifies it as an ISA device.  And, some non PnP ISA cards
> just like some EISA cards (EISA is not PnP BTW), allow you to dynamically
> change the IRQ.  So, what's your point?  If we had a configuration manager
> we woudn't allow flexible devices to conflict with non-flexible ones
> which has absolutly nothing to do with the 2842 being probed through
> eisaconf.

I agree with this... my point is that EISA configuration should be
autonomously seperable from the rest of the configuration.  The bus
attach should be on a per bus basis, and the lines shouldn't be
blurred by probes that cross over allowed boundries.  I think it
should work on the order of SCSI bus attachment, per bus.

I think it has to for the DEC Alpha AXP/PCI boxes: their ISA is
bridged from the PCI, not vice versa, and I know PReP/CHRP require
this, so machines based on the Motorolla chips have the same issue.
I expect there to be Intel based hardware with the same issues
soon (if it doesn't already exist somewhere).


> >It can tell that you don't have an EISA motherboard, which is the same
> >thing, by negative induction.
> 
> Assuming EISA and VLB are mutiually exclusive which they are not.

Right.  I blew it here.  But this is still resolvable by knowing how
EISA/VLB slot address space export works.  Per my "BTW" questions, above,
it should be possible to use knowledge of how the conflicts are dealt
with to allow detection of the thing as a VLB card.  Other cards
don't care about VLB vs. ISA, except in terms of giving us a hint
as to why the machine is failing that we can then passs on to the
user in terms of bus-on time management.


> The 3c509 in eisa configuration mode must be probed through eisaconf
> to be found.  It is reported as an ISA device.

If it *must* use the EISA probe, then I'd call it a "short EISA device".
That it can also be an ISA device via rejumpering is irrelevant.  It
should probably be reported as an EISA device.

> The 2842 is also found through eisaconf and is reported as an ISA
> device.

I still think this is the wrong place to probe it.

> Both show up as ISA device in lsdev too since their kdc parents
> are kdc_isa.  Where does the 2842 get classified as an EISA device?

By virtue of who makes the graph entry for it.  It has to do with
the wrong guy making the call.  I can make generic assumptions about
real EISA devices based on the per slot memory which is currently
ignored, but shouldn't be (you yourself admit that the current code
can't be the final code).


> >> The match routines and forcing a scan of the eisa address space makes
> >> no sense in a generic ISA probe (deals with non PnP hardware) configuration
> >> sub-manager.
> >
> >I agree.  Don't use the slot scan to locate the card; it isn't a
> >substitute for the majority of the work done by the probe code anyway.
> >Move the scan identification into an EISA-specific stub, and create
> >an ISA specific stub for the non-relocatable VLB card.
> 
> And I either make it always be in your kernel, or make it part of
> "eisa0", or I duplicate it.  What a waste.

It's not a part of your kernel if you leave ISA out.


> >I think you are stuck on using the fact that it exports EISA slot
> >data to trigger the probe (the manority of which is not dependent on
> >the fact that it's "EISA").  I think this is wrong, for the ordering
> >reasons stated above.
> 
> The ordering reasons don't hold water.  Nothing is gained by postponing
> the probe of the 2842.  Its just as "relocatable" as other EISA devices
> and its probe is non-invasive (and already performed by the eisaconf code).

No, the problem with having an ISA (VLB) device probed by the EISA code
is that the EISA code must know it's an ISA device and call a different
registration mechanism for it, since EISA devices will be known to be
relocatable and ISA devices not, in a future version of the device
registration code.  And it is caller dependent, unless you call through
the device code for the registration to allow it to be device dependent.


> >The VLB bus is not bridged.  The agregate bus-on time for N VLB cards
> >going in sequence is the issue for deciding to "tune" the VLB cards
> >down.
> 
> This as well as most tuning parameters should be left up to the user.
> I don't see FreeBSD trying to modify your DRAM refresh rates.  Its
> counter intuitive for the user to go in and set the bus on time for
> their adapter using the vendor supplied tools for this purpose
> (EISA config utility for the 2742, SCSI-Select for the 2842) and
> not have the OS honor them.

Windows95 sets defaults, and you use the "System Properties" dialog's
"Device Manager" tab to do tuning.  You don't use the vendor-supplied
tools, because doing so would not provide a unified control model
to the user.


> Your making up problems Terry.  Probe order is determined by bus type.

Except for the 2842.  Augh.

> Resource allocation is determined by the relative flexibility of devices
> regardless of bus type.

Yes.  And bus existance is seperable for the purposes of causing a
bus attach to occur, and you don't need to attach an EISA bus (or
have the code taking space in the kernel) when you don't have an
EISA bus on your machine.

Ideally, returning to the future you pointed at, the bus attach will
probe the existance of the bus, and load the code for it using VM86()
based I/O, then probe the EISA controller through which it made the
VM86() calls to load the probe code, and then load the controller probe
for the EISA controller (again using VM86()), probe it, and if there,
attach it and unload the VM86() fallback driver.  Subsequent devices
will be loaded through the card-specific driver.


> >Precisely!
> >
> >Once you can manipulate the configuration space, EISA cards are as
> >relocatable as ISA PnP cards!  But this VLB ccard, which you lie and
> >say is an EISA card by virtue of whose probe comes true, can *not*
> >be relocated!
> 
> Bullshit!  ISA PnP cards can relocate their I/O area most EISA cards can't.
> Some EISA cards do not allow relocation of anything after the EISA BIOS is
> done.  Furthermore, the data up in configuration space doesn't control the
> settings of the card.  You have to write to the cards own registers to do
> that which FreeBSD already has the capability to do without having access
> to configuration space.

This goes back to providing a unified device management view.  There
is nothing that says that an intervening reboot might not be required
for the management changes to take effect, or even to allow the use of
invase probes for otherwise unidentifiable hardware.

The ability to change soft configurations on a card that is soft
configurable belongs, properly, in the driver for that card, with
a single common configuration API shared by all drivers and a flag
for whether a reboot is required, etc..

The advantage to doing this type of relocation is that it is possible
to have a relocatable-without-reboot card that conflicts with either
a non-relocatable-card or a relocatable-with-reboot card in its two
available locations.  Better to be able to put up a message about the
conflict and allow the user choose to allow the configuration manager
to reboot the system than to lose 2 of 3 devices to conflicts.


> >You have to indirect all EISA configuration space code through the
> >driver, and then call common routines for *all other drivers*, and
> >for this one fake an immobile configuration space!  Bletch!  Talk
> >about unnecessary complexity!
> 
> This just isn't true.  All devices can call the same functions to
> register their resources, but it will only be at attach time that
> they will know if they have to change their settings and to what.

Then you must make registration variant so that the EISA code registers
the card as an ISA card.

This defeats the ability to seperate out (and discard) the EISA bus
attach code on machines without an EISA bus, in all cases.

It also defeats the ability to detect a go/no-go for EISA configuration
automatically (which you would otherwise do by looking for the EISA tag).
This isn't a problem now, but will be a problem if we allow bus
attachment to be demand-loaded via fallback drivers to cause every
running kernel to be ideally configured for the hardware it is running
on (for instance, I don't want to have EISA or ISA or PCI code in
an MCA machine, and I certainly want the ability to have a "pure PCI"
box).


> >EISA cards become relocatable within the conflict space.
> 
> The 2842 doesn't prevent this.

Requiring the EISA code to probe it prevents discarding the EISA
bus attach, or only performing the bus attach when the bus exists. 8-(.


> >Do you not agree that EISA cards should be relocatable by a resonable
> >configuration manager that knows EISA?
> 
> Sure.  Eisaconf is already poised to do this and the 2842 will 
> fit right in there.

The problem with "just class the 2842 as an EISA card for purposes
of probe" is still the EISA bus attach, which will be mandatory for
all ISA machines, since they potentially have a VLB bus, and we
are changing the meaning from "EISA bus attach" to "EISA or VLB bus
attach".

At least we can ignore the EISA bus attach because EISA is detectable
by the ROM tag... IFF VLB devices are classed as a special case of ISA,
not of EISA, in all cases (including the 2842).


> >Or that the 2842, a VLB card, should *not* be relocatable because
> >there is no standard mechanism for handling an EISA relocation of
> >a non-EISA card?
> 
> Hey, you can change the 2842's IRQ so it will tell that to the
> configuration manager.  The 2742 cannot change its IRQ, and it
> will tell the configuration manager that.  If you can handle one
> case, you can handle the other.

The 2742's ability to change it's IRQ is reflected in the data
from the EISA slot.  For this registration to be automatic rather
than dependent on the driver, it's necessary to seperate the identity
of EISA and VLB cards.

> Its not needed to support dynamic configuration of EISA devices.
> The 2742 just like the 2842 will not be making any calls into
> eisaconf to retrieve information from configuration space, so
> it doesn't matter if there is or is not any configuration space
> data for the 2742 or the 2842.  Other drivers may have different
> requirements.

I think the user configuration utility (if we even consult the user
on conflict resoloutions requiring a reboot, which we probably should)
will need to be able to access this data based on registration class
for the device.  This means making the class variant based on which
bus interface registered it, or setting the same flag in a per driver
basis by making the registration process go through the driver to
occur.  Isn't this an obvious consequence of having a non-EISA card
registered by EISA bus interface code?


Anyway, this discussion is getting into the arcane details of design
of generic configuration management, and has so moved out of the scope
of general interest (I think).

If we want to discuss this further, we should probably take it offline.

I'm more than happy to let you control the code.  I only wanted to
voice my concerns that I believe it is better to spend some extra
code seperating the bus identification from the probe and driver
code for the 2842.  I believe that it will save problems later.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.