Re: unknown PNP hardware
Then go look them up. I'm not about to stuff the entire PnP device database into the kernel just to satisfy your curiosity. 8( I was going to ask where, but I see they are in /usr/src/sys/boot/common/pnpdata. That's a useful subset that I keep forgetting about; thanks for reminding me. Google is also remarkably good at finding these things (it's how I've found most of the databases I have). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
Warner Losh wrote: : Whether it's perfect or not, making the device.hints go away : in the presents of PnP BIOS on the machine would seem to be : able to address the issue of doubled entries... right? Not entirely. There are ISA devices in devices.hints that aren't plug and play and aren't in the PnP BIOS list. That's a worse problem than the minor printf :-). Ouch. [ ... ] What we'd like to happen: PnP BIOS devices device.hints PnP ISA devices What we do now device.hints PnP BIOS devices PnP ISA devices Let me ask one more question... you want this reordering to ensure that you can handle the PnP BIOS cases where some legacy device *is* known to the PnP BIOS, vs. where the legacy device is _NOT_ known to the PnP BIOS, so that the device.hints can find it if it's there, before we fall into the PnP ISA [Plug-N-Play OS] game, right? I remember an ACER system with a bus mouse on the motherboard which was unknown to the PnP BIOS, and Windows 95 trying to be a PnP OS used to always do what above looks to be the PnP ISA devices phase of things, and gave IRQ 12 to the second IDE disk interface, instead of the on-board mouse... which would exactly fit this bill. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
I once wrote the following patch to deal with this problem by probing ISA devices in the following order. 1. sensitive ISA devices described in device.hints 2. PnP BIOS ISA devices 3. other ISA devices described in device.hints 4. PnP ISA devices This order is still slightly wrong. You need to do: 0. Disable ALL PnP devices which can be disabled. 1. PnP devices (of any kind) which cannot be disabled, or which only have a single configuration. These devices which cannot be disabled need a placeholder attached to them if a driver doesn't claim them, or some other mechanism so that their resources are never used. 2. Sensitive hinted ISA devices. 3. Other ISA devices. 4. Other PnP devices. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
I remember an ACER system with a bus mouse on the motherboard which was unknown to the PnP BIOS, and Windows 95 trying to be a PnP OS used to always do what above looks to be the PnP ISA devices phase of things, and gave IRQ 12 to the second IDE disk interface, instead of the on-board mouse... which would exactly fit this bill. See my immediately preceeding message for how this has to be worked around. It's doable. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
user/group bind
After being informed of the paragraph in UPDATING on this topic, I went to /usr/src/etc to see what the settled-upon UID/GID of bind is... Ummm... Did someone forget to commit changes to the /usr/src/etc/group and /usr/src/etc/passwd baseline files? What UID/GID should be used? jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: user/group bind
On Sun, Aug 26, 2001 at 06:10:53PM -0500, Jim Bryant wrote: After being informed of the paragraph in UPDATING on this topic, I went to /usr/src/etc to see what the settled-upon UID/GID of bind is... Ummm... Did someone forget to commit changes to the /usr/src/etc/group and /usr/src/etc/passwd baseline files? No, that user and group have been there for 2 1/2 years. Kris PGP signature
Re: user/group bind
Okay, please don't say it... I'm blind... Boot to the head! I see it now, as GID 53... Jim Bryant wrote: After being informed of the paragraph in UPDATING on this topic, I went to /usr/src/etc to see what the settled-upon UID/GID of bind is... Ummm... Did someone forget to commit changes to the /usr/src/etc/group and /usr/src/etc/passwd baseline files? What UID/GID should be used? jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
In message [EMAIL PROTECTED] Andrey A. Chernov writes: : Complaints _are_ easily addressed, tcsh author is responsible and fix all : thing that I report to him. If you complain about 'upgrade' problem, i.e. : we don't have latest tcsh, ask our tcsh maintainer for upgrade. I'm our tcsh maintainer, btw. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
This Weekends Sale... All Combo Pkg\\\'s $79.99
Well it seems the www.spawndevices.com $15 - $25 buck boots and emu\'s made a few of
you happy good... glad to hear it... Well the special for you this weekend is all
Combo Packages are $79.99... Your choice an Emu or a Bootstrap (DPBB) with either a
Dual Crystal ISO or a WT2-X unlooper... your call.
Hope you all Have a Great Weekend... and thanks for the great response on the product
lines. {:-)
PLEASE REMEMBER TO LOG ON to www.spawndevices.com and enter to win anyone of our great
products...FREE WEEKLY DRAWS...
www.spawndevices.com
*
To be removed from our mailing list please click on this link and follow the
directions on the webpage; http://www.spawndevices.com/remove.phtml
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
buildworld fails in libssh on -CURRENT
Having overcome a small issue with buildworld in games/fortune/strfile, there's a new +issue: buildworld fails in /usr/src/secure/lib/libssl make's output is a bit lengthy at this point, so I've slightly clipped it: === libssl ( echo #ifndef MK1MF_BUILD; echo /* auto-generated by crypto/Makefile.ssl for +crypto/cversion.c */; echo #define CFLAGS \cc\; echo #define PLATFORM +\`uname -s`-`uname -m`\; echo #define DATE \`LC_ALL=C date`\; echo #endif +) buildinf.h cc -nostdinc -O -pipe -DTERMIOS -DANSI_SOURCE +-I/usr/src/secure/lib/libssl/../../../crypto/openssl/crypto +-I/usr/obj/usr/src/secure/lib/libssl -DNO_IDEA -DL_ENDIAN -DSHA1_ASM -DBN_ASM -DMD5_ASM +-DRMD160_ASM -DNO_IDEA -I/usr/obj/usr/src/i386/usr/include -c +/usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/t1_srvr.c -o t1_srvr.o rm -f .depend mkdep -f .depend -a -nostdinc -DTERMIOS -DANSI_SOURCE +-I/usr/src/secure/lib/libssl/../../../crypto/openssl/crypto +-I/usr/obj/usr/src/secure/lib/libssl -DNO_IDEA -DL_ENDIAN -DSHA1_ASM -DBN_ASM -DMD5_ASM +-DRMD160_ASM -DNO_IDEA -I/usr/obj/usr/src/i386/usr/include +/usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/bio_ssl.c /us clipping starts for the remainder of mkdep line cd /usr/src/secure/lib/libssl; make _EXTRADEPEND === libssh make: don't know how to make dsa.c. Stop *** Error code 2 Stop in /usr/src/secure/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. If run directly in /usr/src/secure/lib/libssh/ the picture is a bit more verbose, albeit result is the same: # make cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/authfd.c -o authfd.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/authfile.c -o authfile.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/bufaux.c -o bufaux.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/buffer.c -o buffer.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/canohost.c -o canohost.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/channels.c -o channels.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/cipher.c -o cipher.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/compat.c -o compat.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/compress.c -o compress.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/crc32.c -o crc32.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/deattack.c -o deattack.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/hostfile.c -o hostfile.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/log.c -o log.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/match.c -o match.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/mpaux.c -o mpaux.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/nchan.c -o nchan.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/packet.c -o packet.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/readpass.c -o readpass.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/rsa.c -o rsa.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/tildexpand.c -o tildexpand.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/ttymodes.c -o ttymodes.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/uidswap.c -o uidswap.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/xmalloc.c -o xmalloc.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/atomicio.c -o atomicio.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/key.c -o key.o cc -O -pipe -DSKEY -DNO_IDEA -c /usr/src/secure/lib/libssh/../../../crypto/openssh/dispatch.c -o dispatch.o make: don't know how to make dsa.c. Stop -- Andrei __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Headsup! KSE Nay-sayers speak up!
I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! At this stage a commit would break alpha and ia64 until they are patched. From experience I can say that it's not a horrific change to the machine dependent code so patches PRE commit would be welcome. -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Ia64 and ALPHA (+arm, sparc?) kernel developers:
Can the IA64 and Alpha developers (Arm too?) look at the KSE patch set at http://www.freebsd.org/~julian/thediff This compiles and runs pretty solidly on 386. it needs people who understand the other architectures to make the appropriate changes and send them to me (or check them int P4) so that when this is checked into -current their architectures are not broken. (On teh other hand if they would rather fix up the breakage afterwards (which may be easier) then they should let me know so I can get on with committing it. Matt and I want to commit it ASAP, so we can get on with actual threading support. Peter has also indicated that he thinks that it should be done soon, so I need toknow if there will be forthcoming changes for the other architectures, or I should go ahead and commit... -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: exec issue in tcsh?
On Sat, 25 Aug 2001, Jim Bryant wrote: Wow. Why not use xdm? 8) Too lazy? Heh. You just uncomment one line in /etc/ttys and HUP init. It's not compilicated. -- Never put off until tomorrow what you can do today. There might be a law against it by that time. -- /usr/games/fortune, 07/30/2001 Brandon D. Valentine bandix at looksharp.net To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
On Sat, Aug 25, 2001 at 02:02:21PM +0200, Oliver Fromme wrote: Probably because it's just too late. During the initial discussion, the voices pro and contra were about 50:50 (at least that was my impression), and finally the pro ones succeeded, probably because they had more weight (this No, it succeeded because the pro's answered all the questions of the cons and provide work arounds. At the time I imported tcsh, I only remember two decenters. _But_ my vote would be for still having a real csh in /bin, additionally. (And don't tell me that tcsh is a real csh -- it's not, see below.) By chance have you looked at the csh source in the CSRG SCCS files? How about the tcsh sources from day 1 in its CVS repository? Tcsh *is* a direct decendent of CSRG csh. Christos Zulas maintined the CSRG csh in the 4.4 days. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
On Fri, Aug 24, 2001 at 11:10:53PM -0500, Matthew D. Fuller wrote: Then please enumerate them so that they can be given due attention. This is exactly the sort of detailed feedback that was requested when we first raised the issue of switching over, and nobody could come up with any concrete differences that would cause harm, so the deed was done. It blew beets all over the startup script for ROM 2.4 MUD's. Error output?? Script?? We really cannot make things better w/o suffient information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
In message [EMAIL PROTECTED] David W. Chapman
Jr. writes:
: I'm running -current as of an hour ago. I've gotten this since I've
: been running 4.2-stable, any ideas on how I can find out what it
: belongs to?
:
: unknown: PNP0303 can't assign resources
: unknown: PNP0501 can't assign resources
: unknown: PNP0501 can't assign resources
: unknown: PNP0401 can't assign resources
: unknown: PNP0700 can't assign resources
: unknown: PNP0f13 can't assign resources
Don't worry about these.
Warner
Shouldn't we just suppress the message? It just confuses users.
The attached patch will print this message only when we boot
the kernel by 'boot -v'.
Kazu
Index: isa_common.c
===
RCS file: /src/CVS/src/sys/isa/isa_common.c,v
retrieving revision 1.23
diff -u -r1.23 isa_common.c
--- isa_common.c2001/08/10 07:50:14 1.23
+++ isa_common.c2001/08/26 10:24:03
@@ -416,10 +416,11 @@
/*
* Disable the device.
*/
- bus_print_child_header(device_get_parent(child), child);
- printf( can't assign resources\n);
- if (bootverbose)
- isa_print_child(device_get_parent(child), child);
+ if (bootverbose) {
+ bus_print_child_header(device_get_parent(child), child);
+ printf( can't assign resources\n);
+ isa_print_child(device_get_parent(child), child);
+ }
bzero(cfg, sizeof (*cfg));
if (idev-id_config_cb)
idev-id_config_cb(idev-id_config_arg, cfg, 0);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
David O'Brien [EMAIL PROTECTED] wrote: _But_ my vote would be for still having a real csh in /bin, additionally. (And don't tell me that tcsh is a real csh -- it's not, see below.) By chance have you looked at the csh source in the CSRG SCCS files? How about the tcsh sources from day 1 in its CVS repository? Tcsh *is* a direct decendent of CSRG csh. Christos Zulas maintined the CSRG csh in the 4.4 days. No doubt about that, but that's not the point. Did you read what i wrote further down in my message (what I referred to by see below)? Our csh still behaves differently like any /bin/csh on any other system that I know, and can't be easily made to behave like them. When I wrote real csh, I meant a csh which exhibits the traditional behaviour and user interface (look and feel, if you prefer) of a csh. tcsh does not. Someone used to work with a real csh simply can't be happy with tcsh, especially if he has to change frequently between using FreeBSD and other systems. It's a real PITA. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. All that we see or seem is just a dream within a dream (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
On Sun, Aug 26, 2001 at 13:20:23 +0200, Oliver Fromme wrote: Our csh still behaves differently like any /bin/csh on any other system that I know, and can't be easily made to behave like them. When I wrote real csh, I meant a csh which exhibits the traditional behaviour and user interface (look and feel, if you prefer) of a csh. tcsh does not. Someone used to work with a real csh simply can't be happy with tcsh, especially if he has to change frequently between using FreeBSD and other systems. It's a real PITA. I understand your thoughts, but I think you write them to the wrong list. Csh now maintained by tcsh people and known under tcsh name. If you want to restore tradition behaviour at some points, write complaints to tcsh developers instead. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: exec issue in tcsh?
Date: Sun, 26 Aug 2001 02:43:56 -0400 (EDT) From: Brandon D. Valentine [EMAIL PROTECTED] On Sat, 25 Aug 2001, Jim Bryant wrote: Wow. Why not use xdm? 8) Too lazy? Heh. You just uncomment one line in /etc/ttys and HUP init. It's not compilicated. Indeed. However, there are some differences in startup of which to be aware (.xinitrc vs. .xsession). Cheers, david (who quit using xinit about a year ago) -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
fxp SCB timeout problems [FIX]
I believe that I have a real fix for the SCB timeout problems that have been plauging users of recent Intel fxp boards. If you have a board that uses the Intel ICH2/ICH2-M chipset (usually 815E style boards) and feel comfortable applying patches to the system, please contact me to test a fix. The patch works on two different boards here, but I would like to get some wider testing before I commit it to the tree. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
In message [EMAIL PROTECTED] Kazutaka YOKOTA writes: : Shouldn't we just suppress the message? It just confuses users. : : The attached patch will print this message only when we boot : the kernel by 'boot -v'. They are there to remind certain folks that the ISA PnP code is broken slightly and to please fix :-). If we get closer to 5.0 RC1, then yes. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: exec issue in tcsh?
Wow. Why not use xdm? 8) Too lazy? Heh. You just uncomment one line in /etc/ttys and HUP init. It's not compilicated. Indeed. However, there are some differences in startup of which to be aware (.xinitrc vs. .xsession). I just hard-link the two files together. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
: unknown: PNP0303 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0401 can't assign resources : unknown: PNP0700 can't assign resources : unknown: PNP0f13 can't assign resources Shouldn't we just suppress the message? It just confuses users. I would be satisfied just knowing what devices these messages correspond to. I suspect this the sentiment of the original poster as well. brad To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
On Sun, Aug 26, 2001 at 09:51:57AM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Kazutaka YOKOTA writes: : Shouldn't we just suppress the message? It just confuses users. : : The attached patch will print this message only when we boot : the kernel by 'boot -v'. They are there to remind certain folks that the ISA PnP code is broken slightly and to please fix :-). If we get closer to 5.0 RC1, then yes. They are also in RELENG_4.. Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.3-STABLE #2: Mon Jul 30 20:35:10 CEST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/FREEBIE Timecounter i8254 frequency 1193182 Hz ... unknown: PNP can't assign resources unknown: PNP0303 can't assign resources unknown: PNP0f13 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0501 can't assign resources -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
In message [EMAIL PROTECTED] Kazutaka YOK OTA writes: : Shouldn't we just suppress the message? It just confuses users. : : The attached patch will print this message only when we boot : the kernel by 'boot -v'. They are there to remind certain folks that the ISA PnP code is broken slightly and to please fix :-). If we get closer to 5.0 RC1, then yes. Warner Um, we see these messages not only because our ISA PnP driver needs some update, but also because we create ISA device instances TWICE for each motherboard ISA devices, such as sio and atkbdc, due to /boot/device.hints. We need to have /boot/device.hints for those systems without PnP BIOS. On the system with the PnP BIOS, we shall have one ISA device instance (say, sio0) created by the isahint driver based on hints described in /boot/device.hints, and the pnpbios driver will create another instance (sio%d) for the very same device, based on information from the PnP BIOS. Then, we will see unknown: PNPXXX can't assing resources when the second device instance is probed. This happens even if the device driver understands PnP IDs. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
: unknown: PNP0303 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0401 can't assign resources : unknown: PNP0700 can't assign resources : unknown: PNP0f13 can't assign resources Shouldn't we just suppress the message? It just confuses users. I would be satisfied just knowing what devices these messages correspond to. I suspect this the sentiment of the original poster as well. Then go look them up. I'm not about to stuff the entire PnP device database into the kernel just to satisfy your curiosity. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
In message [EMAIL PROTECTED] Wilko Bulte writes: : They are also in RELENG_4.. Those should be hidden by -v then :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fxp SCB timeout problems [FIX]
I have it on two machines with this chipset and it looks good so far. After installing, dmesg shows fxp0: Intel Pro/100 Ethernet port 0xc400-0xc43f mem 0xd5001000-0xd5001fff irq 11 at device 8.0 on pci1 fxp0: *** DISABLING DYNAMIC STANDBY MODE IN EEPROM *** fxp0: New EEPROM ID: 0x49a0 fxp0: EEPROM checksum @ 0xff: 0xe441 - 0xe443 fxp0: *** PLEASE REBOOT THE SYSTEM NOW FOR CORRECT OPERATION *** fxp0: Ethernet address 00:01:80:02:d0:34 inphy0: i82562EM 10/100 media interface on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto and then one more reboot shows fxp0: Intel Pro/100 Ethernet port 0xc400-0xc43f mem 0xd5001000-0xd5001fff irq 11 at device 8.0 on pci1 fxp0: Ethernet address 00:01:80:02:d0:34 inphy0: i82562EM 10/100 media interface on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ---Mike At 10:11 AM 8/26/2001 -0500, Jonathan Lemon wrote: I believe that I have a real fix for the SCB timeout problems that have been plauging users of recent Intel fxp boards. If you have a board that uses the Intel ICH2/ICH2-M chipset (usually 815E style boards) and feel comfortable applying patches to the system, please contact me to test a fix. The patch works on two different boards here, but I would like to get some wider testing before I commit it to the tree. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message Mike Tancsa, tel +1 519 651 3400 Network Administration, [EMAIL PROTECTED] Sentex Communications www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: exec issue in tcsh?
In message [EMAIL PROTECTED] Jim Bryant writes: : Wow. Why not use xdm? 8) : : Too lazy? vi /etc/ttys; s/off/on on xdm line; kill -1 1 Too lazy to do even that? Wow! That's Lazy :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
On Sat, 25 Aug 2001, Kris Kennaway wrote: On Sat, Aug 25, 2001 at 01:50:33AM -0500, Jim Bryant wrote: For 5.0, I maybe the black sheep in saying this, but I'd like to see /bin/csh be the real thing for 5.0. By all means, leave tcsh in /bin, but for the sake of backwards compatability, IMHO `ln /bin/tcsh /bin/csh` was a bad idea. Frankly, this isn't going to happen. We went through all this months ago: please just accept the will of the community and drop the matter. Kris Frankly, this exact statement is the sort of reason I didn't try to weigh in on this issue myself when it happened, or any of a dozen other issues. Adding tcsh is fine, renaming it to csh breaks things. That's like renaming less to more... oh wait, we already did that. The argument isn't to not add new software, it's not even to not drop old software. Add tcsh is fine. Get rid of csh is fine. Just don't call tcsh csh, without making sure the csh call is 100% compatible with the last version of csh shipped. If tcsh were csh, then it would be named csh. Guess what? It's named tcsh because it is NOT csh. It's better to have _nothing_ in /bin/csh and be done with it. If that had been done, I'd have been saved several hours of work and research personally to find out why scores of scripts broke, including some things as simple as login prompts that had embedded escape sequences. I won't say anything more on this issue, and probably on no others as I am fairly sure that it won't be listened to. I will just say that I have been using FreeBSD since 2.0-snap, and have been a consistent advocate of it. I have spent many thousands of dollars having merchandise made (pens, cards, etc), which I gave away free in an effort to bring in users. I have converted my entire company to FreeBSD, and I am now seriously looking at alternatives to FreeBSD. Perhaps net or open, perhaps linux, perhaps forking my own distribution. The motto used to be do it right, not do it the way WE want it on OUR machines, and screw the people who don't make the decisions or cause to much trouble to ignore. If you want to know why the user community is so quiet, you need to ask yourself. If you were spoken to this way, if your preferences and needs were consistently ignored on the basis this is a volunteer project, neener!, how likely would you be to bother commenting? I realize I'll probably get flamed for this, but at this point, I no longer care. I won't be paying to have any more pens or cards made, I won't be making any more deals with companies to get free resources for this community, and I may begin transitioning my network soon. I can't keep spending more time fixing this kind of silly cruft than I did installing the os. [ Name : Christine F. Maxwell] [ ICQ : #45010616 ] [ EMail : [EMAIL PROTECTED] ] [ IRC : Kaila ] [ Home : http://www.cfm.o-o.org/ ] [ BBS : http://www.aci.o-o.org ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
The motto used to be do it right, not do it the way WE want it on OUR machines, and screw the people who don't make the decisions or cause to much trouble to ignore. It still is. And recognising that csh has evolved over the last decade is part of doing it right. What you're really saying is you didn't do what *I* think is right, and I'm packing up my toys and going home. That's your perogative, but it's hardly the mature stance to be taking. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
On Sun, 26 Aug 2001, Mike Smith wrote: The motto used to be do it right, not do it the way WE want it on OUR machines, and screw the people who don't make the decisions or cause to much trouble to ignore. It still is. And recognising that csh has evolved over the last decade is part of doing it right. No, doing it right would have been including tcsh and deprecating csh, then dropping it later as has been done with other things. Naming linking it to csh broke things for people who weren't informed it was happeneing, and then had to go and spend hours tracking down the problem and fixing it. What you're really saying is you didn't do what *I* think is right, and I'm packing up my toys and going home. No, what I am saying is I am a long time user who is getting fed up with THIS type of comment and attitude, and that I might as well go find an alternative that Does it right instead of continuing to put up with having this sort of commentary lobbed at people who dare to voice their opinions. That's your perogative, but it's hardly the mature stance to be taking. Read over your response. What did it have to do with my issues? Nothing. It was a defensive reaction, resorting to name calling because you had nothing logical to refute with. Do you call THIS mature? [ Name : Christine F. Maxwell] [ ICQ : #45010616 ] [ EMail : [EMAIL PROTECTED] ] [ IRC : Kaila ] [ Home : http://www.cfm.o-o.org/ ] [ BBS : http://www.aci.o-o.org ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
On Sun, Aug 26, 2001 at 02:57:31PM -0500, Kaila wrote: On Sun, 26 Aug 2001, Mike Smith wrote: Naming linking it to csh broke things for people who weren't informed it was happeneing, and then had to go and spend hours tracking down the problem and fixing it. How could you be uninformed about this change? The csh vs. tcsh bikeshed happen 16 months ago in the freebsd-current mailing list. Speaking up 16 months later is an unusual way to let the developers know you have an opinion on this change. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
On Sun, Aug 26, 2001 at 01:20:23PM +0200, Oliver Fromme wrote: Our csh still behaves differently like any /bin/csh on any other system that I know, and can't be easily made to behave like them. This is an assertion. Where is your supporting evidence? Kris PGP signature
Re: unknown PNP hardware
Kazutaka YOKOTA wrote: : I'm running -current as of an hour ago. I've gotten this since I've : been running 4.2-stable, any ideas on how I can find out what it : belongs to? : : unknown: PNP0303 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0401 can't assign resources : unknown: PNP0700 can't assign resources : unknown: PNP0f13 can't assign resources Don't worry about these. Shouldn't we just suppress the message? It just confuses users. Shouldn't we just take the Linux/NetBSD information, and actually identify the things instead of saying Unknown, instead, and leave them printing to encourage someone the messages annoy to do the work? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
In message [EMAIL PROTECTED] Terry Lambert writes: : Shouldn't we just take the Linux/NetBSD information, and : actually identify the things instead of saying Unknown, : instead, and leave them printing to encourage someone the : messages annoy to do the work? I'd guess that's too much work. Maybe someone can prove me wrong with trivial patches. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
Andrey A. Chernov wrote: When I wrote real csh, I meant a csh which exhibits the traditional behaviour and user interface (look and feel, if you prefer) of a csh. tcsh does not. Someone used to work with a real csh simply can't be happy with tcsh, especially if he has to change frequently between using FreeBSD and other systems. It's a real PITA. I understand your thoughts, but I think you write them to the wrong list. Csh now maintained by tcsh people and known under tcsh name. If you want to restore tradition behaviour at some points, write complaints to tcsh developers instead. I've been using csh since the early 80's. I can even *gasp!* write csh scripts fairly easily, and do substitution based changes to commands far faster than cursor up 10 times and edit the command. I bitched about this, too, when the switch was being made, but was assured that the system wide defaults and account template defaults would be adjusted to provide traditional behaviour on FreeBSD. I was still grumpy about the change, but that at least was enough to mollify me into not objecting loudly and persitantly up to the import. Let me get this straight, though: _now_ you are saying that the system wide defaults and account template defaults will be whatever the tcsh maintainers say they are, and that any changes that the tcsh maintainers make with instantly and magically be imported into FreeBSD? I think there are a few logic flaws in your plan to have people submit their gripes about the defaults to the tcsh maintainers: 1) They set their defaults the way they like them, and are unlikely to change. 2) A lot of the people who shut up did so on the premise that the defaults would cause tcsh to behave like csh when invoked with that name, and that it was the tcsh users, NOT the csh users, who would have to change away from the system defaults to get their desired behaviour. 3) FreeBSD does not seem to track tcsh changes quickly or religiously enough for a lobbying effort to really be effective. While we may be stuck with this bait-and-switch upgrade, I think his complaints are not co easily addressed. Certainly, the exec complaint remains valid, in any case: it's a bug that csh didn't have. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
On Sun, Aug 26, 2001 at 14:14:48 -0700, Terry Lambert wrote: While we may be stuck with this bait-and-switch upgrade, I think his complaints are not co easily addressed. Certainly, the exec complaint remains valid, in any case: it's a bug that csh didn't have. Complaints _are_ easily addressed, tcsh author is responsible and fix all thing that I report to him. If you complain about 'upgrade' problem, i.e. we don't have latest tcsh, ask our tcsh maintainer for upgrade. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
Thus spake Warner Losh ([EMAIL PROTECTED]): I'd guess that's too much work. Maybe someone can prove me wrong with trivial patches. Maintaining the device-table is probably the most work (since we already have the PNP string and most lists are sortedc by this string as well). Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
It still is. And recognising that csh has evolved over the last decade is part of doing it right. No, doing it right would have been including tcsh and deprecating csh, then dropping it later as has been done with other things. This is what was done. The old csh is deprecated, but still available. Naming linking it to csh broke things for people who weren't informed it was happeneing, and then had to go and spend hours tracking down the problem and fixing it. This is what happens when software is upgraded. It's what they call the price of progress. Most people don't seem to mind it until it impacts them personally, and then they tend to overreact. What you're really saying is you didn't do what *I* think is right, and I'm packing up my toys and going home. No, what I am saying is I am a long time user who is getting fed up with THIS type of comment and attitude, and that I might as well go find an alternative that Does it right instead of continuing to put up with having this sort of commentary lobbed at people who dare to voice their opinions. Opinions were voiced. A decision was made, based on those opinions. Anytime there's more than one opinion, there are going to be losers when the decision is made. The key to surviving is to accept the decision and move on, not make it out to be some grand injustice and then use it to somehow enhance the validity of your argument. That's your perogative, but it's hardly the mature stance to be taking. Read over your response. What did it have to do with my issues? What issues? You haven't raised anything concrete that hasn't already been addressed in this thread. Nothing. It was a defensive reaction, resorting to name calling because you had nothing logical to refute with. Do you call THIS mature? I'm attempting to explain to you how to survive in this situation. The lesson is free, but like most advice, if you abuse the giver, they're prone to walk away and leave you be. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
Steve Kargl wrote: On Sun, Aug 26, 2001 at 02:57:31PM -0500, Kaila wrote: Naming linking it to csh broke things for people who weren't informed it was happeneing, and then had to go and spend hours tracking down the problem and fixing it. How could you be uninformed about this change? The csh vs. tcsh bikeshed happen 16 months ago in the freebsd-current mailing list. Speaking up 16 months later is an unusual way to let the developers know you have an opinion on this change. The bikeshed was not cross-posted to -stable or -hackers, and someone did an MFC on the change, thus bypassing any discussion about getting the change into -stable? Or the natural progression of version changes pushed the change event into the next release, with no real notification, and no csh is deprecated; used tcsh instead message for one major release (i.e. there was no formal deprecation during which people could change their csh scripts)? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
Kris Kennaway wrote: On Sun, Aug 26, 2001 at 01:20:23PM +0200, Oliver Fromme wrote: Our csh still behaves differently like any /bin/csh on any other system that I know, and can't be easily made to behave like them. This is an assertion. Where is your supporting evidence? Hit TAB? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
Kazutaka YOKOTA wrote: Um, we see these messages not only because our ISA PnP driver needs some update, but also because we create ISA device instances TWICE for each motherboard ISA devices, such as sio and atkbdc, due to /boot/device.hints. We need to have /boot/device.hints for those systems without PnP BIOS. On the system with the PnP BIOS, we shall have one ISA device instance (say, sio0) created by the isahint driver based on hints described in /boot/device.hints, and the pnpbios driver will create another instance (sio%d) for the very same device, based on information from the PnP BIOS. Then, we will see unknown: PNPXXX can't assing resources when the second device instance is probed. This happens even if the device driver understands PnP IDs. So, you are saying that this is because there is not a seperate No BIOS and BIOS section (or entry prefix) in the hints file, so that in a non-PnP system, both the No BIOS and BIOS entries will be examined, whereas on a PnP system, only the BIOS entries will be examined? It seems an obvious enhancement to me that there be seperate sections, where the BIOS section is shipped empty, and is only consulted to override broken PnP BIOS contents on PnP BIOS systems... PS: The BIOS section could be shipped non-empty, if it had a per-rogue setion or prefix... then known broken PnP BIOS systems would just work. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
KSE kernel comparissons
Comparative times for 'make buildworld' for unmodified and KSE (milestone-2) kernels unmodified -current 2138.464u 3358.378s 1:37:39.77 93.8%842+1080k 45105+176988io 3208pf+0w modified KSE kernel 2143.716u 3363.311s 1:37:50.33 93.8%841+1081k 45435+176988io 3214pf+0w I'm very glad to see that the overhead added was not too great. (well within the margin of error I'm sure) Same system, same source tree, just different kernel. /usr/obj was deleted before the previous reboot in both cases. Stdout not redirected, running via ssh from another machine. No soft-updates. ref4# size /k* (GENERIC config) textdata bss dec hex filename 3180804 275436 350612 3806852 3a1684 /kernel.normal 3188036 275436 350836 3814308 3a33a4 /kernel.kse My guess is that the size increase in the text area is due to the extra code here and there to take the extra dereference from (p) to (td-td_proc) and the places where there is both a td variabel and a p variable. (with extra code to initialise them) Possibly an extra 1K for code to initialise the more complicated structures too. More actual code will be needed to get away from 1:1, so this is just a baseline. the next steps are for us a s a groupt to decide if this is really the way we want to go, and if so, whether we want to commit these changes to make them available for the world to work on as a base for real threading support. The alternative is to do linux-type threading with processes (peter wemm has been investigating a variant on this scheme). This is probably a no-turning-back commit. It's presently checked in on the FreeBSD p4 tree based on freefall, so it's safe, but we need to make a decision on where it goes next. -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
: unknown: PNP0303 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0401 can't assign resources : unknown: PNP0700 can't assign resources : unknown: PNP0f13 can't assign resources Don't worry about these. Shouldn't we just suppress the message? It just confuses users. Shouldn't we just take the Linux/NetBSD information, and actually identify the things instead of saying Unknown, instead, and leave them printing to encourage someone the messages annoy to do the work? We don't need to take the information from anywhere; I've had most of the comprehensive databases for a while now. The problem with simply stuffing them into the kernel is that they're big, and I tend to agree with folk that we don't really want large single-use string tables in the kernel. This is why the PCI code that identifies unattached drivers reads the strings from a loadable file; once we can safely throw away loaded files, we can load the file at boot/install/whenever time and then throw it away once we're not interested anymore. However, the real reason that most of these strings are being printed is that the ISA probe order is bass-ackwards. The strings are printed because we have good PnP information that tells us a device is present, but we've already gone and believed the ISA hints and stuck a driver in that's claiming some or all of these resources. The messages should be silenced for 4.4, but the deeper problem needs to be addressed as well. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
So, you are saying that this is because there is not a seperate No BIOS and BIOS section (or entry prefix) in the hints file, so that in a non-PnP system, both the No BIOS and BIOS entries will be examined, whereas on a PnP system, only the BIOS entries will be examined? This would be an unnecessary complication. PS: The BIOS section could be shipped non-empty, if it had a per-rogue setion or prefix... then known broken PnP BIOS systems would just work. The amount of work involved in making this just work would be pretty enormous, and most of the applicable systems are approaching relic status, making it hard to find them in order to debug. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
Warner Losh wrote: : Shouldn't we just take the Linux/NetBSD information, and : actually identify the things instead of saying Unknown, : instead, and leave them printing to encourage someone the : messages annoy to do the work? I'd guess that's too much work. Maybe someone can prove me wrong with trivial patches. I think that the correct fix is to deal with the device hints differentially in the PnP BIOS present case, per other posts. Would you accept patches against 4.4-RELEASE? I don't run -current these days, since I need my machines to boot reliably and do real work, other than FreeBSD hacking... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
In message [EMAIL PROTECTED] Terry Lambert writes: : So, you are saying that this is because there is not a seperate : No BIOS and BIOS section (or entry prefix) in the hints file, : so that in a non-PnP system, both the No BIOS and BIOS : entries will be examined, whereas on a PnP system, only the BIOS : entries will be examined? : : It seems an obvious enhancement to me that there be seperate : sections, where the BIOS section is shipped empty, and is only : consulted to override broken PnP BIOS contents on PnP BIOS : systems... : : PS: The BIOS section could be shipped non-empty, if it had : a per-rogue setion or prefix... then known broken PnP BIOS : systems would just work. Since that's not how it works, the solution is a non-starter. We just need to carefully order the ISA code probing sections to get the desired effects. We haven't done that yet. All PnP devices are probed together at the end, which isn't quite right. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
Mike Smith wrote: So, you are saying that this is because there is not a seperate No BIOS and BIOS section (or entry prefix) in the hints file, so that in a non-PnP system, both the No BIOS and BIOS entries will be examined, whereas on a PnP system, only the BIOS entries will be examined? This would be an unnecessary complication. I think the reason the hints are not just ignored is to allow people to fix rogue hardware. I'm willing to be corrected, since this looks like about 12 lines of code would make it ignore device.hints in the PnP BIOS present case. PS: The BIOS section could be shipped non-empty, if it had a per-rogue setion or prefix... then known broken PnP BIOS systems would just work. The amount of work involved in making this just work would be pretty enormous, and most of the applicable systems are approaching relic status, making it hard to find them in order to debug. I wasn't suggesting that the work be done up front! This would have to be handled on a case-by-case basis, by the people having the problems with the defaults sending in their identifying information and the fix that works for them. It would only accumulate the knowledge of the rogues over an extended period of time, on an as-needed basis. Regards, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
Warner Losh wrote: Since that's not how it works, the solution is a non-starter. We just need to carefully order the ISA code probing sections to get the desired effects. We haven't done that yet. All PnP devices are probed together at the end, which isn't quite right. The problem was presented as we are getting two entries for the devices: one for the PnP BIOS, one for the device.hints. Whether it's perfect or not, making the device.hints go away in the presents of PnP BIOS on the machine would seem to be able to address the issue of doubled entries... right? Is there something I'm not seeing here from Kazutaka's posting, or am I being misled? Thanks, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: exec issue in tcsh?
David Wolfskill wrote: Date: Sun, 26 Aug 2001 02:43:56 -0400 (EDT) From: Brandon D. Valentine [EMAIL PROTECTED] On Sat, 25 Aug 2001, Jim Bryant wrote: Wow. Why not use xdm? 8) Too lazy? Heh. You just uncomment one line in /etc/ttys and HUP init. It's not compilicated. Indeed. However, there are some differences in startup of which to be aware (.xinitrc vs. .xsession). Cheers, david (who quit using xinit about a year ago) You are missing the point. This is the way I choose to run X for the moment.. I have a quite nice multi-wm .xsession already in place that I like and works well. Yes, it would take only a moment to enable xdm... The point is that I'm using startx for now. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
In message [EMAIL PROTECTED] Terry Lambert writes: : Warner Losh wrote: : Since that's not how it works, the solution is a non-starter. : : We just need to carefully order the ISA code probing sections to get : the desired effects. We haven't done that yet. All PnP devices are : probed together at the end, which isn't quite right. : : The problem was presented as we are getting two entries for : the devices: one for the PnP BIOS, one for the device.hints. That's a useful high level abstraction of what's happening. However, it isn't completely accurate either. : Whether it's perfect or not, making the device.hints go away : in the presents of PnP BIOS on the machine would seem to be : able to address the issue of doubled entries... right? Not entirely. There are ISA devices in devices.hints that aren't plug and play and aren't in the PnP BIOS list. That's a worse problem than the minor printf :-). : Is there something I'm not seeing here from Kazutaka's posting, : or am I being misled? Yes. Yes. :-) What we'd like to happen: PnP BIOS devices device.hints PnP ISA devices What we do now device.hints PnP BIOS devices PnP ISA devices Note, I tried making the simple changes to make this work, but it failed in subtle ways that I didn't have time to trackdown... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: exec issue in tcsh?
Nate Williams wrote: Wow. Why not use xdm? 8) Too lazy? Heh. You just uncomment one line in /etc/ttys and HUP init. It's not compilicated. Indeed. However, there are some differences in startup of which to be aware (.xinitrc vs. .xsession). I just hard-link the two files together. :) Nate That only works in a single wm arena... What about: case $WMCHOICE in twm) xterm -bg black -fg cyan -sb -sl 5000 -geometry 132x60 twm ;; fvwm95) xterm -bg black -fg cyan -sb -sl 5000 -geometry 132x60 fvwm95 ;; olwm) xterm -bg black -fg cyan -sb -sl 5000 -geometry 132x60 olwm ;; olvwm) xterm -bg black -fg cyan -sb -sl 5000 -geometry 132x60 olvwm ;; wmaker) xscreensaver -timeout 10 -lock-mode -no-splash wmaker ;; motif) xterm -bg black -fg cyan -sb -sl 5000 -geometry 132x60 mwm ;; gnome) xterm -bg black -fg cyan -sb -sl 5000 -geometry 132x60 gnome-session ;; kde2) startkde ;; esac jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
I think the reason the hints are not just ignored is to allow people to fix rogue hardware. I'm willing to be corrected, Good. It's like it is right now because the PnP stuff was bolted on as an afterthought. since this looks like about 12 lines of code would make it ignore device.hints in the PnP BIOS present case. We don't want to ignore the hints either; we just want them to take lower precedence than the PnP BIOS data. Hints can be perfectly valid and relevant in either the broken BIOS or non-PnP device cases. Basically, the problem we have is that we don't have the developer bandwidth to catch up with what has to be done, let alone fix the bandaids that were applied years ago. This results in suboptimal situations like this, something that's only going to be exacerbated as fully funded developer time for FreeBSD-mainline work doesn't seem to be increasing. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
On Sun, Aug 26, 2001 at 03:01:33PM -0700, Terry Lambert wrote: Kris Kennaway wrote: On Sun, Aug 26, 2001 at 01:20:23PM +0200, Oliver Fromme wrote: Our csh still behaves differently like any /bin/csh on any other system that I know, and can't be easily made to behave like them. This is an assertion. Where is your supporting evidence? Hit TAB? Controllable behaviour. Next? Kris P.S. It's already been established (and quite blindingly obvious) that tcsh has different defaults than csh, that's not the issue here. PGP signature
Re: Why is csh tcsh? This can be a bad thing...
Kris Kennaway wrote: On Sun, Aug 26, 2001 at 03:01:33PM -0700, Terry Lambert wrote: Kris Kennaway wrote: On Sun, Aug 26, 2001 at 01:20:23PM +0200, Oliver Fromme wrote: Our csh still behaves differently like any /bin/csh on any other system that I know, and can't be easily made to behave like them. This is an assertion. Where is your supporting evidence? Hit TAB? Controllable behaviour. Next? Hit a single ESC? PS: I've got a million of 'em... er, 256 of 'em... 8-) 8-) -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
Then go look them up. I'm not about to stuff the entire PnP device database into the kernel just to satisfy your curiosity. 8( I was going to ask where, but I see they are in /usr/src/sys/boot/common/pnpdata. thanx, brad To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
Terry Lambert wrote: I was still grumpy about the change, but that at least was enough to mollify me into not objecting loudly and persitantly up to the import. Let me get this straight, though: _now_ you are saying that the system wide defaults and account template defaults will be whatever the tcsh maintainers say they are, and that any changes that the tcsh maintainers make with instantly and magically be imported into FreeBSD? I think there are a few logic flaws in your plan to have people submit their gripes about the defaults to the tcsh maintainers: 1)They set their defaults the way they like them, and are unlikely to change. 2)A lot of the people who shut up did so on the premise that the defaults would cause tcsh to behave like csh when invoked with that name, and that it was the tcsh users, NOT the csh users, who would have to change away from the system defaults to get their desired behaviour. 3)FreeBSD does not seem to track tcsh changes quickly or religiously enough for a lobbying effort to really be effective. While we may be stuck with this bait-and-switch upgrade, I think his complaints are not co easily addressed. Certainly, the exec complaint remains valid, in any case: it's a bug that csh didn't have. Terry, first things first, or is it last things first... I had issued myself a boot to the head because I had simply forgotten to background the startx and issue a logout [been so long since i've done things this way, blah blah blah, boot to the head], This was the second message in this thread, and I asked people to disregard my initial post because of this, shortly after sending the initial message. Since then, this has taken a life of it's own. After reading the ensuing posts, I do have to say that although I don't agree with a lot of the posts against adding more defacto-standard shells to the base distribution [remember the thread about a month ago], I at least now understand one of the base arguments behind the arguments against. I'm not trying to revive that topic, I'm just saying I see what was behind some of the arguments in that thread now. Anyhow, I have other things on my mind right now, such as why installworld is expecting a user named 'bind'... jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
: Whether it's perfect or not, making the device.hints go away
: in the presents of PnP BIOS on the machine would seem to be
: able to address the issue of doubled entries... right?
Not entirely. There are ISA devices in devices.hints that aren't plug
and play and aren't in the PnP BIOS list. That's a worse problem than
the minor printf :-).
: Is there something I'm not seeing here from Kazutaka's posting,
: or am I being misled?
Yes. Yes. :-)
What we'd like to happen:
PnP BIOS devices
device.hints
PnP ISA devices
What we do now
device.hints
PnP BIOS devices
PnP ISA devices
Note, I tried making the simple changes to make this work, but it
failed in subtle ways that I didn't have time to trackdown...
Warner
I once wrote the following patch to deal with this problem by
probing ISA devices in the following order.
1. sensitive ISA devices described in device.hints
2. PnP BIOS ISA devices
3. other ISA devices described in device.hints
4. PnP ISA devices
I am not entirely happy with the patch, though.
Kazu
begin 666 isapnp.diff.gz
M'XL((-]B3L VES87!NYD:69F +U8ZW/:1A#_+/Z*;3+-@59#UXV;CJA
M0%JF!+M _*7M:3I@)N 1$_C:3_[V[=P))!+2SL0SD:SSOOWC\LPMG'
M#O#$M_?%\3K=1Q=!I77__^G,NE-8Y7K -6(@*K=S^5[^0IL0[U8\5P5+!
MV2./%B#PE? X N?2K5=/I^#N053T4S#1-\YGMFFO;CF5?68X-=KO3M#M.
M0Y.2=%T_3TVPEV7*=CMRIOWH#9:+M_1ITC/.F MI,%8-Y@L#WGFS
MP;N[VDT%\-BZJ)@:7,8?4QA(^('!OYJ!5$F9MH RZ$[ $DAC2I9_B@SU!
ML/+YFG[E0C$+EL1;071S+I+TLJ+3Z6S)(J,@,UCR52A8=(EJX+)Y]#]2.
MTTF'N*$U5:MA$\2N?5%^2HY/5V?!TIBX),UMU%=SOK_HAH#?Z;Q%2Q0C
MQB864.7PNP;X/ #1#L_-3UOR#-)I2YJ6*XEW1+_S/TF(EJ1BZ0RR8H6
M+CC^@I3]P?WL=CCM5B6+C#QZ2M[/NL/1;][;X60ZJ[XB:O-''F*HSE?)#49
M$ V_4AYMF731N@ _2?@B*@0]C'/!X46_TL\@8$DK*[\AL)=G;2\[LK4FJ
MLAV?E ]94%2P_2CT_#3U@^741,)E=6H!!3!6_I)VAR9B[*4D@\M,EI@_
M [8) YX6W-A;'@9$5K2[!!]IYMXDB07\,M2Y!O+GQ38A.YTDLJX7O4)GN
M4.?-7F6F(IMY.B_#6,9V.W*[NWO(($?ETF%3*:;'^,+19)6$0UY2U\+G
M?ZV@9]5CGE$$YI*P#Q2!!=PJ@CT$QE\V;@D5,\$!E4=DO4PD%YB]A;U]D
MWWUUE1T!';QZE44,C4N])/53EJFU^C=U!O?SNXF@^E@/%-^? 8GX_C4='
MSQ6? OMYU8Q=:)!G1QOQ1.L);'%.1,RTW)WD\%J7BB3A99NF7JUT*0VC3
M\'=DX/CYY@2RB/ XQ96Y'QC;0(R@%CNF'3G(EZ#*E:%9IL[:5T0*]
MW;0-')%RLD7*'[2M_0DS6S_EH?3N03#_ [F@:X/K04QZ WONQ.OWQMW
MWPTZ%-Y1G6+B-NDPDMK!PB0R,B$Z2@X9',?3JD S K8A@,+[%])/63\K
M:U:WV5F_O,2%3ZZ*\(6:XA,-!I!D%!1^@(N:IFT+UI;5;6E+V5X=%]
M:OF-]ZGER7VJ75JGVE R\L@VM:3]R+;LIN6VP'8[=J/CMC62V29RH@=UW(=
ML.M$[-1E#IMM2B$^VRJ!A0ZG2D]6BY97X@W@N*/FK;YQXTB9B##3CXAJM??D
MO,$#@F_/BY^2.\!J?##S#?1D%*[DN^QYB'6HG%XL;KB !]LU5JZ:GCDL
M%%9.(X/GREGD]R-7R)B.$1R_LVM2T:O7(FE,K=D;^Z(M$$M.($4*OME^
MKI2=!)/CEM#DN) ;6,2.LD6[1; ^SK3L/NV(XF91205)M6W8#[*M.XPHW
M 4CQ\-')^[1L!6:-BC$7(!-8P5?KMI#^8-.[0_]J#L;W@]4Y]T-VY_
M3[UNO^_U?AF.^M6-CW,7UR4IP) YQ-TIXJDCV?QT!PRP'1DZ 1DW'A$E#+
MP6)HW3+2281M)MCV68$LBQ\DKM 3^!ME'V4((#:^641ND[?SNSR[R
MO7F%_,N#K#4XEMNDG#KU3KVN20F%].\I,?L.$E,3:30[CQUC*N\#[60@Q0
M\G',84V?V,V: @RQBW'R![.4G'Y71OEQ5@ R6 \'1)$-)LZQHHM_. )
M$A8EG#I-+I_VQ/L.8TIR KE9G[D;WVF:*]O=:KLP2,P-RO_J2F?\9T
MXI?*XU?)ZC@A'N6$T$2?JGW 4Y;#:9MQ-\32 NW;_H9OPW]E(_@K4?
M^0LF^ZX=9P9NN,V,/RY/?#_'XP[M].AGVC#@=3(;=4EH=/OSL-=$:9
MG_9NW]VATWTLRV=G1O%0[0R[AHX2+.:#1IH3K.5330B[_9Z@^GT=E)-.WV
M5P9DQ@ VM=H!R2I)PW'.L_M^\8X6[!,6!OG2+32V2JI1B@K#6@M,N0XPC
M#5!B%6L_^IX/%7]Z12'6=94(_6AC%+.R?7G^K^]D+3*6]-]:N6)1\/
M/$Z^P8 ZT'R137*,ZKA0F:@;% '4O:MQ[VF)E6O=YI-3J03HX=0LG%:U
M+E%GV\X5=2KU(G2\I!#/-42E_-\BZ(:AO,AGLU]3''@TXT]*=2$O)VJB]_Q
M50JP-(DTL_D*[:1PU63:M'-#X6/+L[;D+S1S([+-'LX7R,B+1-!S,LK_';
MX\8GWT4[?WZ]X:Q1)M**I2FMK+#)R?Q(Y_\61TMZR?(J4Q/ZJ?^[_:=1
+J?P+D26VDX4 :
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
