Can't select/install kernels in custom install.cfg - 6.1RC2
Hi, I have just upgraded some of our product build machines to 6.1RC2 and I am having a few problems getting a custom install.cfg to work with the way sysinstall now selects/installs kernels. I am trying to select a custom distribution set using something like the following: dists=base kernels distKernel=GENERIC SMP distSetCustom base gets installed fine but no kernels ever get installed. If I set any of the standard distribution sets (eg. distSetMinimal, or distSetEverything), then one or both of GENERIC/SMP kernels get installed. I am a bit lost. Did some googling, but couldn't fine anything relevent. Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resolver behaviour regarding searchlist and A/AAAA query replies
On Fri, May 05, 2006 at 08:38:20AM +0900, Hajimu UMEMOTO wrote: Hi, On Mon, 1 May 2006 20:46:40 +0200 Jan Gyselinck [EMAIL PROTECTED] said: Jan What I find strange though, is the fact it's now applying the searchlist Jan to get an answer on the query. Other than the fact this could Jan potentially give unpredictable results in specific situations, I find Jan this rather illogical. Since one of the queries (A or ) succeeded Jan we _know_ the host in question exists (and the searchlist is there to Jan make non-fqdn queries work for 'local' hosts, by applying the searchlist Jan if the host does not seem to exist). So, in short, isn't this a bug? Which application did you use? The application which doesn't use getaddrinfo(3) has this issue, and it cannot be fixed without re-writing the application to use getaddrinfo(3). konqueror, which is dogslow on this box, there must be something else playing here too... Jan Gyselinck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
On Thu, May 04, 2006 at 01:54:58AM -0400, Mike Jakubik wrote: + Kris Kennaway wrote: + On Thu, May 04, 2006 at 12:41:57AM -0400, Mike Jakubik wrote: + Then why utilize a known non-functional technology? + + + Because again, the benefits have been judged by the decision-makers + and found to outweigh the drawbacks. Perhaps that's just a difficult + concept for some people to understand if they're used to thinking of + everything in binary terms. + + + + Yes, i am sorry, but i fail to understand why i would want to use something that i know does not work correctly. I think there are quite a few of those drawbacks that are + pissed off. I'm using bgfsck very often and I didn't have problems with it. Those hangs aren't so easy to trigger in everyday use. There are serval committers, including me and Kris who work on those hangs very hard for more than two week now. The problem is that VFS is very complex and there are many subtle bugs. We found few more problems with snapshots, which weren't reported by users, because of our extensive testing. Fixing one bug, uncovers another one, etc., but as I said those bug don't touch every user and don't make UFS to hang always making FreeBSD unusable. Some of those bugs are maybe quite easy to fix, so the only risk here are latent bugs the fix can uncover, but some of them need a lot of work to fix properly and be sure nothing else will break. That's why fixing those bugs must include extensive testing on many different work-loads. We can't just commit those and hope for the best. The point here is that FreeBSD is as good as their developers are professional and responsible and belive me, committing quick hacks to fix those issues can break 6.1-RELEASE for much more users, who will then send mails to freebsd-stable@ saying Is FreeBSD a professional operating system or a joke? How can they ship a release with broken, untested code?. Do you think that answering We had two users who insisted on fixing those bugs just before release, blame them! would satisfy them? It isn't good to release a software with known, documented bugs, but its better than shipping an untested software with god-one-knows unknown bugs. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpvhlG3ywAba.pgp Description: PGP signature
Re: quota deadlock on 6.1-RC1
On Thu, May 04, 2006 at 04:59:33PM -0700, David Kirchner wrote: Here's how to reproduce the snapshot deadlock I'm seeing, with 6.1-RC2 cvsup'd as of 5 or 6 hours ago: 1) dd if=/dev/zero of=/usr/bigfile bs=1024 seek=209715200 count=0 2) mdconfig -a -t vnode -f /usr/bigfile 3) bsdlabel -w md0 auto 4) newfs -U md0a 5) fsck -v /dev/md0a # ^C this after a second or so, this makes the FS dirty 6) mount /dev/md0a /mnt 7) fsck -v -B /dev/md0a in another window: 8) while true; do ls -al /mnt/.snap;sleep 1;done It locks up every time for me, with no further disk activity. Unfortunately, for some reason, my server console became unaccessable, so I'm not able to get to the kdb prompt. If I can get to it later, what should I run other than show lockedvnodes and show threads? Also, can anyone else try these steps and verify if they cause the same problem for you? I repeat you recipe on CURRENT. What I got was the completely unresponsively system, that was _not_ deadlocked. It has slowly made a progress. Slowness is surely related to hole in the file backing fsck'ed (and snapshotted) filesystem. Snapshotting slowly made a progress, with lot of disk activity. After it had finished, system resumed normal operation. Tor Egge committed several fixes into CURRENT, that certainly help in this situation. In my initial tests, filed in a PR, steps #1 and #2 were unnecessary as I was working with real disks. The result is the same here. Still, I am curious if anyone else can get the same result with a real disk =200GB in size. I am unable to duplicate it with a 20GB partition, and I am not sure why. -- David 'dpk' Kirchner pgptAeKpNTYmx.pgp Description: PGP signature
Re: usb to serial
thx for the suggestions, guys. with device uftdi device uplcom in the kernel config the adapter shows up as ugen0: ArkMicroChips USB-UART Controller, rev 1.10/0.01, addr 2 no specific com port shows up, however, so i must need something else. David Coder Network Engineer Emeritus, Verio Washington, DC On Wed, 3 May 2006, Marc Fonvieille wrote: :Date: Wed, 3 May 2006 14:38:22 +0200 :From: Marc Fonvieille [EMAIL PROTECTED] :To: David Coder [EMAIL PROTECTED] :Cc: freebsd-stable@freebsd.org :Subject: Re: usb to serial : :On Wed, May 03, 2006 at 08:33:22AM -0400, David Coder wrote: : : Is there a generic freebsd driver for usb-to-rs-232 adapters? My Thinkpad : (running 6.1-RC) doesn't have a standard db-9 port. : : :uftdi(4) for some USB/RS232 adapters. : :Marc :___ :freebsd-stable@freebsd.org mailing list :http://lists.freebsd.org/mailman/listinfo/freebsd-stable :To unsubscribe, send any mail to [EMAIL PROTECTED] : On Wed, 3 May 2006, Vivek Khera wrote: :Date: Wed, 3 May 2006 10:00:42 -0400 :From: Vivek Khera [EMAIL PROTECTED] :To: freebsd-stable freebsd-stable@freebsd.org :Subject: Re: usb to serial : : :On May 3, 2006, at 8:33 AM, David Coder wrote: : : Is there a generic freebsd driver for usb-to-rs-232 adapters? My Thinkpad : (running 6.1-RC) doesn't have a standard db-9 port. : :I bought a generic one from BestBuy which works with the uplcom driver (I just :load it from loader.conf). I have an older one I bought there a year ago that :also works with the driver, but only reliably up to 38400 baud. That could be :due to the system to which it is connected, though. The new one seems safe up :to 115200. : :They show up as device /dev/cuaU0 in FreeBSD 6+. They both probe as: : :ucom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 2 : : On Wed, 3 May 2006, Helge Oldach wrote: :Date: Wed, 3 May 2006 16:02:57 +0200 (MET DST) :From: Helge Oldach [EMAIL PROTECTED] :To: David Coder [EMAIL PROTECTED] :Cc: freebsd-stable@freebsd.org :Subject: Re: usb to serial : :Marc Fonvieille: :On Wed, May 03, 2006 at 08:33:22AM -0400, David Coder wrote: : Is there a generic freebsd driver for usb-to-rs-232 adapters? My Thinkpad : (running 6.1-RC) doesn't have a standard db-9 port. :uftdi(4) for some USB/RS232 adapters. : :uplcom(4) as well, for example : :ucom0: Prolific Technology PL2303 Serial adapter (ATEN/IOGEAR UC232A), rev 1.10/2.02, addr 4 : :Helge :___ :freebsd-stable@freebsd.org mailing list :http://lists.freebsd.org/mailman/listinfo/freebsd-stable :To unsubscribe, send any mail to [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: usb to serial
On May 5, 2006, at 11:04 AM, David Coder wrote: thx for the suggestions, guys. with device uftdi device uplcom you should really only need one of these. in the kernel config the adapter shows up as ugen0: ArkMicroChips USB-UART Controller, rev 1.10/0.01, addr 2 it did not detect it as a serial port, just a generic device. you might need a different driver. Look to see if ArkMicroChips is a supported device. Seems not. no specific com port shows up, however, so i must need something else. look for /dev/cuaU0 once you get it recognized as a real device, not a generic object.
Re: resolver behaviour regarding searchlist and A/AAAA query replies
Hi, On Fri, 5 May 2006 09:46:22 +0200 Jan Gyselinck [EMAIL PROTECTED] said: Which application did you use? The application which doesn't use getaddrinfo(3) has this issue, and it cannot be fixed without re-writing the application to use getaddrinfo(3). Jan konqueror, which is dogslow on this box, there must be something Jan else playing here too... I'm not using konqueror, and I'm not sure konqueror is using getaddrinfo(3) with AF_UNSPEC. However, I confirmed that our getaddrinfo(3) doesn't issue bogus query on my 6.1-RC box. The following sequence is from our getaddrinfo(3) with AF_UNSPEC: 00:58:23.041513 IP 192.168.100.140.61204 192.168.100.29.53: 32939+ A? images.slashdot.org. (37) 00:58:23.047501 IP 192.168.100.29.53 192.168.100.140.61204: 32939 1/5/5 A 66.35.250.55 (242) 00:58:23.047692 IP 192.168.100.140.65411 192.168.100.29.53: 32940+ ? images.slashdot.org. (37) 00:58:23.054429 IP 192.168.100.29.53 192.168.100.140.65411: 32940 0/1/0 (96) Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
sk0: watchdog timeout
My motherboard has a built-in ethernet port that is handled by the sk driver. I'm running FreeBSD 6.1-RC on amd64. When the network card is under high load, it often kills any current connections and leaves the message sk0: watchdog timeout in dmesg. I've seen previous posts on this issue, but the problem doesn't seem to be resolved. This issue makes these network cards unusable in production environments. Relevent dmesg output: skc0: Marvell Gigabit Ethernet port 0xa000-0xa0ff mem 0xfbb0-0xfbb03fff ir q 17 at device 10.0 on pci0 skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9) sk0: Marvell Semiconductor, Inc. Yukon on skc0 Any help would be appreciated, Miles ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.x on an IBM T42 laptop
Is anyone aware of any regressions in laptop functionality going from 5.4 to 6.x? If you're worried, just burn a FreeSBIE first. Paul ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
How to disable libcom_err from being built?
Hi - I have an install base of machines running MIT Krb5 (which have their own com_err implementation), and I have always used NO_KERBEROS=true so that the integrated Heimdal stuff wouldn't be built during a buildworld. However libcom_err does, and that causes issues when trying to link in programs that are linked to MIT Krb5. What I am asking is - can NO_KERBEROS be extended to cover com_err? Thanks - Peter signature.asc Description: OpenPGP digital signature
Re: quota deadlock on 6.1-RC1
On 5/5/06, Pawel Jakub Dawidek [EMAIL PROTECTED] wrote: It isn't good to release a software with known, documented bugs, but its better than shipping an untested software with god-one-knows unknown bugs. There's another reasonable option: the known buggy code could be disabled by default, and left to the user to enable if they want to test it and provide feedback. The feature is in no way critical, so the harm would be minimal. Another option is to delay the release until the bugs are fixed and patched, but the impression I get here is that releases absolutely must occur, so that option won't be explored. The only reason I have been pushing this issue is because the bug affects the core subsystem of the OS, and because when the bug occurs, the average user is left with no feedback and no options other than to hard-reset the box and cross his fingers. I don't think this should be acceptable. I'll continue to apply the workaround locally, and will continue to recommend others do the same, and I guess that'll be that. Thank you for the feedback. I'll re-file my findings in a new PR so the issue can be tracked outside this thread (which has strayed significantly from the original subject, my apologies). -- David 'dpk' Kirchner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
DVD Burners/USB
Hello, I recently replaced a DVD Automated Burner unit with a newer model. The older model used firewire for the drive interface and dvd+rw-tools worked fine. The new model uses USB 2.0 ports (1 for each drive.) Unfortunately, it seems that dvd+rw-tools no longer seems to work. Running dvd+rw-mediainfo returns a GET CONFIGURATION error. cdrecord seems to work fine for burning CDs, but I don't currently have a license for the DVD code. The system is running FreeBSD 6.0 Stable from around February. I was just curious if anyone was aware of some sort of issue with the usb/umass interface that would not allow dvd+rw-mediainfo to access the drive correctly when the firewire/sbp interface would. Thanks, Jaime Bozza ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
This quota/nve problem sure stirred things up, i guess im partly to blame, but anyway i think that it all boils down to is this; FreeBSD users now demand stability and performance, as opposed to an influx of new bells and whistles just before the release. FreeBSD already has many great features which we are happy with, but they need to be refined now. Stabilize and optimize the current code, then focus on new ideas. Yes, new features are important to stay in the game, but they should not arrive at the sacrifice of stability. I think FreeBSD should only be released when known major bugs are worked out. A known broken release to me and most new users is useless, lets not release simply for the sake of numbering. I understand that there are problems, sometimes the users are to blame, other the developer, but we all want a stable, functional and thriving OS (i hope). I wish i was a good Unix C programmer myself, so i could contribute in a more direct way (always hated those damn pointers), but thats just not the case. However i think i have contributed quite a bit in other areas, that may not be visible to everyone. I even managed to get the first (afaik) FreeBSD server in to FedEx, which they are very pleased with btw. I don't mean to offend anyone, i fully understand that this is a volunteer project and i appreciate everyones contribution, its just that i think FreeBSD has some problems currently, and there are quite a few people that are concerned. We all love and want FreeBSD to succeed. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
On Fri, 5 May 2006, Mike Jakubik wrote: This quota/nve problem sure stirred things up, i guess im partly to blame, but anyway i think that it all boils down to is this; FreeBSD users now demand stability and performance, as opposed to an influx of new bells and whistles just before the release. FreeBSD already has many great features which we are happy with, but they need to be refined now. Stabilize and optimize the current code, then focus on new ideas. Yes, new features are important to stay in the game, but they should not arrive at the sacrifice of stability. I think FreeBSD should only be released when known major bugs are worked out. A known broken release to me and most new users is useless, lets not release simply for the sake of numbering. I understand that there are problems, sometimes the users are to blame, other the developer, but we all want a stable, functional and thriving OS (i hope). I think you'll find that the vast majority of changes going into 6.x and 7.x are refinement of what was present in 5.x, rather than new features. I.e., cleanups of locking models, removal of long-decayed or no longer useful code, finishing up loose ends, etc. Compared to the new feature lists for the 5.x branch, 6.x and 7.x are significantly less agressive. Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
Mike Jakubik wrote: This quota/nve problem sure stirred things up, i guess im partly to blame, but anyway i think that it all boils down to is this; FreeBSD users now demand stability and performance, as opposed to an influx of new bells and whistles just before the release. FreeBSD already has many great features which we are happy with, but they need to be refined now. Stabilize and optimize the current code, then focus on new ideas. Yes, new features are important to stay in the game, but they should not arrive at the sacrifice of stability. I think FreeBSD should only be released when known major bugs are worked out. A known broken release to me and most new users is useless, lets not release simply for the sake of numbering. I understand that there are problems, sometimes the users are to blame, other the developer, but we all want a stable, functional and thriving OS (i hope). I wish i was a good Unix C programmer myself, so i could contribute in a more direct way (always hated those damn pointers), but thats just not the case. However i think i have contributed quite a bit in other areas, that may not be visible to everyone. I even managed to get the first (afaik) FreeBSD server in to FedEx, which they are very pleased with btw. I don't mean to offend anyone, i fully understand that this is a volunteer project and i appreciate everyones contribution, its just that i think FreeBSD has some problems currently, and there are quite a few people that are concerned. We all love and want FreeBSD to succeed. Please contact me privately with a list of issues on the 6.1 TODO list that are presently affecting you, and I will personally resolve them for you. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
One detail of this has to do with version numbering. The FreeBSD version number says a lot more about the userland than it does about the kernel per se. If we were to version the kernel arch, I think it would look more like this: '94 1.1.5.1 (Last Net/2) Version 0 Nov '94 2.0.5(First unencumbered release) Aug '96 2.1.5 Nov '96 2.2 Version 1 Oct '98 3.0 Major VM changes... Version 2 Mar '00 4.0refinement of 3.x Jan '03 5.0 Major SMP changesVersion 3 Jul '05 6.0refinement of 5.x ??? 7.0refinement of 5.x,6.x ??? 8.0 ??? Version 4 As you can see... major version numbers come and go, but that doesn't say very much about the kernel. Given that it took at least three years for the Version 2 arch to mature after it was initially released, is it any surprise that now at not quite 3 years after Version 3 was released it isn't yet mature? Esp given how radical the differences are between 2 and 3? STABLE is a comment mostly about API/ABI and somewhat (more as merely a matter of pride in craft) about the kernel. (The latter also shows itself in the extensive testing done outside of the treer in the usability of -CURRENT, etc) Paul * This concept of versions represents only my personal opinions. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
At 02:27 PM 05/05/2006, Mike Jakubik wrote: This quota/nve problem sure stirred things up, i guess im partly to blame, but anyway i think that it all boils down to is this; FreeBSD users now demand stability and performance, as opposed to an influx of new bells and I think you *are* forgetting it is a volunteer project, so demand is not a word that can really come into play. No one here has made any commitment to you or any other user about what will and will not be in FreeBSD. If FreeBSD meets your needs, thats great! If not, perhaps try help fixing it yourself, or contributing funds to have someone fix it. I have been using FreeBSD for some time and run a LOT of my business on top of it. So when things dont work, its a drag. Deal with it as best you can (e.g. fix it yourself, work around it or choose a new OS or pay someone to fix it). In the case of quotas, dont use snapshots. In the case of the NVE, a $5 realtek (rl) will work just fine. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
Scott Long wrote: Please contact me privately with a list of issues on the 6.1 TODO list that are presently affecting you, and I will personally resolve them for you. Scott, thanks for the very generous gesture, but i cant ask you something like this. The problems that are affecting me are quota and bge related, i will wait for them to be resolved in -STABLE. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
Make Jakubik wrote: FreeBSD users now demand stability and performance, as opposed to an influx of new bells and whistles just before the release [...] I fully understand that this is a volunteer project [...] I'm sorry, but the former statement proves the latter false. Let's try to do our Semi-Annual Refresher Course On Open Source Development: The developers (at least 99% of them) work for free. In their own spare time. Their motivations vary but I don't believe any of those include being in a position to feel they need to respond to demands. That's not a positive motivator. If they wanted to be in that position, they could just stay at their $realjobs for those extra hours. Part of their shared goals, however, is to turn out the best system that they possibly can, in the hopes that people will find it useful and want to contribute back to it. However, there are no guarantees involved, implicit or explicit. (If you want to compare and contrast to how much guarantee you get from closed-source development, please pull out a copy of your EULA. They barely even guarantee that there are bits on the CD.) There's a long process where the developers try to agree on what features need to be included and what bugs need to be fixed. From the standpoint of the people who attempt to coordinate this process, in technical jargon the process is know as herding cats. I would be able to serve as an expert witness in court about this. (Side note: some of the cats hiss, bite, and scratch; very few, if any, have _any_ interest in being herder.) There are always tradeoffs between stability and features. During the 5.X cycle we managed in some degree to de-optimize both: we had features that were only available in an experimental branch that some people considered critical (wireless, anyone?) while that experimental branch was unsuitable for production use. The idea was that we would hold on to declaring 5.X STABLE until all the major bugs were fixed. And as a consequence, we didn't release for -- what, 2 years? So we've thrown out the idea of wait until every possible bug is fixed. It leads to rare releases, and larger code chaos, larger instability, and allows FreeBSD's detractors to sniff well, they're never going to release anything again. (Notice how the BSD is dying crowd on Slashdot has been a lot quieter since we released 6.0?) So now what we're doing is trying to come up with more regular (not on absolute deadline) releases, with smaller feature sets, to enable smaller sets of new code to be debugged simultaneously. The features that some users see as critical, others don't. (I don't have quotas enabled; I have disabled soft-updates on the theory that as a single user I can trade longer startup time for possibly greater error recovery). I wish i was a good Unix C programmer myself, so i could contribute in a more direct way And there's the rub. The people who _are_ good Unix/C programmers are the ones doing the work, and as such, feel that they have the final say about what goes and what doesn't. While I hope that each of them will listen to what individual users are saying, and take good suggestions to heart, the fact remains that they are under no _obligation_ to do so. Finally, as has been pointed out already, the interactions between quotas, soft-updates, and the rest of the system have problems that are probably going to be fairly difficult to isolate and test. Thus, they could take days, weeks, or months. If we were to hold the release until these were fixed, basically our last 2 months of QA would be out the window. This is not a way to keep developers happy; at some point they will tire of the inability to work on the things that they find interesting, and wander off to find something else more fun to do. Summary: it's too bad that there are regressions, but sometime they're a fact of life. If these regressions are in areas that are critical for a certain user, that user should just skip 6.1 and wait for 6.2. The stability gains that 6.1 have over 6.0 in so many other areas means that it's time for 6.1 to go out the door, because for the majority of users it's going to be a big win. As always, we welcome test cases on e.g. non-critical systems, earlier in the release process (or between releases), where there's enough time to thoroughly test that any proposed fix doesn't cause more problems than it cures. Within a few days of release, that simply isn't the case right now. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
Mike Tancsa wrote: At 02:27 PM 05/05/2006, Mike Jakubik wrote: This quota/nve problem sure stirred things up, i guess im partly to blame, but anyway i think that it all boils down to is this; FreeBSD users now demand stability and performance, as opposed to an influx of new bells and I think you *are* forgetting it is a volunteer project, so demand is not a word that can really come into play. No one here has made any No i am not, i made that clear, please read the whole message again. commitment to you or any other user about what will and will not be in FreeBSD. If FreeBSD meets your needs, thats great! If not, perhaps try help fixing it yourself, or contributing funds to have someone fix it. I have been using FreeBSD for some time and run a LOT of my business on top of it. So when things dont work, its a drag. Deal with it as best you can (e.g. fix it yourself, work around it or Just because it's a volunteer project, doesn't mean the community has no right to express their ideas and concerns. If everyone were to sit quietly the state of this and even the existence of other BSDs would not be the same as now. choose a new OS or pay someone to fix it). In the case of quotas, dont use snapshots. In the case of the NVE, a $5 realtek (rl) will work just fine. It's not always that simple. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sk0: watchdog timeout
On Fri, May 05, 2006 at 01:03:55PM -0400, Miles Lubin wrote.. My motherboard has a built-in ethernet port that is handled by the sk driver. I'm running FreeBSD 6.1-RC on amd64. When the network card is under high load, it often kills any current connections and leaves the message sk0: watchdog timeout in dmesg. I've seen previous posts on this issue, but the problem doesn't seem to be resolved. This issue makes these network cards unusable in production environments. Relevent dmesg output: skc0: Marvell Gigabit Ethernet port 0xa000-0xa0ff mem 0xfbb0-0xfbb03fff ir q 17 at device 10.0 on pci0 skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9) sk0: Marvell Semiconductor, Inc. Yukon on skc0 I had a similar event last night, on a P4 on an Asus P4P800. The current driver is much less prone to this lockup problem than it used to be. In my case it does not have to be in a high-load situation, it appears to happen rather randomly (and *very* infrequently) FreeBSD freebie.xs4all.nl 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #2: Thu May 4 22:37:22 CEST 2006 skc0: 3Com 3C940 Gigabit Ethernet port 0xe800-0xe8ff mem 0xf7ffc000-0xf7ff irq 22 at device 5.0 on pci2 skc0: 3Com Gigabit LOM (3C940) rev. (0x1) sk0: Marvell Semiconductor, Inc. Yukon on skc0 sk0: Ethernet address: 00:0c:6e:4f:77:0c miibus0: MII bus on sk0 e1000phy0: Marvell 88E1000 Gigabit PHY on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto For the time being I stuck a em(4) in this machine, it is my primary server and I need to have it running for my work as re-builder for the Alpha platform :) Wilko -- Wilko Bulte [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: quota deadlock on 6.1-RC1
Mark Linimon wrote: Make Jakubik wrote: FreeBSD users now demand stability and performance, as opposed to an influx of new bells and whistles just before the release [...] I fully understand that this is a volunteer project [...] I'm sorry, but the former statement proves the latter false. Let's try to do our Semi-Annual Refresher Course On Open Source Development: Mark, you bring up a lot of valid points, which i agree with. Maybe i needed a refresher. I can certainly understand the developers loosing interest when they are denied the ability to work on what they are themselves interested in. Perhaps a frequent release cycle is the answer. However, i think things should stay in -CURRENT a bit longer before they make it to -STABLE, i.e. the openbsd dhcp client import caused a lot of problems. In any case, i am grateful to all the contributors and quite happy with what FreeBSD is today, so there wont be any more complains from me on this subject, i vented my steam, and got a refresh on reality. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
Guys, I appreciate the attempts at rational explaination from camp A, and I appreciate the flood of emotional outpouring from camp B. However: Mike Jakubik, David Kirchner, and others: You are making a mountain out of a molehill and exploiting the unprecendented openness of the release engineering team to further your agendas of being unhelpful malcontents. Dictating what you feel should happen is absolutely 100% worthless and a waste of time. Your focus on a small subset of issues completely ignores the large volume of things that have been improved, and the hard work that has been done by a team of hundreds to bring you those improvements. Your opinions are noted and recorded for posterity. Thank you. Now, if you are actually interested in helping, I have a very long list of technical and non-technical tasks that I would be quite willing to share that will go towards continuing our tradition of having good releases. No programming experience required. Apply within. EOE. Mark Linimon, Kris Kenneway, Robert Watson, and others: Thank you very much for your attempts at rational explaination. I think that just about every angle has been covered, and covered multiple times. Unfortunately, I think that this topic has gotten into 'feed the troll' phase, which is unfortunate but also a sign that it's time to move on and go back to doing good work. Thank you again. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota deadlock on 6.1-RC1
On Fri, 5 May 2006, Paul Allen wrote: One detail of this has to do with version numbering. The FreeBSD version number says a lot more about the userland than it does about the kernel per se. If we were to version the kernel arch, I think it would look more like this: '94 1.1.5.1 (Last Net/2) Version 0 Nov '94 2.0.5(First unencumbered release) Aug '96 2.1.5 Nov '96 2.2 Version 1 Oct '98 3.0 Major VM changes... Version 2 Mar '00 4.0refinement of 3.x Jan '03 5.0 Major SMP changesVersion 3 Jul '05 6.0refinement of 5.x ??? 7.0refinement of 5.x,6.x One of the problems we've had in the last ten years was the piling on of features during the 5.x release cycle. Because two very large development projects were going on simultaneously (KSE, SMPng), at the same time as the dotcom bubble burst, greatly reducing various companies commitments of staff resources to FreeBSD, the brach for 5-STABLE kept getting deferred. For better, or sometimes worse, new features kept getting added to avoid stalling all development while SMPng and KSE stabilized. These new features kept deferring the branch date, of course :-). I think there is universal recognition that while the features in FreeBSD 5.x were really great, trickling them in over a longer period of time, and avoiding the steep stability surves for them happening simultaneously, would have been better (in retrospect). The reason we're now trying to move onto a fixed schedule release cycle is to try and limit that: instead of saying Yes, we can defer the release for new feature x, we instead say, We can't add feature x because there isn't time for it to stabilize before the release. By being a little less feature agressive in the short term, we can increase stability, and in fact improve feature delivery in the long term. So there are a variety of new features in the pipeline for 7.x, but we've actually been focussing almost exclusively on stability and performance so far. So what to expect in the future? A slightly less agressive feature schedule for major releases -- 5.x had UFS2, KSE, SMPng, TrustedBSD, OpenPAM, a new gcc, etc. 6.x had significant network stack refinements, VFS SMPng work, etc, but nothing like the feature list of 5.x. The main distinguishing factor for 7.x right now is Audit, which while a good bullet feature, but relatively non-intrusive. I'd expect to see further UFS and VFS work, etc, possibly including a move to UFS journalling from the bgfsck model, a Giant-free NFS client, further refinement of locking in the storage stack, ARM support, and so on. But by driving feature integration by schedule, things should go more smoothly. For example, Audit is in 7.x -- we wanted to merge it for 6.1, but decided that the 6.1 schedule simply didn't allow it, so it will likely appear in 6.2 and 7.0. That's a lot better than merging it prematurely, deferring the release 6 months for it to stabilize, and shipping it prematurely anyway. Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FTPd recommendation?
My vote goes to PureFtpd.. It`s ideal server.. On 5/4/06, N.J. Thomas [EMAIL PROTECTED] wrote: * Noah [EMAIL PROTECTED] [2006-05-04 05:48:40 -0800]: What are people using for their ftpd these days? I am looking for something easy to initiailize, configure, and is very secure. Another vote for vsftpd: http://vsftpd.beasts.org/ Trivial to setup/configure, very secure. In addition to all of the normal security features that vsftpd offers, we turn on the pasv_min_port/pasv_max_port options to restrict the download ports, it's a nice feature. (I attended an Apache/FTP security lecture in the Bay Area a couple of years ago (2002/2003) at one of the local user groups there -- the speaker was testing out his talk on us before he gave it at some Usenix/SAGE conference. The ftp portion was a howto on securing wu-ftpd, but before he started, he said point blank that if you didn't need anonymous uploads, to just use vsftpd.) Thomas -- N.J. Thomas [EMAIL PROTECTED] Etiamsi occiderit me, in ipso sperabo ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [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: 6.x on an IBM T42 laptop
From: Nik Clayton [EMAIL PROTECTED]
I've got an IBM T42 laptop that's currently running 5.4, and it's working
nicely at the moment. ACPI works well enough that suspend to RAM works
('zzz'), the audio works, USB devices are recognised, and the battery life's
reasonable (with est enabled).
Is anyone aware of any regressions in laptop functionality going from 5.4 to
6.x?
I've been running 6-STABLE on a T42 for a while and not noticed any
problems in the subjects mentioned. The addition of iwi has made life
a little simpler. I think it is ok to take the leap...
-mark
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sk0: watchdog timeout
On Fri, 5 May 2006, Wilko Bulte wrote: On Fri, May 05, 2006 at 01:03:55PM -0400, Miles Lubin wrote.. My motherboard has a built-in ethernet port that is handled by the sk driver. I'm running FreeBSD 6.1-RC on amd64. When the network card is under high load, it often kills any current connections and leaves the message sk0: watchdog timeout in dmesg. I've seen previous posts on this issue, but the problem doesn't seem to be resolved. This issue makes these network cards unusable in production environments. Relevent dmesg output: skc0: Marvell Gigabit Ethernet port 0xa000-0xa0ff mem 0xfbb0-0xfbb03fff ir q 17 at device 10.0 on pci0 skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9) sk0: Marvell Semiconductor, Inc. Yukon on skc0 I had a similar event last night, on a P4 on an Asus P4P800. The current driver is much less prone to this lockup problem than it used to be. In my case it does not have to be in a high-load situation, it appears to happen rather randomly (and *very* infrequently) FreeBSD freebie.xs4all.nl 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #2: Thu May 4 22:37:22 CEST 2006 The updated driver has been in HEAD for some days and the problem should be fixed there thanks to Pyun. See last commits to src/sys/dev/sk/* -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sk0: watchdog timeout
On Fri, May 05, 2006 at 08:26:54PM +, Bjoern A. Zeeb wrote.. On Fri, 5 May 2006, Wilko Bulte wrote: On Fri, May 05, 2006 at 01:03:55PM -0400, Miles Lubin wrote.. My motherboard has a built-in ethernet port that is handled by the sk driver. I'm running FreeBSD 6.1-RC on amd64. When the network card is under high load, it often kills any current connections and leaves the message sk0: watchdog timeout in dmesg. I've seen previous posts on this issue, but the problem doesn't seem to be resolved. This issue makes these network cards unusable in production environments. Relevent dmesg output: skc0: Marvell Gigabit Ethernet port 0xa000-0xa0ff mem 0xfbb0-0xfbb03fff ir q 17 at device 10.0 on pci0 skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9) sk0: Marvell Semiconductor, Inc. Yukon on skc0 I had a similar event last night, on a P4 on an Asus P4P800. The current driver is much less prone to this lockup problem than it used to be. In my case it does not have to be in a high-load situation, it appears to happen rather randomly (and *very* infrequently) FreeBSD freebie.xs4all.nl 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #2: Thu May 4 22:37:22 CEST 2006 The updated driver has been in HEAD for some days and the problem should be fixed there thanks to Pyun. See last commits to src/sys/dev/sk/* Once it gets MFC-ed to 6 I will give it another try. -- Wilko Bulte [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: quota deadlock on 6.1-RC1
Mike Jakubik wrote: arrive at the sacrifice of stability. I think FreeBSD should only be released when known major bugs are worked out. A known broken release to me and most new users is useless, lets not release simply for the sake of numbering. For me, and many other quiet users, FreeBSD *IS* stable. I've been running 6.1 since the BETAs with no issues. No, I don't use quotas. I doubt the majority of FreeBSD users do. I wish i was a good Unix C programmer myself, so i could contribute in a more direct way (always hated those damn pointers), You could always hire or help sponsor a developer to fix your pet issues. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
howto/hack for Matrox's mga_hal and Xorg 6.9.
[I've seen some comments here about people struggling w/ mga_hal, so I thought I'd share this.] I wanted to use features of the Matrox mga x11 driver (dual headed digital video) that required the hal, but I wasn't able to get the mga_hal port to work with Xorg 6.9. I cobbled up an underhanded hack that resulted in a working set of binaries, based on some hacks that the Linux community was using. If you need to use mga_hal w/ Xorg 6.9 on -STABLE, my hack might be useful. You can find the details at: http://forum.matrox.com/mga/viewtopic.php?t=19868 g. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb to serial
On Saturday 06 May 2006 00:34, David Coder wrote: thx for the suggestions, guys. with device uftdi device uplcom You can just kldload these BTW. Saves time when testing :) in the kernel config the adapter shows up as ugen0: ArkMicroChips USB-UART Controller, rev 1.10/0.01, addr 2 What does usbdevs -v say about it? I have a CP2102 based device here and I am currently trying to port the Linux driver (reverse engineered from USB tracing) - you may be in the same boat. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpIHOkNSz2eC.pgp Description: PGP signature
Re: system crash during file copy to a floppy with bad sectors
On Saturday 06 May 2006 09:33, Rostislav Krasny wrote: Can you get a back trace? ie enable crash dumps and do it again, or transcribe, or photograph the screen as it panics if you are local. Unfortunately I cannot reproduce it now. Doesn't the old log help? There is one Fatal trap 12. Only if you have the backtrace I think. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpEiWuPSC0dx.pgp Description: PGP signature
6.1-RC and the audit group
Last night I updated on of my machines from 6.0-RELEASE to 6.1-RC. As far as I understand, I followed the instructions correctly - in particular: boot -s # fsck -p # mount -u / # mount -a # adjkerntz -i # cd /usr/src # mergemaster -p # make installworld I found that installworld stops, because the 'audit' group has not been created. Now I just pressed 'return' for the default actions during mergemaster -p, but I didn't notice any mention of the audit group. after manually adding it, and re-running installworld, I noticed that (after delete-old) the second 'mergemaster' has a group temporary file with 'audit' in it (as it wanted to remove mine and add its own - I'd used 70 instead of 77 as gid). So...err, I obviously missed something in during mergemaster -p, where does it do the audit addition? Cheers Mark P.s : 6.1-RC is running very nicely right now. Great work! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system crash during file copy to a floppy with bad sectors
On Fri, 5 May 2006 10:01:09 +0930 Daniel O'Connor [EMAIL PROTECTED] wrote: On Friday 05 May 2006 07:41, Rostislav Krasny wrote: write the same file to the same floppy I didn't run umount and it crashed again. Following are footsteps of the first crash, founded in the /var/log/messages. I hope they may help to localize the problem. From the log it looks like some VFS problem. Can you get a back trace? ie enable crash dumps and do it again, or transcribe, or photograph the screen as it panics if you are local. Unfortunately I cannot reproduce it now. Doesn't the old log help? There is one Fatal trap 12. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sk0: watchdog timeout
On Sat, May 06, 2006 at 12:10:46AM -0400, Miles Lubin wrote: I know this is rather late in the release process, but given that this issue will affect many people, I think it should be considered fixing this driver for 6.1. The release is imminent. The last Ts are being crossed and Is dotted. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
