Re: Upcoming ABI Breakage in RELENG_7
On Tue, Jul 29, 2008 at 10:45 AM, Ken Smith <[EMAIL PROTECTED]> wrote: > > Normally the FreeBSD Project tries very hard to avoid ABI breakage in > "Stable Branches". However occasionally the fix for a bug can not be > implemented without ABI breakage, and it is decided that the fix > warrants the impact of the ABI breakage. We have one of those > situations coming along for RELENG_7 (what will become FreeBSD 7.1). > The ABI breakage should only impact kernel modules that are not part of > the baseline system (those will be patched by the MFC) which deal with > advisory locks. As such the impact should not cause many people > problems. > > The work that will be MFCed fixes issues with filesystem advisory locks, > and moves the advisory locks list from filesystem-private data > structures into the vnode structure. > > The MFC will be done by Kostantin Belousov some time this coming Friday > (August 1st, 2008) if you have concerns and want to watch for it. > Just updated to 7-STABLE last night and found that Truecrypt (which uses a combination of fuse and mdconfig to mount its encrypted volumes) is now completely unable to mount its encrypted volumes. I've rebuilt fusefs-kmod and fusefs-libs as well as Truecrypt to no avail. As Truecrypt is implementing an encrypted file system, I am assuming at this point that the kernel ABI breakage may be what is causing this new problem. Are the any calls in particular that I should be looking for in the Truecrypt code to see where it might be choking on the new kernel ABI? I've briefly reviewed some of the changes in r181119 but lack the experience to discern anything useful from them. I'd like to file an issue with the Truecrypt devs if I can get an idea of where the breakage might be. Thanks, Matt > Thanks. > > -- >Ken Smith > - From there to here, from here to | [EMAIL PROTECTED] > there, funny things are everywhere. | > - Theodore Geisel | > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming ABI Breakage in RELENG_7
On Tue, Aug 5, 2008 at 5:09 PM, Doug Barton <[EMAIL PROTECTED]> wrote: > Matt wrote: >> >> Just updated to 7-STABLE last night and found that Truecrypt (which >> uses a combination of fuse and mdconfig to mount its encrypted >> volumes) is now completely unable to mount its encrypted volumes. >> I've rebuilt fusefs-kmod and fusefs-libs as well as Truecrypt to no >> avail. > > Silly question, but did you build AND install both a new world AND a new > kernel before you rebuilt your ports? > Yes - full, clean (deleted /usr/obj/* before build) build on world + kernel. I've run it through a couple ktrace runs looking for obvious problems, but haven't found anything that I can interpret yet. It appears the failures are triggering around some file-descriptor errors, but nothing that makes any sense yet. I'll look at things a little closer when I get some more time - need to boot into a backup copy of the 7-RELEASE system to get some baselines. Matt > Doug > > -- > >This .signature sanitized for your protection > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with portupgrade
On 3/2/07, Michael Proto <[EMAIL PROTECTED]> wrote: Phillip Ledger wrote: > i have been trying to get portupgrade working, however everything i try > to run it im getting an error with the portsdb. now i have tryed to > rebuild it as requested initaly by portupgrade but im still getting an > error > > portupgrade -aRr > [missing key: categories] [Updating the portsdb in > /var/tmp ... - 16413 port entries found > .1000.2000.3000.4000.5000.6000.7000.8000.9000.1.11000.12000.13000.14000.15000.16000 > . done] > missing key: categories: Cannot read the portsdb! > /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:548:in `open_db': database > file error (PortsDB::DBError) >from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:702:in `port' >from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:890:in > `all_depends_list' >from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:809:in `tsort_build' >from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:801:in `each' >from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:801:in `tsort_build' >from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:823:in `sort_build' >from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:827:in `sort_build!' >from /usr/local/sbin/portupgrade:721:in `main' >from /usr/local/lib/ruby/1.8/optparse.rb:755:in `initialize' >from /usr/local/sbin/portupgrade:220:in `new' >from /usr/local/sbin/portupgrade:220:in `main' >from /usr/local/sbin/portupgrade:2084 > > > any idea whats causeing the issue or how to fix it? Try removing /usr/ports/INDEX-6.db and running "portsdb -u", which should rebuild it from your existing /usr/ports/INDEX-6 file. (if you're using FreeBSD 5 it would be INDEX-5 above). -Proto ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" From /usr/ports/UPDATING: 20070102: AFFECTS: users of sysutils/portupgrade AUTHOR: [EMAIL PROTECTED] If you have a problem with upgrading the tools from version 2.2.1 and less, remove the package with pkg_delete portupgrade\* command and reinstall it from scratch. Remove /usr/ports/INDEX*.db and run portsdb -u. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding athlon xp to bsd.cpu.mk
any one know if my 4.3 stable work with all AMD processors, as well as with SMP enabled? == WWW.XGFORCE.COM The Next Generation Load Balance and Fail Safe Server Clustering Software for the Internet. == - Original Message - From: "David O'Brien" <[EMAIL PROTECTED]> To: "cameron grant" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, October 28, 2001 4:42 PM Subject: Re: adding athlon xp to bsd.cpu.mk > On Sun, Oct 28, 2001 at 02:06:00PM -, cameron grant wrote: > > my system with dual 1.1ghz durons identifies as: > > > > CPU: AMD Duron(tm) MP Processor (1110.94-MHz 686-class CPU) > > Origin = "AuthenticAMD" Id = 0x670 Stepping = 0 > > > > Features=0x383fbff > CMOV,PAT,PSE36,MMX,FXSR,SSE> > > AMD Features=0xc044<,AMIE,DSP,3DNow!> > > > > the entire "AMD Duron(tm) MP Processor" string appears to originate > > Wonder why you get the 'MP' and I don't: > > CPU: AMD Athlon(tm) Processor (1194.46-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x661 Stepping = 1 > Features=0x383fbff > AMD Features=0xc044<,AMIE,DSP,3DNow!> > > This is from my AMD pre-release Tyan Thunder Athon MP system that I > certified FreeBSD SMP support on. > > -- > -- David ([EMAIL PROTECTED]) > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: 4.9R bug fix ?
Oldach, Helge said: > > But unfortunately it breaks code that parses the output of netstat and > relies on a fixed format, for instance phpsysinfo. I would suggest to > re-work the patch and turn "vlan10" into "vla10" to maintain the existing > format. Although phpsysinfo is broken on freebsd 5.x already. It's network counters don't work and show odd values (at least on the last version I tried which was about 2 months ago). I do not have any 4.x boxes to check but I assume that the netstat output is different already between these two. Matt. -- email: [EMAIL PROTECTED] - web: http://xtaz.co.uk/ Hardware, n.: The parts of a computer system that can be kicked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Active List ??
Is the list active, or am I just not getting messages yet? Regards, Matt --- Outgoing mail is certified Virus Free. Regards, Matt Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.677 / Virus Database: 439 - Release Date: 5/4/2004 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
build world in 4.9 ?
Thanks for the replies to my "Is The List Active Post" Ingrid and Liam. I've got an AMD K6-2 500 with FreeBSD 4.9 and a CMD ATA 100 (Siig) Controller installed and 256MB SD100 RAM with a 40GB UDMA 100 HDD. I went to BSD because RHat 9 would not recognize the drives attached to my Siig or my Highpoint ATA controllers as ATA/UDMA 100 without doing major surgery, the board is a FIC 503+ and only provides ATA/UDMA 33. I'm in the process of running "buildworld" after updating my src/ports and have customized a Kernel for the Processor prior to my *buildworld* attempt. Question: Does anybody have any idea how long it might take to finish *buildworld* on this system, been going for about 3hrs now. Regards, Matt --- Outgoing mail is certified Virus Free. Regards, Matt Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.677 / Virus Database: 439 - Release Date: 5/4/2004 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Quotas.
Greetings,
I have two questions now, testing some theories with an odd problem of
mine; A) Is it possible that quota would mishandle a 9.3 GB partition?
B) Is it possible that a minor/major problem with a hard drive would cause
quota but nothing else to 'freak out'? For reference, the machine is
FreeBSD 3.2-Stable as of August 6th, the hard drive is a 13 GB Quantum
Fireball, IDE.
Thanks,
Matt
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
RE: Quotas.
On Tue, 17 Aug 1999, Christopher Michaels wrote: : I suppose anything is possible. I don't think it's likely. I have quota : running on a 21GB /usr partition w/o any trouble what so ever. I thought just as much, I was mainly grasping at any possible contributing cause. : It might help if you sent the actual problem you are having back to the : mailing list. I wanted to avoid this a bit more until I could get my mind clear about what the actual 'real' problem is, but I'm out of ideas now; unless the hard drive is screwed up. Problem is as follows, with some background information. I have two "almost" twin machines; Both are running 3.2-Stable as of August 6th, they were cvsup'd within an hour of each other. They have identical hardware and identical kernels, with the exception of hard drives. The functional machine has a 8.3G Western Digital HD, whereas the non-functional(now that is) one has a 13.6G Quantum Fireball. (Both IDE) However, adding quota's on the "non-functional" machine half locks the machine within 2 minutes of adding them -- Telnet, SSH, Qmail, POP3, Bind, all lock and disallow any connections or logins, but the IRCd on the machine and my bnc run fine and accept connections. This problem is "solved" by a hard reboot as long as check_quotas=YES isn't in the rc.conf. (It won't allow console logins either) On the "functional" machine, quotas work flawlessly, no problems whatsoever, I have tested this in about as many ways as I can think of. So I'm lead to believe that this is not a quota or FreeBSD related problem, except for the fact that on one machine quota locks it up every single time without fail. Unfortunately, the machines are in two different locations, so I'm lacking the ability to test the hard drive of the "non-functional" machine for now. I have the feeling now, that this is a hard drive problem -- However, before I go out and get another HD to replace it with, I am asking opinions on the list =) Any help is much appreciated, the machine IS a mission critical machine and quotas MUST be there, this is not an option unfortunately. : -Chris [quoted email snipped] Thanks for any help or theories, Matt -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
3.3-STABLE problem sorta related to flashplugin
Hi, while trying to install the flash plugin in the ports tree, I did what the missing lib message told me to do which was: 1. extract /usr/src/lib (distribution files: src/slib.??) 2. cd /usr/src/lib/csu/i386 3. make clean depend 4. make all install so I cd to /usr/src/lib/csu/i386, make clean depend which outputs this: root[s02]:/usr/src/lib/csu/i386# make clean depend rm -f a.out crt0.o.tmp c++rt0.o.tmp gcrt0.o.tmp scrt0.o.tmp sgcrt0.o.tmp crt0.o c++rt0.o gcrt0.o scrt0.o sgcrt0.o then I go to make all which outputs this: root[s02]:/usr/src/lib/csu/i386# make all cc -O -pipe -DLIBC_SCCS -fno-omit-frame-pointer -c -DCRT0 -DDYNAMIC /usr/src/lib/csu/i386/crt0.c -o crt0.o /usr/src/lib/csu/i386/crt0.c: In function `__do_dynamic_link': /usr/src/lib/csu/i386/crt0.c:196: storage size of `crt' isn't known /usr/src/lib/csu/i386/crt0.c:260: `CRT_VERSION_BSD_5' undeclared (first use this function) /usr/src/lib/csu/i386/crt0.c:260: (Each undeclared identifier is reported only once /usr/src/lib/csu/i386/crt0.c:260: for each function it appears in.) /usr/src/lib/csu/i386/crt0.c:264: `CRT_VERSION_BSD_4' undeclared (first use this function) /usr/src/lib/csu/i386/crt0.c:268: `CRT_VERSION_BSD_3' undeclared (first use this function) /usr/src/lib/csu/i386/crt0.c:269: invalid use of undefined type `struct _dynamic' /usr/src/lib/csu/i386/crt0.c:275: dereferencing pointer to incomplete type /usr/src/lib/csu/i386/crt0.c:288: `LDSO_VERSION_HAS_DLEXIT' undeclared (first use this function) /usr/src/lib/csu/i386/crt0.c:289: dereferencing pointer to incomplete type *** Error code 1 Stop. This is on 3.3-STABLE cvsupped on October 15th. Is there something I am missing here, or is this simply defunct? Or am I just missing the magic trick to make this work. Please advise, Thank you. -Matt -- "If the primates that we came from had known that someday politicians would come out of the...the gene pool, they'd a stayed up in the trees and written evolution off as a bad idea. Hell, I always thought the opposable thumb was overrated." -Sheridan, "A Distant Star" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
whois patch.
I agree that a wrapper is the more 'practical' answer, however this was something I would love to see done by default. To hear of -current's whois solution, it's much better than mine. I'm glad to see I wasn't the only one thinking along the lines of whois being too narrow minded. Sorry for the mail this has generated, had I know it was something already done in -current, I never would have done anything, but I don't track -current, so I didn't know. Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
-Stable on a Toshiba.
Hi, This is a bit off the normal discussion here, but I've been laptop shopping, and have my mind rather liking the Toshiba 2610DVD, I've been wondering what my odds are on getting fbsd -stable to run on the thing. Has anyone had any exp. with this particular laptop? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
PCIe SATA HBA for ZFS on -STABLE
I'm not on the -STABLE list so please reply to me. I'm using an Intel Core i3-530 on a Gigabyte H55M-D2H motherboard with 8 x 2TB drives & 2 x 1TB drives. The plan is to have the 1 TB drives in a zmirror and the 8 in a raidz2. Now the Intel chipset has only 6 on board SATA II ports so ideally I'm looking for a non RAID SATA II HBA to give me 6 extra ports (4 min). Why 6 extra ? Well the case I'm using has 2 x eSATA ports so 6 would be ideal, 5 OK, and 4 the minimum I need to do the job. So... What do people recommend for 8-STABLE as a PCIe SATA II HBA for someone using ZFS ? Not wanting to break the bank. Not interested in SATA III 6GB at this time... though it could be useful if I add an SSD for... (is it ZIL ?). Can this be added at any time ? The main issue is I need at least 10 ports total for all existing drives... ZIL would require 11 so ideally we are talking a 6 port HBA. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PCIe SATA HBA for ZFS on -STABLE
On 1 June 2011 17:37, Jeremy Chadwick wrote: > On Wed, Jun 01, 2011 at 02:34:55PM +0800, TJ Varghese wrote: > > On Tue, May 31, 2011 at 10:31 PM, Freddie Cash > wrote: > [snip] > > > SuperMicro AOC-USAS2-L8i works exceptionally well. These are 8-port > HBAs > > > using the LSI1068 chipset, supported by the mpt(4) driver. Support 3 > Gpbs > > > SATA/SAS, using multi-lane cables (2 connectors on the card, each > connector > > > supports 4 SATA ports), hot-plug, hot-swap. > > > > > > > > The USAS2 (6Gbps) is supported by the mps driver (on -CURRENT, not sure > if > > it's in 8-STABLE yet). Perhaps you're referring to the earlier USAS which > > does 3Gbps and is supported by the mpt driver. > > Folks considering use of mps(4), which was committed to RELENG_8 roughly > around 2011/02/18 (thus is not in 8.2-RELEASE), should read the below > threads just in case. Always good to be educated. Of course, the > mailing lists are usually filled with complaints rather than success > stories, so the tone of my mail here will therefore sound negative; I > don't mean it that way, I just ask that people "be aware". > > * 2011/04/29 -- mps driver instability under stable/8 > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/thread.html#62507 > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/thread.html#62518 > > * 2011/04/27 -- MPS driver: force bus rescan after remove SAS cable > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/thread.html#62438 > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/thread.html#62443 > > * 2011/03/10 -- LSI SAS2008 performance with mps(4) driver > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-March/thread.html#61862 > Those threads assure me that the SuperMicro AOC-USAS2-L8i with version 9 firmware and the mps(4) driver work very well as long as I'm running FreeBSD 9-CURRENT or 8-STABLE (not 8.2-RELEASE). As I'm running -STABLE I'm quite happy to give it a go. To the OP (Matt Thyer): > > Sadly I don't have a recommendation for you, since you effectively want > a 6-port SATA300 controller that's reliable, you're almost certainly > going to be paying Big Bucks(tm) given the number of ports and your > requirement that it be PCIe-based. You state quite boldly "not wanting > to break the bank", but what you're asking for almost certainly WILL > break the bank. > Jeremy, I think you need to have another look at current prices. I have now bought a SuperMicro AOC-USAS2-L8i on EBay from bakamuzko with the cables I need for only $US 210.99 (I do know about the UIO bracket). For example, an "affordable" controller might be one driven by Silicon > Image's SiI3124 chip -- four (4) SATA300 ports, but it's only hooked to > PCI or PCI-X, not PCIe, which means you're susceptible to a much more > severe bus bottleneck than with PCIe: > I defintely would not consider PCI for part of a ZFS array with 4 drives on that one controller. <http://www.siliconimage.com/products/family.aspx?id=3> > I tend to avoid consumer-grade Marvell and JMicron SATA chipsets like > the plague, however. That's based on my experiences with them under > Windows, where I would expect (truly) the drivers to be rock solid given > the marketing demographic of the chips in question. > I've had the same bad experiences. Good luck, and please let us know what controller you *do* end up going > with and your experience with it! Positives are as important as > negatives. > I'll let you know how it works out. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PCIe SATA HBA for ZFS on -STABLE
On 7 June 2011 12:03, Matthew Dillon wrote: >The absolute cheapest solution is to buy a Sil-3132 PCIe card >(providing 2 E-SATA ports), and then connect an external port multiplier >to each port. External port multiplier enclosures typically support >5 drives each so that would give you your 10 drives. > I've decided to avoid issues with port multiplication by going for a Supermicro AOC-USAS2-L8i and then to flash it to IT (as opposed to IR) mode to make it run as a standard non-RAID HBA. As I've got 8 x 2 TB drives for the ZFS raidz2 I'll put them all on the AOC-USAS2-L8i and save my onboard SATA-II ports for my 2 x 1TB drives for the FreeBSD O.S. and any eSATA use. Now the only remaining issue is whether to go with the Supermicro firmware or the generic Lsi Logic firmware as some have reported better performance with the version 9 Lsi Logic firmware. I'll report on my experiences (as I keep a record of the revision of my -STABLE build this should actually be useful!). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PCIe SATA HBA for ZFS on -STABLE
On 8 June 2011 20:55, Matt Thyer wrote: > On 7 June 2011 12:03, Matthew Dillon wrote: > >>The absolute cheapest solution is to buy a Sil-3132 PCIe card >>(providing 2 E-SATA ports), and then connect an external port >> multiplier >>to each port. External port multiplier enclosures typically support >>5 drives each so that would give you your 10 drives. >> > > I've decided to avoid issues with port multiplication by going for a > Supermicro AOC-USAS2-L8i and then to flash it to IT (as opposed to IR) mode > to make it run as a standard non-RAID HBA. > > As I've got 8 x 2 TB drives for the ZFS raidz2 I'll put them all on the > AOC-USAS2-L8i and save my onboard SATA-II ports for my 2 x 1TB drives for > the FreeBSD O.S. and any eSATA use. > > Now the only remaining issue is whether to go with the Supermicro firmware > or the generic Lsi Logic firmware as some have reported better performance > with the version 9 Lsi Logic firmware. > > I'll report on my experiences (as I keep a record of the revision of my > -STABLE build this should actually be useful!). > > I could not be happier with the result. As planned, I've put all 8 2TB Western Digital WD20EARS drives on the 8 lane PCIe 2.0 AOC-USAS2-L8i (flashed with the latest SuperMicro firmware to behave as an AOC-USAS2-L8e). Many of you are now screaming "Why is he using the dreaded WD20EARS ?". The answer is that I bought the first 4 drives before I knew their issues and later decided to continue with them once I knew how to mitigate their issues by: - Using the DOS based WDIDLE3.EXE utility to change the default "park the heads after 8 seconds of idle time" to the maximum of 5 minutes - Avoiding alignment problems by putting ZFS on the whole disks (with no GPT or MBR partition table) - Convincing ZFS to use 4KiB transfers by creating the pool on top of 4KiB block sized devices created with "gnop -S 4096" And the resulting performance... Previously I could sustain about 45 MiB/s writing from high powered Windows 7 machines (via Samba using asynchronous I/O) on to my old arrangement of 4 drives in raidz1 (using only the Intel on-board SATA ports on the H55 chipset motherboard). I can now sustain 90 MiB/s over the network with the 8 drive raidz2 but that's only because the Windows 7 machines can't feed the data fast enough. I can see from "zpool iostat pool 1" that ZFS is idle for about 5-7 seconds and then it will write at around 390 - 410 MB/s for about 3 seconds. dd tests are: > sudo dd if=/dev/zero of=/export/1G bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 3.218604 secs (333604841 bytes/sec) > sudo dd if=/dev/random of=/export/1G bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 15.531615 secs (69132658 bytes/sec) So I'm very happy that I can keep my home network users happy with the limits now being due to my gigabit ethernet network (and I'm not going 10 GbE any time soon!). This is on 8-STABLE at r220359 (~ 5th of April 2011). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Installworld broken with an NFS /tmp
I've found the following thread from 2009 which matches what I've just come across while trying to install 9-RELEASE to disk on a machine with an NFS root. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00084.html I've just worked around this by nullfs mounting the local disk's /tmp over the existing (nfs) /tmp, but is there a better way of doing this - an environment variable to specify an alternate to /tmp perhaps? Thanks. -- Apologies for the below The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation. Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. For further information, please visit www.icritical.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
157k interrupts per second causing 60% CPU load on idle system
I've upgraded my FreeBSD-STABLE NAS from r225723 (22nd Sept 2011) to r232477 (4th Mar 2012) and am finding that a system process called "intr" is now constantly using about 60% of 1 CPU starting a short time after reboot (possibly triggered by use of the samba server). When this starts, systat -vm 1 says that the system is 85% idle and 14% interrupt handling. It says that there's around 157k interrupts per second. After a reboot the system is back to it's normal state doing between 3 and 250 or so interrupts per second. The hardware is an Intel Core i3-530 (dual core @ 2.93 GHz with Hyperthreading) with 8 GB RAM (2x4GB) on a Gigabyte H55M-D2H rev 1.3 motherboard running the latest BIOS (F4). The system runs a GENERIC kernel with the following significant items in /boot/loader.conf: zfs_load="YES" aio_load="YES" ahci_load="YES" geom_mirror_load="YES" vfs.root.mountfrom="zfs:zroot" vboxdrv_load="YES" It has 2 x 300 GB disks for the system with GPT partitioning and zmirror for the OS ala http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror I have swap on a gmirror as I want swap to survive the loss of one system disk. The NAS data is on a raidz2 pool of 8 disks connected to a SuperMicro AOC-USAS2-L8i (flashed to behave as an AOC-USAS2-L8e). The system is basically a CIFS NAS with ports/net/samba36 built with AIO_SUPPORT and configured like: socket options = SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY min receivefile size=16384 use sendfile=true aio read size = 16384 aio write size = 16384 aio write behind = true The only other interesting workload on the box is a java Minecraft server using ports/java/jdk16. I'm going to try to reproduce the problem in a VM and binary search down to the revision where it started as soon as I can work out a reliable way to trigger the behaviour (as it doesn't start at boot time). Any idea what could be the cause ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 157k interrupts per second causing 60% CPU load on idle system
On 20 March 2012 21:12, Ivan Voras wrote: > On 20/03/2012 06:26, Matt Thyer wrote: > > I've upgraded my FreeBSD-STABLE NAS from r225723 (22nd Sept 2011) to > > r232477 (4th Mar 2012) and am finding that a system process called "intr" > > is now constantly using about 60% of 1 CPU starting a short time after > > reboot (possibly triggered by use of the samba server). > > > > When this starts, systat -vm 1 says that the system is 85% idle and 14% > > interrupt handling. > > It says that there's around 157k interrupts per second. > > > > Ok, but *which* interrupt is getting triggered? Please send the output > of "vmstat -i". > > > interrupt total rate irq16: uhci0+ 3392184862 126692 cpu0: timer 53549677 1999 irq256: mps0 2643187 98 irq257: re0 5508108205 irq258: ahci0 160717 6 cpu1: timer 53525300 1999 cpu2: timer 53525300 1999 cpu3: timer 53525296 1999 Total 3614622447 134999 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 157k interrupts per second causing 60% CPU load on idle system
On 20 March 2012 22:24, Ivan Voras wrote: > On 20 March 2012 12:52, Matt Thyer wrote: > > On 20 March 2012 21:12, Ivan Voras wrote: > >> > >> On 20/03/2012 06:26, Matt Thyer wrote: > >> > I've upgraded my FreeBSD-STABLE NAS from r225723 (22nd Sept 2011) to > >> > r232477 (4th Mar 2012) and am finding that a system process called > >> > "intr" > >> > is now constantly using about 60% of 1 CPU starting a short time after > >> > reboot (possibly triggered by use of the samba server). > >> > > >> > When this starts, systat -vm 1 says that the system is 85% idle and > 14% > >> > interrupt handling. > >> > It says that there's around 157k interrupts per second. > >> > > >> > >> Ok, but *which* interrupt is getting triggered? Please send the output > >> of "vmstat -i". > >> > >> > > interrupt total rate > > irq16: uhci0+ 3392184862 126692 > > Ok, something's probably wrong with USB. Can you disable it in BIOS? > > > > cpu0: timer 53549677 1999 > > irq256: mps0 2643187 98 > > irq257: re0 5508108205 > > irq258: ahci0 160717 6 > > cpu1: timer 53525300 1999 > > cpu2: timer 53525300 1999 > > cpu3: timer 53525296 1999 > > Total 3614622447 134999 > > > I did just update the BIOS at about the same time so the difference may be due to that change. I'll try a few things such as: - Unplugging any USB things (I've only got a keyboard plugged in). - Downgrade BIOS. I'll get back to you all soon. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 157k interrupts per second causing 60% CPU load on idle system
On 21 March 2012 00:03, Gary Palmer wrote: > On Tue, Mar 20, 2012 at 11:10:10PM +1030, Matt Thyer wrote: > > On 20 March 2012 22:24, Ivan Voras wrote: > > > > > On 20 March 2012 12:52, Matt Thyer wrote: > > > > On 20 March 2012 21:12, Ivan Voras wrote: > > > >> > > > >> On 20/03/2012 06:26, Matt Thyer wrote: > > > >> > I've upgraded my FreeBSD-STABLE NAS from r225723 (22nd Sept 2011) > to > > > >> > r232477 (4th Mar 2012) and am finding that a system process called > > > >> > "intr" > > > >> > is now constantly using about 60% of 1 CPU starting a short time > after > > > >> > reboot (possibly triggered by use of the samba server). > > > >> > > > > >> > When this starts, systat -vm 1 says that the system is 85% idle > and > > > 14% > > > >> > interrupt handling. > > > >> > It says that there's around 157k interrupts per second. > > > >> > > > > >> > > > >> Ok, but *which* interrupt is getting triggered? Please send the > output > > > >> of "vmstat -i". > > > >> > > > >> > > > > interrupt total rate > > > > irq16: uhci0+ 3392184862 126692 > > > > > > Ok, something's probably wrong with USB. Can you disable it in BIOS? > > > > > > > > > > cpu0: timer 53549677 1999 > > > > irq256: mps0 2643187 98 > > > > irq257: re0 5508108205 > > > > irq258: ahci0 160717 6 > > > > cpu1: timer 53525300 1999 > > > > cpu2: timer 53525300 1999 > > > > cpu3: timer 53525296 1999 > > > > Total 3614622447 134999 > > > > > > > > > > > I did just update the BIOS at about the same time so the difference may > be > > due to that change. > > > > I'll try a few things such as: > > > > - Unplugging any USB things (I've only got a keyboard plugged in). > > - Downgrade BIOS. > > > > I'll get back to you all soon. > > It would be interesting to know if there are other devices on irq16 also. > > grep 'irq 16' /var/run/dmesg.boot > > I think the '+' on the irq16 line from vmstat means the interrupt is > shared, but the man page doesn't mention it so I'm not 100% sure > > Thanks, > > Gary > Good point... pcib1: irq 16 at device 1.0 on pci0 mps0: port 0xee00-0xeeff mem 0xfbdfc000-0xfbdf,0xfbd8-0xfbdb irq 16 at device 0.0 on pci1 vgapci0: port 0xff00-0xff07 mem 0xfb40-0xfb7f,0xe000-0xefff irq 16 at device 2.0 on pci0 uhci0: port 0xfe00-0xfe1f irq 16 at device 26.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pcib3: irq 16 at device 28.4 on pci0 atapci0: port 0xdf00-0xdf07,0xde00-0xde03,0xdd00-0xdd07,0xdc00-0xdc03,0xdb00-0xdb0f irq 16 at device 0.0 on pci3 I'd suspect the SAS/SATA HBA using the mps0 driver as that's where I have the raidz2 on 8 drives. Is this still the old driver or has the new LSI authored driver been added to -STABLE yet ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
SAS Drive identification LEDs
Under 9.0-RELEASE I'm having trouble figuring out how to light up the drive identification/fault lights on my enclosure (SAS disks on Chenbro 80H10321513C0 backplanes attached to Areca ARC-1320 HBAs) Building+installing the tools in /usr/share/examples/ses gives me the following ability: # getencstat -V /dev/ses0 /dev/ses0: Enclosure Status Element 0x0: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x1: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x2: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x3: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x4: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0x5: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0x6: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0x7: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0x8: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x9: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0xa: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0xb: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0xc: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0xd: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0xe: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0xf: Array device, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0x10: Enclosure OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x11: SAS Expander OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x12: SAS Connector, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) Element 0x13: SAS Connector OK (Status=ok (bytes=0x01 0x3f 0x00 0x00)) Element 0x14: SAS Connector OK (Status=ok (bytes=0x01 0x02 0x00 0x00)) Element 0x15: SAS Connector, Status=unknown status code 8 (bytes=0x08 0x00 0x00 0x00) # setobjstat /dev/ses0 0xb 0x80 0x00 0x02 0x00 < light on drive bay 8 starts flashing > # setobjstat /dev/ses0 0xb 0x80 0x00 0x00 0x00 < light on drive bay 8 stops flashing > Which is great, but how can I work out how /dev/daNN maps to /dev/sesN element 0xNN? I've read mav@'s 2011 PDF on Enclosure Management (http://people.freebsd.org/~mav/Enclosure_Management_en.pdf) which shows a work-in-progress driver and getencstat which does what I need, but it looks like the project's not been committed yet. I've also tried playing around with Areca's SDK, however FreeBSDSCSIInterface()->init(i) causes the closed source driver to panic the kernel. AFAICT that class appears to be closed source too, so that's a dead end too. Is there any current way of mapping LED toggling with drive/serial numbers, or some sort of Areca HBA utility like mfiutil, or is it down to sticky labels on the front of the drive caddies? Thanks -- Sorry for the below... The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation. Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. For further information, please visit www.icritical.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 157k interrupts per second causing 60% CPU load on idle system
On Mar 22, 2012 10:14 AM, "Mike Tancsa" wrote: > > On 3/20/2012 1:26 AM, Matt Thyer wrote: > > I've upgraded my FreeBSD-STABLE NAS from r225723 (22nd Sept 2011) to > > r232477 (4th Mar 2012) and am finding that a system process called "intr" > > is now constantly using about 60% of 1 CPU starting a short time after > > reboot (possibly triggered by use of the samba server). > > > > When this starts, systat -vm 1 says that the system is 85% idle and 14% > > interrupt handling. > > It says that there's around 157k interrupts per second. > > > > Any idea what could be the cause ? > > This sounds like the problem I had with my intel board. BIOS update > fixed it. What chipset and MB vendor do you have ? The original post tells you this. I've already updated to the latest BIOS and this could have caused the problem. I think I should try updating the firmware of the SAS/SATA HBA but not until I've confirmed if a BIOS downgrade works. Unfortunately it's very hard to get downtime on this system so it may be some time before I can report any news. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 157k interrupts per second causing 60% CPU load on idle system
On 23 March 2012 01:16, Mike Tancsa wrote: > Sorry, what I was getting at was that a bad bios (eg latest could have > introduced a regression) can cause the symptoms you are seeing. The bios > change sure seemed to fix my problem. > I've updated the firmware of the SuperMicro AOC-USAS2-L8i to the latest -IT firmware on the Supermicro FTP site (this is version 11 and I was on 7 before) but this made no difference. I then tried downgrading the motherboard BIOS to the F3 release that I was running previously but again this made no difference. So it would seem that this is a problem is to do with a change in FreeBSD-STABLE between r225723 and r232477. I'm wondering whether this is due to the new LSI authored driver for chips such as the LSI SAS2008 that are used in the SuperMicro AOC-USAS2-L8i. I know this driver is in CURRENT but do not know if it's in 8-STABLE. Does anyone know if and when this driver was merged from current to 8-STABLE ? If I can work out what revision that occurred in I'll go back to just before then to confirm if the problem exists. Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SAS Drive identification LEDs
On 03/20/12 21:53, Matt Burke wrote: > I've also tried playing around with Areca's SDK, however > FreeBSDSCSIInterface()->init(i) causes the closed source driver to panic > the kernel. AFAICT that class appears to be closed source too, so that's a > dead end too. Just to follow this up, I got in contact with Areca support, who sent me their new v1.00.00.02 (2012-03-23) arcsas driver and CLI tool, which is now available on their website: http://www.areca.com.tw/support/s_freebsd/nonraid_freebsd.htm The API download has also been updated (dated 2012-03-14) to include separate SAS HBA support, and stuff built against it works correctly for me. As a result I now have management visibility (and ability to toggle drive identification) via the ARC-1320 cards. -- Sorry for the below disclaimer... The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation. Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. For further information, please visit www.icritical.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SAS Drive identification LEDs
On 03/28/12 06:11, Fred Liu wrote: > Does ARC-1320 card need specific backplane to work with to identify > HDD's position? Shouldn't imagine so... I'm using a set of 4x four-bay Chenbro 80H10321513C0 jobbies in a 4U box for a total of 16 disks. My original post showed me lighting up an identification LED by poking values at the backplane via the ses device, but the Areca utility seems to do it by poking the drives themselves - which is a much better solution and *should* be backplane-agnostic. -- Sorry for the below disclaimer The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation. Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. For further information, please visit www.icritical.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SAS Drive identification LEDs
On 03/28/12 12:40, Fred Liu wrote: >> Shouldn't imagine so... I'm using a set of 4x four-bay Chenbro >> 80H10321513C0 jobbies in a 4U box for a total of 16 disks. >> >> My original post showed me lighting up an identification LED by poking >> values at the backplane via the ses device, but the Areca utility seems >> to >> do it by poking the drives themselves - which is a much better solution >> and >> *should* be backplane-agnostic. > > Sounds very good! But what if the drive is thoroughly damaged? How would you identify such a drive on any other system? -- Sorry for the disclaimer... The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation. Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. For further information, please visit www.icritical.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ESCape codes displayed instead of processed in pager
On Mar 29, 2012 5:18 AM, "Jim Bryant" wrote: > > Ever since I have upgraded to 9-stable, I have noticed that the manpages seem to be munged up with displayed instead of processed ESCape codes. I believe that this is due to the terminal type of the console changing from "cons25" to "xterm". If you fix your /etc/ttys to reflect this things should be OK. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ESCape codes displayed instead of processed in pager
On Mar 31, 2012 5:02 AM, "Jim Bryant" @ gmail.com > wrote: > > Matt Thyer wrote: > >> >> On Mar 29, 2012 5:18 AM, "Jim Bryant" >> @ gmail.com @ gmail.com >> wrote: >> > >> > Ever since I have upgraded to 9-stable, I have noticed that the manpages seem to be munged up with displayed instead of processed ESCape codes. >> >> I believe that this is due to the terminal type of the console changing from "cons25" to "xterm". If you fix your /etc/ttys to reflect this things should be OK. >> > 1:27:57pm argus(19): tty > /dev/pts/7 > 1:28:03pm argus(20): setenv TERM xterm > 1:28:05pm argus(21): man man > > MAN(1) FreeBSD General Commands Manual MAN(1) > > ESC[1mNAMEESC[0m >ESC[1mman ESC[22m-- display online manual documentation pages > > same thing going on. that's after switching every vty and the console to xterm in /etc/ttys as well. > > i'm kinda lost on this one. i have determined that somehow, it's the pager... hang on a sec... lemme try vi. > > vi seems to be working properly... it's not the termcap/terminfo... the only thing causing this seems to be more and less, both. > > when i pipe man into cat, everything gets properly interpreted by the tty/vty/pty, when i use the pager, i get this crapargh.. > Some suggestions: Test with a clean environment (most easily done by creating a new user account). If that doesn't fix it then you have a problem with your upgrade that may be fixed by mergemaster. You may need to back up your data and do a clean install. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 157k interrupts per second causing 60% CPU load on idle system
On 25 March 2012 22:26, Matt Thyer wrote: > > Does anyone know if and when this driver was merged from current to > 8-STABLE ? > > If I can work out what revision that occurred in I'll go back to just > before then to confirm if the problem exists. > In the -CURRENT list I've been told that the new driver was introduced into 8-STABLE at revision 230921. I reverted to that revision but the problem was still apparent. So I've now tried: - Previous BIOS - Updating the controller firmware from phase 7 to phase 11 - Going back to the old (pre LSI authored) mps driver But all to no avail. What has worked is to move the single SATA 3 (6 Gbps) drive (the other 7 drives are SATA 2) to the onboard SATA 2 Intel controller. So it seems that both the old and new mps driver have a problem with the Western Digital WD20EARX SATA 3 drive on a SuperMicro AOC-USAS2-L8i (SAS 6G) controller (flashed with -IT firmware). I'll continue this in the -CURRENT list in the thread about the new driver as that's where the main discussion has been. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 157k interrupts per second causing 60% CPU load on idle system
On 4 April 2012 21:55, Desai, Kashyap wrote: > Mike, > Have your purchase LSI controller through Channel or OEM ? > It would be a difficult for developers to help you without any support > channel invovoled ? > If possible can you contact LSI support channel ? > Kashyap, It's me, Matt, not Mike reporting this problem. I purchased the Super Micro card off eBay through a seller with good reputation. I've bought a couple of said cards through him now. I'm not sure why you are thinking the lack of middle men would be a problem. I hope that Super Micro & LSI would both be interested in a detailed report of a problem. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 157k interrupts per second causing 60% CPU load on idle system
On 5 April 2012 01:18, Freddie Cash wrote: > On Wed, Apr 4, 2012 at 5:19 AM, Matt Thyer wrote: > > So it seems that both the old and new mps driver have a problem with the > > Western Digital WD20EARX SATA 3 drive on a SuperMicro AOC-USAS2-L8i (SAS > > 6G) controller (flashed with -IT firmware). > > I wouldn't say the driver has a problem with that specific drive. > More that it might have a problem with a mixed SATA2/SATA3 setup. > > Sorry, that's what I meant to say but it now seems that the 157K interrupts per second is probably not due to the SuperMicro AOC-USAS2-L8i. Since moving the SATA 3 disk to the onboard Intel SATA 2 controller I'm no longer having that disk evicted from the raidz2 pool with write errors and I thought that the high interrupt rate issue had also been solved but it's back again. This is on 8-STABLE at revision 230921 (before the new driver hit 8-STABLE). So now I need to go back to trying to determine what the cause is. I'll stop posting in this thread as I don't think it's anything to do with either the old or new version of this driver. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 157k interrupts per second causing 60% CPU load on idle system
On 7 April 2012 14:31, Matt Thyer wrote: > On 5 April 2012 01:18, Freddie Cash wrote: > >> On Wed, Apr 4, 2012 at 5:19 AM, Matt Thyer wrote: >> > So it seems that both the old and new mps driver have a problem with the >> > Western Digital WD20EARX SATA 3 drive on a SuperMicro AOC-USAS2-L8i (SAS >> > 6G) controller (flashed with -IT firmware). >> >> I wouldn't say the driver has a problem with that specific drive. >> More that it might have a problem with a mixed SATA2/SATA3 setup. >> >> Sorry, that's what I meant to say but it now seems that the 157K > interrupts per second is probably not due to the SuperMicro AOC-USAS2-L8i. > > Since moving the SATA 3 disk to the onboard Intel SATA 2 controller I'm no > longer having that disk evicted from the raidz2 pool with write errors and > I thought that the high interrupt rate issue had also been solved but it's > back again. > > This is on 8-STABLE at revision 230921 (before the new driver hit > 8-STABLE). > > So now I need to go back to trying to determine what the cause is. > > I'll stop posting in this thread as I don't think it's anything to do with > either the old or new version of this driver. > Oops... wrong thread I thought I was replying in -CURRENT. So on to the root cause. vmstat -i has shown that the issue was on irq 16. Unfortunately there seems to be a lot of things on irq 16: $ dmesg | grep "irq 16" pcib1: irq 16 at device 1.0 on pci0 mps0: port 0xee00-0xeeff mem 0xfbdfc000-0xfbdf,0xfbd8-0xfbdb irq 16 at device 0.0 on pci1 vgapci0: port 0xff00-0xff07 mem 0xfb40-0xfb7f,0xe000-0xefff irq 16 at device 2.0 on pci0 uhci0: port 0xfe00-0xfe1f irq 16 at device 26.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pcib3: irq 16 at device 28.4 on pci0 atapci0: port 0xdf00-0xdf07,0xde00-0xde03,0xdd00-0xdd07,0xdc00-0xdc03,0xdb00-0xdb0f irq 16 at device 0.0 on pci3 pcib1: irq 16 at device 1.0 on pci0 mps0: port 0xee00-0xeeff mem 0xfbdfc000-0xfbdf,0xfbd8-0xfbdb irq 16 at device 0.0 on pci1 vgapci0: port 0xff00-0xff07 mem 0xfb40-0xfb7f,0xe000-0xefff irq 16 at device 2.0 on pci0 uhci0: port 0xfe00-0xfe1f irq 16 at device 26.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pcib3: irq 16 at device 28.4 on pci0 atapci0: port 0xdf00-0xdf07,0xde00-0xde03,0xdd00-0xdd07,0xdc00-0xdc03,0xdb00-0xdb0f irq 16 at device 0.0 on pci3 Any idea how to isolate which bit of hardware could be triggering the interrupts ? Unfortunately the only device I could remove would be the SuperMicro AOC-USAS2-L8i (so yes I could eliminate that). My biggest problem right now is not knowing how to trigger the issue. At this stage I'm going to upgrade to 9-STABLE and see if it returns. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 157k interrupts per second causing 60% CPU load on idle system
On Apr 7, 2012 2:38 PM, "Matt Thyer" wrote: > > On 7 April 2012 14:31, Matt Thyer wrote: >> Since moving the SATA 3 disk to the onboard Intel SATA 2 controller I'm no longer having that disk evicted from the raidz2 pool with write errors and I thought that the high interrupt rate issue had also been solved but it's back again. >> >> This is on 8-STABLE at revision 230921 (before the new driver hit 8-STABLE). >> >> So now I need to go back to trying to determine what the cause is. >> > vmstat -i has shown that the issue was on irq 16. > > Unfortunately there seems to be a lot of things on irq 16: > > $ dmesg | grep "irq 16" > > pcib1: irq 16 at device 1.0 on pci0 > mps0: port 0xee00-0xeeff mem 0xfbdfc000-0xfbdf,0xfbd8-0xfbdb irq 16 at device 0.0 on pci1 > vgapci0: port 0xff00-0xff07 mem 0xfb40-0xfb7f,0xe000-0xefff irq 16 at device 2.0 on pci0 > uhci0: port 0xfe00-0xfe1f irq 16 at device 26.0 on pci0 > pcib2: irq 16 at device 28.0 on pci0 > pcib3: irq 16 at device 28.4 on pci0 > atapci0: port 0xdf00-0xdf07,0xde00-0xde03,0xdd00-0xdd07,0xdc00-0xdc03,0xdb00-0xdb0f irq 16 at device 0.0 on pci3 > > Any idea how to isolate which bit of hardware could be triggering the interrupts ? > > Unfortunately the only device I could remove would be the SuperMicro AOC-USAS2-L8i (so yes I could eliminate that). > > My biggest problem right now is not knowing how to trigger the issue. > > At this stage I'm going to upgrade to 9-STABLE and see if it returns. The problem does not occur with 9-STABLE. Who knows what the problem was ? USB maybe ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 157k interrupts per second causing 60% CPU load on idle system
On Apr 15, 2012 6:27 PM, "Ronald Klop" wrote: > >> The problem does not occur with 9-STABLE. >> >> Who knows what the problem was ? USB maybe ? > > > Do you still have the same hardware on the same interrupts on 9-STABLE? > Are there changes in the use of MSI(-X)? > I made no hardware or BIOS changes and I'm running a GENERIC kernel in all testing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 157k interrupts per second causing 60% CPU load on idle system
On Apr 16, 2012 5:42 AM, "Ronald Klop" wrote: > > On Sun, 15 Apr 2012 15:09:34 +0200, Matt Thyer wrote: > >> On Apr 15, 2012 6:27 PM, "Ronald Klop" wrote: >>> >>> >>>> The problem does not occur with 9-STABLE. >>>> >>>> Who knows what the problem was ? USB maybe ? >>> >>> >>> >>> Do you still have the same hardware on the same interrupts on 9-STABLE? >>> Are there changes in the use of MSI(-X)? >>> >> I made no hardware or BIOS changes and I'm running a GENERIC kernel in all >> testing. > > > That does not mean FreeBSD 9 can't put devices on other interrupts than 8 did. > 'dmesg | grep irq' like you did before might show a difference with your previous output. > I'm just guessing here for a clue on the result you are seeing, but without any data I cannot answer you (and I guess nobody can). > Ronald, The irqs seem to be the same: $ grep irq\ 16 /var/run/dmesg.boot pcib1: irq 16 at device 1.0 on pci0 mps0: port 0xee00-0xeeff mem 0xfbdfc000-0xfbdf,0xfbd8-0xfbdb irq 16 at device 0.0 on pci1 vgapci0: port 0xff00-0xff07 mem 0xfb40-0xfb7f,0xe000-0xefff irq 16 at device 2.0 on pci0 uhci0: port 0xfe00-0xfe1f irq 16 at device 26.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pcib3: irq 16 at device 28.4 on pci0 atapci0: port 0xdf00-0xdf07,0xde00-0xde03,0xd00-0xdd07,0xdc00-0xdc03,0xdb00-0xdb0f irq 16 at device 0.0 on pci3 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel panic while detecting cpu in FreeBSD 9
On Apr 18, 2012 2:23 AM, "Chad C" wrote: > > The first suggestion from a forum poster was bad memory but I swapped out the memory and still received the panics. Also tested the memory with memtest86+ and the bios memory test feature. Both reported no errors. I finally was able to get it to boot and install by breaking to the loader prompt and typing "kern.smp.disabled=1". But the installed system also panics at the same point during boot and the only way to get it to boot is by disabling smp at the loader prompt. > Please update your BIOS/UEFI and try again. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: top not restoring terminal echo/icanon correctly
On Apr 18, 2012 3:54 AM, "Jeremy Chadwick" wrote: > > (Please keep me CC'd as I'm not subscribed to the list) > > I'd like to request that folks running RELENG_8 (and RELENG_9, though I > do not use it) please check the behaviour of their terminal after each > of following commands are run (check terminal after each command): > > top -a (press "q" after 1 screen refresh) > top -b > > If you find that your input characters in your shell aren't being echo'd > back after one of the above commands, blindly type "stty icanon echo" > and hit and things should be back to normal. > > What I'm looking for is confirmation from others of the problem. > > Also very important: please provide uname -a output, specifically world > rebuild date. It greatly matters, because a commit was recently done > where now -b functions fine (was previously busted in this way), but now > -a behaves like -b did. So src/world date matters. Both commands work fine with no terminal problems. This is when connected to the machine via SSH from an Android 4.0.3 device running ConnectBot. $ uname -a FreeBSD nas 9.0-STABLE FreeBSD 9.0-STABLE #11 r233966: Sat Apr 7 13:09:45 CST 2012 root@nas:/usr/obj/usr/src/sys/GENERIC amd64 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Load when idl on stable
On Jun 1, 2012 11:27 PM, "Albert Shih" wrote: > > Hi > > I already post a message about my problem > > I've three PC, all are Dell. Two laptop and one desktop. > > All run FreeBSD 9-Stable amd64 > > Since 1 or 2 months I notice the load is never drop down 0.8-0.9 event when > nothing running but only on those laptop. > > I update today my desktop to last csup src and everything is fine on the > desktop. > > On both laptop the load is still at 0.8 - 0.9 > > And in same time the usb mouse on the laptop stop working meaning I can > use the touchpad, but if I plug a usb mouse, the kernel see the device but > the mouse not working on xorg. > > Is' not block my work so I can live with that. I just want report those > problems. > > Regards. > > JAS Is this due to a high rate of interrupts ? i.e. can you see this with "systat -vm 1" with a large number in the "intr" field. If yes, run "vmstat -i" to see what interrupt is being hit. Then tell us what hardware is on that irq (from grep irq /var/run/dmesg.boot). Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unable to boot 9 stable/release on HP EliteBook 8560p
On Jun 18, 2012 9:34 PM, "Matthias Gamsjager" wrote: > > On Mon, Jun 18, 2012 at 1:38 PM, Quentin Schwerkolt < > develloper.u...@hotmail.fr> wrote: > > > I have had a similar problem with my HP Elitebook 8540p and I solved it > > by moving the sata controller from ahci to ide in the bios. > > I've had several problems with Linux on HP machines lately that have been fixed with BIOS upgrades. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
On Sunday 01 February 2009 13:11:21 Alex Goncharov wrote:
> On Sun, 1 Feb 2009 12:33:56 + I wrote:
> | That is not to say the new Xorg doesn't work. The only problems I've
> | seen on Radeons needed a couple of options lines in xorg.conf due to
> | the hald/dbus/xorg race and an fdi to make the keyboard layout match
> | what I actually have rather than "us". Easily fixed for now and 7.4
> | brings some fixes to my systems that I have been awaiting for quite
> | some time, most notably the horrendous XPress 200M chipset now works
> | with DRI.
>
> Knowing about specific things now fixed for specific users is very
> encouraging.
I had better post to the lists exactly what I did, having thrown that
encouraging word out:
Ensure the files section doesn't contain anything like RGBPath if you've
upgraded, then add Option "AllowEmptyInput" "False" and Option
"AutoAddDevices" "False" to the server layout section in xorg.conf. Then
create a file ${LOCALBASE}/etc/hal/fdi/policy/x11-input.fdi with the following
contents:
gb
Restart hald etc.
This cleared up all issues of not playing nice with moused, missing keyboards
and quotemarks on my @ key ;o) Obviously, you'll want to replace "gb" with
whatever layout you require from ${LOCALBASE}/share/X11/xkb/symbols/. Note I
have not tried hotplugging a USB mouse on this configuration. That's to come
on the laptop, which works fine with its trackpad (although middle and right
clicks have been redefined to three and two finger taps respectively - it was
the other way around) with the updated xf86-input-synaptics driver.
Which brings me to another little niggle: Has anyone on list noticed
that statically compiling a keymap in your kernel >7.0-RELEASE ends up with
the US layout in single user mode regardless? This used to work, but now it
doesn't, unless I've missed something in NOTES somewhere.
> Thanks a lot!
You're very welcome.
Best regards,
--
Matt Dawson
MTD15-RIPE
m...@chronos.org.uk
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
7.1-RELEASE I/O hang
I have a machine with a PERC6/e controller. Attached to that are 3 disk shelves, each configured as individual 14-disk RAID10 arrays (the PERC annoyingly only lets you use 8 spans per array) I can run bonnie++ on the arrays individually with no problem. I can also run it across a gstripe of the arrays with no problem. However running it over the 3 arrays in parallel causes something I/O related in the kernel to hang. To define 'hang' better: It appears anything which needs disk io, even on a different controller (albeit the same mfi driver), will hang. A command like 'ps' cached in ram will work but bash hangs after execution, presumably while trying to write ~/.bash_history 'sysctl -a' works but trying to run 'sysctl kern.msgbuf' also hangs I've done some research and it seems the usual cause of bonnie++ crashing a system is due to overflowing TCQ. camcontrol doesn't see any disks, so I've tried setting hw.mfi.max_cmds=32 in /boot/loader.conf but it hadn't made any difference. The bonnie++ invocation is this: (newfs devices mfid[2-3], mount) bonnie++ -s 64g -u root -p3 bonnie++ -d /data/2 -s 64g -u root -y s >b2 2>&1 & bonnie++ -d /data/3 -s 64g -u root -y s >b3 2>&1 & bonnie++ -d /data/4 -s 64g -u root -y s >b4 2>&1 & and it always hangs on "Rewriting...". It's a fresh 7.1-RELEASE with nothing else running (devd, sshd, syslogd, etc) Any ideas? -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.1-RELEASE I/O hang
Kostik Belousov wrote: > Compile ddb into the kernel, and do "ps" from the ddb prompt. If there > are processes hung in the "nbufkv" state, then the patch below might > help. The bonnie++ processes are in state "newbuf" and other hung processes (bash, newly forked sshds, etc) appear to be in the "ufs" state. The patch appears to have no effect, although at the last hang I did see one of the bonnie++ processes in "nbufkv" state. This could be coincidental. The problem also exhibits itself when running a parallel bonnie++ on a single array, both with the onboard PERC6/i and the PERC6/e. I have no access to other controllers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.1-RELEASE I/O hang
Kostik Belousov wrote: >>> Compile ddb into the kernel, and do "ps" from the ddb prompt. If there >>> are processes hung in the "nbufkv" state, then the patch below might >>> help. >> The bonnie++ processes are in state "newbuf" and other hung processes >> (bash, newly forked sshds, etc) appear to be in the "ufs" state. > What is the state of the bufdaemon process ? qsleep -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
NSIS compile failed on FreeBSD 7.2
I'm attempting to install NSIS (http://nsis.sourceforge.net/) on an
amd64 FreeBSD 7.2 system and having trouble. When I run
scons SKIPSTUBS=all SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all
NSIS_CONFIG_CONST_DATA_PATH=no
in the source directory for NSIS, I get a bunch of errors that look like:
/usr/include/c++/4.2/new:95: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter
A google search gives me a link to this bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28582 that doesn't seem to
have been touched since 2006. Is there someway around this compile error?
Thanks,
Matt
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NSIS compile failed on FreeBSD 7.2
Just a note of closure. Apparently NSIS doesn't compile on 64-bit
architectures. Compiled fine on an i386 7.2 install (same machine),
once the proper library paths were provided.
Matt Wilks wrote:
I'm attempting to install NSIS (http://nsis.sourceforge.net/) on an
amd64 FreeBSD 7.2 system and having trouble. When I run
scons SKIPSTUBS=all SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all
NSIS_CONFIG_CONST_DATA_PATH=no
in the source directory for NSIS, I get a bunch of errors that look like:
/usr/include/c++/4.2/new:95: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter
A google search gives me a link to this bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28582 that doesn't seem to
have been touched since 2006. Is there someway around this compile error?
Thanks,
Matt
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
--
Matt Wilks Colossians 2:6-7
University of TorontoInformation Security, I+TS
(416) 978-3328 m...@madhaus.cns.utoronto.ca
4 Bancroft Ave., Rm. 102 Toronto, ON M5S 1C1
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NSIS compile failed on FreeBSD 7.2
If that's indeed the case, then the port Makefile needs to be modified to reject building on any architectures other than i386. This should suffice: ONLY_FOR_ARCHS= i386 If you could file a PR on this matter, the FreeBSD Project folks would likely appreciate it. :-) There isn't actually a FreeBSD port for this project. I was compiling source obtained from the NSIS sourceforge page. -- Matt Wilks Colossians 2:6-7 University of TorontoInformation Security, I+TS (416) 978-3328 m...@madhaus.cns.utoronto.ca 4 Bancroft Ave., Rm. 102 Toronto, ON M5S 1C1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
8.0 machine won't boot single user
I have a server (Dell 2950) running 8.0-RELEASE-p1 that won't boot into single user mode - it hangs on "Trying to mount root from ufs:/dev/label/root". It hangs when using the /dev/mfid1s1a device too so it doesn't appear to be a glabel issue. Previously I had this issue booting multi-user too and the only way I could fix it was to reinstall the base distribution from CD, but this time it appears limited to single user mode. Normal boots work fine. I have built a kernel with DDB to get a backtrace, but hitting ctrl-alt-esc causes the USB keyboard to die. The machine has no PS/2 ports. After the kernel initialises the NICs, the IPMI serial-over-lan dies, presumably until rc brings the interfaces up, so I can't fire up DDB over the serial console. Setting hint.bce.N.disabled=1 at the loader prompt doesn't prevent the kernel from initialising the NICs. I don't have another machine with a physical serial port. Is there anything I can do to diagnose+fix this issue short of trying to hack sys/dev/if_bce.c to bring the interfaces up on attach? Thanks The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation. Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. For further information, please visit www.icritical.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: posting coding bounties, appropriate money amounts?
On Fri, Jan 22, 2010 at 3:06 PM, Ivan Voras wrote: > Dan Naumov wrote: >> >> Hello >> >> I am curious about posting some coding bounties, my current interest >> revolves around improving the ZVOL functionality in FreeBSD: fixing >> the known ZVOL SWAP reliability/stability problems as well as making >> ZVOLs work as a dumpon device (as is already the case in OpenSolaris) >> for crash dumps. I am a private individual and not some huge Fortune >> 100 and while I am not exactly rich, I am willing to put some of my >> personal money towards this. I am curious though, what would be the >> best way to approach this: directly approaching committer(s) with the >> know-how-and-why of the areas involved or through the FreeBSD >> Foundation? And how would one go about calculating the appropriate >> amount of money for such a thing? > > Hi, > > This idea (bounties) appear approximately every 6 months and it appears > there is no better way than contacting the developers directly. AFAIK all > attempts to conglomerate such an effort have failed. One important > conclusion is that it cannot go through the Foundation since they cannot > accept targeted donations. Awhile back, we built a simple app for posting bounties, getting devs and sponsors on board, posting the committed code in a browser viewable format, and then handle final payout upon completion. iXsystems is more than willing to handle financial details and I would gladly be the first to sponsor this project on the site. http://www.sponsorbsd.org We would need a team leader *cough* Ivan *cough* that could make sure developing contributors are actually involved so that the final payoff can be shared accordingly. It's a cakephp app and I'm sure it needs a bit more polish but we could do it on the fly and it shouldn't be to hard :) Any cakephp or php devs interested in helping testing and launch, let me know. I just haven't had much time to spend on launching it although I still think it's a great idea. If somebody would like to spearhead this effort, that would be great. For companies wishing to sponsor non-community code, it also has the option of hiding the community committed code. best, -matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: freebsd 8.0 stable amd64/x86 needs ~9min to bootup
2010/1/27 Zavam, Vinícius > noon, all you guys. > > well, I'm having some issues during the 8.0-stable bootup process. > it takes ~9min to finish the entire boot process to shows me the > "login:" screen. > Are you using zfsloader? A month or so ago the ZFS code was updated to probe all 128 possible GPT partitions instead of just four, resulting in a slow-down, but probably not nine minutes' worth. Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: booting off GPT partitions
On Wed, Jan 27, 2010 at 8:45 AM, Dan Naumov wrote: > Hey > > I was under the impression that everyone and their dog is using GPT > partitioning in FreeBSD these days, including for boot drives and that > I was just being unlucky with my current NAS motherboard (Intel > D945GCLF2) having supposedly shaky support for GPT boot. But right now > I am having an email exchange with Supermicro support (whom I > contacted since I am pondering their X7SPA-H board for a new system), > who are telling me that booting off GPT requires UEFI BIOS, which is > supposedly a very new thing and that for example NONE of their current > motherboards have support for this. > > Am I misunderstanding something or is the Supermicro support tech > misguided? > > I'm booting servers with SuperMicro X8STi-F motherboards just fine using pmbr + GPT + ZFS. Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS pool upgrade to v14 broke ZFS booting
On Wed, Jan 27, 2010 at 11:18 AM, Paul Mather wrote: > I have a FreeBSD guest running under VirtualBox 3.1.2 on Mac OS X. It's > running a recent 8-STABLE and is a ZFS-only install booting via gptzfsboot. > I use this VirtualBox guest as a test install. > > A day or so ago I noticed "zpool status" report that my pool could be > upgraded from v13 to v14. I did this, via "zfs upgrade -a". > > Today, when attempting to fire up this FreeBSD guest in VirtualBox I get > this on the console: > > = > ZFS: unsupported ZFS version 14 (should be 13) > No ZFS pools located, can't boot > _ > = > > and the boot halts at that point. I don't see the boot menu I normally see > that lists the opportunity to boot single-user; disable ACPI; and so on. > > Has anyone else experienced this? Is this a mismatch between gptzfsboot > and my current pool version? (Gptzfsboot includes the message I'm seeing.) > Am I supposed to rebuild and replace gptzfsboot every time the pool version > is updated? (There was no advisory in /usr/src/UPDATING concerning this, > nor do I remember seeing it elsewhere.) > > Yes, you're running a version of gptzfsboot that only knows how to run version 13 and below. The commit that brought in version 14 support also bumped the version number for gptzfsboot though it doesn't look like any of the code changed; perhaps version 14 doesn't change anything that gptzfsboot cares about. Try rebuilding and reinstalling gptzfsboot and zfsloader to see if that helps: cd /sys/boot make cleandir make cleandir make obj make depend make all make install gpart bootcode -p /boot/gptzfsboot -i 1 /dev/somedisk Of course adjust the gpart command for your setup. Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS on root, serial console install
On Thu, Feb 11, 2010 at 10:27 PM, Charles Sprickman wrote: > Any hints on that one? > > I finally got around to getting dhcp/tftp/nfs setup on an internal network > to perform normal installs (and with some pxelinux hackery, the ability to > boot a DOS disk or memtest86 disk images). > > Sysinstall in general is kind of an unweildy beast over serial, but one > thing I was not able to accomplish was to get a shell (no extra virtual > consoles on serial) or attempt any mounting of fixit media. From my last > install that put ZFS on root, I had to do quite a bit of tapdancing since I > had no DVD or bootable USB media - lots of switching from the install disk > to fixit, which brought me to many chicken and egg moments. I did it > though... > > But remotely, I'm not seeing a good way to do this. If mfsroot were larger > and had more tools, then I'd be in business. This is probably the direction > I need to get shoved in. > > I've looked at some other options with pxelinux and perhaps booting the > mini ISO, but I'm not sure that gets me anywhere. > > Any tips? This isn't a make or break situation, I live 15 minutes from the > colo... It's more of a quest. :) The way I do it is to boot over the network using pxeboot, configure the partitions and ZFS pool and filesystems mounted on /mnt, then install using sysinstall, using the Options dialog to set the install directory to /mnt. I think I created the NFS filesystem using "make installworld DESTDIR=/usr/nfs/freebsd" or something like that; this gives you all the tools you need. Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: booting off a ZFS pool consisting of multiple striped mirror vdevs
On Sat, Feb 13, 2010 at 12:04 PM, Dan Naumov wrote: > Hello > > I have succesfully tested and used a "full ZFS install" of FreeBSD 8.0 > on both single disk and mirror disk configurations using both MBR and > GPT partitioning. AFAIK, with the more recent -CURRENT and -STABLE it > is also possible to boot off a root filesystem located on raidz/raidz2 > pools. But what about booting off pools consisting of multiple striped > mirror or raidz vdevs? Like this: > > Assume each disk looks like a half of a traditional ZFS mirror root > configuration using GPT > > 1: freebsd-boot > 2: freebsd-swap > 3: freebsd-zfs > > |disk1+disk2| + |disk3+disk4| + |disk5+disk6| > > My logic tells me that while booting off any of the 6 disks, boot0 and > boot1 stage should obviously work fine, but what about the boot2 > stage? Can it properly handle booting off a root filesystem thats > striped across 3 mirror vdevs or is booting off a single mirror vdev > the best that one can do right now? > > I don't know, but I plan to test that scenario in a few days. Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS tuning [was: hardware for home use large storage]
On Mon, Feb 15, 2010 at 5:49 PM, jhell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > It is funny that you guys are all of a sudden talking about this, as I was > just working on some modifications to the arc_summary.pl script for some > better formatting and inclusion of kmem statistics. > > My intent on the modifications is to make the output more usable to the > whole community by revealing the relevant system information that can be > included in an email to the lists for diagnosis by others. > ... > Example output: > - - > System Summary > OS Revision:199506 > OS Release Date:703100 > Hardware Platform: i386 > Processor Architecture: i386 > Storage pool Version: 13 > Filesystem Version: 3 > > Kernel Memory Usage > TEXT: 8950208 KiB,8 MiB > DATA: 206347264 KiB, 196 MiB > TOTAL: 215297472 KiB, 205 MiB > Above did you really mean "8950208 B" not KiB, etc.? Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: booting off a ZFS pool consisting of multiple striped mirror vdevs
On Tue, Feb 16, 2010 at 12:38 AM, Dan Naumov wrote: > > I don't know, but I plan to test that scenario in a few days. > > > > Matt > > Please share the results when you're done, I am really curious :) > Booting from a stripe of two raidz vdevs works: FreeBSD/i386 boot Default: doom:/boot/zfsloader boot: status pool: doom config: NAME STATE doom ONLINE raidz1 ONLINE label/doom-0 ONLINE label/doom-1 ONLINE label/doom-2 ONLINE raidz1 ONLINE label/doom-3 ONLINE label/doom-4 ONLINE label/doom-5 ONLINE I'd guess a stripe of mirrors would work fine too. If I get a chance I'll test that combo. > If booting of a stripe of 3 mirrors should work assuming no BIOS bugs, > can you explain why is booting off simple stripes (of any number of > disks) currently unsupported? I haven't tested that myself, but > everywhere I look seems to indicate that booting off a simple stripe > doesn't work or is that "everywhere" also out of date after your > changes? :) It's probably unsupported in Solaris/OpenSolaris because of their bootloader. Our bootloader is completely different from theirs and so is not subject to those restrictions in the ZFS docs. The bottom line is that I think FreeBSD can boot from pretty much any configuration, except possibly from systems with huge numbers of disks. Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: booting off a ZFS pool consisting of multiple striped mirror vdevs
On Thu, Feb 18, 2010 at 10:57 AM, Matt Reimer wrote: > On Tue, Feb 16, 2010 at 12:38 AM, Dan Naumov wrote: > >> > I don't know, but I plan to test that scenario in a few days. >> > >> > Matt >> >> Please share the results when you're done, I am really curious :) >> > > Booting from a stripe of two raidz vdevs works: > > FreeBSD/i386 boot > Default: doom:/boot/zfsloader > boot: status > pool: doom > config: > > NAME STATE > doom ONLINE > raidz1 ONLINE > label/doom-0 ONLINE > label/doom-1 ONLINE > label/doom-2 ONLINE > raidz1 ONLINE > label/doom-3 ONLINE > label/doom-4 ONLINE > label/doom-5 ONLINE > > I'd guess a stripe of mirrors would work fine too. If I get a chance I'll > test that combo. > A stripe of three-way mirrors works: FreeBSD/i386 boot Default: mithril:/boot/zfsloader boot: status pool: mithril config: NAME STATE mithril ONLINE mirror ONLINE label/mithril-0 ONLINE label/mithril-1 ONLINE label/mithril-2 ONLINE mirror ONLINE label/mithril-3 ONLINE label/mithril-4 ONLINE label/mithril-5 ONLINE Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: booting off a ZFS pool consisting of multiple striped mirror vdevs
On Thu, Feb 18, 2010 at 4:36 PM, Dan Naumov wrote: > > A stripe of 3-way mirrors, whoa. Out of curiosity, what is the system > used for? I am not doubting that there exist some uses/workloads for a > system that uses 6 disks with 2 disks worth of usable space, but > that's a bit of an unusual configuration. What are your system/disc > specs and what kind of performance are you seeing from the pool? > It's for a reasonably busy webserver hosting a few hundred domains, which tends to be somewhat seek-intensive. For this pool we had two main criteria: speed and double-disk redundancy. A stripe of three two-way mirrors would only give us single-disk redundancy in the worst case (i.e. losing both disks in one of the mirrors), so we went with two three-way mirrors instead. Even though we're only getting the capacity of two disks worth of space, we'll still have 6x the capacity of the array it's replacing. A simple-minded dd test gives me ~180MB/s writing a single long file, and 400-500MB/s reading. Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD 8.0?
On Tue, Dec 8, 2009 at 6:48 PM, Steven Hartland wrote: > I'm currently testing nginx + passenger on FreeBSD 8.0 and I'm seeing a > strange > segv which seems to indicate a core library error in _rtld_error. Could this > be the case or is the stack just badly corrupted? > > (gdb) bt > #0 0x0008005577dc in _rtld_error () from /libexec/ld-elf.so.1 > #1 0x000800557c3f in _rtld_error () from /libexec/ld-elf.so.1 > #2 0x000800557d5e in _rtld_error () from /libexec/ld-elf.so.1 > #3 0x00080055851b in dladdr () from /libexec/ld-elf.so.1 > #4 0x0008005585f3 in dladdr () from /libexec/ld-elf.so.1 > #5 0x00080055576d in ?? () from /libexec/ld-elf.so.1 > #6 0x0001 in ?? () > #7 0x004117f8 in > boost::detail::sp_counted_impl_p::dispose > (this=0x800768980) at sp_counted_impl.hpp:78 > Previous frame inner to this frame (corrupt stack?) > > Regards > Steve Steve, Did you figure this out? We're seeing something very similar with nginx + passenger + FreeBSD 8.0. Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD8.0?
On Wed, Dec 9, 2009 at 4:20 AM, Steven Hartland wrote:
>
> - Original Message - From: "Kostik Belousov"
> To: "Steven Hartland"
> Cc: ;
> Sent: Wednesday, December 09, 2009 10:21 AM
> Subject: Re: nginx + passenger = segv in _rtld_error on restart on
> FreeBSD8.0?
>
> This is the trace once world had been recompiled with:-
> CFLAGS=-pipe
> WITH_CTF=1
> DEBUG_FLAGS=-g
>
>
> #0 0x000800c95eec in thr_kill () at thr_kill.S:3
> #1 0x000800b22e9e in _thr_send_sig (thread=0x800f06600, sig=6) at
> /usr/src/lib/libthr/thread/thr_kern.c:92
> #2 0x000800b1f878 in _raise (sig=6) at
> /usr/src/lib/libthr/thread/thr_sig.c:187
> #3 0x000800d74003 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> #4 0x0043b8a7 in Client::threadMain (this=0x800f9cf40) at
> ext/nginx/HelperServer.cpp:516
> #5 0x00411302 in boost::_mfi::mf0::operator()
> (this=0x7fa45ea8, p=0x800f9cf40) at mem_fn_template.hpp:49
> #6 0x00411651 in boost::_bi::list1
>>::operator(), boost::_bi::list0>
> (this=0x7fa45eb8, f...@0x7fa45ea8, a...@0x7fa45d7f) at
> bind.hpp:232
> #7 0x00411696 in boost::_bi::bind_t Client>, boost::_bi::list1 > >::operator()
> (this=0x7fa45ea8) at bind_template.hpp:20
> #8 0x004116bd in
> boost::detail::function::void_function_obj_invoker0 boost::_mfi::mf0, boost::_bi::list1
>> >, void>::invoke (
> function_obj_p...@0x7fa45ea8) at function_template.hpp:158
> #9 0x0042e73a in boost::function0
>>::operator() (this=0x7fa45ea0) at function_template.hpp:825
> #10 0x00435760 in oxt::thread::thread_main (fu...@0x7fa45ea0,
> da...@0x7fa45e90) at thread.hpp:107
> #11 0x0041310e in
> boost::_bi::list2 std::allocator > >,
> boost::_bi::value >
>>::operator() >,
> boost::shared_ptr), boost::_bi::list0>
> (this=0x800f3ee80, f...@0x800f3ee78, a...@0x7fa45f0f) at bind.hpp:289
> #12 0x00413196 in boost::_bi::bind_t (*)(boost::function >,
> boost::shared_ptr),
> boost::_bi::list2 std::allocator > >,
> boost::_bi::value > >
>>::operator() (this=0x800f3ee78) at bind_template.hpp:20
> #13 0x004131b9 in
> boost::thread::thread_data (*)(boost::function >,
> boost::shared_ptr),
> boost::_bi::list2 std::allocator > >,
> boost::_bi::value > > > >::run
> (this=0x800f3ee00) at thread.hpp:130
> #14 0x00443259 in thread_proxy (param=0x800f3ee00) at
> ext/boost/src/pthread/thread.cpp:127
> #15 0x000800b1badd in thread_start (curthread=0x800f06600) at
> /usr/src/lib/libthr/thread/thr_create.c:288
> #16 0x in ?? ()
> Cannot access memory at address 0x7fa46000
> Current language: auto; currently asm
>
> It seems that in the passenger client threads it calls closeStream which
> errors when
> the socket close errors with ENOTCONN
> virtual void closeStream() {
> TRACE_POINT();
> if (fd != -1) {
> int ret = syscalls::close(fd);
> fd = -1;
> if (ret == -1) {
> if (errno == EIO) {
> throw SystemException("A write operation on the
> session stream failed",
> errno);
> } else {
> throw SystemException("Cannot close the session
> stream",
> errno);
> }
> }
> }
> }
>
> This causes it to call abort on the the thread which then crashes the app
> with
> the above stack trace, which seems really weird. Anyone got any ideas?
>
> Regards
> steve
Steve,
The patch for PR 144061 works for us.
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-February/030741.html
http://www.freebsd.org/cgi/query-pr.cgi?pr=144061
Matt
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ATA/boot problems with 6.2-release and 7-prerelease
I have a 6.1-release machine that I wanted to upgrade, so I decided I would upgrade to 6.2-rel, and then to 7-pre. When I upgraded to 6.2-rel, it fails at mountroot, claiming that it can't find ad0s1a to boot from. (Entering ? to list all available boot devices only lists acd0 and ad2*, which are secondary master/slave. It doesn't list anything on ad0 or ad1 which are primary master/slave.) The same thing happens on 7-pre. All installations are using GENERIC kernel. Booting from CD and going into fixit mode works fine - I can see all filesystems on all disks. I've tried swapping primary/secondary as well as swapping cables, but the problem persists. I've attached the dmesg from 6.1. Both 6.2 and 7-pre have the following text in the dmesg numerous times for ata0. ata0: reiniting channel .. ata0: reset tp1 mask=0x ostat0=58 ostat1=50 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=50 devices=0x3 I see this a couple of times for ata1 as well, but the stat1 line is different and we end up detecting ad2/acd0 which are on ata1. Any ideas? -- Matt Emmerton dmesg.61generic Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Unable to cleanly unmount root filesystem on 9.1 amd64
I am running the latest code which I compiled from RELENG_9_1, although I can see that RELENG_9 is pretty much identical at this point too. I'm using the amd64 architecture on an Intel Atom D525 motherboard. I'm using UFS2 with softupdates and softupdates journalling enabled. And it's mounted via glabel. It works fine except when I try and reboot or shutdown the machine I get this error: Syncing disks, vnodes remaining...7 7 2 0 0 done All buffers synced. fsync: giving up on dirty 0xfe0007102780: tag devfs, type VCHR usecount 1, writecount 0, refcount 2292 mountedhere 0xfe00729ca00 flags (VI(0x200)) v_object 0xfe0005101910 ref 0 pages 23509 lock type devfs: EXCL by thread 0xfe00018fe08e0 (pid 1) dev label/root umount of / failed (35) Then when the box comes back up again it detects that / was not unmounted cleanly and recovers from journal before marking it clean once more. My fstab: /dev/label/root / ufs rw 1 1 /dev/label/swap noneswapsw 0 0 My gpart: =>34 1250263661 ada0 GPT (596G) 341024 1 freebsd-boot (512k) 1058 990- free - (495k) 2048 1228931072 2 freebsd-ufs (586G) 122893312021330575 3 freebsd-swap (10G) I have also tried changing this to /dev/ada0p2 in case it was an issue with using labels and it does the same thing. I had no problems with it unmounting from the USB install stick that I used which was 9.1-BETA1, it's only started doing this since I updated it to RELENG_9_1. I did make a custom kernel file when I did that as well, but I don't think I've taken anything important out of it. Any ideas? Regards, Matt. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
I posted on this mailing list two weeks ago and never received any replies so I decided to raise a PR via the web form. But I think I submitted it under the wrong category and it's marked as low priority as well. But I think this is something that is a potential serious problem if I end up getting a corrupted filesystem so I'm posting here again in the hope somebody can help this time. The PR is amd64/170646. I'm now running the latest RELENG_9 code as of 25th August as I've done a new buildworld/kernel. I still get the same problem. When I reboot it I get WARNING: / was not properly dismounted and it rebuilds from journal. On shutdown I get the messages pasted below. I'm running amd64 with GPT partitioning, UFS2 with softupdates and softupdates journalling enabled. I have a custom kernel but I don't think I took anything important out of it. Syncing disks, vnodes remaining...7 7 2 0 0 done All buffers synced. fsync: giving up on dirty 0xfe0007102780: tag devfs, type VCHR usecount 1, writecount 0, refcount 2292 mountedhere 0xfe00729ca00 flags (VI(0x200)) v_object 0xfe0005101910 ref 0 pages 23509 lock type devfs: EXCL by thread 0xfe00018fe08e0 (pid 1) dev label/root umount of / failed (35) Then when the box comes back up again it detects that / was not unmounted cleanly and recovers from journal before marking it clean once more. My uname: FreeBSD tao.xtaz.co.uk 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sat Aug 25 12:34:52 BST 2012 r...@tao.xtaz.co.uk:/usr/obj/usr/src/sys/TAO amd64 My glabel status: Name Status Components gpt/gptboot N/A ada0p1 gptid/bfe99d62-e00f-11e1-8623-00012e475ffb N/A ada0p1 label/root N/A ada0p2 label/swap N/A ada0p3 My fstab: /dev/label/root / ufs rw 1 1 /dev/label/swap none swap sw 0 0 My gpart: => 34 1250263661 ada0 GPT (596G) 34 1024 1 freebsd-boot (512k) 1058 990 - free - (495k) 2048 1228931072 2 freebsd-ufs (586G) 1228933120 21330575 3 freebsd-swap (10G) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-27 10:28, Stefan Bethke wrote: Is there a particular reason you've decided to glabel your partitions instead of using GPT labels? Which device did you do the newfs on, the GPT partition or the glabel device? My hunch is that the label metadata sector at the end of the GPT partition is interfering with the filesystem. I'd try labelling my partitions (gpart modify -i 2 -l root ada0; gpart modify -i 3 -l swap), then change fstab to reference the gpt labels (dev(gpt/root) instead of the glabel ones. No reason at all really. I had just used it like that on a previous MBR based system and it worked fine. I have just booted it using the USB stick again and removed both labels metadata using glabel stop and clear and changed the fstab to use /dev/gpt/ labels now. Unfortunately the same issue persists. It mounted fine, but when I rebooted it it synced all buffers successfully but then gave the same error saying that it couldn't unmount /. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-27 10:25, c...@milos.co.za wrote: I'm far from anything near an expert on file systems but I'd suggest you remove softupdates and leave journaling on. tunefs -n disable There's no need to have both on and although I agree that both SHOULD work together there's no reason to have them on together. It will only slow down writes to the file system. Effectively soft updates was a go-between before journalin was introduced. Really? This is SU+J journalling that I'm using. Not gjournal. Surely SU+J does require softupdates to be on as it's part of the same thing? Output from tunefs -p: tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-27 11:26, Erich Dollansky wrote: I would run plain UFS for / /var and /tmp and see what will happen then. I know what you will answer. But it will help to isolate the problem. Did you mean not use the label at all? If so I just tried this. Set /dev/ada0p2 in the fstab. No change. Still get the same issue. This might help investigations as I wrote down what I did to install it. The way I created this filesystem was that I dropped out of the installer to a shell because I wanted to do the 4k alignment. And I ran this: gpart create -s gpt ada0 gpart add -t freebsd-boot -l gptboot -s 512k ada0 gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0 gpart add -t freebsd-ufs -l gptroot -b 1M -s 586G ada0 gpart add -t freebsd-swap -l gptswap ada0 gpart show =>34 1250263661 ada0 GPT (596G) 341024 1 freebsd-boot (512k) 1058 990- free - (495k) 2048 1228931072 2 freebsd-ufs (586G) 122893312021330575 3 freebsd-swap (10G) newfs -U -j -L root /dev/gpt/gptroot glabel label root /dev/ada0p2 glabel label swap /dev/ada0p3 mount /dev/gpt/gptroot /mnt vi /tmp/bsdinstall_etc/fstab # DeviceMountpoint FStype Options Dump Pass# /dev/label/root / ufs rw 1 1 /dev/label/swap noneswapsw 0 0 exit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-27 14:56, Warren Block wrote: Stefan called it. The newfs is done on /dev/gpt/gptroot, no problem there. But when glabel writes to /dev/ada0p2--which is /dev/gpt/gptroot, same thing, it overwrites the last block. And then the filesystem is mounted with the glabel device, which is actually one block smaller than the filesystem expects. Could be either the filesystem or GEOM that's causing the failure at shutdown. Happily, those glabels aren't accomplishing anything useful and can be skipped. Removing the glabels and changing the devices in fstab might be enough. A more cautious approach would be to back up, newfs, skip the glabel step, and then change the devices in fstab. As I said on a previous mail I did boot it with a USB stick and cleared the glabel metadata and altered the fstab to point to both the GPT labels and the raw UFS device and I still get the issue. So am I right in thinking then that this has caused irreparable damage and the only way I can fix this now is to newfs the filesystem again, this time just using GPT labels and not using glabel at all? This is the first time I've ever done a manually partitioned installation with GPT and alignment, previously I've only ever used sysinstall with non-aligned MBR installations, so it was a bit of a learning curve. If I do have to newfs it again then I want to be sure that I'm doing the correct things so that I don't find myself with any other issues. So does the rest of what I did look fine? If it is clearly my own fault then the PR can obviously be closed and chalked up to learning! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-27 19:42, Warren Block wrote: No obvious problems jumped out at me. Here are my notes: http://www.wonkity.com/~wblock/docs/html/disksetup.html The gpart version is halfway down. I really need to switch that around. Oh! You're the owner of that site. As it happens those were the exact instructions that I used to try and figure out how to do it as you are first in google for "freebsd gpt newfs"! It's just a shame that I then decided to use the same method that I had used before on my old system for the labelling. On my old system I had used MBR partitioning and so needed to use glabel for labelling the swap and I then used the same thing for the UFS partition for consistency in the fstab. It never occurred to me when I was labelling the GPT partitions that I could have used those directly. One thing that is still bugging me though is I'm wondering why I had no problem with this on my old system. That was using a dangerously dedicated disk with MBR where the root partition was just /dev/ada4a. It was also using UFS2 with SU+J enabled and I had used glabel in exactly the same way but on this box it had not done any damage. Shutdown etc worked perfectly fine. Is there something different with the way GPT partitions work? Thank you for your help anyway, and your wonkity site, which I also once used for converting my procmail to maildrop. And thanks also to Erich and Stefan for your help. When I get some spare time I'll redo the filesystem and hope that it works. Matt. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-27 21:35, Warren Block wrote: On Mon, 27 Aug 2012, Matt Smith wrote: Thank you for your help anyway, and your wonkity site, which I also once used for converting my procmail to maildrop. And thanks also to Erich and Stefan for your help. When I get some spare time I'll redo the filesystem and hope that it works. Please post a followup after that. Here is the followup! I have just rebuilt the server from scratch using a 9.1-RC1 amd64 memstick image. Used the GPT labels directly in the fstab and ignored glabel. And guess what? It works fine as you probably expected. So it was definitely user error and the glabel broke it. At least I've learnt a lot more about partitioning and filesystems than I knew before anyway! So once again, thank you for all your help. There is an open PR for this that I raised which is amd64/170646 , I don't think there is any way for me to close this myself is there? If somebody reads this who has the rights to do so then please close it with "user is an idiot" :) Matt. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Userland dtrace broken?
Following http://wiki.freebsd.org/DTrace/userland on 9.1-RC1, the example fails to work as demonstrated: # dtrace -s pid.d -c test dtrace: script 'pid.d' matched 2 probes CPU IDFUNCTION:NAME 1 59284 main:entry dtrace: pid 25479 exited with status 1 # Also, I get hangs when trying to do pretty much anything with the pid:::entry # dtrace -n 'pid$target::malloc:entry' -c 'echo x' dtrace: description 'pid$target::malloc:entry' matched 2 probes xCPU IDFUNCTION:NAME 1 59311 malloc:entry load: 0.43 cmd: dtrace 63737 [running] 8.93r 1.60u 4.19s 35% 25072k load: 0.88 cmd: echo 63738 [running] 45.10r 2.27u 18.75s 47% 1452k load: 1.19 cmd: dtrace 63737 [running] 70.32r 12.14u 33.27s 64% 25072k # procstat -k 63737 63738 PIDTID COMM TDNAME KSTACK 63737 101505 dtrace -mi_switch sleepq_catch_signals sleepq_timedwait_sig _sleep do_wait __umtx_op_wait_uint_private amd64_syscall Xfast_syscall 63737 111024 dtrace - 63738 101657 echo -mi_switch thread_suspend_switch ptracestop cursig ast doreti_ast I have previously tried using dtrace on 9.0R, but it was insta-panic. Is there anything I may have missed here? make.conf: STRIP= CFLAGS+=-fno-omit-frame-pointer WITH_CTF=1 kernel config: include GENERIC ident DTRACE makeoptions DEBUG="-g" makeoptions WITH_CTF=1 options KDTRACE_FRAME options KDTRACE_HOOKS options DDB_CTF options DDB -- The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-28 22:51, Matt Smith wrote: On 2012-08-27 21:35, Warren Block wrote: On Mon, 27 Aug 2012, Matt Smith wrote: Thank you for your help anyway, and your wonkity site, which I also once used for converting my procmail to maildrop. And thanks also to Erich and Stefan for your help. When I get some spare time I'll redo the filesystem and hope that it works. Please post a followup after that. Here is the followup! I have just rebuilt the server from scratch using a 9.1-RC1 amd64 memstick image. Used the GPT labels directly in the fstab and ignored glabel. And guess what? It works fine as you probably expected. So it was definitely user error and the glabel broke it. At least I've learnt a lot more about partitioning and filesystems than I knew before anyway! So once again, thank you for all your help. There is an open PR for this that I raised which is amd64/170646 , I don't think there is any way for me to close this myself is there? If somebody reads this who has the rights to do so then please close it with "user is an idiot" :) Matt. Hi again. Seems it was not actually that simple after all. Yesterday I had tested rebooting the server after just the base O/S had been installed and it was working fine so I assumed that was it. Today I have reinstalled all my ports and then decided to do one last reboot to make sure everything came up properly. And guess what? The same error happened again! I then tracked it down. It seems to happen when the mail/postgrey port is started. If I comment that out of rc.conf and reboot and let it mark the filesystem clean then I can happily reboot with no issues again. If I remove the comment and start it up then I get the same issue on the next reboot. So there is something strange happening between the mail/postgrey port and 9.1-RC1 amd64. As greylisting isn't completely important I can leave this disabled for now but I would like to still resolve this issue so that I can use it again, unless there is alternative greylisting software that I could use with postfix. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Killing processes from DDB
Is it possible to forcibly kill process from DDB which are unkillable from userland? My understanding is the 'kill' command is effectively the same as the userland version, so perhaps a process could be terminated by invoking an OOM handler or something? I just had a VirtualBox instance crash and hog 100% CPU on my desktop: mattb 36939 100.0 13.6 2577328 2276108 ?? I 6:13AM2:28.44 /usr/local/lib/virtualbox/VirtualBox I kill -9 it mattb 36939 100.0 13.6 2577328 2275804 ?? T 6:13AM3:10.89 /usr/local/lib/virtualbox/VirtualBox Note it's moved to 'stop' state for some reason, yet is still eating 100% cpu time # procstat -k 36939 PIDTID COMM TDNAME KSTACK 36939 227509 VirtualBox - 36939 227836 VirtualBox -mi_switch thread_suspend_switch thread_single exit1 sigexit postsig ast doreti_ast Could this be the trigger - 9.0 binary (from pkgng) against 9.1? $ procstat -b 1 36939 PID COMMOSREL PATH 1 init 901000 /sbin/init 36939 VirtualBox 900044 /usr/local/lib/virtualbox/VirtualBox I couldn't even kill it with "dtrace -n 'pid$target:::' -p 36939 -l" - which so far has proven reliable in killing anything: # dtrace -n 'pid$target:::' -p 2021 -l<--- unimportant proc Bus error: 10 (core dumped) # dtrace -n 'pid$target:::' -p 2044 -l<--- unimportant proc Bus error: 10 (core dumped) # dtrace -n 'pid$target:::' -p 36939 -l <--- virtualbox hangs dtrace ^C I couldn't truss the process or use gcore to get a dump, so my only option was a reboot. Does anyone have any suggestions on a course of action in case this happens again? I can't get a kernel dump since the machine doesn't have enough swap (small SSDs) Thanks -- The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Killing processes from DDB
On 08/30/12 09:12, Konstantin Belousov wrote: > Stop state indicates that the process is stopped or being stopped. The later > is your case. The process has one thread executing exit1() kernel function, > which terminates the process. In the course of work, the function notifies > all other threads of the exiting process that they shall terminate ASAP at > the next safe point. Thanks for the explanation - I thought stop state was just a mechanism for processes to pause (as in ^Z from the shell) by being skipped by the scheduler or something... Looking in /sys/kern I think I need to do a lot of reading to correct what appear to be some bad assumptions I've picked up over the years. > The way to debug the issue is to break into ddb on console and get > a backtrace for the spinning thread, then continue, then break again > and get another backtrace. Do it several times, to see where the code > spins. Understood. > It is impossible to even start guessing what is wrong, without seeing > the backtrace. > > Still, recompiling VB could be good idea, since VB kernel module uses > non-stable KPI and KBI, thus what you see might be just build issue. Indeed, however I find Bad Things happening are a great excuse to learn more about the system's innards ;) -- The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Userland dtrace broken?
On 09/13/12 18:04, Chris Nehren wrote: > Relevant to my interests, too. I've followed the instructions on the > wiki / in the handbook (on 9.0/9.1-PRE) and only receive error messages. > Is DTrace supposed to be working properly on 9.x, or is it still > experimental? >From my experience, as long as you avoid using the pid provider, and don't bother trying to get fbt:::return arguments, then it works reliably. I haven't tried userland static probes though. Tracing userland works *occasionally* (I find maybe ~20% of the time when it's the first command run on a machine with <1m uptime), but you're more likely to get strange results, or just a panic. -- The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
9.1-RELEASE
Hi. With the recent delays from the security incident and the three SAs out of the way, what now are we waiting for? I think we should just get rid of the release schedule on FreeBSD.org if we aren't even going to be close to the set dates. RC3 has been really stable for me, but we have a no non-release policy on production machines. We're so far behind compared to http://www.freebsd.org/releases/9.1R/schedule.html (which has already been updated multiple times because of delay after delay) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 35-40% performance drop releng9 vs releng10 openvpn
On Mar 18 18:28, Mike Tancsa wrote: On 3/18/2015 5:14 PM, John-Mark Gurney wrote: As I've never used OpenVPN before and their docs don't go into saying what it's using.. Is OpenVPN a kernel or userland VPN? Do they use IPSec in the kernel? or are they just using UDP or TCP for their connections? All in userland. I use UDP for the transport, and it uses OpenSSL in the base for the crypto. In this case, AES-128-CBC. There is no hardware assist on the APU either to offload the AES. Isn't OpenSSL in the base on releng9 the 0.9.8 version whereas in releng10 it's the 1.0.1 version? This could make a significant difference. I've heard rumours before that the newer version is a lot slower but I've never had cause to believe it. It could be worth installing OpenSSL from the ports system on the releng9 box and reinstalling OpenVPN so that it links against it. Then they will both be on 1.0.1. Could be an interesting test? -- Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problems with openssl 1.0.2 update
On Mar 23 11:33, Gerhard Schmidt wrote: Hi, we experiencing a problem after upgrading the openssl port to openssl 1.0.2. /usr/bin/vi started to crash after some seconds with segfault. /rescue/vi works just fine. Deleting the openssl 1.0.2 package everything works just fine again. Installing the old openssl 1.0.1_18 package it still works just fine. it seams that besides vi the bash also has this problem. Anybody experiencing the same or is this something specific to my system. I'm running FreeBSD 10.1 updated tonight. There is definitely something not right. See this too https://forums.freebsd.org/threads/postfix-does-not-start-build-anymore-since-upgrade-to-openssl-1-0-2.50959/ I haven't had a chance yet to test it again in more detail, but someone reported that postfix was broken, and I had PHP-FPM racing and taking up 50+ load average on my box which I guess was probably nginx hitting it with tons of requests. Mine is 10.1-STABLE amd64. -- Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problems with openssl 1.0.2 update
On Mar 23 11:36, Matt Smith wrote: On Mar 23 11:33, Gerhard Schmidt wrote: Hi, we experiencing a problem after upgrading the openssl port to openssl 1.0.2. /usr/bin/vi started to crash after some seconds with segfault. /rescue/vi works just fine. Deleting the openssl 1.0.2 package everything works just fine again. Installing the old openssl 1.0.1_18 package it still works just fine. it seams that besides vi the bash also has this problem. Anybody experiencing the same or is this something specific to my system. I'm running FreeBSD 10.1 updated tonight. There is definitely something not right. See this too https://forums.freebsd.org/threads/postfix-does-not-start-build-anymore-since-upgrade-to-openssl-1-0-2.50959/ I haven't had a chance yet to test it again in more detail, but someone reported that postfix was broken, and I had PHP-FPM racing and taking up 50+ load average on my box which I guess was probably nginx hitting it with tons of requests. Mine is 10.1-STABLE amd64. I've just reinstalled openssl 1.0.2, and recompiled all ports that link to openssl. And I'm still getting huge problems. PHP-FPM races and starts loads of processes and uses 50+ load average making the machine unresponsive. And trying to run a /bin/sh shell script gives this: sh: environment corrupt; missing value for USERNAME This is clearly very dangerous and broken. Backing out to openssl 1.0.1 fixes everything. -- Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problems with openssl 1.0.2 update
On Mar 23 22:26, Matt Smith wrote: On Mar 23 11:36, Matt Smith wrote: On Mar 23 11:33, Gerhard Schmidt wrote: Hi, we experiencing a problem after upgrading the openssl port to openssl 1.0.2. /usr/bin/vi started to crash after some seconds with segfault. /rescue/vi works just fine. Deleting the openssl 1.0.2 package everything works just fine again. Installing the old openssl 1.0.1_18 package it still works just fine. it seams that besides vi the bash also has this problem. Anybody experiencing the same or is this something specific to my system. I'm running FreeBSD 10.1 updated tonight. There is definitely something not right. See this too https://forums.freebsd.org/threads/postfix-does-not-start-build-anymore-since-upgrade-to-openssl-1-0-2.50959/ I haven't had a chance yet to test it again in more detail, but someone reported that postfix was broken, and I had PHP-FPM racing and taking up 50+ load average on my box which I guess was probably nginx hitting it with tons of requests. Mine is 10.1-STABLE amd64. I've just reinstalled openssl 1.0.2, and recompiled all ports that link to openssl. And I'm still getting huge problems. PHP-FPM races and starts loads of processes and uses 50+ load average making the machine unresponsive. And trying to run a /bin/sh shell script gives this: sh: environment corrupt; missing value for USERNAME This is clearly very dangerous and broken. Backing out to openssl 1.0.1 fixes everything. FYI. This is tracked down to ASM being enabled in the port config settings. Disable that option and it works fine. Details in the PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198788 -- Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ports/base ntpd rc.d script with WITHOUT_NTP=yes
Hi, I just upgraded my server to 10.1-STABLE r281264 and when I ran mergemaster it told me that /etc/rc.d/ntpd was stale and would I like to delete it. It's never done this before. I've figured out it's because I have WITHOUT_NTP=yes in /etc/src.conf. I did this because I use the ports version of ntpd and thus wanted to remove the base installed version so that when I run commands like ntpq it's using my possibly newer port installed version and not the older one. However, the port version doesn't have its own rc script. It usually uses the base version with ntpd_program and ntpd_config set. With this latest change it means I have to have the base version installed again. Is it possible to get the port version to have its own rc script? -- Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ports/base ntpd rc.d script with WITHOUT_NTP=yes
On Apr 08 12:56, Adam McDougall wrote: On 04/08/2015 12:48, Matt Smith wrote: Hi, I just upgraded my server to 10.1-STABLE r281264 and when I ran mergemaster it told me that /etc/rc.d/ntpd was stale and would I like to delete it. It's never done this before. I've figured out it's because I have WITHOUT_NTP=yes in /etc/src.conf. I did this because I use the ports version of ntpd and thus wanted to remove the base installed version so that when I run commands like ntpq it's using my possibly newer port installed version and not the older one. However, the port version doesn't have its own rc script. It usually uses the base version with ntpd_program and ntpd_config set. With this latest change it means I have to have the base version installed again. Is it possible to get the port version to have its own rc script? net/openntpd has an rc script if you don't mind switching. It is very very simple to configure. Ideally the original problem should be solved too but I ran into the same problem with Kerberos. I didn't get anywhere in the bug report where I argued the system scripts still worked fine except for recent changes in them causing a regression and failure with the port. Both situations could probably use a contributed patch to make an rc script. I guess it wouldn't be too hard to just take the base system script, make some minor changes, and add it to the port. Would probably need to call it something different to ntpd though so it doesn't conflict. The openssh port does this I think with ssh in the base and openssh in the port. I might look into it and submit a PR. -- Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Will 10.2 also ship with a very stale NTP?
On Jul 11 23:22, Chris Nehren wrote: On Sat, Jul 11, 2015 at 09:58:11 +1000, John Marshall wrote: It's me again with my annual NTP whinge. The answer to the perennial "will release $foo ship with old / insecure / otherwise deficient $bar?" is still "install $bar from ports". I completely agree with this, however my NTP whinge is that the NTP port needs to have its own RC init script that is independant of the base. If you use WITHOUT_NTP=yes in /etc/src.conf to remove the base version and just use the port then there is no RC script. You have to copy the version from /usr/src/etc/rc.d/ntp into /usr/local/etc/rc.d. This should be fixed. I guess this wouldn't be too difficult to do. I said six months ago that I might look at submitting a patch to do this, maybe I should actually do it. -- Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
WITHOUT_OPENSSL and make delete-old
Hi, I use the ports version of OpenSSL for everything and don't require the base version. As a result I thought I would remove it by adding WITHOUT_OPENSSL into /etc/src.conf and running make delete-old in /usr/src. However this seems to only want to delete things related to kerberos and gssapi, which is understandable as they depend on OpenSSL. However it doesn't seem to touch any OpenSSL files at all. Is this a bug or have I missed something? -- Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: WITHOUT_OPENSSL and make delete-old
On Jul 13 11:29, Kevin Oberman wrote: On Mon, Jul 13, 2015 at 7:03 AM, Matt Smith wrote: Hi, I use the ports version of OpenSSL for everything and don't require the base version. As a result I thought I would remove it by adding WITHOUT_OPENSSL into /etc/src.conf and running make delete-old in /usr/src. However this seems to only want to delete things related to kerberos and gssapi, which is understandable as they depend on OpenSSL. However it doesn't seem to touch any OpenSSL files at all. Is this a bug or have I missed something? Yes. Several critical base system components require the base OpenSL. So, I seem to recall that while WITHOUT_OPENSSL will skip the optional SSL stuff, I am pretty sure that some of the OpenSSL always are built and are considered too critical to rely on a port being installed... like logging in, adding users, etc. See now I assumed that the only things in the base that used it were Kerberos, GSSAPI, and OpenSSH. If you read the man page for src.conf it says that setting WITHOUT_OPENSSL also sets WITHOUT_KERBEROS, WITHOUT_GSSAPI, and WITHOUT_OPENSSH. This makes me think these are the only things in the base that do actually use OpenSSL? Maybe there is actually a lot more that does then. Unfortunately being the base means I can't just use pkg to look at what's registered against the shared libs. -- Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 10.2-BETA2 patch etc/ntp.conf to enable ntpd pool client functionality
On Jul 24 12:27, John Marshall wrote: I have submitted a patch to the distributed ntp.conf to enable ntpd pool client functionality. This was not possible in the ancient version of ntpd shipped with FreeBSD releases over the past several years. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201803 Thanks for this. But I would like to make some additional suggestions. There is no need to use multiple pools. You only need one. Pool works by using the minclock and maxclock values to work out how many peers it needs to add and keep track of. minclock is the minimum amount of * and + peers it should keep, and maxclock is the maximum amount of total peers including the actual pool itself. Also the local clock has been deprecated in favour of orphan mode. So I would suggest something like this instead: pool 0.freebsd.pool.ntp.org iburst tos minclock 3 maxclock 6 orphan 6 This will fire up a pool association and then add 5 peers from that pool and keep a minimum of 3 in * or + modes. If any become unreliable it will add more according to the min/maxclock values. For more info: http://support.ntp.org/bin/view/Support/OrphanMode http://lists.ntp.org/pipermail/questions/2010-April/026304.html -- Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Buildworld failure on stable
Trying to do a buildworld from the latest stable seems to result in a failure within openssl. Anyone else seen this? --- ocsp_ext.o --- cc -O2 -pipe -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secu re/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_ DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DAES_ASM -DBSAES_ASM -DVPAES_ASM -DOPENSSL_BN_ASM_MONT -DOP ENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DMD5_ASM -DGHASH_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DWHIRLPOOL_ ASM -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../.. /crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -Qunu sed-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variab le -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversi on -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/secure/lib/libcrypto/.. /../../crypto/openssl/crypto/ocsp/ocsp_ext.c -o ocsp_ext.o --- obj_dat.o --- cc: error: unable to execute command: Bus error (core dumped) cc: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: x86_64-unknown-freebsd10.2 Thread model: posix cc: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash b acktrace, preprocessed source, and associated run script. cc: note: diagnostic msg: Error generating preprocessed source(s). *** [obj_dat.o] Error code 254 make[4]: stopped in /usr/src/secure/lib/libcrypto -- Matt ___ 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: Buildworld failure on stable
On Aug 26 11:09, Slawa Olhovchenkov wrote: On Wed, Aug 26, 2015 at 08:01:25AM +0100, Matt Smith wrote: Trying to do a buildworld from the latest stable seems to result in a failure within openssl. Anyone else seen this? --- ocsp_ext.o --- cc -O2 -pipe -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secu re/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_ DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DAES_ASM -DBSAES_ASM -DVPAES_ASM -DOPENSSL_BN_ASM_MONT -DOP ENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DMD5_ASM -DGHASH_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DWHIRLPOOL_ ASM -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../.. /crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -Qunu sed-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variab le -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversi on -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/secure/lib/libcrypto/.. /../../crypto/openssl/crypto/ocsp/ocsp_ext.c -o ocsp_ext.o --- obj_dat.o --- cc: error: unable to execute command: Bus error (core dumped) cc: error: clang frontend command failed due to signal (use -v to see invocation) Hardware error or memory exhausted It does appear to be something along those lines. It's not memory exhaustion as it has around 2GB free at the point it fails. However I've deleted /usr/obj and started the buildworld again and it failed in a different place with the same error. I'm trying it again without -j4 to see what happens. But isn't looking too good. :( -- Matt ___ 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: Buildworld failure on stable
On Aug 26 13:10, Slawa Olhovchenkov wrote: >Hardware error or memory exhausted It does appear to be something along those lines. It's not memory exhaustion as it has around 2GB free at the point it fails. However I've deleted /usr/obj and started the buildworld again and it failed in a different place with the same error. I'm trying it again without -j4 to see what happens. But isn't looking too good. :( Look like hardware error. RAM/CPU/MB Interestingly it *always* manages to succesfully compile clang etc and it has no issues compiling things from ports. It fails compiling something from lib like openssl or kerberos. Doesn't buildworld build a bootstrap version of clang and then use that version to compile the rest of it? I might try downgrading my sources back to the version that I last succesfully compiled just to prove it one way or the other to myself. -- Matt ___ 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: Buildworld failure on stable
On Aug 26 12:27, Matt Smith wrote: On Aug 26 13:10, Slawa Olhovchenkov wrote: Hardware error or memory exhausted It does appear to be something along those lines. It's not memory exhaustion as it has around 2GB free at the point it fails. However I've deleted /usr/obj and started the buildworld again and it failed in a different place with the same error. I'm trying it again without -j4 to see what happens. But isn't looking too good. :( Look like hardware error. RAM/CPU/MB Interestingly it *always* manages to succesfully compile clang etc and it has no issues compiling things from ports. It fails compiling something from lib like openssl or kerberos. Doesn't buildworld build a bootstrap version of clang and then use that version to compile the rest of it? I might try downgrading my sources back to the version that I last succesfully compiled just to prove it one way or the other to myself. So, been doing some testing. It looks like a -j4 problem with the latest sources. If I buildworld with -j1 then it compiles with no issues at all. If I compile r286908 with -j4 then it compiles with no issues at all. If I try and compile r287155 with -j4 then I get the bus errors. So I'm not convinced at all that it's hardware related at the moment. -- Matt ___ 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: Buildworld failure on stable
On Aug 26 17:35, Chris H wrote: On Wed, 26 Aug 2015 18:38:46 +0100 Matt Smith wrote On Aug 26 12:27, Matt Smith wrote: >On Aug 26 13:10, Slawa Olhovchenkov wrote: >>>>Hardware error or memory exhausted >>> >>>It does appear to be something along those lines. It's not memory >>>exhaustion as it has around 2GB free at the point it fails. However I've >>>deleted /usr/obj and started the buildworld again and it failed in a >>>different place with the same error. I'm trying it again without -j4 to >>>see what happens. But isn't looking too good. :( >> >>Look like hardware error. >>RAM/CPU/MB > >Interestingly it *always* manages to succesfully compile clang etc and >it has no issues compiling things from ports. It fails compiling >something from lib like openssl or kerberos. Doesn't buildworld build >a bootstrap version of clang and then use that version to compile the >rest of it? I might try downgrading my sources back to the version >that I last succesfully compiled just to prove it one way or the other >to myself. > So, been doing some testing. It looks like a -j4 problem with the latest sources. If I buildworld with -j1 then it compiles with no issues at all. If I compile r286908 with -j4 then it compiles with no issues at all. If I try and compile r287155 with -j4 then I get the bus errors. So I'm not convinced at all that it's hardware related at the moment. Not saying it is. But it still could be a region of CPU cache that never got exercised, or in the right (same) manner. Maybe use a CPU/RAM test program, just to be sure? --Chris Could be something wrong with it for sure. However I installed the world/kernel that I had succesfully compiled with the -j1, then I repeatedly tried more buildworlds with -j4 again. Can't get it to go wrong at all now. It has 4 cores which is why I'm using j4 by the way. I've run buildworld since with -j4 three different times, every one has worked. So either there is a hardware issue which for some reason I'm no longer hitting, or there may have been something weird with having r286908 installed whilst trying to compile r287155 with j4. I really have no idea at this point. It's working now though, so I think I'll just see what happens over the next couple of months when I try further buildworlds. If it ever happens again then I'll do further tests, or just buy new hardware! Thanks for all your advice though guys. -- Matt ___ 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 the sshd hits the fan
On Sep 23 12:44, Kurt Jaeger wrote: It did enter the PR system. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190447 I'll have a look at it, it annoys me as well 8-} If this type of thing is being done on the base system sshd it would also be useful to look at the port version of ssh as well? I use the port and it has always annoyed me that I get constant "connection refused" whilst I'm waiting for the server to fully boot up! -- Matt ___ 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"
HEADS UP: TCP CUBIC Broken on 12.0-RELEASE/STABLE
Hi all: Just a heads-up for those beginning to test or use FreeBSD 12.0-RELEASE or 12/STABLE, the alternate TCP congestion control algorithm CUBIC (cc_cubic) is currently broken and causes complete stalls of certain network traffic (e.g., rsync, git checkouts, etc.), as well as what appears to be erratic behavior even for basic SSH. I first noticed on a Digital Ocean VM upgraded from 11.2-RELEASE, but was then able to consistently reproduce on a fresh 12.0-RELEASE AWS EC2 instance merely by loading and enabling cc_cubic instead of the default CC, newreno. H-TCP (cc_htcp) was also tested, but the problem is isolated to CUBIC. After some discussion on Twitter with Colin Percival, Hiren Panchasara, and others (thank you!), it was determined that the culprit was r331567 which hadn’t been reverted prior to 12.0-RELEASE. For those with custom kernels, reverting that revision in 12/STABLE will fix the problem with cc_cubic (sys/netinet/cc/cc.h, sys/netinet/cc/cc_cubic.c, sys/netinet/cc/cc_cubic.h); for those running GENERIC 12.0-RELEASE kernels, the only immediate workaround is to use newreno or cc_htcp in the meantime. Hiren has already reverted in HEAD (r342127), and an Errata Notice will hopefully be published at some point in January after the holidays. Hope this saves some troubleshooting! — Thanks, -Matt Garber ___ 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: HEADS UP: TCP CUBIC Broken on 12.0-RELEASE/STABLE
On Sun, Dec 16, 2018 at 11:44 AM Kurt Jaeger wrote:
> Will CUBIC be used if the system is running 12.0, or does it only happen
> if one actively configures the use of the algorithm ?
>
> Can the use be detected somehow ?
>
This only happens if someone explicitly configured the use of the alternate
CC: by setting "cc_cubic_load=YES" in loader.conf{.local}, and setting
"net.inet.tcp.cc.algorithm=cubic" in sysctl.conf. These values deviate from
the default FreeBSD use of newreno, so they must have been set by the admin
at some point, either in a previous release that's been upgraded over time
(like my original discovery), or on a fresh 12.0-RELEASE/STABLE box using
some kind of configuration control or manual setup.
Simplistic instructions to check on a running system could use `sysctl
net.inet.tcp.cc.algorithm` and check that return value for 'cubic'; if it
returns 'newreno', it's the default, and if it returns something else
(e.g., 'htcp') they're also unaffected in this particular case. If they are
using cubic, it should either be changed in loader.conf{.local} and
sysctl.conf back to newreno or another CC prior to upgrading to
12.0-RELEASE/STABLE, or they should wait until the Errata Notice is
hopefully released with the reverted change. Otherwise they'll encounter
the same network connection stalls and problems.
--
Thanks,
-Matt Garber
___
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: Upgrading 11.2 -> 12.0 on EC2
> On Dec 19, 2018, at 1:50 AM, Brian Neal wrote: > > I’m looking for advice on doing a release upgrade of a running instance. It > looks like the normal procedure using freebsd-update requires a reboot > between invocations of the install command, but after the first reboot, most > of the userland is non-functional, including most importantly sshd. Is it > safe to run the install commands back to back without rebooting? Or is the > only safe procedure to build a new instance from scratch for each release? Brian, It’s not true that after the first reboot the userland is non-functional; sshd and friends should still be working fine. The first reboot switches you to the 12.0 kernel, which is necessary as the first step before upgrading the userland to 12.0 – and of course potentially using `pkg-static` or ports to rebuild/reinstall your packages/ports against the new ABI. If you’re running any kind of public-facing service, the safest method in my opinion *with as little downtime as possible* is to deploy a new instance and then point to it once everything is successfully reinstalled (e.g., DNS change, elastic IP change, elastic load balancer, etc.). Otherwise, the “safe” method to upgrade in place is to follow what the handbook says, including when to reboot between invocations of `freebsd-update`. As long as you follow exactly when it instructs a reboot, and when to upgrade/reinstall userland and packages/ports, you should be fine. If you’re still nervous, just snapshot your boot EBS volume first as an extra precautionary measure, and destroy it once you verify everything post-upgrade. -- Matt Garber ___ 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: Upgrading 11.2 -> 12.0 on EC2
> On Dec 19, 2018, at 1:24 PM, Brian Neal wrote: > > Thanks, Matt. I did try the update procedure from the handbook and found the > instance hanging on boot with a repeated socket error. If I have to rebuild > from scratch, I’d prefer to find some jail/deployment-automation so I don’t > have to manually rebuild everything on each release. FWIW, I did have to > recreate the instance when moving from 10 to 11. I’m assuming that error, ‘sockstat input size mismatch’, was encountered during the very first reboot to the new 12.0 kernel? In that case, perhaps there’s an EC2-specific issue at play, since at that point userland and package updates haven’t even come into the picture yet. I’ve performed several 11.2 -> 12.0 upgrades on Digital Ocean (KVM hypervisor) within the past week without any kernel problems, but in your case the safest choice could simply be new instances, one of the things thankfully made nicest by the various cloud providers. I’d also very much recommend looking into some kind of new system automation to make things easier for you – whether it’s a full-blown official thing like Ansible or Puppet, or even just maintaining a giant shell script which you can use on fresh instances, so you’re not having to re-edit config. files by hand each time. -- Matt Garber ___ 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: Any suggestions for a layer 3 load ablancer for 12, as relayd doesnt work anymore
> On Jan 15, 2019, at 9:43 AM, Pete French wrote: > > Thanks for the suggestions - unfortunately both of those (unless I > misread them) terminate the TCP connection and make a new one to > the backends. I was after something where I can see the original IP > address on the socket. Though I could put a procy in front and add > the headers I suppse, but thats a biut more work as it involves changing > the code. > > Interested in the apache traffic manager - I hadnt come across that > one before, tahnks, Pete, For what it’s worth, HAProxy has the PROXY protocol for exactly the scenario you’re describing; I’ve heard it’s very straightforward and powerful to use, although haven’t had to use it on any of my HAProxy instances which are primarily doing L7. https://www.haproxy.com/blog/preserve-source-ip-address-despite-reverse-proxies/ Thanks, — Matt Garber ___ 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: Issue with mod_security3
On Jan 22, 2019, at 1:54 PM, Gregory Byshenk wrote: > > On Tue, Jan 22, 2019 at 11:29:01AM -0500, SoftwareInforJam wrote: > >> I am have a queer problem with the port mod_security3. I >> actually want to set it up to work with NGINX. The port >> /usr/ports/www/mod_security3 exists but when I do a >> # pkg install mod_security3 >> I get >> ???pkg: No packages available to install matching 'mod_security3' >> have been found in the repositories??? >> >> When I do a pkg search ???mod_security*??? only >> ap24-mod_security-2.9.2_3 Intrusion detection and prevention >> engine. So only version 2.9 shows up. Not sure why this is >> happening. Can anyone shed some light on this please? > > I'm no expert on mod_security, but my guess, based on reading > https://www.linuxjournal.com/content/modsecurity-and-nginx, > is that previous (to v3) versions of mod_security worked > _only_ with apache. > > And it seems likely that the port has not yet been updated to > the newest v3. > > Also based on the article, it seems that getting even mod_security > v3 to work with nginx is slightly complicated, as building it > depends on the specific version of nginx that is installed. ModSecurity 3 – working natively with nginx – is significantly different than prior versions, although in this case I think it’s merely a matter of not searching for the correct package name: here are the two packages (not ports) available – note the name change for v3. You’ll need to install ‘modsecurity3’ via packages for that version. (Your search for mod_security* was too restrictive and didn’t show you the v3 package, since it omits the underscore.) $ pkg search mod | grep security ap24-mod_security-2.9.2_3 Intrusion detection and prevention engine modsecurity3-3.0.3_1 Intrusion detection and prevention engine Thanks, — Matt Garber ___ 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: Issue with mod_security3
port to add in the integration of ModSecurity3-nginx if you care about that more than keeping up-to-date with nginx source separately, but then you’d have to avoid overwriting the port – YMMV. Thanks, — Matt Garber ___ 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: X11 on Ryzen 2400G?
> On Jan 30, 2019, at 12:57 PM, Phil Norman wrote: > > My understanding is that the driver is likely borrowed from linux, and > (from http://forum.mxlinux.org/viewtopic.php?t=46887) Vega support only > started working with linux kernel 1.19. The /var/log/Xorg.0.log file says > that the amdgpu module was 'compiled for 1.18.4, module version = 18.1.0'. > Does the 1.18.4 refer to a linux kernel version? If so, what's my best > solution here? Should I just wait until the FreeBSD drivers are updated? Is > there anything I can do in the meantime? Just a point of clarification, I think you’re mixing version numbers up a bit: the Linux kernel version discussed in that forum refers to kernel 4.19 (released Oct 22, 2018), not 1.19. The “compiled for 1.18.4” line is referring to the Xorg server version, not a Linux kernel version (there never was a Linux kernel 1.18, it jumped from patches against 1.0 to 1.1.x versions around ~April-May 1994. Depending on where your amdgpu module came from (e.g., if you compiled it yourself), the first thing I’d verify as a starter is that the “compiled for” version actually matches the Xorg server version you have installed via packages/ports/etc. Thanks, — Matt Garber ___ 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: FreeBSD flood of 8 breakage announcements in 3 mins.
> On May 15, 2019, at 12:12 PM, Will Andrews wrote: > > On Wed, May 15, 2019 at 10:45 AM Julian H. Stacey wrote: > >> Batching also means some of these vulnerabilities could have been >> fixed earlier & less of a surge of demand on recipient admins time. >> >> An admin can find time to ameliorate 1 bug, not 8 suddenly together. >> Avoidance is called planning ahead. Giving warning of a workload. >> Like an admin plans ahead & announces an outage schedule for planned >> upgrade. >> >> Suddenly dumping 8 on admins causes overload on admin manpower. >> 8 reason for users to approach admin in parallel & say >> "FreeBSD seems riddled, how long will all the sudden unplanned >> outages take ? Should we just dump it ?" >> Dont want negative PR & lack of management. >> > > What admins prefer 8 downtime events instead of 1? > > —Will. Exactly. If batching 8 (or more) individual bugs/issues together into one release is really causing admin/manpower overload and angst, then maybe it’s time in your situation to use the binary updates (which would only be a single `freebsd-update` and reboot, so there would be no ‘sudden unplanned outages’) rather than tracking src and remediating each individual bug at a time. I understand that might be mutually exclusive with other reasons why you don’t already use binary updates or prefer to track src for the base system, but there are always compromises and trade-offs to everything, and batching seems preferable to any alternatives. You’d seriously want to run reboots across a server fleet every other day for two weeks if there were 8 separate patches staggered out? That’s insanity, and is way more of a PR problem from a ‘should we just dump it’ perspective. You mention ‘announces an outage schedule for planned upgrade’, but that’s really its own form of internal batching – it shouldn’t make any difference if you’re technically pushing 1 or 8 bug/security fixes during that pre-identified period of time: all of your other internal processes like maintaining a test group for detecting regressions, using boot environments (or other storage features) to allow for rollbacks, etc. all continue to work as intended. Any potential negative PR within your company/organization seems like it would be related to how else you’re handling the upgrade process(es), not whether the fixes are batched or not. Whatever other negative things you can say about them, I don’t hear enterprise admins begging that Microsoft/Oracle/whoever would dribble out patches one at a time each week instead of combining them like they do; it seems like it works just fine for everyone else. ¯\_(ツ)_/¯ Thanks, — Matt Garber ___ 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"
