Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
In response to Ivan Voras ivo...@freebsd.org: Thomas Backman wrote: On Nov 30, 2009, at 9:47 AM, O. Hartmann wrote: I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O shows in contrast to all claims that have been to be improoved the opposite. Corrected link: http://www.phoronix.com/scan.php?page=articleitem=freebsd8_benchmarksnum=1 And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The only reason I'm not switching from Linux. :( All operating systems were left with their default options during the installation process... It's common knowledge that the default value for vfs.read_max is non- optimal for most hardware and that significant performance improvements can be made in most cases by raising it. While it would be nice if FreeBSD shipped with a more performant default setting, it would also be nice if mindless benchmark drones would quit assuming that every system ships pre-configured to perform optimally in their benchmarks. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
In response to Robert Huff roberth...@rcn.com: Bill Moran writes: It's common knowledge that the default value for vfs.read_max is non- optimal for most hardware and that significant performance improvements can be made in most cases by raising it. Documentation/discussion where? http://www.google.com/search?q=freebsd+vfs.read_max ... although it doesn't seem to be officially documented anywhere. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Signing Request
In response to J. Hellenthal jhellent...@gmail.com: If you do not need to pgp/gpg sign email message to the lists please don't. What is the purpose of your message? The above statement is self-cancelling. If I go to the trouble to establish a pgp/gpg key, I will sign every single message that I send out. The purpose of this is to differentiate actual messages from me from messages that may impersonate me. I know I probably don't have your pgp public key and a lot more users probably do not either. Please use your best judgment. While you're free to voice your opinion, I don't understand your purpose in spamming three mailing lists with this demand. What problem are you trying to solve? -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: issues with Intel Pro/1000 and 1000baseTX
In response to James Tanis jta...@mdchs.org: I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in question is: em1: Intel(R) PRO/1000 Network Connection Version - 6.7.3 port 0x2020-0x203f mem 0xd806-0xd807,0xd804-0xd805 irq 19 at device 0.1 on pci4 what we get after boot is: em1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:30:48:xx:xx:xx inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX full-duplex) status: active The problem is that the NIC refuses to connect at 1000baseTX. It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX on ports 23 and 24. This particular computer is connected on port 24. I have a much older end user system which uses the same card (but earlier revision), runs Windows XP and is plugged in to port 23. The end user system has no problem connecting at 1000baseTX. I have of course tried switching ports. Attempting to force 1000baseTX via: ifconfig em1 media 1000baseTX mediaopt full-duplex gets me: status: no carrier After forcing the NIC to go 1000baseTX the LEDs on the backpane are both off. I can only come to the conclusion that this is a driver issue based on previous experience and the simple fact that the end user system is capable of connecting at 1000baseTX. Anybody have any suggestions? I'm hoping I'm wrong. I'd rather not do an in-place upgrade, this is a production system and the main gateway for an entire school, when I do not even know for sure whether this will fix the problem. It's worth it to me though, having a 1000baseTX uplink from the switch would remove a major bottleneck for me. While it's _possible_ that this is a driver issue, it's much more likely (in my experience) that it's a mismatch between the two network devices (the HP and the NIC). Try forcing on both ends (I assume the Procurve will allow you to do that). One thing I've seen consistently is that if you force the speed/duplex on one end, the other end will still try to autoneg, and will end up with something stupid like 100baseT/half-duplex, or will give up and disable the port. Also, try autoneg on both ends. Make absolutely sure the Procurve is set to autoneg. Replace the cable. If the cable is marginal, autoneg will downgrade the speed to ensure reliability. Use a cable that you know will produce 1000baseTX because you've tested it on other systems. Try switching out the NIC. Manufacturing QA isn't 100% reliable, sometimes you get a card that's just flaky. Hope this helps. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: getting garbage faster using FreeBSD?
In response to Volker [EMAIL PROTECTED]: On 02/19/07 20:51, Kris Kennaway wrote: On Mon, Feb 19, 2007 at 08:40:37PM +0100, Volker wrote: The tape sits there since 48 hours writing a block of data every other minute and still didn't fill up the tape completely. The system this is running on is a P-4 3GHz machine using FreeSBIE 2.0 (6.2-RELEASE based). I suspect this to be a slow /dev/random. This sounds odd to me, I get 18-20MB/sec sustained read performance from /dev/random on this 2GHz system, which is probably faster than your tape write speed. Hmm, so this might be the tape drive(r)? I'll check this out as soon as I'm going to write to hard disk. I'm going to make some tests with /dev/random to get the real speed. Are you actually using /dev/random and not /dev/urandom? /dev/random is military grade random data. It will block if it feels that it hasn't gathered enough entropy to satisfy your request. It will never provide random data at any reasonable speed, but it will provide high-quality random data. If you need lost of random data, use /dev/urandom, which provides data that _may_ be predictable under some circumstances, but will provide it at a decent rate of speed. Is there any chance to speed up /dev/random? Would a hifn accelerator card help here to get FreeBSD produce garbage faster? Have you taken a look at DBAN for the drives? I don't know if DBAN will work on the tapes, though. http://dban.sourceforge.net/ As there is medical data on all media I really need garbage (/dev/zero wouldn't be enough for data security as this might get recovered). Neither would a single pass with /dev/random, but you presumably knew this. Yes, I know... I would like to run 5 or more passes if it's not that slow. Do you think playing with randoms' sysctl interface might influence performance? Does /dev/random automatically re-seed from time to time or is it seeded at boot time only? -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Your Recent Trade Show Results
In response to Trond Endrestøl [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 plz! go away with all your junk. I reported it to spamcop.net ... as usual. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getting garbage faster using FreeBSD?
In response to Kris Kennaway [EMAIL PROTECTED]: On Tue, Feb 20, 2007 at 09:12:38AM -0500, Bill Moran wrote: In response to Volker [EMAIL PROTECTED]: On 02/19/07 20:51, Kris Kennaway wrote: On Mon, Feb 19, 2007 at 08:40:37PM +0100, Volker wrote: The tape sits there since 48 hours writing a block of data every other minute and still didn't fill up the tape completely. The system this is running on is a P-4 3GHz machine using FreeSBIE 2.0 (6.2-RELEASE based). I suspect this to be a slow /dev/random. This sounds odd to me, I get 18-20MB/sec sustained read performance from /dev/random on this 2GHz system, which is probably faster than your tape write speed. Hmm, so this might be the tape drive(r)? I'll check this out as soon as I'm going to write to hard disk. I'm going to make some tests with /dev/random to get the real speed. Are you actually using /dev/random and not /dev/urandom? /dev/random is military grade random data. It will block if it feels that it hasn't gathered enough entropy to satisfy your request. It will never provide random data at any reasonable speed, but it will provide high-quality random data. If you need lost of random data, use /dev/urandom, which provides data that _may_ be predictable under some circumstances, but will provide it at a decent rate of speed. Not true in a post 4.x world, they are symlinks and both military grade with non-blocking semantics. Interesting ... I could swear I recently had a problem with /dev/random blocking on a 6.X system ... I'll have to take another look. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
pmap panic message: can someone take a look at this PR?
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108121 -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2 buildworld fails without NO_CXX=YES
In response to archon [EMAIL PROTECTED]: I've just updated the sources in FreeBSD 6.2-RELEASE and tried to rebuild world. With option 'NO_CXX=YES' in /etc/make.conf world compiled successful, if this option not added 'make buildworld' failed. 'make buildworld' fails: groff is written in C++. If you can live without groff, there may be a NO_GROFF knob you could tweak. However, it looks like openssl is also written in C++ as well. If you can live without those two, it should be doable. I'm not sure how practical a system without C++ is in the modern world. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-stable Digest, Vol 190, Issue 5
In response to Pieter Migo [EMAIL PROTECTED]: please unsubscribe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failover-HA-Setup
In response to Vladimir Botka [EMAIL PROTECTED]: Richard píše v st 17. 01. 2007 v 13:47 +0100: Hi there! I am looking for a solution for a small problem regarding a high availability setup. I am running heartbeat on a STABLE-system, the failover works fine for IP-adresses and I am able to see that a '/usr/local/etc/rc.d/mysql-server start' statement is issued. BUT since the variables for mysql are not set in rc.conf (Otherwise it would be started at startup), it isn't starting at all. So my question: How to set those rc.conf-variables in order to start services in such an setup? Or is there a better solution? Hello, just modify the /usr/local/etc/rc.d/mysql-server script. Cheers, -vlado Then have to fsck around with diffs at every upgrade? Not the approach I would take. And please don't top-post. I don't remember the details of how heartbeat works, but you should be able to set the required variables and export them into the environment prior to calling the mysql-server script. If not, just create a wrapper script that sets the required variables then calls the rc script. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rsync write fails on descriptor 3
In response to Ilya Vishnyakov [EMAIL PROTECTED]:
Hello, I'm in trouble with rsync. Some people think that this problem
is freebsd related:
I use rsync to synchronize 2 servers (rsync versions are same on both
machines).
Most of the directories are copied fine, however, some huge ones fail
and produce
some strange output.
Rsync guys detected this problem as:
So the write fails on descriptor 3, which I think is the socket to the
daemon. I Googled FreeBSD write EPERM and turned up the
following FreeBSD bug, which you might be seeing:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern%2F95559
I use FreeBSD m.mycompany.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #2:
here is the detailed output of the error (I tried to run rsync in
different modesm however, with no luck):
truss rsync -atlrpogHvv me at myip::public
- - - --password-file=/root/rsync_pass /home/public
ARRIVALS/ARRV112806.xls,0x7fffc620) ERR#2 'No such file or directory'
lstat(Company/General/2006 OLD
ARRIVALS/ARRV112906.xls,0x7fffc620) ERR#2 'No such file or directory'
select(5,{4},{3},0x0,{60 0}) = 1 (0x1)
write(3,0xc2,4092) ERR#1 'Operation not permitted'
rsync: writefd_unbuffered failed to write 4092 bytes [generator]:
Operation not permitted (1)write(2,0x7fffa4f0,93) = 93 (0x5d)
write(2,0x80083ce67,1) = 1 (0x1)
sigaction(SIGUSR1,{ SIG_IGN
0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t
},0x0) = 0 (0x0)
sigaction(SIGUSR2,{ SIG_IGN
0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t
},0x0) = 0 (0x0)
getpid() = 42660 (0xa6a4)
kill(0xa6a5,0x1e)= 0 (0x0)
rsync error: received SIGUSR1 (code 19) at main.c(1095) [receiver=2.6.8]
rsync error: error in rsync protocol data stream (code 12) at
io.c(1124) [generator=2.6.8]write(2,0x7fffa480,90) = 90 (0x5a)
write(2,0x80083ce67,1) = 1 (0x1)
SIGNAL 20 (SIGCHLD)
SIGNAL 20 (SIGCHLD)
wait4(0x,0x7fffb394,0x1,0x0) = 42661 (0xa6a5)
wait4(0x,0x7fffb394,0x1,0x0) ERR#10 'No child
processes'
sigreturn(0x7fffb3b0)= 524288 (0x8)
exit(0xc)
process exit, rval = 3072
here is my share from the rsync.conf:
- -
uid = 0
gid = 0
hosts allow = myhostsips
secrets file =/usr/local/myfile
auth users = ilya
[public]
path = /home/public/
comment = home filesystem
auth users = ilya
uid = root
read only = yes
secrets file =/usr/local/myfile
- ---
Please advice me what to do next. Thank you in advance.
Ilya.
1) Actually read the PR
2) Have you tried the workaround of removing the skip and/or scrub
directives to pf?
3) Are you even using pf? The PR involved is related to pf, and it
appears as if the problem was related to an incorrect pf configuration,
and _not_ a bug in FreeBSD.
Someone should follow up on that PR and see if the OP ever fixed the
problem.
I don't see as how this belongs on FreeBSD-stable. You might do better
to follow up on that PR, if you can confirm that your problem goes away
with the removal of pf rules as well.
--
Bill Moran
Collaborative Fusion Inc.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Communicating with the public (was Re: Possibility for FreeBSD 4.11 Extended Support)
In response to Adrian Chadd [EMAIL PROTECTED]: (I have the same problem with the Squid project. Lots of people want Squid to do everything, noone's willing to hire programmers to fix up Squid to do these things and release the work back to the public. Then people complain that Squid doesn't have 21st century features. Grr. Sometimes I think we in the Squid project need better PR..) You probably do. In my experience, most F/OSS projects need better PR. It's not that we (as a group) are poor communicators. Within the devel teams and so forth, we seem to communicate just fine. The fact is that when crossing cultural boundaries, we usually fall short. This has come up time and again as the complaint that FreeBSD isn't doing well with business and so forth, but it comes up in other areas as well that are more subtle. The lion's share of our community work _very_ well with information. We have to, we're buried in it. I know I sort through a couple hundred emails each day. On the flip side, the average Joe doesn't do so well. We see side effects of this when people post with crappy subject lines or no subject lines. We see bug reports that are completely useless because there's nowhere near enough information to actually do anything about it. Did it ever occur to you that these people have as much trouble understanding stuff that they receive as they do communicating their own thoughts. Consider, also, that those folks are an extreme end of the scale. A couple of years ago, a guy tried to explain to me how you have to deal with people. He laid it out in steps: 1) Tell them. 2) Tell them again. 3) Tell them that you told them. 4) Remind them that you told them. 5) Tell them that you reminded them that you told them. 6) ... The point being that you really have to use The Big Hammer to get your point across. It's the same reason we have to see a McDonalds commercial _every_single_commercial_break_! (egad I hate McDonalds) Anyway ... in most of the F/OSS communities I'm involved with, we're under the mistaken idea that we can make an announcement and people will see/hear it. Usually you have to make an announcement 6 or 7 times, worded differently each time, before it really hits home with the masses. I could be wrong, but I get the impression that this whole EOL issue with 4.x is partly a result of not reminding people when the EOL date for 4.x is every 5 minutes. The result is that it's just hitting home for a lot of people now that it's the 11th hour. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Communicating with the public (was Re: Possibility for FreeBSD 4.11 Extended Support)
In response to Adrian Chadd [EMAIL PROTECTED]: On 22/12/06, Bill Moran [EMAIL PROTECTED] wrote: I could be wrong, but I get the impression that this whole EOL issue with 4.x is partly a result of not reminding people when the EOL date for 4.x is every 5 minutes. The result is that it's just hitting home for a lot of people now that it's the 11th hour. The trouble Squid had was its push to a new codebase (2.5 - 3.0) without adequately considering what users wanted. After all, if users don't get any of what they want then there's probably no chance of any paid work out of it.. Users cried for new features but with the stability of the existing codebase. In the end the developers caved and provided Squid-2.6 which seems to have begun reinvigorating the project somewhat. I'm not saying thats the case here, but all the people I've seen complain about 4.11 isn't because the upgrade path isn't -there-, its because the upgrade path doesn't give them stability. People then answer but its stable for mee!; both sides don't end up agreeing. tsk .:) Agreed. The problem is that I'm _not_ seeing any problems. The result of this is: 1) I'm not motivated to do anything about it. 2) I don't even know what to do if I was motivated. Until this week, I didn't even know any stability problems existed in post 4.x systems until today, so I _couldn't_ do anything about it. I'm guessing you could say #1 and #2 for any number of developers. There are rumblings about stability issues. The problem is there's very little helpful information. My prediction is that these problems will persist until one of the following conditions is met: 1) Someone knowledgeable just gets interested and starts working on the problem. 2) Someone who needs these features puts some effort in to gathering some truly useful information. 3) Someone who needs these features decides to pay someone knowledgeable to work on it. It's interesting that another party who posted to the list earlier was complaining about how his stability issues went unfixed, yet he had _zero_ useful information on where the problem was originating from. After 5 minutes of searching the PR database, I found an open issue regarding lockups with quotas. This other guy never connected the dots? Never did any diagnosis? Never added his $.02 to the open PR? _That_ is why these things aren't getting fixed. Again, the thing that _absolutely_ boggles my mind is that these folks want to divert developer support _away_ from fixing these issues and to supporting legacy software. Quit bitching and go use Dragonfly. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cached file read performance with 6.2-PRERELEASE
In response to Mark Kirkwood [EMAIL PROTECTED]:
JoaoBR wrote:
I am not convinced that this kind of test is of any value for comparing
systems at all because there are too much factors involved - unless the
competitors are installed on identical hardware. On the other side I think
it
is usefull to compare tweaked settings on a particular machine. For example
you may change fsize/bsize of the filesystem or any other and can compare
this results then.
Exactly, that's why I did the comparison - I think you missed the part
where I mentioned the 2 systems were *identical* with respect to cpus,
memory, mobo - in fact even the power supplies are identical too! the
only differences are that the Gentoo system has a different RAID
controller from the FreeBSD one (a cheaper one in fact), and the FreeBSD
system has larger capacity disks (slightly newer variants, same brand!)
given this comparison is about *cached* read rates, the RAID controllers
and disks are not significant I think.
Specifically:
Gentoo :
- Supermicro P3TDER
- 2xSL5QL 1.26 GHz PIII
- 2xKingston PC133 RCC Registered 1GB DIMMS
- Promise TX4000 4x Maxtor plus 8 ATA-133 7200 40G
FreeBSD
- Supermicro P3TDER
- 2xSL5QL 1.26 GHz PIII
- 2xKingston PC133 RCC Registered 1GB DIMM
- 3Ware 7506 4x Maxtor Plus 9 ATA-133 7200 80G
In fact, to indulge your skepticism ('cause I think this is a real issue
worth sorting out), I booted the FreeBSD system with a Gentoo livecd
and ran the same tests there... and guess what - identical results to
the installed Gentoo system...so... errm - *my* experimental method is
sound...so how about we just get together and see how to make FreeBSD
kick Gentoo eh?
I looks like your testing methodology is sound, and that you've
uncovered an issue worth pursuing.
I recommend starting this thread up on [EMAIL PROTECTED] The folks
on that list are more likely to jump all over this kind of thing.
You might also find helpful people on the current@ and hackers@ lists.
My gut tells me that any changes that can improve this will be large
enough that they'll have to go through CURRENT first, then get MFCed
back in to 6.
Keep in mind also that the holidays tend to slow things down, it might
be early January before you get a lot of people looking at this issue
seriously.
--
Bill Moran
Collaborative Fusion Inc.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Block IP
In response to Suhail Choudhury [EMAIL PROTECTED]: Hi all, I'm using IPFW as my firewall. What's the easiest way to add an IP such as 80.192.49.213 to block it? ipfw add deny all from 80.192.49.213 to me Although you need to take into consideration your existing IPFW rules, as this will not work if a previous rule allows the connection. Also how do I block out IPs after a certain number of invalid login attempts to prevent brute forcing? There are a number of ports that provide this functionality. I believe the most popular is called denyhosts. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possibility for FreeBSD 4.11 Extended Support
In response to Heinrich Rebehn [EMAIL PROTECTED]: Colin Percival wrote: John Smith wrote: Support for FreeBSD 4.11 is going to end sometime in late January. Originally, FreeBSD 6.2 was supposed to be released back in October. This would have given everyone about 3 months to stress test everything and migrate all their boxes from 4.11 direct to 6.2. You've had three months to stress test 6.2-BETA1, 6.2-BETA2, 6.2-BETA3, and 6.2-RC1. We release these for a reason, you know. Now it is near the end of December, and FreeBSD 6.2 RC2 has yet to be seen anywhere. Chances are that FreeBSD 6.2 Release will come out earliest mid-January. This does not give much time for people to migrate to the newest FreeBSD release. I think it would be fair if support is extended for a few more months especially since 6.2 is so late in coming. Your opinion has been noted. Colin Percival I have to second the OP's opinion. :-) I think it is important to be able to stress test the *final* release before installing on production machines. There is little use in stress testing BETAs and then install a broken RELEASE. This happened with 6.1-RELEASE where the nfs server was suddenly unusable on amd64. There is something about these please continue to support 4.x discussions that confuses me. The general argument has been that 4.11 support should continue because 6.2 is not at release status yet. Are the people making this argument unaware that 6.1 and 5.5 have been at release status for quite some time, and thus have been providing ample opportunity to upgrade for some time now? Or has this topic simply degraded to Troll bait? -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possibility for FreeBSD 4.11 Extended Support
In response to Michael R. Wayne [EMAIL PROTECTED]: Private reply. Not interested in trolling or becoming a troll... On Thu, Dec 21, 2006 at 09:58:11AM -0500, Bill Moran wrote: Are the people making this argument unaware that 6.1 and 5.5 have been at release status for quite some time, and thus have been providing ample opportunity to upgrade for some time now? 4.11 is rock solid. 5.5 and 6.1 both have problems to the point that we can NOT roll them out on production machines. EVERY machine we run those releases (or any 5.x or 6.x release) will hang or reboot at random. And it's not hardware - we take a machine that was happily running 4.11, upgrade it, suffer problems, reformat and reinstall 4.11 and the machine is one again solid. So, 4.11 is unsupported, 5.5 and 6.1 are simply unusable and 6.2 is not released. Is is any wonder we are begging for extended support on 4.11? If 6.2 is as bad as 6.1, we're screwed. Don't know why you sent this to me privately. First off, we're running 5.5, 6.1 and 6.2 all over the place and have zero stability problems. Secondly, how many PRs have you filed regarding these problems? If you've found legitimate issues with the OS, the _correct_ thing to do is help the developers resolve the issues, not clamour about why there aren't enough resources to maintain a system that's old, old, old. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S)
In response to Morten A. Middelthon [EMAIL PROTECTED]: On Mon, Oct 30, 2006 at 04:17:00PM +0200, Conrad Burger wrote: I am trying to get FreeBSD to work on a Dell 1955 blade. Looks like the NICs on the blade are not supported by the BCE or BGE driver. On Linux the NICs are identified as 06:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (rev 11) From if_bce.c - * The following controllers are not supported by this driver: * (These are not Production versions of the controller.) * BCM5706C A0, A1 * BCM5706S A0, A1, A2, A3 * BCM5708C A0, B0 * -- BCM5708S -- A0, B0, B1 Is there any reason why the chipset is not supported? Is there anyway of getting the BCE or BGE driver to work with this chipset? Will it be supported sometime in the near future? Any help would be much appreciated. Any development here? We have just started purchasing 1955 Blades and would very much like to install FreeBSD on them :) Support for them is in CURRENT and 6.2, although the comment saying that they're _not_ supported is still there as well ;) -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S)
In response to Claus Guttesen [EMAIL PROTECTED]: I am trying to get FreeBSD to work on a Dell 1955 blade. Looks like the NICs on the blade are not supported by the BCE or BGE driver. On Linux the NICs are identified as 06:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (rev 11) From if_bce.c - * The following controllers are not supported by this driver: * (These are not Production versions of the controller.) * BCM5706C A0, A1 * BCM5706S A0, A1, A2, A3 * BCM5708C A0, B0 * -- BCM5708S -- A0, B0, B1 Is there any reason why the chipset is not supported? Is there anyway of getting the BCE or BGE driver to work with this chipset? Will it be supported sometime in the near future? Any help would be much appreciated. Any development here? We have just started purchasing 1955 Blades and would very much like to install FreeBSD on them :) Support for them is in CURRENT and 6.2, although the comment saying that they're _not_ supported is still there as well ;) No, unfortunately not. The controller is recognized but then bails out with SerDes controller not supported. Have tried (many times :-/ ). Ah ... that part wasn't clear. Unfortunately, I don't have any further information on this. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mount_smbfs: unable to open connection: syserr = Operation timed out
In response to Gerald Host [EMAIL PROTECTED]: I used some non-default kernel options to have more RAM (PAE). On one BSD machine this command works and mounts as expected. On another one it fails: bsd# mount_smbfs -I 192.168.1.10 //[EMAIL PROTECTED]/restorereports /mnt/reports mount_smbfs: unable to open connection: syserr = Operation timed out The difference between the machines is the kernel options and one failing is behind a router, but I don't think any ports are blocked. Both are 6.1servers: I would take some extra time to turn think into know before wasting any time pissing around with kernels. The above error sounds like a routing and/or port-blocked issue. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em interrupt storm
In response to Jack Vogel [EMAIL PROTECTED]: On 11/13/06, Bill Moran [EMAIL PROTECTED] wrote: Just experienced an interrupt storm on an em device that disabled a server until I could reboot it. My initial research turned up this thread: http://lists.freebsd.org/pipermail/freebsd-current/2005-November/058336.html Which seems related, even if it is a little old. I'm aware that there have been problems with recent versions of the em driver but I haven't been following them closely enough, and there's a LOT of mail traffic on this topic. Note that this is a FreeBSD 5.3-RELEASE-p37 system. An upgrade is possible, but this is a production system and the problem occurs infrequently, so I'm reluctant to schedule downtime unless I have good reason to believe that it will fix the problem. Anyone remember if the above problem was fixed in more recent versions, or knows enough about the issue to comment on whether I'm barking up the correct tree or not? I'm pretty early in the diagnosis on this, but I'm looking for pointers to keep me from doing random upgrades or other time-wasting activities. There were fixes to things that MIGHT be a cause of an interrupt storm in the em driver, but without knowing more about your specific hardware and the event when it happened its hard to pontificate :) Hell, it's hard just to spell pontificate! ;) As an aside, I would think getting off 5.3 would be desireable in and of itself :) It's on the TODO list, along with 1000 other things. If I can prove that 5.5 will fix a stability problem, that will move up the TODO list in priority. Can you give a vmstat -i, a pciconf -l, and maybe messages when the storm occurred? Sorry ... should have done that in the first email, but yesterday afternoon was a bit flustering ... There was a console message to the tune of interrupt store on em0 ... I didn't bother to copy it down exactly, because I expected it would end up in /var/log/messages, but it didn't. vmstat -i interrupt total rate irq4: sio0 3 0 irq8: rtc8027965127 irq13: npx01 0 irq14: ata0 58 0 irq16: uhci0 286184 4 irq18: uhci2 221609 3 irq19: uhci1 3 0 irq23: atapci094 0 irq34: mpt0 221609 3 irq64: em0286144 4 irq0: clk6272009 99 Total 15315679244 pciconf -l [EMAIL PROTECTED]:0:0:class=0x06 card=0x016c1028 chip=0x35908086 rev=0x09 hdr=0x00 [EMAIL PROTECTED]:2:0: class=0x060400 card=0x0050 chip=0x35958086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:4:0: class=0x060400 card=0x0050 chip=0x35978086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:5:0: class=0x060400 card=0x0050 chip=0x35988086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:6:0: class=0x060400 card=0x0050 chip=0x35998086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:29:0:class=0x0c0300 card=0x016c1028 chip=0x24d28086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:29:1:class=0x0c0300 card=0x016c1028 chip=0x24d48086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:29:2:class=0x0c0300 card=0x016c1028 chip=0x24d78086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x016c1028 chip=0x24dd8086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:30:0:class=0x060400 card=0x chip=0x244e8086 rev=0xc2 hdr=0x01 [EMAIL PROTECTED]:31:0:class=0x060100 card=0x chip=0x24d08086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:31:1: class=0x01018a card=0x016c1028 chip=0x24db8086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x060400 card=0x0044 chip=0x03298086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:0:2: class=0x060400 card=0x0044 chip=0x032a8086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:5:0: class=0x01 card=0x016c1028 chip=0x00301000 rev=0x08 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x060400 card=0x0044 chip=0x03298086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:0:2: class=0x060400 card=0x0044 chip=0x032a8086 rev=0x09 hdr=0x01 [EMAIL PROTECTED]:7:0: class=0x02 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 [EMAIL PROTECTED]:8:0: class=0x02 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 [EMAIL PROTECTED]:5:0: class=0xff card=0x00111028 chip=0x00111028 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:5:1: class=0xff card=0x00121028 chip=0x00121028 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:5:2: class=0xff card=0x00141028 chip=0x00141028 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:6:0: class=0x010185 card=0x06801095 chip=0x06801095 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:13:0:class=0x03 card=0x016c1028 chip=0x51591002 rev=0x00 hdr=0x00 -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone
em interrupt storm
Just experienced an interrupt storm on an em device that disabled a server until I could reboot it. My initial research turned up this thread: http://lists.freebsd.org/pipermail/freebsd-current/2005-November/058336.html Which seems related, even if it is a little old. I'm aware that there have been problems with recent versions of the em driver but I haven't been following them closely enough, and there's a LOT of mail traffic on this topic. Note that this is a FreeBSD 5.3-RELEASE-p37 system. An upgrade is possible, but this is a production system and the problem occurs infrequently, so I'm reluctant to schedule downtime unless I have good reason to believe that it will fix the problem. Anyone remember if the above problem was fixed in more recent versions, or knows enough about the issue to comment on whether I'm barking up the correct tree or not? I'm pretty early in the diagnosis on this, but I'm looking for pointers to keep me from doing random upgrades or other time-wasting activities. -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AMD64 Stable fails to boot on Dell PowerEdge 1950
In response to Vivek Khera [EMAIL PROTECTED]: On Oct 27, 2006, at 1:00 PM, Travis Pugh wrote: Is there something I'm missing with regards to ACPI on the AMD64 platform? I've read here that i386 boots fine on the same hardware. I have one piece of dell equipment which insists on disabling ACPI timer and then everything works. Disabling ACPI totally seems undesirable under normal circumstances. I've done multiple installs of 6-STABLE on a 1950 without problems. One of them was used to create a custom install CD that I'm using today to install on several others. Haven't had to tweak anything at all in the BIOS. I missed the start of this thread. Did you give any more hardware details? -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.x from i386 to amd64
In response to Greg Black [EMAIL PROTECTED]: On 2006-10-31, Robert Blayzor wrote: Is there a way to upgrade/move an already installed i386 installed 6.1 machine to amd64 without completely reinstalling? Is there a procedure to do so? Having just gone through the migration in the opposite direction, I would ask why you want to do this? The state of the software out there is disgracefully far from being ready for 64-bit platforms -- after wasting weeks in a vain attempt to get a workable development environment on my amd64 setup, I've just completed a move to i386 (by a fresh install). I now have a machine that has almost every port I want working and that still gives me considerable performance improvements over the genuine Intel 32-bit boxes I have. I won't be trying another amd64 setup for at least a couple more years. Are there open PRs on this? We've not had any problems. Although our amd64 deployment is still young, we have several machines humming away happily. Where did you have problems, specifically? -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG 6.1/AMD64 system hangs when SMP enabled
In response to bram [EMAIL PROTECTED]: Hi all, I'm rather new to freebsd so forgive me if I am saying things that don't make sense. I have a dual opteron server running freebsd 6.1/amd64 updated 4 weeks ago. Since I moved to 6 I've been having tho following problem. When I put heavy load on the server (python scripts that take 20 minutes to complete) the server sometimes hangs. I can then not ping it anymore and it does not respond to anything (no keyboard power button etc.). Mostly there are no error messages or anything so I have no clue to what the problem is. One time it did give an error but I did not wrote it down, but as I recall it was something like SMP spin lock timed out. It hangs every three weeks Please give me some info on how I can get it to give more info or how to resolve this problem. I'm no expert, but this is probably where you'll need to start: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
In response to Jason Thomson [EMAIL PROTECTED]: Scott Long wrote: I'll cautiously say that the latest set of changes to bce might be interesting for you. It now survives all of my ttcp and netblast tests in both UDP and TCP. Please let me know if it makes things better, worse, or no change for you. The driver from HEAD (if_bce.c 1.17) is looking much better - thanks Scott! We couldn't trigger this bug using UDP NFS mounts. Neither could we trigger it with multiple simultaneous TCP connections. I'm seeing similar improvement. I've been testing the new version since I came in this morning (About 2.5 hours so far), with no failures. This is the first version of the driver that has allowed me to actually complete a buildworld over NFS. I will continue testing and report again at the end of the day. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpu usage
In response to gareth [EMAIL PROTECTED]: hi, i'm on FreeBSD 6.1, with a problematic cpu - it seems to be overheating and shutting the system down when running intensive jobs, at the moment i can't even finish compiling the mysql-server in ports. i've tried running the make with an increased nice level, but that doesn't seem to change much. and looking through ports there only seems to be cpu monitoring tools, not suppression? It's unlikely that there's anything you can do in software to fix this problem. You need to fix your cooling so the CPU doesn't overheat. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Running large DB's on FreeBSD
Mike Jakubik [EMAIL PROTECTED] wrote: I am in the process of implementing a fairly large mysql server for an even larger company, and naturally i want to use FreeBSD. The hardware will be an HP DL385, 2 x dual-core Opterons, 16GB RAM, 7 x 15k rpm disks in a RAID5 setup. Generally speaking, RAID 5 is known for lousy performance in database loads. Consider using RAID 10. So, first of all, am i crazy for choosing fbsd+mysql for this rather than something like Solaris + Oracle? :) Well, you should be using FreeBSD+PostgreSQL, but that's just my religion. Secondly, i am just looking for some suggestions, opinions, success/failure story's that may help me out. Is anyone out there using FreeBSD for something of this size? I am hoping that everything will work out well, and the client will be happy. This would generate some good PR for FreeBSD, as it is a very large international company and it would be the first FreeBSD server (that i know of) of this type there. Yes, this is being done. I would suggest surfing the Postgresql performance mailing list archives a bit. There are often discussions of huge databases there: http://archives.postgresql.org/pgsql-performance/ -- Bill Moran The presence of stale files in this directory can cause the dreaded unpredictable results, and therefore it is highly recommended that you delete them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
In response to Jason Thomson [EMAIL PROTECTED]: Scott Long wrote: Conrad Burger wrote: Hi It looks like there is a new version of the bce driver in HEAD. When will it be incorporated into Releng_6? It will be merged when someone, preferably 2-3 people, tell me that the changes in HEAD work for them. So far, no one has. Scott ___ Using the driver from HEAD* in the latest RELENG_6 didn't fix our problems. We could still trigger the Watchdog timeout when copying a local file to an NFS mounted filesystem (UDP mount, GigE speeds). Same here, although it seemed to require a lot more effort to produce the problem. I see there have been additional updates to the driver in the past 10 hours. I'll grab those and try again to see if they help any. -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
In response to Bill Moran [EMAIL PROTECTED]: In response to Jason Thomson [EMAIL PROTECTED]: Scott Long wrote: Conrad Burger wrote: Hi It looks like there is a new version of the bce driver in HEAD. When will it be incorporated into Releng_6? It will be merged when someone, preferably 2-3 people, tell me that the changes in HEAD work for them. So far, no one has. Scott ___ Using the driver from HEAD* in the latest RELENG_6 didn't fix our problems. We could still trigger the Watchdog timeout when copying a local file to an NFS mounted filesystem (UDP mount, GigE speeds). Same here, although it seemed to require a lot more effort to produce the problem. I see there have been additional updates to the driver in the past 10 hours. I'll grab those and try again to see if they help any. No dice. I grabbed the latest if_bce.c from cvs HEAD, made the tweaks (provided by Jason) and rebuilt the kernel. I was able to trigger the watchdog timeout in less than 5 minutes. I did not get a kernel panic, and kernel was built with INVARIANTS and INVARIANT_SUPPORT. Any other tests/experiments it would be worthwhile for me to run? -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
In response to Scott Long [EMAIL PROTECTED]: Conrad Burger wrote: Hi It looks like there is a new version of the bce driver in HEAD. When will it be incorporated into Releng_6? It will be merged when someone, preferably 2-3 people, tell me that the changes in HEAD work for them. So far, no one has. I'm working on that now. I wasn't aware that improvements had been committed or I'd have started on it 2 days ago ... -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
In response to Bill Moran [EMAIL PROTECTED]: In response to Scott Long [EMAIL PROTECTED]: Conrad Burger wrote: Hi It looks like there is a new version of the bce driver in HEAD. When will it be incorporated into Releng_6? It will be merged when someone, preferably 2-3 people, tell me that the changes in HEAD work for them. So far, no one has. I'm working on that now. I wasn't aware that improvements had been committed or I'd have started on it 2 days ago ... Well, I tried to backport the driver in -CURRENT to 6-STABLE and failed. Then I tried upgrading the system to -CURRENT, and that's left me with an unbootable system. Just not having a good day ... -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ping question
In response to Balgansuren Batsukh [EMAIL PROTECTED]: Hello, I am using FreeBSD-6.2-PRERELEASE and when I ping to outside IP address get below result. gk# ping y.y.y.y PING y.y.y.y (y.y.y.y): 56 data bytes 64 bytes from y.y.y.y: icmp_seq=0 ttl=43 time=482.571 ms 64 bytes from y.y.y.y: icmp_seq=0 ttl=43 time=482.934 ms (DUP!) 64 bytes from y.y.y.y: icmp_seq=0 ttl=43 time=483.431 ms (DUP!) 64 bytes from y.y.y.y: icmp_seq=1 ttl=43 time=441.772 ms 64 bytes from y.y.y.y: icmp_seq=1 ttl=43 time=441.978 ms (DUP!) 64 bytes from y.y.y.y: icmp_seq=1 ttl=43 time=442.256 ms (DUP!) 64 bytes from y.y.y.y: icmp_seq=2 ttl=43 time=492.160 ms 64 bytes from y.y.y.y: icmp_seq=3 ttl=43 time=477.828 ms 64 bytes from y.y.y.y: icmp_seq=4 ttl=43 time=440.011 ms 64 bytes from y.y.y.y: icmp_seq=4 ttl=43 time=440.372 ms (DUP!) 64 bytes from y.y.y.y: icmp_seq=4 ttl=43 time=440.744 ms (DUP!) 64 bytes from y.y.y.y: icmp_seq=5 ttl=43 time=422.430 ms 64 bytes from y.y.y.y: icmp_seq=5 ttl=43 time=422.790 ms (DUP!) 64 bytes from y.y.y.y: icmp_seq=5 ttl=43 time=423.040 ms (DUP!) 64 bytes from y.y.y.y: icmp_seq=6 ttl=43 time=452.691 ms 64 bytes from y.y.y.y: icmp_seq=7 ttl=43 time=489.581 ms 64 bytes from y.y.y.y: icmp_seq=8 ttl=43 time=479.235 ms 64 bytes from y.y.y.y: icmp_seq=9 ttl=43 time=473.910 ms 64 bytes from y.y.y.y: icmp_seq=9 ttl=43 time=474.271 ms (DUP!) 64 bytes from y.y.y.y: icmp_seq=9 ttl=43 time=474.644 ms (DUP!) 64 bytes from y.y.y.y: icmp_seq=10 ttl=43 time=443.461 ms 64 bytes from y.y.y.y: icmp_seq=11 ttl=43 time=496.951 ms 64 bytes from y.y.y.y: icmp_seq=12 ttl=43 time=500.120 ms 64 bytes from y.y.y.y: icmp_seq=13 ttl=43 time=481.664 ms 64 bytes from y.y.y.y: icmp_seq=13 ttl=43 time=519.755 ms (DUP!) 64 bytes from y.y.y.y: icmp_seq=13 ttl=43 time=520.129 ms (DUP!) Above result shows there some row has (DUP!) message. I don't know why there such message. Where can I get more detail information about it or it is error happen to NIC? It's unlikely that this has anything to do with FreeBSD. It's more likely that a networking problem is causing packets to take multiple routes back at times, thus arriving twice. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
In response to Bruno Ducrot [EMAIL PROTECTED]:
On Tue, Oct 10, 2006 at 02:53:15PM -0400, Bill Moran wrote:
In response to Doug Ambrisko [EMAIL PROTECTED]:
John Baldwin writes:
| On Tuesday 10 October 2006 08:54, Bill Moran wrote:
| In response to Doug Ambrisko [EMAIL PROTECTED]:
| Bruno Ducrot writes:
| | On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote:
| | In response to Bruno Ducrot [EMAIL PROTECTED]:
| | Hi,
| |
| | On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote:
| |
| |A reboot causes the OS to halt, but the hardware just sits
there on the
| |shutdown screen.
| |
| |A shutdown -p does the same.
| |
| | What exactly are the last few lines?
| |
| | (manually copied)
| |
| | ...
| | All buffers synced.
| | Uptime: 1m16s
| |
| |
| | Thanks. Then this happen after print_uptime().
| |
| | I believe one of the drivers register a shutdown_final (or
| | shutdown_post_sync) event that hang your system. I think (though
I
| | may be wrong) mfi may be that one.
| |
| | It would help if you can add some printf in dev/mfi/mfi.c into the
| | mfi_shutdown() function in order to check if that assumption
| | is correct.
|
| Some what related to this we have a local hack:
|
| --- sys/kern/subr_bus.c.origTue Jun 27 15:49:39 2006
| +++ sys/kern/subr_bus.c Tue Jun 27 15:49:51 2006
| @@ -2906,6 +2906,7 @@ bus_generic_shutdown(device_t dev)
| device_t child;
|
| TAILQ_FOREACH(child, dev-children, link) {
| + DELAY(1000);
| device_shutdown(child);
| }
|
| This patch seems to fix the problem. I'm going to replace it with
| some printfs and see if I can determine which driver is actually
| causing the problem (hopefully it's only one).
|
| Am I wrong in saying that the correct solution would be to identify
the
| driver that needs more time and implementing some sort of polling
| mechanism to ensure the hardware is ready when the driver wants to
| shut down?
|
| Well, first let's see which driver it is. :) You might be able to just
| remove the DELAY and add a printf and see which device is printed last.
I think it was in a different ones. One of our configs has the base
HW + bge NIC the other has base HW + 2 x 2 port em NICs. The more
NIC's the better chance for a problem.
I've removed the hack from our kernel and I'm going to run the reboot
cycle. I don't think a printf will work since I recall trying that
it fixed the problem so I put the DELAY in :-( It could be generic
problem to the system with a sufficiently fast CPU to beat the
HW at shutting down. I'm not sure if his system is Dempsey or Woodcrest.
We use Woodcrest and they are really faster. Other machines might be
slow enough that it's not a a problem! We haven't seen it on our older
platforms with the same kernel and similar HW configs.
Well, I already did this. The only printf is the
device_printf(child, shutdown\n) that Bruno suggested. With this
single change, I'm unable to reproduce the problem.
Have any commits been made to 6-STABLE that might have inadvertently
fixed this in the last week or so?
The device_printf() function take too much time I think, so you get the same
behaviour as the DELAY().
True. Problem is that I considered that possibility, and removed the
device_printf(), rebuild the kernel, and have been unable to reproduce
the problem with a stock SMP kernel since yesterday.
I'm seriously considering the possibility that this has been fixed, but
I'm uncomfortable that nobody can say, Sure, I committed a fix to that
last week.
--
Bill Moran
Collaborative Fusion Inc.
IMPORTANT: This message contains confidential information and is
intended only for the individual named. If the reader of this
message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
___
freebsd-stable
Re: Dell 1950 does not properly respond to reboot and shutdown -p
In response to Olivier Mueller [EMAIL PROTECTED]: I would be happy to test help, I also have a PE1950 around waiting for this problem to be solved to go in production. I would just need to have the patch. (I'll check the list archive later, I just joined freebsd-stable today) There isn't really a patch per-se. Just a bunch of recommendations on where to put extra debugging information. You'll find it in the archives. Btw, it would be nice if the patched if_bce.c could also be integrated into the cvs (http://yogurt.org/FreeBSD/if_bce.c). At the moment (beg. of the week) I still had to patch the source tree by hand to keep the network interface working fine (cf. thread on freebsd-hardware). As you might guess, I'm also being bitten by this. Could you point me to the thread in hardware@ please, I've been unable to find it searching the archives. I'm guessing bce is not part of the title? -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
In response to Olivier Mueller [EMAIL PROTECTED]: Btw, it would be nice if the patched if_bce.c could also be integrated into the cvs (http://yogurt.org/FreeBSD/if_bce.c). At the moment (beg. of the week) I still had to patch the source tree by hand to keep the network interface working fine (cf. thread on freebsd-hardware). Are you saying that the version from that site makes your bce card reliable? Doesn't seem to address the issues being worked on: http://lists.freebsd.org/pipermail/freebsd-stable/2006-October/029407.html -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
In response to Doug Ambrisko [EMAIL PROTECTED]:
Bruno Ducrot writes:
| On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote:
| In response to Bruno Ducrot [EMAIL PROTECTED]:
| Hi,
|
| On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote:
|
|A reboot causes the OS to halt, but the hardware just sits there on
the
|shutdown screen.
|
|A shutdown -p does the same.
|
| What exactly are the last few lines?
|
| (manually copied)
|
| ...
| All buffers synced.
| Uptime: 1m16s
|
|
| Thanks. Then this happen after print_uptime().
|
| I believe one of the drivers register a shutdown_final (or
| shutdown_post_sync) event that hang your system. I think (though I
| may be wrong) mfi may be that one.
|
| It would help if you can add some printf in dev/mfi/mfi.c into the
| mfi_shutdown() function in order to check if that assumption
| is correct.
Some what related to this we have a local hack:
--- sys/kern/subr_bus.c.orig Tue Jun 27 15:49:39 2006
+++ sys/kern/subr_bus.c Tue Jun 27 15:49:51 2006
@@ -2906,6 +2906,7 @@ bus_generic_shutdown(device_t dev)
device_t child;
TAILQ_FOREACH(child, dev-children, link) {
+ DELAY(1000);
device_shutdown(child);
}
This patch seems to fix the problem. I'm going to replace it with
some printfs and see if I can determine which driver is actually
causing the problem (hopefully it's only one).
Am I wrong in saying that the correct solution would be to identify the
driver that needs more time and implementing some sort of polling
mechanism to ensure the hardware is ready when the driver wants to
shut down?
--
Bill Moran
Collaborative Fusion Inc.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CALL FOR TESTERS! [Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2]
In response to Scott Long [EMAIL PROTECTED]: Corrected patch is at: http://people.freebsd.org/~scottl/usb_fastintr_RELENG_6.diff I have a Dell 1950 here that's been dedicated to helping solve this problem. I can reliably reproduce the watchdog timeout by doing the following steps: 1) Mount /usr/src via nfs 2) start a -j99 buildworld 3) On a different terminal, do tar czvf /usr/src/temp.tgz /big/directory Usually only takes a few minutes before a watchdog occurs, and I have no more networking. Your patch applied cleanly, and everything built OK. The results are: a) My USB keyboard stopped working :( b) The problem does _not_ improve. In my case, it's a bce driver that's doing it. I also have some em cards in this machine that I can test if the information will be helpful. This is quite a show-stopper for us, if there's any other testing/etc I can do, _please_ let me know. I might even be able to get remote console access to this machine approved for a developer. -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CALL FOR TESTERS! [Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2]
In response to Bill Moran [EMAIL PROTECTED]: In my case, it's a bce driver that's doing it. I also have some em cards in this machine that I can test if the information will be helpful. Note that I can _not_ reproduce the problem with an em interface (a PCI NIC). As mentioned earlier, I can reliably and easily produce a watchdog timeout on the bce interface (onboard). The em interface seems rock-solid. I guess I have a workaround for now, but the offer to test/provide more information stands. -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Dell 1950 does not properly respond to reboot and shutdown -p
is normal mfi0: 825 - Current capacity of the battery is above threshold mfi0: 826 - PCI 0x041028 0x0415 0x041028 0x041f03: Firmware initialization started (PCI ID 0015/1028/1f03/1028) mfi0: 827 - Type 18: Firmware version 1.00.01-0088 mfi0: 828 - Battery Present mfi0: 829 - PD 08(e1/s255) event: Enclosure (SES) discovered on PD 08(e1/s255) mfi0: 830 - PD 08(e1/s255) event: Inserted: PD 08(e1/s255) mfi0: 831 - Type 29: Inserted: PD 08(e1/s255) Info: enclPd=08, scsiType=d, portMap=00, sasAddr=500180b034dad300, mfi0: 832 - PD 00(e1/s0) event: Inserted: PD 00(e1/s0) mfi0: 833 - Type 29: Inserted: PD 00(e1/s0) Info: enclPd=08, scsiType=0, portMap=01, sasAddr=50e012b5c9f2, mfi0: 834 - PD 01(e1/s1) event: Inserted: PD 01(e1/s1) mfi0: 835 - Type 29: Inserted: PD 01(e1/s1) Info: enclPd=08, scsiType=0, portMap=02, sasAddr=50e012b486b2, mfi0: 836 - Adapter ticks 213289148 elapsed 45s: Time established as 10/04/06 14:59:08; (45 seconds since power on) mfi0: 837 - Battery temperature is normal mfi0: 838 - Current capacity of the battery is above threshold SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #4 Launched! cd0 at umass-sim0 bus 0 target 0 lun 0 cd0: Dell Virtual CDROM 123 Removable CD-ROM SCSI-0 device cd0: 40.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present da0 at umass-sim1 bus 1 target 0 lun 0 da0: Dell Virtual Floppy 123 Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim1:1:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim1:1:0:0): CAM Status: SCSI Status Error (da0:umass-sim1:1:0:0): SCSI Status: Check Condition (da0:umass-sim1:1:0:0): NOT READY asc:3a,0 (da0:umass-sim1:1:0:0): Medium not present (da0:umass-sim1:1:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim1:1:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim1:1:0:0): CAM Status: SCSI Status Error (da0:umass-sim1:1:0:0): SCSI Status: Check Condition (da0:umass-sim1:1:0:0): NOT READY asc:3a,0 (da0:umass-sim1:1:0:0): Medium not present (da0:umass-sim1:1:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim1:1:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim1:1:0:0): CAM Status: SCSI Status Error (da0:umass-sim1:1:0:0): SCSI Status: Check Condition (da0:umass-sim1:1:0:0): NOT READY asc:3a,0 (da0:umass-sim1:1:0:0): Medium not present (da0:umass-sim1:1:0:0): Unretryable error Opened disk da0 - 6 Trying to mount root from ufs:/dev/mfid0s1a -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
In response to Guy Helmer [EMAIL PROTECTED]: Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. Other ACPIish stuff seems to work as advertised. (i.e. hitting the power button cleanly shuts down the OS) I'm posting this to stable@, but the same behaviour occurs with FreeBSD 6.1-RELEASE as well. Does setting hw.acpi.handle_reboot to 1 via sysctl help? If set, this variable will use ACPI to perform the reboot action via the reset register instead of using the keyboard controller or a triple fault to reboot. I manually changed that setting and the behaviour did not change. Does the setting need set before the kernel boots? -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CALL FOR TESTERS! [Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2]
In response to Mike Tancsa [EMAIL PROTECTED]: At 12:27 PM 10/4/2006, Bill Moran wrote: In response to Bill Moran [EMAIL PROTECTED]: In my case, it's a bce driver that's doing it. I also have some em cards in this machine that I can test if the information will be helpful. Note that I can _not_ reproduce the problem with an em interface (a PCI NIC). As mentioned earlier, I can reliably and easily produce Hi, Just to clarify, you mean without the patch you do run into the problem, but with the patch you cannot generate the problem ? Or with the em NIC, you have never seen the issue at all ? Without patch: * bce locks up easily * Unable to lock up em * keyboard works With patch: * bce locks up easily * unable to lock up em * keyboard doesn't work -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
In response to Guy Helmer [EMAIL PROTECTED]: Bill Moran wrote: In response to Guy Helmer [EMAIL PROTECTED]: Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. Other ACPIish stuff seems to work as advertised. (i.e. hitting the power button cleanly shuts down the OS) I'm posting this to stable@, but the same behaviour occurs with FreeBSD 6.1-RELEASE as well. Does setting hw.acpi.handle_reboot to 1 via sysctl help? If set, this variable will use ACPI to perform the reboot action via the reset register instead of using the keyboard controller or a triple fault to reboot. I manually changed that setting and the behaviour did not change. Does the setting need set before the kernel boots? The value of that parameter is checked at runtime so you should be able to set it while the system is running. Do you get an ACPI reset failed message on the console? No. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
In response to Bruno Ducrot [EMAIL PROTECTED]: Hi, On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. What exactly are the last few lines? (manually copied) ... All buffers synced. Uptime: 1m16s -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CALL FOR TESTERS! [Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2]
In response to Kris Kennaway [EMAIL PROTECTED]: This is quite a show-stopper for us, if there's any other testing/etc I can do, _please_ let me know. I might even be able to get remote console access to this machine approved for a developer. Remote console access would be a help. I suspect there may be more than one problem here. In progress ... I'll contact you privately when it's ready. -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel se7230NH1-E, 6gb memory not working on FreeBSD 6.0
In response to Jeremy Chadwick [EMAIL PROTECTED]: On Wed, Sep 27, 2006 at 01:58:59PM -0700, [EMAIL PROTECTED] wrote: I am having a very hard time getting an Intel se7230NH1-E motherboard with 6gb of memory to work. I keep getting two messages about Too many holes in the physical address space, giving up. I'm not sure what the BIOS is (it seems to be OEMed to Intel), but with the menu structure I'd have to throw a dart at AMI BIOS. I've scanned the newsgroups/message boards for issues surrounding this and most suggest that there is a BIOS setting that can be tweaked to make things come together. However, I just don't see any of those options - the only thing there with respect to memory involves memory timing. Other posts have talked about unlocking hidden menus in the BIOS (I'll save my tirade on hiding BIOS menu options for another day - but whoever did this should be ashamed of yourself). Alas, none of these have given me any luck. So, with that in mind... Anyone have any ideas on how I can get this to recognize the 6gb of memory we have installed on the motherboard? Based on what I understand of Intel x86 architecture, to address more than 4GB of memory space, you have to use Intel's PAE feature. I don't think the FreeBSD kernels are built with PAE enabled. This might explain why the kernel states there's too many memory holes. I'd recommend either 1) disabling PAE (Physical Address Extensions) in the BIOS if possible, or 2) removing some RAM from the system, getting FreeBSD installed + upgraded to 6.2, building a kernel that has PAE enabled and then putting the extra RAM back in. Any other administrators have tips/comments? I have no idea if the problem is related to PAE, but have you tried booting an amd64 kernel on the system? -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel se7230NH1-E, 6gb memory not working on FreeBSD 6.0
[EMAIL PROTECTED] wrote: I have no idea if the problem is related to PAE, but have you tried booting an amd64 kernel on the system? This is an Intel Pentium 4 (D) system. Would the AMD64 kernel even work? I'm not an Intel sales rep, but I believe all the P4 systems have 64 bit support. Unless it's specifically an Itanium (in which case an i386 kernel wouldn't even boot) it's amd64. -- Bill Moran Many miles away, something crawls through the slime at the bottom of a dark, Scottish lake. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL in FreeBSD jails
Alexander Rusinov [EMAIL PROTECTED] wrote: Hi, I need to run a number of PostgreSQL servers in different FreeBSD jails. I managed to run a first instance of PostgreSQL server in a jail, but after I launch a new server in another jail the first one starts to return an error messages like the following: semctl(1507328, 4, SETVAL, 0) failed: Invalid argument The problem in general is: only one instance of PostgreSQL server processes clients' connections, all of the others return semctl errors. I had this exact same problem. I never found a solution. The cause appears to be that, since shared memory is not segregated between jails, the newly launched Postgres instances corrupt the shared memory of previously running Postgres instances. Supposedly, this shouldn't be possible, but it was happening and I never found a solution. The system is FreeBSD 5.4-PRERELEASE. PostgreSQL-7.4.7. SEM and SHM sysctl setting are: # sysctl -a | grep shm kern.ipc.shmmax: 1 kern.ipc.shmmin: 1 kern.ipc.shmmni: 192 kern.ipc.shmseg: 128 kern.ipc.shmall: 32768 kern.ipc.shm_use_phys: 0 kern.ipc.shm_allow_removed: 0 # sysctl -a | grep sem kern.ipc.semmap: 256 kern.ipc.semmni: 256 kern.ipc.semmns: 512 kern.ipc.semmnu: 256 kern.ipc.semmsl: 60 kern.ipc.semopm: 100 kern.ipc.semume: 10 kern.ipc.semusz: 92 kern.ipc.semvmx: 32767 kern.ipc.semaem: 16384 Trying to solve the problem I've set the following in postgresql.conf files: max_connections = 5 shared_buffers = 100 Please help! What am I doing wrong? -- Alexander Rusinov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Bill Moran Potential Technologies http://www.potentialtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL in FreeBSD jails
Marc G. Fournier [EMAIL PROTECTED] wrote: On Tue, 26 Apr 2005, Bill Moran wrote: Alexander Rusinov [EMAIL PROTECTED] wrote: Hi, I need to run a number of PostgreSQL servers in different FreeBSD jails. I managed to run a first instance of PostgreSQL server in a jail, but after I launch a new server in another jail the first one starts to return an error messages like the following: semctl(1507328, 4, SETVAL, 0) failed: Invalid argument The problem in general is: only one instance of PostgreSQL server processes clients' connections, all of the others return semctl errors. I had this exact same problem. I never found a solution. The cause appears to be that, since shared memory is not segregated between jails, the newly launched Postgres instances corrupt the shared memory of previously running Postgres instances. I'm running 9 jails on a server right now, each with their own instance: snip and never noticed any issues ... but, this is with 4.11, not 5.x, so maybe something has changed? I was running 5.2 when I had the problems. So it's possible that this guess is correct. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Newbie Question About System Update
Pete French [EMAIL PROTECTED] wrote: Colocation that does not include serial console access is IMHO worthless. i;ve been following this discussion with interest - what advantages does a serial concolse give you over a colo's standard KVM access ? I've never used a serial consolve with FreeBSD, though I see the phrase crop up a lot. KVM requires you to physically _be_ at the colo. A serial console with an IP address and ssh capabilities (which is easy to set up, or fairly inexpensive to purchase) allows you access to the system as if you're sitting at it, over ssh. i.e. using a serial console you can boot a different kernel, remotely, see the messages that come up when a kernel panics, etc ... Most of the stuff you could do if you have physical access, without requiring physical access. A serial console allows you to do a proper upgrade remotely, because you can still access the system when it's in single user mode. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Newbie Question About System Update
Pete French [EMAIL PROTECTED] wrote: KVM requires you to physically _be_ at the colo. ?! Not the one I have for our colo - it's a little java app where I choose a machine from a dropdown and get the video in a window on the desktop. That's an out of the ordinary KVM. Would you mind passing on the manufacturer of that unit, I'd like to recommend that unit to a number of clients/associates of mine. The point is that a normal, run of the mill KVM doesn't have that capability. A serial console with an IP address and ssh capabilities (which is easy to set up, or fairly inexpensive to purchase) allows you access to the system as if you're sitting at it, over ssh. Ah, O.K. sounds fairly similar to what I have. Preseumably you can get at BIOS settings and stuff like that too ? Still don't see the advantage to be honest, but thanks for the explanation. With a networkable KVM like you've got, there is no real advantage that I can see (unless you're doing kernel debugging, but that's a pretty advanced topic) But compare your KVM to a typical, non-networkable KVM and you get the same idea of what I was thinking when I compared a serial console to a KVM. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: background_fsck=no does not work?
Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, Apr 25, 2005 at 08:10:35AM -1000, Randy Bush wrote: not always be clean. Softupdates (hopefully) means that it will be consistent and recoverable, but what you're seeing here is normal and Why hopefully? Aren't people convinced that it works correctly? i am convinced, but some of the hosts seem not to be :-) i see shutdowns which 0 0 0 0 and then shut, and when restarted single user and fscked manually show errors. though i think this may be in current, which is on most of my hosts. Yeah, others have reported this problem on -current, but 5.x does not have it. Actually, I have seen a similar problem on 5.x WRT OpenOffice ... 0. OpenOffice hangs and cant' be killed 1. Reboot system 2. System claims all buffers flushed, then just hangs 3. After hardbooting, filesystems need fscked I noticed others with similar complaints about OpenOffice, so I haven't said much. The problem also happens pretty rarely, and I don't have any idea how to reproduce it on demand. I don't think this is _quite_ the same problem, however. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Newbie Question About System Update
Pete French [EMAIL PROTECTED] wrote: That's an out of the ordinary KVM. Would you mind passing on the manufacturer of that unit, I'd like to recommend that unit to a number of clients/associates of mine. It's an HP unit. The client is a Java program called IPViewer you donwload from their website. I did have to tweak it to run under freeBSD (basically download the Linux version and replace the JRE with the FreeBSD native one). *quick rummage* I suspect it's one of these: http://h18004.www1.hp.com/products/servers/proliantstorage/rack-options/kvm/index-console.html Not that I have ever seen the thing. But it seems likely that it's one of those. None of the boxes plugged into it are HP/Compaq ones - they are a miscellany of odd servers from a variety of places, and it works fine with all of them. The point is that a normal, run of the mill KVM doesn't have that capability. I havent worked with many colo's - I assumed they all had some kind of remote KVM ability, sorry. I see what you mean now. cheers, -pcf. PS: I have no clue how miuch those KVM's cost - they might be horrificly expensive if you dont get one as standard with your hosting. HP and 'cheap' aren't two words that I naturally associate. This might be the only real advantage of a serial console. The unit you pointed to is ~$4000.00, whereas 16-port serial console units run more like $1000.00. Of course, the obvious advantage to the networkable KVM is that you can remotely admin GUI-based servers easily. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Newbie Question About System Update
Matthias Buelow [EMAIL PROTECTED] wrote: Bill Moran [EMAIL PROTECTED] writes: Fact is, trying to update a running system could result in silent failures. The system can not replace programs that are in use, so there's always the chance that something or other won't get updated (cron would be an excellent example ... do you always shut cron off when you update? How about syslogd?) This is complete nonsense. Yes, and no. As was pointed out, the install process does not cp, so it doesn't have to deal with this problem. I was wrong. However, it's still true that you can't copy over an executable in use, it's just easy to work around it. On a production system, you should have a serial terminal connected so you can go to single-user mode remotely to do updates. There are fairly inexpensive serial terminal boxes available from a number of vendors, and if you have a spare machine available, you can always hook it up as a serial terminal. I was talking about a colocation situation, where you most likely will never see the machine. Networked console boards are usually available but may not always be cost effective. I would agree that such a board may be a necessity in a high profile production server but if you are a small company, or use a machine privately, the extra cost often outweighs the gain. And a good colo hoster usually also has qualified staff. Who are you using for colo? I'd like to contact them. Unless your server is utterly unimportant, the last thing you want to have happen is an upgrade where the kernel doesn't boot and you have a dead system until someone can hook a console to it. Most colos I've seen charge you a premium to have someone hook a console up for you. I asked one how much it would cost to hook up a serial console and give it an IP for one month, and their response was we don't do that, you have to pay our tech $160/hour to sit on the phone with you and enter what you want. While this seems to be a worst case scenerio, it doesn't seem to be an uncommon attitude. A lesson to all of you, when you choose a colo, don't just look at the cost of having your box sit there - estimate the cost of doing maintenance and handling problems, those are hidden costs where many colos will rape you. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Newbie Question About System Update
Jim Campbell [EMAIL PROTECTED] wrote: I've been away from *NIX a few years. I have been playing with FreeBSD for a week or so now with mixed results. I am using release 4.11 because for some reason 5.3 has problems seeing my hard drives. 4.11, Red Hat Linux and NetBSD have no such trouble. This afternoon I used the Updating Sources with CVSup in the FreeBSD Cheat Sheets and everything worked as advertized. I believe that it advised against using make world and suggested that I use 19.4.1 The Canonical Way to Update Your System in the Handbook. I went through the following steps with no problem: # make buildworld # make installworld # mergemaster # reboot This is not correct, and this is not what 19.4.1 says. The correct procedure is as Mike Schultz described. Please review that section of the handbook. If you did, indeed, do as you described, then you have a world that's out of sync with your kernel. Try this: 1) Boot in to single user mode 2) fsck 3) mount -a 4) cd /usr/src 5) make buildkernel 6) make installkernel 7) reboot If you're unable to complete those steps, then you may be better off reinstalling and trying again - write it off as part of the learning process. There are ways to restore your system if you've made this mistake and the above doesn't work, but it's rather advanced stuff. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Newbie Question About System Update
Matthias Buelow [EMAIL PROTECTED] wrote: Jim Campbell [EMAIL PROTECTED] writes: After that, I ran into problems. It took me a little while to figure out how to do boot -s. However, it appears that a lot of the directories aren't mounted and the next scripts aren't in the path. For example, I can't figure out how to do the mergemaster -p. You don't have to do it in single user mode, I never did. I don't know why it is recommended that one boots in single user in the Makefile, perhaps to get a quiescent system without any users and services that would interfere. But that can also be achieved by stopping the high-volume services on the machine after booting, and on a personal machine (workstation PC) it doesn't matter anyways. Often it's not even possible to boot into single-user, for example if you don't have physical control over the machine (like in a co-lo situation). This isn't really true. Fact is, trying to update a running system could result in silent failures. The system can not replace programs that are in use, so there's always the chance that something or other won't get updated (cron would be an excellent example ... do you always shut cron off when you update? How about syslogd?) That being said, I quite often do installworld on running systems because I have no way to go to single-user mode. It almost always works well enough for my purposes, but I don't want anyone to think that it's OK to do this, as it's not guaranteed to work, and will most likely result in some programs not being updated (such as the examples in the previous paragraphs). On a production system, you should have a serial terminal connected so you can go to single-user mode remotely to do updates. There are fairly inexpensive serial terminal boxes available from a number of vendors, and if you have a spare machine available, you can always hook it up as a serial terminal. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Newbie Question About System Update
Chuck Swiger [EMAIL PROTECTED] wrote: Bill Moran wrote: The system can not replace programs that are in use, This is generally not the case. Unix lets you continue to access a file after it has been deleted, so long as the process hangs on to a file descriptor. This lets you replace programs in use, without running into the same problems that platforms like Windows have. What you say?: bash-2.05b$ su Password: bolivia# cp /usr/sbin/cron /home/wmoran/. bolivia# cp /home/wmoran/cron /usr/sbin/. cp: /usr/sbin/./cron: Text file busy bolivia# Notice that /usr/sbin/cron is in use (because my system is running normally) I can copy _from_ that file, but I can not overwrite it. Apparenlty, nobody who is claiming this has _tried_ it. Try it yourself and see. You can _not_ replace programs that have their Text section in use (i.e. the code) because the demand pager has that area of the file locked. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Newbie Question About System Update
On Tue, 19 Apr 2005 16:34:37 -0600 (MDT) Warner Losh [EMAIL PROTECTED] wrote: From: Bill Moran [EMAIL PROTECTED] Subject: Re: Newbie Question About System Update Date: Tue, 19 Apr 2005 16:32:37 -0400 Chuck Swiger [EMAIL PROTECTED] wrote: Bill Moran wrote: The system can not replace programs that are in use, This is generally not the case. Unix lets you continue to access a file after it has been deleted, so long as the process hangs on to a file descriptor. This lets you replace programs in use, without running into the same problems that platforms like Windows have. What you say?: bash-2.05b$ su Password: bolivia# cp /usr/sbin/cron /home/wmoran/. bolivia# cp /home/wmoran/cron /usr/sbin/. cp: /usr/sbin/./cron: Text file busy bolivia# mv /usr/sbin/cron /usr/sbin/cron- cp /blah/cron /usr/sbin/cron install does this behind the scenes. I suppose I have to stand corrected. Thanks for putting me straight. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: urgent help
kalin mintchev [EMAIL PROTECTED] wrote: PLEASE REPLY TO [EMAIL PROTECTED] upgraded from 4.6 = 4.10 rel network programs are craching the new system: netstat, ping, the qmail tcp server all of them... sshd is running but when accessing from outside it panics too... what is it? can i turn something off in the kernel?! What process did you follow to update? It sounds to me like you didn't complete the upgrade process, skipped a step, or did it improperly. There's no reason I can think of that upgrading should cause things to panic, unless you did the upgrade process improperly. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading sequence to 4.x from 3.3-R
Dmitry Morozovsky wrote: Dear colleagues, What is the correct way to upgrade FreeBSD from 3.3-R to 4.x? Wow ... that's a bit of a leap. I expect you're going to have problems going that far easily. using recommended (extended a bit) make -DNOCLEAN -DNOPERL -DNOPROFILE -DNOGAMES -DNOMAN buildworld I got === doc c++ -O -pipe -I/ar/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/ar/src/gnu/usr.bin/gperf -c /ar/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc /ar/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc:80: warning: `catch', `throw', and `try' are all C++ reserved words /ar/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc: In function `void operator delete(void *)': /ar/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc:82: declaration of `operator delete(void *)' throws different exceptions... internal:82: ...from previous declaration here *** Error code 1 Currently I simply exclude gperf from bootstrap-tools from Makefile.inc, but it seems a bit hackish... I'm no expert on the source tree, but I would think that you might have an easier time of it if you backup up the system and reinstalled. If that seems terribly impractical, you might do better by stepping it. For example: 1) First upgrade to 3-STABLE. 2) Then upgrade to an early 4.x, such as 4.2-RELEASE 3) Then upgrade to 4-STABLE I do think you're going to have problems if you attempt the upgrade without upgrading perl as well. perl is used in many parts of the system in 4.x, if you don't upgrade it, you may not even be able to build 4.x, and if it does build and install, you may find many utilities don't work. -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: wrong CPU frequency detection
Eugene M. Zheganin wrote: Hi, All. Why does my 4.8-PRERELEASE detect my CPU as 1000 MHz instead of real 1200 MHz ? Just because the processor is rated at 1200 doesn't mean that the motherboard is running it at that speed. Any time I've seen this problem, it was because the motherboard was left to autodetect the CPU speed and didn't do so correctly (don't know why they seem to incorrectly guess 1G) Check your BIOS settings. ===Cut=== FreeBSD 4.8-PRERELEASE #0: Sat Mar 1 12:01:00 YEKT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FREEDOM Timecounter i8254 frequency 1193182 Hz CPU: Intel(R) Celeron(TM) CPU1000MHz (1009.95-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 ===Cut=== I have the same problem on 4.6-RELEASE (real CPU frequency is 1700 MHz): ===Cut=== FreeBSD 4.6-RELEASE #0: Mon Oct 7 17:54:30 YEKST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TIGER Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (1009.95-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 ===Cut=== I have some FreeBSD-boxes running with CPU frequency lower than 1GHz - FreeBSD detects them correctly. Is it some kind of misconfiguration ? Can it cause problems ? Thanks a lot. WBR. -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: fsck problem
Jaime wrote: New info for this problem: S array.p0.s0 crashed S array.p0.s1 up S array.p0.s2 up S array.p0.s3 stale Should I just vinum start at the shell? Well, at this point you've got vinum started now. I would fix the raid problem before bothering with an fsck, if it were me. -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: PCI oddity
Jason Andresen wrote: I'm still curious if this is a problem with FreeBSD, with my motherboard, or with the Cards themselves. Is it unusual for a card to share nicely? Not one manual for any of my cards even mentions IRQ sharing. Then they probably don't. IRQ sharing is one of those things that cards usually brag about if they support. If you have non-sharing cards trying to use a shared interrupt, it won't work. Crashes don't surprise me under these circumstances. -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: DVD writer support in -STABLE?
Gareth McCaughan wrote: I'm thinking about getting a DVD writer as a backup device for use with my -STABLE system. It's not clear to me what level of support there is for this in -STABLE. 1. If I just want to treat a DVD as an unusually large CD, will that just work? I mean, can I build a 4GB ISO9660 filesystem using mkisofs and then write it to DVD using burncd? The documentation for mkisofs implies that arbitrarily large filesystems are possible, but neither the manpage nor the source for burncd says that anything other than plain ol' CDs are supported. 2. What's the state of UFS support, if any? Should I care? 3. Can I assume safely that any DVD writer that claims ATAPI compliance can be used happily with -STABLE? If not: the particular device I'm currently looking at is the Pioneer DVR-A04. It's a DVD-R/W drive; the manufacturer's web page says its interface is ATAPI (ATA/ATAPI-5 MCC3, SFFCINF 8090 Ver.5). The last time I looked at this, the answer was no, you can't burn DVDs in FreeBSD yet I just send an email to Soren to see if he needs hardware to develop with, we're ready to donate a DVD-burner to help. -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Frequent Restarts
Holt Grendal wrote: Is there anyway to get more information about this remotely? Has anyone experienced this? Set dumpdev= to your swap partition in /etc/rc.conf or manually use the dumpon(8) command. This will cause more useful information to be reported (if the system is panicing) as well as crash dumps to be saved which can be analized with gdb. -- Bill Moran Potential Technology http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: samba package
On Monday 04 February 2002 06:05, Rostislav wrote: I just installed my new 4.5R box using the official CDs. It looks very strange but I can't find any samba package in any of 4 CDs? Does someone have any idea why the package wasn't included to CDs? In contrast, the samba package exist in ftp. Did you check all 4 CDs? -- Bill Moran Potential Technology technical services http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ultra160 SCSI
Ladislav Kostal wrote: Hello, I found some notice in ahc(4) driver man page, that U160 SCSI at full speed (160MB/s) is not supported (limited to 80MB/s). Is it still true or is there some other driver with support for U160? You're looking at outdated information. I have three systems running U160 at full speed. I don't remember which version of FreeBSD started to support full spped U160, but if you're not running 4.4, you may want to upgrade before trying. -- Bill Moran Potential Technology http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.5-PRERELEASE (25 Dec) and IBM IC35L040AVER07-0
Eugene Grosbein wrote: On Sat, Dec 29, 2001 at 09:11:07AM +0100, Blaz Zupan wrote: You do not use tags, do you? The default is off I believe and I have not explicitely turned them on, so yes, I'm not using them. Those errors were 100% reproducible. Now I've commented out 'hw.ata.tags=1' from /boot/loader.conf and all errors have disappeared. I still wonder if it software or hardware incompatibility. So do I. See http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/29045 Nobody responded to my last post on this pr, and I have no idea where to go from here without direction. This level of technical debugging is quite beyond me at this time. But the problem still exists, it happened again earlier this week (even with the drives throttled to ata33). What kind of HDD are you using? Personally, I suspect HW problems, and I seem to recall a few months ago, someone else with IBM HDDs complaining about the same thing. Have there been any patches to the ata code that could affect this? If so, I'll update this machine and see if it continues to be a problem. -- Bill Moran Potential Technology http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.5-PRERELEASE -- Pobs in compiling custom kernel
Bernie wrote: 1. Is this the right list for this kind of stuff? or should i post in freebsd-questions instead? Not unless you've determined that it only occurs with -STABLE. Otherwise, you should post to freebsd-questions. 2. Is it ok to send attachment on lists? i have captured the stdout and stderr of make (for the custom kernel) in different files. Can i send them to the list togrther with the kernel config file? That's not good practice. Post snippits of the output that you think are important, and if someone asks you for the entire capture, send it to that person only. Sending large messages to the list will generally not be received well. Thanx a lot. Thanks for being curteous enough to check before posting :) -- Bill Moran Potential Technology http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: dirpref benefit on virtual disks
[since I've yet to see any other replies] Daniel Lang wrote: Hi, as I understood, the new dirpref algorithm can improve performance a lot, but only applies to new created directories. To be able to use it, old existing directories would have to be created new. That's consistent with my understanding of it. Now I have some huge filesystems on RAID partitions. To recreate all their directories involves some hassle, but I would think about doing it. But since these are no real but virtual disks, spread over a set of disks in a hardware raidbox, I'm not sure, if I would even benefit from the better algorithm. It sounded a bit like designed for filesystems on a (single?) disk? My thought would be that, yes, it will improve performance. If you've got a typical 3 disk, RAID-5, a read of the directory still causes a seek on all three disks, and if there's continual seeking across the three disks, you'll see performance degredation. If dirpref can layout the directory info so that it's close together, seek time is reduces, whether on 3 disks or one. That being said, I don't _know_. It would be interesting to test it. Since you're already considering recreating directories, why not do a test to see if it's worth it? Just take a directory tree that's pretty complicated and that was created before you updated the dirpref code. Run a find operation of some sort that traverses the tree and time it. Then, back that tree up and recreate it, re-run the find and time it again and let everyone know if it's worth it. You only need do this with one section of a tree on the drive to determine how much difference it's going to make. Also I would like to know, if there is a certain limit of free space, on the disk, so that the algorithm can actually use the better layout? The disks have some space left, in an absolute way, but not that much from a relative point of view (like 12GB left which is just 6% minfree not taken into account). Have a read of the original paper on FFS (which is in /usr/share/doc if you installed docs with FreeBSD) there is an explanation of why 8% is reserved on the drive - man tunefs comments about this as well. I would assume that the new dirpref code needs plenty of free space to use the optimal layout policy, but I don't know if the minimal free space is still 8% or not, and I don't know if anyone has even tested the new dirpref code to see if that number has changed. -- Bill Moran Potential Technology http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ipfilter/ipnat question
[This belongs on -questions, I've cced] On Thursday 04 October 2001 08:31, Robin P. Blanchard wrote: every now and then in my ipflog i see that ipfilter has blocked packets from the internet destined for machines on my internal network: 01/10/2001 19:30:54.722906 3x dc0 @0:23 b 207.68.131.21,80 - 192.168.0.126,1045 PR tcp len 20 1500 -A IN 01/10/2001 19:40:50.351123 dc0 @0:23 b 207.46.106.81,80 - 192.168.0.126,1033 PR tcp len 20 1500 -A IN 02/10/2001 17:43:47.320547 50x dc0 @0:23 b 128.192.37.79,20 - 192.168.0.126,1148 PR tcp len 20 1500 -A IN my question is: how is it that my internal IPs are getting to these hosts in the first place? shouldn't ipnat have taken care of that on the way out? They probably aren't. Do a traceroute to some well-known sites (such as yahoo). Chances are that your ISP is using RFC-1918 addys on their internal routing. Stupid idea, but it's become commonplace to do it. IPv6 needs to come into use soon. This internet thing is such a mess that it amazes me that it works at all! -- Bill Moran Potential Technology technical services (412) 793-4257 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: VINUM PANIC ON -STABLE
[EMAIL PROTECTED] wrote: I posted a message to -hackers several days ago, complete with a kernel backtrace.The panic is 100% reproducible on my machine running the latest -stable. Does anyone care? My message to Greg Lehey was rejected by his mail server, but I am pretty sure he reads both -hackers and -stable. If you've got something that's a reproducable error, you should file a PR. Use send-pr(1) or the web version (http://www.FreeBSD.org/send-pr.html) -- Where's the robot to pat you on the back? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: prerelease 4.4
klein brock wrote: i don't wanna see this message... does somebody know how ? Is that coming from /etc/motd? -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
kernel won't build from kernel sources
Before I get flamed or anything, let me first say that I don't know for sure that this is broken, but it WAS broken in 4.3-RELEASE. I have been meaning to cut a CD and see if it's still broken in 4.4-PRERELEASE but I've been simply overwhelmed lately. If nobody else gets around to it first, I'll make a concentrated effort to test this over the weekend, but I thought I point out the problem so folks could look at it beforehand, and in case I don't manage to find time for it. Here's the scoop. If you install ONLY the kernel sources (which, according to sysinstall, should allow you to compile a kernel) you are unable to build a kernel. GENERIC won't work, I even tried a super stripped down kernel and it still wouldn't compile. However, if you install FULL sources, it works just fine. I'm pointing this out because I'm guessing that it's something that is easily overlooked in testing - most testers install full source, right? So ... I don't know whether this has been fixed in 4.4-PRERELEASE, but it WAS broken in 4.3-RELEASE. If nobody else manages to verify this by Saturday, I'll make a serious effort to test and find out if it's still an issue. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Q: upgrade from 4.0-RELEASE
Warner Losh wrote: In message [EMAIL PROTECTED] Bill Moran writes: : Feel free to correct me if I'm wrong on this (anyone?) I've upgraded from 4.0-current to 4.3-stable about a month ago. I don't know why he's seeing this problem. Hmmm ... I've had a number of people correct me on this point, so I apologize for posting that guess. I suppose I should do more research (or not answer questions when I don't know the answer in the future.) -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: RELENG_4_3 calls itself -RELEASE?
Why not 4.4.1-RELEASE, 4.4.2-RELEASE, etc It's simple, to the point. Implies upgrades. Allows you to quickly determine exactly how current a particular system is with regards to patches, and follows long-standing conventions. Just my $.02 -Bill Andrew Boothman wrote: [Boy do I wish I hadn't started this now!] On Friday 03 August 2001 7:49 pm, Jordan Hubbard wrote: I like -BEET. It's short, means nothing, and is red. What more could you ask for? :P Indeed! Well put. Unless I hear truly strong and well-reasoned sentiments to the contrary, I will tag and document this as the 4.4-BEET branch when the time comes to create it. While I'm usually all for nonsensical names (my own machine is called spatula), I think we should try and pick something related, but clear. How do we feel about 4.4-RELEASE-PATCH1, 4.4-RELEASE-p1 or 4.4-RELEASEp1 for the first commit RELENG_4_4 and 4.4-RELEASE-p2 for the second ? This idea has already been mentioned by various other people, but seems to have been largely ignored by the rest of the conversation which, quite understandably, became more interested in vegetables and flightless birds. :-) I think this is the best option for several reasons : 1) It makes it clear that the version you are running is basically 4.4-RELEASE plus 'something'. 2) We can tell at a glance whether you are patched against a spacific vulnerability. Security advisories can say patched in 4.4-RELEASE-p5 simply type 'uname -r' to determine if your system has been updated since the vulnerability was patched My original problem with the concept with the -SECURITY name was that you can't tell if you have been patched against something. Of course, just calling it -SECURITY doesn't make it any more obvious, but the patch numbers do make it obvious. So calling a system -BEET, as much as I like the name, only addresses one of my original concerns. Patch numbers would address both. -- Andrew Boothman [EMAIL PROTECTED] http://sour.cream.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Where's the robot to pat you on the back? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Is FreeBSD more secure than Windows NT or Windows 2000?
Sung Nae Cho wrote: One thing that makes me uncomfortable with both Linux and FreeBSD is that unlike Windows NT, both UNIX clones seem to be less secure for a desktop use. ( ** Note clones doesn't mean it's any less better than UNIX, it just means, it's not officially considered UNIX by OPEN-GROUP ** ) I've used Windows NT 4.0 since '98, Linux since '99, FreeBSD since '00 and finally gone FreeBSD only on my laptop. However, unlike, Windows NT 4.0, other people can get access to my confidential files! How? Well, they can just reinstall the FreeBSD without deleting my $HOME directory and as a root, they can access all my files! This is an illusion. Let me borrow your laptop for 15 minutes, and I'll boot off a floppy, read through all your files and give it back to you without you having a clue as to what I've done - no matter what OS you've got installed. The funny security checks that NT/2000 do on install are only an illusion of security. As someone else pointed out, the only way to guarantee the privacy of your files on a stolen HDD is to encrypt them. Actually, this isn't a guarantee, since just about any encryption is crackable if the cracker has enough time on his hands and enough patience. You can only hope that it takes him so long to crack, that by the time he decrypts it the information isn't valuable any more. Using RSA algorithms with large keys ( 1024 ) is a good way to do this. -Bill -- It may be that true happiness is nothing more than the ability to *always* know the right thing to say at the right time, whereas true misery is the state of perpetually saying to oneself, What I *should* have said was... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: JFS
Dag-Erling Smorgrav wrote: Dave Uhring [EMAIL PROTECTED] writes: I just took a look at www.sistina.com and a web site which has its font set to Arial is suspect, IMHO. If they have to use Microsoft products to produce a web site.. Is that the best you could come up with? I mean, you could criticize the ingenuity of their designs, or the quality of their code, or their ability to deliver on their promises - or would that require too much effort? It's so much easier to just dismiss them out of hand because they use a font you don't like on their web page, isn't it? Generally, this is what most people do. I'm not defending Dave, or supporting DES. But many people judge a company by such first appearances. I know people who will dismiss a company as amatuer by the quality of their product packaging. I know my opinion of Wind River has been negatively impacted by the numerous spelling errors I found on their web site the first time I visited. Web pages that only display in M$ browsers also make me feel uncomfortable with a company. and _assuming_ that everyone will have a font just because it comes with Windows falls into that category. On the flip side, the Sistina page displays well even though I don't have that font, so _I_ wasn't put off by it. Other aspects of the page design made me decide not to read further into it, however. (primarily the diffucult-to-read blue on black text on the nav column) -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: JFS
Juha Saarinen wrote: On Sun, 8 Jul 2001, Bill Moran wrote: I know my opinion of Wind River has been negatively impacted by the numerous spelling errors I found on their web site the first time I visited. That's different though -- one person rubbishes the product because the presentation uses a Politically Incorrect typeface, whereas you (quite rightly) assume that if they can't be bothered to run a spelling checker over their Web page, their quality control is somewhat suspect... True, as I pointed out later in my previous post: On the flip side, the Sistina page displays well even though I don't have that font, so _I_ wasn't put off by it. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: JFS
Dave Uhring wrote: You seem to have missed the critical point of that paper. When the system goes completely haywire and either crashes or locks up so hard that a manual reset is required, UFS/softupdates requires a substantial amount of time to run fsck. If you have a very large filesystem, you then have to wait until fsck completes. And if you are lucky, it will not terminate with the suggestion that you run fsck by hand. With a true journalling filesystem this wait is obviated. The last transactions are rerun or truncated and the system boots up. Actually ... according to the article, the system boots up and _then_ determines what needs done to repair the filesystem. Also, the lack of a need for fscking is not the only benefit of RieserFS. In fact, it's a _minor_ improvement. If your system is going down so often that the speed of a fsck is a major factor in the layout of the system, you've got other issues you need to address first! The other issues that might make Reiserfs a good idea (and a possible improvement over UFS) are the various improvements such as small file storage and large directory storage. I know that I'm interested in seeing performance comparisons with regard to these factors, and so far, I've seen none that compare ReiserFS to UFS/softupdates. My $.02 -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: Staying *really stable* in FreeBSD
Is there a reason why you took this off the list? On Wednesday, June 27, 2001 10:52 AM, Mike Porter [SMTP:[EMAIL PROTECTED]] wrote: On Wednesday 27 June 2001 07:11, you wrote: On Tuesday, June 26, 2001 5:07 PM, Chad R. Larson [SMTP:[EMAIL PROTECTED]] wrote: If anyone is taking votes, I disagree. The -STABLE branch is not -BETA in any way that I can see. It's simply a low key development branch. Changes are tested in -CURRENT before being merged into -STABLE, therefore there's nothing -BETA about it. While I agree with most of what you said, I disagree here. Just because *some* testing has been done, doesn't mean it isn't BETA. BETA software is generally believed to be pretty stable, just a few minor kinks to work out. At that point, getting it into the hands of the largest possible cross-section of users makes sense, becuase collectively they are more likely to excercise all of the features. Further, some features may work as intended when the user follows all the correct steps in the correct sequence, but how easy is it to get out of the sequence and break things? (Example (ok, its a bad/simplified example but it demonstrates the point): Actually ... it's a good example. So BETA testing takes place after a good deal of previous in house development happens. This is the alpha test stage. Why do you think they use beta (the SECOND letter of the greek alphbet) to denote the SECOND test? It implies that there is an alpha or first test before. thus -CURRENT is ALPHA level code, STABLE is BETA. That's also a relevent point. alpha and beta are generally used to describe testing sequences in/out of the developer circle. In a company, alpha testing is done by the developers or other employees of the company, while beta testing is done by providing the software to a select group of customers who have volunteered to test the software. This particular model falls apart when you have the FreeBSD development model. Reasons: 1) anyone who wants to test -CURRENT can, thus it doesn't fit typical expectation of alpha 2) the developers are generally also the users 3) The -STABLE branch is not *intended* to be for testing purposed only. It is *intended* to be a useable product. In the commercial world, a beta is NOT INTENDED for regular use, but for testing only. Thus, renaming the -STABLE branch would be a misnomer. Of course, if you assume that STABLE is BETA level code, then you can expect some glitches, and sometimes things WILL slip through the cracks and cause major headaches...but *in general* you should have fairly stable code, with a few bugs in it. You EXPECT (or SHOULD EXPECT) there to be bugs in itthat's part of the development effort. No, according the the handbook, you should not *expect* there to be bugs in -STABLE, You should be wary, as the handbook warns you, but my experience with -STABLE over the last two years is that it's generally pretty reliable. The handbook also states that you should subscribe to the stable mailing list if you intend to track -STABLE, so anyone following the hanbook is going to be well informed when breakage occurs. I believe the recent changes to the handbook did an excellent job of clearing this up. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: Staying *really stable* in FreeBSD
On Wednesday, June 27, 2001 3:14 PM, Mike Porter [SMTP:[EMAIL PROTECTED]] wrote: On Wednesday 27 June 2001 09:44, Bill Moran wrote: Is there a reason why you took this off the list? my mistake (or my mailer's depending on how you look at it). If the majordomo config file for the list included the line reply-to: [EMAIL PROTECTED] then all replies would by defualt go back to the list. While this isn't ALWAYS appropriate, it usually is No problem. I expected as such ... looking back, I had intended that question to mean Should I not be posting to -STABLE but then I *did* post to -STABLE so it was pretty silly to bring it up at all ... snipped much reasonable and well-though discussion, because the last paragraph of your reply makes a point the nullifies most of the argument I agree, but I think that putting things in terms people can understand is also important, and mentioning something along the lines of the above paragraph might help some people better undrstand the relationship between -current, -stable, and -release. To take all the specifics out and state my opinion in one general comment. The statement you make above is the exact reason I don't think that beta is a good name. Folks are used to seeing the label beta on some sort of static release that they can test and compare (beta1, beta2, etc) Whereas -STABLE is a constantly moving target. If you looked into it, there would be what? 20,000 possible versions of 4.3-STABLE so far? And you can grab any one of those versions if you want (like if you know a certain feature appeared after a certain date, but a certain bug didn't appear till a certain date) This is the biggest divergence from a beta type software that I see. On the other hand.I seem to recall the initial post in this sub-thread was something like if we are taking votes 1) I don't think we really are taking votes and 2) even if we were, I think the majority by their failure to chime in is indicating their general pleasure with the status quo. True. Considering the core team hasn't asked for a vote, I assume that they either know what they want to do, or they plan to discuss it amoung themselves. I will agree that -STABLE is somewhat misleading. If we had a single word that meant conservative development, that would be the perfect label for that branch. I still think that beta is not that word, but as you put it, there seems to be general pleasure with the status quo. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: Staying *really stable* in FreeBSD
On Wednesday, June 27, 2001 5:30 PM, Juha Saarinen [SMTP:[EMAIL PROTECTED]] wrote: On Wed, 27 Jun 2001, Bill Moran wrote: In a company, alpha testing is done by the developers or other employees of the company, Once Upon A Time this was true, but no longer. Viz. Microsoft's Technology Preview editions of various pieces of software. Due to lengthening development cycles, companies feel compelled to issue some pretty raw code into the public eye, just to show that they're actually doing something. The mindshare game I guess. True, but I guess it still just seems to me that alpha is a closed-source kinda word that doesn't fit in with any open-source type of development. Might just be my perception of the whole thing. Anyway, code never gets out of the beta stage. ;-) I don't know. I mean, beta says to me, we, as developers, can't find any problems, but this hasn't been tested in the real world yet. Whereas a release tag says we've tested this under real world conditions and have not found any problems I see where you're coming from with that statement, though. Especially open-source development, which is always under scrutiny for the purpose of improvement. Oh, and could you please wrap your lines? Yeah ... I just realized that the only way to keep Outlook from mangling lines is to manually wrap. I'm working on site this week, far away from my comfortable FreeBSD desktop workstation :-( so I'm stuck with Outlook. I think I'll install mutt on one of the servers here and use it to get my email via ssh ... :-) Don't tell my boss. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: sendmail does not return
As a side note: if this is the problem, sendmail will not block _forever_. It will eventually time out. I don't know what the actual value is, but it seems like 5 minutes or something, so it could easily seem like it's frozen. -Bill Mike Tancsa wrote: The place where I have come across this is on DNS timeouts. e.g. if you have an IP address on an interface that has as its DNS a non reachable server (for whatever reason), sendmail will block until it gets an answer either way. Do all the PTR records for your IP addresses on the machine in question return right away ? ---Mike At 02:31 PM 6/18/2001 +0200, Thomas Stratmann wrote: Hi everyone, have the weird problem that not anyone of sendmail, newaliases nor mailq returns (neither does any one of them return any error message or output). This includes the call of sendmail -bd -q30m out of /etc/rc (the same applies if I do this by hand), so I have to hit ^C to continue the boot process. It used to work fine the last time I booted (which means I did not see any errors, and sendmail was up) although I did not change any of my configuration in the mean time. -- If a bird in the hand is worth two in the bush, then what can I get for two hands in the bush? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
rpc.statd mem leak?
I seem to be "memory leak guy" this month ... Is it normal for rpc.statd to soak up 257M (as reported by top in the size column)? The "res" column shows 542K. The machine seems to be functioning just fine otherwise. It just seems a little unusual. It's a 4.2-STABLE (Jan 8) machine and it's servicing 2 NFS connections as well as running samba and netatalk. Not much else going on other than Vinum mirrored drives and nightly backups using dump. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Problems in Memory
Jorge Filipe Andrade wrote: I am to have problems with the memory of my server. I have 384MB, and I have 200MB of Swap, it simply, passed one week You should have more swap than RAM. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Dangerously dedicated (was Re: Really odd BTX halted problem booting FreeBSD on VALinux h)
John Baldwin wrote: It is kind of semantic. However, on the alpha it is hardly dangerous. Nor do we fake a MBR on the alpha (which is what makes it dangerous). The alpha architecture doesn't use MBR's, but the PC arch does. Thus, having a disklabel on the alpha is normal, having one at the start of a PC disk requires ugly hacks that break the PC arch, hence the difference. Do I understand you correctly? Are you saying there are potential problems with a "dangerously dedicated" HDD on a PC? I don't use Micros~1 products on any of my machines (acutally, I use nothing but FreeBSD) so I've assumed that there's no reason to do anything other than "dangerously dedicated". Am I wrong is thinking that?? Is this one of those issues where "if it boots, it'll be fine" or is it something that could bite me later?? -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Where do i ask newbie install questions
[EMAIL PROTECTED] send mail to [EMAIL PROTECTED] with this single line in the body: subscribe freebsd-questions erich alfred heine wrote: I subscribed to this list, but after reading it for the last few days, i dont think this is the place to ask newbie install questions. If you could please point me to the proper forum, i would very much appreciate it. Thanks Erich Heine To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: username with -
Doug Barton wrote: I think a better question is, why does rmuser need to check the validity of the username at all? Should it do wildcarding? If not, it needs to check for invalid chars that could be used to wildcard. On the flipside, wildcarding might be nice. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Stop error in make world
John Reynolds~ wrote:
Well, I just cvsup'ed 1 hour ago and built world. No problems. That segfault
you got when building perl looks really odd. Other people have said that
segfaults during buildworld are generally hardware problems. Most likely
memory.
I'd be surprised ... considering I did a successful `make world' about a
month ago with no problems, and I've done many compilations (Apache,
MySQL, php, ssh) on this machine with no problems prior to this. Still,
it's a possibility, things do wear out/break/etc.
Any chance of you swapping out the memory in the machine?
That's pretty much a last resort ... my goal is to fix this without
having to drive 3.5 hours to the location where it exists. If nothing
else works, I'll do that.
Anyway, just reporting "no errors" here with a fresh tree.
Well, that's good news, it means I've botched something. I think the
mistake is that I accidentally got a 3.X-STABLE tree over top the 4.X
tree and the version of perl from 3.X (whatever version that is) isn't
up to doing some of the chores that are required for a 4.X make world.
My plan of attack at this point is:
make -k buildworld
make installworld
make buildworld
If at that point I have no errors, I'm home free to rebuild a current
kernel and make installworld again.
If I'm still having trouble. I'm going to try cvsdowning to 4.0-STABLE
(which is what the machine was before this all started) and see if I can
get it working.
If that doesn't work and I can still get ssh access to the machine, I'll
get really desperate and try getting a 3.5.1 machine on here.
If that doesn't work, I'm driving 3.5 hours to do a clean installation
(please no)
If anyone has any better attack plans, I'm interested to hear them.
Thanks for all the help so far.
-Bill
--
FreeBSD ('BSD'):
No battles to the death are recalled. It is a small Daemon wearing
sneakers. It
is normally found on Internet servers and powerful desktops, and moves
very
quickly. A kill of this poweful creature is enough to tick off any
sysadmin. It
is highly magical, having the power to serve. It resists DoS and SYN
flood
attacks. Nothing is known about its attack.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: problems with make world (Sunday)
What I've seen in the UPDATING file seems to refer to 3.X upgraded to 4.X As far as I can tell there is no special documented procedure for updating within the 4.X line. Should be able to do everything in the ordinary way. I've done it that way on the current system. Along those same lines ... I'm having trouble with one of my 4.0 servers trying to update it to 4.1 and getting all kinds of weird errors in doing the kernel. Just re-cvsuped and trying again. I cvsuped on Sunday as well. I think maybe something in the system was broken. -Bill Kent Stewart wrote: You didn't read /usr/src/UPDATING. It tells you that you can try a "make world" but if it fails don't complain until you have tried the buildworld, build[install}kernel, installworld sequence. A lot changed between 4.0 and 4.1. For example, a kernel build using the config is not supported after a cvsup. It may work but there can be changes that the buildkernel mode will process. Your kernel config file can be different. You need to compare what you have against GENERIC. It has been 4 or 5 days since I did a cvsup and all of the builds and installs. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
