changing a ports final destination via make knobs question...
Greetings, Given that the folks at PHP have decided that no one is allowed to use PHP4 any longer. I've decided to *attempt* to install a copy of PHP5 (cgi only) along side my already installed/configured, and in use copy of PHP4 (apache_module, CLI, & CGI). I spent some time attempting to find successful stories regarding my attempt. But all were for different OS's, and most were *quite* dated. So I took a stab at it, after looking at the Makefile in lang/php5. But it did *NOT* end up where I thought it would. In fact, it clobbered some of my PHP4 install. SO, please find here my desperate plea for the make knob(s)/env options required to install a copy of PHP5 (CGI) beside my already installed/working PHP4. I had tried/ hoped to simply create a --prefix=php5/, thinking that I'd end up with: /usr/local/bin/php5/(php-cgi, phpize, php-config), and /usr/local/etc/php5/php-ini-*, /usr/local/include/php5/*, /usr/local/lib/php5/*. by way of the ports system. But I *clearly* didn't set things correctly. *Any* help/advice would be *GREATLY* appreciated. Thank you for all your time and consideration. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: changing a ports final destination via make knobs question...
Quoting Chris St Denis <[EMAIL PROTECTED]>: [EMAIL PROTECTED] wrote: Greetings, Given that the folks at PHP have decided that no one is allowed to use PHP4 any longer. I've decided to *attempt* to install a copy of PHP5 (cgi only) along side my already installed/configured, and in use copy of PHP4 (apache_module, CLI, & CGI). I spent some time attempting to find successful stories regarding my attempt. But all were for different OS's, and most were *quite* dated. So I took a stab at it, after looking at the Makefile in lang/php5. But it did *NOT* end up where I thought it would. In fact, it clobbered some of my PHP4 install. SO, please find here my desperate plea for the make knob(s)/env options required to install a copy of PHP5 (CGI) beside my already installed/working PHP4. I had tried/ hoped to simply create a --prefix=php5/, thinking that I'd end up with: /usr/local/bin/php5/(php-cgi, phpize, php-config), and /usr/local/etc/php5/php-ini-*, /usr/local/include/php5/*, /usr/local/lib/php5/*. by way of the ports system. But I *clearly* didn't set things correctly. *Any* help/advice would be *GREATLY* appreciated. Thank you for all your time and consideration. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" This should probably go on freebsd-questions list Hello, and thank you for your reply. Agreed, but my inbox couldn't handle the volume. So since I've already been subscribed to this list for a few yrs. I hoped that given this should likely end up a short thread, it'd be no big deal. :) Try *make **PREFIX=/usr/local/php5* and *make install **PREFIX=/usr/local/php5* I can't help but notice that your suggested make defines are wrapped in asterisks. I'm going to assume you did that to highlight them. :) I did this to get php4 working as a cgi with php5 installed regularly as mod_php. Seems to work ok. * * I'll give it a go. Thanks for the suggestion. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: changing a ports final destination via make knobs question...
Quoting Chuck Swiger <[EMAIL PROTECTED]>: Hi-- On Aug 26, 2008, at 12:42 PM, [EMAIL PROTECTED] wrote: Given that the folks at PHP have decided that no one is allowed to use PHP4 any longer. I've decided to *attempt* to install a copy of PHP5 (cgi only) along side my already installed/configured, and in use copy of PHP4 (apache_module, CLI, & CGI). [ ... ] *Any* help/advice would be *GREATLY* appreciated. You might consider doing your builds and testing on another machine entirely, to avoid disrupting a system which is in use. Quite right! But a couple of reasons I elected to do it anyway; * I have a *good* backup schedule * This server is scheduled for upgrade (source && ports) So if anything went too terribly wrong, nothing is lost. Also, it only clobbered some of the includes, and ini files. Given that I had no reason to add any more extensions/libs to the PHP4 version, no harm done. PHP4 runs as it did prior to the PHP5 experiment. :) Another option to consider is using a chroot'ed environment or jail using $DESTDIR (cf /usr/ports/Mk/bsd.destdir.mk). Finally, if neither of the previous seems to suit, then you can change where ports are installed by adjusting $LOCALBASE. I'll have a close look at $LOCALBASE. That sounds like a good candidate. With any luck, it'll also cover extensions, ini(s), and related libs. :) Thank you for taking the time to respond. --Chris Regards, -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: changing a ports final destination via make knobs question...
Quoting Paul Schmehl <[EMAIL PROTECTED]>:
--On August 26, 2008 2:09:27 PM -0700 [EMAIL PROTECTED] wrote:
I'll have a close look at $LOCALBASE. That sounds like a good
candidate. With any luck, it'll also cover extensions, ini(s), and
related libs. :)
Please be aware that if you change ${LOCALBASE} you change it for
*all* subsequently installed port. Chris' suggestion to use make
install PREFIX=/usr/local/php5 is the correct one for changing the
location of a single port.
Hello, and thank you very much for your reply.
Yes. After looking closely at the variable, I discovered that also.
So I used the PREFIX=/usr/local/php5. But as I build it (via php5-extensions)
I am not seeing the PREFIX variable reflected. Shouldn't I be using:
make -DPREFIX=/usr/local/php5? Or simply hack the Makefile?
Thanks again for taking the time to respond.
--Chris
Paul Schmehl, If it isn't already
obvious, my opinions are my own
and not those of my employer.
**
WARNING: Check the headers before replying
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: changing a ports final destination via make knobs question...
Quoting [EMAIL PROTECTED]:
Quoting Paul Schmehl <[EMAIL PROTECTED]>:
--On August 26, 2008 2:09:27 PM -0700 [EMAIL PROTECTED] wrote:
I'll have a close look at $LOCALBASE. That sounds like a good
candidate. With any luck, it'll also cover extensions, ini(s), and
related libs. :)
Please be aware that if you change ${LOCALBASE} you change it for
*all* subsequently installed port. Chris' suggestion to use make
install PREFIX=/usr/local/php5 is the correct one for changing the
location of a single port.
Hello, and thank you very much for your reply.
Yes. After looking closely at the variable, I discovered that also.
So I used the PREFIX=/usr/local/php5. But as I build it (via php5-extensions)
I am not seeing the PREFIX variable reflected. Shouldn't I be using:
make -DPREFIX=/usr/local/php5? Or simply hack the Makefile?
OK. Never mind. Installing via lang/php5-extensions w/
make PREFIX=/usr/local/php5
resulted in:
Installing PHP CGI into: /usr/local/php5/bin/
Installing build environment: /usr/local/php5/lib/php/build/
Installing header files: /usr/local/php5/include/php/
Installing helper programs: /usr/local/php5/bin/
program: phpize
program: php-config
Installing man pages: /usr/local/php5/man/man1/
So that went as desired.
But the extension(s) vomited because I renamed phpize (PHP4) php4ize.
OOOPS! I thought I should do that 'cause of potential versioning issues
- guess not.
Thanks again for taking the time to respond.
--Chris
Thanks again for taking the time to respond.
--Chris
Paul Schmehl, If it isn't already
obvious, my opinions are my own
and not those of my employer.
**
WARNING: Check the headers before replying
___
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: changing a ports final destination via make knobs question...
Quoting Paul Schmehl <[EMAIL PROTECTED]>:
--On August 26, 2008 3:05:25 PM -0700 [EMAIL PROTECTED] wrote:
Hello, and thank you very much for your reply.
Yes. After looking closely at the variable, I discovered that also.
So I used the PREFIX=/usr/local/php5. But as I build it (via
php5-extensions)
I am not seeing the PREFIX variable reflected. Shouldn't I be using:
make -DPREFIX=/usr/local/php5? Or simply hack the Makefile?
If you're trying to force the install of php5 by installing
php5-extensions, that's not going to work. Php5 will be built with
the default ${LOCALBASE} instead.
There are several ways to work around the problem. You can build
php5 first, with the altered PREFIX, then build php5-extensions with
the altered PREFIX. You can set the PREFIX for php5 and
php5-extensions in /usr/local/etc/pkgtools.conf (see the extensive
notes in the file or read man (5) pkgtools.conf).
You can edit the Makefiles for the affected ports, but changing
PREFIX in a Makefile is tricky, so testing carefully is required.
Furthermore, the Makefiles will be overwritten every time the port is
updated, so it's really not the best way to do things.
You can even edit /etc/make.conf, but that changes the parameters for
all ports.
If you plan on doing this often, pkgtools.conf is your best bet. If
you plan on doing it once, commandline is probably the easiest and
quickest.
If you choose to use pkgtools.conf, you'd probably want something like this:
MAKE_ARGS = {
'lang/php5*' => 'PREFIX=/usr/local/php5',
}
Hello. Let me preface the following by first thanking you for your indulgence,
and taking the time to share your insight. :)
That said, as you already knew - php5 installed quite as intended. But the
extensions are "squealing like pigs" in my error log -
Unable to load dynamic library...
So I'm just going to uninstall the whole works, and start with PHP5, then
the extensions.
As per setting things up by editing the Makefile v using the /etc/make.conf;
I had considered saving the altered variables from the Makefile and using
USE_SUBMAKE, which would allow me to "suck" the changes into make. But then
wondered how I might continue using my usual conditionals in /etc/make.conf;
.if ${.CURDIR:M*/lang/php5}
WITH_THIS=TRUS
WITHOUT_THAT=TRUE
...
.endif
But hadn't experimented much beyond that, except a couple of others...
X_WINDOW_SYSTEM=xorg, WITH_GECKO=seamonkey,CPUTYPE?=pentium(N), etc.
You mention that it'll change the parameters for all ports. But I was
thinking that if used in an if.. then conditional I might be able to
limit it's scope.
Well, you've (kindly) given me some more studying to do. As I'm
getting a bit weary of this whole thing. I'm going to end it here, and
get on with it.
Thank you again for all your time and consideration.
--Chris
Paul Schmehl, If it isn't already
obvious, my opinions are my own
and not those of my employer.
**
WARNING: Check the headers before replying
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: changing a ports final destination via make knobs question...
Quoting "Matthew D. Fuller" <[EMAIL PROTECTED]>: On Tue, Aug 26, 2008 at 06:04:36PM -0500 I heard the voice of Paul Schmehl, and lo! it spake thus: If you plan on doing this often, pkgtools.conf is your best bet. If you plan on doing it once, commandline is probably the easiest and quickest. I would say using ports-mgmt/portconf would be a better bet, and maintained by the same maintainer as the PHP version I'm currently struggling with... I'll take it. :) It seems a lot less "kludgy" than the ways /I've/ been considering. All of which were not /nearly/ as eloquent as those that have been suggested here by Paul, Chris, and all. ;) since it does its thing whether you use make install or portupgrade or portmaster or portsuperwhatsit. A line like php5*: PREFIX=/usr/local/php5 should take care of all php5 base/extension ports, wherever in the tree they end up. Of course, you're still odd in the tricky woods building PECL stuff or the like, which could go against 4 or 5. But that's a different mess. Indeed. :) Thanks for taking the time to lend a hand. :) --Chris -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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]"
Is it safe to delete /bin/[ && /usr/bin/false?
Greetings,
Well, I en devoured to install a copy of 7 as an effort to upgrade
one of our servers. After installing a few ports, I began to notice:
[: -le: argument expected messages being emitted during the configure/make
process. I've already invested a fair amount of time on this upgrade,
and /really/ don't want to wipe the disk(s) and start all over. This
issue is not new to me - see thread:[: -le: argument expected for details.
But I have /yet/ to discover a solution. When I started the upgrade (install),
I had an /etc/make.conf. Thinking that this might be the culprit when
these messages starting to appear, I looked it over for possible typos.
The only possible issue I could see was the reference to databases/mysql:
.if ${.CURDIR:M*/databases/mysql*}
WITH_OPENSSL=yes
WITH_CHARSET=latin1
WITH_XCHARSET=complex
WITH_COLLATION=latin1_general_ci
WITH_PROC_SCOPE_PTH=yes
BUILD_OPTIMIZED=yes
WITH_ARCHIVE=yes
WITH_CSV=yes
.endif
NOTE the YES | NO, as opposed to TRUE | FALSE. I changed them to true v false.
But I have already built MySQL with the YES | NO. Could this be the issue?
Source(s) cvsupped 08-09-01
Thank you for all your time and consideration.
--Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is it safe to delete /bin/[ && /usr/bin/false?
Quoting Bill Campbell <[EMAIL PROTECTED]>: No it isn't safe to delete these as many, many scripts depend on them. LOL yes, I knew that :) My chosen title for the thread is more a reflection of my frustration with this problem. I'm hoping that a solution is possible. Because /bin/[ & /usr/bin/false are used to evaluate conditionals. It is /quite/ necessary for me to resolve /why/ this keeps happening. As nothing (many||most) things will not work as intended - if at all until the problem is found & fixed. Thank you for taking the time to respond. --Chris Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax:(206) 232-9186 One man's brain plus one other will produce one half as many ideas as one man would have produced alone. These two plus two more will produce half again as many ideas. These four plus four more begin to represent a creative meeting, and the ratio changes to one quarter as many ... -- Anthony Chevins ___ 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: Is it safe to delete /bin/[ && /usr/bin/false?
Hello, and thank you for your reply. Quoting Peter Jeremy <[EMAIL PROTECTED]>: On 2008-Sep-02 10:49:43 -0700, [EMAIL PROTECTED] wrote: Well, I en devoured to install a copy of 7 as an effort to upgrade one of our servers. After installing a few ports, I began to notice: [: -le: argument expected messages being emitted during the configure/make process. This probably indicates badly written configure scripts that have things like "[ 23 -le $x ]" but don't set $x. The solution is to write patches for the configure scripts and feed them back upstream. Bummer. I've already invested a fair amount of time on this upgrade, and /really/ don't want to wipe the disk(s) and start all over. I'm not sure how this will help. Good. Perhaps you (or anyone) can suggest how I might debug /when/where/ these eval are called. I could use /usr/bin/script, but not sure how to (e)grep the culprit(s). This issue is not new to me - see thread:[: -le: argument expected for details. You haven't mentioned where this thread exists - definitely not here. Ahem... Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: On Fri, Feb 01, 2008 at 10:18:14AM -0800, Chris H. wrote: I wanted to sync up my ports database before hand. So ran a portsdb -uU. ---8<---[huge snip]---8<--- Hello again Jeremy, Well, after carefully examining your reply; emptying /etc/make.conf; searching for any sign of another Apache APR, and finding none.; performing a cvsup -g -L 2 ports-supfile && portsdb -uU && pkgdb -F; which resulted in many [: -le: argument expected's, and [: -eq: argument expected's; I performed a: cd /usr/ports/lang/php5 && make extract; Yep! You guessed it, [: -le: argument expected again! Well, what was expected to be a 3 day affair, has turned into a 2 week affair. At least that's been my past experience with installing a FreeBSD server (3 days). :) Anyway, I've run out of patience (and time) debugging this issue. So I think it would be more expedient to wipe the disk and start anew. :) If I should run into this again on the new install. I guess a send-pr would be in order. Oh, and expect /alot/ of noise in the list. :) Thank you again for your continued (and valued) input. Best wishes. --Chris H [Hide Quoted Text] -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" I didn't mean to sound argumentative but the above was my last posting to the thread: [: -le: argument expected in freebsd-stable on Feb 2008. :) Thanks again for taking the time to respond. --Chris -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is it safe to delete /bin/[ && /usr/bin/false?
Hello, and thank you for your reply. Quoting Stanislav Sedov <[EMAIL PROTECTED]>: On Tue, 02 Sep 2008 12:25:51 -0700 [EMAIL PROTECTED] mentioned: Good. Perhaps you (or anyone) can suggest how I might debug /when/where/ these eval are called. I could use /usr/bin/script, but not sure how to (e)grep the culprit(s). Try to find the exact script which causes this (it'd be pretty easy if you could find a port with this error reproducible). Then you will be able to track the problem down by inserting a couple of echos/exits in the offending script and observing the result. Well, I ultimately found the problem by recognizing a pattern. Since the error messages hadn't proved fatal as far as I could see. I just continued to build as required - always keeping a watchful eye. I began to notice what seemed to be ports checking against Apache were emitting errors, where others were not. Then it occurred to me that my problem was self-inflicted. I had made some changes to the Apache source before making && installing. Because the changes were so unique, I bumped the version by a tenth of a point (1.4x). I then remembered all the Apache make conditionals being against 1.3 || 2 - the light went off in my pointy head; the version /I/ installed was != 1.3 || 2, but > 1.3 < 2. D'OH! Well, no harm has /yet/ come of it. The scripts simply emit the error and continue on their merry way. So unless something bombs farther down the road, I'll just accept/expect the errors knowing what they are trying to tell me. :) Thanks again for responding. --Chris -- Stanislav Sedov ST4096-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bugged sysinstall, bsdlabel, zfs, gmirror - recept for disaster :)
Congratulations! Thanks for sharing, I'm guessing that you've probably prevented a few ppl from tripping on this by posting this. Me; I'm still waiting for: make zfs ad0s1, ad1s1, ad2s1 install. :-) Best wishes. --Chris Quoting Bartosz Stec <[EMAIL PROTECTED]>: Hello there! Here's my story, hopefully some of you won't follow my steps and avoid some troubles :) Yesterday I've decided that's about time to test zfs functionality on my home server PC (i386 FreeBSD 7.1-pre) . A couple of weeks ago I bought new desktop PC (with SATA), so I had a bunch of PATA disks from old one to use in server. Lucky me - there was 3 HDD at size 40GB - RAIDZ was on approch! So after a thirty minutes I had a plan, and my server had 4 disks connected - one 20GB with actual system (ad1), and three 40GB to replace actual system (ad[023]). Plan was simple: 1. csup freebsd-stable 2. follow the tuning guide for zfs, rebuild world, kernel, and follow system upgrade 3. Reboot in single user mode 4. fdisk new disks with sysinstall using one big slice for every disk 5. bsdlabel every new disk with sysinstall using: 1GB for /, 512MB for swap, and rest unused (for ZFS) 6. gmirror -n -v -b round-robin boot ad0s1a ad2s1a ad3s1a 7. newfs /dev/mirror/boot 8. mount /dev/mirror/boot /mnt && cd /mnt 9. dump -h 0 -L -f - -C 32 / | restore rf - 10. zpool create tank raidz ad0s1d ad2s1d ad3s1d 11. zfs create new cool filesystems :) 12. dump | restore old ufs2 filesystem to new cool zfs filesystems :) 13. changing mount points from tank/foo to /foo 14. edit new fstab on mirror by replacing root mount point by "boot" mirror, adding new swaps and remove ald ones and all fs now placed on zpool 15. power off system, detach ad1 and power on new system in mixed gmirror - raidz environment. Yay! Well...it has almost works. Sysinstall screw it up. I was always too lazy to read man bsdlabel, that's why I've been using this "nice" tool for disk related tasks. Such a mistake! Problem with labels created with sysinstal, is that it aks for a mount point for every partition in slice. Well, in my case it was unwanted behaviour, so on every disk I created first: a:/ b: swap c: none d: /foo Then by using "M" key I removed mount points and saved changes with "W". At this point everything seems ok. So I've added gmirror to loader.conf and run "gmirror label -n -v -b round-robin boot ad0s1a ad2s1a ad3s1a". Still ok until now. Next step - kldload geom_mirror. Here's disaster! System became unresponsible and hangs after a while. Reboot didn't help, just after gmirror module was loaded by kernel, screen was flooded with messages: WARNING: Expected rawoffset 0, found 63 andy didn't boot. I've made system start only because an old drive ad1 has no gmirror module added to loader.conf. So after reboot I've cleared metadata on providers and made some another attempts, but results were always the same. Finally I have found explanation for this issue. Man bsdlabel says: /offset/ The offset of the start of the partition from the beginning of the drive in sectors, or *** to have *bsdlabel* calculate the correct offset to use (the end of the previous partition plus one, ignor- ing partition `c'). For partition `c', *** will be interpreted as an offset of 0. The first partition should start at offset 16, because the first 16 sectors are reserved for metadata. So proper labels for disks should be (and they are now): # /dev/ad0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 2097152 164.2BSD0 0 0 b: 1048576 2097168 swap c: 781561620unused0 0 # "raw" part, don't edit d: 75010418 3145744unused0 0 Problem was - Sysinstall has placed partition "a:" starting with offset 0! This is what happens when you don't RTFM :) I assume that this bug occured because I created mount point for root on ad[023]s1a and removed it after, than saved label. It seems that GEOM framework didn't expect this, neither maual for bsdlabel. I think that should be fixed somehow. Fortunately manually editing labels by "bsdlabel -e" wasn't so hard as I expected. This is how I made everything back to normal: a: 1024M *4.2BSD0 0 0 b: 512M * swap c: 781561620unused0 0 # "raw" part, don't edit d: * *unused0 0 After that, gmirror has stopped pissing me off, and I finished my plan, as below: # zpool status pool: tank state: ONLINE scrub: scrub completed with 0 errors on We
gjournal panic 7.0-RC1
I had originally enabled gjournal and seemed to have no problems but I was seeing errors in messages regarding dma write failures and after some research concluded I had setup gjournal incorrectly. I setup the gjournal again properly with soft updates disabled and doing a fresh newfs, mount showed it as enabled and I had the .journal mounted. Started copying files to it from another partition as I wanted to set that up on gjournal also and the copying I felt would be a good stress test to see if the errors stop, the errors were gone and I felt great but as it was about 80 gig of data to copy I went away to do something else for a bit. Came back to see box had rebooted itself from a journal related panic. panic: Journal overflow (joffset=49905408 active=499691355136 inactive=4990$ cpuid = 0 7.0-RC1 Fair to say this is not as stable as ufs + soft updates then? googling did show other occurances of problem or is there a patch/workaround for the issue? disks are both 500 gig each. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal panic 7.0-RC1
> I did some experimentation with gjournal a few weeks ago to determine > how I might partition > a new server, as well as how large to make my journals and where. I did > find that for the computers > I have tested so far, a 1 gig (default size) journal seems to be > sufficient, but half of that or less is > asking for trouble and I could not find any workarounds to reduce the > chances of panic when I > was already stuck with a too-small journal I created a while ago. I > also found the -s parameter > is vague in that it does not say what units it accepts (appears to be > bytes) and I *could not* get it > to make a journal inside a data partition any bigger than somewhere > around 1.7 gigs. Some values > of -s seemed to wrap around to a smaller number, while other values gave > errors about being too small > (when they weren't) or invalid size. The only way I could force a > journal size 2G or larger was > to make a separate partition for journal. On the server I was setting > up, I decided to make my > (journaled) data partitions da0s1d,e,f and the journals da0s2d,e,f. > > I'm just getting this out there to the list because I don't have time to > debug it further. thanks for this info I have spent some 8 hours on this today and it seems the documentation for this is somewhat lacking all information required, the server is handling large 50meg files, I have an identical server that hasnt beetouched by gjournal and even after I had setup gjournal properly so no more errors I then found the write speeds were pretty poor, with hd load very high in vmstat. My initial impressions of gjournal is complicated to setup, unstable and slow write speeds however I have not given up yet and may play with it a little more tommorow. The errors that were appearing are these. ad4: FAILURE - WRITE_DMA48 status=51 error=10 LBA=662870719 This is not hd failure but occurs when the gjournal was enabled on the initial newfs but has no actual journal location. I stopped these errors after the proper configuration but of course had that single panic. If the only advantage of journaling is to avoid slow fsck's then I may decide I can live without it, the real attraction to me was been able to use the much glamorised async which is what made me so shocked when write speeds were low. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal panic 7.0-RC1
> AFAIK this means that the journal is too small for your machine - try > doubling it until there are no more panics. > > If so, this is the same class of errors as ZFS (some would call it > "tuning errors"), only this time the space reserved for the on-disk > journal is too small, and the fast drives fill it up before data can be > transfered from the journal to the data area. > > > To double it is to do another newfs and start from scratch again or can I somehow increase the size without losing the data on the drive? Does a larger journal incease write speeds as I am finding them very poor around 60% of a sync + soft updates drive. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal panic 7.0-RC1
> If I understood this thread correctly, the impression of poor > performance is based on a configuration where both the journal and the > data are on the same physical drive. Intuitively, this will likely > penalize any transaction on the volume, read or write, since you're > asking the drive to not only accumulate a queue of information to the > journal in one region of the disk but also to flush that data in "idle > time" to a region in the data space on that same disk at a significant > seek-length away. > > I would think that journaling on one drive and storing the resultant > data-set on another would improve performance enormously (reduced > seek-lengths) and more so if they were 1) high-rpm drives (less > rotational latency) and 2) on different buses (no bus/controller > contention), > >Michael > Yes I have suspected this, there is 2 physical drives in the machine so this would be possible, if its possible to swap the journals round so they journaling for each other I will give it a go tommorow. They both sata 300 drives. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re[2]: gjournal panic 7.0-RC1
> Ok, subsystem can not work efficiently. Degrade service. Swith to > "one 512 byte sector per second" speed mode. Disable all caches, doesn't > try to work with all features. Complain 10 times/second on console (and > dmesg buffer). Ok. But PANIC?! NO-NO-NO!!! > Yes given the fact I had a panic and the work involved in configuring it properly I decided to newfs the drives again to ufs + soft updates something that is faster and just works, googling shows there seems to be very few people using gjournal so is still a bit immature for stable status in my view. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.0 Questions
On 28/02/2008, Krassimir Slavchev <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jeremy Chadwick wrote: > > On Wed, Feb 27, 2008 at 11:15:30PM -0800, Doug Hardie wrote: > >> I have just installed 7.0 on some new hardware. Have never tried earlier > >> versions. There are a couple of unexpected items that I do not understand. > >> > >> 2. I have 2 SATA drives in the system. The first is recognized as ad10 > >> and the second as ad12. I expected to see ad0 and ad1. > > > > You shouldn't "expect" this in any way shape or form. The device > > numbers are not consistent, and are known to change depending upon lots > > of reasons (AHCI disabled/enabled, another ATA controller in place, SATA > > in "compatible" mode or "enhanced" mode, etc. etc.). > > > > Thus, never expect the adX devices to "start with 0". > > > > If you want adX devices to "start with 0" just remove 'options > ATA_STATIC_ID' from the kernel config file but be very carefully if you > change hardware! > > Best Regards > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (FreeBSD) > > iD8DBQFHxpH2xJBWvpalMpkRAtpzAJsHAkMtjVIHU6dmXTZJdn3mtTWtYwCfRl7x > a9dAr6mnbnORaksfDpJMu8w= > =jiUk > -END PGP SIGNATURE- > ___ Ahh thats useful, on the occasions I have remotely installed freebsd over linux I have always failed due to incorrectly guessing the hd id and as such a wrong fstab, if I know it will always be ad0 and ad1 and so on it makes this much easier. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
> > If you replace the disk and you still continue to see DMA errors, then > my vote would be that you're experiencing the same thing others (and > myself, on one occasion) are. I've done my best to bring this issue to > the attention of proper people in recent days, and that's all I can say > on the matter. > > -- > | Jeremy Chadwickjdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > ___ Ouch, I have a server which both hds show dma errors all new hardware. I cant rule out hardware failure, incompatible sata interface etc. but if it is a freebsd bug then surely its a showstopper as stability is compromised which freebsd has built its reputation on. Did they push ahead with release because waiting for the mia dev? Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
On 28/02/2008, Mark Linimon <[EMAIL PROTECTED]> wrote: > On Thu, Feb 28, 2008 at 02:47:28PM +0000, Chris wrote: > > Did they push ahead with release because waiting for the mia dev? > > There's a lot of things that go into deciding when to release. The > release cycle this time was not supposed to be as long as it was. > We kept finding showstoppers and needing to go back and fix them > (especially for things like TCP performance and stability). > > However, sooner or later you do have to release something. There are > bugs in every software program ever released. > > It seems that in certain cases (we're not sure exactly which) the ata > subsystem has regressed. There's debate on the lists about exactly > how common this is: with bugmeister hat on, I don't think it's as > common as some folks seem to think it is (otherwise we would be overwhelmed > with bug reports). > > There's a lot of badly-written firmware out there, and a lot of workarounds > for it in the current ata stack. I'm not familiar with the code, but > fixing all this is a totally non-trivial task. > > Of course it would be nice to have several committers with sufficient > variety of boards, and time, and experience to do a lot more QA, but > we're a volunteer project and have to go with what we have in some cases. > > I'm open to suggestions about how we can get more people involved in > QAing ata. > > mcl > Well I have now 3 servers running freebsd 7 and one is showing the dma errors, a friend of mine has another 2 servers they both dont have dma errors. So the problem doesnt seem to be frequent but is a serious problem when it does occur assuming I am affected by the problem as my problem could be hardware related.. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
On 29/02/2008, Stephen Hurd <[EMAIL PROTECTED]> wrote: > > last night. It's a MiniITX board, model EN1200. My system can't remain > > up for more than 10minutes before something locks it up and frequently > > the screen will output error messages relating to DMA. > > As a workaround, adding the line: > hw.ata.ata_dma="0" > > To /boot/loader.conf will disable DMA and prevent the hangs that are caused > by the DMA timeouts. > > ___ Does that workaround work when the disks are sata? Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
linked ssl libraries to binary
I have a freebsd 6.3 server and a freebsd 7.0 server, I have a binary I run of the freebsd 7 box but has recently been crashing, the binary in question is ezbounce. It was previously running for weeks no problems at all and then during the past 2 weeks or so its had problems. Like many shell programs it has a configure script and you then run make or gmake to compile the binary. On freebsd 6 it picks up /usr/local ssl libaries no problem and in fact uses them without even haveing to specify the directory it auto detects them over the base ssl. On freebsd 7 it uses the base libraries even when telling it to search in /usr/local. So I then decided to move the binary I compiled on freebsd 6 over to the freebsd 7 box and when I ran ldd on the binary to my surprise it is using the base libraries on freebsd 7. ldd on binary on freebsd 6 libssl.so.5 => /usr/local/lib/libssl.so.5 (0x48102000) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x48143000) libcrypt.so.3 => /lib/libcrypt.so.3 (0x4829f000) libboost_iostreams.so => /usr/local/lib/libboost_iostreams.so (0x482b8000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x482c) libm.so.4 => /lib/libm.so.4 (0x48396000) libpthread.so.2 => /lib/libpthread.so.2 (0x483ac000) libc.so.6 => /lib/libc.so.6 (0x483d3000) libbz2.so.2 => /usr/lib/libbz2.so.2 (0x484cb000) libz.so.3 => /lib/libz.so.3 (0x484dc000) ldd on same binary on freebsd 7 libssl.so.5 => /usr/lib/libssl.so.5 (0x28101000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x28142000) libcrypt.so.3 => /usr/local/lib/compat/libcrypt.so.3 (0x2829a000) libboost_iostreams.so => /usr/local/lib/libboost_iostreams.so (0x282b2000) libstdc++.so.5 => /usr/local/lib/compat/libstdc++.so.5 (0x282bd000) libm.so.4 => /usr/local/lib/compat/libm.so.4 (0x28388000) libpthread.so.2 => /usr/local/lib/compat/libpthread.so.2 (0x2839e000) libc.so.6 => /usr/local/lib/compat/libc.so.6 (0x283c3000) libc.so.7 => /lib/libc.so.7 (0x284a9000) libbz2.so.3 => /usr/lib/libbz2.so.3 (0x285a4000) libz.so.4 => /lib/libz.so.4 (0x285b4000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x285c6000) libm.so.5 => /lib/libm.so.5 (0x286ba000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x286cf000) libthr.so.3 => /lib/libthr.so.3 (0x286da000) The binary doesnt run on the freebsd 7 either it coredumps even tho I have compat6x installed, typically in the past I have had no problems at all using binaries compiled on old freebsd versions on newer versions I just had to install the appropriate compat package. Here is the ldd when compiled on the freebsd 7 box libssl.so.5 => /usr/lib/libssl.so.5 (0x2810f000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x2815) libcrypt.so.4 => /lib/libcrypt.so.4 (0x282a8000) libboost_iostreams.so => /usr/local/lib/libboost_iostreams.so (0x282c1000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x282cc000) libm.so.5 => /lib/libm.so.5 (0x283c) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x283d5000) libthr.so.3 => /lib/libthr.so.3 (0x283e) libc.so.7 => /lib/libc.so.7 (0x283f3000) libbz2.so.3 => /usr/lib/libbz2.so.3 (0x284ee000) libz.so.4 => /lib/libz.so.4 (0x284fe000) Is the output for the ssl libraries skewed because both the local filenames and the base filenames are the same? as there is a /usr/local/lib/libssl.so.5 and a /usr/lib/libssl.so.5. Or does this mean that it really is linked against the base libraries as I am wondering how that is possible when the same binary is linked against different libraries on a different machine. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to handle the pack files now we have switched to git?
On 2021-01-05 03:08, Pete French wrote: So, for me the switch to git went very smoothly. I havent moved to etcupdate yet, but will probably do that soon. Hopwever I did hit one issue. What I do is to build on a single machine, and then send that to a number of places using rsync. But what seems to happen wuth git is that it has a big pack file of objects, and the name of the opack file is the SHA1 of whatever is inside it. So if something chnages then the filename chnages - and thus rsync tries to move the entire lot all over again, even if the change is tiny. Does anyone have a solution to this ? Currently I am telling rsync to ignore .git when it sends the source, but am not entirely happy with that. But apart from that, git works fine ;) Brilliant minds think alike. I use nearly the same routine. ;-) Have been doing so on svn(1) as well. FWIW the only difference between passing the archive with vs without the .git. Is that getting the details of what rev the source is at will not be available without the .git. Same on svn. For me this is only a minor inconvenience. To help overcome this in the past. I issued a 'svn info /usr/src >./SRC-REV'. Then simply passed that file along to the receiving host(s). OTOH it won't be (easily) possible to "up" the repo(s) from the receiving hosts w/o the .git. HTH --Chris -pete. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
When did pkg(8) drop support for 12-stable?
Given this is a pkg(8) error, I brought it up on ports@ but it was suggested I (also?) bring it up here on stable@ OK awhile back I installed a copy of 12 stable from the usb stick image. I tweaked it to my wishes then got called away and haven't been able to get back to it until the other day. This is still a fresh install which has a populated /usr/src. So I svnlite co svn://svn.freebsd.org/ports/head /usr/ports followed by a cd /usr/ports/ports-mgmt/pkg/ && make install clean which returns make /!\ ERROR: /!\ Ports Collection support for your FreeBSD version has ended, and no ports are guaranteed to build on this system. Please upgrade to a supported release. No support will be provided if you silence this message by defining ALLOW_UNSUPPORTED_SYSTEM. *** Error code 1 Stop. Err what? Ok while I think this was from stable 12.1, it's still still 12, and it's on stable. So what gives? Thanks in advance for any enlightenment. --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: When did pkg(8) drop support for 12-stable?
On 2021-02-23 17:07, Brian W. wrote: 12-stable is not what you're running if you got that error. # uname -apKU FreeBSD fbsd12dev 12.1-STABLE FreeBSD 12.1-STABLE r363918 GENERIC amd64 amd64 1201522 1201522 Looks pretty STABLE to me. --Chris Run freebsd-update with appropriate args to get to a later release is the easiest option. Brian On Tue, Feb 23, 2021, 5:04 PM Warner Losh wrote: On Tue, Feb 23, 2021, 4:51 PM Chris wrote: > Given this is a pkg(8) error, I brought it up on ports@ > but it was suggested I (also?) bring it up here on stable@ > > OK awhile back I installed a copy of 12 stable from the > usb stick image. I tweaked it to my wishes then got called > away and haven't been able to get back to it until the other > day. This is still a fresh install which has a populated /usr/src. > So I > svnlite co svn://svn.freebsd.org/ports/head /usr/ports > followed by a > cd /usr/ports/ports-mgmt/pkg/ && make install clean > which returns > make > /!\ ERROR: /!\ > > Ports Collection support for your FreeBSD version has ended, and no ports > are > guaranteed to build on this system. Please upgrade to a supported release. > > No support will be provided if you silence this message by defining > ALLOW_UNSUPPORTED_SYSTEM. > > *** Error code 1 > > Stop. > Err what? Ok while I think this was from stable 12.1, it's still still 12, > and it's on stable. So what gives? > 12.1 has reached EOL now that 12.2 has been out a while. Warner Thanks in advance for any enlightenment. > > --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: When did pkg(8) drop support for 12-stable?
On 2021-02-23 17:42, Mark Millard wrote: (Warner is only CC'd here.) Warner Losh imp at bsdimp.com wrote on Wed Feb 24 01:04:13 UTC 2021 : On Tue, Feb 23, 2021, 4:51 PM Chris wrote: > Given this is a pkg(8) error, I brought it up on ports@ > but it was suggested I (also?) bring it up here on stable@ > > OK awhile back I installed a copy of 12 stable from the > usb stick image. I tweaked it to my wishes then got called > away and haven't been able to get back to it until the other > day. This is still a fresh install which has a populated /usr/src. > So I > svnlite co svn://svn.freebsd.org/ports/head /usr/ports > followed by a > cd /usr/ports/ports-mgmt/pkg/ && make install clean > which returns > make > /!\ ERROR: /!\ > > Ports Collection support for your FreeBSD version has ended, and no ports > are > guaranteed to build on this syst em. Please upgrade to a supported release. > > No support will be provided if you silence this message by defining > ALLOW_UNSUPPORTED_SYSTEM. > > *** Error code 1 > > Stop. > Err what? Ok while I think this was from stable 12.1, it's still still 12, > and it's on stable. So what gives? > 12.1 has reached EOL now that 12.2 has been out a while. From release/12.1.0/ : "Tag releng/12.1@r354233 as release/12.1.0 (12.1-RELEASE)" I think that implicit in Warner's response is that versions of stable/12/ that are not after r354233 are also EOL. One needs to have stable/12/ material from after -r354233 in order for it to be supported. He might even mean that stable/12/ material from before: "Tag releng/12.2@r366954 as release/12.2.0 (12.2-RELEASE)" would also be considered as not supported. To be safe you should be using stable/12/ material from on or after -r366954 in order to have a supported context. (I'm not sure if anything is explicit about the status of stable/12/ material between releng/12.1@r354233 and releng/12.2@r366954 .) A HUGE thanks for all of this, Mark. This is EXACTLY what I needed. # uname -apKU FreeBSD fbsd12dev 12.1-STABLE FreeBSD 12.1-STABLE r363918 GENERIC amd64 amd64 1201522 1201522 which pretty well confirms what you deduced. I'm still a bit confused. It seems to me that it didn't _used_ to be that way. But my brain isn't using ECC. So a couple of bits may be flipped. Since you did not provide the output from the likes of "uname -apKU" (or some rough equivalent) I've no direct clue which version you were trying. But you should be able to compare to the above to see which range the material is from. Thanks again! --Chris === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: When did pkg(8) drop support for 12-stable?
On 2021-02-23 19:30, Mark Millard via freebsd-stable wrote: On 2021-Feb-23, at 18:08, Chris wrote: On 2021-02-23 17:42, Mark Millard wrote: (Warner is only CC'd here.) Warner Losh imp at bsdimp.com wrote on Wed Feb 24 01:04:13 UTC 2021 : On Tue, Feb 23, 2021, 4:51 PM Chris wrote: > Given this is a pkg(8) error, I brought it up on ports@ > but it was suggested I (also?) bring it up here on stable@ > > OK awhile back I installed a copy of 12 stable from the > usb stick image. I tweaked it to my wishes then got called > away and haven't been able to get back to it until the other > day. This is still a fresh install which has a populated /usr/src. > So I > svnlite co svn://svn.freebsd.org/ports/head /usr/ports > followed by a > cd /usr/ports/ports-mgmt/pkg/ && make install clean > which returns > make > /!\ ERROR: /!\ > > Ports Collection support for your FreeBSD version has ended, and no ports > are > guaranteed to build on this syst em. Please upgrade to a supported release. > > No support will be provided if you silence this message by defining > ALLOW_UNSUPPORTED_SYSTEM. > > *** Error code 1 > > Stop. > Err what? Ok while I think this was from stable 12.1, it's still still 12, > and it's on stable. So what gives? > 12.1 has reached EOL now that 12.2 has been out a while. From release/12.1.0/ : "Tag releng/12.1@r354233 as release/12.1.0 (12.1-RELEASE)" I think that implicit in Warner's response is that versions of stable/12/ that are not after r354233 are also EOL. One needs to have stable/12/ material from after -r354233 in order for it to be supported. He might even mean that stable/12/ material from before: "Tag releng/12.2@r366954 as release/12.2.0 (12.2-RELEASE)" would also be considered as not supported. To be safe you should be using stable/12/ material from on or after -r366954 in order to have a supported context. (I'm not sure if anything is explicit about the status of stable/12/ material between releng/12.1@r354233 and releng/12.2@r366954 .) A HUGE thanks for all of this, Mark. This is EXACTLY what I needed. # uname -apKU FreeBSD fbsd12dev 12.1-STABLE FreeBSD 12.1-STABLE r363918 GENERIC amd64 amd64 1201522 1201522 which pretty well confirms what you deduced. I'm still a bit confused. It seems to me that it didn't _used_ to be that way. But my brain isn't using ECC. So a couple of bits may be flipped. The implication of all of stable/12/ being supported would be support of stable/12/ from on or after its creation: QUOTE Revision 339434 - Directory Listing Modified Fri Oct 19 00:09:24 2018 UTC (2 years, 4 months ago) by gjb Copied from: head revision 339432 Copy head@r339432 to stable/12 as part of the 12.0-RELEASE cycle. Additional post-branch commits will follow. END QUOTE Such does not seem likely to me. What would be the point of dropping 12.0-RELEASE support and 12.1-RELEASE support if such stable/12/ history was covered, some of that history being minor variations on the 12.0-RELEASE or 12.1-RELEASE ? Note: Despite some claims in other messages, svn -r363918 is not 12.1-RELEASE ( not -r354233 ) and -r363918 is shown as (only) in stable/12/ by svn. Your claim of 12-STABLE was correct, just not detailed enough. Thanks. I really appreciate your taking the time to clear things up for me. It also seems clear that I've somehow mixed the purpose of RELEASE vs STABLE. :-/ Thanks again, Mark! --Chris === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Vinum deprecation for FreeBSD 14 - are there any remaining Vinum users?
On 2021-03-25 10:25, Ed Maste wrote: Vinum is a Logical Volume Manager that was introduced in FreeBSD 3.0, and for FreeBSD 5 was ported to geom(4) as gvinum. gvinum has had no specific development at least as far back as 2010 and it is not clear how well it works today. There are open PRs with reports of panics upon removing disks, etc. And, it also imposes an ongoing cost as it must be updated when other work is done (such as the recent MAXPHYS work). I suspect that by now all users have migrated to either graid(8) or ZFS. I plan to add a deprecation notice after a short discussion period, assuming no reasonable justification is made to retain it. The notice would suggest graid and ZFS as alternatives, and would be merged in advance of FreeBSD 13.1. Then, gvinum would be removed in advance of FreeBSD 14.0. Please follow up if you have experience or input on vinum in FreeBSD, including past use but especially if you are still using it today and expect to continue doing so. I can only state that I use it only occasionally, and that when I do. I have had no problems with it. I'm glad that it's there when I need it. Further; I find it easier to setup and use, as compared to the alternatives. It is also "lighter" than the alternatives. While it wouldn't be "the end of the world" if it disappeared. I'm really glad it's there. --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Vinum deprecation for FreeBSD 14 - are there any remaining Vinum users?
On 2021-03-26 07:22, Ed Maste wrote: On Thu, 25 Mar 2021 at 15:09, Chris wrote: I can only state that I use it only occasionally, and that when I do. I have had no problems with it. I'm glad that it's there when I need it. Thanks for the reply. Can you comment on your use cases - in particular, did you use mirror, stripe, or raid5? If the first two then gmirror, gconcat, gstripe, and/or graid are suitable replacements. Thank you for the reply. :-) Sure. My only needs have been for: gstripe gmirror or gconcat. I'm not looking to deprecate it just because it's old, but because of a mismatch between user and developer expectations about its stability. Sure. I understand. Thanks for mentioning it. --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
On 2021-04-03 13:45, Warner Losh wrote: On Sat, Apr 3, 2021 at 2:40 PM Ed Maste wrote: I propose deprecating the ftpd currently included in the base system before FreeBSD 14, and opened review D26447 (https://reviews.freebsd.org/D26447) to add a notice to the man page. I had originally planned to try to do this before 13.0, but it dropped off my list. FTP is not nearly as relevant now as it once was, and it had a security vulnerability that secteam had to address. I *strongly* object. MacOS also did this. Which made me discover that I could simply copy my already built FreeBSD version over to all my MacOS laptops and now enjoy an even better version than had previously existed. This fact has made my use and need for FreeBSD' ftp even more important. It has also made FreeBSD more popular with the Mac folks. I depend upon ftp(1) && ftpd(8). I have on FreeBSD, for as many years as FreeBSD has existed. I find the ssh and related ports are probed and hammered on constantly. Whereas the ftp ports are quite rare by comparison. So keeping sshd(8) and friends ports closed removes overhead. I have no difficulty managing ftpd(8) via inet(8) && hosts.allow(5). Ftp && ftpd are both trivial programs and should not be considered for removal. If the reason for their suggested removal is "development overhead". Please allow me to maintain both. I will happily assume full responsibility for them. Thank you for listening. :-) --Chris I'm happy to make a port for it if anyone needs it. Comments? I already use one of the ports ftpd's for my needs, so this is fine by me. I'm agnostic about whether we need a port for what was in base, but suspect that's likely the path of least resistance. Warner ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
On 2021-04-04 12:10, Ian Lepore wrote: On Sat, 2021-04-03 at 16:39 -0400, Ed Maste wrote: I propose deprecating the ftpd currently included in the base system before FreeBSD 14, and opened review D26447 (https://reviews.freebsd.org/D26447) to add a notice to the man page. I had originally planned to try to do this before 13.0, but it dropped off my list. FTP is not nearly as relevant now as it once was, and it had a security vulnerability that secteam had to address. I'm happy to make a port for it if anyone needs it. Comments? I would find the removal of ftpd to be very inconvenient unless there was a port/pkg to install it from. If there is a port, it would only be useful if I could set PREFIX=/usr when building/installing it, so that its behavior when installed as a port/pkg would be identical to how it was when it was part of base (in terms of where its config files are located). I like the sound of that. Except that I'd like to do it one better and suggest something along the lines of PORTS_MODULES in make.conf(5). Maybe PORTS_DAEMONS= ftpd sshd rpcbind nfsd ypbind inetd etc... That might make it a tenable for situation for everyone. ;-) --Chris -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
On 2021-04-05 07:44, Cy Schubert wrote: In message , Ed Maste writes: I propose deprecating the ftpd currently included in the base system before FreeBSD 14, and opened review D26447 (https://reviews.freebsd.org/D26447) to add a notice to the man page. I had originally planned to try to do this before 13.0, but it dropped off my list. FTP is not nearly as relevant now as it once was, and it had a security vulnerability that secteam had to address. I think this is an excellent start. My shopping list includes: - remove ftp(1) - remove ftpd(8) - remove telnet(1) - remove telnetd(8) - remove ftp:// and http:// from libfetch. This is 2021 and we should all use https://. - replace DNS lookups with DoH and/or DoT. Why let your ISP see your DNS traffic? You've clearly never worked on extremely large networks. Or at least not considered them in this statement -- think LAN/intranet in large corporate settings. ftp(1) as well as ftpd(8) are lightweight, and utilitarian. It's because of this that gives them such great value. They require nothing to use. They just work with no setup required. With very little setup you can manage something a little more sophisticated. I can easily script ftp for complex situations needing nothing more than sh(1) and ftp(1), and it's all available right-out-of-the-box. This isn't true of the others. In an internet public facing scenario. It's enough to utilize one specific line in inetd(8) and 2 in hosts.allow(2). This simplicity and lack of overhead is not available with the other options. Because something is old and un-featured does not make it valueless. I'm happy to make a port for it if anyone needs it. Comments? A port would be a nice option. But it should remain an option; as in one _should_ be allowed to get ftp || ftpd out of the box if they so choose. I've started working on splitting ftp and ftpd into an external git repo. The problem I've encountered is that though only ftp and ftpd are left the resultant repo is still 1.2 GB. If my last attempt fails, there is a choice between a 1.2 GB repo and burning ftp forever then the choice is clear: burn it forever. Adding the following as an option: Also note that the tnftp ports are the NetBSD ftp and ftpd. The FreeBSD ftp and ftpd are simply copies of tnftp and tnfpd. Would it make more sense to share our customizations with NetBSD and we simply reply on NetBSD for the client and server in our ports? This last option might be simpler than creating a port. Personally, I'd suggest we remove the ftpd server *AND* ftp client and rely on ports. Having worked on UNIX, Internet security, and firewalls over the last 3/5 of my almost 50 year career, I have lamented the existence of the FTP protocol back in 1995 and I hate the FTP protocol with greater a passion today. Let's simply remove all vestiges of FTP from the base system, including libfetch, sooner than later. We don't need it now that we have HTTPS and POST; and sftp. This assumes your willing to expend all the time and overhead to setup a web server for a simple but absolutely mandatory one time task. When none of the boxes you're working on are slated for or perhaps are even capable of running as much. I (or anyone) should be able to have a FULLY functional system WITHOUT the need to get additional sources to build additional functionality -- this ain't Linux. I think we should make it our goal to remove any and all unencrypted protocols from FreeBSD by 2025. Not everyone works exclusively "in the wild". Many also work within safe environments, where such things, while nice, are unnecessary. --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
On 2021-04-05 11:27, Roger Leigh wrote: On 3 Apr 2021, at 22:21, Eugene Grosbein wrote: 04.04.2021 3:39, Ed Maste wrote: I propose deprecating the ftpd currently included in the base system before FreeBSD 14, and opened review D26447 (https://reviews.freebsd.org/D26447) to add a notice to the man page. I had originally planned to try to do this before 13.0, but it dropped off my list. FTP is not nearly as relevant now as it once was, and it had a security vulnerability that secteam had to address. I'm happy to make a port for it if anyone needs it. Comments? I'm strongly against remove of stock ftpd. FTP is fastest protocol for both testing and daily file transfer for trusted isolated segments, and even for WAN wrapped in IPSec. Our stock ftpd has very short backlog of security issues comparing with other FTP server implementations, mostly linked with libc or other libraries and not with ftpd code itself. Please don't fix what ain't broken. Please. How would you draw the line between something that must be part of the base system vs. something that would be better off as part of the ports tree? What bar should ftpd have to meet to warrant remaining in base vs moving to ports? Personally, I’ve never enabled it nor had any desire to. FTP is, at this point in time, thoroughly obsolescent, and I cannot imagine that it is something that most people enable, if they are even aware of its existence. Why can’t it simply be installed from the ports for the occasional user who still requires it? Why should the base system contain obsolete stuff that few people will use? Surely the ports tree serves this need better? Can I ask, for those who do enable it, why isn’t “sftp” acceptable (or “scp”)? Sure. Because it's part of a one-time task. It might be part of a server setup. Or might a task that must be done on thousands of machines. It needs to be available out-of-the-box, and needs no overhead for setup (key exchange, config, etc...). This scenario may also be on machines w/o any external sources/packages. IOW everything should be available out of the box, with little to no additional setup overhead. ftp(1), and ftpd(8) provide everything required at no additional cost. :-) Both provide a similar function, securely, which also works with a basic installation without any ports. SSHFXP, the protocol underlying sftp is better specified, less ambiguous and more fault tolerant and safe than the FTP protocol ever was. The client is better than most ftp clients, and the server (/usr/libexec/sftp-server) is started on demand on a per-connection basis. What makes FTP more desirable than a service over SSH which is (from a technical and usability point of view) a better FTP than FTP ever was? Kind regards, Roger --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
On 2021-04-05 12:01, Patrick M. Hausen wrote: Hi all, Am 03.04.2021 um 22:39 schrieb Ed Maste : I'm happy to make a port for it if anyone needs it. Comments? A bit late to the party, but my take is: please just don't. I absolutely freaked out when Apple removed the telnet and ftp clients from Mac OS and I needed to reinstall them via MacPorts. That route uses an inferior (opinion) version of ftp(1) && ftpd(8). It might interest you to know that the FreeBSD versions that (currently) already come with FreeBSD can be copied over to your Mac. I *too* became upset when I found MacOS w/o these, and on a hunch tried it, and worked as intended/expected. The FreeBSD version(s) are more "featurefull" than those that originally came on the Mac, or the GNU one that is supplied w/MacPorts. People who manage any larger collection of networking gear *depend* on these outdated but simple services. Client and server side alike. TFTP is not going away, neither is FTP. I'm dead serious. Remote media via Supermicro IPMI in 2021? SMB1. Firmware updates for my UPS? FTP. Scanner/printer/fax all-in-one thingy? Uploads received fax transmissions via FTP. PBX? Uploads usage reports via FTP. This stuff is here to stay. In local networks, of course. But still even on "the Internet", FTP is the most used method for customers of static website hosting. You cannot teach these people what an SSH key is. Just my experience, but backed by a load of customer interactions over more than 20 years ... Kind regards, Patrick -- punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de i...@punkt.de AG Mannheim 108285 Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
On 2021-04-05 13:43, Ed Maste wrote: On Sat, 3 Apr 2021 at 16:39, Ed Maste wrote: I propose deprecating the ftpd currently included in the base system before FreeBSD 14, and opened review D26447 (https://reviews.freebsd.org/D26447) to add a notice to the man page. I posted this as a proposal for community feedback, and there's clearly a strong objection to removing the base system ftpd. So, I'm not going to pursue this any further. I like to take the time to extend a massive _Thank You_ for your chosen course for handling this. I'm also grateful for it's outcome. :-) Thanks! --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
On 2021-04-07 23:27, aventa...@fastmail.fm wrote: I think folks have different definitions of what an operating system should be. Agreed. An Operating System (OS) is an interface between a computer user and computer hardware. An operating system is a software which performs all the basic tasks like file management, memory management, process management, handling input and output, and controlling peripheral devices such as disk drives and printers. If you add or take away from the above definition, then there is your misunderstanding. IMHO many refer to Linux as an Operating System. When in fact it is a Kernel. Which is also what you describe above. OTOH, UNIX as an OS has a defined set of commands available, as well as servers to facilitate running a fully installed server. Which is what I believe he was referring to. At this point I think this thread is becoming tiresome. ;-) --Chris Best Regards, Vic Thacker On Wed, Apr 7, 2021, at 21:17, tech-lists wrote: Hi, I'm a bit late to the discussion On Mon, Apr 05, 2021 at 07:44:59AM -0700, Cy Schubert wrote: >I think this is an excellent start. My shopping list includes: > >- remove ftp(1) >- remove ftpd(8) >- remove telnet(1) >- remove telnetd(8) >- remove ftp:// and http:// from libfetch. This is 2021 and we should all >use https://. >- replace DNS lookups with DoH and/or DoT. Why let your ISP see your DNS >traffic? Very firmly against this, and this sort of thing, for the following reasons: 1. I want an OS, not a kernel. If I just want a kernel, then why not go with linux? FreeBSD is meant to be, I think, (generally), a server OS. So, would you agree that it needs the ability to have server protocols easily configured, with a minimum of fuss, without packages? 2. a lot of infrastructure depends on ftpd. it's easy to configure securely ftpd in base. 3. there are some networks, like internal ones, where encryption is not a requirement, or appropriate. 4. there are some places where encryption is in fact illegal. >Personally, I'd suggest we remove the ftpd server *AND* ftp client and rely >on ports. Having worked on UNIX, Internet security, and firewalls over the >last 3/5 of my almost 50 year career, I have lamented the existence of the >FTP protocol back in 1995 and I hate the FTP protocol with greater a >passion today. Let's simply remove all vestiges of FTP from the base >system, including libfetch, sooner than later. We don't need it now that we >have HTTPS and POST; and sftp. 5. some services commonly don't use https. Lots of internet radio stations don't. If https is enforced then the user will have to jump through more hoops than they already do in order to, in this case, listen to internet radio. Or face a loss of functionality. 6. not everywhere will have constant internet access. Not everyone will want to use pkgs or have space for the ports tree. >I think we should make it our goal to remove any and all unencrypted >protocols from FreeBSD by 2025. I think you should carefully think of the consequences of removing functionality in the default install. It will make it less useful, not more. -- J. Attachments: * signature.asc ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: using interface groups in pf tables stopped working in 13.0-RELEASE
On 2021-04-14 07:16, Peter Ankerstål wrote:
In pf I use the interface group syntax alot to make the configuration more
readable. All interfaces are assigned to a group representing its use/vlan
name.
For example:
ifconfig_igb1_102="172.22.0.1/24 group iot description 'iot vlan' up"
ifconfig_igb1_102_ipv6="inet6 2001:470:de59:22::1/64"
ifconfig_igb1_300="172.26.0.1/24 group mgmt description 'mgmt vlan’ up"
ifconfig_igb1_300_ipv6="inet6 2001:470:de59:26::1/64”
in pf.conf I use these group names all over the place. But since I upgraded
to
13.0-RELEASE it no longer works to define a table using the :network syntax
and
interface groups:
tableconst { trusted:network mgmt:network dmz:network
guest:network edmz:network \
admin:network iot:network client:network }
If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded
Some changes in the pf source have been made over the last couple
of months. The error returned appears to be related. It appears
that your running into a table size/count and memory allocation
related error. The first change moved/changed memory allocation to
kernel space, requiring one to increase allocation via loader.conf(5).
It was recently moved back to userspace allowing one to make changes
to a running system via sysctl.conf(5) or the commandline.
IOW if your on the recent change you should be able to simply
increase your table count by executing something like:
# echo "set limit table-entries " | pfctl -m -f -
OTOH if your stuck with the change in kernelspace, increase
net.pf.request_maxcount=
by some amount in loader.conf(5). If you are on the newer userspace
change, you can issue the sysctl(8) command at your terminal for
net.pf.request_maxcount=
as well.
HTH
--Chris
I have tried to use just one network, double check the interface group
setting and
so on, but with no luck.
to use actual interface works just fine:
table{ igb1.300:network }
but using the group fails:
# ifconfig -g mgmt
igb1.300
table{ mgmt:network }
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded
Any ideas?
Thanks!
/Peter.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: using interface groups in pf tables stopped working in 13.0-RELEASE
On 2021-04-14 10:44, Peter Ankerstål wrote:
const { trusted:network mgmt:network dmz:network
guest:network edmz:network \
admin:network iot:network client:network }
If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded
Some changes in the pf source have been made over the last couple
of months. The error returned appears to be related. It appears
that your running into a table size/count and memory allocation
related error. The first change moved/changed memory allocation to
kernel space, requiring one to increase allocation via loader.conf(5).
It was recently moved back to userspace allowing one to make changes
to a running system via sysctl.conf(5) or the commandline.
IOW if your on the recent change you should be able to simply
increase your table count by executing something like:
# echo "set limit table-entries " | pfctl -m -f -
OTOH if your stuck with the change in kernelspace, increase
net.pf.request_maxcount=
by some amount in loader.conf(5). If you are on the newer userspace
change, you can issue the sysctl(8) command at your terminal for
net.pf.request_maxcount=
as well.
I dont think so. Everything works normally if I switch from group name to
interface name
in the config.
Sure. I only mentioned it because 1) the error you received looked almost
exactly
the same as the one I encountered after the (pf source) changes, 2) alot of
work
has been done recently (as I mentioned above). :-)
I'll defer to kp@ (Kristof Provost) for more insightful possibilities. As
he's done
most all the recent work. :-)
--Chris
It seems to me that pf for some reason changed how it interprets group names
differently from
12.2-RELEASE-p4 and 13.0-RELEASE.
I dont really get how "anchor in from trusted:network” can resolve to
"anchor in inet6 all”
/Peter.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: using interface groups in pf tables stopped working in 13.0-RELEASE
On 2021-04-14 11:04, Chris wrote:
On 2021-04-14 10:44, Peter Ankerstål wrote:
const { trusted:network mgmt:network dmz:network
guest:network edmz:network \
admin:network iot:network client:network }
If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded
Some changes in the pf source have been made over the last couple
of months. The error returned appears to be related. It appears
that your running into a table size/count and memory allocation
related error. The first change moved/changed memory allocation to
kernel space, requiring one to increase allocation via loader.conf(5).
It was recently moved back to userspace allowing one to make changes
to a running system via sysctl.conf(5) or the commandline.
IOW if your on the recent change you should be able to simply
increase your table count by executing something like:
# echo "set limit table-entries " | pfctl -m -f -
OTOH if your stuck with the change in kernelspace, increase
net.pf.request_maxcount=
by some amount in loader.conf(5). If you are on the newer userspace
change, you can issue the sysctl(8) command at your terminal for
net.pf.request_maxcount=
as well.
I dont think so. Everything works normally if I switch from group name to
interface name
in the config.
Sure. I only mentioned it because 1) the error you received looked almost
exactly
the same as the one I encountered after the (pf source) changes, 2) alot of
work
has been done recently (as I mentioned above). :-)
I'll defer to kp@ (Kristof Provost) for more insightful possibilities. As
he's done
most all the recent work. :-)
--Chris
CC'ing pf@ for better coverage of your problem.
It seems to me that pf for some reason changed how it interprets group
names
differently from
12.2-RELEASE-p4 and 13.0-RELEASE.
I dont really get how "anchor in from trusted:network” can resolve to
"anchor in inet6 all”
/Peter.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
On 2021-04-14 19:28, Andy Farkas wrote: I think this is an excellent start. My shopping list includes: - remove ftp(1) - remove ftpd(8) - remove telnet(1) - remove telnetd(8) - remove ftp:// and http:// from libfetch. This is 2021 and we should all use https://. - replace DNS lookups with DoH and/or DoT. Why let your ISP see your DNS traffic? I wonder how many people use YP/NIS (man 8 yp)? It's a nifty concept; I played around with it last century... I believe there is still an open PR in bugzilla I created (can't find it right now, used a diffent email address back then, although same username). LOL I did the same a year or so ago. I felt much the same as you describe. But I've since discovered it can be leveraged in ways that it did not originally intend to do. So I've since decided that given in whole it's small footprint, along with a proven track record. It has value enough that it ought to remain. Removing it from base (if it should be done at all) looks very complicated and therefore creating a port equally so. I know this topic (removing ftpd) is closed, so perhaps this should be a new one (removing YP/NIS)? ie. no development on yp has been done for over a decade. My view: remove neither I concur. :-) -andyf --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
clean update 12.2 > 13.0
Wow.. Best update I have done in years. At least for me 12.2 > 13.0 was great. Great job ! ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
clean update 12.2 > 13.0
Wow.. Best update I have done in years. At least for me 12.2 > 13.0 was great. Great job ! ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: clocked speed not showing in dev.cpu.[0-7].freq
On 2021-04-27 11:28, Ian Lepore wrote: On Tue, 2021-04-27 at 19:22 +0100, tech-lists wrote: Hi, Not sure where to put this. system is amd64/stable/13. It's running powerd but with no additional flags. CPU is Intel(R) Core(TM) i7-4770K CPU. Has 32GB RAM The system is clocked in the bios at 4.251 GHz. I never see this value in sysctl dev.cpu.[0-7].freq though. Here's the output: [...] sysctl dev.cpu.0 dev.cpu.0.cx_method: C1/hlt dev.cpu.0.cx_usage_counters: 100878534 dev.cpu.0.cx_usage: 100.00% last 185us dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1/0 dev.cpu.0.freq_levels: 3400/84000 3200/77169 3100/73848 2900/67388 2700/61182 2500/55201 2400/52298 2200/46677 2000/41272 1800/36091 1700/34277 1500/29407 1300/24752 1100/20312 1000/18167 800/14031 dev.cpu.0.freq: 3400 dev.cpu.0.temperature: 68.0C dev.cpu.0.coretemp.throttle_log: 0 dev.cpu.0.coretemp.tjmax: 100.0C dev.cpu.0.coretemp.resolution: 1 dev.cpu.0.coretemp.delta: 32 dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 _CID=none dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU Here's the cpu string on boot: CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (4251.32-MHz K8-class CPU) So, is it really clocked? or does the sysctl show what is right? thanks, The same is true on my system: CPU: Intel(R) Xeon(R) CPU W3680 @ 3.33GHz (4250.09-MHz K8-class CPU) dev.cpu.0.freq_levels: 3334/143000 /13 3200/117000 3067/105000 2933/94000 2800/85000 2667/76000 2533/68000 2400/61000 2267/54000 2133/48000 2000/43000 1867/39000 1733/35000 1600/32000 I've clocked this cpu at various speeds between 4.25 - 5.0 ghz over the years (faster when it was younger, more conservative now that it's old). The value in parens (4250.09) changes accordingly, but the values in the sysctl never do. I'm sure this is running at the overclocked speed (various benchmark values change as they should when changing the OC values in the bios). FWIW on all my AMD CPUs that top out @4.25-4.50Ghz FreeBSD reports 3.8Ghz. I get the idea the FreeBSD returns the average (running) top speed on CPU0 --Chris -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How to make 'named' rc script invokded earlier at boot time
On 2021-04-30 00:30, Yasuhiro Kimura wrote: I installed dns/bind916 on my home server and configured it so it worked as both authoritative and recursor. Then I added 'nameserver 127.0.0.1' to /etc/resolv.conf and everything worked fine. But after updating OS from 12.2-RELEASE to 13.0-RELEASE I noticed execution of some rc scripts fails at boot time because of DNS lookup error. And I also found these scripts are executed earlier than 'named'. I've been plagued with this for years (well, a couple anyways) on several of my servers. As I never saw anyone else mention it. I assumed it was just "me". ;-) rc(8) has a mountlate. Seems to me there ought to be a "startlate" key as well. While this won't fix the cause introduced. It might at least solve the problem. create an /etc/rc.conf.local and move your host/nic related things into it followed by your "named" entry. Leaving everything else in /etc/rc.conf This (should) source all the rc.conf.local entries ahead of the rc.conf entries. Thereby providing name resolution before ntpdate(8)/time sync service(s) HTH --Chris Now let me use 'ntpdate' as an example. If I run `rcorder /etc/rc.d/* /usr/local/etc/rc.d/*` on 12.2-RELEASE, then I get following result. -- root@rolling-vm-freebsd3[474]# uname -a FreeBSD rolling-vm-freebsd3.home.utahime.org 12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 GENERIC amd64 root@rolling-vm-freebsd3[475]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* /etc/rc.d/growfs /etc/rc.d/sysctl /etc/rc.d/hostid /etc/rc.d/zvol /etc/rc.d/dumpon (snip) /etc/rc.d/static_arp /etc/rc.d/bridge /etc/rc.d/route6d /etc/rc.d/NETWORKING /etc/rc.d/mountcritremote /etc/rc.d/devfs /etc/rc.d/ipmon /etc/rc.d/kdc /etc/rc.d/mdconfig2 /etc/rc.d/newsyslog /etc/rc.d/syslogd /usr/local/etc/rc.d/tcsd /usr/local/etc/rc.d/named /etc/rc.d/watchdogd /etc/rc.d/savecore /etc/rc.d/archdep /etc/rc.d/linux /etc/rc.d/sysvipc /etc/rc.d/SERVERS /usr/local/etc/rc.d/tpmd /usr/local/etc/rc.d/stunnel /etc/rc.d/accounting /etc/rc.d/ntpdate /etc/rc.d/rpcbind /etc/rc.d/nfsclient /etc/rc.d/nisdomain (snip) -- As you can see, while 'named' is executed before SERVERS, 'ntpdate' is done after it. On the other hand I get following result on 13.0-RELEASE. -- root@rolling-vm-freebsd2[332]# uname -a FreeBSD rolling-vm-freebsd2.home.utahime.org 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri Apr 9 04:24:09 UTC 2021 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 root@rolling-vm-freebsd2[333]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* /etc/rc.d/dhclient /etc/rc.d/dumpon /etc/rc.d/growfs /etc/rc.d/natd (snip) /etc/rc.d/netwait /etc/rc.d/blacklistd /etc/rc.d/local_unbound /etc/rc.d/NETWORKING /etc/rc.d/pppoed /etc/rc.d/kdc /etc/rc.d/kfd /etc/rc.d/nfsuserd /etc/rc.d/iscsid /etc/rc.d/ipropd_slave /etc/rc.d/nfscbd /etc/rc.d/iscsictl /etc/rc.d/ipropd_master /etc/rc.d/kadmind /etc/rc.d/kpasswdd /etc/rc.d/mountcritremote /etc/rc.d/wpa_supplicant /etc/rc.d/motd /etc/rc.d/accounting /etc/rc.d/cleartmp /etc/rc.d/dmesg /etc/rc.d/archdep /etc/rc.d/gptboot /etc/rc.d/hostapd /etc/rc.d/virecover /etc/rc.d/mdconfig2 /etc/rc.d/devfs /etc/rc.d/os-release /etc/rc.d/newsyslog /etc/rc.d/linux /etc/rc.d/syslogd /etc/rc.d/sysvipc /etc/rc.d/watchdogd /etc/rc.d/savecore /etc/rc.d/ntpdate /etc/rc.d/localpkg /etc/rc.d/auditd /etc/rc.d/bsnmpd /etc/rc.d/pwcheck /etc/rc.d/power_profile /etc/rc.d/rpcbind /etc/rc.d/auditdistd /usr/local/etc/rc.d/named /etc/rc.d/nfsclient /etc/rc.d/hastd /etc/rc.d/SERVERS /etc/rc.d/nisdomain /usr/local/etc/rc.d/stunnel /usr/local/etc/rc.d/tpmd /usr/local/etc/rc.d/tcsd (snip) -- Now both 'named' and 'ntpdate' are executed before SERVERS. And unfortunately the latter is earlier than the former. So it is natural that execution of 'ntpdate' fails with DNS lookup failure. I compared ntpdate rc script between releng/12.2 and releng/13.0 but there is no difference. -- yasu@rolling-vm-freebsd2[1035]% pwd /usr/src yasu@rolling-vm-freebsd2[1036]% git diff origin/releng/12.2 origin/releng/13.0 -- libexec/rc/rc.d/ntpdate yasu@rolling-vm-freebsd2[1037]% -- And of cource there is no difference with /usr/local/etc/rc.d/named either. So it seems evaluation of rcorder(8) is changed between 12.2-RELASE and 13.0-RELEASE. Then is there any way to make 'named' rc script invoked earlier at boot time on 13.0-RELEASE? Best Regards. --- Yasuhiro Kimura ___ freebsd-po...@freebsd.
Re: ZFS...
Your story is so unusual I am wondering if its not fiction, I mean all sorts of power cuts where it just so happens the UPS fails every time, then you decide to ship a server halfway round the world, and on top of that you get a way above average rate of hard drive failures. But aside from all this you managed to recover multiple times. ZFS is never claimed to be a get out of jail free card, but it did survive in your case multiple times, I suggest tho if you value redundancy, do not use RAIDZ but use Mirror instead. I dont know why people keep persisting with raid 5/6 now days with drives as large as they are. I have used ZFS since the days of FreeBSD 8.x and its resilience compared to the likes of ext is astounding and especially compared to UFS. Before marking it down think how would UFS or ext have managed the scenarios you presented in your blog. Also think about where you hosting your data with all your power failures and the UPS equipment you utilise as well. On Mon, 29 Apr 2019 at 16:26, Michelle Sullivan wrote: > > I know I'm not going to be popular for this, but I'll just drop it here > anyhow. > > http://www.michellesullivan.org/blog/1726 > > Perhaps one should reconsider either: > > 1. Looking at tools that may be able to recover corrupt ZFS metadata, or > 2. Defaulting to non ZFS filesystems on install. > > -- > Michelle Sullivan > http://www.mhix.org/ > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS...
Sorry t clarify, Michelle I do believe your tail of events, just I meant that it reads like a tale as its so unusual. I also agree that there probably at this point of time should be more zfs tools written for the few situations that do happen when things get broken. Although I still standby my opinion I consider ZFS a huge amount more robust than UFS, UFS always felt like I only had to sneeze the wrong way and I would get issues. There was even one occasion simply installing the OS on its defaults, gave me corrupted data on UFS (9.0 release had nasty UFS journalling bug which corrupted data without any power cuts etc.). In future I suggest you use mirror if the data matters. I know it costs more in capacity for redundancy but in todays era of large drives its the only real sensible option. On the drive failures you have clearly been quite unlucky, and the other stuff is unusual. Best of luck On Sat, 4 May 2019 at 09:54, Pete French wrote: > > > > On 04/05/2019 01:05, Michelle Sullivan wrote: > > New batteries are only $19 on eBay for most battery types... > > Indeed, my problem is actual physical access to the machine, which I > havent seen in ten years :-) I even have a relacement server sitting > behind my desk which we never quite got around to installing. I think > the next move it makes will be to the cloud though, so am not too worried. > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
P5 bork
I am not a sophsicated user.. Im running FreeBSD 12 and Unbound at home doing DoT TLS1.3 Thats all I do on the machine. Its a very clean boring typical install. X86. FreeBSD-update fetch freebsd-update install reboot BORKED. Just loops duing boot. Backed up to kernal.old - works perfect.. If anyone cares I could go grab logs and things, but, I would assume this is already known and I will just wait for P6, hehehe.. Sorry im not deeper on the subject. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: P5 bork
Thank you Pete :) On 5/15/2019 10:58 PM, Pete Wright wrote: On 5/15/19 10:15 PM, Chris wrote: I am not a sophsicated user.. Im running FreeBSD 12 and Unbound at home doing DoT TLS1.3 Thats all I do on the machine. Its a very clean boring typical install. X86. FreeBSD-update fetch freebsd-update install reboot BORKED. Just loops duing boot. Backed up to kernal.old - works perfect.. If anyone cares I could go grab logs and things, but, I would assume this is already known and I will just wait for P6, hehehe.. Sorry im not deeper on the subject. should be fixed now: https://www.freebsd.org/security/advisories/FreeBSD-SA-19:07.mds.asc "v2.0 2019-05-15 Rerelease 12.0-RELEASE patch as -p5 due to i386 panic bug." -pete ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: P5 bork
hahaha.. So I gotta patch the patch with a patch if its patched already. :) On 5/15/2019 11:56 PM, Chris wrote: Thank you Pete :) On 5/15/2019 10:58 PM, Pete Wright wrote: On 5/15/19 10:15 PM, Chris wrote: I am not a sophsicated user.. Im running FreeBSD 12 and Unbound at home doing DoT TLS1.3 Thats all I do on the machine. Its a very clean boring typical install. X86. FreeBSD-update fetch freebsd-update install reboot BORKED. Just loops duing boot. Backed up to kernal.old - works perfect.. If anyone cares I could go grab logs and things, but, I would assume this is already known and I will just wait for P6, hehehe.. Sorry im not deeper on the subject. should be fixed now: https://www.freebsd.org/security/advisories/FreeBSD-SA-19:07.mds.asc "v2.0 2019-05-15 Rerelease 12.0-RELEASE patch as -p5 due to i386 panic bug." -pete ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UEFI ISO boot not working in 12.1 ?
On Wed, 6 Nov 2019 14:17:11 -0500 Chris Ross cross+free...@distal.com said Hi there. I tried booting FreeBSD-12.1-RELEASE-amd64-disc1.iso on a system here, which didn't work, and I found that FreeBSD-12.0-RELEASE-amd64-disc1.iso did work on that same system. Another [older] system I had was working with FreeBSD-12.1-RELEASE-amd64-disc1.iso, but after I had reason to change that older system to UEFI boot mode, I found it also would not boot the 12.1 ISO any longer A successul UEFI boot of 12.0-RELEASE-amd64-disc1 shows many lines of EFI information to the console, and nearing the bottom: BootOrder: 0001 0002 0003 0004[*] BootInfo Path: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x3)/CDROM(0x1) BootInfo Path: VenHw(,) Ignoring Boot0004: No Media Path Trying ESP: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x3) Setting currdev to cd3: - And, that last line is a spinning cursor, after which becomes: Loading /boot/defaults/loader.conf And continues on from there. However, the attempt to boot 12.1-RELEASE never loads the loader and allows it to boot. The console output for 12.1-RELEASE is below. Can anyone help me figure out if it's something I need to do? How has 12.1 changed w.r.t. 12.0 for UEFI? The 12.1-RELEASE shows the same as above until starting with "Trying ESP": Trying ESP: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x3)/CDROM(0x1) Setting currdev to cd4: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x1) Setting currdev to cd0: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x2) Setting currdev to cd1: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x3) Setting currdev to cd2: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x3)/CDROM(0x0) Setting currdev to cd3: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x4) Setting currdev to cd5: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x5) Setting currdev to cd6: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x6) Setting currdev to cd7: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x7) Setting currdev to cd8: Failed to bind bootable partition press any key to interrupt reboot in 5 seconds Let me know why 12.1-RELEASE is not behaving the same way on my systems... Thank you. - Chris Not trying to hijack this thread, But on a similar note; Wile I'm able to boot/install from them. None of the October (12.1) install images will produce a bootable install. So I'm stuck on RELENG-12. This is on a Core 13 second gen. IOW my problem is the inverse of yours. --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Running FreeBSD on M.2 SSD
On Fri, 28 Feb 2020 21:44:45 -0300 Mario Olofo mario.ol...@gmail.com said Hello guys, a little update that let me more confused I reinstalled the FreeBSD with 4k pages using the sysctl vfs.zfs.min_auto_ashift = 12 and no errors after a lot of stress I put on it. One thing that I noticed is that with the pool as 4k, the disk fill up very fast, recompiling the kernel used my 8GB space and didn't even completed. But now I don't know if the 4k is the correct answer or if this just delays the problem as the pages are bigger. The TLDR of 4k vs 512 largely has to do with the size of the files going onto your medium. Many files of a smaller size fit better on a 512 boundary. Whereas larger mp3s or archives fair better on a 4k boundary. BTW these are called SECTOR sizes. Not pages. :) 4k blocks typically read faster, than the 512 blocks (sectors). Because more data can be consumed in one read/write. So really, your going to have to decide how best to "tune" your disk to best suite it's intended use. Many small files. Or big files, and storage. HTH --Chris FreeBSD 14.0-FUTURE #0.000 cray256 Mario Em sex., 28 de fev. de 2020 às 13:18, Mario Olofo escreveu: > Yes, tried 4k quirk but not on install because don't know how to, I did a > clean install then patch and rebuild the kernel, but > the volume was already configured for 512bytes, I think I would need to > create manually the volume, but don't remember how to anymore xD > But I'll search some tutorials and try. From what I saw, the patch > suggested on bugzilla got merged into the stable branch, so the quirk will > be > detected to use 4k in the installer in a near future. > > Mario > > Em sex., 28 de fev. de 2020 às 12:52, Theron > escreveu: > >> On 2020-02-28 09:14, Mario Olofo wrote: >> > Thanks! >> > >> > The only thing that I didn't checked was the questions of Theron, about >> > misaligned data. >> > The layout of the disk is as follows: >> > >> > Disco /dev/sdb: 447,1 GiB, 480113590272 bytes, 937721856 setores >> > Unidades: setor de 1 * 512 = 512 bytes >> > Tamanho de setor (lógico/físico): 512 bytes / 512 bytes >> > Tamanho E/S (mínimo/ótimo): 512 bytes / 512 bytes >> > Tipo de rótulo do disco: gpt >> > Identificador do disco: D1725E60-D734-4461-90F8-E9EB2376A65A >> > >> > DispositivoInício Fim Setores Tamanho Tipo >> > /dev/sdb12048 1023999 1021952499M Windows ambiente de >> > recuperação >> > /dev/sdb2 1024000 1228799204800100M Sistema EFI >> > /dev/sdb3 1228800 1261567 32768 16M Microsoft reservado >> > /dev/sdb4 1261568 532482047 531220480 253,3G Microsoft dados básico >> > /dev/sdb5 532482048 549257215 16775168 8G FreeBSD ZFS >> > /dev/sdb6 549257216 937719807 388462592 185,2G Linux sistema de >> arquivos >> > >> > The zfsroot was configured automatically by the installer, so I think >> that >> > it align the volume automaticaly right? >> > >> > Mario >> >> Yes, I don't see any potential alignment issue here. I would wonder if >> this drive is misrepresenting its physical sector size, deceiving ZFS >> and the SATA driver into making small writes that the drive does not >> actually support, but it looks like you may have already tried the >> relevant workaround: >> >> On 2020-02-27 23:44, Mario Olofo wrote: >> > Maybe the problem really is a combination of factors, for the person >> that >> > filed a bug on bugzilla the fix was setting the quirks 4k and >> broken_trim, >> > but for me the real block size is 512bytes and only setting the flag >> > broken_trim didn't help... >> > >> > Mario >> Did you try 4k quirk ? >> >> Theron >> > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: vt [was: Re: [Bug 235564] INDEX.keymaps for vt contains "from-" keymaps but the files are missing]
On Mon, 9 Mar 2020 07:06:31 +1000 Andy Farkas an...@andyit.com.au said On 2020-03-09 04:15, bugzilla-nore...@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235564 > > --- Comment #8 from commit-h...@freebsd.org --- > A commit references this bug: > > Author: emaste > Date: Sun Mar 8 18:14:45 UTC 2020 > New revision: 358758 > URL: https://svnweb.freebsd.org/changeset/base/358758 > > Log: >MFC r355585: remove nonexistent from-* entries from vt INDEX.keymaps Is anyone actually working on the vt(4) driver? Will it ever become feature-parity with the old sc(4) driver? I've noticed some weird things happening on my console recently... like psychedelicly-colour-coded kernel messages.. far out, man. Just wondering, -andyf Thanks for bringing this up. I've been meaning to ask similar. When building a custom kernel, and including sc(4). Then adding kern.vt=sc to loader.conf(5). I'm presented with rainbow text. I wouldn't mind so much *except* that it's color choices, and places are simply *random* Thanks in advance for any insight on this. :) --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
what 3rd party boot mgr is required to boot multiple freebsd versions?
I'm attempting to boot multiple versions of FreeBSD. I started with an install of older 11 with a (u)efi boot partition installed. I then grabbed an current 11 usbstick, and installed that. Which stated it needed to install a (u)efi boot partition. I let it do it. But the new (additional) install doesn't show up at boot. Altho my UEFI BIOS sees it. I guess there are just too many uefi bios versions, and too many changes in the FreeBSD uefi boot code to expect consistent results over the long haul. Should I just convert the 1st efi (GPT) boot partition to a PMBR, and delete the second efi partition. Or is there a recommended bootmanager I can use to boot multiple versions of FreeBSD? Windows? Thank you! --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
efi: WARNING: Unable to alias diskid/DISK-... to enc@n306168... - path too long
I'm getting the following message on a fresh install of 12.1: WARNING: Unable to alias diskid/DISK-WD-WCANM2154600 to enc@n3061686369656d30/type@0/slot@1/elmdesc@Slot_00/diskid/DISK-WD-WCANM2154600 - path too long Actually, there are several similar messages. Which required me to perform several disk related tasks in order to get a successful boot into the new system. It's GPT/UFS(2) if it matters. But I suspect it's more related to fbsd' implementation of EFI, as it relates to my BIOS' implementation (Intel Sandy Bridge). What can I do to make everything happy? Thanks! --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: efi: WARNING: Unable to alias diskid/DISK-... to enc@n306168... - path too long
On Wed, 18 Mar 2020 10:48:08 -0600 Alan Somers asom...@freebsd.org said On Wed, Mar 18, 2020 at 10:37 AM Chris wrote: > I'm getting the following message on a fresh install of 12.1: > WARNING: Unable to alias diskid/DISK-WD-WCANM2154600 to > > enc@n3061686369656d30/type@0/slot@1/elmdesc@Slot_00/diskid/DISK-WD-WCANM2154600 > - path too long > Actually, there are several similar messages. Which required me to > perform several disk related tasks in order to get a successful boot > into the new system. It's GPT/UFS(2) if it matters. But I suspect > it's more related to fbsd' implementation of EFI, as it relates to my > BIOS' implementation (Intel Sandy Bridge). What can I do to make > everything happy? > > Thanks! > > --Chris > When did you see that message? Was it printed from the bootloader, or after you booted? If it happened after boot, then they're probably harmless, but you can make them go away by setting kern.geom.label.disk_ident.enable=0. Thanks for the reply! It's during boot, and found in dmesg.boot. I wouldn't care so much, except I was unable to boot into the system until I performed a gpart modify -i -l on all the slices, and modify fstab(5) accordingly. Kind of a rough start for an install IMHO. :) Thanks again, for the reply, Alan! --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: efi: WARNING: Unable to alias diskid/DISK-... to enc@n306168... - path too long
On Wed, 18 Mar 2020 11:37:34 -0600 Alan Somers asom...@freebsd.org said On Wed, Mar 18, 2020 at 10:56 AM Chris wrote: > On Wed, 18 Mar 2020 10:48:08 -0600 Alan Somers asom...@freebsd.org said > > > On Wed, Mar 18, 2020 at 10:37 AM Chris wrote: > > > > > I'm getting the following message on a fresh install of 12.1: > > > WARNING: Unable to alias diskid/DISK-WD-WCANM2154600 to > > > > > > enc@n3061686369656d30/type@0/slot@1/elmdesc@Slot_00 > /diskid/DISK-WD-WCANM2154600 > > > - path too long > > > Actually, there are several similar messages. Which required me to > > > perform several disk related tasks in order to get a successful boot > > > into the new system. It's GPT/UFS(2) if it matters. But I suspect > > > it's more related to fbsd' implementation of EFI, as it relates to my > > > BIOS' implementation (Intel Sandy Bridge). What can I do to make > > > everything happy? > > > > > > Thanks! > > > > > > --Chris > > > > > When did you see that message? Was it printed from the bootloader, or > > after you booted? If it happened after boot, then they're probably > > harmless, but you can make them go away by setting > > kern.geom.label.disk_ident.enable=0. > Thanks for the reply! > It's during boot, and found in dmesg.boot. I wouldn't care so much, > except I was unable to boot into the system until I performed a > gpart modify -i -l on all the slices, and modify > fstab(5) accordingly. Kind of a rough start for an install IMHO. :) > > Thanks again, for the reply, Alan! > > --Chris > How did you setup your zroot? This shouldn't matter unless you used those long aliases as the vdevs for your zroot pool. Thanks for the reply, Alan. As mentioned above; the disk is GPT/UFS(2). I chose "custom" from the disk layout dialog from the install media. I chose UFS/softupdates, and later, after getting a successful boot onto the drive. I added journaling. But that's it. Nothing fancy. Thanks again. --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Why is the console a graphic/bitmapped console, and not text/character by default
Sorry for the ling title. But wasn't sure how make my question more concise. Why did we begin making an initial console "graphics mode" by default. My understanding has always been that (Free)BSD has been a "Server by default", and a Desktop after an initial install if that's one chosen target. It's near impossible to perform initial configuration in graphics mode, using a mouse to cut/copy/paste does *not* work as intended. Which requires one to make the necessary changes "breaking to the new system" after install completes to change initiation to test-mode before bouncing the box. While this "works" for long-time users. It's an *extra*, and seemingly *unnecessary* step. It is also likely to behoove first-time/new users -- except those already targeting a Desktop. Thanks for any insight into this! :) --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why is the console a graphic/bitmapped console, and not text/character by default
On Sun, 12 Apr 2020 12:55:47 +0700 Eugene Grosbein eu...@grosbein.net said 12.04.2020 11:41, Chris wrote: > Sorry for the ling title. But wasn't sure how make my > question more concise. > Why did we begin making an initial console "graphics mode" > by default. My understanding has always been that (Free)BSD > has been a "Server by default", and a Desktop after an initial > install if that's one chosen target. > It's near impossible to perform initial configuration > in graphics mode, using a mouse to cut/copy/paste does *not* > work as intended. Which requires one to make the necessary > changes "breaking to the new system" after install completes > to change initiation to test-mode before bouncing the box. > While this "works" for long-time users. It's an *extra*, and > seemingly *unnecessary* step. It is also likely to behoove > first-time/new users -- except those already targeting a > Desktop. > > Thanks for any insight into this! :) There are now many new hardware incapable of booting in legacy mode. It runs in UEFI mode only that needs newer console driver vt(4) that defaults to pixel rendering mode but supports text mode, too. Sadly, some UEFI-based hardware does not support text mode even with vt(4) and there is no option other than using pixel mode then. That explains it. Thanks Eugene! :) Even if the answer is a bit disappointing. ;) --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: make kernel ignore broken SATA disk
On Sun, 12 Apr 2020 16:37:06 +0200 Stefan Bethke s...@lassitu.de said I have a server I don't have physical access to right now, which has a broken SATA disk that produces mostly errors (but not entirely). The disk has two partitions that are part of a zpool each. I can't bring the system up with this disk being online, because ZFS is trying its darndest to use it. I already renamed the GPT partitions in the hope that ZFS would not find them anymore, but it does. I can't gpart destroy -f ada1 because "device busy". FTR it's gpart destroy -F (note the case difference) :-) Is there a way, ideally in the loader, to tell the kernel to ignore ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the disk? I do have a spare disk I can use to replace the failed one, but I can't get the machine into a state where I could even issue the zpool replace command. Stefan --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support of PCIe NVME drives
On Thu, 16 Apr 2020 22:57:10 +0200 Miroslav Lachman 000.f...@quip.cz said Chuck Tuffli wrote on 04/16/2020 22:29: > On Thu, Apr 16, 2020 at 12:30 PM Miroslav Lachman <000.f...@quip.cz> wrote: >> >> Pete Wright wrote on 04/16/2020 20:23: >>> >>> >>> On 4/16/20 11:12 AM, Miroslav Lachman wrote: >>>> Kurt Jaeger wrote on 04/16/2020 20:07: >> >>> I would try booting via UEFI if you can. I just installed a laptop >>> yesterday which has a nvme root device, it was detected by the 12-STABLE >>> snapshot I used to boot from. no other modifications were necessary on >>> my end. >> >> I changed BIOS settings to use UEFI boot method, booted 12.1 installer >> ISO but without luck. Still no NVME disks :( >> >> You can see it on printscreen from iDRAC https://ibb.co/tPnymL7 >> >> Anything more I can test? > > Fair warning, I don't deal much with Dell, but it's curious that iDrac > lists the device protocol as MI >> Device Protocol: NVMe-MI1.0 > > MI or the Management Interface is defined by NVMe, but it isn't the > same as a block interface. MI typically uses SMBUS and not PCIe to > communicate with the device. So it's possible that the device is > visible to iDrac via SMBUS but may not be on the PCIe bus for > $reasons. Does iDrac have any tools to interact with the device via > MI? iDRAC does not allow me to do anything with the drives. But I booted Linux SystemRescueCd and nvme devices are there visible in /dev/ printscreen https://ibb.co/sj22Nwg So I think the HW is OK, but FreeBSD does not recognize the controller? Does mps(4) or any of the other (often Dell) rebranded LSI drivers expose anything? Kind regards Miroslav Lachman --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support of PCIe NVME drives
On Thu, 16 Apr 2020 19:57:21 -0700 Mel Pilgrim list_free...@bluerosetech.com said On 2020-04-16 12:30, Miroslav Lachman wrote: > Pete Wright wrote on 04/16/2020 20:23: >> >> >> On 4/16/20 11:12 AM, Miroslav Lachman wrote: >>> Kurt Jaeger wrote on 04/16/2020 20:07: > >> I would try booting via UEFI if you can. I just installed a laptop >> yesterday which has a nvme root device, it was detected by the >> 12-STABLE snapshot I used to boot from. no other modifications were >> necessary on my end. > > I changed BIOS settings to use UEFI boot method, booted 12.1 installer > ISO but without luck. Still no NVME disks :( > > You can see it on printscreen from iDRAC https://ibb.co/tPnymL7 > > Anything more I can test? Looking at server specs, the R6515's NVME support is only through the PERC S150 RAID controller. If that's the case, I'm pretty sure you're out of luck. The PERC S-series controllers are software-based RAID that require Dell's Windows or Linux drivers. You'd need a PERC H-series card to get support in FreeBSD. Someone please correct me if I'm wrong? As I mentioned. I was suspicious of this. He should be able to flash the card, making it a pass. I do a lot of them. If someone doesn't beat me to it. I'll dig through what I have, and see if I can't find the right image(s), and program(s). --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support of PCIe NVME drives
On Fri, 17 Apr 2020 08:17:56 +0200 Miroslav Lachman 000.f...@quip.cz said Chris wrote on 04/17/2020 05:51: > On Thu, 16 Apr 2020 19:57:21 -0700 Mel Pilgrim > list_free...@bluerosetech.com said > >> On 2020-04-16 12:30, Miroslav Lachman wrote: >> > Pete Wright wrote on 04/16/2020 20:23: >> >> >> >> >> >> On 4/16/20 11:12 AM, Miroslav Lachman wrote: >> >>> Kurt Jaeger wrote on 04/16/2020 20:07: >> > >> I would try booting via UEFI if you can. I just installed a >> laptop >> yesterday which has a nvme root device, it was detected by >> the >> 12-STABLE snapshot I used to boot from. no other modifications >> were >> necessary on my end. >> > > I changed BIOS settings to use UEFI boot method, booted 12.1 >> installer > ISO but without luck. Still no NVME disks :( >> > > You can see it on printscreen from iDRAC https://ibb.co/tPnymL7 >> > > Anything more I can test? >> >> Looking at server specs, the R6515's NVME support is only through the >> PERC S150 RAID controller. If that's the case, I'm pretty sure you're >> out of luck. The PERC S-series controllers are software-based RAID >> that require Dell's Windows or Linux drivers. You'd need a PERC >> H-series card to get support in FreeBSD. That's something I didn't expect at all. So there is nothing which can be fixed on FreeBSD side? :( >> Someone please correct me if I'm wrong? > As I mentioned. I was suspicious of this. He should be able to flash the > card, > making it a pass. I do a lot of them. If someone doesn't beat me to it. > I'll > dig through what I have, and see if I can't find the right image(s), and > program(s). This is rented dedicated machine. I cannot flash anything on it. Apologies for the late reply. Unfortunately $JOB requires me to $WORK. :( OK Given these are rentals. Probably the most I could supply for your needs are images that allow you to poll, and change settings of the controller(s). I have cd9660, and USB flash images of the utilities for the 100-300 series HBAs as provided by LSI/AvGO. They boot to (MS)DOS, or to an (U)EFI prompt. Having read what I can; the S150 controller is Software controlled (likely explaining the "S" in it's model number), and as I understand it *shouldn't* require any flashing. As I also understand you *should* be able to access control of it through UEFI configs. I *think* accessed via F2. Apologies if this comes too late, or you've already solved this. If you're still interested in the management software I have for the 100-300 series. Let me know, and I'll attach a copy, or provide a link for you as needed. --Chris I can ask the provider if they can install some card. Do you have some recommendation? What is supported by Dell and FreeBSD for ZFS? I really appreciate your help! Kind regards Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Loader hangs on the latest -STABLE
On Fri, 24 Apr 2020 08:26:13 +0400 Igor Pokrovsky i...@unixway.org said Hello all, I haven’t been using FreeBSD since 8-STABLE times. Recently I tried to install latest 12-STABLE on my old computer. But even during initial boot up loader hangs. Eventually I was able to proceed with installation after replacing loader in the installation disk with one found in my old system 8-STABLE. The same happened when I tried zfs on root partition. A lot of things are moving around in /boot over the last year. Pure speculation; if you're using a usb stick. Mount it from your currently running system, and cd /boot rm ./loader cp -p ./loader.efi ./loader umount Then see if it doesn't work for you. Like I said, pure speculation. But you indicated an old box. So I think you might find this works. Best wishes! --Chris I used MBR partition on PATA hard drive. Motherboard was ASUS A8V (Athlon64). ip ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Loader hangs on the latest -STABLE
On Thu, 23 Apr 2020 22:24:00 -0700 bsd-li...@bsdforge.com said On Fri, 24 Apr 2020 08:26:13 +0400 Igor Pokrovsky i...@unixway.org said > Hello all, > > I haven’t been using FreeBSD since 8-STABLE times. Recently I tried to > install latest 12-STABLE on my old computer. > But even during initial boot up loader hangs. Eventually I was able to > proceed with installation after replacing loader in > the installation disk with one found in my old system 8-STABLE. The same > happened when I tried zfs on root partition. A lot of things are moving around in /boot over the last year. Pure speculation; if you're using a usb stick. Mount it from your currently running system, and cd /boot rm ./loader cp -p ./loader.efi ./loader STRIKE THAT! I meant cp -p ./loader.4th ./loader sorry! OH, and you will, of course need to do it as root. :) --Chris umount Then see if it doesn't work for you. Like I said, pure speculation. But you indicated an old box. So I think you might find this works. Best wishes! --Chris > > I used MBR partition on PATA hard drive. Motherboard was ASUS A8V > (Athlon64). > > ip > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: LUA ERROR: memory allocation error: block too big
On Wed, 3 Jun 2020 05:00:13 + (UTC) Roderick hru...@gmail.com said LUA Error! I would real want hear, why was the boat loader spoiled with Lua? Bwcause lua is so cool? Rodrigo On Tue, 2 Jun 2020, Budi Janto wrote: > Hi Folks, > > Now, I'am running FreeBSD 12.1-STABLE, suddenly after restart system can > not able to booting (boot to single user only). > > ... > Loading /boot/defaults/loader.conf > Loading /boot/device.hints > Loading /boot/loader.conf > efipart_readwrite: rw=1, blk=5656992 size=40 status=7 > Startup error in /boot/lua/loader.lua: > LUA ERROR: memory allocation error: block too big. > > can't load 'kernel' > > Type '?' for a list of commands. 'help' for more detailed help > OK > ... > > Anyone could give some clue to fixing this booting issue? -- Thank You. Boot single user if possible, tho it's probably not. Failing that; boot from the install media. Mount the root slice of your failing system. cd to its /boot folder rm ./loader ln loader_4th loader cd / unmount the system remove the install media you just booted from, and reboot. It should (hopefully) work now. --Chris > > > -- > Regards, > > > Budi Janto > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: swap space issues
. Feeling the same way. C++ IMHO was the beginning of the end -- abstraction / objects do not lead to a better understanding of what you're doing, if you've never worked on "bare metal" (at the "chip" level). Those w/o knowledge in assembler never really fully understand what their doing. Sorry. Couldn't resist. Another problem, especially with programmers whose memories have not yet accumulated many painful experiences, is the attraction toward newer, more exciting features accompanied by a disinterest in tracking down and fixing existing bugs, even fairly critical bugs. This problem, if left unchecked by management, can lead to terrible predicaments like the one FreeBSD is in now, namely, having no production releases being supported. DragonflyBSD, NetBSD, and OpenBSD do not, AFAIK, suffer from this predicament at present. They are behind to varying degrees in terms of newer, more exciting features, but at least they appear to work. For example, sdf.org has well over 70,000 users and runs quite a few servers to do so. It runs NetBSD miku 8.1_STABLE NetBSD 8.1_STABLE (GENERIC) #0: Wed Sep 11 03:47:45 UTC 2019 root@ol:/sdf/sys/NetBSD-8/sys/arch/amd64/compile/GENERIC amd64 at present. (miku.sdf.org is one of the servers.) Its uptime is currently 306 days. They run several VMs of FreeBSD, OpenBSD, LINUX, and possibly others on some of the servers. ZFS appeared in NetBSD 9.0. I don't know the sysadmin's reasons for not upgrading to it so far, but I suspect they have to do with the number of systems to upgrade, the fact that it is a .0 release, and that root on ZFS and ZFS boot environments are not yet supported, as used to be the case with FreeBSD. I'm not ready to switch to NetBSD quite yet and would not enjoy doing so, but it has been a steadily improving alternative to FreeBSD of late, and if FreeBSD does not release a production system in the meantime, NetBSD may become a better choice for many of us who want to run a production OS. It also offers an alternative to Micro$lop for the so-called "Internet of Things", which no other FOSS OS does, AFAIK, although I don't know enough about LINUX to be sure. > > Those who live on -CURRENT are used to OOPS, but the rest of us get paid > not to have them. I've been using -STABLE for the last several major releases, but because of the vast numbers of conflicts and failures buried throughout the ports tree and the horrendous amount of time it takes to rebuild most of my installed ports I am considering surrendering to using -RELEASE and using quarterly packages, in spite of the loss of features that doing so entails. That would still not deal with the dependency conflicts or the installation of identically named files by different ports, but it would reduce the time spent on building ports that fail to install. > > I am happy with what the Core Team gives us, AND of course we want > ['more','better','faster','STABLE']. :D > As Mark Linimon pointed out, the Core Team only does that indirectly. However, it is the Core Team's job to give firm direction or redirection to those who do the designing and coding to avoid regressions, avoid ignoring the introduction of bugs, especially those that render a system unfit for production use, enhance testing, and so on. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
How to get mouse configured in X(org)?
Greetings all, I just installed a copy of 12@363433 from the install media. I then pkg installed everything I intended to use. After installing Xorg-server,nvidia-driver,xf86-input-keyboard, xf86-input-mouse. I fired Xorg -configure examined the output in both /var/Xorg.o.log && ~/xorg.conf.new everything appeared to be in order. So I fired off a Xorg -config ~/xorg.conf.new -retro While I got the familiar background mesh (-retro), and the keyboard functioned correctly. The mouse doesn't work. From Xorg.0.log: [85.337] (II) config/udev: Adding input device IntelliMouse Explorer (/dev/input/event4) [85.337] (II) No input driver specified, ignoring this device. [85.337] (II) This device may have been added with another device file. Relevant excerpt from xorg.conf.new: Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection I appear to have covered all the bases in the entry of the handbook at: https://www.freebsd.org/doc/handbook/x-config.html Thanks in advance for any assistance. --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How to get mouse configured in X(org)?
On Fri, 31 Jul 2020 21:36:33 + Mark Linimon lini...@lonesome.com said What is the output of the script mentioned in: https://lists.freebsd.org/pipermail/freebsd-x11/2020-February/025004.html Thanks for the prompt, and thoughtful reply, Mark! :-) OK I've been following CURRENT, and was aware of that. As I needed it the first time around with the new Xorg. But I hadn't imagined I would require any outside helpers on STABLE. :( Anyway. I managed to get a working xorg.conf.new running against Xorg -config. So I added only what I thought I absolutely needed to /usr/local/X11/xorg.conf.d/ and fired up startx with my chosen DE in .xinitrc. Only to find I _still_ had no mouse, nor control of the WM. My only recourse was to bounce the box. :-( I had to scrub the pool, and blow away all the X related things in ~/ && try again. I was finally successful after creating the following 4 files: server-layout.conf Section "ServerLayout" Identifier "X.org Configured" Option "AutoAddDevices" "Off" Option "Log" "sync" EndSection driver-nvidia.conf Section "Device" Identifier "Card0" Driver "nvidia" BusID "PCI:2:0:0" EndSection screen-layout.conf Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName"Monitor Model" EndSection keyboard-zap.conf Section "InputClass" Identifier "KeyboardDefaults" Driver "keyboard" MatchIsKeyboard "on" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection Altho the keyboard-zap.conf is probably unnecessary. I added it in hopes of being able to bail out as opposed to bouncing the box. I can't believe what a disappointment X has become. It's almost a different incantation for every install. I'd understand on CURRENT/release. But not on STABLE. I'm very grateful for your lending a hand, Mark. I don't mean to point any of my frustration at/towards you. :-) Thanks, again! :-) --Chris mcl ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How to get mouse configured in X(org)?
On Fri, 31 Jul 2020 18:03:17 -0700 bsd-li...@bsdforge.com said All bitching aside. My conclusion is the Option "AutoAddDevices" "Off" Line below is responsible for permitting/activating the mouse. server-layout.conf Section "ServerLayout" Identifier "X.org Configured" Option "AutoAddDevices" "Off" Option "Log" "sync" EndSection driver-nvidia.conf Section "Device" Identifier "Card0" Driver "nvidia" BusID "PCI:2:0:0" EndSection screen-layout.conf Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName"Monitor Model" EndSection keyboard-zap.conf Section "InputClass" Identifier "KeyboardDefaults" Driver "keyboard" MatchIsKeyboard "on" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
net.pf.request_maxcount: UNDESIRABLE_OID
We've been developing an appliance/server based on FreeBSD && pf(4). We started some time ago, and have been using a very early version of 12. We're now collecting some 20,000,000 IP's /mos. So we're satisfied we're close to releasing. As such, we needed to bring the release up to a supported (freebsd) version (12-STABLE). We would have done so sooner. But we need a stable (unchanging) testbed to evaluate what we're working on. We built and deployed a copy of 12-STABLE @r363918 that contained our work with pf(4). Booting into it failed unexpectedly with: cannot define table nets: too many elements. Consider increasing net.pf.request_maxcount. pfctl: Syntax error in config file: pf rules not loaded OK this didn't happen on our testbed prior to the upgrade with a combined count of ~97,000,900 IPs. In fact the OID mentioned didn't exist. For reference; our testbed provides DNS, www, mail for ~60 domains/hosts, as well as our pf(4) testing. We can happily load our tables, and run these services w/8Gb RAM. This OID is more a problem than a savior. Why not simply return ENOMEM? Isn't that what it used to do? pf.conf(5) already facilitates thresholds, and they aren't _read only_. Is there any way to turn this OID off; like using a -1 value? Or will we need to simply back out the commit? Thanks in advance for any advice. --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: net.pf.request_maxcount: UNDESIRABLE_OID
On Fri, 21 Aug 2020 08:33:16 +0200 Kristof Provost k...@freebsd.org said Hi Chris, Hello, Kristof. Thanks for the reply. Nice name BTW. ;-) On 21 Aug 2020, at 2:40, Chris wrote: > We've been developing an appliance/server based on FreeBSD && > pf(4). We started some time ago, and have been using a very > early version of 12. We're now collecting some 20,000,000 > IP's /mos. So we're satisfied we're close to releasing. As > such, we needed to bring the release up to a supported > (freebsd) version (12-STABLE). We would have done so sooner. > But we need a stable (unchanging) testbed to evaluate what > we're working on. > We built and deployed a copy of 12-STABLE @r363918 that > contained our work with pf(4). Booting into it failed > unexpectedly with: cannot define table nets: too many > elements. Consider increasing net.pf.request_maxcount. > pfctl: Syntax error in config file: pf rules not loaded > OK this didn't happen on our testbed prior to the upgrade > with a combined count of ~97,000,900 IPs. In fact the OID > mentioned didn't exist. > For reference; our testbed provides DNS, www, mail for > ~60 domains/hosts, as well as our pf(4) testing. We can > happily load our tables, and run these services w/8Gb > RAM. > This OID is more a problem than a savior. Why not simply > return ENOMEM? > To quote the commit message: pf ioctls frequently take a variable number of elements as argument. This can potentially allow users to request very large allocations. These will fail, but even a failing M_NOWAIT might tie up resources and result in concurrent M_WAITOK allocations entering vm_wait and inducing reclamation of caches. Limit these ioctls to what should be a reasonable value, but allow users to tune it should they need to. Now that pf can be used in vnet jails there’s a possibility of an attacker using pf to deny service to other jails (or the host) by exhausting memory. Imposing limits on pf request sizes mitigates this. Hadn't considered vnet. Thanks for mentioning it. But why must it be a read-only OID? > Isn't that what it used to do? pf.conf(5) > already facilitates thresholds, and they aren't _read > only_. Is there any way to turn this OID off; like using > a -1 value? Or will we need to simply back out the commit? > You can functionally disable it by setting a very large value. Try setting 4294967295. Thanks. When I was confronted with the message. I simply chose an arbitrarily high number of 8. Which allowed the tables to load. But I felt I should look closer into this for a better understanding. :-) Thank you very much for taking the time to reply! Best regards, Kristof --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: net.pf.request_maxcount: UNDESIRABLE_OID
On Fri, 21 Aug 2020 08:56:12 +0200 Kristof Provost k...@freebsd.org said On 21 Aug 2020, at 8:53, Chris wrote: > On Fri, 21 Aug 2020 08:33:16 +0200 Kristof Provost k...@freebsd.org said > >> Hi Chris, > Hello, Kristof. Thanks for the reply. > Nice name BTW. ;-) >> >> On 21 Aug 2020, at 2:40, Chris wrote: >> > We've been developing an appliance/server based on FreeBSD && >> > pf(4). We started some time ago, and have been using a very >> > early version of 12. We're now collecting some 20,000,000 >> > IP's /mos. So we're satisfied we're close to releasing. As >> > such, we needed to bring the release up to a supported >> > (freebsd) version (12-STABLE). We would have done so sooner. >> > But we need a stable (unchanging) testbed to evaluate what >> > we're working on. >> > We built and deployed a copy of 12-STABLE @r363918 that >> > contained our work with pf(4). Booting into it failed >> > unexpectedly with: cannot define table nets: too many >> > elements. Consider increasing net.pf.request_maxcount. >> > pfctl: Syntax error in config file: pf rules not loaded >> > OK this didn't happen on our testbed prior to the upgrade >> > with a combined count of ~97,000,900 IPs. In fact the OID >> > mentioned didn't exist. >> > For reference; our testbed provides DNS, www, mail for >> > ~60 domains/hosts, as well as our pf(4) testing. We can >> > happily load our tables, and run these services w/8Gb >> > RAM. >> > This OID is more a problem than a savior. Why not simply >> > return ENOMEM? >> > >> To quote the commit message: >> >> pf ioctls frequently take a variable number of elements as >> argument. This can >> potentially allow users to request very large allocations. These >> will fail, >> but even a failing M_NOWAIT might tie up resources and result in >> concurrent >> M_WAITOK allocations entering vm_wait and inducing reclamation of >> caches. >> >> Limit these ioctls to what should be a reasonable value, but >> allow users to >> tune it should they need to. >> >> Now that pf can be used in vnet jails there’s a possibility of an >> attacker using pf to deny service to other jails (or the host) by >> exhausting memory. Imposing limits on pf request sizes mitigates >> this. > Hadn't considered vnet. Thanks for mentioning it. > But why must it be a read-only OID? > It doesn’t have to be, and in CURRENT it’s not: https://svnweb.freebsd.org/base?view=revision&revision=355744 That hasn’t been MFC’d for the excellent reason that I forgot. Good news! I’ll try to do that today, after I fix my dev-VM. Hope it turns out to be an easy fix for you. Thanks for all your time! Best regards, Kristof --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: The spkr driver
On 2020-08-28 09:25, Warner Losh wrote: Greetings, I'd like to retire the spkr driver. It was a cute hack before sound cards were ubiquitous, but it's not been kept up to date, and it's not clear that it still works It is still Giant locked, and though it's not a huge effort to do the locking I literally have no way to test it that I trust... Is anybody using it these days for anything? If not, I'd propose we de-orbit it before 13. If so, I need people to test patches to remove Giant... I still use it for important events, as alerts that something needs attention on any one of my servers. It's easier to distinguish, and while many boards include more complex sound. The speaker is "cheap" and easy to use. I should be able to help test. Thanks for the heads-up! --Chris Warner ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: release cycle
On 02/06/07, Fabian Keil <[EMAIL PROTECTED]> wrote: Chris <[EMAIL PROTECTED]> wrote: > On 29/05/07, Mark Linimon <[EMAIL PROTECTED]> wrote: > > On Tue, May 29, 2007 at 09:17:57PM +1000, Peter Jeremy wrote: > > > Agreed. 6.3-RELEASE would nominally be due around July but the lack > > > of any schedule on http://www.freebsd.org/releng/ suggests that it will > > > be later than that. The plans to start the 7.0-RELEASE cycle will also > > > impact this. > > > > At BSDCan, Ken Smith mentioned that 7.0 is due to be branched in July and > > released in Aug/Sep, with 6.3 quickly following (perhaps even overlapping > > so as to reuse the same ports freeze). > > > > The ports tree is not even close to stable enough to release right now. > Given that Kris repeatedly tells me and others that the ports system > is only supported on the latest freebsd release (meaning one has to be > upgrading freebsd on their servers every few months to get this > support) if 7.0 and 6.3 are released around the same time will the > ports tree be supported on both? I believe you misunderstood something. Where do you think Kris said that? Fabian He said using the ports is only supported in the latest FreeBSD release, so eg. its not supported in 5.5 and 6.0 and 6.1. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: release cycle
On 02/06/07, Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> wrote: On Jun 2, 2007, at 3:45 , Chris wrote: > Given that Kris repeatedly tells me and others that the ports system > is only supported on the latest freebsd release (meaning one has to be > upgrading freebsd on their servers every few months to get this > support) if 7.0 and 6.3 are released around the same time will the > ports tree be supported on both? I think you're confused by terminology. As I understand it, the ports tree is supported on -CURRENT and the latest -STABLE series: that is, currently on 6.x and 7.x (and possibly 5.x still since RELENG_5 and RELENG_6 were both being released for a while), but not RELENG_4 or earlier. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH So my question remains when we have 7.0 and 6.3 both STABLE releases will the ports tree not be supported in 6.3 a just released version of FreeBSD? Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: release cycle
On 02/06/07, Kris Kennaway <[EMAIL PROTECTED]> wrote: On Sat, Jun 02, 2007 at 02:02:44PM +0200, Fabian Keil wrote: > Chris <[EMAIL PROTECTED]> wrote: > > > On 29/05/07, Mark Linimon <[EMAIL PROTECTED]> wrote: > > > On Tue, May 29, 2007 at 09:17:57PM +1000, Peter Jeremy wrote: > > > > Agreed. 6.3-RELEASE would nominally be due around July but the lack > > > > of any schedule on http://www.freebsd.org/releng/ suggests that it will > > > > be later than that. The plans to start the 7.0-RELEASE cycle will also > > > > impact this. > > > > > > At BSDCan, Ken Smith mentioned that 7.0 is due to be branched in July and > > > released in Aug/Sep, with 6.3 quickly following (perhaps even overlapping > > > so as to reuse the same ports freeze). > > > > > > The ports tree is not even close to stable enough to release right now. > > > Given that Kris repeatedly tells me and others that the ports system > > is only supported on the latest freebsd release (meaning one has to be > > upgrading freebsd on their servers every few months to get this > > support) if 7.0 and 6.3 are released around the same time will the > > ports tree be supported on both? > > I believe you misunderstood something. Where do you think Kris said that? Yep, looks like he's confused again. I hope it's not a terminal condition. Kris Please repeat what you told me when I asked why a variable I had to set on 6.1 machines wasnt put in UPDATING. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: release cycle
On 04/06/07, Doug Barton <[EMAIL PROTECTED]> wrote: Chris wrote: > So my question remains when we have 7.0 and 6.3 both STABLE releases > will the ports tree not be supported in 6.3 a just released version of > FreeBSD? I can't help but get the impression that you're spoiling for a fight here, so let me ask you to take step 1, which is relax a little. You are focusing on released version numbers when you ask about ports support, and we generally focus on release branches. See http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html for more information about that. We will be supporting ports for RELENG_5 and _6, and RELENG_7 after it's created from what is now HEAD. Where I think the confusion is coming in is in regards to support for a specific version number that is older than the latest version in that branch. For example, support for 6.1 which is an older release on the RELENG_6 branch. We do our best to provide ports support for older versions on currently supported branches, but it's not always possible to do so. You can search the archives of the ports list for information on why just supporting 3 active branches (which will be 4 after RELENG_7 is branched) for over 16,000 ports is a pretty massive undertaking. I hope this makes the situation more clear. Doug -- This .signature sanitized for your protection This is what I had always thought until I was told otherwise recently thanks. Not spoiling for a fight just trying to understand the situation because it was dissapointing to be told last week that the reason for a ommision in UPDATING was because 6.1 was not the latest release. For this reason I wont dig up the quote I am just happy that 6.3 will be supported. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gbde encryption and server crash
Does gbde encryption have known stability problems? Reason I ask is in the past I remember having numerous problems with it and tried it again today, within 30 secs of sending a file to the partition the server died and is offline and I am waiting for it to be rebooted (remote server) I followed the handbook to the latter. I set the sector size to 2048 as the handbook said although the file says to leave at 512 for best stability. Freebsd 6.2-STABLE if the box still boots as I am worried it wont then I will provide a dmesg and kernel config output. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nfe driver 6.2 stable
Hi I installed the following driver. http://www.f.csce.kyushu-u.ac.jp/~shigeaki//software/freebsd-nfe.html Before I had the nve driver which was unstable on this server and on a prior server in both cases causing either spontaneous reboot or just a crash when under load. So far touchwood the nfe driver has stayed up and running at almost 3 days uptime and has had some stress. I know the driver supports device polling which I have chosen not to use yet as I wanted to see initially if it was more stable in its default mode. But what I want to know is the following if possible please. My ifconfig output below. nfe0: flags=8843 mtu 1500 options=8 inet x.x.x.x netmask 0xff00 broadcast x.x.x.x inet x.x.x.x netmask 0x broadcast x.x.x.x ether x media: Ethernet autoselect (1000baseTX ) status: active 1 - is there a man page for nfe anywhere? 2 - does it support hardware checksum I remember reading it does but from ifconfig output it appears to not be in use so if it does support it how do I enable it? 3 - same with TOS? 4 - how do I enable jumbo frames if it supports it? 5 - is it safe to use with zero copy sockets? 6 - I currently have both net.isr.direct and mpsafenet disabled is this driver safe to use on them? Thanks Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfe driver 6.2 stable
On 24/09/2007, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > On Mon, Sep 24, 2007 at 12:57:23AM +0100, Chris wrote: > > nfe0: flags=8843 mtu 1500 > > options=8 > > inet x.x.x.x netmask 0xff00 broadcast x.x.x.x > > inet x.x.x.x netmask 0x broadcast x.x.x.x > > ether x > > media: Ethernet autoselect (1000baseTX ) > > status: active > > > > 1 - is there a man page for nfe anywhere? > > Closest thing I can find would be the manpage from -CURRENT's nfe(4), > which is supposedly the same code. > > http://www.freebsd.org/cgi/man.cgi?query=nfe&apropos=0&sektion=0&manpath=FreeBSD+7-current&format=html > > > 2 - does it support hardware checksum I remember reading it does but > > from ifconfig output it appears to not be in use so if it does support > > it how do I enable it? > > It does support it, but I don't know the circumstances surrounding when > it gets enabled. That is to say, it's known that some versions of the > chip (and/or associated PHY) have bugs, so possibly hardware checksum > offloading is known to be broken on the system you're on. Taken from my > 7-CURRENT box at home (Asus A8N-E, nForce 4-based): > > nfe0: flags=8843 metric 0 mtu 1500 >options=10b >ether 00:15:f2:17:30:e9 >inet 192.168.1.51 netmask 0xff00 broadcast 192.168.1.255 >media: Ethernet 1000baseTX >status: active > > I do not explicitly specify rxcsum or txcsum in my rc.conf ifconfig > line. > > > 3 - same with TOS? > > TOS (type-of-service) or TSO? If TSO, see above ifconfig. > > > 4 - how do I enable jumbo frames if it supports it? > > You should take a bit more itme to read the webpage you obtained the > driver from. I see these on the page: > > 2007/01/06 Added jumbo frame support. [...] Fixed a bug to handle >Tx/Rx checksum offload settings with ifconfig. > 2006/08/11 Added support for jumbo frame capability. > > yongari@ (Pyun YongHyeon) should be able to provide additional help > with both. > > > 5 - is it safe to use with zero copy sockets? > > No idea. > > > 6 - I currently have both net.isr.direct and mpsafenet disabled is > > this driver safe to use on them? > > No idea. > > -- > | Jeremy Chadwickjdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > Thanks yes I meant TSO sorry, I would guess with the checksum either the 6.x driver is older and not fully implemented yet, the 6.x driver does need more patches for certian chipsets so would indicate its older then the CURRENT driver. Or as you said my chipset is known to be unstable with the hardware checksums. The card is more stable when using nve driver no crashes still but the performance is around the same maxing out at around 200mbit. I was expecting nearer 400-500mbit. e1000phy0: on miibus0 Is the line from dmesg, I believe in CURRENT mpsafe is always on regardless so if you have no problems then its a good sign and I will reenable mpsafe networking (default). Thanks really appreciated. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfe driver 6.2 stable
On 24/09/2007, Chris <[EMAIL PROTECTED]> wrote: > On 24/09/2007, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > On Mon, Sep 24, 2007 at 12:57:23AM +0100, Chris wrote: > > > nfe0: flags=8843 mtu 1500 > > > options=8 > > > inet x.x.x.x netmask 0xff00 broadcast x.x.x.x > > > inet x.x.x.x netmask 0x broadcast x.x.x.x > > > ether x > > > media: Ethernet autoselect (1000baseTX ) > > > status: active > > > > > > 1 - is there a man page for nfe anywhere? > > > > Closest thing I can find would be the manpage from -CURRENT's nfe(4), > > which is supposedly the same code. > > > > http://www.freebsd.org/cgi/man.cgi?query=nfe&apropos=0&sektion=0&manpath=FreeBSD+7-current&format=html > > > > > 2 - does it support hardware checksum I remember reading it does but > > > from ifconfig output it appears to not be in use so if it does support > > > it how do I enable it? > > > > It does support it, but I don't know the circumstances surrounding when > > it gets enabled. That is to say, it's known that some versions of the > > chip (and/or associated PHY) have bugs, so possibly hardware checksum > > offloading is known to be broken on the system you're on. Taken from my > > 7-CURRENT box at home (Asus A8N-E, nForce 4-based): > > > > nfe0: flags=8843 metric 0 mtu 1500 > >options=10b > >ether 00:15:f2:17:30:e9 > >inet 192.168.1.51 netmask 0xff00 broadcast 192.168.1.255 > >media: Ethernet 1000baseTX > >status: active > > > > I do not explicitly specify rxcsum or txcsum in my rc.conf ifconfig > > line. > > > > > 3 - same with TOS? > > > > TOS (type-of-service) or TSO? If TSO, see above ifconfig. > > > > > 4 - how do I enable jumbo frames if it supports it? > > > > You should take a bit more itme to read the webpage you obtained the > > driver from. I see these on the page: > > > > 2007/01/06 Added jumbo frame support. [...] Fixed a bug to handle > >Tx/Rx checksum offload settings with ifconfig. > > 2006/08/11 Added support for jumbo frame capability. > > > > yongari@ (Pyun YongHyeon) should be able to provide additional help > > with both. > > > > > 5 - is it safe to use with zero copy sockets? > > > > No idea. > > > > > 6 - I currently have both net.isr.direct and mpsafenet disabled is > > > this driver safe to use on them? > > > > No idea. > > > > -- > > | Jeremy Chadwickjdc at parodius.com | > > | Parodius Networking http://www.parodius.com/ | > > | UNIX Systems Administrator Mountain View, CA, USA | > > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > > > > > Thanks yes I meant TSO sorry, I would guess with the checksum either > the 6.x driver is older and not fully implemented yet, the 6.x driver > does need more patches for certian chipsets so would indicate its > older then the CURRENT driver. Or as you said my chipset is known to > be unstable with the hardware checksums. > > The card is more stable when using nve driver no crashes still but the > performance is around the same maxing out at around 200mbit. I was > expecting nearer 400-500mbit. > > e1000phy0: on miibus0 > > Is the line from dmesg, I believe in CURRENT mpsafe is always on > regardless so if you have no problems then its a good sign and I will > reenable mpsafe networking (default). > > Thanks really appreciated. > > Chris > Sorry I meant the card is more stable with this nfe then the nve driver. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfe driver 6.2 stable
On 24/09/2007, Chris <[EMAIL PROTECTED]> wrote: > On 24/09/2007, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > On Mon, Sep 24, 2007 at 12:57:23AM +0100, Chris wrote: > > > nfe0: flags=8843 mtu 1500 > > > options=8 > > > inet x.x.x.x netmask 0xff00 broadcast x.x.x.x > > > inet x.x.x.x netmask 0x broadcast x.x.x.x > > > ether x > > > media: Ethernet autoselect (1000baseTX ) > > > status: active > > > > > > 1 - is there a man page for nfe anywhere? > > > > Closest thing I can find would be the manpage from -CURRENT's nfe(4), > > which is supposedly the same code. > > > > http://www.freebsd.org/cgi/man.cgi?query=nfe&apropos=0&sektion=0&manpath=FreeBSD+7-current&format=html > > > > > 2 - does it support hardware checksum I remember reading it does but > > > from ifconfig output it appears to not be in use so if it does support > > > it how do I enable it? > > > > It does support it, but I don't know the circumstances surrounding when > > it gets enabled. That is to say, it's known that some versions of the > > chip (and/or associated PHY) have bugs, so possibly hardware checksum > > offloading is known to be broken on the system you're on. Taken from my > > 7-CURRENT box at home (Asus A8N-E, nForce 4-based): > > > > nfe0: flags=8843 metric 0 mtu 1500 > >options=10b > >ether 00:15:f2:17:30:e9 > >inet 192.168.1.51 netmask 0xff00 broadcast 192.168.1.255 > >media: Ethernet 1000baseTX > >status: active > > > > I do not explicitly specify rxcsum or txcsum in my rc.conf ifconfig > > line. > > > > > 3 - same with TOS? > > > > TOS (type-of-service) or TSO? If TSO, see above ifconfig. > > > > > 4 - how do I enable jumbo frames if it supports it? > > > > You should take a bit more itme to read the webpage you obtained the > > driver from. I see these on the page: > > > > 2007/01/06 Added jumbo frame support. [...] Fixed a bug to handle > >Tx/Rx checksum offload settings with ifconfig. > > 2006/08/11 Added support for jumbo frame capability. > > > > yongari@ (Pyun YongHyeon) should be able to provide additional help > > with both. > > > > > 5 - is it safe to use with zero copy sockets? > > > > No idea. > > > > > 6 - I currently have both net.isr.direct and mpsafenet disabled is > > > this driver safe to use on them? > > > > No idea. > > > > -- > > | Jeremy Chadwickjdc at parodius.com | > > | Parodius Networking http://www.parodius.com/ | > > | UNIX Systems Administrator Mountain View, CA, USA | > > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > > > > > Thanks yes I meant TSO sorry, I would guess with the checksum either > the 6.x driver is older and not fully implemented yet, the 6.x driver > does need more patches for certian chipsets so would indicate its > older then the CURRENT driver. Or as you said my chipset is known to > be unstable with the hardware checksums. > > The card is more stable when using nve driver no crashes still but the > performance is around the same maxing out at around 200mbit. I was > expecting nearer 400-500mbit. > > e1000phy0: on miibus0 > > Is the line from dmesg, I believe in CURRENT mpsafe is always on > regardless so if you have no problems then its a good sign and I will > reenable mpsafe networking (default). > > Thanks really appreciated. > > Chris > More info its a NVIDIA nForce 430 MCP13 adaptor from dmesg. 2006/08/17 Provided a patch to support Marvell 88E1116 PHY In the changelog after they added hardware checksum the changelog says MCP65 had it removed from driver due to no support so I may contact the driver author on this to see what he says. Chris Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfe driver 6.2 stable
On 24/09/2007, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > On Mon, Sep 24, 2007 at 12:57:23AM +0100, Chris wrote: > > nfe0: flags=8843 mtu 1500 > > options=8 > > inet x.x.x.x netmask 0xff00 broadcast x.x.x.x > > inet x.x.x.x netmask 0x broadcast x.x.x.x > > ether x > > media: Ethernet autoselect (1000baseTX ) > > status: active > > > > 1 - is there a man page for nfe anywhere? > > Closest thing I can find would be the manpage from -CURRENT's nfe(4), > which is supposedly the same code. > > http://www.freebsd.org/cgi/man.cgi?query=nfe&apropos=0&sektion=0&manpath=FreeBSD+7-current&format=html > > > 2 - does it support hardware checksum I remember reading it does but > > from ifconfig output it appears to not be in use so if it does support > > it how do I enable it? > > It does support it, but I don't know the circumstances surrounding when > it gets enabled. That is to say, it's known that some versions of the > chip (and/or associated PHY) have bugs, so possibly hardware checksum > offloading is known to be broken on the system you're on. Taken from my > 7-CURRENT box at home (Asus A8N-E, nForce 4-based): > > nfe0: flags=8843 metric 0 mtu 1500 >options=10b >ether 00:15:f2:17:30:e9 >inet 192.168.1.51 netmask 0xff00 broadcast 192.168.1.255 >media: Ethernet 1000baseTX >status: active > > I do not explicitly specify rxcsum or txcsum in my rc.conf ifconfig > line. > > > 3 - same with TOS? > > TOS (type-of-service) or TSO? If TSO, see above ifconfig. > > > 4 - how do I enable jumbo frames if it supports it? > > You should take a bit more itme to read the webpage you obtained the > driver from. I see these on the page: > > 2007/01/06 Added jumbo frame support. [...] Fixed a bug to handle >Tx/Rx checksum offload settings with ifconfig. > 2006/08/11 Added support for jumbo frame capability. > > yongari@ (Pyun YongHyeon) should be able to provide additional help > with both. > > > 5 - is it safe to use with zero copy sockets? > > No idea. > > > 6 - I currently have both net.isr.direct and mpsafenet disabled is > > this driver safe to use on them? > > No idea. > > -- > | Jeremy Chadwickjdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > Ok to recap I have nforce 430 MCP13 I checked the src and current and 6.2-stable driver I am using are the same version number but my driver src has this added above tunables. /* definitions for backporting RELENG-6 */ #ifndef IFCAP_TSO4 #define IFCAP_TSO4 0 #define CSUM_TSO0 #endif #ifndef VLAN_CAPABILITIES #define VLAN_CAPABILITIES(x) #endif #ifndef IFCAP_VLAN_HWCSUM #define IFCAP_VLAN_HWCSUM 0 #endif I am guessing If I set the values to 1 I get the features but would like someone to confirm this for me before I try it thanks. I only have remote access so if it stops the card working I lose access to the box. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gbde and geli on 6.2
Hi I am concerned about the availabilities of these encryptions in freebsd releases that are marked stable. It seems gbde has a problem when the the data written goes over the lba boundary around lba48. http://lists.freebsd.org/pipermail/freebsd-geom/2007-August/002524.html I suffered this problem error example below. Usage at the time was approx 150gig when I first noticed it. g_vfs_done():ad6s1c.bde[WRITE(offset=493964558336, length=131072)]error = 1 After reading about this problem on a few diff hits (all with no response on fixes) I tried geli. However I seen this in geli within an hour of using it. GEOM_ELI: Crypto WRITE request failed (error=1). ad6s1c.eli[WRITE(offset=0, length=131072)] couldnt really found much info on it so I have given up on freebsd encryption for now and using the disk unencrypted. No dma errors etc. all running fine. I expect the gbde is a problem and would like it to come with some warning as a modern drive is now often larger then the lba48 limit whilst I am unsure of geli as I couldnt really found much information on the problem I had so I understand its possible I had set something incorrectly although I followed the handbooks guidelines. The data itself was actually written and not corrupt but the server did crash whilst was in use occasionally so needed reboots which is no good for a production server. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gbde and geli on 6.2
On 26/09/2007, Michael Butler <[EMAIL PROTECTED]> wrote: > Chris wrote: > > Hi I am concerned about the availabilities of these encryptions in > > freebsd releases that are marked stable. > > > > It seems gbde has a problem when the the data written goes over the > > lba boundary around lba48. > > Could you please test the attached patch to /usr/src/sys/dev/ata/ata-all.c ? > > I believe this may be due to the error in the underlying ata driver > rather than specifically to do with encryption. > > As a side note - Soren, could we get this commited to both -current and > -stable if there aren't any significant objections? > >Michael > > yep I further read the link I posted and apologise I seen bad ata was mentioned. I will test on a local machine as I cant test that production machine again, as I understand it I just need to use a large hd greater then lba48? Thanks Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfe driver 6.2 stable
On 27/09/2007, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > On Mon, Sep 24, 2007 at 05:17:40PM +0100, Chris wrote: > > On 24/09/2007, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > > On Mon, Sep 24, 2007 at 12:57:23AM +0100, Chris wrote: > > > > nfe0: flags=8843 mtu 1500 > > > > options=8 > > > > inet x.x.x.x netmask 0xff00 broadcast x.x.x.x > > > > inet x.x.x.x netmask 0x broadcast x.x.x.x > > > > ether x > > > > media: Ethernet autoselect (1000baseTX ) > > > > status: active > > > > > > > > 1 - is there a man page for nfe anywhere? > > > > > > Closest thing I can find would be the manpage from -CURRENT's nfe(4), > > > which is supposedly the same code. > > > > > > > http://www.freebsd.org/cgi/man.cgi?query=nfe&apropos=0&sektion=0&manpath=FreeBSD+7-current&format=html > > > > > > > 2 - does it support hardware checksum I remember reading it does but > > > > from ifconfig output it appears to not be in use so if it does support > > > > it how do I enable it? > > > > > > It does support it, but I don't know the circumstances surrounding when > > > it gets enabled. That is to say, it's known that some versions of the > > > chip (and/or associated PHY) have bugs, so possibly hardware checksum > > > offloading is known to be broken on the system you're on. Taken from my > > > 7-CURRENT box at home (Asus A8N-E, nForce 4-based): > > > > > > nfe0: flags=8843 metric 0 mtu > 1500 > > >options=10b > > >ether 00:15:f2:17:30:e9 > > >inet 192.168.1.51 netmask 0xff00 broadcast 192.168.1.255 > > >media: Ethernet 1000baseTX > > >status: active > > > > > > I do not explicitly specify rxcsum or txcsum in my rc.conf ifconfig > > > line. > > > > > > > 3 - same with TOS? > > > > > > TOS (type-of-service) or TSO? If TSO, see above ifconfig. > > > > > > > 4 - how do I enable jumbo frames if it supports it? > > > > > > You should take a bit more itme to read the webpage you obtained the > > > driver from. I see these on the page: > > > > > > 2007/01/06 Added jumbo frame support. [...] Fixed a bug to handle > > >Tx/Rx checksum offload settings with ifconfig. > > > 2006/08/11 Added support for jumbo frame capability. > > > > > > yongari@ (Pyun YongHyeon) should be able to provide additional help > > > with both. > > > > > > > 5 - is it safe to use with zero copy sockets? > > > > > > No idea. > > > > > > > 6 - I currently have both net.isr.direct and mpsafenet disabled is > > > > this driver safe to use on them? > > > > > > No idea. > > > > > > -- > > > | Jeremy Chadwickjdc at parodius.com > | > > > | Parodius Networking http://www.parodius.com/ > | > > > | UNIX Systems Administrator Mountain View, CA, USA > | > > > | Making life hard for others since 1977. PGP: 4BD6C0CB > | > > > > > > > > > > Ok to recap I have nforce 430 MCP13 > > > > I checked the src and current and 6.2-stable driver I am using are the > > same version number but my driver src has this added above tunables. > > > > /* definitions for backporting RELENG-6 */ > > #ifndef IFCAP_TSO4 > > #define IFCAP_TSO4 0 > > #define CSUM_TSO0 > > #endif > > #ifndef VLAN_CAPABILITIES > > #define VLAN_CAPABILITIES(x) > > #endif > > #ifndef IFCAP_VLAN_HWCSUM > > #define IFCAP_VLAN_HWCSUM 0 > > #endif > > > > I am guessing If I set the values to 1 I get the features but would > > like someone to confirm this for me before I try it thanks. I only > > have remote access so if it stops the card working I lose access to > > the box. > > > > Do you have strong evidence that nForce 430(MCP13, aka MCP51) supports > hardware checksum offload? AFAIK MCP13 does NOT have support checksum > offload/jumbo frame as well as TSO. > > If you want to experiment checksum offload capability of MCP13 > hardware replace the following line in nfe_attach(). > > From: >case PCI_PRODUCT_NVIDIA_MCP51_LAN1: >case PCI_PRODUCT_NVIDIA_MCP51_LAN2: >sc->nfe_flags |= NFE_40BIT_ADDR | NFE_PWR_MGMT; >break; > > To: >case PCI_PRODUCT_NVIDIA_MCP51_LAN1: >case PCI_PRODUCT_NVIDIA_MCP51_LAN2: >sc->nfe_flags |= NFE_40BIT_ADDR | NFE_PWR_MGMT | NFE_HW_CSUM; > ^^ >break; > > -- > Regards, > Pyun YongHyeon > No I didnt know sorry I didnt know MCP13 was aka MCP51 so that explains why thanks. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfe driver 6.2 stable
On 27/09/2007, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > On Mon, Sep 24, 2007 at 04:44:09PM +0100, Chris wrote: > > On 24/09/2007, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > > On Mon, Sep 24, 2007 at 12:57:23AM +0100, Chris wrote: > > > > nfe0: flags=8843 mtu 1500 > > > > options=8 > > > > inet x.x.x.x netmask 0xff00 broadcast x.x.x.x > > > > inet x.x.x.x netmask 0x broadcast x.x.x.x > > > > ether x > > > > media: Ethernet autoselect (1000baseTX ) > > > > status: active > > > > > > > > 1 - is there a man page for nfe anywhere? > > > > > > Closest thing I can find would be the manpage from -CURRENT's nfe(4), > > > which is supposedly the same code. > > > > > > > http://www.freebsd.org/cgi/man.cgi?query=nfe&apropos=0&sektion=0&manpath=FreeBSD+7-current&format=html > > > > > > > 2 - does it support hardware checksum I remember reading it does but > > > > from ifconfig output it appears to not be in use so if it does support > > > > it how do I enable it? > > > > > > It does support it, but I don't know the circumstances surrounding when > > > it gets enabled. That is to say, it's known that some versions of the > > > chip (and/or associated PHY) have bugs, so possibly hardware checksum > > > offloading is known to be broken on the system you're on. Taken from my > > > 7-CURRENT box at home (Asus A8N-E, nForce 4-based): > > > > > > nfe0: flags=8843 metric 0 mtu > 1500 > > >options=10b > > >ether 00:15:f2:17:30:e9 > > >inet 192.168.1.51 netmask 0xff00 broadcast 192.168.1.255 > > >media: Ethernet 1000baseTX > > >status: active > > > > > > I do not explicitly specify rxcsum or txcsum in my rc.conf ifconfig > > > line. > > > > > > > 3 - same with TOS? > > > > > > TOS (type-of-service) or TSO? If TSO, see above ifconfig. > > > > > > > 4 - how do I enable jumbo frames if it supports it? > > > > > > You should take a bit more itme to read the webpage you obtained the > > > driver from. I see these on the page: > > > > > > 2007/01/06 Added jumbo frame support. [...] Fixed a bug to handle > > >Tx/Rx checksum offload settings with ifconfig. > > > 2006/08/11 Added support for jumbo frame capability. > > > > > > yongari@ (Pyun YongHyeon) should be able to provide additional help > > > with both. > > > > > > > 5 - is it safe to use with zero copy sockets? > > > > > > No idea. > > > > > > > 6 - I currently have both net.isr.direct and mpsafenet disabled is > > > > this driver safe to use on them? > > > > > > No idea. > > > > > > -- > > > | Jeremy Chadwickjdc at parodius.com > | > > > | Parodius Networking http://www.parodius.com/ > | > > > | UNIX Systems Administrator Mountain View, CA, USA > | > > > | Making life hard for others since 1977. PGP: 4BD6C0CB > | > > > > > > > > > > Thanks yes I meant TSO sorry, I would guess with the checksum either > > the 6.x driver is older and not fully implemented yet, the 6.x driver > > does need more patches for certian chipsets so would indicate its > > older then the CURRENT driver. Or as you said my chipset is known to > > be unstable with the hardware checksums. > > > > See the other mail I've posted. > > > The card is more stable when using nve driver no crashes still but the > > performance is around the same maxing out at around 200mbit. I was > > expecting nearer 400-500mbit. > > > > e1000phy0: on miibus0 > > > > There had been issues nfe(4) with 88E1116/88E1149 PHYs but your issue > seems to be different one. How about manually set media configuration? > For example, "ifconfig nfe0 media 1000baseTX mediaopt full-duplex" > > > Is the line from dmesg, I believe in CURRENT mpsafe is always on > > regardless so if you have no problems then its a good sign and I will > > reenable mpsafe networking (default). > > > > Thanks really appreciated. > > > > Chris > -- > Regards, > Pyun YongHyeon > I typod I meant to say nve was unstable and nfe has been rock solid so great work with the driver. I enabled mpsafe now and still no problems and its gave me a little more performance as well, a shame my nic has no hardware features (unusual for a gigabit nic) but overall glad its at least stable. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gbde and geli on 6.2
On 27/09/2007, Roland Smith <[EMAIL PROTECTED]> wrote: > On Wed, Sep 26, 2007 at 11:09:22PM +0100, Chris wrote: > > Hi I am concerned about the availabilities of these encryptions in > > freebsd releases that are marked stable. > > > > It seems gbde has a problem when the the data written goes over the > > lba boundary around lba48. > > > > http://lists.freebsd.org/pipermail/freebsd-geom/2007-August/002524.html > > > > I suffered this problem error example below. Usage at the time was > > approx 150gig when I first noticed it. > > > > g_vfs_done():ad6s1c.bde[WRITE(offset=493964558336, length=131072)]error = 1 > > > > After reading about this problem on a few diff hits (all with no > > response on fixes) I tried geli. > > > > However I seen this in geli within an hour of using it. > > > > GEOM_ELI: Crypto WRITE request failed (error=1). > > ad6s1c.eli[WRITE(offset=0, length=131072)] > > I've been running a GELI encrypted /home partition on 6.2-STABLE amd64 > for months without problems. I've had trouble with GELI on usb > harddisks, but that seems to be related to the USB/ATAPI controller. > > The message seems to come from /usr/src/sys/geom/eli/g_eli_integrity.c, > in the function g_eli_auth_write_done. But for a more detailed analysys, > you'd have to set kern.geom.eli.debug to 3, and see what else pops > up. The headers indicate that the error number is used according to > errno.h, which lists 1 as being "Operation not permitted". > > Both GELI and GBDE fail with the same length of request. So the error > might depend on the underlaying code in the kernel (bio* functions). > > Are you sure that the disk and controller are working properly? > > Roland > -- > R.F.Smith http://www.xs4all.nl/~rsmith/ > [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] > pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) > > As I said no dma errors or any hd related errors of any sort with encyrption turned off. How big are your drives? Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gbde and geli on 6.2
On 27/09/2007, Roland Smith <[EMAIL PROTECTED]> wrote: > On Thu, Sep 27, 2007 at 07:35:28PM +0100, Chris wrote: > > > > However I seen this in geli within an hour of using it. > > > > > > > > GEOM_ELI: Crypto WRITE request failed (error=1). > > > > ad6s1c.eli[WRITE(offset=0, length=131072)] > > > > > > I've been running a GELI encrypted /home partition on 6.2-STABLE amd64 > > > for months without problems. I've had trouble with GELI on usb > > > harddisks, but that seems to be related to the USB/ATAPI controller. > > > As I said no dma errors or any hd related errors of any sort with > > encyrption turned off. How big are your drives? > > I have two 160GB SATA150 drives in a mirrored configuration (VIA Tech > V-RAID RAID1). The encrypted partition is 120GB. > > Roland > -- > R.F.Smith http://www.xs4all.nl/~rsmith/ > [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] > pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) > > In that case the partition is too small if the problem is what we think it is. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfe driver 6.2 stable
On 28/09/2007, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > On Thu, Sep 27, 2007 at 06:30:20PM +0100, Chris wrote: > > On 27/09/2007, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > > > On Mon, Sep 24, 2007 at 04:44:09PM +0100, Chris wrote: > > [...] > > > > > > > The card is more stable when using nve driver no crashes still but the > > > > performance is around the same maxing out at around 200mbit. I was > > > > expecting nearer 400-500mbit. > > > > > > > > e1000phy0: on miibus0 > > > > > > > > > > There had been issues nfe(4) with 88E1116/88E1149 PHYs but your issue > > > seems to be different one. How about manually set media configuration? > > > For example, "ifconfig nfe0 media 1000baseTX mediaopt full-duplex" > > > > > [...] > > > > > I typod I meant to say nve was unstable and nfe has been rock solid so > > great work with the driver. I enabled mpsafe now and still no > > problems and its gave me a little more performance as well, a shame my > > nic has no hardware features (unusual for a gigabit nic) but overall > > glad its at least stable. > > > > How did you check network performance? > Maxing out at around 200Mbps seems weird. Personally, I had never seen > GigE hardwares that saturate at 200Mbps. One of causes I can think of > is speed/duplex mismatches with link partner. Manually setting > speed/duplex might fix your performance issue, I guess. > > -- > Regards, > Pyun YongHyeon > These are ftp transfers it is running on a amd62 x2 dual core processor and gig of ram, when at max speed cpu usage is very high in excess of 80% but not completely maxed out. It now seems to be able to sustain around 30meg/sec the highest I have seen I havent done any other testing so if you have a better way it would be good to know thanks. Please bare in mind I have no local access to the server so crashing it eg. is expensive for as will have to pay for a kvm switch netstat -i indicates no collisions for a duplex mismatch so not keen on trying a manual negotiotian again for reasons above. So even for a card with no hardware features you would expect it to exceed 200mbit easily? I havent enabled net isr setting I wonder if that will help. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfe driver 6.2 stable
On 29/09/2007, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > On Fri, Sep 28, 2007 at 07:05:35PM +0100, Chris wrote: > > On 28/09/2007, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > > > On Thu, Sep 27, 2007 at 06:30:20PM +0100, Chris wrote: > > > > On 27/09/2007, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > > > > > On Mon, Sep 24, 2007 at 04:44:09PM +0100, Chris wrote: > > > > > > [...] > > > > > > > > > > > The card is more stable when using nve driver no crashes still > but the > > > > > > performance is around the same maxing out at around 200mbit. I > was > > > > > > expecting nearer 400-500mbit. > > > > > > > > > > > > e1000phy0: on miibus0 > > > > > > > > > > > > > > > > There had been issues nfe(4) with 88E1116/88E1149 PHYs but your > issue > > > > > seems to be different one. How about manually set media > configuration? > > > > > For example, "ifconfig nfe0 media 1000baseTX mediaopt full-duplex" > > > > > > > > > > > [...] > > > > > > > > > > > I typod I meant to say nve was unstable and nfe has been rock solid so > > > > great work with the driver. I enabled mpsafe now and still no > > > > problems and its gave me a little more performance as well, a shame my > > > > nic has no hardware features (unusual for a gigabit nic) but overall > > > > glad its at least stable. > > > > > > > > > > How did you check network performance? > > > Maxing out at around 200Mbps seems weird. Personally, I had never seen > > > GigE hardwares that saturate at 200Mbps. One of causes I can think of > > > is speed/duplex mismatches with link partner. Manually setting > > > speed/duplex might fix your performance issue, I guess. > > > > > > -- > > > Regards, > > > Pyun YongHyeon > > > > > > > These are ftp transfers it is running on a amd62 x2 dual core > > processor and gig of ram, when at max speed cpu usage is very high in > > excess of 80% but not completely maxed out. It now seems to be able > > to sustain around 30meg/sec the highest I have seen I havent done any > > other testing so if you have a better way it would be good to know > > ftp transfers involve disk activities so you're not measuring NIC > performance. Try one of benchmark programs in ports/benchmarks > (e.g. netperf, iperf, ttcp etc). > ATM nfe(4)'s interrupt moderation mechanism doesn't seem to work > at all so nfe(4) generates too many interrupts. However I don't > think it wouldn't be major bottleneck of the performance. > > > thanks. Please bare in mind I have no local access to the server so > > crashing it eg. is expensive for as will have to pay for a kvm switch > > netstat -i indicates no collisions for a duplex mismatch so not keen > > on trying a manual negotiotian again for reasons above. So even for a > > card with no hardware features you would expect it to exceed 200mbit > > easily? > > > > Yes. You have a gigabit ethernet controller and fast CPU. > Run one of benchmark programs and get a number. > > > I havent enabled net isr setting I wonder if that will help. > > > > That wouldn't help a lot, I guess. > > > Chris > > -- > Regards, > Pyun YongHyeon > Will let you know results thanks, also will polling work on my card? Chris ___ 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.3 or FreeBSD 7.0
On 16/11/2007, S.N.Grigoriev <[EMAIL PROTECTED]> wrote: > > Thu, 15 Nov 2007 22:31:19 + (GMT) > Robert Watson <[EMAIL PROTECTED]> wrote: > > > I feel that the 7.0 kernel will prove to be one of our most stable, > > not to mention most performant, .0 releases to date. > > Unfortunately, that's not true. For example, parallel printing > crashes my amd64 system since the beginning of May. I've posted > PR (kern/116669) which is still open. Some other people have > reported about similar problems. > > To my mind it's a stopper defect for 7.0 because parallel > printing is one of the basic computer tasks. FreeBSD was one > of the best print servers for years. But at present it cannot > be used in such a role (at least on amd64). > > Regards, > Serguey. > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > Without a doubt I have to say the old saying applies dont try to fix what isnt broke, so goto 6.3 and by the time that is EOL then 7.x should be matured and a 7.1 release will exist which I have no doubt will have fixed bugs that we dont know about now. 6.0 was the same story we were all urged to upgrade our servers to it and for many people was fine but of course there was unforseen problems that had to be fixed in 6.1 and 6.2 it is a catch 22 it needs wider scale usage for problems to be found but people wont necessarily move their servers over willingly as the risk of things breaking is too high. I have a hobby server on 7.0 beta 3 but all my web servers are staying on 6.x for the forseeable future unless I have a good reason to move to 7 even taking into account the work that has gone into improving mysql performance. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any hope for nfe/msk?
ime=32923.814 ms > > 64 bytes from 10.1.1.254: icmp_seq=4 ttl=64 time=31922.833 ms > > 64 bytes from 10.1.1.254: icmp_seq=5 ttl=64 time=30921.878 ms > > 64 bytes from 10.1.1.254: icmp_seq=6 ttl=64 time=29920.923 ms > > 64 bytes from 10.1.1.254: icmp_seq=7 ttl=64 time=28919.960 ms > > 64 bytes from 10.1.1.254: icmp_seq=8 ttl=64 time=27919.009 ms > > 64 bytes from 10.1.1.254: icmp_seq=9 ttl=64 time=26918.042 ms > > 64 bytes from 10.1.1.254: icmp_seq=10 ttl=64 time=25917.078 ms > > 64 bytes from 10.1.1.254: icmp_seq=11 ttl=64 time=24916.115 ms > > 64 bytes from 10.1.1.254: icmp_seq=12 ttl=64 time=23915.144 ms > > 64 bytes from 10.1.1.254: icmp_seq=13 ttl=64 time=22914.192 ms > > 64 bytes from 10.1.1.254: icmp_seq=14 ttl=64 time=21913.214 ms > > 64 bytes from 10.1.1.254: icmp_seq=15 ttl=64 time=20912.278 ms > > 64 bytes from 10.1.1.254: icmp_seq=16 ttl=64 time=19911.330 ms > > 64 bytes from 10.1.1.254: icmp_seq=17 ttl=64 time=18910.375 ms > > 64 bytes from 10.1.1.254: icmp_seq=18 ttl=64 time=17909.419 ms > > 64 bytes from 10.1.1.254: icmp_seq=19 ttl=64 time=16853.821 ms > > 64 bytes from 10.1.1.254: icmp_seq=20 ttl=64 time=15854.710 ms > > 64 bytes from 10.1.1.254: icmp_seq=21 ttl=64 time=14701.312 ms > > 64 bytes from 10.1.1.254: icmp_seq=22 ttl=64 time=13701.003 ms > > 64 bytes from 10.1.1.254: icmp_seq=23 ttl=64 time=12700.052 ms > > 64 bytes from 10.1.1.254: icmp_seq=24 ttl=64 time=11699.098 ms > > 64 bytes from 10.1.1.254: icmp_seq=25 ttl=64 time=10698.148 ms > > 64 bytes from 10.1.1.254: icmp_seq=36 ttl=64 time=0.463 ms > > 64 bytes from 10.1.1.254: icmp_seq=37 ttl=64 time=0.379 ms > > > > -- > Regards, > Pyun YongHyeon > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > I started having problems on nfe driver now I was using on 6.2 stable and I had polling enabled, the entire system was lagging and even when idle. I have no upgraded the box in question to 7.0 beta 3 and keeping the nfe driver on. irq22: nfe0 ehci01652548 20 It hasnt had heavy load since the upgrade yet. ehci0: I have no local access so cannot disable usb in the bios, if I do a new kernel disabling ehci in the kernel config will this stop the interrupt sharing and allow me to use nfe reasonably without polling as I think polling itself has been causing me problems (i use nfs). Is nfe still getting development as these are existing problems that are known but there has been no update to the below page for a while now so I am curious if its dead in the water now. http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Benchmarks results for FreeBSD 11
On 29 August 2016 at 09:30, Fernando Herrero Carrón wrote: > 2016-08-29 3:04 GMT+02:00 K. Macy : > >> > I'm writing from my cellphone away from my computer, so take this with a >> > grain of salt: >> > >> > -L/usr/local/llvm38/lib >> >> You're missing the point. If your webserver crashes every other day, >> the fact that you can run a batch job to restart it doesn't make it >> OK. >> >> > Fair enough, I misunderstood the point as "clang, even from ports, cannot > do omp at all [from a shell]". > > >> [...] Requiring additional tweaking to build on FreeBSD >> or requiring users to install gcc is kind of underwhelming. >> > > Isn't that precisely what the ports infrastructure is supposed to do? What > about compiler.mk? If it can provide an extra library-dirs argument to the > port's configure then we're not that bad. And still I agree, this is far > from an ideal situation, and we speaking about finding a library, we have > still not touched having clang use the LLVM linker... > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" I have not looked at the article yet. but yes if one compiles FreeBSD ports using a default make.conf (empty file) then the ports will not be built optimised. I dont go all out on optimisation like some people do but I consider basic optimisation to be a modern version of gcc combined with the cpu native flag. Which will auto detect the processor used and add the right flags correctly. I dont fiddle with -O2 -O3 etc. However there is a flipside to this on performance, ubuntu packages by default are now built with PIE, BIND_NOW, SMACK, RELRO etc. These will all slow down performance but are modern expected hardening. FreeBSD I think still does not do this by default? and as such ubuntu is managing to beat FreeBSD whilst also adding exploit mitigations which is impressive. It is a real shame the default ports compile and base has not been looked into but instead it all has been kept on conservative approach which is no exploit protection and to compile for the lowest denominator like a 486 cpu. Hardened bsd has done some good work on this but I see they were forced to fork away because their changes were rejected on the base system. As a final note I assumed clang no longer has a noticeable disadvantage vs gcc, if it does then that's bad news for the base files. If I Am wrong on the above please feel free to correct me. Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
named rc.d
Apologies if posted to wrong list, the rc.d script for named chowns /etc/namedb to root:wheel if set to bind:bind why is this? A slave named server running as bind user cannot download new slave zones if dir ownership is root or update it if file ownerships are root which I sometimes see. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: named rc.d
On 02/08/06, Mark Andrews <[EMAIL PROTECTED]> wrote: > Apologies if posted to wrong list, the rc.d script for named chowns > /etc/namedb to root:wheel if set to bind:bind why is this? A slave > named server running as bind user cannot download new slave zones if > dir ownership is root or update it if file ownerships are root which I > sometimes see. Use /etc/namedb/slave for slave zone. Use /etc/namedb/dynamic for dynamic zone. Mark # $FreeBSD: src/etc/mtree/BIND.chroot.dist,v 1.6 2004/11/04 05:24:29 gshapiro Exp $ # # Please see the file src/etc/mtree/README before making changes to this file. # /set type=dir uname=root gname=wheel mode=0755 . dev mode=0555 .. etc namedb dynamic uname=bind .. master .. slave uname=bind .. .. .. /set type=dir uname=bind gname=wheel mode=0755 var uname=root dump .. log .. run named .. .. stats .. .. .. > Chris > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] thanks to all, I see now. So using the subdir is the correct way. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nfs/geli stability problems and file corruption
Hi on 3 different servers we had the same pronlem as below. 2 servers 6.1-STABLE and one 6.1-RELEASE security branch. 2 of the servers before hand were running without nfs and geli for months stable, the 3rd was brand new. We enabled geli encryption on loopback partitions and real partitions to encrypt our data, we then mounted some nfs mounts fro debian servers. Things would run well for anything from a few days to a few weeks. Then the server stops responding. We reboot the server and it fails to boot with an error /etc/fstab unable to mount filesystem. The local tech was unable to proceed from there so the boxes were formatted and data lost. On one of the servers before it died I did notice nfs stale errors. What has got me curious is (a) whats causing the crashes or network hang since the boxes may well have still been responding locally and (b) what was causing the filesystems not mounting upon reboot. The hardware is not the cause I am talking about 3 different servers 2 of which were running fine for months nad have ran fine since debian has been put on. The first 2 servers arent mine and the owners had enough of the problems, the 3rd server been mine I want to find a solution to run it on freebsd, I have to pay for reformats so ideally dont want to do trial and error and having to pay for a reinstall every time. I did some googling and it appears nfs on freebsd has its problems, I have seen PRs sent for nfs not answered and some documents regarding freebsd nfs having problems with other OS's nfs. The crashes arent so bad the killer is the unable to mount on the following reboot, could geli be causing this since this is relatvely new, whilst gdbe is more established. Can gdbe be used on loopback filesystems? Thanks Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance 4.x vs. 6.x
On 16/10/06, Mark Kirkwood <[EMAIL PROTECTED]> wrote: Mark Linimon wrote: > On Sun, Oct 15, 2006 at 02:01:08PM -0400, Michael Butler wrote: >> For everyone's benefit then, please feel free to submit your patches >> along with your technical analysis. > > I think his best bet is a fork, instead. Then he can tell all the people > that volunteer to work on _his_ project exactly what to do, and see how > far he gets with that approach. > > He might have got further by volunteering to create and supply profiles for those specific workloads that were faster in 4.x than 6.x on UP machinery etc... i.e. help make 6.x better rather than discourage the development team (whose efforts are much appreciated by the rest of us that are happily using 6.x...) regards Mark ___ I recently ordered some servers from a datacentre on lease, specs were UP p4 2.8ghz gig of ddr2 ram and sata hd, intel lan card. None of the servers would boot in freebsd 6.x, they booted in freebsd 4.x but needed a pata controller, they only worked properly in freebsd 5.x. It seems their are 2 major problems with freebsd at the moment (1) is the hardware support is still way behind both linux and windows and its very frustrating in the amount of datacentres that dont support freebsd. and (2) the uniprocessor performance remains below par. The freebsd team it would help to realise not everyone can pick and choose their hardware and not everyone has the budget for state of the art hardware, certianly if you go around browsing datacentre websites for dedicated servers the dominant spec is x86 single processor, dual cpu is growing but still not dominent and I think 32bit UP wont be dead for at least half a decade. freebsd 4.x their is nothing to dispute, its leaner and smoother on pretty much every UP setup and I think it would do freebsd's reputation some good if a 4.12 was to come about. just my 2 pence worth. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
128 Bucket Free Count
I asked this question of Freebsd questions yesterday but realize it probably needs to go to this list. I have a Tyan S4882 quad opteron with 8GB RAM on 6.2 PR running a healthy load of webserver traffic. This machine is hanging occasionally (it was able to make 4 days this time we put it in, we are on day 5 of the second round). I've been through the hardware repeatedly since march when we bought it and at this point I don't think we have a hardware problem. Memory has been replaced and I went to 6.2 to pick up bge driver changes. I have it set up to dump if the problem occurs again and if we get a dump I'll certainly chase that as best as I can. Never done that process before so I have my doubts that I know what I'm doing. Taking another tack, I started dumping vmstat -z to another server every 2 minutes looking at the counters plus noting differences between when the system booted and current along with difference between last and current sample. I put in checks to determine anything that exceeded a 25% jump or drop in stats for any of the vm parameters. That turned out to be meaningless because approximately half make such jumps every cycle. I put in one additional check which was to look for anything that showed frequent changes yet had a Free Count that would go to zero often. I found that the stat called 128 Bucket gradually dropped down from a starting point of about 600 to 0 where it hovers between 0, 1 and 2 even as the used count gradually grows. Oddly at 12 midnight on Sunday, it totally freed up and popped back up above 500. One of the weekly cron cleanups? Does the sampling I'm doing have validity and what is a 128 Bucket? Coincidentally, yesterday people on the "questions" list discussed the 6.2 PR todo page. When I looked at it, I noted a panic related to 128 Bucket (the only reference on the net). The problem is I'm not getting a panic I don't think. But... I have to remotely cycle power to restart it because it started failing to reboot when I supped to 6.2. So I'm not really sure what is happening because I can't see the console. I set the acpi*reboot to 1 so I'm hoping that problem will disappear on the next failure. I also only allocated 8GB of swap so perhaps I've inhibited crashing correctly. Is it possible I'm seeing a related problem to the 128 Bucket Panic issue? Is it normal for 128 Bucket to sit at 0, 1, or 2 for a free count and only be reset on Sunday night at 12:00 midnight? Thank you, Chris Pratt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sshfs/nfs cause server lockup
400-0xc403,0xc080-0xc08f mem 0xdfe7c000-0xdfe7cfff irq 21 at device 8.1 on pci0 ata4: on atapci2 ata5: on atapci2 pcib2: at device 9.0 on pci0 pci2: on pcib2 pcib3: at device 11.0 on pci0 pci3: on pcib3 pcib4: at device 12.0 on pci0 pci4: on pcib4 pci0: at device 13.0 (no driver attached) acpi_button0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter "TSC" frequency 2410945801 Hz quality 800 Timecounters tick every 1.000 msec ad4: 238475MB at ata2-master UDMA33 Trying to mount root from ufs:/dev/ad4s1a Regards Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
