Re: newbus and modem(s)

[Doug Rabson]

On Mon, 19 Apr 1999, Peter Wemm wrote:

> > > 
> > > I don't think I understand. The DRIVER_MODULE declaration goes in the
> > > downstream driver, not the upstream bus. The bus doesn't need any
> > > knowledge of what drivers might be attached to it.
> > 
> > Well, what about the i386 nexus?  It specifically creates connection points
> > for apm, npx, eisa, isa, and pci as children.
> > 
> > However, pci devices don't do this to attach to their parent.  I am
> > obviously missing something. :-)
> 
> Never mind, I understand now. :-)
> 
> For the benefit of the 'cc' list, and to check my understanding, let me run
> through it..
> 
> The parents pick up the children in one of two ways.  For a 'smart' bus,
> like pci, usb, eisa, etc, the bus probes itself and adds an "unidentified"
> child (NULL name, -1 unit) with the known ID.  The bus mechanism then uses
> this to poll the drivers to see which one(s) want to claim that ID.  It
> knows who the children are because of the DECLARE_MODULE() statement.  This
> means that a "smart" (or self identifying) bus doesn't need anything more
> to manage the relationship.
> 
> On the other hand, there's isa, which is quite dumb.  In this case, the bus
> looks up it's "hint" list and specifically adds the requested children from
> those hints, and using the supplied irq, port, etc values from the hints.
> The drivers then use that data to probe for the existance of the device.
> 
> The nexus is a little bit different..  It doesn't have things to
> specifically look for, so it adds the children manually.  It could have
> used the resource database to find the requested things to attach to the
> nexus in pretty much the same way as the isa bus does.
> 
> And then there's the old isa drivers...  They attach themselves to the isa
> parent device class on the fly, there is no DECLARE_MODULE() table for all
> the old isa (and perhaps PCI too) drivers.
> 
> Doug, is that right so far? :-)

Perfectly.

> 
> Now what I'm curious about is how to handle the nexus and isa/eisa better
> so they don't need to explicitly name the children.  On one hand it could
> look at the hints table to see all the 'at nexus?' declarations, but I
> think it might be better to go for a hunt to locate all the children it can
> find.  One way to do this might be to simply add a heap of "unidentified"
> devices and let the bus mechanism find all the devices that are children
> and let them probe themselves while ignoring the fake device id's.  Perhaps
> this could change the probe order enough so that isa and eisa won't be
> attached until after pci has been recursively probed.

I'm not sure how this would work. At the nexus, I think it has to know
what the possibly attached devices are (or at least a list of names). The
NetBSD code does a simple probe (e.g. checking for pci config method or
looking for the mainboard ID) before adding devices.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: HEADS UP!!!! Important instructions for -current users!

[Nick Hibma]

 > To make the communication more close, it is possible to post
 > the achievements and plans to hackers or current. Do you think
 > this appropriate?

Yes.


Nick
FreeBSD USB Project.




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

Re: newbus and isa auto irq

[Doug Rabson]

On Mon, 19 Apr 1999, Luoqi Chen wrote:

> > This is not happening for the maddr stuff.   
> > I suspect this would do better:
> > 
> > if (portsize > 0)
> > isa_set_portsize(dev, portsize);
> > if (dvp->id_iobase >= 0)
> > isa_set_port(dev, dvp->id_iobase);
> > if (dvp->id_irq != 0)
> > isa_set_irq(dev, ffs(dvp->id_irq) - 1);
> > if (dvp->id_drq != -1)
> > isa_set_drq(dev, dvp->id_drq);
> > if (dvp->id_maddr != 0)
> > isa_set_maddr(dev,
> >   (int) dvp->id_maddr - 
> > KERNBASE);
> > if (dvp->id_msize != 0)
> > isa_set_msize(dev, dvp->id_msize);
> > I'm not sure about the "nothing" value for id_drq though, it might need to
> > be 0 - but that's a valid dma channel.
> > 
> > IMHO, isa_release_resources() clearing of the default values for the probe
> > hints is a timebomb...  I thought about adding a seperate store for the
> > "hint" values rather than using the id_foo[0] entries, and leaving the
> > tracked resource entries for alloc/free without risking the hints.
> > 
> > Cheers,
> > -Peter
> > 
> Off the topic, I think we should replace (dvp->id_maddr - KERNBASE) with
> kvtop(dvp->id_maddr), too much assumption about vm layout...

I agree. I think your fix for the irq problem is the correct one too.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: PCI VGA card becomes ISA

[Doug Rabson]

On Mon, 19 Apr 1999, Blaz Zupan wrote:

> I noticed that after the latest round of new-bus changes, my PCI VGA card
> is now recognized as a generic ISA card by the kernel. I don't see any ill
> effects from this, but the new-bus developers may want to know, in case it
> breaks something else.
> 
> The VGA card is a S3 Trio64V+. Here's the dmesg output I get. I don't have
> an old dmesg output before the changes, but the card was recognized by
> its name and it was using IRQ 9.

I know about this. The vga probe is stubbed out in pci at the moment. The
reason is that syscons requires a vga0 device on isa but pci already
allocated vga0 and things go downhill from there...

Its harmless and it should go away soon if we can reorganise syscons' vga
driver slightly.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: Peer review (was: HEADS UP!!!! Important instructions for -current users!)

[Doug Rabson]

On Tue, 20 Apr 1999, Greg Lehey wrote:

> On Monday, 19 April 1999 at 21:46:30 -0700, Jordan K. Hubbard wrote:
> >> integrate newconfig stuff.  I hope you have the flexibility
> >> to think seriously the integration of newconfig.
> >
> > As long as it doesn't significantly impact the work already in
> > progress, I think the flexibility is certainly there.
> >
> >> To make the communication more close, it is possible to post
> >> the achievements and plans to hackers or current. Do you think
> >> this appropriate?
> >
> > I think it's more than appropriate, it's *mandatory* if you wish to
> > solve the communication problem.  Posting regular updates on your
> > progress on -hackers or -current (depending on applicability) is
> > strongly encouraged.
> 
> But as we have seen, posting on -hackers doesn't guarantee that
> anybody of any importance will see it.

Possibly -current is better for ongoing development reports. I read both
:-)

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: Peer review (was: HEADS UP!!!! Important instructions for -current users!)

[Nick Hibma]

 > > > I think it's more than appropriate, it's *mandatory* if you wish to
 > > > solve the communication problem.  Posting regular updates on your
 > > > progress on -hackers or -current (depending on applicability) is
 > > > strongly encouraged.
 > > 
 > > But as we have seen, posting on -hackers doesn't guarantee that
 > > anybody of any importance will see it.
 > 
 > Possibly -current is better for ongoing development reports. I read both
 > :-)

Which means that someone will crosspost it if necessary...

Post and forget.

Nick






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

IPFW as built in kernel feature seems broken.

[Ian West]

Hi, since rougly the time the recent changes were commited, I have
been unable
to compile a kernel with the IPFW funtionality build in. It still
works as
an KLD, but I would prefer not to run it this way. (It bothers me that
if
something caused it to be unloaded, or to fail to load, the machine
could
and would quite cheerfully pass everything.) Is this a transient
thing, or
is this a permanent change ? I have cvsupped and rebuilt quite a few
times,
the last only about 30 minutes ago, and it still appears to be the
same.
Thankyou for any feeback you can give me on this.

On a brighter note, my machine is running fine with a fresh kernel,
dual
PII-350, vr0, fxp0 lan cards, bt848 video capture card and matrox
millenium
II agp card. No problems at all. (Other than the IPFW thing)

Sorry if this has nothing to do with these changes, I did post a query
a
couple of days back, but there has been no response to this.

Thankyou.
Regards,
Ian West.


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

Having trouble with the new ATAPI driver

[William Liao]

Hi,
I did a CVSUP and make world at 4/15, then I decided to try the
new ATAPI driver on my box. So I made some necessary changes to 
my kernel config and made a new kernel.
But after boot, it always hangs on mounting disks.
The message is: swapon: /dev/wd0s1b: Device not configured
Then I tried to boot into single user mode and mount the slices
manually. Unfortunately, same thing happened again when I tried
to mount my /home, /var, etc. 
Mount replied: /dev/wd2s1e: Device not configured.

Did I miss anything?... Thanks for your help.

FYI, my BSD box mixes using SCSI and IDE disks, the /kernel and
main system files are all on the old 1G SCSI disk.

Oh yes, I forgot to comment out the old wd driver at first time, 
so the boot made some corrupt to the file system, will that hurt?.. 
(Of course, I fscked)

Following is my dmesg output, kernel config, and fstab.

===
dmesg
===
Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #0: Mon Apr 19 15:42:08 CST 1999
r...@dns.te.fcu.edu.tw:/usr/src/sys/compile/LEMON
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium/P55C (200.46-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x543  Stepping=3
  Features=0x8001bf
real memory  = 100663296 (98304K bytes)
avail memory = 95027200 (92800K bytes)
Preloaded elf kernel "kernel.ata" at 0xc02b3000.
Probing for devices on PCI bus 0:
chip0:  rev 0x01 on pci0.0.0
chip1:  rev 0x01 on pci0.7.0
ata-pci0:  rev 0x01 on pci0.7.1
ata-pci0: Busmastering DMA supported
ata0 at 0x01f0 irq 14 on ata-pci0
ata1 at 0x0170 irq 15 on ata-pci0
chip2:  rev 0x01 on pci0.7.3
vga0:  rev 0x00 int a irq 4 on pci0.11.0
ahc0:  rev 0x00 int a irq 9 on pci0.13.0
ahc0: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs
fxp0:  rev 0x08 int a irq 10 on 
pci0.15.0
fxp0: Ethernet address 00:90:27:57:c6:34
Probing for PnP devices:
Probing for devices on the ISA bus:
sc0 on isa
sc0: VGA color <8 virtual consoles, flags=0x0>
atkbdc0 at 0x60-0x6f on motherboard
atkbd0 irq 1 on isa
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa
sio0: type 8250
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16550A
ata-isa1: already registered as ata0
ata1 not found at 0x1f0
ata-isa2: already registered as ata1
ata2 not found at 0x170
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1.44MB 3.5in
vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa
npx0 on motherboard
npx0: INT 16 interface
Intel Pentium detected, installing workaround for F00F bug
IP packet filtering initialized, divert enabled, rule-based forwarding 
disabled, logging limited to 20 packets/entry
ata0: master: settting up UDMA2 mode on PIIX4 chip OK
ad0:  ATA-3 disk at ata0 as master
ad0: 8063MB (16514064 sectors), 16383 cyls, 16 heads, 63 S/T, 512 B/S
ad0: piomode=4, dmamode=2, udmamode=2
ad0: 16 secs/int, 0 depth queue, DMA mode
ata0: slave: settting up WDMA2 mode on PIIX3/4 chip OK
ad1:  ATA-? disk at ata0 as slave 
ad1: 4134MB (8467200 sectors), 8960 cyls, 15 heads, 63 S/T, 512 B/S
ad1: piomode=4, dmamode=2, udmamode=-1
ad1: 16 secs/int, 0 depth queue, DMA mode
ata1: master: settting up WDMA2 mode on PIIX3/4 chip OK
ad2:  ATA-? disk at ata1 as master
ad2: 519MB (1064448 sectors), 1056 cyls, 16 heads, 63 S/T, 512 B/S
ad2: piomode=4, dmamode=2, udmamode=-1
ad2: 8 secs/int, 0 depth queue, DMA mode
afd0:  rewriteable drive at ata1 as slave 
afd0: 96MB (196608 sectors), 32 cyls, 64 heads, 96 S/T, 512 B/S
afd0: Unknown media (0x0)
Waiting 3 seconds for SCSI devices to settle
changing root deviceda0 at ahc0 bus 0 target 1 lun 0
da0:  Fixed Direct Access SCSI-2 device 
da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
da0: 1041MB (2131992 512 byte sectors: 255H 63S/T 132C)
 to da0s2a
cd0 at ahc0 bus 0 target 2 lun 0
cd0:  Removable CD-ROM SCSI-2 device 
cd0: 10.000MB/s transfers (10.000MHz, offset 15)
cd0: Attempt to query device size failed: NOT READY, Medium not present

==
kernel config
==
#
# LINT -- config file for checking all the sources, tries to pull in
#   as much of the source tree as it can.
#
#   $Id: LINT,v 1.501 1998/11/06 20:32:22 msmith Exp $
#
# NB: You probably don't want to try running a kernel built from this
# file.  Instead, you should start from GENERIC, and add options from
# this file as required.
#

#
# This directive is mandatory; it defines the architecture to be
# configured for; in this case, the 386 family based IBM-PC and
# compatibles.
#
machine "i386"
ident   LEMON
maxusers32

options FAILSAFE

config  kernel  root on da0

#cpu"I386_CPU"
#cpu"I486_CPU"
cpu "I586_CPU"  # aka Pentium(tm)
cpu "I686_CPU"  # aka Pentium Pro(tm)

options "COMPAT_43"

options SYSVSHM
options SYSVSE

Re: HEADS UP!!!! Important instructions for -current users!

[Warner Losh]

Thank you for the update on progress of new config, Nishiyama-san.
Are snapshots of the new config work available to members outside the
development team?  If so, can you post a URL pointing to them.

Warner


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

Re: PCI VGA card becomes ISA

[Khetan Gajjar]

Around Today, "Doug Rabson" wrote :

DR>  Its harmless and it should go away soon if we can reorganise syscons' vga
DR>  driver slightly.

I'm seeing this as well, but as you've said, it's harmless.
What I am "concerned" about is from sources last night,
the error
haveseen_isadev() called - FIXME!
after the isa0 bus has been probed, and something I haven't seen before :
(cd1:aha0:0:6:0): CCB 0xc51952e0 - timed out
indicating a problem with my Yamaha CD-RW.

Is this something serious ?

As an aside, I'm trying Soren's ATA code, and it combined with
the new-bus changes (neither of which I was using before) has made a
dramatic difference speed-wise (or maybe it's just a
placebo effect). Nice work :)

Dmesg below.

Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #0: Tue Apr 20 13:00:36 SAST 1999
khe...@chain.freebsd.os.org.za:/usr/src/sys/compile/CHAIN
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 200455994 Hz
CPU: Pentium/P54C (200.46-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x52c  Stepping=12
  Features=0x1bf
real memory  = 100663296 (98304K bytes)
avail memory = 94699520 (92480K bytes)
Preloaded elf kernel "kernel" at 0xc02d9000.
ccd0-1: Concatenated disk drivers
Probing for PnP devices:
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  on motherboard
pci0:  on pcib0
chip0:  at device 0.0 on pci0
ata0:  at device 0.1 on pci0
ata-pci0: Busmastering DMA supported
ata0 at 0x01f0 irq 14 on ata-pci0
ata1 at 0x0170 irq 15 on ata-pci0
isab0:  at device 1.0 on pci0
pcib1:  at device 2.0 on pci0
pci1:  on pcib1
de0:  at device 11.0 on pci0
de0: interrupting at irq 5
de0: SMC 21041 [10Mb/s] pass 1.1
de0: address 00:00:c0:f9:2f:c8
isa0:  on motherboard
haveseen_isadev() called - FIXME!
aha0 at port 0x330-0x333 irq 11 drq 6 on isa0
aha0: AHA-1542CF FW Rev. C.0 (ID=45) SCSI Host Adapter, SCSI ID 7, 16 CCBs
aha0: interrupting at irq 11
atkbdc0:  at port 0x60 on isa0
atkbd0:  on atkbdc0
atkbd0: interrupting at irq 1
psm0:  on atkbdc0
psm0: model IntelliMouse, device ID 3
psm0: interrupting at irq 12
vga0:  on isa0
sc0:  on isa0
sc0: VGA color <16 virtual consoles, flags=0x0>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio0: interrupting at irq 4
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sio1: interrupting at irq 3
ppc0 at port 0x378 irq 7 on isa0
ppc0: Winbond chipset (NIBBLE-only) in COMPATIBLE mode
plip0:  on ppbus 0
lpt0:  on ppbus 0
lpt0: Interrupt-driven port
ppi0:  on ppbus 0
ppc0: interrupting at irq 7
de0: enabling 10baseT port
Intel Pentium detected, installing workaround for F00F bug
ata0: master: settting up generic WDMA2 mode OK
ad0:  ATA-? disk at ata0 as master
ad0: 1033MB (2116800 sectors), 2100 cyls, 16 heads, 63 S/T, 512 B/S
ad0: piomode=4, dmamode=2, udmamode=-1
ad0: 16 secs/int, 0 depth queue, DMA mode
ata0: slave: settting up generic WDMA2 mode OK
ad1:  ATA-? disk at ata0 as slave 
ad1: 1039MB (2128896 sectors), 2112 cyls, 16 heads, 63 S/T, 512 B/S
ad1: piomode=4, dmamode=2, udmamode=-1
ad1: 8 secs/int, 0 depth queue, DMA mode
ata1: master: settting up generic WDMA2 mode OK
ad2:  ATA-? disk at ata1 as master
ad2: 2015MB (4127760 sectors), 4095 cyls, 16 heads, 63 S/T, 512 B/S
ad2: piomode=4, dmamode=2, udmamode=-1
ad2: 16 secs/int, 0 depth queue, DMA mode
Waiting 15 seconds for SCSI devices to settle
changing root device to wd1s1a
da0 at aha0 bus 0 target 2 lun 0
da0:  Fixed Direct Access SCSI-2 device 
aha0: ahafetchtransinfo - Inquire Setup Info Failed
da0: 3.300MB/s transfers
da0: 516MB (1057616 512 byte sectors: 64H 32S/T 516C)
da1 at aha0 bus 0 target 4 lun 0
da1:  Fixed Direct Access SCSI-2 device 
da1: 3.300MB/s transfers
da1: 515MB (1056708 512 byte sectors: 64H 32S/T 515C)
cd0 at aha0 bus 0 target 5 lun 0
cd0:  Removable CD-ROM SCSI-2 device 
cd0: 3.300MB/s transfers
cd0: cd present [325725 x 2048 byte records]
(cd1:aha0:0:6:0): CCB 0xc51952e0 - timed out
(cd1:aha0:0:6:0): CCB 0xc51952e0 - timed out
aha0: No longer in timeout
cd1 at aha0 bus 0 target 6 lun 0
cd1:  Removable CD-ROM SCSI-2 device 
cd1: 3.300MB/s transfers
cd1: Attempt to query device size failed: NOT READY, Medium not present - tray 
closed



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

Re: HEADS UP!!!! Important instructions for -current users!

[Tomoaki NISHIYAMA]

From: Warner Losh 
Subject: Re: HEADS UP Important instructions for -current users! 
Date: Tue, 20 Apr 1999 09:27:56 -0600
Message-ID: <199904201527.jaa03...@harmony.village.org>

imp> Thank you for the update on progress of new config, Nishiyama-san.
imp> Are snapshots of the new config work available to members outside the
imp> development team?  If so, can you post a URL pointing to them.

Yes, the source code is available to everyone in the world.
General information is shown at http://www.jp.freebsd.org/newconfig/
Snapshots will appear at
ftp://daemon.jp.freebsd.org/pub/FreeBSD-jp/newconfig/snapshot/

You can also CVSup newconfig source from cvsup.jp.FreeBSD.ORG or
its mirrors (cvsup[2-5].jp.FreeBSD.ORG). 
Example of CVSup file is: 
 begin example
  # Defaults that apply to all the collections
  *default host=cvsup.jp.freebsd.org
  *default base=/some/where/you/want
  *default prefix=/some/where/you/want/prefix
  *default release=cvs
  *default delete use-rel-suffix

  jp-newconfig
 end example

The test implementation code of dynamic configuration by 
UCHIYAMA Yasushi [newconfig-jp 1710] is at 
ftp://ftp.nop.or.jp/users/uch/PCMCIA/FreeBSD/
sys4c990410-newconfig990413-kld990419test2.patch.gz
Note that this code is a test implementation and does not yet work
completely.


Tomoaki Nishiyama
  e-mail:tomo...@biol.s.u-tokyo.ac.jp
 Department of Biological Sciences,
Graduate School of Science, The University of Tokyo


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

Re: Having trouble with the new ATAPI driver

[Geoff Rehmet]

William Liao writes :
> 
> Hi,
> I did a CVSUP and make world at 4/15, then I decided to try the
> new ATAPI driver on my box. So I made some necessary changes to 
> my kernel config and made a new kernel.
> But after boot, it always hangs on mounting disks.
> The message is: swapon: /dev/wd0s1b: Device not configured
> Then I tried to boot into single user mode and mount the slices
> manually. Unfortunately, same thing happened again when I tried
> to mount my /home, /var, etc. 
> Mount replied: /dev/wd2s1e: Device not configured.
> 
> Did I miss anything?... Thanks for your help.

I've actually seen the same symptoms, with one of my swap partitions,
but it is now also giving me this with one of my file systems, on
fsck, at bootup.  It drops me to single user (since fsck -p fails),
I run fsck -p manually, it is happy, and I go multiuser.
The same happened with the swap partition in question - a second
"swapon -a", and everything worked - that slice has however since
become my /tmp, as I already had enough swap.

I have only been getting "device not configured" errors on ad2 though.

Geoff.
-- 
Geoff Rehmet,
The Internet Solution
geo...@is.co.za; ge...@rucus.ru.ac.za; c...@freebsd.org
tel: +27-83-292-5800


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

Re: ATA driver for alpha

[Erik Haugen Bakke]

> On Mon, 19 Apr 1999 e...@habatech.no wrote:
> 
> > 
> > On 19-Apr-99 Doug Rabson wrote:
> > > I have ported the new ATA driver to the FreeBSD/alpha. This provides
> > > support for IDE disks and cdroms. The version of the driver in the tree 
> > > has only been tested on one old 433au machine so your mileage may vary
> > >:-). For the adventurous, add these lines to your kernel config:
> > > 
> > Hooray!
> > Just one question, though...
> > Will this driver support the Cypress CY82C693 controller on the AlphaPC
> > 164SX boards?
> 
> I think so.
> 
If anyone has / will compile a boot disk with the new kernel,
I would be very grateful if they could make it available for
download somewhere. :)

Anyone tracking -current?

Regards
---
Erik H. Bakke



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

Re: ATA driver for alpha (fwd)

[Nick Hibma]

-- Forwarded message --
Date: Tue, 20 Apr 1999 18:29:04 +0200 (CEST)
From: Nick Hibma 
To: Erik Haugen Bakke 
Subject: Re: ATA driver for alpha


Jordan, you said nowadays one can simply compile a kernel < 1.44Mb and
stick it on the disk kern.flp?

People could appreciate this. I for one would like to make demo floppies
to send to companies having supplied devices for USB support to show
their devices at work.


Nick


 > > > > I have ported the new ATA driver to the FreeBSD/alpha. This provides
 > > > > support for IDE disks and cdroms. The version of the driver in the 
 > > > > tree 
 > > > > has only been tested on one old 433au machine so your mileage may vary
 > > > >:-). For the adventurous, add these lines to your kernel config:
 > > > > 
 > > > Hooray!
 > > > Just one question, though...
 > > > Will this driver support the Cypress CY82C693 controller on the AlphaPC
 > > > 164SX boards?
 > > 
 > > I think so.
 > > 
 > If anyone has / will compile a boot disk with the new kernel,
 > I would be very grateful if they could make it available for
 > download somewhere. :)
 > 
 > Anyone tracking -current?
 > 
 > Regards
 > ---
 > Erik H. Bakke
 > 
 > 
 > 
 > To Unsubscribe: send mail to majord...@freebsd.org
 > with "unsubscribe freebsd-current" in the body of the message
 > 
 > 




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

Build of kernel, and make world broken on my machine

[Kenneth Wayne Culver]

For the last week, I haven't been able to get my kernel to build, or a
make world to complete. I didn't have the kernel problems until recently,
when the newbus stuff was done. This is my error when building the kernel.
(after typing config -r MYKERNEL; make depend; make)

cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing
-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions
-ansi  -no
stdinc -I- -I. -I../.. -I../../../include  -DKERNEL -include opt_global.h
-elf
ioconf.c
ioconf.c:103: warning: `psm0_count' redefined
ioconf.c:68: warning: this is the location of the previous definition
ioconf.c:97: redefinition of `psm0_resources'
ioconf.c:64: `psm0_resources' previously defined here
ioconf.c:100: warning: excess elements in array initializer after
`psm0_resource
s'
ioconf.c:101: warning: excess elements in array initializer after
`psm0_resource
s'
*** Error code 1

Stop.
culverk:/usr/src/sys/compile/MYKERNEL#

make -DNOGAMES world
always seems to crash when building libc but it stops at a different place
each time.

Kenneth Culver



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

Re: ATA driver for alpha (fwd)

[Daniel C. Sobral]

Nick Hibma wrote:
> 
> Jordan, you said nowadays one can simply compile a kernel < 1.44Mb and
> stick it on the disk kern.flp?

It is possible. Even more, you can add kld modules to that disk, and
then edit loader.rc to load them too, so you don't even need to
compile a kernel.

> People could appreciate this. I for one would like to make demo floppies
> to send to companies having supplied devices for USB support to show
> their devices at work.

So, anyone up for creating a web page generating custom kern.klp
disks, with features not found in GENERIC, using a cgi script? :-)

If you limit this to adding kld modules, it would be surprisingly
easy to do it.

--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org

"Well, Windows works, using a loose definition of 'works'..."


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

Re: Build of kernel, and make world broken on my machine

[Daniel C. Sobral]

Kenneth Wayne Culver wrote:
> 
> For the last week, I haven't been able to get my kernel to build, or a
> make world to complete. I didn't have the kernel problems until recently,
> when the newbus stuff was done. This is my error when building the kernel.
> (after typing config -r MYKERNEL; make depend; make)

I don't know about world, but the kernel will build much better once
you remove the duplicate psm0 lines from MYKERNEL.

--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org

"Well, Windows works, using a loose definition of 'works'..."


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

Which -current snapshot is good to install?

[nordwick]

I have a box with an old 3.0-current distribution on it and want to move it to
4.0-current, but the upgrade path looks daunting, so I thought that I would
just reinstall (besides, I could use the practice).   I grabbed the
4.0-19990418-current/floppies files, but after a visual conf and removing
unused drivers, then probbing the busses, it panics with an invalid
page fault (I will report this more in depth later).

So, what would be the safest snapshot to install with?

thanks
-jay


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

Some questions about booting with newbus

[Jeroen Ruigrok/Asmodai]

Some questions I have pertaining the newbus stuff (and as a reminder to you
Peter, thanks for looking into it):

Am I the only one where booting with -v doesn't really do any verbose
booting?

Also, as talked about with Peter, -v should report unclaimed/unmatched
devices, currently it doesn't...

Also, I am trying to work up a driver here, but have only a list of vendor
ID's for the PCI bus, anyone have a textfile with some more ID's such as
the classes, etc..?

Thanks,

---
Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl
The FreeBSD Programmer's Documentation Project 
Network/Security Specialist  
*BSD: Powered by Knowledge & Know-how 


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

Re: newbus and modem(s)

[Peter Wemm]

Doug Rabson wrote:
> On Mon, 19 Apr 1999, Peter Wemm wrote:
[..]
> > Now what I'm curious about is how to handle the nexus and isa/eisa better
> > so they don't need to explicitly name the children.  On one hand it could
> > look at the hints table to see all the 'at nexus?' declarations, but I
> > think it might be better to go for a hunt to locate all the children it can
> > find.  One way to do this might be to simply add a heap of "unidentified"
> > devices and let the bus mechanism find all the devices that are children
> > and let them probe themselves while ignoring the fake device id's.  Perhaps
> > this could change the probe order enough so that isa and eisa won't be
> > attached until after pci has been recursively probed.
> 
> I'm not sure how this would work. At the nexus, I think it has to know
> what the possibly attached devices are (or at least a list of names). The
> NetBSD code does a simple probe (e.g. checking for pci config method or
> looking for the mainboard ID) before adding devices.

Thinking about this some more, the same problem is applicable to "smart"
isa devices where the driver can find the card and the settings without
any help.  Presently it won't even get probed unless there is an 'at isa?'
hint to cause the driver to be connected to isa.

Presently, drivers are added to busses mostly in two ways.  The first is
where the bus has identification, and each identifier is added listing
a device_id with an unknown driver/unit.  The new-bus code will try all
of the registered child drivers in turn until it finds one that matches
and stops there.  The isa bus on the other hand uses the hints to create
a device instance that needs verification/probing.  If there's no hint,
the driver doesn't get a chance to probe.

What I'd like would be for the busses to be able to call all the child
drivers to let them look for themselves, and not stop until all are probed.
For isa this would mean hint-less probing capabilities.  For example, a
driver could know that the hardware lives at one of 4 IO port addresses, so
it could test them to see if it looks likely that there is one there.

Obviously there is danger in this as calling the generic probe routines
with no hints at all (ie: all zero) will cause rather bad results on most
existing drivers.  Perhaps there could be a specific 'identify' method for
drivers that support this.

ie: the probe/attach sequence would become:

bus identifies what it can, ie: find device id's or look up resource hints.
bus calls all child drivers to probe what has been found or hinted at
bus calls all child drivers with an identify methods to see if they can
  find something on their own without an id or hint.

This would be applicable to the nexus code as it would call all it's child
driver 'identify' methods which would cause them to attach themselves to
the nexus.  You could then do a 'kldload eisa' and have the nexus get a
notification of a new driver added, and then in doing the normal probe of
the known devices (ie: none), the new eisa driver will have it's identify
called which could then cause a new instance to be attached to the nexus,
like what is presently hard coded.

Does that make sense or am I rambling? :-)

Cheers,
-Peter




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

Re: PCI VGA card becomes ISA

[Doug Rabson]

On Tue, 20 Apr 1999, Khetan Gajjar wrote:

> Around Today, "Doug Rabson" wrote :
> 
> DR>  Its harmless and it should go away soon if we can reorganise syscons' vga
> DR>  driver slightly.
> 
> I'm seeing this as well, but as you've said, it's harmless.
> What I am "concerned" about is from sources last night,
> the error
> haveseen_isadev() called - FIXME!
> after the isa0 bus has been probed, and something I haven't seen before :
> (cd1:aha0:0:6:0): CCB 0xc51952e0 - timed out
> indicating a problem with my Yamaha CD-RW.
> 
> Is this something serious ?

Its a reminder that the implementation of isa_compat is not quite
complete. Not many drivers use this feature of the old isa code so we
might just convert them all.

> As an aside, I'm trying Soren's ATA code, and it combined with
> the new-bus changes (neither of which I was using before) has made a
> dramatic difference speed-wise (or maybe it's just a
> placebo effect). Nice work :)

I can't take credit for the ATA code.  It is nice though :-)

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: newbus and modem(s)

[Doug Rabson]

On Wed, 21 Apr 1999, Peter Wemm wrote:

> Doug Rabson wrote:
> > On Mon, 19 Apr 1999, Peter Wemm wrote:
> [..]
> > > Now what I'm curious about is how to handle the nexus and isa/eisa better
> > > so they don't need to explicitly name the children.  On one hand it could
> > > look at the hints table to see all the 'at nexus?' declarations, but I
> > > think it might be better to go for a hunt to locate all the children it 
> > > can
> > > find.  One way to do this might be to simply add a heap of "unidentified"
> > > devices and let the bus mechanism find all the devices that are children
> > > and let them probe themselves while ignoring the fake device id's.  
> > > Perhaps
> > > this could change the probe order enough so that isa and eisa won't be
> > > attached until after pci has been recursively probed.
> > 
> > I'm not sure how this would work. At the nexus, I think it has to know
> > what the possibly attached devices are (or at least a list of names). The
> > NetBSD code does a simple probe (e.g. checking for pci config method or
> > looking for the mainboard ID) before adding devices.
> 
> Thinking about this some more, the same problem is applicable to "smart"
> isa devices where the driver can find the card and the settings without
> any help.  Presently it won't even get probed unless there is an 'at isa?'
> hint to cause the driver to be connected to isa.
> 
> Presently, drivers are added to busses mostly in two ways.  The first is
> where the bus has identification, and each identifier is added listing
> a device_id with an unknown driver/unit.  The new-bus code will try all
> of the registered child drivers in turn until it finds one that matches
> and stops there.  The isa bus on the other hand uses the hints to create
> a device instance that needs verification/probing.  If there's no hint,
> the driver doesn't get a chance to probe.
> 
> What I'd like would be for the busses to be able to call all the child
> drivers to let them look for themselves, and not stop until all are probed.
> For isa this would mean hint-less probing capabilities.  For example, a
> driver could know that the hardware lives at one of 4 IO port addresses, so
> it could test them to see if it looks likely that there is one there.
> 
> Obviously there is danger in this as calling the generic probe routines
> with no hints at all (ie: all zero) will cause rather bad results on most
> existing drivers.  Perhaps there could be a specific 'identify' method for
> drivers that support this.
> 
> ie: the probe/attach sequence would become:
> 
> bus identifies what it can, ie: find device id's or look up resource hints.
> bus calls all child drivers to probe what has been found or hinted at
> bus calls all child drivers with an identify methods to see if they can
>   find something on their own without an id or hint.
> 
> This would be applicable to the nexus code as it would call all it's child
> driver 'identify' methods which would cause them to attach themselves to
> the nexus.  You could then do a 'kldload eisa' and have the nexus get a
> notification of a new driver added, and then in doing the normal probe of
> the known devices (ie: none), the new eisa driver will have it's identify
> called which could then cause a new instance to be attached to the nexus,
> like what is presently hard coded.
> 
> Does that make sense or am I rambling? :-)

It certainly makes sense (it would be sort of like the old eisa code where
the driver digs around and finds all of the devices which it can drive). I
have to figure out how this fits in with the interface system which really
needs a device to hang off.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: Build of kernel, and make world broken on my machine

[Warner Losh]

In message  
Kenneth Wayne Culver writes:
: ioconf.c:103: warning: `psm0_count' redefined

This is quickly becoming a FAQ.  Remove the second psm0 device in your
config file.

Warner


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

Re: Some questions about booting with newbus

[Doug Rabson]

On Tue, 20 Apr 1999, Jeroen Ruigrok/Asmodai wrote:

> Some questions I have pertaining the newbus stuff (and as a reminder to you
> Peter, thanks for looking into it):
> 
> Am I the only one where booting with -v doesn't really do any verbose
> booting?
> 
> Also, as talked about with Peter, -v should report unclaimed/unmatched
> devices, currently it doesn't...
> 
> Also, I am trying to work up a driver here, but have only a list of vendor
> ID's for the PCI bus, anyone have a textfile with some more ID's such as
> the classes, etc..?

There are a lot of class and subclass definitions in pcireg.h

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: Some questions about booting with newbus

[Warner Losh]

In message  Jeroen Ruigrok/Asmodai writes:
: Am I the only one where booting with -v doesn't really do any verbose
: booting?
: Also, as talked about with Peter, -v should report unclaimed/unmatched
: devices, currently it doesn't...

I've seen that it does.  I have a chip made by Sony that no driver
claims.  Likely a firewire or MPEG video chip of some flavor.

: Also, I am trying to work up a driver here, but have only a list of vendor
: ID's for the PCI bus, anyone have a textfile with some more ID's such as
: the classes, etc..?

You could look in http://www.halcyon.com/scripts/jboemler/pci/pcicode

for a list of most vendors (that's how I know the chip is made by
Sony) and for many cards (but none from Sony :-(.

Warner


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

Newbus in UPDATING

[Warner Losh]

Now that there has been some experience with newbus, I'd like to put
together an entry for updating.  So far I have the following problems:
sio pnp/pccard support broken
some (which ones?) sound drivers broken
psm0 duplicate/duplicate devices in general
keyboard/mouse attachment

Anything else?

Warner


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

Re: ATA driver for alpha

[Nick Hibma]

Great idea.


I'll be the first one to try it with the USB support...

> > People could appreciate this. I for one would like to make demo floppies
> > to send to companies having supplied devices for USB support to show
> > their devices at work.
> 
> So, anyone up for creating a web page generating custom kern.klp
> disks, with features not found in GENERIC, using a cgi script? :-)
> 
> If you limit this to adding kld modules, it would be surprisingly
> easy to do it.
> 
> --
> Daniel C. Sobral  (8-DCS)
> d...@newsguy.com
> d...@freebsd.org
> 
>   "Well, Windows works, using a loose definition of 'works'..."
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 
> 

-- 
e-Mail: hi...@skylink.it




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

Re: newbus and modem(s)

[Nick Hibma]

What about creating a second bus, isa_s, for ISA self probing?

Nick

On Wed, 21 Apr 1999, Peter Wemm wrote:

> Doug Rabson wrote:
> > On Mon, 19 Apr 1999, Peter Wemm wrote:
> [..]
> > > Now what I'm curious about is how to handle the nexus and isa/eisa better
> > > so they don't need to explicitly name the children.  On one hand it could
> > > look at the hints table to see all the 'at nexus?' declarations, but I
> > > think it might be better to go for a hunt to locate all the children it 
> > > can
> > > find.  One way to do this might be to simply add a heap of "unidentified"
> > > devices and let the bus mechanism find all the devices that are children
> > > and let them probe themselves while ignoring the fake device id's.  
> > > Perhaps
> > > this could change the probe order enough so that isa and eisa won't be
> > > attached until after pci has been recursively probed.
> > 
> > I'm not sure how this would work. At the nexus, I think it has to know
> > what the possibly attached devices are (or at least a list of names). The
> > NetBSD code does a simple probe (e.g. checking for pci config method or
> > looking for the mainboard ID) before adding devices.
> 
> Thinking about this some more, the same problem is applicable to "smart"
> isa devices where the driver can find the card and the settings without
> any help.  Presently it won't even get probed unless there is an 'at isa?'
> hint to cause the driver to be connected to isa.
> 
> Presently, drivers are added to busses mostly in two ways.  The first is
> where the bus has identification, and each identifier is added listing
> a device_id with an unknown driver/unit.  The new-bus code will try all
> of the registered child drivers in turn until it finds one that matches
> and stops there.  The isa bus on the other hand uses the hints to create
> a device instance that needs verification/probing.  If there's no hint,
> the driver doesn't get a chance to probe.
> 
> What I'd like would be for the busses to be able to call all the child
> drivers to let them look for themselves, and not stop until all are probed.
> For isa this would mean hint-less probing capabilities.  For example, a
> driver could know that the hardware lives at one of 4 IO port addresses, so
> it could test them to see if it looks likely that there is one there.
> 
> Obviously there is danger in this as calling the generic probe routines
> with no hints at all (ie: all zero) will cause rather bad results on most
> existing drivers.  Perhaps there could be a specific 'identify' method for
> drivers that support this.
> 
> ie: the probe/attach sequence would become:
> 
> bus identifies what it can, ie: find device id's or look up resource hints.
> bus calls all child drivers to probe what has been found or hinted at
> bus calls all child drivers with an identify methods to see if they can
>   find something on their own without an id or hint.
> 
> This would be applicable to the nexus code as it would call all it's child
> driver 'identify' methods which would cause them to attach themselves to
> the nexus.  You could then do a 'kldload eisa' and have the nexus get a
> notification of a new driver added, and then in doing the normal probe of
> the known devices (ie: none), the new eisa driver will have it's identify
> called which could then cause a new instance to be attached to the nexus,
> like what is presently hard coded.
> 
> Does that make sense or am I rambling? :-)
> 
> Cheers,
> -Peter
> 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 
> 

-- 
e-Mail: hi...@skylink.it




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

Re: Newbus in UPDATING

[Doug Rabson]

On Tue, 20 Apr 1999, Warner Losh wrote:

> 
> Now that there has been some experience with newbus, I'd like to put
> together an entry for updating.  So far I have the following problems:
>   sio pnp/pccard support broken
>   some (which ones?) sound drivers broken
>   psm0 duplicate/duplicate devices in general
>   keyboard/mouse attachment
> 
> Anything else?

Machines with multiple host-pci bridges (Intel 450NX machines I think)
will not probe the second bridge yet.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: Newbus in UPDATING

[Thomas Dean]

From: Jose Gabriel Marcelino 

vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa
fb0: vga0, vga, type:VGA (5), flags:0x700ff
vga0:  on isa0

known problem.


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

solid NFS patch #6 avail for -current - need testers files)

[Matthew Dillon]

NFS patch #6 is now available for -current.  This patch has been
extensively tested with NFS and with FFS+softupdates and has not
screwed up yet, so I'm reasonably confident that it will not
scrap whole filesystems :-)

http://www.backplane.com/FreeBSD4/

Please remember to back-out all prior patches before applying this one.
Note that the memory-zeroing code ( which is committed to -current ), is
*correct* and should not be disabled.

This patch is for CURRENT ONLY.  Do not apply to -3.x unless you like
seeing computer equipment melt!

The only difference between patch #5 and patch #6 is that the VMIO
directory backing mods have been removed.  These mods worked, but 
appear to have resulted in an occassional softupdates panic during
'installworld'.  It is more important for us to have a rock solid 
implementation then majorly optimized implementation, so...  The
patch will probably return later on when we figure out why it is 
causing softupdates to panic.

Please post bug reports to -current or -hackers.

-Matt



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

Re: solid NFS patch #6 avail for -current - need testers files)

[Amancio Hasty]

What does this patch fix?

Tnks!
Amancio

-- 

 Amancio Hasty
 ha...@star-gate.com




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

ed0: device timeout

[Martin Blapp]

Hi,

Maybe current is not the right one to send my problem to - but I'm not
subscribed on freebsd.mobile.

Recently I bought a new laptop and my ed0-pccard stopped working. This
happened before the newconfig stuff came in. I first thought there were
some irq-related problems, but I wasn't able to figure out where the
problems are. The pccard-controller is now on irq 3 (SIO1 is disabled). I
also tried to put it on irq 9 or 10 with set machdep.pccard.pcic_irq,
after I disabled the soundcard. That worked, but the result was the same.
Is suppose that the irq's aren't as free they should be. I tried other
io-settings, other irq's, the result was the same. 

Curious: A 2.2.8 PA0 system worked on this Laptop without problems,
the card gets recognized and no timeouts appeared at all.  

Any help is welcome. I've no idea what my problem could be.

some dmsg-output from fresh kernel:
---

chip0:  at device 0.0 on pci0
isab0:  at device 1.0 on pci0
ide_pci0:  at device 1.1 on pci0
uhci0:  at device 1.2 on  pci0
usb0:  on uhci0 
chip1:  at device 1.3 on pci0
chip2:  at device 3.0 on pci0
chip3:  at device 3.1 on pci0 



PC-Card VLSI 82C146 (5 mem & 2 I/O windows)
pcic: controller irq 3
Initializing PC-card drivers: ed 



Card inserted, slot 0
ed0: address 00:c0:f0:1c:b8:20, type NE2000 (16 bit) 
ed0: device timeout
ed0: device timeout
ed0: device timeout
ed0: device timeout 

dmesg | grep irq:
-

uhci0: interrupting at irq 11
fdc0: interrupting at irq 6
fdc0:  at port 0x3f0-0x3f7 irq 6 drq 2 on isa0
wdc0 at port 0x1f0-0x1f7 irq 14 on isa0
wdc0: interrupting at irq 14
wdc1 at port 0x170-0x177 irq 15 on isa0
wdc1: interrupting at irq 15
atkbd0: interrupting at irq 1
psm0: interrupting at irq 12
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: interrupting at irq 4
ppc0 at port 0x378 irq 7 on isa0
ppc0: interrupting at irq 7
pcic: controller irq 3

cat /dev/sndstat :
-

OPL-2/OPL-3 FM at 0x388
SoundPort at 0x534 irq 5 drq 1,3
MPU-401 (UART) at 0x320 irq 9 

/etc/pccard.conf :
--

# Generally available IO ports
io 0x280 - 0x2F0 0x300 - 0x360
# Generally available IRQs (Built-in sound-card owners remove 5)
irq 5 9 10
# Available memory slots
memory  0xd4000 96k
memory  0xc4000 32k 

# Kingston Ethernet card
card "Kingston" "KNE-PC2"
config  0x22 "ed0" 10
insert  echo "Kingston card inserted"
insert  /etc/pccard_home ed0
remove  echo "Kingston card removed"
remove  /sbin/ifconfig ed0 delete  

kernel-konfig:
--

# PCCARD (PCMCIA) support
controller  card0
device  pcic0 at card?
device  pcic1 at card? 
device ed0 

altern. kernel-konfig:
--
controller  card0
device  pcic0 at card?
device  pcic1 at card? 
device ed0 at isa? port 0x340 net irq 10 iomem 0xd8000

pccardc dumpcis:


Configuration data for card in slot 0
Tuple #1, code = 0x1 (Common memory descriptor), length = 2
000:  00 ff
Common memory device information:
Device number 1, type No device, WPS = OFF
Speed = No speed, Memory block size = reserved, 32 units
Tuple #2, code = 0x17 (Attribute memory descriptor), length = 3
000:  49 00 ff
Attribute memory device information:
Device number 1, type EEPROM, WPS = ON
Speed = 250nS, Memory block size = 512b, 1 units
Tuple #3, code = 0x20 (Manufacturer ID), length = 4
000:  86 01 00 01
PCMCIA ID = 0x186, OEM ID = 0x100
Tuple #4, code = 0x21 (Functional ID), length = 2
000:  06 00
Network/LAN adapter

Tuple #5, code = 0x15 (Version 1 info), length = 21
000:  04 01 4b 69 6e 67 73 74 6f 6e 00 4b 4e 45 2d 50
010:  43 32 00 00 ff
Version = 4.1, Manuf = [Kingston],card vers = [KNE-PC2]
Addit. info = []
Tuple #6, code = 0x1a (Configuration map), length = 5
000:  01 23 f8 03 03
Reg len = 2, config register addr = 0x3f8, last config = 0x23
Registers: XX--
Tuple #7, code = 0x1b (Configuration entry), length = 21
000:  e0 81 1d 3f 55 4d 5d 06 86 46 26 fc 24 c5 60 00
010:  03 1f 30 b8 9e
Config index = 0x20(default)
Interface byte = 0x81 (I/O)  wait signal supported
Vcc pwr:
Nominal operating supply voltage: 5 x 1V
Minimum operating supply voltage: 4.5 x 1V
Maximum operating supply voltage: 5.5 x 1V
Continuous supply current: 1 x 100mA
Max current average over 1 second: 1 x 100mA, ext = 0x46
Max current average over 10 ms: 2 x 100mA
Wait scale Speed = 1.5 x 10 us
Card decodes 4 address lines, 8 Bit I/O only
IRQ modes: Level
IRQ level = 4
Tuple #8, code = 0x1b (Configuration entry), length = 7
000:  20 08 c5 60 00 02 1f
Config 

Re: solid NFS patch #6 avail for -current - need testers files)

[Alfred Perlstein]

On Tue, 20 Apr 1999, Amancio Hasty wrote:

> What does this patch fix?

NFS clients getting blocks of 0x00 in the cache.

try to link a large object over NFS without the patches, you'll see
what i mean.

Matt, i'm going to test your patches now, I really appreciate the work
and explanations you've given as to the problem and the solution you've
devised.  If anyone's gonna find a NFS bug :)

I'm impressed with the changes you're proposing for the VM system
and was wondering if these patches include the work for directory
caching you've been working on.

Thanks, 
-Alfred 

> 
>   Tnks!
>   Amancio
> 
> -- 
> 
>  Amancio Hasty
>  ha...@star-gate.com



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

New ATA driver and crash dumps

[Christopher Masto]

My machine panicked today for the first time since switching to the
new ATA drivers, and I noticed that I no longer have crash dumps.
Is this something that is expected to be put back in soon?

I know Søren's a busy guy, and I'm glad we have the results of his
work.  I just hope the old drivers don't get killed off until the
replacement has the same functionality.

Then again, wddump() is only 100 lines of code, so I should probably
try to fix it myself before whining.
-- 
Christopher Masto Senior Network Monkey  NetMonger Communications
ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net

Free yourself, free your machine, free the daemon -- http://www.freebsd.org/


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

new-bus, a moderate success report.

[Matthew Jacob]

To also follow the 'new-bus' success report story... I configured and
built for a AMI mother board- two PCI busses... the only thing that was a
gotcha was that de0 and de1 (both on separate PCI busses) got swapped in
the changeover.

-matt





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

Re: ATA driver for alpha (fwd)

[Jordan K. Hubbard]

> Jordan, you said nowadays one can simply compile a kernel < 1.44Mb and
> stick it on the disk kern.flp?

Yep!  You can even make one > 1.44MB and gzip it first (but remember
to call it /kernel.gz or the loader won't be smart enough to un-gzip
it).  As long as the kernel is compiled with options MFS_ROOT and
options MFS, it will know to look for the mfsroot image in memory
(which the kern.flp's loader.rc will also ask for).

- Jordan


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

Re: solid NFS patch #6 avail for -current - need testers

[Mark Newton]

Matthew Dillon wrote:

 > This patch is for CURRENT ONLY.  Do not apply to -3.x unless you like
 > seeing computer equipment melt!

Wow.  I makes NFS access *that* fast?!

   - mark :-)


Mark Newton   Email:  new...@internode.com.au (W)
Network Engineer  Email:  new...@atdot.dotat.org  (H)
Internode Systems Pty Ltd Desk:   +61-8-82232999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223


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

RE: newbus and modem(s)

[paul]

> -Original Message-
> From: Peter Wemm [mailto:pe...@netplex.com.au]
> Sent: 20 April 1999 21:20
> To: Doug Rabson
> Cc: Takanori Watanabe; freebsd-current@freebsd.org
> Subject: Re: newbus and modem(s) 
> 
> 
> Doug Rabson wrote:
> > On Mon, 19 Apr 1999, Peter Wemm wrote:
> [..]
> > > Now what I'm curious about is how to handle the nexus and 
> isa/eisa better
> > > so they don't need to explicitly name the children.  On 
> one hand it could
> > > look at the hints table to see all the 'at nexus?' 
> declarations, but I
> > > think it might be better to go for a hunt to locate all 
> the children it can
> > > find.  One way to do this might be to simply add a heap 
> of "unidentified"
> > > devices and let the bus mechanism find all the devices 
> that are children
> > > and let them probe themselves while ignoring the fake 
> device id's.  Perhaps
> > > this could change the probe order enough so that isa and 
> eisa won't be
> > > attached until after pci has been recursively probed.
> > 
> > I'm not sure how this would work. At the nexus, I think it 
> has to know
> > what the possibly attached devices are (or at least a list 
> of names). The
> > NetBSD code does a simple probe (e.g. checking for pci 
> config method or
> > looking for the mainboard ID) before adding devices.
> 
> Thinking about this some more, the same problem is applicable 
> to "smart"
> isa devices where the driver can find the card and the 
> settings without
> any help.  Presently it won't even get probed unless there is 
> an 'at isa?'
> hint to cause the driver to be connected to isa.
> 
> Presently, drivers are added to busses mostly in two ways.  
> The first is
> where the bus has identification, and each identifier is added listing
> a device_id with an unknown driver/unit.  The new-bus code 
> will try all
> of the registered child drivers in turn until it finds one 
> that matches
> and stops there.  The isa bus on the other hand uses the 
> hints to create
> a device instance that needs verification/probing.  If 
> there's no hint,
> the driver doesn't get a chance to probe.
> 
> What I'd like would be for the busses to be able to call all the child
> drivers to let them look for themselves, and not stop until 
> all are probed.
> For isa this would mean hint-less probing capabilities.  For 
> example, a
> driver could know that the hardware lives at one of 4 IO port 
> addresses, so
> it could test them to see if it looks likely that there is one there.

Doesn't this get in to the area we discussed some time back on the new-bus
list about changing the way probing works so that instead of the pci code
calling all the device drivers it just looks the device id up in a table and
assigns that driver?

I much prefer that direction than having all drivers called.

> Obviously there is danger in this as calling the generic 
> probe routines
> with no hints at all (ie: all zero) will cause rather bad 
> results on most
> existing drivers.  Perhaps there could be a specific 
> 'identify' method for
> drivers that support this.
> 
> ie: the probe/attach sequence would become:
> 
> bus identifies what it can, ie: find device id's or look up 
> resource hints.
> bus calls all child drivers to probe what has been found or hinted at
> bus calls all child drivers with an identify methods to see 
> if they can
>   find something on their own without an id or hint.

If I'm reading this right then you'd call an identify function in all
available isa drivers and have them try and identify hardware? The risk here
is that isa drivers/devices don't play well together and will trash you're
machine if asked to probe for hardware that isn't present.

Paul.


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

Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Dillon]

:
:Matt, i'm going to test your patches now, I really appreciate the work
:and explanations you've given as to the problem and the solution you've
:devised.  If anyone's gonna find a NFS bug :)
:
:I'm impressed with the changes you're proposing for the VM system
:and was wondering if these patches include the work for directory
:caching you've been working on.
:
:Thanks, 
:-Alfred 

No, we removed it temporarily while we track down a softupdates bug.
Plus it's more an optimization ... not really a bug fix, so it should
be separate.

I didn't really propose that we do what I said in the last posting 
in re: to the VM system, though it is a possibility.  Any changes at
that level would not occur for a year or so ... not until 4.x becomes
stable and 5.x becomes current.  It wouldn't be worthwhile unless we
could simplify some of the complexity in the existing setup, and there
may be other ways to do that ( like, for example, embedding the I/O within
the buffer cache routines rather then requiring that the caller issue the
I/O, which encapsulates a great deal of the buffer cache's current
complexity ).

-Matt
Matthew Dillon 




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

Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Dillon]

:What does this patch fix?
:
:   Tnks!
:   Amancio
:
: Amancio Hasty
: ha...@star-gate.com

It mainly fixes interactions between mmap(), read(), and write() on
NFS files.  Many utilities ( such as the compiler/linker ) these days
use a combination of the three and NFS was making assumptions that 
would leave a VM page partially uncovered - where the NFS system is storing
critical data in the page but the VM system didn't know it was.
The mmap-zero fixes that were committed last week brought the problem
to light.

As part of the fix, a bunch of things were ripped out of the buffer cache
code.  For example, the b_validoff/b_validend fields were ripped out
because only NFS previously used them ( but don't any more ).

Also pieces of the buffer cache code were rewritten in regards to dealing
with the B_CACHE bit, leading to more optimal code in the critical path
( fewer scans the the b_pages array when figuring out the B_CACHE state
of a struct buf ).

And some other stuff.  The whole thing stems from fixes made to -current
over the last several months, fixes made by Luoqi, Alan, Julian, DG, 
and me.  Luoqi concentrated on fixing up the vm_page_t valid/dirty handling
and struct buf b_offset handling when dealing with small-block devices
( people may recall that this fixed, then broke, then fixed msdos floppy
mounts that would occur after a ufs mount attempt, and also fixed CDROM 
panics ).  The rest of us were working on a mmap-zeroing problem, NFS,
and a mmap-garbage-after-file-EOF problem brought up by Tor.  A number
of vnode interlock issues came up that we fixed, a getnewbuf()
supervisor stack overflow was fixed (I rewrote getnewbuf()), a bunch of
low-memory handling issues were dealt with but there are still a few
left.  A few minor bugs in softupdates were fixed with Kirk's help. 
A VNOP/MMAP deadlock was fixed.  Tor & DG and someone else threw in fixes 
for KVM exhaustion in large-memory subsystems, the ability to 
handle > 2G of ram, and BSDI compatibility w/ the new KVM increase. 
Earlier this year I tackled basic bugs in the VM system, rewrote the
swapper, rewrote the VN device, and formalized and documented most of
the VM system, and Alan and I began removing unused cruft.

All in all, it has been a good beginning to the year.

-Matt
Matthew Dillon 




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

Re: cvs commit: src/sys/i386/conf LINT GENERIC

[Amancio Hasty]

> 
> P.S.: USBDI as in, our version of it. The people from the consortium
> kicked us out.

Can you elaborate on the reason that USBDI does not FreeBSD 
to be involved with the consortium?

Tnks
P.S.: Just got a 3 COM USB modem and I am going over the USB specs right now 8)



-- 

 Amancio Hasty
 ha...@star-gate.com




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

Re: New ATA driver and crash dumps

[Soren Schmidt]

It seems Christopher Masto wrote:
> My machine panicked today for the first time since switching to the
> new ATA drivers, and I noticed that I no longer have crash dumps.
> Is this something that is expected to be put back in soon?
> 
> I know Søren's a busy guy, and I'm glad we have the results of his
> work.  I just hope the old drivers don't get killed off until the
> replacement has the same functionality.
> 
> Then again, wddump() is only 100 lines of code, so I should probably
> try to fix it myself before whining.

I know :), it has just not been done yet. It will be done eventually
but I have other areas in the driver I want finish first.

Also the old wd driver will probably not be killed off entirely, as 
its the only one we have that support old ST506/ESDI drives.

-Søren


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