Hanging at boot
Hi there, Last time (around middle of October) when I tried out a new current kernel it was hanging at boot time at acd1 ata1 is: acd1: DVD-ROM TOSHIBA DVD-ROM SD-M1612 at ata1-slave UDMA33 I tried it again yesterday. Now acd1 seems to be fine. However it hangs at acd2.After the following message acd2: CD-RW MITSUMI DW-7801TE at ata3-master UDMA33 it stops working. No error message is showing up. What data could I provide to help track it down? Manfred ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
[ Lots of CC trimming ] On Sun, Nov 23, 2003 at 06:27:01PM -0500 I heard the voice of Richard Coleman, and lo! it spake thus: You would need to make sure that startup scripts never use tilde expansion. I'm not sure how common that is with RCNG. Not just the startup scripts, but ANY script. I dare say there's a long, long list of scripts that use ~-expansion, to say nothing of the homegrown ones we all have working quietly and forgotten for years. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atacontrol(8) not yielding any output
It seems Bruce M Simpson wrote: Hi all, kimchi# uname -a FreeBSD kimchi.dek.spc.org 5.2-BETA FreeBSD 5.2-BETA #4: Sun Nov 23 01:52:10 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/KIMCHI i386 atacontrol doesn't report any devices. Using commands such as cap/info/list don't yield anything at all. Perhaps more worrying:- kimchi# atacontrol mode 0 atacontrol: ioctl(ATAGMODE): Device not configured The disk and cd themselves are present in dmesg during boot. Uhm, are you sure you have unmodified sources ? sos# uname -a FreeBSD sos.DeepCore.dk 5.2-BETA FreeBSD 5.2-BETA #0: Sun Nov 23 15:59:00 CET 2003 [EMAIL PROTECTED]:/home/SRC/current/sys/i386/compile/SOS i386 sos# atacontrol list ATA channel 0: Master: acd0 QSI CD-RW/DVD-ROM SBW-242/UX02 ATA/ATAPI rev 5 Slave: no device present ATA channel 1: Master: ad2 IC25N060ATMR04-0/MO3OAD0A ATA/ATAPI rev 6 Slave: no device present # -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sun, 23 Nov 2003, Bruce M Simpson wrote: On Sun, Nov 23, 2003 at 02:42:58AM +0100, Brad Knowles wrote: At 5:22 PM -0800 2003/11/22, David O'Brien wrote: Please, NO. There wasn't an FTP client available for this type of recovery pre-/rescue, there shouldn't be one now. Why? Why cut your nose off to spite your face? Even though this capability may not have existed before, why shouldn't we have it now? I think David has valid concerns here about feeping creaturism. fetch has a whole load of library dependencies which go with it, making it unsuitable for inclusion in /rescue in the base system. If you want access to fetch early on in this way, you could make a local branch and maintain the change for your own site, or you could boot from a FreeBSD live CD, or use sysinstall from the installation CD to install a package. I don't see fetch as a requirement for diskless clients. Not diskless clients, but ruined FreeBSD installation. IMHO /rescue is created for it. We shouldn't put fetch into /bin, but placing fetch into crunched executable may be helpful in case of system restore. Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
If you want access to fetch early on in this way, you could make a local branch and maintain the change for your own site, or you could boot from a FreeBSD live CD, or use sysinstall from the installation CD to install a package. I don't see fetch as a requirement for diskless clients. Wrong. Not diskless. Simple w/o CD, DVD, FDC. Only HDD. -- Slawa Olhovchenkov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic when trying to mount cd9660 as udf
Maxime Henrion [EMAIL PROTECTED] writes: Christian Laursen wrote: Maxime Henrion [EMAIL PROTECTED] writes: Christian Laursen wrote: By accident, I tried to mount a CD as UDF, and got the follwoing panic: [snip] Can you try the attached patch and tell me if it fixes your problem? Unfortunately it doesn't seem to make any difference. [snip] Oops, sorry, that patch had 0 chances to work. I now see what is the problem and I'll send you another fix as soon as possible, but can't right now. Alexander Kabaev committed a fix to vfs_mount.c rev. 1.116 which seems to fix the problem. -- Best regards Christian Laursen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
pam_ldap and passwd
I have a server where I use pam_ldap and nss_ldap. Everything works fine except for changing passwords: [EMAIL PROTECTED] passwd passwd: Sorry, `passwd' can only change passwords for local or NIS users. As I understand pam_ldap supports changing LDAP passwords. Is it supposed to work on FreeBSD ? Yuri ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
From: David O'Brien [EMAIL PROTECTED] I'll seriously argue against the 2nd point above. I don't know of a SINGLE person that uses /bin/sh as their interactive shell when multi-user. Not ONE. Every Bourne shell'ish user I've ever met uses Bash, ATT ksh, pdksh, zsh. I don't know anyone that farms lama's, so there cannot be any lama farmers. computer$ grep dmlb /etc/passwd dmlb:*:1166:1166:Duncan Barclay:/home/dmlb:/bin/sh Duncan So, imagine, i'm accidentally deleted /bin with your most wanted static sh... And, of course, due to static nature of /bin/sh it was removed from /rescue? Nothing will protect you from shooting in the leg, neither static linking, nor assumption that /lib is OK. MOST people uses /bin/sh only for rc scripts (to be correct, their system uses it). David O'Brien just tried to told, that NOBODY he knows will be REALLY impacted by performance loss, caused due dynamic /bin/sh linking. You will... So, because Duncan Barclay is impacted by performance loss due dynamic /bin/sh linking, ENTIRE FreeBSD community will have troubles (at least with NSS) due to static linking... Maxim, I was merely rising to David's bait for some proof that people use /bin/sh as an interactive shell. You're correct in saying that if /bin/sh on my machines gets hosed it won't matter too much - I'll use another shell to rebuild the machine, or boot from an install CD to get a shell. But as part of me fixing the machine, I'll put /bin/sh back on. I didn't say anything about NSS and I don't intend to as I don't need it. The debate should be held between people that need the functionality but want it implemented in different ways. As to performance loss, I really don't think I'm going to notice it - the cheapest machine I can find in the UK is an Athlon 1800XP, that has a lot more grunt than I need. This may not be true for others. Duncan Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On Mon, Nov 24, 2003 at 12:14:39AM -, Duncan Barclay wrote: From: David O'Brien [EMAIL PROTECTED] I'll seriously argue against the 2nd point above. I don't know of a SINGLE person that uses /bin/sh as their interactive shell when multi-user. Not ONE. Every Bourne shell'ish user I've ever met uses Bash, ATT ksh, pdksh, zsh. I don't know anyone that farms lama's, so there cannot be any lama farmers. One has to make a strong statement to get the people to come out of the woodwork. Ack. computer$ grep dmlb /etc/passwd dmlb:*:1166:1166:Duncan Barclay:/home/dmlb:/bin/sh Good. Now do you need NSS support? Do the benefits of supporting NSS in /bin/sh for you out-weigh the performance issue of building it dynamically? Couldn't you just as easily use the pdksh port? The machine use I generate doesn't really require a lot of /bin/sh invocations. Either I have file servers, shell boxes, or compute engines running CPU bound jobs for half an hour upwards. Whether it takes a gnats longer to start /bin/sh doesn't really matter to me. However, NSS is likely to feature as needed sometime soon. Duncan -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: null_lookup() vnode locking wierdness
On Mon, 24 Nov 2003 12:53:53 +0600
Boris Popov [EMAIL PROTECTED] wrote:
Yes, this seems to be correct and necessary addition. At first sight,
the later code shouldn't blow because of that. BTW, buildworld -jN on top of
the null mount together with another buildword -jN on the underlying file
system helps a lot to discover vnode locking problems.
While you're looking at nullfs... I get a ENAMETOOLONG while trying to
mount a FS with nullfs or unionfs. The funny thing: realpath reports a
max of 79 characters for both pathnames.
---snip---
{71} FreeBSD 5.1-CURRENT [M87:~netchild/FreeBSD/SystemOnCD]
(62) [EMAIL PROTECTED] # realpath work/SystemOnCD-1/usr/ports/distfiles |wc -c
79
{0} FreeBSD 5.1-CURRENT [M87:~netchild/FreeBSD/SystemOnCD]
(63) [EMAIL PROTECTED] # realpath /space/distfiles |wc -c
17
{0} FreeBSD 5.1-CURRENT [M87:~netchild/FreeBSD/SystemOnCD]
(64) [EMAIL PROTECTED] # mount -t unionfs -o -b /space/distfiles
work/SystemOnCD-1/usr/ports/distfiles
unionfs: /space/distfiles: File name too long
{71} FreeBSD 5.1-CURRENT [M87:~netchild/FreeBSD/SystemOnCD]
(65) [EMAIL PROTECTED] # mount -t unionfs -o -b /space/distfiles /mnt
---snip---
Any ideas what's wrong or where I need to look for a bug?
Bye,
Alexander.
--
If Bill Gates had a dime for every time a Windows box crashed...
...Oh, wait a minute, he already does.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_ldap and passwd
On Mon, 24 Nov 2003 10:39:16 +0100
Yuri Khotyaintsev [EMAIL PROTECTED] wrote:
I have a server where I use pam_ldap and nss_ldap. Everything works
fine except for changing passwords:
[EMAIL PROTECTED] passwd
passwd: Sorry, `passwd' can only change passwords for local or NIS
users.
As I understand pam_ldap supports changing LDAP passwords. Is it
supposed to work on FreeBSD ?
according to src/usr.bin/passwd/passwd.c:
...
/* check where the user's from */
switch (pwd-pw_fields _PWF_SOURCE) {
case _PWF_FILES:
fprintf(stderr, Changing local password for %s\n,
pwd-pw_name);
break;
case _PWF_NIS:
fprintf(stderr, Changing NIS password for %s\n,
pwd-pw_name);
break;
default:
/* XXX: Green men ought to be supported via PAM. */
errx(1,
Sorry, `passwd' can only change passwords for local or NIS users.);
}
...
If you change default: behaviour you CAN change your password. Currently,
passwd is not fully PAM-aware.
clem
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
Bruce M Simpson [EMAIL PROTECTED] writes: I think David has valid concerns here about feeping creaturism. fetch has a whole load of library dependencies which go with it, making it unsuitable for inclusion in /rescue in the base system. Not if you build it without SSL support. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_ldap and passwd
Yuri Khotyaintsev [EMAIL PROTECTED] writes: As I understand pam_ldap supports changing LDAP passwords. Is it supposed to work on FreeBSD ? Unfortunately, for historical reasons, passwd(1) does not use PAM to change the password. You may want to file a PR about this and have it assigned to me. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sun, Nov 23, 2003 at 06:00:36PM -0800, Tim Kientzle wrote: Scenarios that require /rescue are ones in which /bin and /sbin are unusable, which is almost always going to imply a trashed file in /bin, /sbin, or /lib. Thus, most /rescue scenarios are going to involve locating a good copy of a trashed file to replace a damaged local copy. NO. /rescue was allowed in the system to handle the case of a trashed file in /lib[exec]. To allow a sysadmin to recover a system from the same type of mishaps they could before we went to a dynamic /. Not to continue to add to /rescue until the sysadmin could recover from every conceivable way of trashing a system. /rescue was not to become the all-in-compassing Swiss Army recover tool. We provide the Live-FS CD (disc 2) for that. I can only think of a few places where that good copy can come from: * CDROM: requires a CD-ROM drive, and a suitable CD. * floppy: requires a floppy drive * NFS: requires a local network and an NFS server * An HTTP or FTP server: requires a network connection and 'fetch.' I don't think we can safely assume that everyone has access to one of the first three options here. We have made the assumption for the first three options since day one. Why should we change the assumptions just because we now have a dynamic /? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0 on install
On Sun, 23 Nov 2003, Randy Bush wrote: trying to install using the 5.1-release mini cd and em0. it seems not to dhcp (looked with tcpdump) despite my saying Yes (and no to ipv6). am i missing a clue? I can easily cause my em0 to stop working with a 5.1 kernel, by running find on a large filesystem across ssh. This seems to be fixed in current, I could not reproduce it with a 5.2-BETA kernel ( no changes in world ). The mtu size of 9014 may have something to do with the breakage :). -- Sten Spans There is a crack in everything that's how the light gets in. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA lockup
Robert Watson wrote: Any chance you could hook up a serial console, set BREAK_TO_DEBUGGER in kernel options, and see if a serial break drops you to DDB over serial? Under some circumstances a serial break can be more effective getting into the debugger than a console break. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories I have tried this and the serial port looks hung as well. I can't get any response at all. A kernel from the 16th works fine though (and drops me into DDB via serial so this works fine). As were in a code freeze there have not been that many commits in the last week so not much could have changed I guess between 16th and now. I am planning to try two things: 1) Try the latest kernel after sam's commits to various tcp/divert code. I run ipfw2 and ipdivert/natd so you never know :) 2) NFS is still not working and I can't backtrack to previous kernels to find the date it broke due to statfs. As I believe it's still only me and soren who are affected by the looks of it and nobody else I assume there is something very very specifically wrong with my system. Maybe an old library left around and something not recompiled properly against a new one etc. I have no idea. Basically though when the final 5.2-RELEASE is actually available I plan on reinstalling both my desktop and server machines from scratch with a full format and then cvsup to HEAD again to get rid of any cruft left around from my exploits with 5.0-RELEASE all the way through to present. I need to recompile all my ports at some point anyway really so I may as well just install them from scratch I figure. It's possible this might fix NFS. Though I've noticed the NFS thing has become added to the showstopper list for 5.2 so I might have to try this with a JPSNAP instead I guess. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_ldap and passwd
Dag-Erling Smørgrav wrote: Yuri Khotyaintsev [EMAIL PROTECTED] writes: As I understand pam_ldap supports changing LDAP passwords. Is it supposed to work on FreeBSD ? Unfortunately, for historical reasons, passwd(1) does not use PAM to change the password. You may want to file a PR about this and have it assigned to me. DES Done. http://www.freebsd.org/cgi/query-pr.cgi?pr=59638 -- Yuri Khotyaintsev, PhD Swedish Institute of Space Physics, http://www.cluster.irfu.se/yuri Uppsala Division (IRF-U),http://ovt.irfu.se Box 537, S-75121 Uppsala e-mail: yuri AT irfu.se ph: 46-18-471-5929fax: 46-18-471-5905 private: 46-18-462-905 mobile: 46-73-674-8136 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_ldap and passwd
Clement Laforet wrote:
Yuri Khotyaintsev [EMAIL PROTECTED] wrote:
As I understand pam_ldap supports changing LDAP passwords. Is it
supposed to work on FreeBSD ?
according to src/usr.bin/passwd/passwd.c:
...
/* check where the user's from */
switch (pwd-pw_fields _PWF_SOURCE) {
case _PWF_FILES:
fprintf(stderr, Changing local password for %s\n,
pwd-pw_name);
break;
case _PWF_NIS:
fprintf(stderr, Changing NIS password for %s\n,
pwd-pw_name);
break;
default:
/* XXX: Green men ought to be supported via PAM. */
errx(1,
Sorry, `passwd' can only change passwords for local or NIS users.);
}
...
If you change default: behaviour you CAN change your password. Currently,
passwd is not fully PAM-aware.
clem
I think I will wait for official solution rather then hacking myself...
Do you have any patches for this ?
Yuri
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_ldap and passwd
On Mon, 24 Nov 2003 14:17:06 +0100 Yuri Khotyaintsev [EMAIL PROTECTED] wrote: I think I will wait for official solution rather then hacking myself... Wise decision Do you have any patches for this ? Sorry I don't have clean and reliable patch for this... clem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
atheros (ath) - duplicate packets with long distance link
Hi I am getting a lot of duplicate packets on my long distance wireless link, but on my identical link in the Lab everything works fine. (DWL-AG520 adapter). The one adapter is configured in hostap mode, and the other one as a client, both in 11b mode. ( current 5.2-BETA - 24 Nov ) I know there are a lot of CRC errors on the long distance wireless link, but if I swap the hostap device with a 802.11b Lucent AP (over the same distance) then I don't get any duplicate packets. atheros# ./athstats 1 beacon miss interrupts 52 tx management frames 106 tx frames discarded prior to association 4 tx failed 'cuz too many retries 88 long on-chip tx retries 45 tx frames with no ack marked 62 tx frames with short preamble 58979 rx failed 'cuz of bad CRC 11 rx failed 'cuz decryption 1511778 rx failed 'cuz of PHY err 1495162 OFDM timing 16614 CCK timing 2 CCK restart 8 periodic calibrations 40 rate control checks 1 rate control dropped xmit rate AP = DWL-AG520 - HostAP atheros# ping -s 1450 192.168.10.10 PING 192.168.10.10 (192.168.10.10): 1450 data bytes 1458 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=27.432 ms 1458 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=101.903 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=178.306 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=15.965 ms 1458 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=96.968 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=216.500 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=2 ttl=64 time=27.865 ms 1458 bytes from 192.168.10.10: icmp_seq=2 ttl=64 time=107.189 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=3 ttl=64 time=19.401 ms 1458 bytes from 192.168.10.10: icmp_seq=3 ttl=64 time=138.412 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=3 ttl=64 time=213.613 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=4 ttl=64 time=57.855 ms 1458 bytes from 192.168.10.10: icmp_seq=4 ttl=64 time=134.540 ms (DUP!) AP = Lucent AP-1000 PING 146.64.86.3 (146.64.86.3): 56 data bytes 64 bytes from 146.64.86.3: icmp_seq=0 ttl=64 time=81.586 ms 64 bytes from 146.64.86.3: icmp_seq=1 ttl=64 time=4.358 ms 64 bytes from 146.64.86.3: icmp_seq=2 ttl=64 time=2.837 ms 64 bytes from 146.64.86.3: icmp_seq=3 ttl=64 time=3.878 ms 64 bytes from 146.64.86.3: icmp_seq=4 ttl=64 time=3.889 ms 64 bytes from 146.64.86.3: icmp_seq=5 ttl=64 time=5.677 ms 64 bytes from 146.64.86.3: icmp_seq=6 ttl=64 time=3.915 ms 64 bytes from 146.64.86.3: icmp_seq=7 ttl=64 time=3.945 ms 64 bytes from 146.64.86.3: icmp_seq=8 ttl=64 time=5.720 ms Regards Johann ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
mouse problems on Compaq nc4000 / 5.2-BETA
Hello, I've tried to install 5.2-BETA (with ACPI) on my Compaq nc4000 notebook and in /dev I can't find psm(4) entry - it doesn't exist. I've tried to boot my notebook without ACPI - mouse works well, I can use /dev/psm ... I've tried to dump/compile ACPI DSDT table, but I found only one warning: Compiling acpi.dsl acpi.dsl 3898: Name (_WDG, Buffer (0x50) Warning 2033 - ^ Unknown reserved name (_WDG) ASL Input: acpi.dsl - 5180 lines, 163519 bytes, 2800 keywords AML Output: DSDT.aml - 20599 bytes 712 named objects 2088 executable opcodes Compilation complete. 0 Errors, 1 Warnings, 0 Remarks, 679 Optimizations Is it possible to make my build-in mouse work with ACPI :) ? Thank you. vd ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_ldap and passwd
while you are at it can you: --- passwd.cTue Jul 15 12:31:13 2003 +++ passwd.c.orig Sat Apr 19 00:27:09 2003 @@ -119,10 +119,6 @@ fprintf(stderr, Changing NIS password for %s\n, pwd-pw_name); break; - case _PWF_HESIOD: - fprintf(stderr, Changing HESIOD password for %s\n, - pwd-pw_name); - break; default: /* XXX: Green men ought to be supported via PAM. */ errx(1, thanks, danny ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ntpd and kvm_getprocs
Hi :) I'm having a problem with ntpd under 5.2-BETA When I start ntpd, I get the following error message: $ /etc/rc.d/ntpd start ps: kvm_getprocs: No such process Starting ntpd. ntpd get started anyway but does not seem to work, my /var/db/ntp.drift file contains 0.000 and this never changes ... ! Here is my ntp.conf file: #---# server ntp.univ-lyon1.fr prefer server clepsydra.dec.com server ntp0.nl.net driftfile /var/db/ntp.drift restrict 127.0.0.1 restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap restrict default ignore #---# Thanks. -- Antoine Jacoutot [EMAIL PROTECTED] http://www.lphp.org PGP/GnuPG key: http://www.lphp.org/ressources/ajacoutot.asc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic in fridays current
hi I upgraded from 5.1-RELEASE to current from 21st Nov about 10am CET... after make world+kernel I noticed one kernel panic - I was working for about 45 minutes then loaded if_ep module, then it crashed... (after a short while) 28 ?? WL 0:04.61 (swi8: tty:sio clock) was the process reaching some NULL pointer (I suppose) I was running vim + several tcsh sessions but all this was sleeping (I worked on another machine) previous instalation of 5.1-RELEASE havent crashed even once I compiled kernel+world with CPUTYPE = p2 and CFLAGS = -O -pipe nothing more dont know what is this crashed related (can it be that turnstile problem?) to and havent' succeeded to reproduce it - anyone knows more about this? My 3com NIC is pccard one thnx! r.d. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in fridays current
On Mon, 24 Nov 2003, Divacky Roman wrote: I upgraded from 5.1-RELEASE to current from 21st Nov about 10am CET... after make world+kernel I noticed one kernel panic - I was working for about 45 minutes then loaded if_ep module, then it crashed... (after a short while) 28 ?? WL 0:04.61 (swi8: tty:sio clock) was the process reaching some NULL pointer (I suppose) I was running vim + several tcsh sessions but all this was sleeping (I worked on another machine) previous instalation of 5.1-RELEASE havent crashed even once I compiled kernel+world with CPUTYPE = p2 and CFLAGS = -O -pipe nothing more dont know what is this crashed related (can it be that turnstile problem?) to and havent' succeeded to reproduce it - anyone knows more about this? My 3com NIC is pccard one A stack trace and copy of the panic message would be extremely helpful. turnstiles are often implicated in a secondary panic following a page fault, since an assertion fails in the turnstile code when it's invoked from the VM code handling a page fault generated by the kernel. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On Mon, 24 Nov 2003, Maxim M. Kazachek wrote: MOST people uses /bin/sh only for rc scripts (to be correct, their system uses it). David O'Brien just tried to told, that NOBODY he knows will be REALLY impacted by performance loss, caused due dynamic /bin/sh linking. You will... So, because Duncan Barclay is impacted by performance loss due dynamic /bin/sh linking, ENTIRE FreeBSD community will have troubles (at least with NSS) due to static linking... Actually, you appear to be agreeing with him, not disagreeing with him. Duncan was pointing out that he *does* use /bin/sh as his shell, in response to David's suggestion that on one uses it and therefore that making it statically linked wouldn't hurt. It strikes me that this whole conversation has gotten a little confrontational... The middle ground of adding a static /sbin/sh for scripts soudds like a reasonable choice, and has precedent in other systems (Solaris). We can set the boot and periodic scripts to use that, and interactive users can keep using /bin/sh. Someone must be using /bin/sh as a shell, because apparently someone spent a lot of time adding things like character input editing, filename completion, etc. We even use sh as the default in adduser(8). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i have linux mandrake
On Sunday 23 November 2003 23:32, james wrote: I am trying to migrate to free bsd is there a way for me to put freebsd on with it woth out loosing mandrake or the files in it ? This depends on your current disk layout. In general: Yes. You need one spare partition (called slice in FreeBSD) which you can assign hard drive space and create labels inside (also sometimes called Partition) The handbook is always a good point to start, in your case: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install.html -Harry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
David O'Brien wrote: On Sun, Nov 23, 2003 at 06:00:36PM -0800, Tim Kientzle wrote: Scenarios that require /rescue are ones in which /bin and /sbin are unusable, which is almost always going to imply a trashed file in /bin, /sbin, or /lib. Thus, most /rescue scenarios are going to involve locating a good copy of a trashed file to replace a damaged local copy. NO. /rescue was allowed in the system to handle the case of a trashed file in /lib[exec]. To allow a sysadmin to recover a system from the same type of mishaps they could before we went to a dynamic /. Ie, let's do things the same way we did in 1994? Other things have changed since then, hard drives and typical root partitions are much bigger, and Tim estimated the total bloat from this as 64k. Maybe earlier, pre-/rescue, you couldn't recover from damaged files in the root partition without a CD/floppy/NFS, it doesn't mean you should not have that capability in /rescue. For a *lot* of people today (like home users), an up-to-date FreeBSD CD or floppy or a second machine to create the disk on may not be handy (and forget about NFS), but a network connection may still be available. This applies equally if the trashed file is in /lib[exec]. I don't understand this argument of we have never been able to do this, therefore we shouldn't do this now even if we are able to. Rahul ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumb question 'Bad system call' after make world
On Fri, 21 Nov 2003, Barney Wolff wrote: Does make world build a kernel? I didn't think so, and OP's message indicates that make world is all he did. I suspect re-install is the best answer now. Will somebody please tell me when make world is ever correct in the environment of the last several years? I've been unable to understand its continued existence as a target. I'd call it hysterical raisins, but there are some decomposed targets, which I use regularly: buildworld buildkernel installworld installkernel -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
IRQ problem with VAIO laptop again
I had noted a problem with choppy audio after the pci.c update of a week ago; this turns out to be more general. I've also lost firewire and the memory-stick slot (3rd usb controller) completely: --- Copyright (c) 1992-2003 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 5.1-CURRENT #24: Wed Nov 19 13:35:33 PST 2003 [EMAIL PROTECTED]:/d/obj-c/usr/src/sys/PORT2 Preloaded elf kernel /boot/kernel/kernel at 0xc087d000. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) III Mobile CPU 1200MHz (1193.11-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 535298048 (510 MB) avail memory = 510177280 (486 MB) Pentium Pro MTRR support enabled acpi0: SONY C1 on motherboard pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00fdf30 Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu0: C2 state 1 lat acpi_tz0: Thermal Zone port 0x530-0x537 on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 2 INTA is routed to irq 9 pcib0: slot 29 INTA is routed to irq 9 pcib0: slot 29 INTB is routed to irq 9 pcib0: _PRS resource entry has unsupported type 0 agp0: Intel 82830M (830M GMCH) SVGA controller mem 0xe000-0xe007,0xe800-0xefff irq 9 at device 2.0 on pci0 agp0: detected 892k stolen memory agp0: aperture size is 128M pci0: display at device 2.1 (no driver attached) uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0x1800-0x181f irq 9 at device 29.0 on pci0 usb0: Intel 82801CA/CAM (ICH3) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801CA/CAM (ICH3) USB controller USB-B port 0x1820-0x183f irq 9 at device 29.1 on pci0 usb1: Intel 82801CA/CAM (ICH3) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ==++==++==++==++==++==++==++==++==++==++ uhci2: Intel 82801CA/CAM (ICH3) USB controller USB-C port 0x1840-0x185f at device 29.2 on pci0 pcib0: _PRS resource entry has unsupported type 0 uhci2: Could not allocate irq device_probe_and_attach: uhci2 attach returned 6 This one loses the memory-stick slot ==++==++==++==++==++==++==++==++==++==++--- pcib1: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib1 pcib1: _PRS resource entry has unsupported type 0 pcib1: slot 8 INTA is routed to irq 9 ==++==+++=++==++==++==++==++==++==++==++ fwohci0: Texas Instruments TSB43AB22/A mem 0xe020-0xe0203fff,0xe0205000-0xe02057ff at device 2.0 on pci2 pcib1: _PRS resource entry has unsupported type 0 fwohci0: Could not allocate irq device_probe_and_attach: fwohci0 attach returned 6 This one loses firewire ==++==++==++==++==++==++==++==++==++===+==++ cbb0: RF5C475 PCI-CardBus Bridge irq 3 at device 5.0 on pci2 start (8800) sc-membase (e020) end () sc-memlimit (e02f) cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 cbb0: [MPSAFE] fxp0: Intel 82801CAM (ICH3) Pro/100 VE Ethernet port 0x3000-0x303f mem 0xe0204000-0xe0204fff irq 9 at device 8.0 on pci2 fxp0: Ethernet address 08:00:46:4e:96:17 miibus0: MII bus on fxp0 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto cbb1: TI1410 PCI-CardBus Bridge at device 11.0 on pci2 start (8800) sc-membase (e020) end () sc-memlimit (e02f) cardbus1: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 pcib1: slot 11 INTA is routed to irq 9 cbb1: [MPSAFE] isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH3 UDMA100 controller port 0x1860-0x186f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 mem 0xe010-0xe01003ff at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: serial bus, SMBus at device 31.3 (no driver attached) ==++==++==++==++==++==++==++==++==++==++==++ pcm0: Intel ICH3 (82801CA) port 0x18c0-0x18ff,0x1c00-0x1cff irq 9 at device 31.5 on pci0 pcm0: Yamaha YMF753 AC97 Codec This one says it has an IRQ but it doesn't work. Since it is shared with usb, I can get the audio to work fairly well by moving an external mouse around during playing :-( This is the one that I had noticed breakage on; I only noticed the other two devices this morning when I tried to burn a CD.
Re: Unfortunate dynamic linking for everything
Robert Watson writes: It strikes me that this whole conversation has gotten a little confrontational... The middle ground of adding a static /sbin/sh for scripts soudds like a reasonable choice, and has precedent in other systems (Solaris). We can set the boot and periodic scripts to use that, and interactive users can keep using /bin/sh. Someone must be using /bin/sh as a shell, because apparently someone spent a lot of time adding things like character input editing, filename completion, etc. We even use sh as the default in adduser(8). Tru64 also does the /sbin/sh (static) and /bin/sh (dynamic) thing. I've never liked it because standard, portable shell scipts expect to use /bin/sh. Standard, portable shell scripts don't need tilde expansion for ldap/nss usernames. So I think the best solution (*) would be to keep /bin/sh statically linked, and build a dynamic version in /usr/bin that people can use as an interactive shell. Root's shell remains /bin/sh 1) All three (;-) interactive bourne shell users that use nss/ldap get tilde expansion. 2) 3rd party scripts, which are written to be portable and don't use tilde, don't have to pay for dynamic linking. 3) System startup scripts are faster because they use the static /bin/sh (*) The real best solution would be to backout the dynamic linking changes and put the onus on those who want/need nss/ldap to prove that the dynamic linking changes do not produce a measurable slowdown (as they were asked to do 6 months ago, and never did). If it really slows things down, then they need to fix the performance problems by either speeding up dynamic linking, or getting the features they need in another, less invasive way (as discussed previously in this thread). Drew [reply-to set to freebsd-current, as I don't want to be CC'ed on this thread forever.. ] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Mon, 24 Nov 2003 03:40:06 -0800, David O'Brien [EMAIL PROTECTED] said: We have made the assumption for the first three options since day one. Why should we change the assumptions just because we now have a dynamic /? Because we are not all masochists. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IRQ problem with VAIO laptop again
I had noted a problem with choppy audio after the pci.c update of a week ago; this turns out to be more general. I've also lost firewire and the memory-stick slot (3rd usb controller) completely: --- Following up to my own note: With no visible change to dmesg, the audio now appears to work at least pretty well, maybe a little chop but acceptable with no changes to pci.c; maybe some acpi change fixed it? Music plays at least fairly well now, but the X-windows beep function (using kde + artsd) still seems rather delayed but now completely non-choppy. However, the firewire and memory-stick are still listed as missing in action... I can't burn a cd using my usb drive since this laptop doesn't support ehci (can send the files to another computer with an internal drive). I will check this again, but I am pretty sure that I have plug-and-play OS turned ON in my bios since last summer when the acpi started working fairly well. How is this supposed to be set now on non-acpi motherboards (I have several such that run current; one Aladdin-5 K6-2 (ASUS has acpi, but at least one of my cheap ones doesn't), and an embedded-controller (Cyrix GX) mini-system)? -- Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) - duplicate packets with long distance link
Off-the-wall suggestion: run tcpdump -e and check whether both responses are coming from the same host. Unless you're running WEP, you many have an unexpected guest. (WEP is no guarantee, but it's better than nothing.) On Mon, Nov 24, 2003 at 03:55:13PM +0200, Johann Hugo wrote: Hi I am getting a lot of duplicate packets on my long distance wireless link, but on my identical link in the Lab everything works fine. (DWL-AG520 adapter). The one adapter is configured in hostap mode, and the other one as a client, both in 11b mode. ( current 5.2-BETA - 24 Nov ) I know there are a lot of CRC errors on the long distance wireless link, but if I swap the hostap device with a 802.11b Lucent AP (over the same distance) then I don't get any duplicate packets. atheros# ./athstats 1 beacon miss interrupts 52 tx management frames 106 tx frames discarded prior to association 4 tx failed 'cuz too many retries 88 long on-chip tx retries 45 tx frames with no ack marked 62 tx frames with short preamble 58979 rx failed 'cuz of bad CRC 11 rx failed 'cuz decryption 1511778 rx failed 'cuz of PHY err 1495162 OFDM timing 16614 CCK timing 2 CCK restart 8 periodic calibrations 40 rate control checks 1 rate control dropped xmit rate AP = DWL-AG520 - HostAP atheros# ping -s 1450 192.168.10.10 PING 192.168.10.10 (192.168.10.10): 1450 data bytes 1458 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=27.432 ms 1458 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=101.903 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=178.306 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=15.965 ms 1458 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=96.968 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=216.500 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=2 ttl=64 time=27.865 ms 1458 bytes from 192.168.10.10: icmp_seq=2 ttl=64 time=107.189 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=3 ttl=64 time=19.401 ms 1458 bytes from 192.168.10.10: icmp_seq=3 ttl=64 time=138.412 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=3 ttl=64 time=213.613 ms (DUP!) 1458 bytes from 192.168.10.10: icmp_seq=4 ttl=64 time=57.855 ms 1458 bytes from 192.168.10.10: icmp_seq=4 ttl=64 time=134.540 ms (DUP!) AP = Lucent AP-1000 PING 146.64.86.3 (146.64.86.3): 56 data bytes 64 bytes from 146.64.86.3: icmp_seq=0 ttl=64 time=81.586 ms 64 bytes from 146.64.86.3: icmp_seq=1 ttl=64 time=4.358 ms 64 bytes from 146.64.86.3: icmp_seq=2 ttl=64 time=2.837 ms 64 bytes from 146.64.86.3: icmp_seq=3 ttl=64 time=3.878 ms 64 bytes from 146.64.86.3: icmp_seq=4 ttl=64 time=3.889 ms 64 bytes from 146.64.86.3: icmp_seq=5 ttl=64 time=5.677 ms 64 bytes from 146.64.86.3: icmp_seq=6 ttl=64 time=3.915 ms 64 bytes from 146.64.86.3: icmp_seq=7 ttl=64 time=3.945 ms 64 bytes from 146.64.86.3: icmp_seq=8 ttl=64 time=5.720 ms Regards Johann ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
[ From: set to /dev/null as too many can't follow the Reply-To: ]
On Mon, Nov 24, 2003 at 11:00:24AM -0500, Rahul Siddharthan wrote:
NO. /rescue was allowed in the system to handle the case of a trashed
file in /lib[exec]. To allow a sysadmin to recover a system from the
same type of mishaps they could before we went to a dynamic /.
Ie, let's do things the same way we did in 1994? Other things have
changed since then, hard drives and typical root partitions are much
bigger, and Tim estimated the total bloat from this as 64k. Maybe
earlier, pre-/rescue, you couldn't recover from damaged files in the
root partition without a CD/floppy/NFS, it doesn't mean you should not
have that capability in /rescue.
Lets have /rescue/{[s]bin,usr/[s]bin}. Install static copies of every
thing in /[s]bin and /usr/[s]bin today. That will let you recover in
even more ways.
Where does it end if we don't go full-out and install a 2nd copy of every
binary?
For a *lot* of people today (like home users), an up-to-date FreeBSD
CD or floppy or a second machine to create the disk on may not be
handy (and forget about NFS), but a network connection may still be
available.
That network connection would most likely be a M$-Win box in that case,
which doesn't have an FTP server. Samba, not an FTP client should be in
/rescue then.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Mon, Nov 24, 2003 at 11:46:54AM -0500, Garrett Wollman wrote: On Mon, 24 Nov 2003 03:40:06 -0800, David O'Brien [EMAIL PROTECTED] said: We have made the assumption for the first three options since day one. Why should we change the assumptions just because we now have a dynamic /? Because we are not all masochists. Why wasn't it enough of a problem to bring up until we went to a dynamic /? Not having a usable FTP client if your libs are FUBAR'ed isn't new with dynamic. Now that it is brought up, where does it end what goes into /rescue? Having what goes into /rescue bounded only by what is in /[s]bin, /usr/[s]bin is what worries some of us. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On Mon, Nov 24, 2003 at 10:47:24AM -0500, Robert Watson wrote: It strikes me that this whole conversation has gotten a little confrontational... The middle ground of adding a static /sbin/sh for scripts soudds like a reasonable choice, and has precedent in other systems (Solaris). Time for a pdksh import! We can install it as the dynamic /bin/sh, and there is precedent in other systems (Solaris) for /bin/ksh. The issue with static /sbin/sh is that we have to fix all the base scripts (doable), and then try to educate people that they need to do the same to their scripts (very hard to do). Someone must be using /bin/sh as a shell, because apparently someone spent a lot of time adding things like character input editing, filename completion, etc. Filename complete isn't in stock /bin/sh as its a private hack someone did, it is a hack and isn't commitable. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Sun, Nov 23, 2003 at 04:14:08PM +0200, Enache Adrian wrote:
$ cc close.c -o close ./close
0
0
$ cc close.c -lc_r -o close ./close
0
25
$ cat close.c
#include errno.h
main()
{
int fd = open(/dev/null, 1);
printf(%d\n, errno);
close(fd);
printf(%d\n, errno);
}
This confuses rather badly applications which assume errno is meaningful.
The application is broken. You must only check errno if you get an
error indication from the library call.
URL:http://www.opengroup.org/onlinepubs/007904975/functions/errno.html
IEEE Std 1003.1, 2003 Edition says, in part:
``The value of errno should only be examined when it is indicated to
be valid by a function's return value.''
Cheers,
--
Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum still not working
On Sunday 23 November 2003 23:50, you wrote: Yes. The fix wasn't enough. I was holding off committing until I could test it. Thanks for YOUR commit! :-) All works fine here now... -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PII SMP system hangs during boot with ACPI enabled
On 24-Nov-2003 Nate Lawson wrote: Please add debug.acpi.disable=cpu to loader.conf or type that in at the loader prompt. If it boots ok, we'll have to debug the acpi_cpu_startup path. Thanks. It still hangs even with debug.acpi.disable=cpu. I have attached the verbose boot messages. They are essentially the same as the previous messages, except that the acpi_cpu messages are gone now as expected. If there's anything else I should try, just let me know. John SMAP type=01 base= len=0009fc00 SMAP type=02 base=0009fc00 len=0400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=0fee SMAP type=03 base=0ffe len=00018000 SMAP type=04 base=0fff8000 len=8000 SMAP type=02 base=fec0 len=1000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=fffc len=0004 Copyright (c) 1992-2003 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 5.2-BETA #1: Sun Nov 23 13:32:22 PST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/VASHON Preloaded elf kernel /boot/kernel/kernel at 0xc07bc000. ACPI APIC Table: TYANCP TYANTBLE Calibrating clock(s) ... i8254 clock: 1193039 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 400911753 Hz CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping = 2 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM OV,PAT,PSE36,MMX,FXSR real memory = 268304384 (255 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00829000 - 0x0fb39fff, 254873600 bytes (62225 pages) avail memory = 255262720 (243 MB) APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00fdb40 bios32: Entry = 0xfdb50 (c00fdb50) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdb71 pnpbios: Found PnP BIOS data at 0xc00f72c0 pnpbios: Entry = f:6964 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 MADT: Found IO APIC ID 2, Vector 0 at 0xfec0 ioapic0: intpin 0 - ExtINT (edge, activehi) ioapic0: intpin 1 - irq 1 (edge, activehi) ioapic0: intpin 2 - irq 2 (edge, activehi) ioapic0: intpin 3 - irq 3 (edge, activehi) ioapic0: intpin 4 - irq 4 (edge, activehi) ioapic0: intpin 5 - irq 5 (edge, activehi) ioapic0: intpin 6 - irq 6 (edge, activehi) ioapic0: intpin 7 - irq 7 (edge, activehi) ioapic0: intpin 8 - irq 8 (edge, activehi) ioapic0: intpin 9 - irq 9 (edge, activehi) ioapic0: intpin 10 - irq 10 (edge, activehi) ioapic0: intpin 11 - irq 11 (edge, activehi) ioapic0: intpin 12 - irq 12 (edge, activehi) ioapic0: intpin 13 - irq 13 (edge, activehi) ioapic0: intpin 14 - irq 14 (edge, activehi) ioapic0: intpin 15 - irq 15 (edge, activehi) ioapic0: intpin 16 - irq 16 (level, activelo) ioapic0: intpin 17 - irq 17 (level, activelo) ioapic0: intpin 18 - irq 18 (level, activelo) ioapic0: intpin 19 - irq 19 (level, activelo) ioapic0: intpin 20 - irq 20 (level, activelo) ioapic0: intpin 21 - irq 21 (level, activelo) ioapic0: intpin 22 - irq 22 (level, activelo) ioapic0: intpin 23 - irq 23 (level, activelo) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 - intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: active-hi MADT: intr override: source 9, irq 20 ioapic0: intpin 9 disabled ioapic0: intpin 20 trigger: level ioapic0: intpin 20 polarity: active-hi ioapic0 Version 1.1 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00040011 LDR: 0x0100 DFR: 0x0fff lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled acpi0: TYANCP TYANTBLE on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: Power Button (fixed) ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
From: Jacques A. Vidrine [EMAIL PROTECTED] The application is broken. You must only check errno if you get an error indication from the library call. errno is only meaningful after a syscall error. it is also well known that stdio uses isatty(3) (or equivelant) that may set errno to ENOTTY. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote: From: Jacques A. Vidrine [EMAIL PROTECTED] The application is broken. You must only check errno if you get an error indication from the library call. errno is only meaningful after a syscall error. Wrong, counter-example: strtol(). Stefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-BETA USB woes
The full tale of woe can be found at: http://www.lovett.com/~ade/freebsd.html The executive summary is that after some unfortunate hardware failures, I picked up an ASUS A7V8X-X motherboard with a 6 USB 2.0 ports. GENERIC doesn't appear to have ehci in it, so not a great deal happened. I then took the GENERIC kernel, ripped out all of the USB code from the kernel and enabled usbd(8) to hopefully do the right thing. There's a single USB device connected up (an MS optical cordless wheelmouse, which works just fine with XP and Gentoo Linux, and is seen by 4.9-RELEASE, though nothing much happens with moused). Here's what happened: uhci0: VIA 83C572 USB controller port 0xb000-0xb01f irq 21 at device 16.0 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xa800-0xa81f irq 21 at device 16.1 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 uhci2: VIA 83C572 USB controller port 0xa400-0xa41f irq 21 at device 16.2 on pci0 usb2: VIA 83C572 USB controller on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhub1: port error, restarting port 1 uhub1: port error, giving up port 1 uhub1: port error, restarting port 2 uhub1: port error, giving up port 2 ehci0: EHCI (generic) USB 2.0 controller mem 0xf100-0xf1ff irq 21 at device 16.3 on pci0 ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 uhub0: port error, restarting port 2 uhub0: port error, giving up port 2 uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 usb3: EHCI (generic) USB 2.0 controller on ehci0 usb3: USB revision 2.0 uhub3: (0x1106) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered uhub2: port error, restarting port 1 uhub2: port error, giving up port 1 uhub2: port error, restarting port 2 uhub2: port error, giving up port 2 No mouse detected, usbd is running, but all the ports are dead. Disconnecting and reconnecting the mouse has absolutely no effect whatsoever. If a friendly USB guru happens to be around, I can provide ssh and root access to the box, or if there are further diagnostics I can run, please let me know. -aDe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
At 3:40 AM -0800 11/24/03, David O'Brien wrote: NO. /rescue was allowed in the system to handle the case of a trashed file in /lib[exec]. To allow a sysadmin to recover a system from the same type of mishaps they could before we went to a dynamic /. Not to continue to add to /rescue until the sysadmin could recover from every conceivable way of trashing a system. /rescue was not to become the all-in-compassing Swiss Army recover tool. We provide the Live-FS CD (disc 2) for that. Another issue with adding more-and-more to /rescue is that every thing added to /rescue is compiled for it. Which is to say, the time it takes for a buildworld keeps increasing. I just bought one hardware upgrade to get back the time lost from going to GCC 3.x, and I find that the buildworld times are now increasing again due to compiling everything twice for /rescue. I kind of like the idea of having 'vi' available, but I will also admit that I don't need it. All my hardware has CD-ROM drives, and I set up all my systems with multiple (multi-boot) installs of freebsd. If something goes wrong, I like having vi around, but then I also like having bash and ruby (among other things). So, I have dual-boot systems. No matter what you put in /rescue, there are *possible* disaster scenarios where you won't have something you need. For some reason, I manage to hit those every few months. From my experience I have found that it's much better to have multiple separate installs, and that way I can usually fix one install from the other one. Other people will have other hardware, and thus other needs. We should probably make sure it's easy to add some of these programs to /rescue, but I don't think that all of us should have to build all the programs that any one of us feel they might need. I doubt there is any perfect answer which will satisfy everyone, but perhaps we can recognize that and figure out some flexible middle ground. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) - duplicate packets with long distance link
On Monday 24 November 2003 09:07 am, Barney Wolff wrote: Off-the-wall suggestion: run tcpdump -e and check whether both responses are coming from the same host. Unless you're running WEP, you many have an unexpected guest. (WEP is no guarantee, but it's better than nothing.) Better, use tcpdump -e -i ath0 -y IEEE802_11 and verify the 802.11 frames are actual duplicates. They should not be unless there's a bug in the duplicate suppression logic in the 802.11 code. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PII SMP system hangs during boot with ACPI enabled
On Mon, 24 Nov 2003, John Polstra wrote: On 24-Nov-2003 Nate Lawson wrote: Please add debug.acpi.disable=cpu to loader.conf or type that in at the loader prompt. If it boots ok, we'll have to debug the acpi_cpu_startup path. Thanks. It still hangs even with debug.acpi.disable=cpu. I have attached the verbose boot messages. They are essentially the same as the previous messages, except that the acpi_cpu messages are gone now as expected. Ok, that indicates that it's not the acpi_cpu changes. If there's anything else I should try, just let me know. Please also send the output of acpidump -t -d jdp-P2.asl If you can break to the debugger after it has hung, a tr would be nice. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PII SMP system hangs during boot with ACPI enabled
On Mon, 24 Nov 2003, John Polstra wrote: On 24-Nov-2003 Nate Lawson wrote: Please add debug.acpi.disable=cpu to loader.conf or type that in at the loader prompt. If it boots ok, we'll have to debug the acpi_cpu_startup path. Thanks. It still hangs even with debug.acpi.disable=cpu. I have attached the verbose boot messages. They are essentially the same as the previous messages, except that the acpi_cpu messages are gone now as expected. If there's anything else I should try, just let me know. It's a long shot, but what about setting kern.timecounter.hardware to i8254. It appears your ACPI timer is bad. The reason why I suggest this is that it seems like interrupts are being lost. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) - duplicate packets with long distance link
On Monday 24 November 2003 21:22, Sam Leffler wrote: tcpdump -e -i ath0 -y IEEE802_11 and verify the 802.11 frames are actual duplicates. They should not be unless there's a bug in the duplicate suppression logic in the 802.11 code. The packets are definately from the same host. Will it help if I recompile with AR_DEBUG turned on ? PING 192.168.10.10 (192.168.10.10): 56 data bytes 64 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=4.373 ms 64 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=74.278 ms (DUP!) 64 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=2.646 ms 64 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=83.930 ms (DUP!) 64 bytes from 192.168.10.10: icmp_seq=2 ttl=64 time=2.631 ms 64 bytes from 192.168.10.10: icmp_seq=3 ttl=64 time=4.127 ms atheros# tcpdump -e -i ath0 -y IEEE802_11 proto ICMP tcpdump: data link type DLT_IEEE802_11 tcpdump: listening on ath0 00:04:57.452451 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:f0:4 DA:0:5:5d:95:ef:2c 192.1 68.10.20 192.168.10.10: icmp: echo request 00:04:57.455152 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.457598 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.461559 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.467485 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.478495 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.483984 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.490683 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.509604 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.531031 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.546951 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:57.557694 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.469354 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:f0:4 DA:0:5:5d:95:ef:2c 192.1 68.10.20 192.168.10.10: icmp: echo request 00:04:58.473004 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.476335 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.488546 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.508876 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.521360 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.528470 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.537460 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.547434 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:58.551423 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 192.168.10.20: icmp: echo reply 00:04:59.479303 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:f0:4 DA:0:5:5d:95:ef:2c 192.1 68.10.20 192.168.10.10: icmp: echo request Johann ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
Garance A Drosihn wrote: Another issue with adding more-and-more to /rescue ... I am certainly not suggesting adding more-and-more to /rescue. The dynamic root is a new feature with as-yet-unknown failure modes. As we understand those failure modes, we can fine-tune the contents of /rescue. I'm trying to understand what those failure modes are and what that implies about the contents of /rescue. I do want /rescue to be small and I want it to compile quickly. But I mostly want it to be useful to the people who need it. I kind of like the idea of having 'vi' available, ... I'm personally tempted to remove vi/ex from /rescue. I originally put it in based on my experience recovering systems where I needed to edit configure files. But, I've not managed to come up with a scenario where a broken config file would break /bin. If that's the case, then vi isn't needed in /rescue, since the purpose of /rescue is to repair a broken /bin, /sbin, /lib. Once those are working, you can mount /usr and have access to /usr/bin/vi. Contrary to what David claims, I don't think /rescue does need to support all of the recovery actions that a static /s?bin would support. Rather, I think it only needs to support those recovery actions necessary to repair /bin and /sbin if they break. That could be a very small set of tools. It is not necessarily a subset of /bin and /sbin, however. Unfortunately (or fortunately, I suppose), few people seem to have actually needed /rescue, so we as a community don't yet have enough experience to really tailor that toolkit. disaster scenarios where you won't have something you need. For some reason, I manage to hit those every few months. The only way to find out what's truly necessary in /rescue is to pay attention to people who actually use it. If someone knows they'll never use it, NO_RESCUE has been shown to measurably reduce buildworld times. I doubt there is any perfect answer which will satisfy everyone, but perhaps we can recognize that and figure out some flexible middle ground. That's exactly what I'm trying to do. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IRQ problem with VAIO laptop again
uhci2: Intel 82801CA/CAM (ICH3) USB controller USB-C port 0x1840-0x185f at device 29.2 on pci0 pcib0: _PRS resource entry has unsupported type 0 uhci2: Could not allocate irq device_probe_and_attach: uhci2 attach returned 6 This one loses the memory-stick slot pcib1: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib1 pcib1: _PRS resource entry has unsupported type 0 pcib1: slot 8 INTA is routed to irq 9 fwohci0: Texas Instruments TSB43AB22/A mem 0xe020-0xe0203fff,0xe0205000-0xe02057ff at device 2.0 on pci2 pcib1: _PRS resource entry has unsupported type 0 fwohci0: Could not allocate irq device_probe_and_attach: fwohci0 attach returned 6 This one loses firewire The problem is that your _PRS values are incorrect. Actually, I think jhb committed some code to deal with extended irq resources. Send me the output of acpidump -t -d pete-SonyVaio.asl Also, does booting without ACPI fix things? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
40% slowdown with dynamic /bin/sh
Here is a simple test which times the execution of a null shell script. It basically times fork/exec of the chosen shell. % cat harness.sh #!/bin/sh sh=$1 cnt=$2 i=0 while [ $i -le $cnt ]; do $sh ./foo i=`expr $i + 1` done #eof %cat foo exit #eof % ldd sh.dynamic sh.dynamic: libedit.so.4 = /lib/libedit.so.4 (0x2808c000) libncurses.so.5 = /lib/libncurses.so.5 (0x280a1000) libc.so.5 = /lib/libc.so.5 (0x280e1000) % ldd sh.static ldd: sh.static: not a dynamic executable Here are some timings taken from ref5.freebsd.org: % /usr/bin/time ./harness.sh ./sh.dynamic 100 1.55 real 0.27 user 1.11 sys % /usr/bin/time ./harness.sh ./sh.dynamic 100 1.55 real 0.28 user 1.10 sys % /usr/bin/time ./harness.sh ./sh.dynamic 100 1.60 real 0.21 user 1.18 sys % ./harness.sh ./sh.static 100 1.12 real 0.08 user 0.87 sys % ./harness.sh ./sh.static 100 1.12 real 0.08 user 0.87 sys % ./harness.sh ./sh.static 100 1.12 real 0.11 user 0.84 sys So.. forking a dynamic sh is roughly 40% more expensive than forking a static copy of sh. This is embarrassing. I propose that we at least make /bin/sh static. (and not add a /sbin/sh; if we must have a dynamic sh, import pdksh, or put a dynamically linked sh in /usr/bin/sh). I'd greatly prefer that the the dynamic root default be backed out until a substantial amount of this performance can be recovered. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR filedesc structure / Giant
This is with a current from around two days ago, with a kernel not much different from GENERIC. lock order reversal 1st 0xc48ab234 filedesc structure (filedesc structure) @ /usr/src/sys/kern/sys_generic.c:896 2nd 0xc0729a60 Giant (Giant) @ /usr/src/sys/fs/specfs/spec_vnops.c:377 Stack backtrace: backtrace(c06cdeaa,c0729a60,c06ca2ff,c06ca2ff,c06c5b0c) at backtrace+0x17 witness_lock(c0729a60,8,c06c5b0c,179,0) at witness_lock+0x686 _mtx_lock_flags(c0729a60,0,c06c5b0c,179,c06ce4b1) at _mtx_lock_flags+0xb4 spec_poll(d79e7afc,d79e7b1c,c05897b4,d79e7afc,c071e1a0) at spec_poll+0x113 spec_vnoperate(d79e7afc,c071e1a0,c4692208,40,c4888f00) at spec_vnoperate+0x18 vn_poll(c466f7f8,40,c4888f00,c4425c80,c4888f00) at vn_poll+0x3c selscan(c4425c80,d79e7b9c,d79e7b8c,5,4) at selscan+0x11a kern_select(c4425c80,5,bfbfe3f8,0,0) at kern_select+0x368 select(c4425c80,d79e7d14,c06e5eae,3ee,5) at select+0x67 syscall(2f,2f,2f,1,bfbfed24) at syscall+0x292 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (93), eip = 0x280c7073, esp = 0xbfbfe39c, ebp = 0xbfbfecf0 --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3c fault code = supervisor read, page not present instruction pointer = 0x8:0xc04e1305 stack pointer = 0x10:0xd8c0a8a8 frame pointer = 0x10:0xd8c0a978 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 19005 (patch) kernel: type 12 trap, code=0 Stopped at devfs_lookupx+0x448:movl0x3c(%eax),%eax db trace devfs_lookupx(d8c0a9d0,1,0,c6592500,c4658c30) at devfs_lookupx+0x448 devfs_lookup(d8c0a9d0,c6592500,0,c6592500,c6592500) at devfs_lookup+0x4b lookup(d8c0abdc,0,c06d1d39,a6,c6592500) at lookup+0x2e0 namei(d8c0abdc,c072f3a8,0,c6592500,c07358e0) at namei+0x235 vn_open_cred(d8c0abdc,d8c0acdc,d,c4888f00,4) at vn_open_cred+0x257 vn_open(d8c0abdc,d8c0acdc,d,4,d8c0ab80) at vn_open+0x33 kern_open(c6592500,80527e6,0,3,f) at kern_open+0xd0 open(c6592500,d8c0ad14,c06e5eae,3ee,3) at open+0x30 syscall(2f,2f,2f,80543d0,0) at syscall+0x292 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x280c47b3, esp = 0xbfbfeb2c, ebp = 0xbfbfeb58 --- -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
recursed on non-recursive lock (sleep mutex) vnode interlock @ /var/portbuild/sparc64/src-client/sys/ufs/ufs/ufs_ihash.c:128
One of my sparc64 package machines (running -current from Nov 21) died overnight with the following: recursed on non-recursive lock (sleep mutex) vnode interlock @ /var/portbuild/sparc64/src-client/sys/ufs/ufs/ufs_ihash.c:128 first acquired @ /var/portbuild/sparc64/src-client/sys/ufs/ufs/ufs_ihash.c:128 panic: recurse cpuid = 0; Debugger(panic) Stopped at Debugger+0x1c: ta %xcc, 1 db trace panic() at panic+0x174 witness_lock() at witness_lock+0x3b4 _mtx_lock_flags() at _mtx_lock_flags+0x9c ufs_ihashget() at ufs_ihashget+0x94 ffs_vget() at ffs_vget+0x20 ufs_lookup() at ufs_lookup+0xb2c ufs_vnoperate() at ufs_vnoperate+0x1c vfs_cache_lookup() at vfs_cache_lookup+0x330 ufs_vnoperate() at ufs_vnoperate+0x1c lookup() at lookup+0x408 namei() at namei+0x254 vn_open_cred() at vn_open_cred+0x208 vn_open() at vn_open+0x18 kern_open() at kern_open+0x84 open() at open+0x14 syscall() at syscall+0x308 -- syscall (5, FreeBSD ELF64, open) %o7=0x4038c2b0 -- userland() at 0x40395948 user trace: trap %o7=0x4038c2b0 pc 0x40395948, sp 0x7fddaf1 pc 0x4038b47c, sp 0x7fddc31 pc 0x101778, sp 0x7fddcf1 pc 0x101378, sp 0x7fdddb1 pc 0x100f80, sp 0x7fdde71 pc 0x4020a234, sp 0x7fddf31 done pgp0.pgp Description: PGP signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
For a *lot* of people today (like home users), an up-to-date FreeBSD CD or floppy or a second machine to create the disk on may not be handy (and forget about NFS), but a network connection may still be available. That network connection would most likely be a M$-Win box in that case, which doesn't have an FTP server. Samba, not an FTP client should be in /rescue then. # ftp ftp.freebsd.org get blah/blah/blah/release/bin.tgz # tar xzvf seems like a damn easy fix for killing /bin and /sbin i like the idea of having a tiny (re: non-ssl) fetch availble for when i shoot myself in the foot. would be incredibly helpful. And while in my current configurations, live cd or NFS are also options, sometimes fetch is going to be faster, and if it's a production machine, time is money. In a perfect world, I'd never hose a production machine, but... ~j ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] = Yesterday upon the stair I saw a man who wasn't there, he wasn't there again today, oh how i wish he'd go away Rev. Jonathan T. Sage - Lighting / Set Designer [HTTP://www.wisefreebsd.org] [HTTP://jonsage.wisefreebsd.org] [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PII SMP system hangs during boot with ACPI enabled
On 24-Nov-2003 Nate Lawson wrote: Please also send the output of acpidump -t -d jdp-P2.asl When I try to run that command, I get: acpidump: sysctl machdep.acpi_root does not point to RSDP The sysctl command shows that machdep.acpi_root is 0. Remember, though, in order to boot it I had to disable ACPI in /boot/loader.conf. If you can break to the debugger after it has hung, a tr would be nice. The fact that it didn't occur to me to try that says a lot about how long I've been away from -current. :-( I've attached traces from two different boots. They seem to vary somewhat. I can supply line numbers on request. John db trace siointr1(c298d000,0,c06c9bb7,6a0,cdb64a04) at siointr1+0xec siointr(c298d000,c06a7546,c070bf40,c2944100,4) at siointr+0x35 intr_execute_handlers(c129f88c,cdb64a1c,cdb64a64,c065ca63,34) at intr_execute_ha ndlers+0xc8 lapic_handle_intr(34) at lapic_handle_intr+0x3a Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc053b9a4, esp = 0xcdb64a60, ebp = 0xcdb64a64 --- wakeup(c2944100,0,c06a7546,140,6c) at wakeup+0x4 AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xa8 AcpiUtReleaseMutex(9,30,c295e8c0,c295e760,cdb64acc) at AcpiUtReleaseMutex+0x8c AcpiUtReleaseToCache(3,c295e760,cdb64ad8,c045ac17,c295e760) at AcpiUtReleaseToCa che+0x8c AcpiPsFreeOp(c295e760,cdb64afc,c045ab37,c12a0800,0) at AcpiPsFreeOp+0x30 AcpiPsDeleteCompletedOp(c12a0800,0,c12a0800,c295e7c0,c12a0800) at AcpiPsDeleteCo mpletedOp+0x17 AcpiPsGetNextWalkOp(c12a0800,c295e760,c045ac00,c2967080,c295e8c0) at AcpiPsGetNe xtWalkOp+0x77 AcpiPsDeleteParseTree(c295e8c0,c12a0c00,c12a0de4,0,cdb64bf4) at AcpiPsDeletePars eTree+0x9a AcpiPsCompleteThisOp(c12a0c00,c295e8c0,0,c12a0c10,150) at AcpiPsCompleteThisOp+0 x1b8 AcpiPsParseLoop(c12a0c00,c2967340,cdb64c14,c12a0c00,c12a0de4) at AcpiPsParseLoop +0x6c8 AcpiPsParseAml(c12a0c00,c2967380,c295ca80,ce5b5ac0,d) at AcpiPsParseAml+0x7c AcpiPsxExecute(c295ca80,0,cdb64c9c,c295ca80,0) at AcpiPsxExecute+0x202 AcpiNsExecuteControlMethod(c295ca80,0,cdb64c9c,c2944180,c294dedc) at AcpiNsExecu teControlMethod+0x5f AcpiNsEvaluateByHandle(c295ca80,0,0,76,c295ca80) at AcpiNsEvaluateByHandle+0x96 AcpiEvAsynchExecuteGpeMethod(c294dedc,0,c06a7461,7b,0) at AcpiEvAsynchExecuteGpe Method+0x8c acpi_task_thread(0,cdb64d48,c06b7385,311,5f616964) at acpi_task_thread+0x105 fork_exit(c0474e20,0,cdb64d48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcdb64d7c, ebp = 0 --- db c ~Stopped at siointr1+0xec: jmp siointr1+0x220 db show all procs pid proc uarea uid ppid pgrp flag stat wmesgwchan cmd 48 c299a8d4 d26330000 0 0 204 [IWAIT] swi0: tty:sio 47 c28f0a98 ce57a0000 0 0 204 new [RUNQ] usbtask 46 c28f0c5c ce57b0000 0 0 204 new [RUNQ] usb0 8 c28f0e20 ce57c0000 0 0 204 new [RUNQ] acpi_task2 7 c2935000 ce57d0000 0 0 204 new [RUNQ] acpi_task1 6 c29351c4 ce57e0000 0 0 204 [CPU 0] acpi_task0 45 c2935388 ce57f0000 0 0 204 [IWAIT] swi7: acpitaskq 44 c293554c ce580 0 0 204 new [IWAIT] swi3: cambio 43 c2935710 ce5810000 0 0 204 new [IWAIT] swi2: camnet 42 c29358d4 ce5820000 0 0 204 new [IWAIT] swi5:+ 5 c2935a98 ce5830000 0 0 204 [SLP]tqthr 0xc070f268] taskqueu e 41 c2935c5c ce5a80000 0 0 204 new [IWAIT] swi6:+ 40 c2935e20 ce5a90000 0 0 204 [IWAIT] swi7: task queue 39 c2937000 ce5aa0000 0 0 204 [RUNQ] random 4 c28e154c ce54a0000 0 0 204 [RUNQ] g_down 3 c28e1710 ce54b0000 0 0 204 [RUNQ] g_up 2 c28e18d4 ce54c0000 0 0 204 [RUNQ] g_event 38 c28e1a98 ce54d0000 0 0 204 new [IWAIT] swi4: vm 37 c28e1c5c ce54e0000 0 0 20c [IWAIT] swi8: tty:sio clock 36 c28e1e20 ce54f0000 0 0 204 new [IWAIT] swi1: net 35 c28f ce550 0 0 204 new [IWAIT] irq9: 34 c28f01c4 ce5750000 0 0 204 new [IWAIT] irq0: clk 33 c28f0388 ce5760000 0 0 204 new [IWAIT] irq23: 32 c28f054c ce5770000 0 0 204 new [IWAIT] irq22: 31 c28f0710 ce5780000 0 0 204 new [IWAIT] irq21: 30 c28f08d4 ce5790000 0 0 204 [RUNQ] irq20: acpi0 29 c12ae1c4 cdb490000 0 0 204 new [IWAIT] irq19: fxp0 uhci0 28 c12ae388 cdb4a0000 0 0 204 new [IWAIT] irq18: 27 c12ae54c cdb4b0000 0 0 204 new [IWAIT] irq17: fxp1 26 c12ae710 cdb4c0000 0 0 204 new [IWAIT] irq16: ahc0 ahc1 25 c12ae8d4 cdb710000 0 0 204 new [IWAIT] irq15: ata1 24 c12aea98 cdb720000 0 0 204 [IWAIT] irq14: ata0 23 c12aec5c cdb730000 0 0 204 new [IWAIT] irq13: 22 c12aee20 cdb740000 0 0 204 new
Re: HEADS UP: /bin and /sbin are now dynamically linked
* Garance A Drosihn [EMAIL PROTECTED] [031124 14:11]: I doubt there is any perfect answer which will satisfy everyone, but perhaps we can recognize that and figure out some flexible middle ground. Would it be possible, through some make.conf magic, for the end-user to set extra programs to be put into /rescue that are not typically there? RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch ?? --Mike pgp0.pgp Description: PGP signature
Re: PII SMP system hangs during boot with ACPI enabled
On 24-Nov-2003 Nate Lawson wrote: It's a long shot, but what about setting kern.timecounter.hardware to i8254. It appears your ACPI timer is bad. The reason why I suggest this is that it seems like interrupts are being lost. I put kern.timecounter.hardware=i8254 into /boot/loader.conf, but it didn't make any difference. Are you sure it even works from loader.conf? From the sources it looks like this is a sysctl rather than a tunable. I could change it to a tunable, though, if you think it's worthwhile. John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR filedesc structure / Giant
On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote: This is with a current from around two days ago, with a kernel not much different from GENERIC. Known problem. Kris pgp0.pgp Description: PGP signature
Re: PII SMP system hangs during boot with ACPI enabled
In message [EMAIL PROTECTED], John Polstra writes: On 24-Nov-2003 Nate Lawson wrote: It's a long shot, but what about setting kern.timecounter.hardware to i8254. It appears your ACPI timer is bad. The reason why I suggest this is that it seems like interrupts are being lost. I put kern.timecounter.hardware=i8254 into /boot/loader.conf, but it didn't make any difference. Are you sure it even works from loader.conf? From the sources it looks like this is a sysctl rather than a tunable. I could change it to a tunable, though, if you think it's worthwhile. It would be rather complicated to make it a tunable. Far easier to go into the ACPI timecounter and just give it a negative quality, that will disable it. I'm not sure why Nate think this will change anything with respect to interrupts, but I pressume he knows what he's talking about. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
USB 1.0 IDE to ATAPI drive enclosure failure
Howdy list, I'm running FreeBSD 5.1-RELEASE. I just bought a generic USB 1.1/2.0/firewire external drive enclosure for my 32gb Travelstar 2.0 12.5mm hard drive. The device shows up like this: Nov 18 14:06:16 trevarthan kernel: umass0: Acer Labs USB 2.0 Storage Device, rev 2.00/1.03, addr 3 Nov 18 14:06:16 trevarthan kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Nov 18 14:06:17 trevarthan kernel: da0: USB 2.0 Storage Device 0100 Fixed Direct Access SCSI-0 device Nov 18 14:06:17 trevarthan kernel: da0: 1.000MB/s transfers Nov 18 14:06:17 trevarthan kernel: da0: 30520MB (62506080 512 byte sectors: 255H 63S/T 3890C) But `ls -al /dev/da*` reveals no slices: crw-r- 1 root operator4, 22 Nov 18 13:35 /dev/da0 The hard disk inside this enclosure was formatted with a 10gig FAT32 partition. It works fine in a Coolmax Gemini 2.5 USB 2.0/1.1 drive enclosure (which shows up as IDE-ATA under Windows XP), and it works fine in this enclosure as long as I'm running Windows XP (but it shows up differently than the Gemini under XP: IDE-ATAPI). It just doesn't work under FreeBSD 5.1-RELEASE or FreeBSD 4.8-RELEASE for some reason... I've found the following links relating to similar problems: http://lists.freebsd.org/pipermail/freebsd-current/2003-August/008504.html http://lists.freebsd.org/pipermail/freebsd-hardware/2003-July/000393.html But no solutions. Has the USB code been updated since FreeBSD 5.1-RELEASE? Is there a chance it will work if I cvsup to -CURRENT? I contacted the gentleman from the first link above, and he said that the only thing different about his configuration (other than hardware) is that: 1.) He connects through a USB hub 2.) He runs -CURRENT from Nov 7th I can't seem get my hands on a USB hub, so it looks like my only option is -CURRENT. Does anyone have any clues to help get this drive working? I'm all for debugging of any kind, including coding. I'm just not sure where to start. Thanks! -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PII SMP system hangs during boot with ACPI enabled
On Mon, 24 Nov 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], John Polstra writes: On 24-Nov-2003 Nate Lawson wrote: It's a long shot, but what about setting kern.timecounter.hardware to i8254. It appears your ACPI timer is bad. The reason why I suggest this is that it seems like interrupts are being lost. I put kern.timecounter.hardware=i8254 into /boot/loader.conf, but it didn't make any difference. Are you sure it even works from loader.conf? From the sources it looks like this is a sysctl rather than a tunable. I could change it to a tunable, though, if you think it's worthwhile. It would be rather complicated to make it a tunable. Far easier to go into the ACPI timecounter and just give it a negative quality, that will disable it. I'm not sure why Nate think this will change anything with respect to interrupts, but I pressume he knows what he's talking about. Some ACPI timecounters on old systems would hang on a read from the register and so moving to i8254 would help if it was being used. But farther down, I see that he was already using TSC so it won't make a difference. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR filedesc structure / Giant
Am 24.11.2003 um 22:19 schrieb Kris Kennaway: On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote: This is with a current from around two days ago, with a kernel not much different from GENERIC. Known problem. I do follow -current quite closely, but none of the cvs lists. It appears that I missed some important info. What should I monitor more closely? What can I do to analyze this more closely? Thanks, Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR filedesc structure / Giant
On Mon, Nov 24, 2003 at 10:52:54PM +0100, Stefan Bethke wrote: Am 24.11.2003 um 22:19 schrieb Kris Kennaway: On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote: This is with a current from around two days ago, with a kernel not much different from GENERIC. Known problem. I do follow -current quite closely, but none of the cvs lists. It appears that I missed some important info. What should I monitor more closely? What can I do to analyze this more closely? First checking the mailing list archives and PR database for similar problem reports is often prudent. This one has been reported for several months, and I also submitted a PR about it. Kris pgp0.pgp Description: PGP signature
Re: USB 1.0 IDE to ATAPI drive enclosure failure
On Mon, Nov 24, 2003 at 04:44:02PM -0500, Jesse Guardiani wrote: I'm running FreeBSD 5.1-RELEASE. I just bought a generic USB 1.1/2.0/firewire external drive enclosure for my 32gb Travelstar 2.0 12.5mm hard drive. The device shows up like this: Nov 18 14:06:16 trevarthan kernel: umass0: Acer Labs USB 2.0 Storage Device, rev 2.00/1.03, addr 3 Nov 18 14:06:16 trevarthan kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Nov 18 14:06:17 trevarthan kernel: da0: USB 2.0 Storage Device 0100 Fixed Direct Access SCSI-0 device Nov 18 14:06:17 trevarthan kernel: da0: 1.000MB/s transfers Nov 18 14:06:17 trevarthan kernel: da0: 30520MB (62506080 512 byte sectors: 255H 63S/T 3890C) But `ls -al /dev/da*` reveals no slices: If you're using an ohci usb controller, perhaps you need a patch. Browse the -current archives for the last week or so. Why hasn't anything been committed? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PII SMP system hangs during boot with ACPI enabled
On Mon, 24 Nov 2003, John Polstra wrote:
On 24-Nov-2003 Nate Lawson wrote:
Please also send the output of acpidump -t -d jdp-P2.asl
When I try to run that command, I get:
acpidump: sysctl machdep.acpi_root does not point to RSDP
The sysctl command shows that machdep.acpi_root is 0.
Remember, though, in order to boot it I had to disable ACPI in
/boot/loader.conf.
Yes, I see. You could use an older kernel like the 5.1R cd.
If you can break to the debugger after it has hung, a tr would be nice.
The fact that it didn't occur to me to try that says a lot about how
long I've been away from -current. :-( I've attached traces from
two different boots. They seem to vary somewhat. I can supply line
numbers on request.
Trace 1:
wakeup(c2944100,0,c06a7546,140,6c) at wakeup+0x4
AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xa8
AcpiUtReleaseMutex(9,30,c295e8c0,c295e760,cdb64acc) at AcpiUtReleaseMutex+0x8c
AcpiUtReleaseToCache(3,c295e760,cdb64ad8,c045ac17,c295e760) at
AcpiUtReleaseToCache+0x8c
Trace 2:
_mtx_unlock_flags(c2944100,0,c06a7546,150,6c) at _mtx_unlock_flags+0x96
AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xc8
AcpiUtReleaseMutex(9,8,c045f9cc,c2965940,c12a0c00) at AcpiUtReleaseMutex+0x8c
AcpiUtAcquireFromCache(2,cdb64bf4,c0462229,c12a0c00,cdb64c34) at
AcpiUtAcquireFromCache+0x53
Both of these show that acpi_task_thread is calling a task and then
AcpiOsSignalSemaphore is hanging. I'm wondering if your system can't
handle the acpi interrupt being moved to irq 20. Please try this
(untested) patch that should disable moving the SCI to irq 20. jhb can
probably address this better than I.
-Nate
Index: /sys/i386/acpica/madt.c
===
RCS file: /home/ncvs/src/sys/i386/acpica/madt.c,v
retrieving revision 1.7
diff -u -r1.7 madt.c
--- /sys/i386/acpica/madt.c 14 Nov 2003 22:26:29 - 1.7
+++ /sys/i386/acpica/madt.c 24 Nov 2003 21:51:02 -
@@ -538,11 +538,13 @@
}
if (intr-Source != intr-GlobalSystemInterrupt) {
+#if 0
/* XXX: This assumes that the SCI uses IRQ 9. */
if (intr-GlobalSystemInterrupt 15 intr-Source == 9)
acpi_OverrideInterruptLevel(
intr-GlobalSystemInterrupt);
else
+#endif
ioapic_remap_vector(new_ioapic, new_pin, intr-Source);
if (madt_find_interrupt(intr-Source, old_ioapic,
old_pin) != 0)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB 1.0 IDE to ATAPI drive enclosure failure
Barney Wolff wrote: On Mon, Nov 24, 2003 at 04:44:02PM -0500, Jesse Guardiani wrote: I'm running FreeBSD 5.1-RELEASE. I just bought a generic USB 1.1/2.0/firewire external drive enclosure for my 32gb Travelstar 2.0 12.5mm hard drive. The device shows up like this: Nov 18 14:06:16 trevarthan kernel: umass0: Acer Labs USB 2.0 Storage Device, rev 2.00/1.03, addr 3 Nov 18 14:06:16 trevarthan kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Nov 18 14:06:17 trevarthan kernel: da0: USB 2.0 Storage Device 0100 Fixed Direct Access SCSI-0 device Nov 18 14:06:17 trevarthan kernel: da0: 1.000MB/s transfers Nov 18 14:06:17 trevarthan kernel: da0: 30520MB (62506080 512 byte sectors: 255H 63S/T 3890C) But `ls -al /dev/da*` reveals no slices: If you're using an ohci usb controller, perhaps you need a patch. Browse the -current archives for the last week or so. Sorry, I didn't realize that might be important. Pretty sure it's UHCI: [17:[EMAIL PROTECTED]:[~]% usbdevs addr 1: UHCI root hub, Intel addr 1: UHCI root hub, Intel addr 2: USB Receiver, Logitech addr 1: UHCI root hub, Intel And from dmesg.boot: uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0x1800-0x181f irq 9 at device 29.0 on pci0 usb0: Intel 82801CA/CAM (ICH3) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801CA/CAM (ICH3) USB controller USB-B port 0x1820-0x183f irq 11 at device 29.1 on pci0 usb1: Intel 82801CA/CAM (ICH3) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801CA/CAM (ICH3) USB controller USB-C port 0x1840-0x185f irq 9 at device 29.2 on pci0 usb2: Intel 82801CA/CAM (ICH3) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PII SMP system hangs during boot with ACPI enabled
On 24-Nov-2003 Nate Lawson wrote: On Mon, 24 Nov 2003, John Polstra wrote: On 24-Nov-2003 Nate Lawson wrote: Please also send the output of acpidump -t -d jdp-P2.asl When I try to run that command, I get: acpidump: sysctl machdep.acpi_root does not point to RSDP The sysctl command shows that machdep.acpi_root is 0. Remember, though, in order to boot it I had to disable ACPI in /boot/loader.conf. Yes, I see. You could use an older kernel like the 5.1R cd. I'll try that, and send you the dump if I can get one. Both of these show that acpi_task_thread is calling a task and then AcpiOsSignalSemaphore is hanging. I'm wondering if your system can't handle the acpi interrupt being moved to irq 20. Please try this (untested) patch that should disable moving the SCI to irq 20. jhb can probably address this better than I. I tried your patch, but it didn't change the behavior any. John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PII SMP system hangs during boot with ACPI enabled
On 24-Nov-2003 Nate Lawson wrote: Trace 1: wakeup(c2944100,0,c06a7546,140,6c) at wakeup+0x4 AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xa8 AcpiUtReleaseMutex(9,30,c295e8c0,c295e760,cdb64acc) at AcpiUtReleaseMutex+0x8c AcpiUtReleaseToCache(3,c295e760,cdb64ad8,c045ac17,c295e760) at AcpiUtReleaseToCache+0x8c Trace 2: _mtx_unlock_flags(c2944100,0,c06a7546,150,6c) at _mtx_unlock_flags+0x96 AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xc8 AcpiUtReleaseMutex(9,8,c045f9cc,c2965940,c12a0c00) at AcpiUtReleaseMutex+0x8c AcpiUtAcquireFromCache(2,cdb64bf4,c0462229,c12a0c00,cdb64c34) at AcpiUtAcquireFromCache+0x53 Both of these show that acpi_task_thread is calling a task and then AcpiOsSignalSemaphore is hanging. I'm wondering if your system can't handle the acpi interrupt being moved to irq 20. Please try this (untested) patch that should disable moving the SCI to irq 20. As I mentioned a minute ago, the patch didn't help. But I grabbed another stack trace while I was at it. This one is quite different from the others. I don't think it's different because of your patch, though. I saw one like this earlier, but thought it might have been an anomaly caused by my own mucking around in DDB. siointr1(c298d000,0,c06c9b97,6a0,cdb5ec70) at siointr1+0xec siointr(c298d000,c053a016,c06d88a0,c06e7ae0,4) at siointr+0x35 intr_execute_handlers(c129f88c,cdb5ec88,cdb5eccc,c065ca43,34) at intr_execute_handlers+0xc8 lapic_handle_intr(34) at lapic_handle_intr+0x3a Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc053a4ea, esp = 0xcdb5eccc, ebp = 0xcdb5eccc --- critical_exit(c070af20,1,c06b8c37,14b,0) at critical_exit+0x2a _mtx_unlock_spin_flags(c070af20,0,c06b74f7,23a,c294954c) at _mtx_unlock_spin_flags+0x9d ithread_loop(c12a6800,cdb5ed48,c06b7365,311,0) at ithread_loop+0x26e fork_exit(c0520150,c12a6800,cdb5ed48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcdb5ed7c, ebp = 0 --- John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR filedesc structure / Giant
Am 24.11.2003 um 22:56 schrieb Kris Kennaway: On Mon, Nov 24, 2003 at 10:52:54PM +0100, Stefan Bethke wrote: Am 24.11.2003 um 22:19 schrieb Kris Kennaway: On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote: This is with a current from around two days ago, with a kernel not much different from GENERIC. Known problem. I do follow -current quite closely, but none of the cvs lists. It appears that I missed some important info. What should I monitor more closely? What can I do to analyze this more closely? First checking the mailing list archives and PR database for similar problem reports is often prudent. This one has been reported for several months, and I also submitted a PR about it. Sorry for banging on about this, but the PR kern/55175 does not appear to contain much more information than I submitted. If the problem is indeed well known, and deemed a freak accident that won't do any damage, then I apologise for wasting your time. This caused a panic on one of my systems, and the panic hosed the root filesystem. As I'm planning to put two identical systems into production at 5.2 release, or hopefully at 5-stable (depending on timeframe), I would much prefer to have confidence in the stability of the system, and this isn't it. The machine has been running current for the past 4 months, with the occasional make world and portupgrade -f, to make sure that it is stable enough for low-level production work ( 10k hits on apache, 10k emails, some ssh sessions per day). (Running setiathome to test the cpu.) The LOR appears to occur consistently on this machine; I am not sure I can force it to occur at the same sequence of events, but in five of five tries, trying to re-compile ports, it occurs during the compile. If this situation is interesting to anyone, I can easily arrange shell and console access; usually I or a colleague will be available to push buttons if neccessary. If anyone feels I can perform any tests to shed further light on this, please let me know. Thanks, Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
In message: [EMAIL PROTECTED] Stefan Farfeleder [EMAIL PROTECTED] writes: : On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote: : From: Jacques A. Vidrine [EMAIL PROTECTED] : The application is broken. You must only check errno if you get an : error indication from the library call. : : errno is only meaningful after a syscall error. : : Wrong, counter-example: strtol(). errno is meaningful for syscalls after an error (the original message). The fact that other functions also dink with errno is not relevant to that statement. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB 1.0 IDE to ATAPI drive enclosure failure
In message: [EMAIL PROTECTED] Barney Wolff [EMAIL PROTECTED] writes: : Why hasn't anything been committed? Code freeze? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Mon, Nov 24, 2003 at 12:08:58PM -0800, Tim Kientzle wrote: Contrary to what David claims, I don't think /rescue does need to support all of the recovery actions that a static /s?bin would support. Rather, I think it only needs to support those recovery actions necessary to repair /bin and /sbin if they break. No, you're missing my stance. My stance is that no failure mode needs to be repairable that wasn't repairable with a static /. With a static / last month, if I needed to get a file onto the machine, I had to use a floppy, CDROM, or mount another file system (NFS counts in this). The argument flowing in this thread is about adding additional ways to repair a trashed machine. Those of us that agreed to the /rescue bloat didn't agree to that. We agreed to the claim that /rescue would hold those bits needed to repair a trashed system in the SAME ways one did with a static /. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Mon, Nov 24, 2003 at 04:07:49PM -0500, Michael Edenfield wrote: I doubt there is any perfect answer which will satisfy everyone, but perhaps we can recognize that and figure out some flexible middle ground. Would it be possible, through some make.conf magic, for the end-user to set extra programs to be put into /rescue that are not typically there? RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch This list could easily need things added to librescue. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB 1.0 IDE to ATAPI drive enclosure failure
This is interesting: [17:[EMAIL PROTECTED]:[~]# camcontrol devlist USB 2.0 Storage Device 0100 at scbus1 target 0 lun 0 (da0,pass0) [17:[EMAIL PROTECTED]:[~]# camcontrol inquiry 1:0:0 pass0: USB 2.0 Storage Device 0100 Fixed Direct Access SCSI-0 device pass0: Serial Number pass0: 1.000MB/s transfers So it looks like it's just not recognizing the file system on da0. Perhaps I should try `camcontrol format`? It would probably take for ever to format a 32Gb disk over a 1M link, but I could leave it on over night... I originally formatted this disk by putting it in my primary drive sled in my laptop and running a partitioning program... -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Mon, Nov 24, 2003 at 03:33:49PM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Stefan Farfeleder [EMAIL PROTECTED] writes: : On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote: : From: Jacques A. Vidrine [EMAIL PROTECTED] : The application is broken. You must only check errno if you get an : error indication from the library call. : : errno is only meaningful after a syscall error. : : Wrong, counter-example: strtol(). errno is meaningful for syscalls after an error (the original message). The fact that other functions also dink with errno is not relevant to that statement. I read boyd's statement as a contradiction to Jacques' one (only after syscall error vs. after library call error). If that's a misinterpretation, I'm sorry. Stefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB 1.0 IDE to ATAPI drive enclosure failure
On Mon, Nov 24, 2003 at 03:35:42PM -0700, M. Warner Losh wrote: : Why hasn't anything been committed? Code freeze? I understand the concept, but I haven't seen any reports of people claiming that OHCI works for other than mice/keyboards without the following patch (from Brian F. Feldman [EMAIL PROTECTED]): --- ohci.c 12 Nov 2003 01:40:11 - 1.138 +++ ohci.c 22 Nov 2003 03:28:42 - @@ -569,7 +569,7 @@ cur-td.td_cbp = htole32(dataphys); cur-nexttd = next; cur-td.td_nexttd = htole32(next-physaddr); - cur-td.td_be = htole32(DMAADDR(dma, curlen - 1)); + cur-td.td_be = htole32(DMAADDR(dma, offset + curlen - 1)); cur-len = curlen; cur-flags = OHCI_ADD_LEN; cur-xfer = xfer; It cured my problems with a Sony DSC F707. Maybe most people with OHCI controllers haven't had problems, but if so they've been quietly satisfied. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
So.. forking a dynamic sh is roughly 40% more expensive than forking a static copy of sh. This is embarrassing. read the original paper carefully: http://citeseer.nj.nec.com/cache/papers/cs/3066/http:zSzzSzswt-www.informatik.uni-hamburg.dezSz~1friedrizSzsvzSzreferenceszSzShared_Libraries_In_Sun_OS.pdf/gingell87shared.pdf it's conclusions state that they are slower. this was the _original paper_ that announced the damn things. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl0: watchdog timeout
Matt Smith wrote: Matt Smith wrote: Jimmy Selgen wrote: On Fri, 2003-11-21 at 21:29, Kris Kennaway wrote: On Fri, Nov 21, 2003 at 09:22:49PM +0100, Jimmy Selgen wrote: I saw this with some of sam's locking changes that (temporarily) broke DUMMYNET. I see you're using ipfilter - it's possible that this configuration has not been well-tested. Are you passing much traffic through ipfilter on this box? The box in question is my workstation, so I guess i'm not passing that much traffic through ipfilter. Also, when I said that the NIC still worked, I might have mislead you a bit. I had about 5-10 timeouts while scp'ing the dmesg output to my other workstation. Data seems to move from userland to the kernel, then get stuck in buffers there for 10-15 seconds, generating timeouts, before they're shipped off. I assume this is expected behaviour when a NIC isnt behaving correctly. It would be helpful if you can do a binary search to narrow down when the problem started. What would you have me search ? I'm a faily seasoned C programmer (12 years experience, some of them doing RTOS kernel work), but dont know much about FreeBSD kernel development, or the process of checking out different kernel revisions. I've tried a build without IPFILTER, and the problem still exists. I've also tried booting with ACPI disabled, and the problem is still there. I have attached a copy of my kernel config file, in case i'm doing something wrong. snip kernel file I have just noticed that my xl0 card is misbehaving as well. I have a 3c905c in my desktop and noticed that an ftp of a file from another machine on the lan (100 meg switched) was only going at around 70KB/sec. Normally I get around 9MB/sec. A netstat -bi xl0 shows lots of errors: NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 Link#1 00:04:76:8d:c5:fd 3081878 217616 3778632119 2451968 6 368229701 0 I also have this in my messages file: xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 240 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 300 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 360 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 420 bytes I do not currently have any debugging options compiled into this kernel. FreeBSD fraggle.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Nov 18 20:05:52 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRAGGLE i386 I am actually in the process of building a new world/kernel to update it again as I thought it might be something that's fixed. I unfortunatly can not boot the old kernel to see if it works fine in that because of the statfs changes so it *could* possibly be the NIC has gone funny. I also have a 3c905a and a 3c905b in my router machine and this is showing no issues at all with the same dated kernel. http://xtaz.net/ Matt. I am now running a 5.2-BETA kernel from today and still have the problem with my xl0 card here. I can only get a max throughput of around 110KB/sec through it. And I am getting huge amounts of errors in the interface stats (5 minutes after booting): NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 Link#1 00:04:76:8d:c5:fd 217042 1290 57669634 309460 0 208178476 0 So the question is, is this my network card has died and I need to throw it out or is it related to Jimmy Selgen's email about the watchdog timeouts? It's a shame I can't boot an old kernel to test really. Matt. I have done some testing on this. I've changed the network cable, switch port etc. No affect. I've found though that if I ftp this box and GET a file it goes at around 6MB/sec. But if I PUT a file it goes at 100KB/sec. Previously this has worked at around 9-10MB/sec both ways. I can't place a date on it though because I've not tried to do large file transfers for a long time and only just noticed it this week. So it looks like it is driver related I guess. The buffer scenario Jimmy reported looks likely. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to fix this in 5.1-REL??
Date: Sat, 22 Nov 2003 06:07:03 -0800 From: Kris Kennaway [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] --nVMJ2NtxeReIH9PS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Nov 22, 2003 at 03:16:06PM +0300, Odhiambo Washington wrote: I end up with the following when I run `make world` on 5.1-RELEASE-p10. Did you read UPDATING? I fear a bikeshed, but I really think it may be past time to remove the 'world' target from /usr/src/Makefile.inc1. It is rarely useful and only should be used by those who understand the process and know that it is safe. Removing it would remove a clear way to shoot one's foot and would really have trivial impact on those who use it properly. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS lockup issues and xl0 watchdog timeout
I've had a possible idea regarding the NFS issues. I'm wondering if perhaps my NFS issues are related to the other email thread I have going which is the xl0: watchdog timeouts etc. I had not noticed this until last week because it's not often I copy large files from one machine to another but doing an ftp/scp etc from one machine to the other I'm only getting 100KB/sec with a PUT from my nfsclient-nfsserver, and 6MB/sec with a GET. This used to go at 9-10MB/sec both ways. Thinking about it I think this started happening around the same time I started having NFS issues. My NFS issues are also only when writing to the server from the client, never the other way around. So this ties up with the throughput figure difference I get on FTP. Jimmy mentioned a watchdog timeout caused by what looked like a 10-15 second delay in a buffer going from userland to kernel? I guess if this is the case it could kill NFS as well. Tomorrow night I will change my xl0 card in this desktop for a spare realtek card I happen to have and test throughput and NFS. I'll let you know my results. It would be interesting to see if the other person who reported these NFS issues (soren) has a similar experience. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
David O'Brien wrote: On Mon, Nov 24, 2003 at 12:08:58PM -0800, Tim Kientzle wrote: ... I think [/rescue] only needs to support those recovery actions necessary to repair /bin and /sbin if they break. My stance is that no failure mode needs to be repairable that wasn't repairable with a static /. I'm willing to compromise, David. Here's what I suggest: * I could support removing vi/ex from /rescue. * In exchange for this concession, would you be willing to support adding fetch? I expect this exchange would result in a net 150-200 kB savings in /rescue. How about it? Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PII SMP system hangs during boot with ACPI enabled
On Mon, 24 Nov 2003, John Polstra wrote: On 24-Nov-2003 Nate Lawson wrote: Trace 1: wakeup(c2944100,0,c06a7546,140,6c) at wakeup+0x4 AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xa8 AcpiUtReleaseMutex(9,30,c295e8c0,c295e760,cdb64acc) at AcpiUtReleaseMutex+0x8c AcpiUtReleaseToCache(3,c295e760,cdb64ad8,c045ac17,c295e760) at AcpiUtReleaseToCache+0x8c Trace 2: _mtx_unlock_flags(c2944100,0,c06a7546,150,6c) at _mtx_unlock_flags+0x96 AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xc8 AcpiUtReleaseMutex(9,8,c045f9cc,c2965940,c12a0c00) at AcpiUtReleaseMutex+0x8c AcpiUtAcquireFromCache(2,cdb64bf4,c0462229,c12a0c00,cdb64c34) at AcpiUtAcquireFromCache+0x53 Both of these show that acpi_task_thread is calling a task and then AcpiOsSignalSemaphore is hanging. I'm wondering if your system can't handle the acpi interrupt being moved to irq 20. Please try this (untested) patch that should disable moving the SCI to irq 20. As I mentioned a minute ago, the patch didn't help. But I grabbed another stack trace while I was at it. This one is quite different from the others. I don't think it's different because of your patch, though. I saw one like this earlier, but thought it might have been an anomaly caused by my own mucking around in DDB. siointr1(c298d000,0,c06c9b97,6a0,cdb5ec70) at siointr1+0xec siointr(c298d000,c053a016,c06d88a0,c06e7ae0,4) at siointr+0x35 intr_execute_handlers(c129f88c,cdb5ec88,cdb5eccc,c065ca43,34) at intr_execute_handlers+0xc8 lapic_handle_intr(34) at lapic_handle_intr+0x3a Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc053a4ea, esp = 0xcdb5eccc, ebp = 0xcdb5eccc --- critical_exit(c070af20,1,c06b8c37,14b,0) at critical_exit+0x2a _mtx_unlock_spin_flags(c070af20,0,c06b74f7,23a,c294954c) at _mtx_unlock_spin_flags+0x9d ithread_loop(c12a6800,cdb5ed48,c06b7365,311,0) at ithread_loop+0x26e fork_exit(c0520150,c12a6800,cdb5ed48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcdb5ed7c, ebp = 0 --- Someone more familiar with ithread_loop should probably answer this. One workaround might be to enable ACPI_NO_SEMAPHORES on your box. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
On Tuesday 25 November 2003 06:45, Andrew Gallatin wrote: So.. forking a dynamic sh is roughly 40% more expensive than forking a static copy of sh. This is embarrassing. I propose that we at least make /bin/sh static. (and not add a /sbin/sh; if we must have a dynamic sh, import pdksh, or put a dynamically linked sh in /usr/bin/sh). I'd greatly prefer that the the dynamic root default be backed out until a substantial amount of this performance can be recovered. What _REAL WORLD_ task does this slow down? My production systems don't spin in infinite loops spawning shell processes which die straight away. If yours do, well.. curious, but I hardly think it is of relevance to most users of FreeBSD. If it is for you then just build your world with static root. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
At 3:15 PM -0500 11/24/03, Andrew Gallatin wrote: Here is a simple test which times the execution of a null shell script. It basically times fork/exec of the chosen shell. So.. forking a dynamic sh is roughly 40% more expensive than forking a static copy of sh. This is embarrassing. To be more precise: shell scripts which do-nothing will be 40% more expensive than they used to be. It is not like the entire operating system will get 40% slower. I propose that we at least make /bin/sh static. I suggest that we leave all of /bin and /sbin as it is for 5.2-release. We are still telling users that 5.2 is a snapshot of -current, and it is more valuable to have a wider range of experience with this worst-case scenario. (worst-case == all files dynamically linked). We certainly may want to make changes to address the performance issues that you note, but there is no reason we must decide *which* change should be made right now. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
Daniel O'Connor wrote: What _REAL WORLD_ task does this slow down? I think the point was that, in this particular worst case, it's a forty percent performance hit. What's the average case? What's the case for a real world pipeline with a lot of tiny little static binaries? I dislike this decision enough that I'm actually considering going away from FreeBSD, something I really had never for a moment thought possible. It's even worse that you deride someone who tried to shed a little light on the discussion. The performance hit is real. Even if it's not forty percent it's worth consideration, no matter how much you may want to shout down those who disagree. My production systems don't spin in infinite loops spawning shell processes which die straight away. Uh, _huh_. Well, can you _imagine_ a scenario in which a production system might actually do something along those lines? _I_ can. Think a system of shell scripts. If yours do, well.. curious, but I hardly think it is of relevance to most users of FreeBSD. I can guarantee you that you have no idea _at all_ what is of relevance to most users of FreeBSD. It is nearly axiomatic that developers cannot imagine the uses to which their users put their systems. If it is for you then just build your world with static root. Kind of defeats the purpose, don't you think? Feh. This is utterly ridiculous. Yeah, I understand why you guys made the decision. It's the same set of reasons a lot of other people in the past have made the same or similar decisions. We'll see if you get burned by it, as many of those other people were. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
In the last episode (Nov 25), Daniel O'Connor said: On Tuesday 25 November 2003 06:45, Andrew Gallatin wrote: So.. forking a dynamic sh is roughly 40% more expensive than forking a static copy of sh. This is embarrassing. I propose that we at least make /bin/sh static. (and not add a /sbin/sh; if we must have a dynamic sh, import pdksh, or put a dynamically linked sh in /usr/bin/sh). I'd greatly prefer that the the dynamic root default be backed out until a substantial amount of this performance can be recovered. What _REAL WORLD_ task does this slow down? Try timing cd /usr/ports/www/mozilla-devel ; make clean with static and dynamic /bin. bsd.port.mk spawns many many many /bin/sh processes. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
In message: [EMAIL PROTECTED] Dan Nelson [EMAIL PROTECTED] writes: : In the last episode (Nov 25), Daniel O'Connor said: : On Tuesday 25 November 2003 06:45, Andrew Gallatin wrote: : So.. forking a dynamic sh is roughly 40% more expensive than : forking a static copy of sh. This is embarrassing. : : I propose that we at least make /bin/sh static. (and not add a : /sbin/sh; if we must have a dynamic sh, import pdksh, or put a : dynamically linked sh in /usr/bin/sh). : : I'd greatly prefer that the the dynamic root default be backed out : until a substantial amount of this performance can be recovered. : : What _REAL WORLD_ task does this slow down? : : Try timing cd /usr/ports/www/mozilla-devel ; make clean with static : and dynamic /bin. bsd.port.mk spawns many many many /bin/sh processes. Maybe you could try it with both and tell us the actual difference in wall time? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
Andrew Gallatin wrote: So I think the best solution (*) would be to keep /bin/sh statically linked, and build a dynamic version in /usr/bin that people can use as an interactive shell. Root's shell remains /bin/sh 1) All three (;-) interactive bourne shell users that use nss/ldap get tilde expansion. 2) 3rd party scripts, which are written to be portable and don't use tilde, don't have to pay for dynamic linking. 3) System startup scripts are faster because they use the static /bin/sh Are you suggesting that (t)csh also move to /usr/bin to match /usr/bin/sh? The screams caused by such a change would be deafening. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
serial console trouble
I'm putting together a ipf/ipnat gateway for a friend using his abit BX (rev2) motherboard. I'd very much to get serial console working before tendering it over; but am having zero luck. The world/kernel deployed to this box is from my NFS host box (which runs the same kernel/world, and whose serial console works fine). The only thing that seems odd to me is that dmesg doesn't report the appropriate flags (0x10) despite them being in device.hints. Nevertheless, I should still be able to use the serial port as a login terminal give my ttys; but even that doesn't work. Anyone see anything awry here ? Anything I should try ? I've tried disabling acpi in the bios to no avail; switching on/off PNP in the bios to no avail; switching from auto to hard-set port settings in the bios to no avail. Lengthy verbose boot follows as well as kernel config. # uname -a FreeBSD test.robinpb.home 5.2-BETA FreeBSD 5.2-BETA #0: Mon Nov 24 14:41:28 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/vpn.ule i386 # fgrep COMCONSOLE /etc/make.conf BOOT_COMCONSOLE_SPEED=19200 # fgrep ttyd0 /etc/ttys ttyd0 /usr/libexec/getty std.19200 unknown on secure # fgrep sio.0 /boot/device.hints hint.sio.0.at=isa hint.sio.0.port=0x3F8 hint.sio.0.flags=0x10 hint.sio.0.irq=4 # cat /var/run/dmesg.boot Copyright (c) 1992-2003 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 5.2-BETA #0: Mon Nov 24 14:41:28 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/vpn.ule Preloaded elf kernel /boot/kernel/kernel at 0xc07a8000. Preloaded elf module /boot/modules/linux.ko at 0xc07a81f4. Preloaded elf module /boot/modules/if_de.ko at 0xc07a82a0. Preloaded elf module /boot/modules/accf_data.ko at 0xc07a834c. Preloaded elf module /boot/modules/accf_http.ko at 0xc07a83fc. Calibrating clock(s) ... i8254 clock: 1193269 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 412365212 Hz CPU: Pentium II/Pentium II Xeon/Celeron (412.37-MHz 686-class CPU) Origin = GenuineIntel Id = 0x653 Stepping = 3 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,P AT,PSE36,MMX,FXSR real memory = 134152192 (127 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00829000 - 0x07d89fff, 123080704 bytes (30049 pages) avail memory = 124874752 (119 MB) bios32: Found BIOS32 Service Directory header at 0xc00faf00 bios32: Entry = 0xfb380 (c00fb380) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb3b0 pnpbios: Found PnP BIOS data at 0xc00fbfd0 pnpbios: Entry = f:bff8 Rev = 1.0 Other BIOS signatures found: null: null device, zero device mem: memory I/O Pentium Pro MTRR support enabled random: entropy source acpi0: ABIT AWRDACPI on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00fdf00 PCI-Only Interrupts: 10 11 Location Bus Device Pin Link IRQs slot 1 0 15A 0x60 3 4 5 7 9 10 11 12 14 15 slot 1 0 15B 0x61 3 4 5 7 9 10 11 12 14 15 slot 1 0 15C 0x62 3 4 5 7 9 10 11 12 14 15 slot 1 0 15D 0x63 3 4 5 7 9 10 11 12 14 15 slot 2 0 13A 0x61 3 4 5 7 9 10 11 12 14 15 slot 2 0 13B 0x62 3 4 5 7 9 10 11 12 14 15 slot 2 0 13C 0x63 3 4 5 7 9 10 11 12 14 15 slot 2 0 13D 0x60 3 4 5 7 9 10 11 12 14 15 slot 3 0 11A 0x62 3 4 5 7 9 10 11 12 14 15 slot 3 0 11B 0x63 3 4 5 7 9 10 11 12 14 15 slot 3 0 11C 0x60 3 4 5 7 9 10 11 12 14 15 slot 3 0 11D 0x61 3 4 5 7 9 10 11 12 14 15 slot 4 09A 0x63 3 4 5 7 9 10 11 12 14 15 slot 4 09B 0x60 3 4 5 7 9 10 11 12 14 15 slot 4 09C 0x61 3 4 5 7 9 10 11 12 14 15 slot 4 09D 0x62 3 4 5 7 9 10 11 12 14 15 slot 5 0 17A 0x63 3 4 5 7 9 10 11 12 14 15 slot 5 0 17B 0x60 3 4 5 7 9 10 11 12 14 15 slot 5 0 17C 0x61 3 4 5 7 9 10 11 12 14 15 slot 5 0 17D 0x62 3 4 5 7 9 10 11 12 14 15 embedded07A 0x60 3 4 5 7 9 10 11 12 14 15 embedded07B 0x61 3 4 5 7 9 10 11 12 14 15 embedded07C 0x62 3 4 5 7 9 10 11 12 14 15 embedded07D 0x63 3 4 5 7 9 10 11 12 14 15 embedded01A 0x60 3 4 5 7 9 10 11 12 14 15 embedded01B 0x61 3 4 5 7 9 10 11 12 14 15 embedded01C 0x62 3 4 5 7 9 10 11 12 14 15 embedded01D 0x63 3 4 5 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0
Re: 40% slowdown with dynamic /bin/sh
On Monday 24 November 2003 05:25 pm, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Dan Nelson [EMAIL PROTECTED] writes: : In the last episode (Nov 25), Daniel O'Connor said: : On Tuesday 25 November 2003 06:45, Andrew Gallatin wrote: : So.. forking a dynamic sh is roughly 40% more expensive than : forking a static copy of sh. This is embarrassing. : : I propose that we at least make /bin/sh static. (and not add a : /sbin/sh; if we must have a dynamic sh, import pdksh, or put a : dynamically linked sh in /usr/bin/sh). : : I'd greatly prefer that the the dynamic root default be backed out : until a substantial amount of this performance can be recovered. : : What _REAL WORLD_ task does this slow down? : : Try timing cd /usr/ports/www/mozilla-devel ; make clean with static : and dynamic /bin. bsd.port.mk spawns many many many /bin/sh processes. Maybe you could try it with both and tell us the actual difference in wall time? I don't see why this surprises anyone. A dynamic shell has to be the equivalent of swapping. In situations I have been in, you can only improve on static if you have a way to leave the pieces memory resident. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
On Tuesday 25 November 2003 11:36, Frank Mayhar wrote: Daniel O'Connor wrote: What _REAL WORLD_ task does this slow down? I think the point was that, in this particular worst case, it's a forty percent performance hit. What's the average case? What's the case for a real world pipeline with a lot of tiny little static binaries? I dislike this decision enough that I'm actually considering going away from FreeBSD, something I really had never for a moment thought possible. It's even worse that you deride someone who tried to shed a little light on the discussion. It is _trivial_ to buildworld with a static root. The performance hit is real. Even if it's not forty percent it's worth consideration, no matter how much you may want to shout down those who disagree. Of course it's real! I am not disputing that. It's just that I believe most people don't run /bin/sh so much it matters. If they do, then building it static is simple. My production systems don't spin in infinite loops spawning shell processes which die straight away. Uh, _huh_. Well, can you _imagine_ a scenario in which a production system might actually do something along those lines? _I_ can. Think a system of shell scripts. Sigh. Surely you don't run /bin/sh so frequently it has an appreciable impact.. Again, if you do, buildworld with static binaries. System shell scripts run mostly at boot, this is not what the PC spends most of it's time doing. If you have a file, web, mail, database, etc server it's predominant application is already dynamically linked. I can guarantee you that you have no idea _at all_ what is of relevance to most users of FreeBSD. It is nearly axiomatic that developers cannot imagine the uses to which their users put their systems. I'm not a committer, I use FreeBSD and I submit PRs. Perhaps we should run a survey to determine what If it is for you then just build your world with static root. Kind of defeats the purpose, don't you think? ?! Not really, if you want the performance back, then build statically. Feh. This is utterly ridiculous. Yeah, I understand why you guys made the decision. It's the same set of reasons a lot of other people in the past have made the same or similar decisions. We'll see if you get burned by it, as many of those other people were. Why didn't you pipe up when this was discussed _long_ ago? I don't understand why you can't buildworld with static slash if you feel so strongly about it. If you are deploying FreeBSD on servers you should build your own release anyway (which is hardly an onerous task). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
Tim Kientzle wrote: David O'Brien wrote: On Mon, Nov 24, 2003 at 12:08:58PM -0800, Tim Kientzle wrote: ... I think [/rescue] only needs to support those recovery actions necessary to repair /bin and /sbin if they break. My stance is that no failure mode needs to be repairable that wasn't repairable with a static /. I'm willing to compromise, David. Here's what I suggest: * I could support removing vi/ex from /rescue. * In exchange for this concession, would you be willing to support adding fetch? I expect this exchange would result in a net 150-200 kB savings in /rescue. How about it? Tim I think a better compromise is to add the make.conf option so that extra utilities may be added to /rescue. Then leave both vi and fetch out of the default. With the size of disk drives these days, (for my own setup) I'm tempted to just add a complete copy of /bin and /sbin into /rescue. The extra 100 meg doesn't take much out of a 80 gig hard drive. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
On Tuesday 25 November 2003 11:52, Dan Nelson wrote: I'd greatly prefer that the the dynamic root default be backed out until a substantial amount of this performance can be recovered. What _REAL WORLD_ task does this slow down? Try timing cd /usr/ports/www/mozilla-devel ; make clean with static and dynamic /bin. bsd.port.mk spawns many many many /bin/sh processes. OK my bad, it will probably slow down the ports building. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
Daniel O'Connor writes: On Tuesday 25 November 2003 11:52, Dan Nelson wrote: I'd greatly prefer that the the dynamic root default be backed out until a substantial amount of this performance can be recovered. What _REAL WORLD_ task does this slow down? Try timing cd /usr/ports/www/mozilla-devel ; make clean with static and dynamic /bin. bsd.port.mk spawns many many many /bin/sh processes. OK my bad, it will probably slow down the ports building. I'll bet a larger percentage of our users build ports than need nss or ldap. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
Steve Kargl wrote: On Mon, Nov 24, 2003 at 05:06:52PM -0800, Frank Mayhar wrote: Kind of defeats the purpose, don't you think? Let's see. You dislike the dynamic root decision enough that you are considering the abandonment of FreeBSD. Then when you're told that you can still build a static root if you need/want it, you make a sarcastic remark. It wasn't sarcastic, it was serious. Needing to have special configuration defeats the purpose of running FreeBSD for me. I'm busy enough that I don't have time to deal with everything _now_; adding something else I have to keep track of for a half-dozen systems is something else I just don't need. Cake remark elided. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
Daniel O'Connor writes: It is _trivial_ to buildworld with a static root. Then its equally trivial to build with a dynamic root. Please do so, and don't wreck the performance of the OS I've used since 1994. Why didn't you pipe up when this was discussed _long_ ago? In the orginal thread, there was an agreement that the performance would be measured BEFORE the default was changed, and the default would only be changed if there was no measurable performance impact. I believe sam@ asked for this. As far as I know, performance measurments were never done. Instead, the switch was thrown just before the code freeze. If you are deploying FreeBSD on servers you should build your own release anyway (which is hardly an onerous task). Its pretty hard to use the binary update tools that way. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
Richard Coleman writes: Are you suggesting that (t)csh also move to /usr/bin to match /usr/bin/sh? The screams caused by such a change would be deafening. Of course not. Nobody in their right mind uses csh for scripting. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
I'm not going to add to the heat in the rest of the email, but this is a very good question: Daniel O'Connor wrote: Why didn't you pipe up when this was discussed _long_ ago? Honestly, I don't remember the discussion. It's certainly possible that I may have missed it. I just dug around in the -current archives and couldn't find the it, but my life has been kind of chaotic over the last year or so. In fact, if it happened about a year ago, it could well have taken place while I was in China for three weeks. Believe me, if I had encountered the discussion when it took place, I would have made my feelings known. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
On Tuesday 25 November 2003 12:23, Frank Mayhar wrote: Let's see. You dislike the dynamic root decision enough that you are considering the abandonment of FreeBSD. Then when you're told that you can still build a static root if you need/want it, you make a sarcastic remark. It wasn't sarcastic, it was serious. Needing to have special configuration defeats the purpose of running FreeBSD for me. I'm busy enough that I don't have time to deal with everything _now_; adding something else I have to keep track of for a half-dozen systems is something else I just don't need. You DO know FreeBSD is a cooperative project right? I hardly think you're in a position to complain about a (probably very minor) performance loss which has a trivial work around, which also benefits a fair number of users. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
On 25 Nov, Daniel O'Connor wrote: On Tuesday 25 November 2003 11:52, Dan Nelson wrote: I'd greatly prefer that the the dynamic root default be backed out until a substantial amount of this performance can be recovered. What _REAL WORLD_ task does this slow down? Try timing cd /usr/ports/www/mozilla-devel ; make clean with static and dynamic /bin. bsd.port.mk spawns many many many /bin/sh processes. OK my bad, it will probably slow down the ports building. The ports infrastructure is horribly slow even with a static sh, though not as glacially slow as installing and patching Solaris 9. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
