Re: loads of SetAttrs in cvsup of cvs repo
Amancio Hasty wrote: > Curious why are you cvsupping every couple of minutes ? He isn't. He's saying normally when he cvsups, it only takes a couple of minutes, not that he does it every couple of minutes. At least that's the way I read it. -- Ben Smithurst| PGP: 0x99392F7D [EMAIL PROTECTED] | key available from keyservers and | [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Making sure /var/tmp/vi.recover exists during reboot
Adrian Penisoara wrote: > (cc uses /var/tmp for > temporary files) so do "TMPDIR=/tmp; export TMPDIR", problem solved. (Or just use -pipe when compiling.) -- Ben Smithurst| PGP: 0x99392F7D [EMAIL PROTECTED] | key available from keyservers and | [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
timed/adjtime() on -current
[sorry about the crosspost - I'm not sure if this is me being a dumbass, or something wrong with adjtime() on current. adjtime() certainly behaves as I expect it to on stable.] I've recently updated one of my machines to -current, and now timed(8) seems to have stopped working. Is there some reason why timed(8) on -current wouldn't like the master being on -stable? (I can't see one.) Enabling tracing with timedc shows the corrections that timed thinks it should be making, and ktracing the timed process shows it is calling adjtime, but nothing seems to be changing the time. Hmm. timed is doing something very wierd... before starting timed, my clock seems to be fairly stable (gaining about 1ms per minute, but I can cope with that). As soon as I start timed, the clock starts gaining about 1ms per 2 seconds, which is a bit much. Actually, now I've written this, it's gaining about 5ms per second. Soon after I kill timed, the clock goes back to normal. So, I write a small program which calls adjtime itself... if I specify tv_sec=-4 and tv_usec=0, this seems to speed the clock up. tv_sec=4 seems to slow it down, in direct contradiction of the manpage and common sense: time on scientia.demon.co.uk is 4366 ms. behind time on platinum.scientia.demon.co.uk time on scientia.demon.co.uk is 4316 ms. behind time on platinum.scientia.demon.co.uk time on scientia.demon.co.uk is 4266 ms. behind time on platinum.scientia.demon.co.uk time on scientia.demon.co.uk is 4216 ms. behind time on platinum.scientia.demon.co.uk time on scientia.demon.co.uk is 4166 ms. behind time on platinum.scientia.demon.co.uk time on scientia.demon.co.uk is 4116 ms. behind time on platinum.scientia.demon.co.uk time on scientia.demon.co.uk is 4066 ms. behind time on platinum.scientia.demon.co.uk time on scientia.demon.co.uk is 4016 ms. behind time on platinum.scientia.demon.co.uk time on scientia.demon.co.uk is 3966 ms. behind time on platinum.scientia.demon.co.uk time on scientia.demon.co.uk is 3916 ms. behind time on platinum.scientia.demon.co.uk time on scientia.demon.co.uk is 3866 ms. behind time on platinum.scientia.demon.co.uk time on scientia.demon.co.uk is 3816 ms. behind time on platinum.scientia.demon.co.uk time on scientia.demon.co.uk is 3766 ms. behind time on platinum.scientia.demon.co.uk time on scientia.demon.co.uk is 3716 ms. behind time on platinum.scientia.demon.co.uk (platinum is the -current machine, scientia is the -stable timed master). This seems wierd... anyone know what's going on here? (It *is* 5 a.m., so I may be missing something obvious.) adjtime() seems to behave as I expect it to on -stable. If you want more information, just let me know. This is a fairly recent -current, cvsupped around 1 a.m. GMT saturday morning. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: timed/adjtime() on -current
Poul-Henning Kamp wrote: > You're right, I used the wrong sign last I mucked about with this, I'll > fix this. thanks... > Anyway: Don't used timed, use ntpd. Do you have any hints about using xntpd over an intermittent dialup connection? At the moment, I use ntpdate to sync the time to my ISP's servers when ever I go online, I can't see it being easy to tell xntpd to sync the time when I tell it to, and only when I tell it to. Unless you know otherwise? :-) -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
getaddrinfo with IPv6 and unqualified hostname
Is it just some misconfiguration of mine which causes getaddrinfo() with an unqualified hostname, IPv6 and hints->ai_family == AF_UNSPEC to block (trying a DNS lookup I guess), even when the hostname has a perfectly good IPv4 address, or is this normal behaviour? This seems rather annoying, and means something as simple as "ftp otherhost" will block unless I use the FQDN. Is there any way to avoid this behaviour? ben@platinum:~$ nslookup magnesium Server: magnesium.scientia.demon.co.uk Address: 192.168.91.34 Name:magnesium.scientia.demon.co.uk Address: 192.168.91.34 ben@platinum:~$ ping magnesium PING magnesium.scientia.demon.co.uk (192.168.91.34): 56 data bytes 64 bytes from 192.168.91.34: icmp_seq=0 ttl=255 time=0.347 ms 64 bytes from 192.168.91.34: icmp_seq=1 ttl=255 time=0.349 ms ^C --- magnesium.scientia.demon.co.uk ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.347/0.348/0.349/0.001 ms ben@platinum:~$ ftp magnesium load: 0.00 cmd: ftp 9478 [poll] 0.00u 0.01s 0% 976k It's rather annoying, to say the least. The pause may well be quite short if you have a permanent connection so the DNS lookup can fail quickly, but it will take a while to timeout with an intermittent connection. :-( -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build World dies....
William Woods wrote: > ===> libpam/modules/pam_ssh > make: don't know how to make log-client.c. Stop > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > > -- > > How would I fix that. Add NO_OPENSSH=true and NO_OPENSSL=true to /etc/make.conf, that fixed it for me. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build World dies....
William Woods wrote: > Grr..cant say I like that idea, I would like to have them both... Oh. You *have* cvsup'ed the cvs-crypto collection, right? I think that's the one you need. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: getaddrinfo with IPv6 and unqualified hostname
[EMAIL PROTECTED] wrote: > (I've tried to send it personally but it seems I couldn't) oh? Why not? I hope my ISP hasn't broken something. > if you put the following line into /etc/hosts, your case should be okay. > > --- from here > ::1 localhost > --- to here well, that will fix it for "localhost", but for the more general case of other unqualified hostnames (I guess I should have made this clearer earlier on). Still, I'll put that line in anyway. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: getaddrinfo with IPv6 and unqualified hostname
[EMAIL PROTECTED] wrote: > lookup /etc/hosts for IPv6 address > lookup DNS for IPv6 address <--- > lookup /etc/hosts for IPv4 address > lookup DNS for IPv4 address > Ben dislikes the second item on the above. What I dislike really is looking up the unqualified name in the root domain *before* checking the qualified name for an IPv4 address. Is something like this possible, for unqualified names? assume query "foo", default domain is "domain" ... lookup "foo" in /etc/hosts for either address type lookup "foo.domain." in DNS () lookup "foo.domain." in DNS (A) lookup "foo." in DNS () lookup "foo." in DNS (A) this seems the best to me, but I wouldn't know if it's a) easy, b) possible, c) standards conforming. I'm not sure where /etc/hosts would go. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: getaddrinfo with IPv6 and unqualified hostname
Jun-ichiro itojun Hagino wrote: > Ben, if you run tcpdump, do you see forward lookups for ? yes: 10:32:43.545488 platinum.scientia.demon.co.uk.1787 > magnesium.scientia.demon.co.uk.domain: 42376+ ? localhost.scientia.demon.co.uk. (48) 10:32:43.545951 magnesium.scientia.demon.co.uk.domain > platinum.scientia.demon.co.uk.1787: 42376* 0/1/0 (118) 10:32:43.546321 platinum.scientia.demon.co.uk.1788 > magnesium.scientia.demon.co.uk.domain: 42377+ ? localhost. (27) 10:32:43.546584 magnesium.scientia.demon.co.uk.3719 > scientia.demon.co.uk.domain: 54839+ ? localhost. (27) 10:32:48.552729 platinum.scientia.demon.co.uk.1789 > scientia.demon.co.uk.domain: 42377+ ? localhost. (27) > I intend to correct this one, however, the way to fix it is very > dependent to resolver internal functions. so fix to netbsd-current > won't apply to freebsd-current. oh, OK. As long as it's kind of known about and not just something I've broken locally. thanks. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: timed/adjtime() on -current
Peter Wemm wrote: > Set your ppp filters carefully. Tell it that ntp packets (port 123) are > not to cause a dialup, and are not to trigger the idle timer. The result > of this will be that ntp will sync up while you are online but won't keep > the connection alive and prevent an idle hangup (assuming you use idle > timeouts). ok. I wasn't aware that ntpd would constantly try to sync... I thought it would just try every few minutes, which might miss a connection. I'll look at this then, I didn't realise it was so easy. :-) thanks. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: getaddrinfo with IPv6 and unqualified hostname
I wrote: > I'm not sure where /etc/hosts would go. sorry, forget that bit, I wrote that before I'd finished writing the search order, which did include /etc/hosts in the end. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: getaddrinfo with IPv6 and unqualified hostname
[EMAIL PROTECTED] wrote: > As I said, the above order makes more sense. However, to do the above > we need a MAJOR rewrite in src/lib/libc/net. BIND9 does not address > this problem either. Let us (KAME) think what is the best solution > in long-term, and short-term. ok. For now I've found the really simple solution (I knew there would be one) I should have found straight away... add IPv6 addresses to the DNS for the hosts on my network, as IPv4-mapped addresses, i.e. magnesium A 192.168.91.34 :::192.168.91.34 things seem to be working better now, as the initial IPv6 query succeeds. > More description can be found in NetBSD PR I've replied (URL > attached in one of previous emails). I'll take a look. Thanks for the help. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world
Kai Großjohann wrote: > Omachonu Ogali <[EMAIL PROTECTED]> writes: > >> ===> lib/libcom_err/doc >> install-info --quiet --defsection="Programming & development tools." >--defentry="* libcom_err: (com_err).A Common Error Description Library for >UNIX." com_err.info /usr/share/info/dir >> install-info: unrecognized option `--defsection=Programming & development tools.' >> Try `install-info --help' for a complete list of options. > > I did `make -k install-world', then `make installworld'. The first > make will install the new install-info binary which has the new > options, the second make will use that binary to install the info > files. Isn't that overkill? I just did "cd /usr/src/gnu/usr.bin/texinfo/install-info; make install" before a normal "make installworld". > I hope this isn't wrong... ditto :-) -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 Release tag.......
William Woods wrote: > My ISP mail was down for about 5 hrs yesterday..what is the 4.0 release > cvsup tag? Better to ask that after 4.0 is released, then there might actually be a valid answer other than "there isn't one". :-) I think it's planned for release on the 10th. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: YA ssh question (ssh-askpass?)
Richard J Kuhns wrote: > I've installed a Tcl/Tk version of ssh-askpass in /usr/local/bin (which > works by itself; I've tried it). I've also set SSH_ASKPASS_ENV to > /usr/local/bin/ssh-askpass, but it hasn't made any difference. ben@platinum:/usr/src/crypto/openssh$ grep ssh-askpass * ssh.h: * Default path to ssh-askpass used by ssh-add, ssh.h:#define SSH_ASKPASS_DEFAULT "/usr/X11R6/bin/ssh-askpass" have you tried putting it in that location? -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mount_cd9660+atapi-cd panic
s... 12
done
Uptime: 2m50s
dumping to dev #ad/0x50001, offset 278656
dump ata0: resetting devices .. done
63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35
34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4
3 2 1 0
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
304 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc012ddc8 in poweroff_wait (junk=0xc01ffccf, howto=-978243040) at
../../kern/kern_shutdown.c:554
#2 0xc01dbcd9 in trap_fatal (frame=0xc6047cf0, eva=44) at ../../i386/i386/trap.c:924
#3 0xc01db9b1 in trap_pfault (frame=0xc6047cf0, usermode=0, eva=44) at
../../i386/i386/trap.c:817
#4 0xc01db57b in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi
= -1065680896,
tf_ebp = -972784324, tf_isp = -972784356, tf_ebx = -1064931712, tf_edx = 0,
tf_ecx = 0, tf_eax = 44,
tf_trapno = 12, tf_err = 0, tf_eip = -1071923027, tf_cs = 8, tf_eflags = 66050,
tf_esp = -1065678848,
tf_ss = -1065704960}) at ../../i386/i386/trap.c:423
#5 0xc01bc0ad in atapi_queue_cmd (atp=0xc07b, ccb=0xc6047d68 "\036", data=0x0,
count=0, flags=0, timeout=30,
callback=0, unused=0x0, bp=0x0) at ../../dev/ata/atapi-all.c:178
#6 0xc01bfdd0 in acd_prevent_allow (cdp=0xc07b0800, lock=1) at
../../dev/ata/atapi-cd.c:1747
#7 0xc01bdbae in acdopen (dev=0xc07aa200, flags=1, fmt=8192, p=0xc5b13220) at
../../dev/ata/atapi-cd.c:481
#8 0xc015eef9 in spec_open (ap=0xc6047e10) at ../../miscfs/specfs/spec_vnops.c:191
#9 0xc015edf9 in spec_vnoperate (ap=0xc6047e10) at
../../miscfs/specfs/spec_vnops.c:117
#10 0xc01a4f51 in ufs_vnoperatespec (ap=0xc6047e10) at ../../ufs/ufs/ufs_vnops.c:2301
#11 0xc015ba3f in vn_open (ndp=0xc6047edc, fmode=1, cmode=0) at vnode_if.h:189
#12 0xc0157a3d in open (p=0xc5b13220, uap=0xc6047f80) at ../../kern/vfs_syscalls.c:994
#13 0xc01dbf0a in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi =
-1077936645, tf_esi = 2,
tf_ebp = -1077938168, tf_isp = -972783660, tf_ebx = -1077936832, tf_edx =
-1077936635, tf_ecx = -1077936635,
tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip = 134525628, tf_cs = 31,
tf_eflags = 647, tf_esp = -1077939028,
tf_ss = 47}) at ../../i386/i386/trap.c:1073
#14 0xc01d0e86 in Xint0x80_syscall ()
#15 0x80482b9 in ?? ()
#16 0x80480f9 in ?? ()
(kgdb) frame 5
#5 0xc01bc0ad in atapi_queue_cmd (atp=0xc07b, ccb=0xc6047d68 "\036", data=0x0,
count=0, flags=0, timeout=30,
callback=0, unused=0x0, bp=0x0) at ../../dev/ata/atapi-all.c:178
178 request->ccbsize = (ATP_PARAM->cmdsize) ? 16 : 12;
(kgdb) p request
$1 = (struct atapi_request *) 0x0
(this seems odd, a few lines before that dereferenced request without a
problem.)
(kgdb) p *atp
$2 = {controller = 0x0, unit = 0, driver = 0x10, devname = 0x18 , cmd = 32 ' ',
flags = 1024}
That doesn't look very useful either... I'm guessing the fix should be
fairly simple (check something != NULL and return ESOMETHING if it is),
unfortunately as the drive seems to be working again I won't be able to
test it. :-(
kernel config file:
## $Id: PLATINUM,v 1.10 2000/02/20 20:34:28 ben Exp $
machine i386
cpu I586_CPU
ident PLATINUM
maxusers16
options ATA_STATIC_ID
options COMPAT_43
options FFS
options FFS_ROOT
options INET
options INET6
options KTRACE
options P1003_1B
options SOFTUPDATES
options SYSVSHM
options UCONSOLE
options _KPOSIX_PRIORITY_SCHEDULING
device isa
device atkbdc0 at isa? port IO_KBD
device miibus
device pci
device ata
device atadisk
device atapicd
device atkbd0 at atkbdc? irq 1
device psm0at atkbdc? irq 12
device npx0at nexus? port IO_NPX irq 13
device rl
device sc0 at isa?
device vga0at isa?
pseudo-device bpf 4
pseudo-device loop
pseudo-device ether
pseudo-device pty
pseudo-device splash
If you want more information, let me know.
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
netstat output for inet6
Is there any way to see the full IPv6 address with netstat? I just see: ben@strontium:~$ netstat -an -f inet6 Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address(state) tcp6 0 0 2002:d4e4:e0d:0:.989 2002:d4e4:e0d:0:.22ESTABLISHED ... Perhaps there's some flag I missed. If there is no way, there should be; perhaps a -W flag for wider output for IPv6 addresses? I'll try this myself if people think it would be a good idea, or have any better ideas, but it may be too much for me. :-) -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: netstat output for inet6
Yoshinobu Inoue wrote: > Please add "-l" flag. ah.. thanks. > And sorry, it is not added to netstat man yet. I see you've just commited a change there, but I think it needs adding to the usage message as well: ben@platinum:~$ netstat -\? netstat: illegal option -- ? usage: netstat [-Aan] [-f address_family] [-M core] [-N system] netstat [-abdghimnrs] [-f address_family] [-M core] [-N system] netstat [-bdn] [-I interface] [-M core] [-N system] [-w wait] netstat [-M core] [-N system] [-p protocol] -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0R ?
Jim Bloom wrote: > The tag was laid down earlier today. Here is what my current kernel > claims to be at the moment: I saw the RELENG_4 tag in my cvsup log, but I don't think that's the same as the 4.0 release tag is it? That would be RELENG_4_0_0_RELEASE surely. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why do FreeBSD mailing lists ignore MX preference?
Bruce Albrecht wrote: > Non-authoritative answer: > zuhause.mn.org preference = 150, mail exchanger = minuet.skypoint.net > zuhause.mn.org preference = 100, mail exchanger = 205.215.217.178 "205.215.217.178." almost certainly does not have an address (A) record. Mail exchangers must be host names, not IP addresses. -- Ben Smithurst| PGP: 0x99392F7D [EMAIL PROTECTED] | key available from keyservers and | [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
[ CC list trimmed ] Pat Lynch wrote: > DUL, while I'm not sure whether we should take this to -chat or not since > we are now getting into noise on the -current list, is also a good thing. > simply because noone on a dialup has reason to be sending mail directly to > me, they should be sending it through thier ISP's mail servers. There are reasons not to use an ISP's smarthost. First, I have no idea how long my mail will stay there. Second, if my mail can't be delivered to the other end immediately, I'd rather be able to find out why by checking my logs. Third, my ISP's smarthost has occasionally been blacklisted by ORBS because it relays mail for its customers, some of whom are running open relays. (This is a completely ridiculous action on ORBS' part, IMO, but that's a discussion for somewhere else.) So far at least, I have never had any problems sending mail from my dialup (which has a static IP address -- I think static IP dialups are exempt from many dialup blocking lists), and I hope this will continue. -- Ben Smithurst| PGP: 0x99392F7D [EMAIL PROTECTED] | key available from keyservers and | [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: identd
Phil 0. Nature wrote: > Has anyone else experienced problems with identd not working? Uh, you'd probably have to be more specific. What identd (pidentd from ports, or something else). What version. In what way doesn't it work. What error messages are being logged. What version of FreeBSD. -current, presumably, but how recent. The only small problem I've seen is this, with pidentd-2.8.5 from ports on a 3.2-stable system: Sep 30 21:54:20 scientia identd[75098]: getbuf: bad address (0f80 not in c0116360-0xFFC0) - ofile Sep 30 21:54:20 scientia identd[75098]: k_getuid retries: 1 Oct 3 12:48:00 scientia identd[93188]: getbuf: bad address (137b not in c0116360-0xFFC0) - ofile Oct 3 12:48:00 scientia identd[93188]: k_getuid retries: 1 but I haven't got round to looking into it much. Other than those two errors, it works fine. -- Ben Smithurst| PGP: 0x99392F7D [EMAIL PROTECTED] | key available from keyservers and | [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: People getting automatically unsub'ed from -arch
Jonathan M. Bresler wrote: > i do NOT send the person mail to inform them that the are > being removed from the mailing lists, because their email is bouncing. How about sending a message to them once every 24 hours for, say, a week? I imagine some of those bounces are due to temporary mis-configurations which will soon be fixed. -- Ben Smithurst| PGP: 0x99392F7D [EMAIL PROTECTED] | key available from keyservers and | [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious locking problem in CURRENT
David Malone wrote:
> On Sat, Nov 06, 1999 at 01:29:16PM -0600, Jonathan Lemon wrote:
>
>> From the manual page for flock:
>>
>> NOTES
>> Locks are on files, not file descriptors. That is, file descriptors du-
>> plicated through dup(2) or fork(2) do not result in multiple instances of
>> a lock, but rather multiple references to a single lock. If a process
>> holding a lock on a file forks and the child explicitly unlocks the file,
>> the parent will lose its lock.
>
> Doesn't this make it impossible to hold a lock on a file when you
> want to fork a child to do some task 'cos the lock will be dropped
> when the child closes its copy of the file discriptor on exit?
> Either it's a posix goof or the lock shouldn't be let go until
> either explicitly released or the last instance of the file discriptor
> is closed?
The lock doesn't seem to be released until *explicitly* released, like
the manual page says. I don't think closing the descriptor counts as
an explicit unlock, though I am probably wrong. Run this program,
you'll see the parent still has the lock. Change close(fd) to flock(fd,
LOCK_UN) and you'll see it doesn't. It's possible I've misunderstood
something though.
#include
#include
#include
#include
int
main(void) {
int fd;
fd = open("lock", O_CREAT|O_RDWR, 0600);
if (fd < 0)
err(1, "open");
if (flock(fd, LOCK_EX) != 0)
err(1, "flock");
switch (fork()) {
case -1:
err(1, "fork");
case 0:
close(fd);
_exit(0);
default:
sleep(2);
break;
}
system("lsof | less");
return (0);
}
--
Ben Smithurst| PGP: 0x99392F7D
[EMAIL PROTECTED] | key available from keyservers and
| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
Dan Nelson wrote: > In the last episode (Nov 23), Forrest Aldrich said: >> Why does ps not show the full path on 4.0 as in 3.3? (for non-root >> users) >> >> 4.0> ps -ax >> >>134 v2 Is+0:00.00 (getty) >>135 v3 Is+0:00.00 (getty) >>136 v4 Is+0:00.00 (getty) >>137 v5 Is+0:00.00 (getty) >> >> 3.3> ps -ax >> >>312 v0 Is+0:00.01 /usr/libexec/getty Pc ttyv0 >>313 v1 Is+0:00.01 /usr/libexec/getty Pc ttyv1 >>314 v2 Is+0:00.01 /usr/libexec/getty Pc ttyv2 > > That just means that on your 4.0 box, the gettys have been swapped out. Wouldn't there be a difference in the STAT columns on each system if that were the case? (A 'W' according to ps(1) for the swapped out processes.) -- Ben Smithurst| PGP: 0x99392F7D [EMAIL PROTECTED] | key available from keyservers and | [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: burncd problem
John Hay wrote: > The CD writer is an HP 8100 and I have used it before without problems > with a much older version of 4-CURRENT, that is before the ata driver. > > Does anybody else have problems with the HP 8100 series? I have included > dmesg.boot at the end. Someone else reported problems with an HP 8100 on (I think) -stable recently. Maybe coincidence, maybe not. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make release problems
first, is a "make release" of a 5.0-current snapshot supposed to be possible on 4-stable? It seems to be failing here, but perhaps I'm just dumb in hoping it would work to start with. :-) ===> sys/modules/tx @ -> /usr/src/sys machine -> /usr/src/sys/i386/include touch opt_bdg.h perl @/kern/makeobjops.pl -h @/kern/device_if.m perl @/kern/makeobjops.pl -h @/kern/bus_if.m perl @/kern/makeobjops.pl -h @/pci/pci_if.m perl @/kern/makeobjops.pl -h @/dev/mii/miibus_if.m rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../include -I/usr/obj/usr/src/i386/usr/include / usr/src/sys/modules/tx/../../pci/if_tx.c /usr/src/sys/modules/tx/../../pci/if_tx.c:68: bpf.h: No such file or directory mkdep: compile failed *** Error code 1 Should I just do a normal "make buildworld" instead of trying to do a "make release"? It looks as though if_tx.c is #including "bpf.h" when nothing else in /sys/pci seems to, which strikes me as odd as well. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone have OpenSSH + X11-fwd working?
Brian Fundakowski Feldman wrote: > On Thu, 20 Apr 2000, Chris Piazza wrote: > >> It's working from my 5.0 box to my 4.0-R box across town, too. >> >> -Chris > > Okay, give me some more info, please: > > You're going from the 5.0 box to the 4.0 box. What's the /etc/hosts > look like on the 5.0 box? What's xauth list show (you don't have to > show me the cookies, of course :)? What does xauth list say when > you're ssh'd into the 4.0 box? X11 forwarding is working for me now, but wasn't when I first tried it. I found I was explicitly setting XAUTHORITY=~/.Xauthority in my .zshrc file, so the temporary bits created in /tmp/ssh-foo/cookies by ssh weren't being picked up. I missed the beginning of this thread, but you're not doing anything similar are you? After fixing that, it seems to be working for me. Of course, I'm on 4.0-stable, so if that works for you anyway and it's just 5.0-current which is broken, ignore me. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wrong permissions on /dev ?
Arun Sharma wrote: > There is a minor nit about the permissions on /dev. It was not readable > by others. So ps wouldn't work, because it could not open /dev/null. I noticed this when I tried a home-built 5.0 snapshot (/dev was mode 0700), I didn't report it though because I thought it might have been an artifact of my botched installation attempt on that machine. This was a clean 5.0 install, not an upgrade of any kind. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs/df bug?
Alexander Langer wrote: > neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs > neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 > neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn > neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs > neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 > neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn > neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs > neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 > neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn > neutron:/usr/home/ncvs 992439 9606843175597%/usr/home/ncvs > neutron:/usr/home/mp3 9591515 9298876 29263997%/usr/home/mp3 > neutron:/usr/home/brenn 695311 5948384484993%/usr/home/brenn You probably have a symlink in the client path somewhere. Is /usr/home a symlink to /home or something? -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
Re: mount_nfs/df bug?
Alexander Langer wrote: >> You probably have a symlink in the client path somewhere. Is /usr/home >> a symlink to /home or something? > > drwxr-xr-x 7 root wheel 512 6 Mär 14:45 /usr/home/ > lrwxrwxrwx 1 root wheel 9 27 Feb 20:33 /home@ -> /usr/home ok, that's not it, the /home symlink shouldn't matter... Or are any of the affected directories (brenn, mp3, ncvs) symlinks? Or maybe your /etc/fstab lists /home/foo instead of /usr/home/foo? > However, that is not the point. Well, if symlinks are involved I think this is a known bug. Would you care to fix it? :-) Whether it's a bug in the mount(8) program, the mount(2) syscall, or somewhere deeper, I don't know. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
Re: Virus alert, was: Re: SCSI Question
Jeroen Ruigrok van der Werven wrote: > -On [2709 21:20], Leif Neland ([EMAIL PROTECTED]) wrote: >> These messages are infected with the kak virus. See >> http://www.cai.com/virusinfo/encyclopedia/descriptions/wscript.htm > > Am I the only one to NOT see this? > > Both the original postings look normal in mutt whichever way I use to > look at them. Try "|less". I think it says a lot that you have to make special effort to even _see_ the virus on FreeBSD, when on Windows it probably gets executed by default... -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
Re: KAME integration and plans
Kris Kennaway wrote: > In this vein, I'd like to suggest a new "hands-off" policy of not > committing gratuitous changes to KAME-derived code, including manpage > changes, unless: > > a) The commit is required for operation on FreeBSD (in which case it's not > really gratuitous) I'd like to commit this: --- stf.4 2000/07/04 16:39:23 1.4 +++ stf.4 2000/07/11 13:44:47 @@ -36,7 +36,7 @@ .Nd .Tn 6to4 tunnel interface .Sh SYNOPSIS -.Cd "pseudo-device stf" +.Cd "pseudo-device gif" .Sh DESCRIPTION The .Nm 'pseudo-device stf' gives an error, stf lives in the gif driver, so this is required really. Is that ok? Is there anyone at KAME I should send this to as well? > Sheldon Hearn will be taking care of passing the manpage diffs back to > KAME. ah... right. I guess that answers my question. :-) Sheldon - you can commit this yourself if you want, or shall I do it and you just take care of passing it back to KAME? It's releated to PR 19163 by the way. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
Re: KAME integration and plans
Sheldon Hearn wrote: > On Tue, 11 Jul 2000 14:56:35 +0100, Ben Smithurst wrote: > >> 'pseudo-device stf' gives an error, stf lives in the gif driver, so this >> is required really. Is that ok? Is there anyone at KAME I should send >> this to as well? > > I'm interested to see how the KAME folks react to our chucking out the > pseudo-device keyword from config(8). :-) Ah, good point... I did my test on -stable where pseudo-device still exists. I'll wait for a while for this one then. There's another PR open on this problem, which asmodai is looking at (18852). -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
Re: KAME integration and plans
Hajimu UMEMOTO wrote: >>>>>> On Tue, 11 Jul 2000 14:56:35 +0100 >>>>>> Ben Smithurst <[EMAIL PROTECTED]> said: > > ben> 'pseudo-device stf' gives an error, stf lives in the gif driver, so this > ben> is required really. Is that ok? Is there anyone at KAME I should send > ben> this to as well? > > No. Before merging latest KAME, that is true. In that days, stf was > quick hack version of gif. But, stf is NOT gif but stf, now. > My config contains: > > device stf # 6to4 IPv6 over IPv4 encapsulation Ok. I guess all that needs doing is s/pseudo-device/device/ in the SYNOPSIS then. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
Re: KAME integration and plans
Kris Kennaway wrote: > On Tue, 11 Jul 2000, Ben Smithurst wrote: > >> 'pseudo-device stf' gives an error, stf lives in the gif driver, so this >> is required really. Is that ok? Is there anyone at KAME I should send >> this to as well? > > Um, "device stf" certainly does work. Ah. I'm using -STABLE here... AFAICT you still need 'pseudo-device gif' there. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
Re: if_tun.ko seems broken
Sheldon Hearn wrote: > On Wed, 26 Jul 2000 12:33:07 +0200, Sheldon Hearn wrote: > >> Does this have anything to do with your recent change to if_tun.c? > > Nope. I've reverted rev 1.75 of if_tun.c and the behaviour persists. > Someone locally insists that the ifconfig line > > ifconfig tun0 inet 10.0.0.1 > > should work. Any ideas? I think the device needs to be opened before you can do anything with it. PPP of course does this for you, but if you want to ifconfig it yourself you might try something like ``dd if=/dev/tun0 of=/dev/null count=0'' first. That makes ifconfig work for me at least, I'm not sure if it's the "right" way. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D FreeBSD Documentation Project / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Broadcast address with DHCP
dhclient seems to be broken, it's giving me the all zeroes broadcast
address instead of all ones:
inet 192.168.91.35 netmask 0xfff0 broadcast 192.168.91.32
(should be broadcast 192.168.91.47)
Index: dhclient.c
===
RCS file: /usr/cvs/src/contrib/isc-dhcp/client/dhclient.c,v
retrieving revision 1.16
diff -u -r1.16 dhclient.c
--- dhclient.c 2000/07/20 19:51:37 1.16
+++ dhclient.c 2000/07/27 12:21:38
@@ -1972,7 +1972,7 @@
if (broadcast.len) {
client_envadd (ip -> client,
prefix, "broadcast_address",
- "%s", piaddr (subnet));
+ "%s", piaddr (broadcast));
}
}
}
I think this needs fixing.
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
FreeBSD Documentation Project /
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Broadcast address with DHCP
Ben Smithurst wrote: > dhclient seems to be broken, it's giving me the all zeroes broadcast > address instead of all ones: > > inet 192.168.91.35 netmask 0xfff0 broadcast 192.168.91.32 > > (should be broadcast 192.168.91.47) ok, ignore this, it seems to be working after another buildworld. I'm not sure why it broke in the first place. :-( -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D FreeBSD Documentation Project / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftp and /etc/services...
Donn Miller wrote: > This is on a recently-built -current box. When I try to move ftp from > port 21 to port 2121 in /etc/services, I get a "Connection refused" > message when I try to login to anonymous ftp sites. Well _there's_ a surprise. > Should ftp be this dependent on /etc/services? Uh, yes, that's the whole _point_ of /etc/services, so you can dynamically get a port number rather than hardcoding it. Of course, the port number for things like ftp/http/smtp and the other popular protocols are very unlikely to ever change, but that's not the point. If you change port numbers in /etc/services, things will break. > What if you _have_ no services running, e.g. inetd & portmap? ?? What relevance does that have to your problem/question? -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D FreeBSD Documentation Project / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Question from a neophyte... Why isn't rc.local being read?
Michael Lucas wrote: > rc.local is deprecated. Drop a shell script in /usr/local/etc/rc.d Not really. Some of us prefer to have commands to start things in one nice list in /etc/rc.local, rather than loads of separate shell scripts in /usr/local/etc/rc.d. There's no reason I can see for rc.local not to get read at boot time. I'd recommend the original poster compare his other /etc/rc* files with those in /usr/src/etc to make sure there has been no local modification to remove the code which calls rc.local. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
patch for mergemaster when /dev is devfs
Just a minor point...
Should we add a patch something like this to mergemaster so that it
doesn't prompt the user about MAKEDEV if their /dev is a devfs where
MAKEDEV can't be created anyway?
Or would you prefer that this be made an option like IGNORE_DEV or
IGNORE_MAKEDEV or something? If you'd prefer that I can probably create
an appropriate patch, but this route seems more sensible to me, since no
config change will be needed if I decide to stop using devfs.
Index: mergemaster.sh
===
RCS file: /usr/cvs/src/usr.sbin/mergemaster/mergemaster.sh,v
retrieving revision 1.10
diff -u -r1.10 mergemaster.sh
--- mergemaster.sh 2000/08/13 19:32:19 1.10
+++ mergemaster.sh 2000/08/23 16:17:48
@@ -10,7 +10,7 @@
# $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.10 2000/08/13 19:32:19
gshapiro Exp $
-PATH=/bin:/usr/bin:/usr/sbin
+PATH=/bin:/usr/bin:/usr/sbin:/sbin
display_usage () {
VERSION_NUMBER=`grep "[$]FreeBSD:" $0 | cut -d ' ' -f 4`
@@ -421,6 +421,11 @@
*) rm ${TEMPROOT}/etc/motd
;;
esac
+
+ # Avoid trying to update MAKEDEV if /dev is on a devfs
+ if mount | grep -q "devfs on /dev "; then
+rm ${TEMPROOT}/dev/MAKEDEV ${TEMPROOT}/dev/MAKEDEV.local
+ fi
;; # End of the "RERUN" test
esac
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Installkernel
James Johnson wrote: > Having to specify > which kernel to build with the KERNEL= parameter seems to indicate that > people should be running GENERIC kernels all the time as it is the default. No, it seems to indicate that you should specify KERNEL=YOURKERNEL in make.conf. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Jens Schweikhardt wrote: > although there was much rejoicing, I think there's no need for a > new option to cp. Just use the toolbox, it's not too hard: > > (cat bigfilelist; echo destdir) | xargs cp > > Or even > > echo destdir >>bigfilelist > xargs cp < bigfilelist > > should do the trick. Err, neither of those will work if there are too many filenames for a single invokation of "cp" since none but the last will get the "destdir" argument. -- Ben Smithurst / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tail -f over NFS in -stable
Doug Barton wrote: > Blast from the past. This patch seemed reasonable to me at the time, but I > notice you didn't commit it. Any reason why? The issue has just come up > again on -questions. I seem to recall finding it had been fixed elsewhere, though unfortunately I can't remember the details. If it's still needed perhaps you could commit it, I have no time at the moment for FreeBSD stuff unfortunately, I might after June 2nd when my exams have finished and I've got nothing much else to do for 4 whole months. :-) -- Ben Smithurst / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wierd build error with -current
Andrew Reid wrote: > On 30 Jun 2001 09:39:15 -0700, Matthew Jacob wrote: > >> No, the build process is broken. It is in fact supposed to work, and >> worked last week, to build from a read-only /usr/src. > > How do you qualify this? The error you got was "Permission denied". The > build process will want to write files. Your filesystem is mounted as > read-only. All writes during a buildworld are supposed to go to /usr/obj, not /usr/src. -- Ben Smithurst / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: diskcheckd goes nuts on /dev/cd0
Steven G. Kargl wrote: > I updated a pre june 13th current to a july 3 current. > Ran mergemaster and installed /etc/diskcheckd.conf > without modification. Upon reboot I saw 1000s of the > following message streaming up the console: > > dscheck(cd0): bio_bcount 512 is not on a sector boundary (ssize 2048) > > Checking /var/log/messages I find (note date and machine name removed): > > diskcheckd[213]: /dev/cd0 has 2048 byte sectors, may cause minor problems > /boot/kernel/kernel: dscheck(cd0): bio_bcount 512 is not on a sector boun > dary (ssize 2048) > last message repeated 3 times > diskcheckd[213]: error reading 512 bytes from sector 0 on /dev/cd0 I was gonna commit a fix for this, but after reporting the problem DES never tested the patch I supplied. :-( I'll commit it later hopefully; se@ did test it and it worked for him... > As a side question, why is diskcheckd even looking at at /dev/cd0? Because my only current system when I was writing diskcheckd didn't have a CD drive so I didn't think to tell it not to check them. Sorry... I'll commit a patch soon that allows you to specify drives to exclude, and the default config file will exclude cd*, acd*, and md*. Also, you shouldn't get these errors soon even if diskcheckd did try to check the CD drive, because it will no longer read in 512 byte blocks. -- Ben Smithurst / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: diskcheckd goes nuts on /dev/cd0
Steven G. Kargl wrote: > Do you need to special case tape drives, floppies, zip, etc? If so, > you might want to exclude all devices except those that start with > da and ad. floppies, no: ben@ref5:~$ grep fd0 /var/run/dmesg.boot fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ben@ref5:~$ sysctl kern.disks kern.disks: ad0 i.e. floppies aren't included in kern.disks. Not sure about zip disks, and if tapes are included in kern.disks there's something very broken going on. ;-) -- Ben Smithurst / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: diskcheckd goes nuts on /dev/cd0
Antoine Beaupre (LMC) wrote: > Actually, I think that it should exclude all devices except those > > specified in the config file... As in "check only requested disks"... It's perfectly possible to do just that... phk wanted it to check all disks by default when I was writing it though, but this seems to be causing problems for people. :-( I think excluding CDs and MDs should solve most of the problems that have been reported, I'm not sure what the situation with zip/jaz type things is though. Are they included in kern.disks? Anyone? -- Ben Smithurst / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: diskcheckd goes nuts on /dev/cd0
Dag-Erling Smorgrav wrote:
> Ben Smithurst <[EMAIL PROTECTED]> writes:
>> I was gonna commit a fix for this, but after reporting the problem DES
>> never tested the patch I supplied. :-(
>
> I never got a patch.
Oh. Well I'll leave you to figure out why the attached mail, which I
sent two weeks ago, didn't get to you then.
2001-06-23 20:26:28 15Dt36-000Kos-00 <= [EMAIL PROTECTED]
H=strontium.shef.vinosystems.com [192.168.91.36] U=root P=esmtp S=4879
[EMAIL PROTECTED] for [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED]
2001-06-23 20:26:35 15Dt36-000Kos-00 => [EMAIL PROTECTED] R=lookuphost T=remote_smtp
H=flood.ping.uio.no [129.240.78.31] C="250 VAA79059 Message accepted for delivery"
--
Ben Smithurst / [EMAIL PROTECTED]
ok, I think I agree with phk that excluding drives should be done in the
config file somehow, something like
!md
!acd
!cd
... hack hack hack ...
Could you test the attached patch? It allows lines like the above in
diskcheckd.conf. Seems to work but ref5 is the only current machine I
have access to which is a bit of a pain for testing things.
Stefan wrote...
>> 2) The defaults make diskcheckd read 4KB per transaction from my
>> system disk. I think I'd rather have it reading 64KB/t at a
>> rate of 1 per 16 seconds. (Perhaps 32KB is a better size, in
>> order to not flush the drives cache, once per second ...)
>>
>> Reading 16, 32 or 64KB at a time should (except for cache effects)
>> cause minimally higher load per transaction than 4KB, and the
>> reduced transaction rate should drastically reduce the impact
>> on the system.
This shouldn't be too hard to implement, I'll see what I can do.
--
Ben Smithurst / [EMAIL PROTECTED]
Index: diskcheckd.c
===
RCS file: /home/ncvs/src/usr.sbin/diskcheckd/diskcheckd.c,v
retrieving revision 1.1
diff -u -r1.1 diskcheckd.c
--- diskcheckd.c2001/06/03 20:02:03 1.1
+++ diskcheckd.c2001/06/23 19:18:37
@@ -62,7 +62,7 @@
volatile sig_atomic_t got_sighup = 0, got_sigterm = 0;
-char **getdisknames(void);
+char **getdisknames(char **, int);
off_t dseek(struct disk *, off_t, int);
struct disk *readconf(const char *);
void getdisksize(struct disk *);
@@ -464,6 +464,8 @@
double dval;
long lval;
int linenum;
+ char **skip;
+ int numskip;
if ((fp = fopen(conf_file, "r")) == NULL) {
syslog(LOG_NOTICE, "open %s failure: %m", conf_file);
@@ -482,6 +484,37 @@
line++;
if (*line == '#' || *line == '\n' || *line == '\0')
continue;
+
+ /* First, if the line starts with '!', this is a disk name
+* to ignore. For example, '!md' will skip all '/dev/md*'
+* devices.
+*/
+ if (*line == '!') {
+ line++;
+ while (isspace(*line))
+ line++;
+ field = strsep(&line, " \t\n");
+ if (field == NULL || *field == '\0') {
+ syslog(LOG_NOTICE, "%s:%d: missing disk name",
+ conf_file, linenum);
+ continue;
+ }
+
+ numskip++;
+ if ((skip = reallocf(skip,
+ numskip * sizeof (*skip))) == NULL) {
+ syslog(LOG_NOTICE, "reallocf failure: %m");
+ exit(EXIT_FAILURE);
+ }
+
+ if ((skip[numskip-1] = strdup(field)) == NULL) {
+ syslog(LOG_NOTICE, "strdup failure: %m");
+ exit(EXIT_FAILURE);
+ }
+
+ continue;
+ }
+
fields = flags = 0;
while ((field = strsep(&line, " \t\n")) != NULL) {
if (*field == '\0')
@@ -602,7 +635,7 @@
onumdisks = numdisks;
for (dp = disks; dp < disks + onumdisks; dp++) {
if (strcmp(dp->device, "*") == 0) {
- for (np = np0 = getdisknames(); *np != NULL; np++) {
+ for (np = np0 = getdisknames(skip, numskip); *np != NULL;
+np++) {
odisks = disks;
if ((disks = reallocf(disks,
(numdisks + 1) * sizeof (*disks))) == NULL) {
@@ -746,10 +779,11 @@
* is returned.
*/
char **
-getdisknames(void) {
+getdisknames(
Re: fwd: [root: security check]
Steve Ames wrote:
>> virtual-voodoo.com changes in mounted filesystems:
>> 6d5
>> < /dev/ad1s1g/source ufs rw 0 2
>> 8a8
>>> /dev/ad1s1g /source ufs rw 0 2
>
> Got this is this morning's security check. This doesn't really
> show a change. The actual change was from normal to soft-updates.
>
> Any way this can show what actually changed? 'mount -p' (which
> /etc/security uses) doesn't show things such as soft-updates. In
> fact I don't see a single mount option that does show everything...
This is because the filesystem just moved in the mount list. I've seen
this a few times. The fix is trivial, I think:
--- security2000/08/07 09:08:35 1.41
+++ security2000/09/09 17:38:26
@@ -64,7 +64,7 @@
# Show changes in the way filesystems are mounted
#
[ -n "$ignore" ] && cmd="egrep -v ${ignore#|}" || cmd=cat
-if mount -p | $cmd > $TMP; then
+if mount -p | $cmd | sort > $TMP; then
if [ ! -f $LOG/mount.today ]; then
separator
echo "no $LOG/mount.today"
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
page fault in sched_ithd
A kernel from the latest sources gets a page fault in sched_ithd. DDB says: Stopped at: sched_ithd+0x3c:movl $0x01,0x14(%edi) Any ideas what's wrong? I'll try to get a serial console working at some point so hopefully I can get some more useful information. Here's the kernel config for that machine... ## $BCPS: conf/kern/LITHIUM,v 1.32 2000/08/27 17:02:20 ben Exp $ machine i386 cpu I486_CPU ident LITHIUM maxusers16 makeoptions DEBUG=-g options ATA_STATIC_ID options COMPAT_43 options DDB options DEVFS options FFS options FFS_ROOT options INET options INET6 options INVARIANTS options INVARIANT_SUPPORT options KTRACE options P1003_1B options SOFTUPDATES options SYSVSHM options UCONSOLE options _KPOSIX_PRIORITY_SCHEDULING device ata device atadisk device atkbd device atkbdc 1 device bpf device ep device ether device fdc device isa device loop device npx device pty device sc 1 device sio device splash device vga device vn 4 -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: page fault in sched_ithd
Ben Smithurst wrote: > A kernel from the latest sources gets a page fault in sched_ithd. DDB says: > > Stopped at: sched_ithd+0x3c:movl $0x01,0x14(%edi) > > Any ideas what's wrong? After poking around a bit with remote GDB, this seems to be caused by a stray IRQ 7, since irq == 7, ir == ithds[irq] == NULL, ir->foo == BOOM. The attached rather crude patch has "fixed" the problem for now, but does anyone have any suggestions for a real fix? -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D Index: ithread.c === RCS file: /usr/cvs/src/sys/i386/isa/ithread.c,v retrieving revision 1.1 diff -u -r1.1 ithread.c --- ithread.c 2000/09/07 01:32:48 1.1 +++ ithread.c 2000/09/09 19:58:46 @@ -144,6 +144,9 @@ } #endif + if (ir == NULL) + return; + /* * Set it_need so that if the thread is already running but close * to done, it will do another go-round. Then get the sched lock
Re: page fault in sched_ithd
Bosko Milekic wrote: >I catch this page fault (described in topic) following an: > >`ifconfig de0 down' > >Unfortunately, I don't have much more information to provide for now. >I'm in the middle of debugging something else. More info can be provided >on request (let me know if you want to look at it and cannot reproduce >it). Sources of last friday (evening). ifconfig(8) is what does it for me too. It's ifconfig(8) at boot time though, so I'm not sure exactly what arguments it has or what it's doing at the time. Mike wrote: >> Isn't a stray IRQ a hardware glitch? If so, I'd say that logging it >> and then ignoring it would be the right thing. If people think so then I'll improve my patch a bit to do this. I agree, unless there's a better way to fix the problem. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: page fault in sched_ithd
Ben Smithurst wrote:
> Greg Lehey wrote:
>
>> Sorry, I missed the beginning of this. Could somebody send me the
>> patch? I'd assume that a relatively simple check would handle the
>> issue, based on what I've seen here.
>
> I've lost the actual patch, I basically just added
>
> if (ir == NULL)
> return;
>
> in sched_ithd() before it ever de-references ir. I've some up with a
> slightly bigger patch which adds stray IRQ logging too, but I haven't
> tested that yet.
Here's the slightly bigger patch, which seems to be working fine so far.
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
Index: ithread.c
===
RCS file: /usr/cvs/src/sys/i386/isa/ithread.c,v
retrieving revision 1.1
diff -u -r1.1 ithread.c
--- ithread.c 2000/09/07 01:32:48 1.1
+++ ithread.c 2000/09/10 12:57:59
@@ -95,6 +95,8 @@
SYSINIT(start_softintr, SI_SUB_SOFTINTR, SI_ORDER_FIRST, start_softintr, NULL)
+#defineMAX_STRAY_LOG 5
+
/*
* Schedule a heavyweight interrupt process. This function is called
* from the interrupt handlers Xintr.
@@ -104,6 +106,7 @@
{
int irq = (int) cookie; /* IRQ we're handling */
ithd *ir = ithds[irq]; /* and the process that does it */
+ static int straycount[NHWI];
/* This used to be in icu_vector.s */
/*
@@ -144,6 +147,20 @@
}
#endif
+ if (ir == NULL) {
+ if (irq < NHWI) {
+ if (straycount[irq] < MAX_STRAY_LOG) {
+ printf("stray irq %d\n", irq);
+ if (++straycount[irq] == MAX_STRAY_LOG)
+ printf("got %d stray irq %d's: "
+ "not logging anymore\n",
+ MAX_STRAY_LOG, irq);
+ }
+ return;
+ }
+ panic("sched_ithd: ithds[%d] == NULL", irq);
+ }
+
/*
* Set it_need so that if the thread is already running but close
* to done, it will do another go-round. Then get the sched lock
Re: page fault in sched_ithd
Greg Lehey wrote: > Sorry, I missed the beginning of this. Could somebody send me the > patch? I'd assume that a relatively simple check would handle the > issue, based on what I've seen here. I've lost the actual patch, I basically just added if (ir == NULL) return; in sched_ithd() before it ever de-references ir. I've some up with a slightly bigger patch which adds stray IRQ logging too, but I haven't tested that yet. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How to use RSA with USA_RESIDENT=NO?
Jun Kuriyama wrote: > After installworld, I can not use ssh with RSA. Does someone know how > to fix this problem? > > - > % ssh white > ssh: no RSA support in libssl and libcrypto. See ssl(8). > Disabling protocol version 1 > DH_generate_key > % This is going to sound weird, but did you rebuild the kernel? I'm *sure* I had my system at one point such that ssh worked with the new kernel but not with the old one. I'm not sure why, perhaps I was dreaming. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: call for testers: init securelevel patch
Leif Neland wrote:
> How is that done?
> Will gdb not attach to init, or will init not let gdb attach?
The kernel won't let GDB attach. Look at the code for ptrace()...
/* can't trace init when securelevel > 0 */
if (securelevel > 0 && p->p_pid == 1)
return EPERM;
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
Poul-Henning Kamp wrote:
> I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
> is bogus. It looks like something which happened "because we can" more
> than something which has a legitimate need.
You think adding a hack to every program to support "-" to mean
stdout/stdin is better? It seems to be that saying "/dev/stdin" when
you mean stdin is better than saying "-" and hoping the application
handles that correctly. Of course many programs will read stdin by
default, and write stdout by default, but that doesn't help when you
want to read more than one file, one of which is stdin.
> If anything I would propose we ditch it...
And break loads of scripts at the same time?
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
Garrett Wollman wrote:
> [/dev/stdin] also helps when bogus programs refuse to read from the
> standard input.
Or if you want to read more than one file, one of which is standard input.
e.g.
gzip -dc oldlogs.*.gz | cat /dev/stdin todays-log | log-analyzer ...
Of course that will work with "-" instead of "/dev/stdin" but I
personally think it's the "-" hack to mean stdin/stdout which should be
abolished, not /dev/std{in,out,err}. No doubt others will disagree.
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: page fault in sched_ithd
Bruce Evans wrote:
> On Sat, 9 Sep 2000, Ben Smithurst wrote:
>
>> After poking around a bit with remote GDB, this seems to be caused by a
>> stray IRQ 7, since irq == 7, ir == ithds[irq] == NULL, ir->foo == BOOM.
>>
>> The attached rather crude patch has "fixed" the problem for now, but
>> does anyone have any suggestions for a real fix?
>
> The stray interrupt handler needs to have a thread, or stray interrupts
> need to be handled as traps. Stray interrupts are more like NMIs than
> normal interrupts, and NMIs are already (mis)handled as traps.
OK, but would you or anyone else object to the attached patch as a
temporary fix, at least? Page-faulting almost immediately is not
particularly good. The patch doesn't seem to have had any negative
effects so far.
Who are the main people responsible for the SMPng stuff anyway? jasone
and jhb seem to have been involved a bit, so I cc'd them as well.
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
Index: ithread.c
===
RCS file: /usr/cvs/src/sys/i386/isa/ithread.c,v
retrieving revision 1.3
diff -u -r1.3 ithread.c
--- ithread.c 2000/09/13 18:33:23 1.3
+++ ithread.c 2000/09/14 22:06:44
@@ -95,6 +95,8 @@
SYSINIT(start_softintr, SI_SUB_SOFTINTR, SI_ORDER_FIRST, start_softintr, NULL)
+#defineMAX_STRAY_LOG 5
+
/*
* Schedule a heavyweight interrupt process. This function is called
* from the interrupt handlers Xintr.
@@ -103,6 +105,7 @@
sched_ithd(void *cookie)
{
int irq = (int) cookie; /* IRQ we're handling */
+ static int straycount[NHWI];/* count of stray IRQs */
struct ithd *ir = ithds[irq]; /* and the process that does it */
/* This used to be in icu_vector.s */
@@ -144,6 +147,21 @@
}
#endif
+ /* XXX: quick fix to avoid page fault until this is done properly. */
+ if (ir == NULL) {
+ if (irq < NHWI) {
+ if (straycount[irq] < MAX_STRAY_LOG) {
+ printf("stray irq %d\n", irq);
+ if (++straycount[irq] == MAX_STRAY_LOG)
+ printf("got %d stray irq %d's: "
+ "not logging anymore\n",
+ MAX_STRAY_LOG, irq);
+ }
+ return;
+ }
+ panic("sched_ithd: ithds[%d] == NULL", irq);
+ }
+
/*
* Set it_need so that if the thread is already running but close
* to done, it will do another go-round. Then get the sched lock
Re: Kernel builds to wrong location?
Mike Meyer wrote: > I cvsupped and rebuilt earlier to today, only to find that the kernel > was installed as /boot/kernel/kernel instead of > /boot/kernel/kernel.ko. While fixing this was trivial, it was a bit of > a surprise. > > Is this a bug, or did I happen to catch the world in a state of change > described in a cvs-all or current message I missed or hadn't read yet? This is an intentional change, and was discussed on freebsd-arch. I'm not sure why you needed to fix anything though, it should have worked anyway. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
"No buffer space available" errors
.c 110: sendto 192.168.91.47: No buffer space available Sep 18 10:51:38 lithium dhclient: send_packet: No buffer space available Sep 18 10:54:45 lithium dhclient: send_packet: No buffer space available Sep 18 10:58:42 lithium dhclient: send_packet: No buffer space available Sep 18 11:03:24 lithium last message repeated 2 times Sep 18 11:04:56 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 11:05:11 lithium dhclient: send_packet: No buffer space available Sep 18 11:05:49 lithium dhclient: send_packet: No buffer space available Sep 18 11:06:54 lithium dhclient: send_packet: No buffer space available Sep 18 11:17:31 lithium last message repeated 15 times Sep 18 11:18:25 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 11:18:57 lithium dhclient: send_packet: No buffer space available Sep 18 11:21:25 lithium dhclient: send_packet: No buffer space available Sep 18 11:25:03 lithium dhclient: send_packet: No buffer space available Sep 18 11:31:11 lithium last message repeated 12 times Sep 18 11:31:54 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 11:32:03 lithium dhclient: send_packet: No buffer space available Sep 18 11:33:26 lithium dhclient: send_packet: No buffer space available Sep 18 11:35:29 lithium last message repeated 5 times Sep 18 11:44:40 lithium last message repeated 17 times Sep 18 11:45:23 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 11:45:24 lithium dhclient: send_packet: No buffer space available Sep 18 11:46:11 lithium dhclient: send_packet: No buffer space available Sep 18 11:48:17 lithium last message repeated 6 times Sep 18 11:57:44 lithium last message repeated 22 times Sep 18 11:58:25 lithium dhclient: send_packet: No buffer space available Sep 18 11:58:52 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 11:59:35 lithium dhclient: send_packet: No buffer space available Sep 18 12:01:59 lithium dhclient: send_packet: No buffer space available Sep 18 12:05:31 lithium dhclient: send_packet: No buffer space available Sep 18 12:09:04 lithium dhclient: send_packet: No buffer space available Sep 18 12:12:21 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 12:15:27 lithium dhclient: send_packet: No buffer space available Sep 18 12:22:31 lithium dhclient: send_packet: No buffer space available Sep 18 12:25:27 lithium /boot/kernel/kernel: stray irq 7 Sep 18 12:25:30 lithium /boot/kernel/kernel: stray irq 7 Sep 18 12:25:30 lithium dhclient: New IP Address(ep0): 192.168.91.35 Sep 18 12:25:31 lithium dhclient: New Subnet Mask (ep0): 255.255.255.240 Sep 18 12:25:31 lithium dhclient: New Broadcast Address(ep0): 192.168.91.47 Sep 18 12:25:31 lithium dhclient: New Routers: 192.168.91.33 Sep 18 12:25:52 lithium timed[27809]: slave to scientia.demon.co.uk Copyright (c) 1992-2000 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.0-CURRENT #0: Sun Sep 17 13:02:24 BST 2000 [EMAIL PROTECTED]:/current/obj/current/src/sys/LITHIUM Timecounter "i8254" frequency 1193182 Hz CPU: AMD Enhanced Am486DX4 Write-Through (486-class CPU) Origin = "AuthenticAMD" Id = 0x484 Stepping = 4 Features=0x1 real memory = 16777216 (16384K bytes) avail memory = 13979648 (13652K bytes) Preloaded elf kernel "kernel" at 0xc029b000. Preloaded elf module "random.ko" at 0xc029b09c. npx0: on motherboard npx0: INT 16 interface isa0: on motherboard ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x90 on isa0 sio0: type 16450 sio1 at port 0x2f8-0x2ff irq 3 flags 0x10 on isa0 sio1: type 16450 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ep0: <3Com 3C509-Combo EtherLink III> at port 0x300-0x30f irq 10 on isa0 ep0: Ethernet address 00:a0:24:eb:f4:a2 ad0: 407MB [898/15/62] at ata0-master using BIOSPIO Mounting root from ufs:/dev/ad0s1a -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'host' command with CNAMEs
Sean Kelly wrote: > I've got two machines here, one running 4.1-STABLE (from Aug 3) and a > 5.0-CURRENT (from Aug 10) and both of them show the same issue. When > you use the 'host' command to resolve a CNAME, it will show all the A > records twice: The problem is older than that: ben@magnesium:~$ host www www.scientia.demon.co.uk is a nickname for magnesium.scientia.demon.co.uk magnesium.scientia.demon.co.uk has address 192.168.91.34 magnesium.scientia.demon.co.uk has address 192.168.91.34 ben@magnesium:~$ uname -rsm FreeBSD 3.4-STABLE i386 ISTR when the problem first cropped up it was briefly mentioned, but evidently no-one could be bothered to fix it at the time. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
Crist J. Clark wrote: > Anyone have a good reason why everyone _must_ have src-release to > buildworld? No. Sorry. I kind of assumed people doing buildworlds would just get src-all. Pointy hat this way please... As I said in a reply to a private mail to Crist, I'll commit a fix for this tonight and MFC it soon. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
Crist J. Clark wrote: > On Thu, Jan 11, 2001 at 11:52:43AM -0800, John Baldwin wrote: > >> Erm, many things live in both /stand and other places: >> >>> ll /stand/ | wc -l >> 35 >>> ll /stand/rm /bin/rm >> -r-xr-xr-x 2 root wheel 255736 Jan 9 08:17 /bin/rm >> -r-xr-xr-x 31 root wheel 1729520 Jul 28 07:32 /stand/rm > > I am not clear what you are saying here. Only sysinstall lives in > /stand, yeah, but it can be used as many things. If invoked as "rm" sysinstall behaves just like the real rm, it happens to be one big binary. > Well, /stand/rm is not _really_ rm at all, but I get the point. I > guess the only question is whether to put it in /sbin or /usr/sbin. I > think /sbin makes sense (so it is bootable), but it is 1.6MB of > /-bloat... But from another thread about making 250MB the default / > size, I guess few care too much about that anymore. I'd prefer it in /usr/sbin, some of my root partitions are only 32MB, and that's not big enough at the moment. If your /usr is hosed to the extent you can't mount it you've probably got more problems than sysinstall will help you with. But that's just my opinion. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 bike shed
Steve Kargl wrote: > I've already filed a PR about this. And, yes > I know people have discussed this the last day or > two, but until the color is chosen can someone > please remove the the installation of sysinstall.8 > from src/share/man/man8/Makefile. ugh, sorry. I forgot to fix that. :-( ... Fixed now, I hope. If this fixes it for you I'll MFC it. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Spontaneous reboots
ple = 3, master/slave recovery = 1 intel_piix_status: secondary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 1 status: 04 from port: f00a found-> vendor=0x5333, dev=0x8811, revid=0x54 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[0]: type 1, range 32, base e000, size 26 vga0: rev 0x54 int a irq 11 on pci0.10.0 Probing for devices on the ISA bus: atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa sc0 on isa sc0: fb0 kbd0 sc0: VGA color <8 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio2: irq maps: 0x1 0x9 0x1 0x1 sio2 at 0x3e8-0x3ef irq 3 on isa sio2: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): , LBA, 32-bit, multi-block-16 wd0: 1628MB (3335472 sectors), 827 cyls, 64 heads, 63 S/T, 512 B/S wd0: ATA INQUIRE valid = 0003, dmamword = 0407, apio = 0003, udma = wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (wd2): , LBA, 32-bit, multi-block-16 wd2: 4892MB (10018890 sectors), 623 cyls, 255 heads, 63 S/T, 512 B/S wd2: ATA INQUIRE valid = 0007, dmamword = 0407, apio = 0003, udma = 0007 wdc1: unit 1 (atapi): , removable, dma, iordy acd0: drive speed 1375KB/sec, 86KB cache acd0: supported read types: CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked npx0 flags 0x1 on motherboard npx0: INT 16 interface vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3b0-0x3df, crtc:0x3d4, mem:0xa 0x2 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xf00b8000 size:32k gran:32k, buf:0x0 size:0k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff imasks: bio c008c040, tty c003001a, net c006 BIOS Geometries: 0:03393f3f 0..825=826 cylinders, 0..63=64 heads, 1..63=63 sectors 1:026dfe3f 0..621=622 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. IP packet filtering initialized, divert disabled, rule-based forwarding disabled, logging limited to 5000 packets/entry bpf: tun0 attached bpf: lo0 attached Considering FFS root f/s. changing root device to wd0s2a wd0s1: type 0x6, start 63, end = 2088575, size 2088513 : OK wd0s2: type 0xa5, start 2088576, end = 2153087, size 64512 : OK wd0s3: type 0xa5, start 2153088, end = 3334463, size 1181376 : OK wd2s1: type 0xa5, start 63, end = 289169, size 289107 : OK wd2s2: type 0xa5, start 289170, end = 6554519, size 6265350 : OK wd2s3: type 0xa5, start 6554520, end = 9687194, size 3132675 : OK wd2s4: type 0xa5, start 9687195, end = 10008494, size 321300 : OK ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates splash: image decoder found: green_saver -- Ben Smithurst b...@scientia.demon.co.uk send a blank message to ben+...@scientia.demon.co.uk for PGP key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Spontaneous reboots
Brian Feldman wrote: > It could. Ahem... are you absolutely certain there are no messages in > /var/log/messages that happen before the reboot? Completely certain, there was nothing in /var/log/all either (which as the name suggests, all syslog messages are written to). -- Ben Smithurst b...@scientia.demon.co.uk send a blank message to ben+...@scientia.demon.co.uk for PGP key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users
Dmitry Valdov wrote: > Is there Any way to fix it? Yes. Limit the number of processes they can have in /etc/login.conf. If they've already done it once, appropriate use of a baseball bat may make them think twice about doing it again. -- Ben Smithurst b...@scientia.demon.co.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
