Problem with USB keyboard during boot screen
Hi. I recently installed 9.0-release on a brand new PC which has an i3 chip. During the initial install I happened to use a USB keyboard from Apple. I installed freebsd/amd64. Everything that I tried worked okay with it. After testing a variety of things, I put the machine in a small rack I have, and hooked up a different USB keyboard to it. Once the machine has booted all the way up to a login: prompt, the newer USB keyboard also works fine. It's from Logitech, and has illuminated keys (if that makes any difference). The thing is, the newer keyboard will not work during the initial boot screen. I see the menu fine, but everything I type using the logitech keyboard is ignored. If I plug in the Apple keyboard, that works fine during the bootup screen. Is there something I could configure to make the Logitech keyboard work during that bootup screen? The thing is that the Apple keyboard has a pretty short USB cable, while the Logitech one has a much longer cable. When I plug in the Logitech keyboard, I get /var/log/messages of: Jan 26 16:54:20 santropez kernel: ugen1.3: Logitech at usbus1 Jan 26 16:54:20 santropez kernel: ukbd0: Logitech Logitech Illuminated Keyboard, class 0/0, rev 2.00/55.01, addr 3 on usbus1 Jan 26 16:54:20 santropez kernel: kbd2 at ukbd0 Jan 26 16:54:20 santropez kernel: uhid0: Logitech Logitech Illuminated Keyboard, class 0/0, rev 2.00/55.01, addr 3 on usbus1 When I plug in the Apple keyboard, I get messages of: Jan 26 16:54:37 santropez kernel: ugen1.4: Apple, Inc. at usbus1 Jan 26 16:54:37 santropez kernel: uhub4: Apple, Inc. Keyboard Hub, class 9/0, rev 2.00/94.15, addr 4 on usbus1 Jan 26 16:54:38 santropez kernel: uhub4: 3 ports with 2 removable, bus powered Jan 26 16:54:39 santropez kernel: ugen1.5: Apple, Inc at usbus1 Jan 26 16:54:39 santropez kernel: ukbd1: Apple, Inc Apple Keyboard, class 0/0, rev 2.00/0.69, addr 5 on usbus1 Jan 26 16:54:39 santropez kernel: kbd3 at ukbd1 Jan 26 16:54:39 santropez kernel: uhid1: Apple, Inc Apple Keyboard, class 0/0, rev 2.00/0.69, addr 5 on usbus1 This is not particularly critical to me, but it'd be nice if I could get the logitech one to work during the bootup screen. -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ 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: Problem with mxge on RELENG_8_1
At 3:21 PM -0400 8/13/10, Robert Healey wrote: I recently updated the central file server/router systems for a pair of research clusters from RELENG_8_0 to RELENG_8_1. After following the proper procedures, the network throughput when pulling files from both machines via mxge0 is 200KB/s or less. Before the update, 50MB/s was the normal rate. Doing some testing, with the 8.1 kernel booted, I can upload files to the server over the 10G link with scp or NFS at the expected rates. I can fetch files from the Internet using this server as the NAT gateway also at the expected rates. Retrieving files from the server over mxge, the throughput falls to 200KB/s. Retrieving files from the server from the onboard Broadcom NIC, rates are as to be expected from gigabit. With 8.0, everything works as expected. Hardware Config 1: Dell Poweredge R610 with 2 Xeon E5530 @ 2.4 GHz, hyperthread disabled and 24GB RAM. Onboard interface is bce. Disk is attached via a PERC 6/E. Internal cluster switch is Dell Powerconnect 6248P. This switch sees excessive large packets on the 10G connection on 8.1, but not 8.0. Hardware Config 2: HP Proliant DL 320G6 with 1 Xeon E5540 @ 2.53GHz, hyperthread enabled and 8GB RAM. Onboard interface is bge. Disk is attached via a HP Smart Array P212. Internal cluster switch is an HP Procurve 2910al. It does not see any packet errors from the 10G link. You're seeing the performance problems with both scp and NFS? Could you get some tcpdumps of a file transfer with both setups (8.0 vs 8.1), just to see if something very odd jumps out? If I'm reading this right, file transfers work at expected speeds if the file is going *to* the server, but you see the slowdown when you're pulling files *from* the server. That sounds similar to a problem with a duplex-mismatch, except of course that you shouldn't be getting into duplex issues on a gigabit network. -- Garance Alistair Drosehn= g...@gilead.netel.rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Instituteor dro...@rpi.edu ___ 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
FreeBSD and iSCSI for disks.
Some friends of mine are looking at the new DroboPro, which makes a lot of disk space available via iSCSI (in addition to firewire 800), and they were wondering how well iSCSI works with FreeBSD. I haven't paid attention to iSCSI support. Is there anyone using it heavily for disk-storage under FreeBSD? Has there been much changed for iSCSI support in the 8.x branch, or is 7.x support working fine? -- Garance Alistair Drosehn= g...@gilead.netel.rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Instituteor dro...@rpi.edu ___ 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: Big problems with 7.1 locking up :-(
At 2:55 PM + 1/12/09, Robert Watson wrote: On Fri, 9 Jan 2009, Garance A Drosihn wrote: At 2:39 PM -0500 1/9/09, Robert Blayzor wrote: On Jan 8, 2009, at 8:58 PM, Pete French wrote: I have a number of HP 1U servers, all of which were running 7.0 perfectly happily. I have been testing 7.1 in it's various incarnations for the last couple of months on our test server and it has performed perfectly. I noticed a problem with 7.0 on a couple of Dell servers. [...] We've since then compiled the kernel under the BSD scheduler to rule that out, and so far so good. Since ULE is now default in 7.1 and not in 7.0, perhaps you can try that? FWIW, the other guy I know who is having this problem had already switched to using ULE under 7.0-release, and did not have any problems with it. So *his* problem was probably not related to SCHED_ULE, unless something has recently changed there. Turns out he hasn't reverted back to 7.0-release just yet, so he's going to try SCHED_4BSD and see if that helps his situation. Scheduler changes always come with some risk of exposing bugs that have existed in the code for a long time but never really manifested themselves. ULE is well shaken-out, having been under development for at least five years, but it is possible that some problems will become visible as a result of the switch. I would encourage people to stick with ULE, but if you're having a stability problem then experimenting with scheduler as a variable that could be triggering the problem may well be useful to help track down the bug. Just to followup on this: My friend did switch back to a 7.1 kernel with SCHED_4BSD, and he still ran into problems. The error messages weren't the same, but errors did happen in the same high disk-I/O situations as the lockup happened with SCHED_ULE. At this point he's fallen back to the 7.0-kernel that he had been running (which also has SCHED_ULE), and all the problems have gone away. So at the moment he's running with a 7.0-ish kernel and the 7.1-release userland, without the hanging problems. So the problem is something in the kernel, but it is *NOT* the scheduler (at least, not in his case). He is not eager to do a whole lot of experiments to track down the problem, since this is happening on busy production machines and he can't afford to have a lot of downtime on them (especially now that the semester at RPI has started up). The systems have some large (2 TB) filesystems on them, and the lockups occur in high disk-I/O situations. He's seeing the problem on one system which is a dual CPU quad-core xeon, and another which is a 64 bit P4 with hyperthreading. The one thing in common between the two setups is that the boot drives + a 3ware controller (with its array of RAID disks) is moved from one machine to the other one: its a 3ware 9500 12 port model, the boot drive is connected to an ICH6 in IDE mode, and yes, I've run it in single, single with hyper threading, and 8 way mode. All 64 bit. We still have no idea where the problem really is. For all we know, someone spilled a Pepsi on it when he wasn't looking... -- Garance Alistair Drosehn= g...@gilead.netel.rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Instituteor dro...@rpi.edu ___ 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: Big problems with 7.1 locking up :-(
At 1:58 AM + 1/9/09, Pete French wrote: I have a number of HP 1U servers, all of which were running 7.0 perfectly happily. I have been testing 7.1 in it's various incarnations for the last couple of months on our test server and it has performed perfectly. So the last two days I have been round upgrading all our servers, knowing that I had run the system stably on identical hardware for some time. Since then I have starte seeing machines lock up. This always happens under heavy disc load. When I bring the machine back up then sometimes it fails to fsck due to a partialy truncated inode. The locksup appear to be disc related [...] One of my friends is also having trouble with lockups on two machines he had upgraded to 7.1. Also seems to be related to heavy disk I/O, although I'm not sure the symptoms are the same as what you report. Both machines had been running 7.0-release without trouble. On at least one of the systems, he's also working with (what I consider) very large file systems (over 2 TB). Both machines are using a 3ware controller with its RAID. I realize that isn't much to go on, but it suggests that there is some problem wider than just your (Pete's) usage. I think his situation is such that lockups like this are simply not acceptable, and the last I heard he was reverting back to 7.0-release. -- Garance Alistair Drosehn= g...@gilead.netel.rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Instituteor dro...@rpi.edu ___ 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: Big problems with 7.1 locking up :-(
At 2:39 PM -0500 1/9/09, Robert Blayzor wrote: On Jan 8, 2009, at 8:58 PM, Pete French wrote: I have a number of HP 1U servers, all of which were running 7.0 perfectly happily. I have been testing 7.1 in it's various incarnations for the last couple of months on our test server and it has performed perfectly. I noticed a problem with 7.0 on a couple of Dell servers. [...] We've since then compiled the kernel under the BSD scheduler to rule that out, and so far so good. Since ULE is now default in 7.1 and not in 7.0, perhaps you can try that? FWIW, the other guy I know who is having this problem had already switched to using ULE under 7.0-release, and did not have any problems with it. So *his* problem was probably not related to SCHED_ULE, unless something has recently changed there. Turns out he hasn't reverted back to 7.0-release just yet, so he's going to try SCHED_4BSD and see if that helps his situation. -- Garance Alistair Drosehn= g...@gilead.netel.rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Instituteor dro...@rpi.edu ___ 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: 6.2: maillog grows, newsyslog's misbehaving ?
At 1:08 PM +0200 5/28/07, Andreas Klemm wrote: Hi, discovered that the maillog file on my freebsd Desktop grows and grows (now at 50MB). According to the newsyslog.conf file it should be trimmed every night at midnight. /var/log/maillog640 7 *@T00 JC Is it a prerequisite, that the system then runs 24x7 so that the newsyslog default settings work ? As mentioned in the man page for newsyslog.conf : If a time is specified, the log file will only be trimmed if newsyslog(8) is run within one hour of the specified time. You could force a rotate by running newsyslog yourself: /usr/sbin/newsyslog -F /var/log/maillog but that would be a one-time fix. There is a startup file for newsyslog in /etc/rc.d which runs the program one-time at startup. You could set an alternate value for the variable 'newsyslog_flags' in your /etc/rc.conf file, and use that to do the checks you want at startup. This would probably mean creating a duplicate newsyslog.conf file. So, to answer your question: Yes, the default settings for newsyslog.conf do assume that your system is running 24x7. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and make -j# buildworld usability
At 4:31 PM +0200 10/13/06, Buki wrote: Hi, I searched the archives and web a little but found many different opinions on stability/usability of using make -j# with buildworld (and buildkernel). So I am asking if it is a good idea to use make -j on production boxes. It depends on the target. There are no bugs in 'make -j' per se, but a makefile target has to pay attention to some extra details if that specific target is going to work reliably when using '-j'. You are asking about two different targets. It should be safe to use -j on 'make buildworld', and in fact I do that all the time. Most of my systems are dual-CPU or dual-core, and -j makes the buildworld go significantly faster. *Occasionally* that does not work (particularly if you are following the freebsd-current branch), but any problems in that target are fixed as soon as they are noticed. In the past it has not been safe to use -j on 'make buildkernel', so I never do that. You probably wouldn't gain all that much time by using -j on 'make buildkernel' -- or at least not as much time as you'll lose the first time it does not work right. So I'm sure you see plenty of people say DON'T DO THAT!! when it comes to -j and 'make buildkernel'. Some work is now being done so that -j can be reliably used on 'make buildkernel', but I don't think that has been completed yet. For now, my own opinion is that you're not going to save enough time with -j on buildkernel to justify the amount of time you'll lose if it does not work. That is my answer for today, but I expect -j for buildkernel will be more reliable as time goes on. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
At 8:42 AM -0700 10/11/06, Jason Stone wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Though I admit RELENG_4 is getting dusty, it is not rusty. I believe it is still used in many places because of its stability and performance. [...] Is it envisageable to extend the RELENG_4's and RELENG_4_11's EoL once more ? Yes, I'm also voting for it. I realize that resources to keep chasing this stuff are in limited supply, but if you solicit the opinion of the community, I'd bet that more people would rather see 4.x support continue than 5.x support. While this is an interesting idea, please realize that if we are supporting 6.x (and we are!), then it is much less work to also support 5.x than it is to support 4.x instead of 5.x. The effort for one is not the same as the effort for the other. But I do agree that this is an interesting idea. In a different message, Dan Lukes wrote: Even if no new ports will be compilable on 4.x, even if the old ports will not be updated with exception of update caused by security bug, I vote for delaying EOL of 4.11 That's easy to say. But then that security bug will be in an old version of openssh, and to fix it you'll need to update *both* openssh and openssl, and to compile openssl you'll need a newer version of, oh, some compiler. Or the latest libtool. Or it will assume a variety of changes have been made to base-system include files under /usr/include/**.h. (Note that I face this very issue with a variety of old Solaris and IRIX machines here at work. It's one thing to say Oh, I'll just apply one little security fix, and it's another when you figure out it's going to take you two weeks of solid work to do successfully do that) More to the point, we might not even know there *is* a security exposure in the system you are running. Maybe someone stumbles upon a new exploit in an ancient version of some-component, but everyone running 5.x and 6.x and 7.x is already running the newer version. Thus, we won't even know that 4.x users have a serious security issue which needs to be fixed. You can't just keep voting to say support me forever, and have it cost nothing. Someone, somewhere, has to put up the time and effort to actually do that support. And realistically, that someone has to be the people who are actively running 4.x. Me, I have no desire to run 4.x. I have become too accustomed to a variety of nice features which are in 6.x. I'm also in the process of replacing two of my PC's (because they are having hardware trouble), and once I do that I only have one PC which will even bootup in 4.x -- and that is a 10-year-old PC which I hope to replace before the end of the year. (of course, I'm only one freebsd developer, and I do not claim to be speaking for [EMAIL PROTECTED] or [EMAIL PROTECTED] I'm just saying, more and more FreeBSD developers are actively running on newer hardware, and thus that is where their expertise is...) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
At 12:42 AM +0200 10/12/06, Dan Lukes wrote: As I'm not commiter, I'm allowed to submit PR and speak. I'm trying both. This letter is speak part. Understood. But this has been announced for awhile. If the people who actually depend on 4.x can find the resources to support it, I am fine with them doing that work. I was running 4.x on a production server until just about six months ago. But now I am not. I do have a full-time job, and my hobby programming is going to go into the operating system I run on the hardware I own. It isn't going to go into *your* hardware that you want to see supported, for free, for as long as you can keep voting that SOMEONE ELSE must do a bunch of free work just for your peace-of-mind. Your 4.x system is not doing to die when we EOL 4.x. We're only saying that it is not going to see any additional work on it in the official FreeBSD repository. None of us are going to break into your house and smash your currently-running system. This is an open-source project. If it really is as easy to support 4.x with security fixes as you think it is, then you (all of you who depend on a 4.x system) should be able to do that work without help from us (the people running AMD64, ARM, PowerPC, Sparc64, or even just recent i386 hardware which is not supported by 4.x). That's it. The entire rest of your message is irrelevant to the issues here. I very soon will not own any hardware which can even boot up 4.x, so you can be sure that I will not be providing any support for your continued piece-of-mind. If I do not run a given operating system, then I can not claim to support it. That fact is not going to change simply because you vote on it. I don't want to sound unsympathetic here, because up until just six months ago I was also depending on security fixes for 4.x. But after having two of my personal PC's fried (due to a broken air-conditioner), I have now moved on. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.1-STABLE: Unexplained power off
At 7:59 PM +0300 8/15/06, Android Andrew [:] wrote: Yes, nothing changed. Problem could be in anything: memory, raid controller, network adapter, power supply, bios and so on. But to test it all empirically will take too much time. The most annoying thing in this situation is absence of any system/kernel messages or reports that could explain something. Is there any methodology of troubleshooting in similar situations? It can be very tedious to pin something like this down. I had something like this hit with one system of mine, which would die on 6.x-current (I think it was), but still work fine on 5.x-stable (I think it was. A dual- boot system, but I forget exactly which releases). After trying to pin it down to an update to 6.x, I eventually got all the way back to the exact same snapshot I had been running before the trouble started, but the trouble still existed. I even did a clean- install of the 6.x system, from some original CD's that were *before* the problem started, and yet I still had problems. And then I started to occasionally see the same problem on the 5.x system. And then more frequently. And finally it got to the point that the machine would not boot up at all. Not even 'POST'. It was a dead parrot. It ended up that something had gone wrong with the motherboard itself. It was about two months from the time I first started to see problems to the point where it completely died. It was a very frustrating two months! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird problems with 'pf' (on both 5.x and 6.x)
At 9:30 PM +0200 7/28/06, Stefan Bethke wrote:
Am 28.07.2006 um 03:57 schrieb Garance A Drosihn:
It occurred to me that it might be more informative to
see the transaction from the *freebsd* side of things,
since that's the machine running pf! So, here is a
similar set of two lpq's, as seen from the print-server
side of the connection. It seems to be telling the
same basic story, as far as I can tell.
It's just showing that no ACKs come back. Can you see
if anything showing pflog0 with tcpdump?
Thanks for the reply. I'll check that when I get a chance
to turn the machine back on. (the air-conditioning for
our offices just died -- AGAIN -- so I had to shut down
most of my machines today).
That output should also tell you which rule forced the
rejection.
There is only one rule. The config file I'm testing with
has three comment lines, and:
pass out quick proto { tcp, udp } all keep state
That's it. That's the entire /etc/pf.conf file.
What I do find curious is that the client keeps using
port 1023 consistently. I was under the impression that
reusing the same port number (thus having the same
src-ip/port+dst-ip/port tuple) shouldn't work, because
old packets could arrive after the original connection
was closed; that's what the CLOSE_WAIT state in netstat is.
Hmm. Well, I did wait a few seconds between the two lpq's,
just so it would be easier tell them apart in the packet dumps.
Perhaps solaris is quicker to reuse ports, while 'pf'
remembers that src-ip/port+dst-ip/port tuple for a
longer stretch of time?
But if so, there were seven seconds between the end of the
first 'lpq' and the first attempt to start a connection for
the second one. The 'pf' side didn't start returning ACK's
until 111 seconds after the first connection had closed.
That seems like a pretty long time to wait.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Weird problems with 'pf' (on both 5.x and 6.x)
It happens that I noticed two odd networking problems recently.
One of them is easily reproducible, and I have it tracked down
to one innocuous-looking line in my /etc/pf.conf. The other
is a problem in a chat server that I run, with a few hundred
people on it, and is much more of a hassle to reproduce. But
turning off 'pf' to solve the first problem seems to have
also solved the second problem, so I assume both problems
come from the same culprit.
Once I figured out how to reproduce the problem, it seems so
easy to reproduce that I find it odd that no one else has
run into it. But I also do not notice any PR's that seemed
to describe the problem. I'd appreciate it if people would
try to duplicate the problem on some other machines.
This problem has been seen on:
5.x-stable as built on Mon Jul 24
6.x-stable as built on Mon Jul 17
(as well as several earlier snapshots of both 5.x and 6.x).
I have a freebsd box which is the server for a print queue
named 'bill', and is running pf. I have other machines which
reference that queue. It seems that machines on the same
subnet as the server-box do not exhibit the problem. But
for other machines, if I do 'lpq -Pbill' twice in rapid
succession, then the second one will hang.
After some futzing around, I determined that if my pf.conf
has only the lines:
# Filtering: the implicit first two rules are
#pass in all
#pass out all
then I can do many many lpq's in a row, without any trouble.
But if I restart pf after adding these lines to pf.conf:
# Allow all outgoing tcp and udp connections and keep state
pass out quick proto { tcp, udp } all keep state
then I have the problem where the second 'lpq' from a remote
host will hang, if it is done right after the first one.
That's right. I add a rule which just does quick passing
for *outbound* connections, and somehow that screws up
(blocks?) *incoming* connections. I have no rules which
should block any packets at all, so my guess is that some
packets are getting lost, delayed, or corrupted somewhere.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird problems with 'pf' (on both 5.x and 6.x)
At 9:07 PM -0400 7/27/06, Garance A Drosihn wrote:
But if I restart pf after adding these lines to pf.conf:
# Allow all outgoing tcp and udp connections and keep state
pass out quick proto { tcp, udp } all keep state
then I have the problem where the second 'lpq' from a remote
host will hang, if it is done right after the first one.
The client-machine which is doing the lpq is a solaris
machine, so here is the 'snoop' output from that side
of things. Disclaimer: I'm not a networking expert,
so I'm hoping someone else will find this a lot more
obvious than I do.
Here's the packets from the first 'lpq', with various
names changed to protect the innocent (and to reduce
the wrapping a little bit...):
1 0.0 lpq-client - print-serv ETHER Type=0800 (IP), size = 62 bytes
1 0.0 lpq-client - print-serv IP D=128.113.000.001
S=128.113.002.002 LEN=48, ID=13267
1 0.0 lpq-client - print-serv TCP D=515 S=1023 Syn
Seq=1503722122 Len=0 Win=24820 Options=nop,nop,sackOK,mss 1460
1 0.0 lpq-client - print-serv PRINTER C port=1023
2 0.00068 print-serv - lpq-client ETHER Type=0800 (IP), size = 62 bytes
2 0.00068 print-serv - lpq-client IP D=128.113.002.002
S=128.113.000.001 LEN=48, ID=4007
2 0.00068 print-serv - lpq-client TCP D=1023 S=515 Syn
Ack=1503722123 Seq=1874442309 Len=0 Win=65535 Options=mss
1460,sackOK,eol
2 0.00068 print-serv - lpq-client PRINTER R port=1023
3 0.00072 lpq-client - print-serv ETHER Type=0800 (IP), size = 54 bytes
3 0.00072 lpq-client - print-serv IP D=128.113.000.001
S=128.113.002.002 LEN=40, ID=13268
3 0.00072 lpq-client - print-serv TCP D=515 S=1023
Ack=1874442310 Seq=1503722123 Len=0 Win=24820
3 0.00072 lpq-client - print-serv PRINTER C port=1023
4 0.00088 lpq-client - print-serv ETHER Type=0800 (IP), size = 63 bytes
4 0.00088 lpq-client - print-serv IP D=128.113.000.001
S=128.113.002.002 LEN=49, ID=13269
4 0.00088 lpq-client - print-serv TCP D=515 S=1023
Ack=1874442310 Seq=1503722123 Len=9 Win=24820
4 0.00088 lpq-client - print-serv PRINTER C port=1023 \3bill\n
5 0.03003 print-serv - lpq-client ETHER Type=0800 (IP), size = 132 bytes
5 0.03003 print-serv - lpq-client IP D=128.113.002.002
S=128.113.000.001 LEN=118, ID=4045
5 0.03003 print-serv - lpq-client TCP D=1023 S=515
Ack=1503722132 Seq=1874442310 Len=78 Win=65535
5 0.03003 print-serv - lpq-client PRINTER R port=1023 Warning: bill is
6 0.03014 print-serv - lpq-client ETHER Type=0800 (IP), size = 60 bytes
6 0.03014 print-serv - lpq-client IP D=128.113.002.002
S=128.113.000.001 LEN=40, ID=4046
6 0.03014 print-serv - lpq-client TCP D=1023 S=515 Fin
Ack=1503722132 Seq=1874442388 Len=0 Win=65535
6 0.03014 print-serv - lpq-client PRINTER R port=1023
7 0.03020 lpq-client - print-serv ETHER Type=0800 (IP), size = 54 bytes
7 0.03020 lpq-client - print-serv IP D=128.113.000.001
S=128.113.002.002 LEN=40, ID=13270
7 0.03020 lpq-client - print-serv TCP D=515 S=1023
Ack=1874442388 Seq=1503722132 Len=0 Win=24820
7 0.03020 lpq-client - print-serv PRINTER C port=1023
8 0.03022 lpq-client - print-serv ETHER Type=0800 (IP), size = 54 bytes
8 0.03022 lpq-client - print-serv IP D=128.113.000.001
S=128.113.002.002 LEN=40, ID=13271
8 0.03022 lpq-client - print-serv TCP D=515 S=1023
Ack=1874442389 Seq=1503722132 Len=0 Win=24820
8 0.03022 lpq-client - print-serv PRINTER C port=1023
9 0.03074 lpq-client - print-serv ETHER Type=0800 (IP), size = 54 bytes
9 0.03074 lpq-client - print-serv IP D=128.113.000.001
S=128.113.002.002 LEN=40, ID=13272
9 0.03074 lpq-client - print-serv TCP D=515 S=1023 Fin
Ack=1874442389 Seq=1503722132 Len=0 Win=24820
9 0.03074 lpq-client - print-serv PRINTER C port=1023
10 0.03132 print-serv - lpq-client ETHER Type=0800 (IP), size = 60 bytes
10 0.03132 print-serv - lpq-client IP D=128.113.002.002
S=128.113.000.001 LEN=40, ID=4047
10 0.03132 print-serv - lpq-client TCP D=1023 S=515
Ack=1503722133 Seq=1874442389 Len=0 Win=65534
10 0.03132 print-serv - lpq-client PRINTER R port=1023
and then here is the packets from the second 'lpq', done
right after the first one. It looks like the problem is
in the initial handshaking to get the connection started:
11 7.19194 lpq-client - print-serv ETHER Type=0800 (IP), size = 62 bytes
11 7.19194 lpq-client - print-serv IP D=128.113.000.001
S=128.113.002.002 LEN=48, ID=13273
11 7.19194 lpq-client - print-serv TCP D=515 S=1023 Syn
Seq=1505511645 Len=0 Win=24820 Options=nop,nop
Re: Weird problems with 'pf' (on both 5.x and 6.x)
At 9:18 PM -0400 7/27/06, Garance A Drosihn wrote:
At 9:07 PM -0400 7/27/06, Garance A Drosihn wrote:
But if I restart pf after adding these lines to pf.conf:
# Allow all outgoing tcp and udp connections and keep state
pass out quick proto { tcp, udp } all keep state
then I have the problem where the second 'lpq' from a remote
host will hang, if it is done right after the first one.
The client-machine which is doing the lpq is a solaris
machine, so here is the 'snoop' output from that side
of things.
It occurred to me that it might be more informative to
see the transaction from the *freebsd* side of things,
since that's the machine running pf! So, here is a
similar set of two lpq's, as seen from the print-server
side of the connection. It seems to be telling the
same basic story, as far as I can tell.
aside
But if there is a bug somewhere, then might it
be that the same bug which effects 'pf' would
also confuse what tcpdump would report, when
running tcpdump on the same machine?
/aside
(316) santropez/root # tcpdump -X -r
/tmp/gadchecks/all-060727.212311 host lpq-client
reading from file /tmp/gadchecks/all-060727.212311, link-type EN10MB (Ethernet)
21:23:32.175093 IP (tos 0x0, ttl 63, id 53775, offset 0, flags [DF],
proto: TCP (6), length: 48) lpq-client.1023 print-serv.printer: S,
cksum 0x6b2c (correct), 2119630748:2119630748(0) win 24820
nop,nop,sackOK,mss 1460
0x: 4500 0030 d20f 4000 3f06 36af 8071 1985 [EMAIL PROTECTED]
0x0010: 8071 18a2 03ff 0203 7e56 ff9c .q..~V..
0x0020: 7002 60f4 6b2c 0101 0402 0204 05b4 p.`.k,..
21:23:32.175205 IP (tos 0x0, ttl 64, id 4488, offset 0, flags [DF],
proto: TCP (6), length: 48) print-serv.printer lpq-client.1023: S,
cksum 0x0bfa (correct), 2140553600:2140553600(0) ack 2119630749 win
65535 mss 1460,sackOK,eol
0x: 4500 0030 1188 4000 4006 f636 8071 18a2 [EMAIL
PROTECTED]@..6.q..
0x0010: 8071 1985 0203 03ff 7f96 4180 7e56 ff9d .qA.~V..
0x0020: 7012 0bfa 0204 05b4 0402 p...
21:23:32.175787 IP (tos 0x0, ttl 63, id 53776, offset 0, flags [DF],
proto: TCP (6), length: 40) lpq-client.1023 print-serv.printer: .,
cksum 0xd6c8 (correct), 1:1(0) ack 1 win 24820
0x: 4500 0028 d210 4000 3f06 36b6 8071 1985 E..([EMAIL PROTECTED]
0x0010: 8071 18a2 03ff 0203 7e56 ff9d 7f96 4181 .q..~VA.
0x0020: 5010 60f4 d6c8 P.`.UU
21:23:32.175935 IP (tos 0x0, ttl 63, id 53777, offset 0, flags [DF],
proto: TCP (6), length: 49) lpq-client.1023 print-serv.printer: P,
cksum 0xc80d (correct), 1:10(9) ack 1 win 24820
0x: 4500 0031 d211 4000 3f06 36ac 8071 1985 [EMAIL PROTECTED]
0x0010: 8071 18a2 03ff 0203 7e56 ff9d 7f96 4181 .q..~VA.
0x0020: 5018 60f4 c80d 0370 6269 6c6c 3264 P.`..bill
0x0030: 0a .
21:23:32.204946 IP (tos 0x0, ttl 64, id 4526, offset 0, flags [DF],
proto: TCP (6), length: 118) print-serv.printer lpq-client.1023: P,
cksum 0x5bcb (correct), 1:79(78) ack 10 win 65535
0x: 4500 0076 11ae 4000 4006 f5ca 8071 18a2 [EMAIL
PROTECTED]@q..
0x0010: 8071 1985 0203 03ff 7f96 4181 7e56 ffa6 .qA.~V..
0x0020: 5018 5bcb 5761 726e 696e 673a P...[...Warning:
0x0030: 2070 6269 6c6c 3264 2069 7320 646f 776e .bill.is.down
0x0040: 3a20 5468 6973 2071 7565 7565 2069 7320 :.This.queue.is.
0x0050: 666f 7220 4761 7261 6e63 6520 7465 7374 for.Garance.test
0x0060: 696e 672e 2073 742f 3678 0a6e 6f20 656e ing..st/6x.no.en
0x0070: 7472 6965 730a tries.
21:23:32.204988 IP (tos 0x0, ttl 64, id 4527, offset 0, flags [DF],
proto: TCP (6), length: 40) print-serv.printer lpq-client.1023: F,
cksum 0x3765 (correct), 79:79(0) ack 10 win 65535
0x: 4500 0028 11af 4000 4006 f617 8071 18a2 E..([EMAIL
PROTECTED]@q..
0x0010: 8071 1985 0203 03ff 7f96 41cf 7e56 ffa6 .qA.~V..
0x0020: 5011 3765 P...7e..
21:23:32.205701 IP (tos 0x0, ttl 63, id 53778, offset 0, flags [DF],
proto: TCP (6), length: 40) lpq-client.1023 print-serv.printer: .,
cksum 0xd671 (correct), 10:10(0) ack 79 win 24820
0x: 4500 0028 d212 4000 3f06 36b4 8071 1985 E..([EMAIL PROTECTED]
0x0010: 8071 18a2 03ff 0203 7e56 ffa6 7f96 41cf .q..~VA.
0x0020: 5010 60f4 d671 P.`..q..UU
21:23:32.205755 IP (tos 0x0, ttl 63, id 53779, offset 0, flags [DF],
proto: TCP (6), length: 40) lpq-client.1023 print-serv.printer: .,
cksum 0xd670 (correct), 10:10(0) ack 80 win 24820
0x: 4500 0028 d213 4000 3f06 36b3 8071 1985 E..([EMAIL PROTECTED]
0x0010: 8071 18a2 03ff 0203 7e56 ffa6 7f96 41d0 .q..~V
Re: NFS Locking Issue
At 9:13 PM -0400 7/1/06, Francisco Reyes wrote: John Hay writes: I only started to see the lockd problems when upgrading the server side to FreeBSD 6.x and later. I had various FreeBSD clients, between 4.x and 7-current and the lockd problem only showed up when upgrading the server from 5.x to 6.x. It confirms the same we are experiencing.. constant freezing/locking issues. I guess no more 6.X for us.. for the foreseable future.. I don't know if this will be of any help to anyone, but... I recently moved a network-based service from a 4.x machine to a 6.x machine. Despite some testing in advance of the switch, many people had problems with the service. I booted to a somewhat out-of-date snapshot of 5.x on the same box. I still had problems, but it didn't seem as bad, so I stuck with the 5.x system. Some problems turned out to be bugs in the service itself, and were eventually found and fixed. However, one set of problems on that out-of-date snapshot of 5.x were solved by adding: net.inet.tcp.rfc1323=0 to /etc/sysctl.conf. The guy who suggested that said it avoided a bug which was fixed in later versions of either 5.x or 6.x, I forget which. Of interest is that the bug was such that some people connecting to the service were never bothered by the bug, while other people could not use the service at all until I turned off tcp.rfc1323 . I have a test version of the same service running on a different FreeBSD/i386 box, and that box is now updated to freebsd-stable as of June 10th. Lo and behold, someone connecting to that test box reported some problems. So I typed in 'sysctl net.inet.tcp.rfc1323=0', and his problem immediately disappeared. So, it might be that there is still some problem with the rfc1323 processing, or that the bug which had been fixed has somehow been re-introduced. In any case, people who are experiencing problems with NFS might want to try that, and see if it makes any difference. It does strike me as odd that some people are having a *lot* of trouble with NFS under 6.x, while others seem to be okay with it. Perhaps the difference is the network topology between the NFS server and the NFS clients. Obviously, this is nothing but a guess on my part. I am not a networking guru! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: swap performance under 6.1
At 12:03 AM -0400 4/12/06, Kris Kennaway wrote: On Tue, Apr 11, 2006 at 10:43:32PM +, David E. Cross wrote: I saw under http://www.freebsd.org/releases/6.1R/todo.html that swap performance under 6.x is slower then 4.X, and this is listed as not done. I noticed that 6.1 seemed to be a dog, but 6.0 I thought was better. As a test I installed 6.0 and 6.1 in parallel on my laptop with identical ports trees (and packages) Note... and 6.0 does feel a lot more responisve to swapping; I would be eager to help track this down if someone could give me some pointers. If I have to _guess_ as to a problem it would seem like some of the scheduling priorities changed. I didn't think this was a 6.1 regression compared to 6.0, but 6.x compared to 4.x. It would be good to try and quantify any performance differences here - so far it's just a bunch of people's subjective opinions (including mine) after upgrading from 4.x. In Dave's case, the tests are explicitly 6.0-release vs [EMAIL PROTECTED] Those are the two installations he has on his laptop, which he is comparing to each other via dual- booting. The thing is, he's not sure how to get the numbers to back up the performance feel that he's experiencing. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: swap performance under 6.1
At 11:44 AM -0600 4/12/06, Scott Long wrote: Garance A Drosihn wrote: At 12:03 AM -0400 4/12/06, Kris Kennaway wrote: I didn't think this was a 6.1 regression compared to 6.0, but 6.x compared to 4.x. It would be good to try and quantify any performance differences here - so far it's just a bunch of people's subjective opinions (including mine) after upgrading from 4.x. In Dave's case, the tests are explicitly 6.0-release vs [EMAIL PROTECTED] Those are the two installations he has on his laptop, which he is comparing to each other via dual- booting. The thing is, he's not sure how to get the numbers to back up the performance feel that he's experiencing. Is he using the same swap partitions for both of the dual-booted OS's? If not, he's measuring the speed of the disk at the outer tracks vs the inner tracks. There may indeed be performance issues in the OS, but they need to be quanitfied in a controlled environment and not be subject to things like this. David has been talking about this on a local chat system for a week or two now, but apparently he doesn't track the freebsd mailing lists as much as I do... From a comment he made on that chat system: - As an additional datapoint, I am actually sharing the - swap partition between the 6.0 and 6.1 partitions, so - that should eliminate any problems there. Now is the - 6.1 partition itself has disk issues it could still - explain my problems - OS's are on the same physical drive, different partition, - GENERIC for 6.0 and 6.1 It wouldn't surprise either me or David if this was something specific to his system or his setup, but we're running out of ideas of what that would be. (and we're both busy juggling a few other things in our main jobs, so we're probably not as focused on this as issue we would like to be...). -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ``shutdown -p now'' not working in 5.4 STABLE
At 8:43 PM -0700 8/4/05, Mike Eubanks wrote: On Thu, 2005-08-04 at 19:14 -0400, Garance A Drosihn wrote: Hmm. The more I think about this, the more I think I tripped across something similar once. I think it was something like I turned on 'APM' somewhere, or I added it to my kernel, or something. For power-down, you need to be using ACPI, not APM. But from your dmesg output, it looks like you are using ACPI, so I am probably not helping much with that guess either. Ok, I built APM into the kernel and gave it a few tries, fiddling with different things. Sorry, my comments were not as clear as they should have been. What I meant is that my problem was *caused* by adding APM into the mix, when it should not have been there. That's what I meant by: For power-down, you need to be using ACPI, not APM. But all of this is just vague memory anyway. I haven't had any problems with my machines powering down for quite awhile now. (through many different system builds...) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ``shutdown -p now'' not working in 5.4 STABLE
At 1:32 PM -0700 8/4/05, Mike Eubanks wrote: I have finished migrating my system from 5.1-RELEASE to 5.4-STABLE. The system no longer powers down using either the `shutdown -p now' or `acpiconf -s 5' commands. Instead it always restarts. This won't help much, but I have a system running 5.4-STABLE as of Thu Jul 28, and `shutdown -p now' works on that. Dual-athlon. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quality of FreeBSD
At 8:50 AM -0400 7/21/05, MikeM wrote: On 7/21/2005 at 8:29 PM Daniel O'Connor wrote: | | I think the best way to rectify this is to test RC candidates | on YOUR hardware.. This finds the bugs you need fixed at a | time when people are very receptive to fixing them. | | It's not realistic for the release engineer to test on a lot | of hardware as they are very busy doing other things. = Your comment presupposes that most of the bugs are specific to one piece of hardware, I doubt that is a valid assertion. I would offer that most of the bugs are not present in source code specific to a certain piece of hardware, ... Some problems are not tied to one specific piece of hardware, but to the combination of different hardware. I also went through a lot of pain with ATA problems for awhile there, and I was fed up enough that I tried to buy my way out of the problem. I ended up with three different SATA controllers, and two different SATA hard disks. The thing was, the problems I saw depended on the *combination* of a hard disk and SATA controller. My real-SATA hard drive would fail (in some ways) when connected to one SATA controller, but not to the other. And my fake-SATA drive would *work* on the controller which the real-sata drive failed on, but fail on the controller the real-sata drive worked on! There is no question that this was infuriating for me, so I can sympathize with your frustration. But I helped Søren get some hardware he needed for testing, and things gradually improved. But the problems weren't specific to the hard drive I was using, or the SATA controller I was using. They depended on the combination of pieces that were in my PC. Once a bug is reported, and that bug can be reproduced on the hardware of the development team, then that bug should not reappear again, In my case, the development team needed to *buy* hardware to reproduce some of the problems I was seeing. But their hardware still isn't *exactly* the same as mine. So, they made some fixes which solved problems on their hardware and (happily) on mine. But it is certainly possible for some future change to work perfectly fine on their hardware, and *not* work on mine. There is still no substitute for testing on your hardware, with some sort of real-world loads. The project, as such, simply can not test all combinations of hardware, on all kinds of real-world loads. Even if we had a huge collection of PC's to test on, we're not necessarily going to throw the same kinds of loads on those machines as you deal with. I should note that *all* of my SATA-based hardware is stuff that was not supported at all under 4.x. So it's awkward for me to complain too loudly, because I *do* want SATA, and the only way for FreeBSD to support these new controllers was to make changes to some previously-working code. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0-BETA1 Available
At 1:06 PM +0200 7/16/05, Øystein Holmen wrote: I was looking for a place to download 6.0-BETA1-powerpc-bootonly.iso to test om my PowerMac G4. But I cannot find it on any of the ftp-sites og mirrors. Where can I download it? It may have been taken down. There were a few problems with the iso's of 6.0-beta1 for PowerPC. If you're interested in PowerPC, you might want to join the freebsd-ppc mailing list, and send questions there. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /sbin/nologin
At 3:40 PM -0500 4/7/05, Frank Knobbe wrote: Greetings, I just noticed that the /etc/passwd files contains the shell /usr/sbin/nologin by default on many users. Shouldn't that be /sbin/nologin instead? It was moved from /sbin/nologin to /usr/sbin/nologin, for reasons that were tied to changing /bin and /sbin to be dynamically-linked binaries (instead of having them all statically-linked). -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Promise FastTrak Tx4200 FreeBSD 5.3
At 8:50 AM +1000 3/9/05, Simon Litchfield wrote: Hi folks Anyone have any ideas on the Promise PDC20319 (Fasttrak S150 TX4)? We intend to run 5.3 release on this machine. Hmm. Looking at sys/dev/ata/ata-chipset.c, it looks like that chipset is known by 5.3-release. I know Søren has said that he has had more cooperation from Promise than from some other card makers, so I would *think* that this card would work fine. But I don't know for sure. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patch: fix 30 second hang while resuming
re@ note: This might be important for 5.4-release At 5:59 PM -0800 2/27/05, Nate Lawson wrote: Garance A Drosihn wrote: One minor point: Søren is on vacation right now. I *think* he will be getting back around March 5th Augh. Not the most convenient circumstances. I'm happy to work with someone else if necessary. Is this something which only comes up in 6.x? Or is the same thing happening in 5.x too? There are two bugs I sent in two separate messages. The first gives several overwrites of 512 bytes of memory adjacent to the ATA param structure. The second is just a very long delay on resume. Well, if the first is a serious bug then I assume we can get that fix in when Søren gets back. I don't know who else you would work with. I don't know enough in that code to review any major changes. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patch: fix 30 second hang while resuming
At 3:19 PM -0800 2/27/05, Nate Lawson wrote: Poul-Henning Kamp wrote: Have you tried sos@ new ATAng mk III patches ? As far as I know he plans to commit those shortly. One minor point: Søren is on vacation right now. I *think* he will be getting back around March 5th (assuming I understand what he said in a recent message). So, *if* this is something we want to get in before the code-freeze, we may have to act without his input. Not yet. In any case, I'd prefer these problems be fixed before the import since the patches are minor and data corruption is generally a bad thing for a little while even if a large, new something is coming sometime soon. Your original message only mentioned a long-delay when resuming. Is this bug also causing data-corruption in some circumstances? (I don't have the slightest idea what this area of code does, I just want to make sure we understand how serious the issue is...). Is this something which only comes up in 6.x? Or is the same thing happening in 5.x too? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem with CVSUP12
At 7:31 PM -0800 2/21/05, Doug White wrote: cvsup12 is damaged. If you've checked out against it your checkout is corrupted and you'll need to blow away your src dir and checkouts.cvs file to recover. The administrator has been notified. Is there some way we could inform/re-direct the people who are connecting to cvsup12? I had been using it, and only happened to read the thread on buildworld fails on: === bin/domainname. I can't think of an easy and reliable way to inform everyone, but perhaps we could change the DNS entry to point to a different cvsup machine? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NULL pointer deref in sioopen() suggests a close/open race on sio device?
At 4:51 PM + 1/23/05, Robert Watson wrote: The ps list is a bit boring, but the primary interesting thing is that it looks like the close was going on in one thread just about when the sio swi was scheduled to run also: [...] This in turn suggests that something has called ttyrel/tty_close on the TTY in a race with the open, or otherwise NULL'd that pointer via knlist_destroy(). Anyone have any pointers on this one? The TTY code is not my forte... FWIW, I just recently setup some of my freebsd boxes with serial consoles. It *seems* to me that if I type in 'shutdown -r now' when I am logged into a serial console, there's often some long delay before the reboot happens. It's long enough to be annoying, but not long enough to motivate me to look into it. My machines usually have a monitor/keyboard also setup on them, so my solution has been to avoid using the serial console... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DMA errors with SATA on 5.x [one fix]/ SATA DVD+RW
At 9:49 PM +0100 12/9/04, Søren Schmidt wrote: I'm going to work on it soon thats for sure, however I have lots on the burner currently so its no rush. However all kinds of (S)ATA/ATAPI gear is always most welcome here in the lab, the levels of support I can provide is directly proportional to the amount of HW I have access to :) I am not great at mailing things. My sister is still waiting for me to mail her christmas presents for *last* year... Do you have a paypal account? I could send some money that way, and then you could get whatever devices seem the most important to the work you have been doing. That way you might get something from me before SATA becomes obsolete... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DMA errors with SATA on 5.x [one fix]
At 1:01 AM -0600 12/7/04, Tim Welch wrote:
I'm getting NID not found/DMA errors on 5-STABLE with a Seagate 200gb
sata drive:
ad2: FAILURE - WRITE_DMA status=51READY,DSC,ERROR
error=10NID_NOT_FOUND LBA=268435455
This appears to be a result of 48-bit addressing. Any time a write is
attempted to the sector above, I get multiple messages like this. It
continues until I shut down. After a bit of googling I found this post:
http://lists.freebsd.org/pipermail/freebsd-hackers/2004-October/008821.html
and applied the change suggested. It seems to have fixed the problem,
and I've had no troubles from this since Nov. 18th when I applied that
patch. I'm running an Intel 875PBZ board with the ich5 controller.
The drive in question is a Seagate ST3200822AS/3.01 (as reported by
dmesg). So the question is, will this patch be committed anytime soon?
That looks like a pretty safe patch to make. The message says he
just reduced the 48-bit trigger level by one:
--- ata-lowlevel.c.orig Wed Nov 24 05:47:26 2004
+++ ata-lowlevel.c Wed Dec 8 22:45:39 2004
@@ -701,7 +701,7 @@
ATA_IDX_OUTB(atadev-channel, ATA_ALTSTAT, ATA_A_4BIT);
/* only use 48bit addressing if needed (avoid bugs and overhead) */
-if ((lba 268435455 || count 256) atadev-param
+if ((lba 268435454 || count 256) atadev-param
atadev-param-support.command2 ATA_SUPPORT_ADDRESS48) {
/* translate command into 48bit version */
If this fixes a problem with large disks for both the original
person and for you, then I suspect we should commit it. I don't
know if we need to add a comment saying why we're going with
268435454 instead of 268435455, though.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: names of supfiles in /usr/share/examples/cvsup
At 7:36 PM +0100 12/6/04, Jose M Rodriguez wrote: El Lunes, 6 de Diciembre de 2004 08:39, Rob escribió: Hi, For 5.3 in /usr/share/examples/cvsup, there's: stable-supfile : for FreeBSD-stable standard-supfile : for FreeBSD-current I find this naming rather confusing. Why stable refers to STABLE, but standard refers to CURRENT ? This causes unnecessary confusion. Why not the following name convention: release-supfile : for FreeBSD-RELEASE Better security-supfile. There is just one release, things like RELENG_5_3 are security branchs, not release branchs. Let me add to the pain by noting that RELENG_5_3 is not a security branch (the way we used to have security branches). It is now called an errata branch, and it may see some updates which are not for security issues. Not many, and only really really safe ones, but it is more than just security fixes... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make -j$n buildworld : use of -j investigated
At 2:08 PM +0900 11/23/04, Rob wrote: Hi, I have tested following with FreeBSD 5.3-Stable. On several different PCs I have used make -j$n buildworld with $n ranging from 1 to 9. Although people suggest -j4 as optimal in general case, I have come to a very different conclusion... So, I finally got around to doing some timings on my newest PC. It is a AMD Athlon(tm) XP 3000+ (2166.43-MHz 686-class CPU) with 1-gig of memory, and fast SATA disks. It was certainly different that what I saw on my previous single-CPU systems. Roughly: Real User Sys Max-LA 2670.86 2071.66 543.49 1.25 buildworld 2751.60 2085.95 603.69 1.35 -j1 buildworld 2825.87 2137.19 637.15 5.58 -j2 buildworld 2887.03 2158.60 648.37 11.85 -j3 buildworld 2856.75 2156.48 647.43 19.06 -j4 buildworld 2851.71 2154.39 647.19 25.43 -j5 buildworld 2850.92 2155.40 646.19 31.59 -j6 buildworld 2850.07 2153.77 648.41 36.19 -j7 buildworld 2852.64 2155.74 647.82 47.00 -j8 buildworld 2851.66 2153.43 650.23 53.51 -j9 buildworld (I've actually done multiple runs of each, but they all show about the same numbers). I had a separate session doing 'uptime's every 30 seconds, and the Max-LA column is the maximum load-average that was seen by that separate session. Apparently the faster disks made a much bigger difference than I had expected to see. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 'ifconfig fxp0 -alias' wipes out all IPs on device
At 1:02 AM -0400 11/7/04, Marc G. Fournier wrote: I hate to report an email, but after being laughed at by both Linux and Windows users, I'm kinda concerned at the lack of response to my originals ... is this truly the desired behaviour? And, if so ... can someone put some sort of warning/notice about it in the man page(s)? I imagine you received no response simply because several of the main developers have been swamped trying to finish off 5.3. I remember seeing your earlier report, but I don't remember which mailing list it was sent to. I'll respond enough to say that the behavior you saw seems undesirable to me. But I'm not a networking guy, so that doesn't mean much... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portsdb -Uu results in coredump
At 10:49 PM -0400 9/6/04, Sahil Tandon wrote: kstewart wrote: There is a bug in ruby that shows up as a bus error. Follow the topic on [EMAIL PROTECTED] There are several ways to alter the INDEX[-5] so that it occurs less frequently. Occurs less frequently? That's not what I'm looking for. Is there a *fix* for the root cause? Oddly enough, there are a lot of other people who would also prefer a more complete fix. If we had a fix, we would install it and you wouldn't have to work around the problem. There are developers who are looking into the problem. I think the problem is really in bdb (which ruby is calling for database-work), and not in ruby itself. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: two minor lpr gripes
At 10:47 AM -0700 9/18/03, roger n. tospott wrote: /usr/src/usr.sbin/lpr/common_source/lp.local.h currently has #define DEFMX 1000 Given the size of files nowadays, shouldn't this be a little larger? This was recently changed to 0 in current, but not in stable. (zero meaning no limit). It probably makes sense to pick *some* limit instead of infinity, but I couldn't come up with a good reason for any specific value, so we just went with zero (aka infinity). Also, maybe it's just me, but given this (from man printcap): Name Type DefaultDescription mx num 1000 maximum file size (in BUFSIZ blocks), zero = unlimited it's not obvious to me that Type num means that, if i wanted an unlimited maximum file size, the printcap entry should be mx#0, rather than mx=0. Perhaps more expressive examples could be helpful in /usr/src/etc/printcap. Heh. It's obvious to people who have done a lot with printcap or termcap, but it's true that people often miss that. I thought I had added some logic to chkprintcap for that (so you'd at least see a warning message when lpd starts up). Perhaps I only did that in my own versions, and never committed it to freebsd. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xargs broken
At 3:08 PM +1000 7/1/02, Edwin Groothuis wrote: # xargs ls -d /tmp/p xargs: ls: Argument list too long You mean the warning Argument list too long ? It's coming from your shell. Well, that's true, but it's coming from the shell because xargs built a command that was too long... :-) tjr has already found a bug in xargs which seems to be the culprit for this problem. The change is in -current, and will show up in -stable in another day or two. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Heads Up: Accept filters fixed
At 11:07 PM -0500 4/30/02, Mike Silbersack wrote: Just a quick note for those of you using accept filters with a 4.4+ kernel using the syncache: Your accept filters are broken, and easily DoSable. The fix (attached) has now been committed to both 5.0 and 4.5, so I recommend doing one of two things if you're using accept filters: How seriously are they broken? Should this be MFC'ed into RELENG_4_5 ? (security-patches branch) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Is vmnet broken in 4.5?
At 11:38 AM +0300 2/19/02, Eugene Mitrofanov wrote: Hi. My vmware2 use netgraph bridge to access the network. Under 4.4 all work fine. But after upgrade to 4.5 I got some trouble. I can't see my FBSD box under vmware, but all other boxes in network work fine. I can't ping from FBSD box to vmnet1 address. It seems, vmware guest OS can't get arp address of FBSD. I do not know enough to help with the problem you are seeing, but I thought I would mention that I am running vmware2 on a freebsd-4.5 system, and it is working for me. I follow the 4-stable branch, so I have been rebuilding my system every few weeks. It may be that I had to do special steps at some point to keep vmware2 working, but I don't remember what those would have been. I do remember that at some point I had to rebuild the port. I am using netgraph bridging too. So, it is possible for vmware2 to still work under 4.5-release. It is not completely broken. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: *_enable=YES behavior is bogus
At 6:36 PM +0100 2/1/02, Erik Trulsson wrote: Consider that the actual code in the various rc* start scripts is in most cases of the form: if foo_enable==yes do stuff else do nothing Let me approach this from a different angle. Several people have tried to argue this by proposing various What if? scenarios. Let me also do that. Let us say that we did happen to decide that for all 'foo_enable' options in rc.conf, a setting of 'foo_enable=no' does in fact mean that the service 'foo' will NOT be running at the end of the boot-up process. Maybe some company offers us a million dollars if we will just guarantee that, and we think of all the good programmers we could pay for that million dollars, so we all agree to standardize on this definition of 'enable=no' If we decided to do that, then as a *practical* matter, how many of the current options in rc.conf would need to be changed? I don't mean if we need to cover the case where someone renames /usr/sbin/lpd to /bin/echo, what would we need to do?. I mean, given any default installation of the base operating system (no ports), and any valid kernel configuration, in what cases of 'enable' would we really *have* to add some lines to those 'else' clauses that you quoted? In the case of lpd_enable, as a *practical* matter, there would be no need to write additional code. There is no kernel setting which automatically turns on lpd support, and if 'lpd_enable=yes' does not *start* /usr/sbin/lpd, then we do know that the lpd program is not running. I don't have time to look into it now, but I expect that is true for all of the other 'enable' options. As a *practical* reality, I expect that the firewall_enable option is the only one where we do need to write code to implement the 'enable=no' case as I described it. People will argue that this is special, because it's a kernel option! Lpd would behave exactly the same way, *if* it were a kernel option!. All fine and good, *if* it were true, but irrelevant to my What if? question. Of the current foo_enable options, which options would we need to change *right now* to support the definition of 'enable=no' that some people think is logical? [mind you, I don't actually know the answer to that question, but I just got a phone call and need to leave right now... So, I am breaking the first rule of a good lawyer, in that I am asking a question that I don't already know the answer to. :-) ] -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: *_enable=YES behavior is bogus
Oh. Damn. Someone *added* freebsd-current to this thread without removing freebsd-stable. Several people have requested that we stop discussing this on freebsd-stable, and I *thought* I was only sending my recent messages to the one mailing list. I do not particularly care which mailing list this discussion is on, but I really think we should pick one mailing list and keep it on only one list. Peoples' nerves are frazzled enough already about this topic without having to see this on two mailing lists! I'm sending this message only to stable, with the hint being that maybe we should debate the topic only on -current, as several others have suggested/requested. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: I'm not going to finish my sysinstall changes before 4.5
At 11:47 AM +1030 12/23/01, Greg Lehey wrote: Somehow I'm nervous this close to a release. I suspect that this is one area which gets almost no testing in -CURRENT. Can you summarize (again?) what they do? The change is to what partition-sizes are chosen if a person does let 'disklabel' auto-partition a disk. Given the nature of the changes, I suspect it would be best to add them to -stable as soon as possible, so they get as much testing as possible. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Has the size of stable /modules increased a lot lately?
At 9:31 PM -0700 11/19/01, Chad R. Larson wrote: On Mon, Nov 19, 2001 at 07:49:49PM -0500, Garance A Drosihn wrote: The comments for the commit include which adds the ability to compile modules -g as well (among other things). The original commit to current (1.241 on Aug 2nd) was a bit more explicit as to the effect: When building a debugging kernel with modules, build modules with debugging support as well. It isn't just that the ability is now available, it's that anyone who has debugging set for the /kernel *will* also get it for /modules. Personally, I think it makes sense that if the kernel is built with debugging, the modules should as well. All we need is a heads up in the release notes (my preference) or in the updating instructions. I do agree that the change is a sensible one, now that I know what caused the increased size of /modules. But that increase did greatly disrupt my 'make installkernel', right in the middle of an otherwise uneventful update to the latest stable. It would have been nice to know what was going to happen before I was sitting there with a screen full of disk full errors and a half-installed kernel... I suspect it's worth a short blurb in UPDATING, just to say people with 'makeoptions DEBUG=-g' in their kernel are going to see a 15-meg increase in the size of their /modules directory with the first build they do after Oct 18th, and another 15-meg (for /modules.old) with the second build after that date. If you run out of space in '/', you may need to comment out the DEBUG option. [On the other hand, this change was over a month ago, and it apparently hasn't bitten many folks, so the note probably doesn't need to be all that detailed] The release notes would have a different kind of entry, one saying that the change was made, and why this change was a good idea. [okay, I'll shutup about it now] -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Has the size of stable /modules increased a lot lately?
This is something odd I noticed when I did a buildworld. It may be due to something I did, but I thought I'd mention it in case other people start noticing the same thing. My system is working fine, so this is not a crisis for me. Just an oddity that I thought I'd mention. [and apologies if this has been covered in some recent message, but I don't remember any reference to anything like this] - - - - I went to do a buildworld today, and ran out of space in '/' when it came time for the 'installkernel' step. After removing a number of other files I eventually did get it to install, but '/' is still a bit cramped. It turns out my /modules directory is taking up 20meg, which seems a bit high. But by the time I did get the install to go ok, I had blown away all old copies of /modules, so I can't say for sure what the size used to be. My recent buildworld times were: Oct 13th, Nov 11th (or 12th), Nov 18th Looking at the output from the daily log-runs, there was a definite spike in disk-usage in '/' with the install on the 11th, and another jump today (it's a bit hard to say how much, given how many unrelated files I had to remove to get the installkernel to work). Right now I have 44-meg tied up in /kernel+/kernel.old+/modules+/modules.old, and back at the start of November *everything* in '/' added up to about 43-meg. In comparing my /modules to someone who did a buildworld in early Nov, all of my modules are larger than his. My /etc/make.conf includes: CFLAGS= -O -pipe NOCLEANDEPENDS=true USA_RESIDENT= YES And my kernel config does include 'makeoptions DEBUG=-g'. And I am also running with softupdates on for '/', which makes the 'installkernel' a bit more likely to fail when free space is low. The thing is, all of those have been true for at least six months, so that does not explain why I'd see a sudden spike. The only kernel-config change I've made since Sept is to add device 'urio' (presumably that wouldn't blow up the size of ALL modules). I'll probably take out the DEBUG in my kernel config, or turn off softupdates (and mount a separate /tmp), so I'm not in a bind here. I'm just curious why there would be a sudden jump. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: AFS for FreeBSD?
At 11:11 AM -0700 10/18/01, Gordon Tetlow wrote: On Fri, 5 Oct 2001, Schmalzbauer, Harald wrote: see www.openafs.org. I read that somebody has successfully ported the server. I haven't tried it yet but I hope it's working. AFS is THE solution for many problems. /usr/ports/net/arla is the only *client* that works for FreeBSD. For an AFS *server* check out openafs. I believe there is a porting effort to get the openafs client working on FreeBSD, but I don't know the status of it. BTW, there is a freebsd-afs mailing list. Please subscribe. It would actually be better to go to www.openafs.org and subscribe to the mailing-lists there. They have a list for OpenAFS-port-freebsd , and that gets more traffic than the freebsd-afs mailing list. The freebsd-afs mailing list was created before openafs showed up, and was really intended in getting a transarc client for freebsd. That did not get very far before IBM decided to spin-off openAFS. I'll also say that I am looking forward to openafs clients and servers for freebsd. I realize arla should work as a client, but it would be easier for me to sell FreeBSD with an official openAFS client here at RPI. Right now the openAFS for linux client is one of the things which causes us to use linux for some new servers. ARLA may very well be fine code, but politically it is a harder sell. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: dirpref gives massive performance boost
At 10:57 AM -0500 10/18/01, David W. Chapman Jr. wrote: Must one supply any other arguments to newfs in order to enable dirpref? A quick look at man newfs didn't make any mention of dirpref. No, it's on by default in kernels that include the new code. Is there a way to check to see if a slice has difpref enabled? Dirpref is not something which is enabled or disabled, not in the same sense as softupdates is enabled. Dirpref is a smarter layout of information in a partition. You need a version of the system which knows HOW to do that smarter layout, and then you just rebuild the partition. There is no switch to turn on and off. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: make -j4 vs -j8... 4 works, but 8 does not
At 12:38 PM -0400 9/15/01, Mike Tancsa wrote: Should a parallel build always work ? I was just trying to stress a new series of MB we are evaluating and to my suprise, -j4 works, but not -j8 Well, in a philosophical sense, yes it should always work. Bugs creep into the process from time-to-time. I can not say that I know how to pin down such problems when they occur. I do know that earlier this year I had some problem I was checking, and as a tangent to that problem I did several fresh 'make buildworld's, going from -j2 to -j10 on my dual 650-MHz pentium machine. I then did md5 comparisons of the resulting obj-tree results, and they all came out the same. Of course, I wasn't getting any errors at build time, either. What happens if you remove all of /usr/obj/usr/src before trying to build with -j8? === usr.sbin/boot0cfg rm -f .depend mkdep -f .depend -a-I/usr/obj/usr/src/i386/usr/include /usr/src/usr.sbin/boot0cfg/boot0cfg.c cd /usr/src/usr.sbin/boot0cfg; make _EXTRADEPEND echo boot0cfg: /usr/obj/usr/src/i386/usr/lib/libc.a .depend 1 error *** Error code 2 1 error *** Error code 2 the thing which interests me about the above is that 'make' aborts with error code 2, but I don't see any error message as to what the error was. I wonder if this is another case in /bin/sh -e where an error return is NOT being ignored when it should be ignored. I fixed two similar bugs last summer last summer. [aside on those multiple builds that I did: It was interesting that even though it was on a dual-processor system, there was not much of a speed improvement (on 4.3-stable) when going from -j4 to -j10. Big improvement going from -j1 to -j4, but after that it didn't help much] -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Minor issue with portmap=NO vs 'ypwhich'
This will probably seem like a dumb thing to report, but I'll mention it in case someone who knows about yp/NIS would want to comment on it. My .bashrc file is (pretty much) the same on the many different platforms that I work on, and as a matter of trouble-shooting on SOME of those platforms I do a 'ypwhich' in it. Most of those platforms do NOT run yp, but I still run it on all platforms and just catch the error for those hosts which are not running yp. I am NOT running yp on freebsd. With this week's -stable, /etc/defaults/rc.conf changes portmap_enable to be NO. With portmap_enable off, ypwhich still errors out as it does with portmap_enable on, but it takes it much longer to figure out that yp is not running (30 seconds? 60 seconds?). So, I realize it's probably dumb to care about how quickly ypwhich completes on a machine which is NOT running yp, but it is a noticeable change, so I thought I'd mention it. It is easy for me to just fix my .bashrc so I wouldn't hit that long delay, or to just turn on portmap, for that matter (which is what I've done for the moment). So, this isn't a big issue for me. I'm just wondering if there are any other effects which might be more significant for other users. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: difficulty uninstalling ports
At 9:52 PM -0700 7/12/01, Jordan Hubbard wrote: And, as I'm sure others have pointed out by now, it's even easier to do this with the -a flag. :) Of course, since pkg_delete also supports globbing now, one assumes 'pkg_delete *' from *any* directory would also work. watch out there. you wouldn't want your shell to do it's glob- expansion before pkg_delete even sees the parameter. So, you might want: pkg_delete '*' but probably not pkg_delete * when typing that in from any directory. disclaimer: I assume that's how it would work, but I'm not going to try it myself to know for sure... :-) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: FreeBSD 4.3-RC5 now on ftp.freebsd.org
At 3:29 PM -0700 4/20/01, David Greenman wrote: someone wrote: And even in "normal" situations, it's quite hard to actually get all the bit's from ftp.freesoftware.com ... You are right that the performance has sucked generally for awhile, however. Lightning has been bandwidth limiting us, resulting in lower performance than what people had gotten used to. Does this mean we won't be seeing any more record-breaking data-transfer statistics? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: FreeBSD 4.2-RELEASE delayed until November 20th.
At 7:37 PM +0100 11/13/00, Marko Cuk wrote: What is with the bridging code ?? It won't work from 4.0 !! I wrote about that problem many times. Where did you write it to? I do not see any problem-reports (ie, as generated via send-pr) from you. You may have described them in previous messages to some mailing list, but it is better to officially send a PR for problems. I also do not see any problem reports from anyone which mention "bridging". You would probably have better luck if you sent in a problem-report with the details. The above has almost no helpful details. "Bridging" what to what? How does it not work? Given that you describe the problem as being with release 4.0, and we're now on release 4.2, I would expect that any major problem with bridging would have been noticed by many people by now. -- --- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Small patch to lpr - comments, review, commit ?
At 12:33 PM + 10/30/00, Steve O'Hara-Smith wrote: I have found that lpr does not pass the -C parameters to lpd unless burst header pages are being printed. Unfortunately apsfilter (ab)uses the -C parameters for printer mode control. The patch below moves pass through of the -C parameters out of the conditional block. As far as I can see this is never harmful. I suspect it is never harmful within our lpr. Not sure about how lprNG or various other things would treat it. My guess is it should never be harmful. In fact, I'm inclined to say both the 'C' and 'P' lines should be moved out of that conditional block. The only thing that really triggers a header sheet is the 'L' line, and there are other processes which might want that 'P' line to be there even if the header sheet is off. I could put that change into lpr in -current, if you want. It should probably sit there for a little while just to make sure it doesn't cause any problems when sent to other lpr implementations. (which is to say, this will not make 4.2-release...) --- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Small patch to lpr - comments, review, commit ?
At 3:38 PM -0500 10/30/00, Garance A Drosihn wrote: In fact, I'm inclined to say both the 'C' and 'P' lines should be moved out of that conditional block. The only thing that really triggers a header sheet is the 'L' line, and there are other processes which might want that 'P' line to be there even if the header sheet is off. Er, that isn't quite right. I keep confusing 'P' lines with 'L' lines, as shown by the fact that I talk about moving the 'P' line when the 'P' line isn't even IN the conditional... I can't move the 'L' line, but the update that Steve wrote to move the 'C' line should be fine. I'll make the change unless someone sees a problem with it. It still won't make it into 4.2, though :-) --- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: I'll be rolling a 4.1.1 release on September 25th
At 6:19 PM -0700 9/16/00, Kris Kennaway wrote: On Sat, 16 Sep 2000, Peter Radcliffe wrote: Kris Kennaway [EMAIL PROTECTED] probably said: On Sat, 16 Sep 2000, Peter Radcliffe wrote: Can we _please_ get these two patches into at least -stable before or after this release cut ? Poeple often pop up right before a release is due to be rolled, and ask for some patch to "make it into the release" - often it doesn't, and they go away until the next release is announced. This isn't how the FreeBSD development model works, and you're targetting the wrong group at the wrong time. Let me note that there are two discussions going on in this thread, right in the above paragraphs. Peter is asking about a specific set of updates. Kris is (at least partially) responding to a general topic. "Speaking to the audience", instead of the individual who brought up a question. (I have done this in the past myself, in comp.sys.next newsgroups, and generated much confusion in the process...) Sorry for being short, but I'm on my way out. 1) they're not my patches, but they're useful to me. 2) I didn't specificly ask for them to make it into this release, I said "before or after". 3) I've asked before and go no response. 4) I can't commit things to -current. My point was that you need to either ask one of the committers directly, or ask in a forum where the committerss hang out. That's not -stable - there are only a few of us here, so asking here is almost akin to asking in a vacuum. Again, Peter is making it even more explicit that he is wondering about a specific set of patches. From various comments in this thread, it seems these patches have been brought up in several contexts over many months. I think Kris needs to say "I don't know about this specific set of updates", lest more confusion result. 5) I know how the system works, but it requires someone to commit the patches and no one will. Works for you..they have to go through -current first in case they break for someone else. Assume he meant "I know how the freebsd development model is supposed to work, but what is a person to do if they do not have commit access and can not seem to get anyone's attention?" An explicit list of steps would be nice. "Send a message here. Wait one month. No reaction? Send a message to this other place". For the *specific* question, Peter seems pretty flexible about getting the updates in "before or after" the release, so ignore the deadline of 4.1.1 or even 4.2. Just list the steps in the "Freebsd development model". My question still stands, can these patches get in, somewhere ? You're still talking to the wrong list. And this still did not provide an answer, not to the specific question, nor for the "speech to the audience". Where do we find these mythical committers who have time? Here we all are, debating this topic on a saturday night. My guess is that we are all available right now because we're busy working on something that we didn't have time to finish during the normal work week. I still stay it boils down to a simple matter of too much work for too few people. That may be frustrating, but it is not as infuriating as implying that there is some magical "freebsd development model" which would always get patches-in-PR's incorporated if people would "just follow the steps". That only makes things worse for people who see their PR's sit around, because it seems like they must be getting deliberately snubbed, instead of just being too far down the list to look at. I think that's probably enough for me to say, at least for the weekend. I don't suppose anyone knows why my bpf devices aren't working for me, even though I *know* I had used them fine under freebsd at one point? Sigh. saturday nights --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: Upgrading 3.5-STABLE to 4.0-STABLE
At 9:40 PM -0400 7/16/00, Phil Rosenthal wrote: Is it possible to ignore the "reboot in single mode" part? It is not possible to get this system into single mode, because it has to be up, always. it can have a maximum downtime of maybe 45 seconds, which is too long to go into single mode and compile stuff. I know it is obviously more dangerous to be in multi-user mode, but is it one of those "better safe than sorry, but it will probably work" things? If you have a machine which really has that kind of uptime requirement, then you need to rethink your upgrade strategy. There's no absolute guarantee that everything is going to work after upgrading (particularly when doing a large jump, such as going from 3.5 to 4.0-stable). Even if everything DOES work, it might be that it'll take an extra 30 seconds to boot up. I can not imagine feeling comfortable saying "sure, go ahead, it will 'probably' work" if you really can not afford a minute's worth of downtime. If the upgrade does work 99% of the time, and you happen to hit that other 1%, then you're screwed. I would not want to be responsible for you finding yourself screwed. I realize you probably also have the constraint that you can not spend any money on redundant equipment, but at some point reality will have to set in. Either get redundant equipment, or give up on 45-second maximum downtime, or simply do not do upgrades. That's just my view of things, of course... In my case, I have a machine where the goal for maximum downtime is more like 30 MINUTES, and yet I have a duplicate machine for that case. I'm certainly not going to recommend that you jump into 4.0-stable on a critical production machine without doing some testing of it before switching to it. [aside: on that machine, I'm about 3 hours away from having one year's worth of continuous uptime... :-) ] --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: NO! Re: [PATCHES] Two fixes for lpd/lpc for review and test
Note: I'm sending this to just the -current list, since it's pretty clear that this change won't be ready for -stable anytime this year... (hopefully Alfred is in -current?) At 3:02 PM -0800 12/9/99, Alfred Perlstein wrote: On Thu, 9 Dec 1999, Andre Albsmeier wrote: On Tue, 07-Dec-1999 at 14:55:37 -0800, Alfred Perlstein wrote: please do not, the patch in PR 11997 introduces a major security flaw. someone can hardlink to any file and clobber it with a file owned by them: I think the (really big) security hole can be closed by not doing the chown/chmod commands. I inserted them because I wanted the file in the spool directory to appear exactly as if lpr would have copied it. I don't have too much time to think about this, argue me this: why should I allow a user to print any file on the system? the race condition is still there. I think the general goal of the patch is a good idea (ie, doing a 'mv' instead of a 'cp rm' when we can). And, in fact, I'd like the chown/chmod's to be done so the file is owned and permitted the same way as if it was cp'ed. I don't have any time to really look at the patch right now though (it's end-of-semester, things breaking, students around here in a frenzy, etc, etc). I might try to suggest something this weekend, depending on how things go. I think we can afford to do whatever checking is necessary to get this right, as the checking can't possibly be more expensive than copying the whole file and removing the old one. (in my environment we have people printing thru samba or CAP, and who are sending 100meg files. If I can use 'mv' instead of 'cp', that has to save a lot of cpu time!). Of course, the security implications of such a change are also pretty important in our environment here... --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
