IPFW does not seem to work except as kld on recent builds (last day or so)
Hi, I noticed that IPFW as a built in kernel options quietly doesn't seem to work, no compile errors, but the resultant kernel passes evrything and does not appear to contain ipfw funtionality. ipfw -a l returns ipfw: getsockopt(IP_FW_GET): Protocol not available. kldload ipfw and it all works fine. Is the intention for it to longer be a available except as a kld module ? Thankyou for any feedback. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Make World breaks in /sys/modules/fxp
As stated. The Makefile calls for perl5, which is not available at that time. Replacing perl5 by perl solves the problem. Cheers, PYD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: login
:On Sat, Apr 17, 1999 at 12:38:25PM -0700, Annelise Anderson wrote:
:
: I think it was, thanks. I changed the order of the nameservers
: in resolv.conf and it no longer happens. :)
:
:What about setting up a caching DNS server on your machine ?
:You could configure forwarders.
:
:options {
: directory /etc/namedb;
: forwarders {
: aaa.bbb.ccc.ddd;
: };
:};
:
:in /etc/resolv.conf
:
:domain your.domain
:nameserver 127.0.0.1
:
:Had to do many many (~600) DNS requests in a script and had
:a lame nameserver over network about 3-4 hops away.
:
:After configuring a local DNS server the script was much (!) faster.
:
:--
:Andreas Klemm http://www.FreeBSD.ORG/~andreas
I'm going to pass on a lesson I learned at BEST.
Setting a forwarders chain sucks, because named doesn't do the right thing
with it -- even if you have multiple entries, if the first one is
unreachable it will create a significant delay for nearly all your
DNS requests which can seriously degrade scripts and servers.
The safest way to set up a reliable DNS server is very similar to what
you have above, but without forwarders.
* You setup a local DNS server
* You install a root cache. i.e., no forwarders. No remote cache... only
local caching. root.zone can be obtained from ftp.rs.internic.net as
the file domain/root.zone.gz.
zone . {
type hint;
file root.zone;
};
* You then secondary the domains that are most critical for your machine's
proper booting and operation. For example, at BEST each of our machines
secondaries the best.com domain.
You need to do this sort of thing to ensure that your machine is able
to boot normally into a getty even when it is disconnected from the net,
so you can at least login to it from the console. This guarentees that
the domains the system needs to boot are cached locally as of the time
of the poweron/reboot. If not, the machine will still eventually finish
booting, but it could take a long long time to get past all the myrid
DNS timeouts.
zone best.com {
type slave;
file s/best.com;
masters {
209.24.149.41;
209.157.102.11;
209.24.149.42;
};
};
By setting up your DNS this way, you generate a small amount of extra
net traffic but you get an order of magnitude better reliability out
of it. By forcing DNS to do lookups through the NS record structure,
you get around problems with ( for example ) domains which have lame
nameservers. The NS structure is a parallel/least-time poll. A
forwarders structure runs a sequential/timeout poll.
-Matt
Matthew Dillon
dil...@backplane.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: newbus and modem(s)
On Sat, 17 Apr 1999, Alex Zepeda wrote: I'm as excited as anyone to see progress, especially if it means the ability to modularize the kernel and load various drivers on demand. But, alas, it seems this whole thing was rushed horribly. The first thing I noticed was the panic I got, in atkbd_isa_intr, which has since been fixed. Well, that is what you have to expect when running current. You are a betatester, and you can't expect the authors to have access to every combination of hardware. On the other hand, I have been cvsup'ing and making world every night for the last 6 months or so, and besides having to do the changes in heads up-messages, I haven't had any troubles. Right, make world do fail sometimes, often because I have cvsup'ed during commits, but the system has never been unbootable. I do this every night from cron cd /usr/src /usr/local/bin/cvsup -s -l /tmp/cvslock -L 2 -P - -h cvsup.dk.freebsd.org /root/ports-supfile|tee /dev/ttyv7|mail root /usr/local/bin/cvsup -s -l /tmp/cvslock -L 2 -P - -h cvsup.dk.freebsd.org /root/standard-supfile|tee /dev/ttyv7|mail root make -DNOGAMES world cd /usr/src/sys/i386/conf config GINA cd /usr/src/sys/compile/GINA make depend make make install echo reboot | at +5minutes Leif To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: newbus and modem(s)
On Sat, 17 Apr 1999, Alex Zepeda wrote:
I'm as excited as anyone to see progress, especially if it means the
ability to modularize the kernel and load various drivers on demand. But,
alas, it seems this whole thing was rushed horribly.
The first thing I noticed was the panic I got, in atkbd_isa_intr, which
has since been fixed.
But once I got my system booted, I noticed that it didn't detect my PnP
modem (a quick check revealed that the PnP code was #if 0'd out). So, I
tried my external modem, which worked. But in the process of downloading
email, I got about 5 sio overflows. I've left my box up for a few days
and rebuilt world while downloading stuff, and only gotten around one or
two overflows.
I looked at un #ifdef'n the PnP code, but some things seem to have changed
substantially. Where is there any documentation on how to un-butcher
drivers or even properly fix them?
Sure it looks like the pcm driver works and works with the PnP code but it
uses the shims.
I'm not sure about pnp but this patch should fix the overflows (not
tested):
Index: sio.c
===
RCS file: /home/ncvs/src/sys/isa/sio.c,v
retrieving revision 1.224
diff -u -r1.224 sio.c
--- sio.c 1999/04/17 01:02:27 1.224
+++ sio.c 1999/04/18 08:53:36
@@ -349,7 +349,7 @@
static driver_t sio_driver = {
driver_name,
sio_methods,
- DRIVER_TYPE_TTY,
+ DRIVER_TYPE_TTY|DRIVER_TYPE_FAST,
sizeof(struct com_s),
};
--
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)
I'm as excited as anyone to see progress, especially if it means the ability to modularize the kernel and load various drivers on demand. But, alas, it seems this whole thing was rushed horribly. Not at all, it's simply something which will require some time to work out the details of in -current. People forget all too often that -current is the bleeding edge and you shouldn't even bother (truly) to track it unless you're willing and able to bleed occasionally. I'm actually always happy to see this lesson driven home again when it looks like people are getting way too complacent about -current. :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: make aout-to-elf on -current?
I had to try this due to an unfortunate 'accident', and no, it currently does not work. The aout assembler complains about a '.section' tag in the assembly output of contrib/gcc/cp/tinfo2.cc. You have to elfify your system with a non-egcs compiler before you can move onto using egcs to make the world. Timo On Fri, Apr 16, 1999 at 12:54:32AM -0600, Warner Losh wrote: Does make aout-to-elf still purport to work from a 2.2.8R system to a recent (like today's) current? Warner 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
Re: login
On Sun, Apr 18, 1999 at 12:26:15AM -0700, Matthew Dillon wrote: Setting a forwarders chain sucks, because named doesn't do the right thing with it -- even if you have multiple entries, if the first one is unreachable it will create a significant delay for nearly all your DNS requests which can seriously degrade scripts and servers. Uh, didn't know that, thanks. Well, here I use only one forwarder entry as the leaf site of an ISP. I forward all DNS traffic to the DNS Server, that is located in the same segment as the NAS. Don't want to act as a secondary for the whole gtn.com. domain, because my machine often boots, so the extra traffic of the zone transfers isn't welcome ;-) The safest way to set up a reliable DNS server is very similar to what you have above, but without forwarders. O.k., understand that. But would do that only in my own network. If you have for example a machine in a customers network for doing some analysis task, I wouldn't setup secondaries, to be more silent in the network. * You install a root cache. i.e., no forwarders. No remote cache... only local caching. root.zone can be obtained from ftp.rs.internic.net as the file domain/root.zone.gz. I run this from cron, this makes things easier on the long run: 0 18 * * 0 dig @a.root-servers.net . ns /etc/namedb/named.root.new mv /etc/namedb/named.root.new /etc/namedb/named.root * You then secondary the domains that are most critical for your machine's proper booting and operation. For example, at BEST each of our machines secondaries the best.com domain. Good idea. Andreas -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD 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!
As of a few minutes ago, a minimal set of changes to bring the so-called 'new-bus' functionality to the i386 kernel in -current. It looks like the stat clock isn't started after this. I have tried a SMP and UNI kernel and both behave the same. Looking with vmstat -i and systat -vmstat, there is no sign of the stat clock. Sysctl kern.clockrate also have profhz and stathz as 100. A kernel of about a week ago doesn't have this problem. John -- John Hay -- john@mikom.csir.co.za To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kern/5038: FreeBSD can't read MS Joliet CDs.
Motomichi Matsuzaki wrote: The 'mandatory + recommended' object size is no more than 5 kbytes. The GENERIC kernel does not require necessarily the euc-jp support or any other charsets. I think the iso8859-1 support alone is sufficient for GENERIC. The custom kernels can have the euc-jp support through the CHARSET_EUC_JP and ENCODING_EUC kernel configure option. (They are currently defined at the top of the source files.) But are they set by default to include euc-jp? Well, that's a minor point. Yes. sysctl is not the best idea. I think the charset preferences should apply on per-process basis ideally. The operator mounts some disks. The users access the disks in their own preferred charset. The UNICODE is a multiligual codeset, so we shoud not suppose any specific charset on the disk. Therefore, a per-mount basis is not enough. If the routines can refer the users' environment 'LC_CTYPE', it is fine idea. But it can't, I suppose. Yeah, Terry Lambert has preached on this before. My point is that I can't get the patch committed with it using a sysctl node. -- 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: HEADS UP!!!! Important instructions for -current users!
John Hay wrote:
As of a few minutes ago, a minimal set of changes to bring the so-called
'new-bus' functionality to the i386 kernel in -current.
It looks like the stat clock isn't started after this. I have tried a SMP
and UNI kernel and both behave the same. Looking with vmstat -i and
systat -vmstat, there is no sign of the stat clock. Sysctl kern.clockrate
also have profhz and stathz as 100. A kernel of about a week ago doesn't
have this problem.
Hmm...
[7:38pm]~-103# sysctl kern.clockrate
kern.clockrate: { hz = 100, tick = 1, tickadj = 5, profhz = 1024,
stathz = 128 }
And from systat:
zfod Interrupts
Proc:r p d s wCsw Trp Sys Int Sof Fltcow 230 total
2 2 23592 141 230 306 16016 wirepci irq11
15636 act 2 pci irq5
1.1%Sys 1.1%Intr 0.8%User 97.0%Nice 0.0%Idl24480 inact pci irq6
|||||||||| 3736 cache pci irq4
=-- 1400 freepci irq7
daefr 100 clk0 irq2
Namei Name-cacheDir-cache prcfr 128 rtc0 irq8
The labelling of the source column is known to be broken at the moment, there
are a number of key places where the fake isa unit number is getting passed
down to the lower level code. This will be fixed up shortly.
Cheers,
-Peter
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Make world fails - 990418
4.0-current === sys/modules/fdesc @ - /usr/src/sys machine - /usr/src/sys/i386/include sh /usr/src/sys/modules/fdesc/../../kern/vnode_if.sh /usr/src/sys/modules/fdesc/../../kern/vnode_if.src cc -nostdinc -O -pipe -DFDESC -DKERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/usr/obj/usr/src/sys/modules/fdesc -I/usr/obj/usr/src/sys/modules/fdesc/@ -I/usr/obj/usr/src/tmp/usr/include -DVFS_LKM -DVFS_KLD -c /usr/src/sys/modules/fdesc/../../miscfs/fdesc/fdesc_vfsops.c cc -nostdinc -O -pipe -DFDESC -DKERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/usr/obj/usr/src/sys/modules/fdesc -I/usr/obj/usr/src/sys/modules/fdesc/@ -I/usr/obj/usr/src/tmp/usr/include -DVFS_LKM -DVFS_KLD -c /usr/src/sys/modules/fdesc/../../miscfs/fdesc/fdesc_vnops.c /usr/src/sys/modules/fdesc/../../miscfs/fdesc/fdesc_vnops.c: In function `fdesc_open': /usr/src/sys/modules/fdesc/../../miscfs/fdesc/fdesc_vnops.c:352: warning: enumeration value `Froot' not handled in switch /usr/src/sys/modules/fdesc/../../miscfs/fdesc/fdesc_vnops.c:352: warning: enumeration value `Fdevfd' not handled in switch /usr/src/sys/modules/fdesc/../../miscfs/fdesc/fdesc_vnops.c:352: warning: enumeration value `Flink' not handled in switch gensetdefs fdesc_vfsops.o fdesc_vnops.o cc -nostdinc -O -pipe -DFDESC -DKERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/usr/obj/usr/src/sys/modules/fdesc -I/usr/obj/usr/src/sys/modules/fdesc/@ -I/usr/obj/usr/src/tmp/usr/include -DVFS_LKM -DVFS_KLD -c setdef0.c cc -nostdinc -O -pipe -DFDESC -DKERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/usr/obj/usr/src/sys/modules/fdesc -I/usr/obj/usr/src/sys/modules/fdesc/@ -I/usr/obj/usr/src/tmp/usr/include -DVFS_LKM -DVFS_KLD -c setdef1.c ld -Bshareable -o fdesc.ko setdef0.o fdesc_vfsops.o fdesc_vnops.o setdef1.o === sys/modules/fxp @ - /usr/src/sys machine - /usr/src/sys/i386/include echo #define NFXP 1 fxp.h echo #define NBPFILTER 0 bpfilter.h touch opt_bdg.h perl5 /usr/src/sys/modules/fxp/../../kern/makedevops.pl -h /usr/src/sys/modules/fxp/../../kern/device_if.m perl5: not found *** Error code 1 I cvsuped about one hour ago, but the problem was there from before... -- Regards... Gianmarco Unix expert since yesterday http://www.giovannelli.it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Make world fails - 990418
On Sun, 18 Apr 1999, Gianmarco Giovannelli wrote: 4.0-current ... perl5: not found *** Error code 1 I cvsuped about one hour ago, but the problem was there from before... Fixed. -- 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 wrote:
I'm not sure about pnp but this patch should fix the overflows (not
tested):
Seems to work fine for me (I had the sio overflow problems too).
Index: sio.c
===
RCS file: /home/ncvs/src/sys/isa/sio.c,v
retrieving revision 1.224
diff -u -r1.224 sio.c
--- sio.c 1999/04/17 01:02:27 1.224
+++ sio.c 1999/04/18 08:53:36
@@ -349,7 +349,7 @@
static driver_t sio_driver = {
driver_name,
sio_methods,
- DRIVER_TYPE_TTY,
+ DRIVER_TYPE_TTY|DRIVER_TYPE_FAST,
sizeof(struct com_s),
};
--
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: HEADS UP!!!! Important instructions for -current users!
Let us not forget that much of the newconfig work can be used with newconfig shims in the newbus scheme. Probably some simple drivers for newconfig works with newconfig shims, but bus code that depends on newconfig may not work. I don't go to new-bus, this direction is disunion of BSDs. It is bad decision. -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: make aout-to-elf on -current?
On 1999-04-16 00:54:32 -0600, Warner Losh wrote: Does make aout-to-elf still purport to work from a 2.2.8R system to a recent (like today's) current? I updated my laptop 4 weeks ago from 2.2.6R to 4.0-current. There where only minor problems, see PR bin/10784 and bin/10785 -- Wolfram Schneider wo...@freebsd.org http://wolfram.schneider.org 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!
I don't go to new-bus, this direction is disunion of BSDs. It is bad decision. I'm sorry that you feel this way, but I can only re-state that better communication could have prevented this in the first place and hope that you've learned your own lessons from this exercise. If you haven't, then a good opportunity for learning has simply been wasted. - Jordan 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!
John Hay wrote:
As of a few minutes ago, a minimal set of changes to bring the so-called
'new-bus' functionality to the i386 kernel in -current.
It looks like the stat clock isn't started after this. I have tried a SMP
and UNI kernel and both behave the same. Looking with vmstat -i and
systat -vmstat, there is no sign of the stat clock. Sysctl kern.clockrate
also have profhz and stathz as 100. A kernel of about a week ago doesn't
have this problem.
Hmm...
[7:38pm]~-103# sysctl kern.clockrate
kern.clockrate: { hz = 100, tick = 1, tickadj = 5, profhz = 1024,
stathz = 128 }
Ok, I have found it. My kernel still had the apm line from its GENERIC
days, which didn't hurt me before:
device apm0at nexus? disable flags 0x31 # Advanced Power Management
It seems that the disable keyword is ignored, because the apm0 device
suddenly appeared in the probe messages and that set statclock_disable to 1.
I have removed apm from my kernel config file and all is well again.
John
--
John Hay -- john@mikom.csir.co.za
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!
On Sun, 18 Apr 1999, John Hay wrote:
John Hay wrote:
As of a few minutes ago, a minimal set of changes to bring the so-called
'new-bus' functionality to the i386 kernel in -current.
It looks like the stat clock isn't started after this. I have tried a SMP
and UNI kernel and both behave the same. Looking with vmstat -i and
systat -vmstat, there is no sign of the stat clock. Sysctl kern.clockrate
also have profhz and stathz as 100. A kernel of about a week ago doesn't
have this problem.
Hmm...
[7:38pm]~-103# sysctl kern.clockrate
kern.clockrate: { hz = 100, tick = 1, tickadj = 5, profhz = 1024,
stathz = 128 }
Ok, I have found it. My kernel still had the apm line from its GENERIC
days, which didn't hurt me before:
device apm0at nexus? disable flags 0x31 # Advanced Power
Management
It seems that the disable keyword is ignored, because the apm0 device
suddenly appeared in the probe messages and that set statclock_disable to 1.
I have removed apm from my kernel config file and all is well again.
This should be fixed. I changed the apm driver to honour the disabled
keyword.
--
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)
On Sun, 18 Apr 1999, Jordan K. Hubbard wrote: I'm as excited as anyone to see progress, especially if it means the ability to modularize the kernel and load various drivers on demand. But, alas, it seems this whole thing was rushed horribly. Not at all, it's simply something which will require some time to work out the details of in -current. Which means that it perhaps should be worked out before being merged. Take for instance CAM. It didn't work perfectly, but it sure got a lot more exposure than newbus, and when it was integrated it caused very few problems. People forget all too often that -current is the bleeding edge and you shouldn't even bother (truly) to track it unless you're willing and able to bleed occasionally. I'm actually always happy to see this lesson driven home again when it looks like people are getting way too complacent about -current. :-) Well, why not make ext2fs the default fs just to shake things up? It's one thing to expect panics and soon, but it's another thing to import code that wasn't ready. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: newbus and modem(s)
The first thing I noticed was the panic I got, in atkbd_isa_intr, which has since been fixed. Well, that is what you have to expect when running current. You are a betatester, and you can't expect the authors to have access to every combination of hardware. Well that's my point. Again, I'll point at CAM. That was available to the public for testing, and therefor required caused very little trouble (with the exception of the aic driver) when it was integrated. Hell, I'm even interested in fixing the PnP part of the sio driver, but where can I find information on newbus and PnP? The only other PnP driver I've looked at (pcm) uses the shims. Perhaps for good reason? - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: newbus and modem(s)
Alex Zepeda wrote: Which means that it perhaps should be worked out before being merged. Take for instance CAM. It didn't work perfectly, but it sure got a lot more exposure than newbus, and when it was integrated it caused very few problems. I think CAM is a very bad example. We *still* don't have all the drivers we had, and that includes at least one reasonably requested driver. On the other hand, I don't see we losing anything with newbus, which is quite a feat given the extent of the changes. Moreover, I have seen very few problems reported. Changing the compiler to egcs seems to have produced more waves, in fact. Well, why not make ext2fs the default fs just to shake things up? It's one thing to expect panics and soon, but it's another thing to import code that wasn't ready. It seems to work on my computer. Why do you say it isn't ready? A reality check seems to be in order. It would seem you are peeved because some of the very few gliches affected you. -- 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: newbus and modem(s)
On Mon, 19 Apr 1999, Daniel C. Sobral wrote: I think CAM is a very bad example. We *still* don't have all the drivers we had, and that includes at least one reasonably requested driver. Is that an offer to write the missing drivers? On the other hand, I don't see we losing anything with newbus, which is quite a feat given the extent of the changes. Moreover, I have seen very few problems reported. Changing the compiler to egcs seems to have produced more waves, in fact. Plug and Play for at least the sio driver, perhaps just pnp in general for drivers that were moved to the newbus stuff. Is there any documentation explaining what exactly was changed? Sure, egcs created problems, but at least the general public was warned that this was going to be merged soon. But the kernel worked, and C programs worked usually. Well, why not make ext2fs the default fs just to shake things up? It's one thing to expect panics and soon, but it's another thing to import code that wasn't ready. It seems to work on my computer. Why do you say it isn't ready? A reality check seems to be in order. It would seem you are peeved because some of the very few gliches affected you. Why would I say it wasn't ready? Because outside of core (apparently), nobody was warned/told that this was going to be committed in a few days/hours/minutes. Glitches? What about the sbxvi driver? The apm driver? Sure, I'm annoyed about one of the glitches affecting me, but I just think if this code had been aired more publically before merging, all of these problems could have been easily avoided. And then what about newconfig? To me this just adds more truth to the whole /. argument that *BSD promotes a closed development model. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: newbus and modem(s)
Which means that it perhaps should be worked out before being merged. Take for instance CAM. It didn't work perfectly, but it sure got a lot more exposure than newbus, and when it was integrated it caused very few problems. The two systems aren't equivalent so it's not really correct to make comparisons like this. In any case, -current has always been designated for developers to work on issues precisely like this one and it's simply not accurate to suggest that bleeding edge development should not be done in the -current branch. As I said before, it only points out that many people are tracking the wrong branch. If you want a smooth experience, track -stable and that's all I'm going to say on the issue. Well, why not make ext2fs the default fs just to shake things up? It's If there were a truly practical reason to do so, you may rest assured that we would. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: newbus and modem(s)
And then what about newconfig? To me this just adds more truth to the whole /. argument that *BSD promotes a closed development model. I think your perceptions are fundamentally flawed here, it's just that simple. You can argue the point all you like in -current, but it won't change that fact one iota. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Pccard support still works with newbus, right?
I'm currently working on a driver for the Lucent WaveLAN/IEEE 802.11 PCMCIA adapter, as part of a project for the COMET lab people here at Columbia. Lucent has a PCMCIA and an ISA version of this adapter, however the ISA version is really just a PCMCIA card fitted into an add-in PCMCIA controller card that mounts in an ISA slot (i.e. something that lets you plug PCMCIA devices into a desktop host that doesn't have any built-in PCMCIA slots). This adapter card has a Vadem 469 chip on it which, fortunately, is supported by our current pccard code. The system I'm testing on is running 3.0-RELEASE and I'm reasonably confident my code will work with 3.1-RELEASE too. As it stands now, I can get the card probed and attached when I start pccardd, and everything seems peachy. What I need to know is if anybody has tested the pccard support in 4.0-CURRENT now that all the newbus stuff has been rolled in. If the pccard support for the x86 still works under 'emulation' using an ISA device shim, then that's fine. If not... well, then I suppoose _I'm_ the one who's going to end up testing it. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City = It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: newbus and modem(s)
Alex Zepeda wrote: On Mon, 19 Apr 1999, Daniel C. Sobral wrote: I think CAM is a very bad example. We *still* don't have all the drivers we had, and that includes at least one reasonably requested driver. Is that an offer to write the missing drivers? Is that sidetracking the argument? :-) Alas, I found a FreeBSD driver for my card, which I don't have the heck whether it is aic-based or not, and I'll try to write a -current driver based on it. Sure, egcs created problems, but at least the general public was warned that this was going to be merged soon. But the kernel worked, and C programs worked usually. I agree that a heads up a few days earlier would have been in order. I even recall a certain document might have mentioned something to this effect... Which is a different issue altogether. Why would I say it wasn't ready? Because outside of core (apparently), nobody was warned/told that this was going to be committed in a few days/hours/minutes. Nobody warning is a very different issue from it not being ready. Glitches? What about the sbxvi driver? The apm driver? Sure, I'm annoyed about one of the glitches affecting me, but I just think if this code had been aired more publically before merging, all of these problems could have been easily avoided. Looks like glitches to me. And, as Jordan said, -current's purpose is airing code more publically. And then what about newconfig? To me this just adds more truth to the whole /. argument that *BSD promotes a closed development model. New-bus mailing list was open to subscription, the cvs repository for the code was announced, and, if I'm not mistaken, you could even cvsup it from cvsup2. It lacked a Hey, people, new-bus *IS* going to be imported into FreeBSD at some point in the near future message, so people who did not look further would have no doubts about it, but this is a minor point. As for the newconfig people, it *was* said to them that FreeBSD *was* going with new-bus. I suspect that, not liking this direction, they opted to proceed with their code, in the hope that working code wins against vaporware any day. Unfortunately, for them, newbus isn't vaporware. And, as Jordan said, only one of newbus and newconfig could be choosen, so there is nothing closed about choosing. -- 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: Pccard support still works with newbus, right?
On Sun, 18 Apr 1999, Bill Paul wrote: I'm currently working on a driver for the Lucent WaveLAN/IEEE 802.11 PCMCIA adapter, as part of a project for the COMET lab people here at Columbia. Lucent has a PCMCIA and an ISA version of this adapter, however the ISA version is really just a PCMCIA card fitted into an add-in PCMCIA controller card that mounts in an ISA slot (i.e. something that lets you plug PCMCIA devices into a desktop host that doesn't have any built-in PCMCIA slots). This adapter card has a Vadem 469 chip on it which, fortunately, is supported by our current pccard code. The system I'm testing on is running 3.0-RELEASE and I'm reasonably confident my code will work with 3.1-RELEASE too. As it stands now, I can get the card probed and attached when I start pccardd, and everything seems peachy. What I need to know is if anybody has tested the pccard support in 4.0-CURRENT now that all the newbus stuff has been rolled in. If the pccard support for the x86 still works under 'emulation' using an ISA device shim, then that's fine. If not... well, then I suppoose _I'm_ the one who's going to end up testing it. I think it works as well it did before but I haven't personally tested it. -- 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
new-bus, a success report.
Since everybody's slagging new-bus right now, I thought I'd just jump in and say that as of 10 minutes ago, having made the world and a new kernel, everything's working great. NOTE: Look at GENERIC! Things have changed and you will likely need to update your old config file before everything is peachy again. I had to update my PS/2 rodent and keyboard entries, as well as the parallel port bus stuff, and it's now working wonderfully on my dual PII/450 with a fairly non-trivial set of peripherals plugged into it, including on-board PnP sound and a Hauppage bt848 card for video. My dmesg output, JFYI: 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: Sun Apr 18 08:30:14 PDT 1999 j...@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping=2 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134217728 (131072K bytes) avail memory = 127864832 (124868K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel kernel at 0xc02a5000. Pentium Pro MTRR support enabled, default memory type is uncacheable npx0: math processor on motherboard npx0: INT 16 interface pcib0: PCI host bus adapter on motherboard pci0: PCI bus on pcib0 chip0: Host to PCI bridge (vendor=8086 device=71a0) at device 0.0 on pci0 pcib1: PCI to PCI bridge (vendor=8086 device=71a1) at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 devclass_alloc_unit: npx0 already exists, using next available unit number isa0: ISA bus on isab0 ide_pci0: Intel PIIX4 Bus-master IDE controller at device 7.1 on pci0 chip1: Intel 82371AB Power management controller at device 7.3 on pci0 pcib2: PCI to PCI bridge (vendor=1011 device=0024) at device 16.0 on pci0 pci2: PCI bus on pcib2 fxp0: Intel EtherExpress Pro 10/100B Ethernet at device 17.0 on pci0 fxp0: interrupting at irq 19 fxp0: Ethernet address 00:e0:81:10:20:9e ahc0: Adaptec aic7895 Ultra SCSI adapter at device 18.0 on pci0 ahc0: interrupting at irq 16 ahc0: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: Adaptec aic7895 Ultra SCSI adapter at device 18.1 on pci0 ahc1: interrupting at irq 16 ahc1: aic7895 Wide Channel B, SCSI Id=7, 16/255 SCBs bktr0: BrookTree 848a at device 20.0 on pci0 bti2c0: bt848 Hard/Soft I2C controller iicbb0: I2C generic bit-banging driver on bti2c0 iicbus0: Philips I2C bus on iicbb0 master-only smbus0: System Management Bus on bti2c0 smb0: SMBus general purpose I/O on smbus0 bktr0: interrupting at irq 17 Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner. fdc0: interrupting at irq 6 fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive at fdc0 drive 0 wdc0 at port 0x1f0-0x1f7 irq 14 on isa0 wdc0: unit 0 (wd0): WDC AC36400L wd0: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S wdc0: interrupting at irq 14 wdc1 at port 0x170-0x177 irq 15 on isa0 wdc1: unit 0 (atapi): CREATIVEDVD-ROM DVD5240E/1.01, removable, accel, dma, iordis wcd0: drive speed 5500KB/sec, 512KB cache wcd0: supported read types: CD-R, CD-RW, CD-DA, packet track wcd0: Audio: play, 255 volume levels wcd0: Mechanism: ejectable tray wcd0: Medium: no/blank disc inside, unlocked wdc1: interrupting at irq 15 atkbdc0: keyboard controller (i8042) at port 0x60 on isa0 atkbd0: AT Keyboard on atkbdc0 atkbd0: interrupting at irq 1 psm0: PS/2 Mouse on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 psm0: interrupting at irq 12 vga0: Generic ISA VGA on isa0 sc0: System console 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: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 ppc0: interrupting at irq 7 pcm0 at port 0x220 irq 5 drq 1 flags 0x13 on isa0 pcm0: interrupting at irq 5 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 Waiting 2 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST39102LW 0005 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C)
Re: newbus and modem(s)
Why would I say it wasn't ready? Because outside of core (apparently), nobody was warned/told that this was going to be committed in a few days/hours/minutes. The USB code has been using newbus for over 4 months now. And up to now we've had only one bug to fix. The rest was feature requests. I've ported the newconfig style USB code of NetBSD to FreeBSD and I really prefer the newbus style, because it is truly dynamic. Nick FreeBSD USB project To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Language barrier (was Re: HEADS UP!!!! Important instructions for -current users! )
I would ask people to STOP DOING THIS. Do not harass or ridicule someone for not being fluent in english! Now, it is sorely true that someone wil Let me just reinforce this statement. This is wonderful, but has this ever happened in our mailing lists? I guess I don't remember anyone *ever* ridiculing or harassing someone for not being fluent in the language. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
new-bus on ISA only machine
On ISA only machine, w/o controller pci0at nexus? in kernel config, after make depend: In file included from ../../i386/i386/nexus.c:74: ../../pci/pcivar.h:192: pci_if.h: No such file or directory In file included from ../../i386/i386/userconfig.c:132: ../../pci/pcivar.h:192: pci_if.h: No such file or directory mkdep: compile failed *** Error code 1 With controller pci0at nexus? it's ok, and kernel is running fine. But I don't need PCI code into kernel on my ISA only machine. Val === Valentin Shopov 2301 West Bethel Ave., #53 Muncie, IN 47304-2112 Phone: ++1-(765)-214-0504 E-Mail: val...@yahoo.com val...@usa.net URL:http://www.cyberspace.org/~valentin _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com 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!
John Hay wrote: As of a few minutes ago, a minimal set of changes to bring the so-called 'new-bus' functionality to the i386 kernel in -current. It looks like the stat clock isn't started after this. I have tried a SMP and UNI kernel and both behave the same. Looking with vmstat -i and systat -vmstat, there is no sign of the stat clock. Sysctl kern.clockrate also have profhz and stathz as 100. A kernel of about a week ago doesn't have this problem. There are also some funny results in systat -vmstat; lots of interrupt names are wrong; a pnp-probed sound card is listed as ??? irq5, and everything else except clk0 int0 and rtc0 irq8 are listed as pci irqNN (with NN replaced some believable number). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Language barrier (was Re: HEADS UP!!!! Important instructions for -current users! )
: that someone wil : : Let me just reinforce this statement. : :This is wonderful, but has this ever happened in our mailing lists? I :guess I don't remember anyone *ever* ridiculing or harassing someone for :not being fluent in the language. : :Nate Oh sure, it happens quite often. I've seen people 'talk down' to other people lots of time in responding to their questions. I see it most often when the person who posted the question has trouble with the language. Sometimes you can just see how much time it took the guy to ooze-out a single sentence and it really makes me angry when all they get for their trouble is a flip answer from some bozo. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus, a success report.
Jordan K. Hubbard wrote: Since everybody's slagging new-bus right now, I thought I'd just jump in and say that as of 10 minutes ago, having made the world and a new kernel, everything's working great. NOTE: Look at GENERIC! Things have changed and you will likely need to update your old config file before everything is peachy again. I had to update my PS/2 rodent and keyboard entries, as well as the parallel port bus stuff, and it's now working wonderfully on my dual PII/450 with a fairly non-trivial set of peripherals plugged into it, including on-board PnP sound and a Hauppage bt848 card for video. My PPro/SMP (Remember that board, Jordan?) is also running it with nary a glitch. Here's my 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: Sat Apr 17 13:17:31 SAST 1999 r...@greenpeace.grondar.za:/usr/src/sys/compile/GA586DX Timecounter i8254 frequency 1193182 Hz CPU: Pentium Pro (686-class CPU) Origin = GenuineIntel Id = 0x619 Stepping=9 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 67108864 (65536K bytes) avail memory = 62566400 (61100K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec0 Preloaded elf kernel kernel at 0xc0284000. Pentium Pro MTRR support enabled, default memory type is uncacheable Probing for PnP devices: CSN 1 Vendor ID: CSC0b36 [0x360b630e] Serial 0x Comp ID: @@@ [0x] mss_attach CS42361 at 0x530 irq 5 dma 1:0 flags 0x10 pcm1 (CS423x/Yamaha/AD1816 CS4236 sn 0x) at 0x530-0x537 irq 5 drq 1 flags 0x10 on isa npx0: math processor on motherboard npx0: INT 16 interface pcib0: PCI host bus adapter on motherboard pci0: PCI bus on pcib0 chip0: Intel 82440FX (Natoma) PCI and memory controller at device 0.0 on pci0 fxp0: Intel EtherExpress Pro 10/100B Ethernet at device 6.0 on pci0 fxp0: interrupting at irq 18 fxp0: Ethernet address 00:a0:c9:49:c1:95 isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ahc0: Adaptec aic7880 Ultra SCSI adapter at device 9.0 on pci0 ahc0: interrupting at irq 17 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs fdc0: interrupting at irq 6 fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 atkbdc0: keyboard controller (i8042) at port 0x60 on isa0 atkbd0: AT Keyboard on atkbdc0 atkbd0: interrupting at irq 1 psm0: PS/2 Mouse on atkbdc0 psm0: model MouseMan+, device ID 0 psm0: interrupting at irq 12 vga0: Generic ISA VGA on isa0 sc0: System console 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: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppc0: interrupting at irq 7 APIC_IO: routing 8254 via 8259 on pin 0 Waiting 4 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: IBM OEM DCHS04U 5353 Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 4340MB (543 512 byte sectors: 255H 63S/T 553C) ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org 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!
Mark Murray wrote: John Hay wrote: As of a few minutes ago, a minimal set of changes to bring the so-called 'new-bus' functionality to the i386 kernel in -current. It looks like the stat clock isn't started after this. I have tried a SMP and UNI kernel and both behave the same. Looking with vmstat -i and systat -vmstat, there is no sign of the stat clock. Sysctl kern.clockrate also have profhz and stathz as 100. A kernel of about a week ago doesn't have this problem. There are also some funny results in systat -vmstat; lots of interrupt names are wrong; a pnp-probed sound card is listed as ??? irq5, and everything else except clk0 int0 and rtc0 irq8 are listed as pci irqNN (with NN replaced some believable number). Known bogon... In between putting out fires (here), I hope to take a further shot at cleaning up the interrupt layering shortly. I wasn't too worried about that, I didn't think the world would end if the labels fell off the irq table, so I left it out. :-] Cheers, -Peter 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!
Peter Wemm wrote: Known bogon... In between putting out fires (here), I hope to take a further shot at cleaning up the interrupt layering shortly. ... as I saw 3 messages later. I wasn't too worried about that, I didn't think the world would end if the labels fell off the irq table, so I left it out. :-] No problem. No-one got hurt ;-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: newbus and modem(s)
In message pine.bsf.3.96.990418205350.3261e-100...@heidi.plazza.it, Nick Hibm a wrote: Why would I say it wasn't ready? Because outside of core (apparently), nobody was warned/told that this was going to be committed in a few days/hours/minutes. I've ported the newconfig style USB code of NetBSD to FreeBSD and I really prefer the newbus style, because it is truly dynamic. Simple Question. If there were 'Closed'-Host-Controller-Interface with object-only driver, Can the vendor make the Host controller recognized without changing usb.c code? #That's what frustrated me while writing driver for smbus controller. Takanori Watanabe a href=http://www.planet.kobe-u.ac.jp/~takawata/key.html; Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
compaq presario 1675 pccard
Hello, Has anyone been successful getting pccard services to run on this laptop? I enabled the card controller and rebuilt the kernel, enable pccard services in rc.conf, but when I run pccardc dumpcis I get 0 slots found. I have a feeling the pcmcia controller isn't being recognized. Can anyone point me in the right direction? Thanks. -Ted To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
newbus and isa auto irq
Hi, I ave found one more thing that seems to be broken. I have used the irq autodetect feature of the ed(4) for a long time, but it seems that the newbus compatability shim is not doing the right thing with it. My kernel config file have a line like this: device ed0 at isa? port 0x280 net irq ? iomem 0xd8000 The card gets probed but you just get device timeouts and there is no mention of an irq for that device in the probe output. Booting with -c and specifying the irq there also didn't work. Rebuilding the kernel with a config file which specified the irq did work though. John -- John Hay -- john@mikom.csir.co.za To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
compaq presario 1675 pccard (fwd)
Guess I should mention this is 3.1-RELEASE. -- Forwarded message -- Date: Sun, 18 Apr 1999 16:37:55 -0400 (EDT) From: T.D. Brace t...@stargate.org To: freebsd-current@FreeBSD.ORG Subject: compaq presario 1675 pccard Hello, Has anyone been successful getting pccard services to run on this laptop? I enabled the card controller and rebuilt the kernel, enable pccard services in rc.conf, but when I run pccardc dumpcis I get 0 slots found. I have a feeling the pcmcia controller isn't being recognized. Can anyone point me in the right direction? Thanks. -Ted 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
Parallel ZIP drive hangs machine
I'm running current as of April 6th and whenever I try to multi-volume tar directly to my parallel port zip drive using /dev/da0 it hangs when it gets to the end of the zip. I don't think it's a hardware problem because I've seen it happen on 2 completely separate machines. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: compaq presario 1675 pccard (fwd)
On Sun, 18 Apr 1999, T.D. Brace wrote: Guess I should mention this is 3.1-RELEASE. -- Forwarded message -- Date: Sun, 18 Apr 1999 16:37:55 -0400 (EDT) From: T.D. Brace t...@stargate.org To: freebsd-current@FreeBSD.ORG Subject: compaq presario 1675 pccard Hello, Has anyone been successful getting pccard services to run on this laptop? I enabled the card controller and rebuilt the kernel, enable pccard services in rc.conf, but when I run pccardc dumpcis I get 0 slots found. I have a feeling the pcmcia controller isn't being recognized. Can anyone point me in the right direction? Thanks. -Ted Wild speculation, did you enable pnp? do you have these lines in the kernel config file: # PCCARD (PCMCIA) support controller card0 device pcic0 at card? device pcic1 at card? controller pnp0# PnP support for ISA controller isa0 right? -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus, a success report.
On Sun, 18 Apr 1999, Jordan K. Hubbard wrote: Since everybody's slagging new-bus right now, I thought I'd just jump in and say that as of 10 minutes ago, having made the world and a new kernel, everything's working great. NOTE: Look at GENERIC! Things have changed and you will likely need to update your old config file before everything is peachy again. I had to update my PS/2 rodent and keyboard entries, as well as the parallel port bus stuff, and it's now working wonderfully on my dual PII/450 with a fairly non-trivial set of peripherals plugged into it, including on-board PnP sound and a Hauppage bt848 card for video. Heck, Jordan, you weren't first. I can't understand why Alex is all upset, most especially about the sound breakage (which I don't see, my sound works fine). The sound stuff is one of the things that's likely to be helped by the fact of our bus technology on the road to becoming closer to NetBSD/OpenBSD bus technology, so we can share code. It's not done, but that's the path, and Alex would be one of those helped by it. I don't see any breakage at all, myself, but even if there is (and I know, there must be some) then it sure seems worth it. This new-bus stuff is absolutely great, and I hope Doug, Peter, and everyone else involved doesn't hear the criticism only. You guys are doing fine work. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus on ISA only machine
Valentin Shopov wrote: On ISA only machine, w/o controller pci0at nexus? in kernel config, after make depend: In file included from ../../i386/i386/nexus.c:74: ../../pci/pcivar.h:192: pci_if.h: No such file or directory In file included from ../../i386/i386/userconfig.c:132: ../../pci/pcivar.h:192: pci_if.h: No such file or directory mkdep: compile failed *** Error code 1 With controller pci0at nexus? it's ok, and kernel is running fine. But I don't need PCI code into kernel on my ISA only machine. I've fixed one of these, and was in the middle of patching the other one when I got a little sidetracked.. I need some sleep, I'm making silly mistakes. Anyway, If you want to run without pci, you'll have to tweak the nexus.c code a little so that it adds the isa bus always (just like on PC98). Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Laptop support
Hello, A better place to ask this question would be over on freebsd-mobile. The whole list is nothing but portables. Can anyone tell me if I can get freebsd 3.1 running on a compaq pressario 1675 - I'm worried about the pcmcia controller being recognized (and my xircom re-100btx working). Thanks. 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
Re: newbus and modem(s)
On Sun, 18 Apr 1999, Alex Zepeda wrote: On Mon, 19 Apr 1999, Daniel C. Sobral wrote: I think CAM is a very bad example. We *still* don't have all the drivers we had, and that includes at least one reasonably requested driver. Is that an offer to write the missing drivers? On the other hand, I don't see we losing anything with newbus, which is quite a feat given the extent of the changes. Moreover, I have seen very few problems reported. Changing the compiler to egcs seems to have produced more waves, in fact. Plug and Play for at least the sio driver, perhaps just pnp in general for drivers that were moved to the newbus stuff. Is there any documentation explaining what exactly was changed? Sure, egcs created problems, but at least the general public was warned that this was going to be merged soon. But the kernel worked, and C programs worked usually. Well, why not make ext2fs the default fs just to shake things up? It's one thing to expect panics and soon, but it's another thing to import code that wasn't ready. It seems to work on my computer. Why do you say it isn't ready? A reality check seems to be in order. It would seem you are peeved because some of the very few gliches affected you. Why would I say it wasn't ready? Because outside of core (apparently), nobody was warned/told that this was going to be committed in a few days/hours/minutes. Glitches? What about the sbxvi driver? The apm driver? Sure, I'm annoyed about one of the glitches affecting me, but I just think if this code had been aired more publically before merging, all of these problems could have been easily avoided. I saw this and just had to note something to you. THINK what branch you are using. This is _WHERE_ things are being aired publically, and merged eventually to the STABLE branch. And then what about newconfig? To me this just adds more truth to the whole /. argument that *BSD promotes a closed development model. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) | http://www.freebsd.org _ |___)___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: newbus and modem(s)
On Sun, 18 Apr 1999, Brian Feldman wrote: I saw this and just had to note something to you. THINK what branch you are using. This is _WHERE_ things are being aired publically, and merged eventually to the STABLE branch. Gosh, thank you, without your wonderful help and understanding, I NEVER would have been able to realize this. You are so smart. Will you commit my code which breaks a few things and causes a panic? Wouldya? Huh? Huh? Huh? - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Parallel ZIP drive hangs machine
On Sun, 18 Apr 1999, Smelly Pooh wrote: I'm running current as of April 6th and whenever I try to multi-volume tar directly to my parallel port zip drive using /dev/da0 it hangs when it gets to the end of the zip. I don't think it's a hardware problem because I've seen it happen on 2 completely separate machines. This is a known problem, that writes to an end of a block device will cause a lockup. I have no idea if anyone was going to fix this. Did you try using the character device, which is what you SHOULD be using anyway? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) | http://www.freebsd.org _ |___)___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: newbus and modem(s)
On Sun, 18 Apr 1999, Alex Zepeda wrote: On Sun, 18 Apr 1999, Brian Feldman wrote: I saw this and just had to note something to you. THINK what branch you are using. This is _WHERE_ things are being aired publically, and merged eventually to the STABLE branch. Gosh, thank you, without your wonderful help and understanding, I NEVER would have been able to realize this. You are so smart. Will you commit my code which breaks a few things and causes a panic? Wouldya? Huh? Huh? Huh? Alex, that's twice ... and enough. If you feel you have to drip sarcasm, go pick another mailing list, no one here wants to hear the sarcasm, even if they *might* agree with your points. Don't get personal, don't use sarcasm, this isn't the list for it. If you want stuff like that, the Usenet groups abound in it, go there. All you're doing here is making yourself look bad. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
NFS patch #5 avail - need testers files)
NFS patch #5 is now available for -current. I believe I have fixed all the bugs for NFSV3 over UDP, but I need people to help test it. http://www.backplane.com/FreeBSD4/ This patch also includes general B_VMIO caching for directories ( ufs, nfs, anyone ), which DG may commit soon so if you get errors just wait a bit for me to update the patch or fix collisions yourself. To use, unapply any previous patches and start fresh. I believe this patch to be reasonably stable -- enough that it should be possible to perform meaningful testing with it. But, as always, do not run this on any box containing critical data. It has successfully passed *all* of my tests so far. Note that this is for NFSV3 UDP only, and although all the fixes apply to TCP and most of them apply to NFS V2 too, TCP probably still has other bugs. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: make aout-to-elf on -current?
In message 19990416083544.a10...@timog.prestel.co.uk Timo Geusch writes: : You have to elfify your system with a non-egcs compiler before you can move : onto using egcs to make the world. Yes. I discovered this the hard way... I did an upgrade to 3.1-stable with a make aout-to-elf and then to -current from there. Three make worlds, but it worked... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Language barrier (was Re: HEADS UP!!!! Important instructions for -current users! )
In message 199904181923.naa25...@mt.sri.com Nate Williams writes: : This is wonderful, but has this ever happened in our mailing lists? I : guess I don't remember anyone *ever* ridiculing or harassing someone for : not being fluent in the language. I have seen people ask others to explain again since they didn't understand, but I cannot recall ever seeing anybody holding someone up to ridicule publically. I have deep respect for several people that have pushed through the language barrier. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Pccard support still works with newbus, right?
In message pine.bsf.4.05.9904181854010.85882-100...@herring.nlsystems.com Doug Rabson writes: : I think it works as well it did before but I haven't personally tested it. I have personally tested my new ata-flash support as well as my 3C589D card, both with a PC-Card Vadem 365 based ISA on my PPro 200. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus, a success report.
On Sun, Apr 18, 1999 at 05:20:44PM -0400, Chuck Robey wrote: This new-bus stuff is absolutely great, and I hope Doug, Peter, and everyone else involved doesn't hear the criticism only. You guys are doing fine work. Hear Hear! A painless switch here too (nothing unusual about the box). -- Adrian Wontroba To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
