Re: zfs native encryption best practices on RELENG13
On 4/23/21 11:23 PM, Xin Li via freebsd-stable wrote: I think loader do not support the native OpenZFS encryption yet. However, you can encrypt non-essential datasets on a boot pool (that is, if com.datto:encryption is "active" AND the bootfs dataset is not encrypted, you can still boot from it). This is what my tests showed too (on 12.2 with OpenZFS from ports). This is in contrast to what is written here: https://openzfs.github.io/openzfs-docs/Getting%20Started/FreeBSD.html Can we get that page corrected? bye & Thanks av. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
On 4/5/21 8:27 PM, Roger Leigh wrote: Can I ask, for those who do enable it, why isn’t “sftp” acceptable (or “scp”)? Because it's an *incompatible* replacement. While I never enabled ftpd, I was once asked to. I refused and enabled sftp instead: the problem was that for 99% of the customers on the other side of the wire, this wasn't the same thing. It was hard to make them change their habits, their clients, etc... That said, I vote for moving ftpd to ports. Just my 2c. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
On 4/5/21 5:28 PM, sth...@nethelp.no wrote: - replace DNS lookups with DoH and/or DoT. Why let your ISP see your DNS traffic? Because I trust my (European) ISP significantly more than I trust big US companies? Yes, I have a pretty good idea what Cloudflare, Google etc have said about the queries they receive. I still don't see a reason to trust them, given their actions in other areas. I agree. Another reason is I often have my internal DNS server. bye av. ___ 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-Announce] FreeBSD Errata Notice FreeBSD-EN-20:14.linuxkpi
On 2020-07-09 16:15, Mark Johnston wrote: This is a different bug, unfortunately. :-( The one fixed by the patch is described in PR 242913. Thanks for the info, anyway. bye av. ___ 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-Announce] FreeBSD Errata Notice FreeBSD-EN-20:14.linuxkpi
On 2020-07-09 10:31, Niclas Zeising wrote: I am unsure, but it seems mostly related to using X forwarding, when looking at the errata notice. Which I'm using heavily... What issues are you seeing, on which hardware? I've extensively wrote about this on x11@, e.g.: https://lists.freebsd.org/pipermail/freebsd-x11/2020-May/025989.html bye & Thanks av. ___ 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-Announce] FreeBSD Errata Notice FreeBSD-EN-20:14.linuxkpi
On 2020-07-08 23:06, FreeBSD Errata Notices wrote: II. Problem Description A bug in one of the LinuxKPI subroutines could cause a kernel panic. Hello. Can we get any reference to this? E.g. a sample stack trace? I've been experiencing panics with the latest x.org and had to revert to an older version. It would be useful to me to know whether we are talking about the same problem, in order to know if it's worth trying the new version again. bye & Thanks av. ___ 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: Long-shot: repeatable macOS samba share unmounting during Lightroom import
On 2019-11-24 21:01, Chris Gordon wrote: Just my 2c... Since updating to Catalina, I've found lots of problems dealing with SMB using the Finder window and the items under the Locations side bar. For instance: - Mount a share. At some point overnight when nothing is using it, the share is unmounted. I can't find anything in the logs to say why, when, what, etc. Just unmounted. I've got a customer who apparently is hit by the same problem: he boots his Mac in the morning and says in the afternoon (some of?) the shares are disconnected with no apparent reasons. I've yet to go and investigate this, but: a) I *think* (not sure) he uses the side bar (although I told him to use Command-K); b) his Mac has NOT been upgraded to Catalina yet. bye av. ___ 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 5/15/19 6:16 PM, Matt Garber wrote: 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. Maybe I'm dumb, but I still don't get what "src vs binary" has to do with "8 vs 1"... I ran a single "svn update; make buildworld; make kernel; make installworld; reboot", not 8... bye av. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS...
On 4/30/19 2:41 AM, Michelle Sullivan wrote: The system was originally built on 9.0, and got upgraded through out the years... zfsd was not available back then. So get your point, but maybe you didn’t realize this blog was a history of 8+ years? That's one of the first things I thought about while reading the original post: what can be inferred from it is that ZFS might not have been that good in the past. It *could* still suffer from the same problems or it *could* have improved and be more resilient. Answering that would be interesting... bye av. ___ 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: FCP-0101: Deprecating most 10/100 Ethernet drivers
On 10/4/18 7:38 PM, Warner Losh wrote: I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc, sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and which I doubt are in use in any FreeBSD system of any age today. I still have a vr integrated on an old MotherBoard. As I said, if it goes away I'll find another solution; if it stays, the better. I doubt it will survive until late 2023, BTW. bye av. ___ 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: Notification for GMirror failures
On 05/09/18 01:51, Jack L. wrote: I use crontab @daily (/sbin/gmirror status | grep -q COMPLETE) || mail -s "gmirror failure" email addy Or you could simply add the following to /etc/periodic.conf[.local]: daily_status_gmirror_enable="YES" bye av. ___ 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: Opteron 6100-series "Magny-Cours"
On 03/25/17 19:02, Andriy Gapon wrote: Does anyone [still] use Opteron 6100-series / "Magny-Cours" processors with FreeBSD? Will an equivalent Athlon do or is this Opteron specific? What would that Athlon be? bye av. ___ 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: Nightly disk-related panic since upgrade to 10.3
On 10/20/16 22:12, Peter wrote: Hello. Basically You have two options: A) fire up kgdb, go into the code and try and understand what exactly is happening. This depends if You have clue enough to go that way; I found "man 4 gdb" and especially the "Debugging Kernel Problems" pdf by Greg Lehey quite helpful. I've tried this way, but altough I'm quite proficient with [k]gdb I tend to get lost in FreeBSD's kernel's source code, which, unfortunately, I'm not familiar with. BTW, I had read that book years ago; I searched for it now, but a 2005 edition still comes up. Has it ever been updated? B) systematically change parameters. Start by figuring from the logs the exact time of crash and what was happening then, try to reproduce that. Then change things and isolate the cause. Again, I already tried, but without luck. Since I had one hang one night during the creation of a snapshot, yesterday I tried creating/deleting around 40 of them: I hoped to get the system to hang again, but it all worked perfectly. Since backups are run at night (possibly at the time of the hangs/panics and doing snapshots), I launched several backup jobs, but they all worked perfectly. I checked that at the times of the panics there is usually no cron job, periodic job or whatever. At least not something I could identify. There was in fact once a periodic running, but that's not the rule. "ps -axl -M /var/crash/vmcore.x" showed nothing unusual. bye & Thanks av. ___ 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"
Nightly disk-related panic since upgrade to 10.3
Hello. Last week I upgraded a 9.3/amd64 box to 10.3: since then, it crashed and rebooted at least once every night. The only exception was on Friday, when it locked without rebooting: it still answered ping request and logins through HTTP would half work; I'm under the impression that the disk subsystem was hung, so ICMP would work since it does no I/O and HTTP too worked as far as no disk access was required. Today I was able to get a couple of (almost identical) dumps: cpuid = 1 KDB: stack backtrace: #0 0x804ee170 at kdb_backtrace+0x60 #1 0x804b4576 at vpanic+0x126 #2 0x804b4443 at panic+0x43 #3 0x8068fd2a at softdep_deallocate_dependencies+0x6a #4 0x805394b5 at brelse+0x145 #5 0x8053793c at bufwrite+0x3c #6 0x806ae20f at ffs_write+0x3df #7 0x8076d519 at VOP_WRITE_APV+0x149 #8 0x806ec7c9 at vnode_pager_generic_putpages+0x2a9 #9 0x8076f3b7 at VOP_PUTPAGES_APV+0xa7 #10 0x806ea6f5 at vnode_pager_putpages+0xc5 #11 0x806e17f8 at vm_pageout_flush+0xc8 #12 0x806db432 at vm_object_page_collect_flush+0x182 #13 0x806db1cd at vm_object_page_clean+0x13d #14 0x806dadbe at vm_object_terminate+0x8e #15 0x806eac60 at vnode_destroy_vobject+0x90 #16 0x806b4232 at ufs_reclaim+0x22 #17 0x8076e5c7 at VOP_RECLAIM_APV+0xa7 Has anyone any better insight on what might be going on? The disks are all connected to a SAS RAID adapter running on mfi; I don't think it might be an hardware issue, since it has worked perfectly for years until I did the upgrade; also mfiutil says everything is ok and nothing mfi-related is in the logs. Some ideas come to mind about which I might use a second opinion: _ soft-update is broken: that would really surprise me, since I've been using that for years on this and several other boxes (10.3 too); _ snapshot creation/deletion is causing this: again I'm using that almost anywhere, so I don't think this might be the cause alone; besides, I've been able to do some dumps without trouble and I don't think anything was messing with snapshots at the time of the last two panics; _ mfi driver is broken on 10.3: this is more reasonable to me, since this is the only machine I have it on and it's the only case where I get this panics. I found https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183618, but I get no "g_vfs_done()..." messages. Any other hint? I'd really like to find out what's going on, I'll appreciate any help and I'm willing to provide any useful info. On the other hand, this is a production server, so I have to solve this really soon. Some idea comes to mind, like disabling softupdate (knowing which file system was having trouble would help here; is there any way to know?), trying to enable journaling, upgrading to 10-STABLE, build a kernel with INVARIANTS/WITNESS/etc..., but I'd appreciate a second opinion before I start shooting in the dark. bye & Thanks av. ___ 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: Call for testing: VM bugs in 10.3
On 08/02/16 21:25, Konstantin Belousov wrote: Below is the merge of some high-profile virtual memory subsystem bug fixes from stable/10 to 10.3. I merged fixes for bugs reported by users, issues which are even theoretically unlikely to occur in real world loads, are not included into the patch set. The later is mostly corrections for the handling of radix insertion failures. Included fixes are for random SIGSEGV delivered to processes, hangs on "vodead" state on filesystem operations, and several others. List of the merged revisions: r301184 prevent parallel object collapses, fixes object lifecycle r301436 do not leak the vm object lock, fixes overcommit disable r302243 avoid the active object marking for vm.vmtotal sysctl, fixes "vodead" hangs r302513 vm_fault() race with the vm_object_collapse(), fixes spurious SIGSEGV r303291 postpone BO_DEAD, fixes panic on fast vnode reclaim I am asking for some testing, it is not necessary for your system to exhibit the problematic behaviour for your testing to be useful. I am more looking for smoke-testing kind of confirmation that patch is fine. Neither I nor people who usually help me with testing, run 10.3 systems. If everything appear to be fine, my intent is to ask re/so to issue Errata Notice with these changes in about a week from now. I upgraded a 10.3/amd64 system which in fact was showing some possibly related troubles. So far so good, since I haven't had any problem: altough it's close to impossible to deterministically reproduce the locks I've had, I saw no regression so far. I plan to upgrade other boxes in some weeks. bye & Thanks av. ___ 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: Call for testing: VM bugs in 10.3
On 08/02/16 21:25, Konstantin Belousov wrote: Below is the merge of some high-profile virtual memory subsystem bug fixes from stable/10 to 10.3. I merged fixes for bugs reported by users, issues which are even theoretically unlikely to occur in real world loads, are not included into the patch set. The later is mostly corrections for the handling of radix insertion failures. Included fixes are for random SIGSEGV delivered to processes, hangs on "vodead" state on filesystem operations, and several others. List of the merged revisions: r301184 prevent parallel object collapses, fixes object lifecycle r301436 do not leak the vm object lock, fixes overcommit disable r302243 avoid the active object marking for vm.vmtotal sysctl, fixes "vodead" hangs r302513 vm_fault() race with the vm_object_collapse(), fixes spurious SIGSEGV r303291 postpone BO_DEAD, fixes panic on fast vnode reclaim I am asking for some testing, it is not necessary for your system to exhibit the problematic behaviour for your testing to be useful. I am more looking for smoke-testing kind of confirmation that patch is fine. Neither I nor people who usually help me with testing, run 10.3 systems. If everything appear to be fine, my intent is to ask re/so to issue Errata Notice with these changes in about a week from now. Hello and thanks for your work. Has this anything to do with https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204764 ? bye & Thanks av. ___ 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: Panic with sym on 10.2
On 01/19/16 15:19, Matthew Seaman wrote: On 01/19/16 13:13, Andrea Venturoli wrote: Two days ago I upgraded a (perfectly working) 9.3/i386 box to 10.2p10 Since then I've had two panics with the following message: panic: assertion "lp->busy_itl==0&>busy_itlq==0" failed: file /usr/src/sys/dev/sym/sym_hipd.c Since the disk controller is involved, I do not get any core and I have to press the reset button. Google showed up no results (I'm not using ZFS, btw) and Bugzilla didn't help either. Any hint on where to go from here? I recommend asking about this on freebsd-stable@... I'm cc:ing and reply-to:ing :) it now. and/or raising a PR in bugzilla. I'd gladly do this, but I though I'd ask for some direction before, since, right now, I have very few details. If there's any more information you can pull out of your system, that would probably be helpful Something in particular? The only thing that comes to my mind is the following: # pciconf -lv ... sym0@pci0:3:5:0: class=0x01 card=0x39071de1 chip=0x000c1000 rev=0x01 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = '53c895' class = mass storage subclass = SCSI The card really is a Tekram DC-390U2W. Oh, and I'm using gmirror with a couple of disks. There's also a zip drive attached (which has always worked), but I've not been using it in the last three days, so it was not "active" when the system paniced. -- even if it's a case of taking a photo of your screen and sticking it on a pasteboard site somewhere. Not much to see, really: the above message (which should be *almost* exact, since I copied it by hand) and a backtrace which doesn't mean much. Nothing else. Hmmm... sym(4) looks like it's fairly elderly, implying the same is probably true of your hardware. Sure. Is it possible your disk controller is succumbing to the vagaries of age? I have never seen any little trouble with such a card (I've had more than one here and at customers'); thought it might actually be dying, I really find it strange that it started as soon as I upgraded from 9.3 to 10.2... bye & Thanks a lot av. ___ 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: Drive failures with ada on FreeBSD-9.1, driver bug or wiring issue?
On 07/18/13 10:25, Bob Bishop wrote: Me too (over a long period, with various hardware). There is a general problem with energy-saving drives that controllers don't understand them. Typically the drive decides to go into some power-saving mode, the controller wants to do some operation, the drive takes too long to come ready, the controller decides the drive has gone away. You have to persuade the controller to wait longer for the drive to come ready, and/or persuade the drive to stay awake. This isn't necessarily easy, eg the controller's ready wait may not be programmable. (Or avoid such drives like the plague, life's too short). Perhaps they are WD Green drives? In that case, other than quoting Bob's suggestion about avoiding them, there's something you can do: a) turn off the drives' power-saving features (this is done through a DOS utility you can download); b) try different controllers and/or different OS releases. You'll find a lot on this problem if you search the web. There's also a report of mine you can search on this ML, regarding FreeBSD specifically. HTH. bye av. ___ 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: Drive failures with ada on FreeBSD-9.1, driver bug or wiring issue?
On 07/18/13 21:13, Dr Josef Karthauser wrote: b) try different controllers and/or different OS releases. I'm committed to FreeBSD, as the machine is already rolled out and in a data centre ;). I said different OS releases, not different OS! I wouln't say such a blasphemy :) bye av. ___ 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: Drive failures with ada on FreeBSD-9.1, driver bug or wiring issue?
On 07/18/13 21:31, Charles Swiger wrote: Updating the firmware and increasing the timeout before these spin down automagically is likely to help, but as Andrea noted, such drives do have quite a history of timeout problems due to excessive head parking and their power conservation attempts. Just for the record, I've been using them for several months without a hitch; it's just a matter of finding the correct settings/firmware/OS version/controller. This is to say you should be able to get them to work, altough you might require some luck (or some sort of divination). bye av. ___ 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: Help review the FAQ
On 11/26/12 23:09, Bas Smeelen wrote: Probable addition 8.8 I get a lot of 'spurious interrupts detected' messages on a modified i386 build kernel and my computer does not work right. What did I do wrong? You have a single processor computer, build your own customized kernel and disabled options SMP (multiprocessor). Probably you also disabled the line below, device apic# I/O APIC This is code for the advanced programmable interrupt controller which also controls interrupts for your attached devices, being ethernet cards and others. Do not disable this device. While I don't know about apic, there used to be KEEP THIS!!! comments in GENERIC's conf file. I guess this would be more on the spot than a FAQ you'd read *after* removing this. Just my 2c. bye av. ___ 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: Help review the FAQ
On 11/23/12 10:25, Lars Engels wrote: I've seen that on almost every USB MP3 player, Android mobile phones and on other USB devices that export an internal memory card. BTW, my disk drive is SCSI attached, so it's not an USB-only issue. But it would be really really really great if someone(TM) would fix it, so the workaround is no longer needed... Yep, that would be really great. bye av. ___ 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: Help review the FAQ
On 11/19/12 18:44, Eitan Adler wrote: Hey all, The FAQ for FreeBSD needs a significant amount of updating and changing. The first step in that process is to figure out what needs to be changed. If you can a take a moment and thoroughly review just one question and add your comments and concerns it would be immensely helpful. http://wiki.freebsd.org/ThwackAFAQ Under serial-communication: Shouldn't USB to serial converters be mentioned? I believe the most common modems nowadays are GSM/3G, which usually plug in through USB, but in fact show up as a ttyU/cuaU. There are several working mobile modems; few are listed in the hardware compatibility page. bye av. ___ 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: Help review the FAQ
On 11/19/12 18:44, Eitan Adler wrote: Hey all, The FAQ for FreeBSD needs a significant amount of updating and changing. The first step in that process is to figure out what needs to be changed. If you can a take a moment and thoroughly review just one question and add your comments and concerns it would be immensely helpful. http://wiki.freebsd.org/ThwackAFAQ Under: removable-drives Would it be worth mentioning no /dev/xxxs1 is created when the device is plugged in after boot? E.G. 1: I have a Zip Drive which is /dev/da1. Everything is fine if a disk is in when I boot, but if I insert the media after boot, /dev/da1s1 is not there. I need to mount /dev/da1 /mnt: this also fails, but now I have /dev/da1s1 and can mount it. E.G. 2: I connect my Android phone with an USB cable: it will be /dev/da7. Again I have no /dev/da7s1 until I dd count=0 if=/dev/random of=/dev/da7. Same happens with CompactFlash, MMC, SD, etc... bye av. ___ 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: confirm that csup is still usable fos the new 9.1
On 11/17/12 21:04, Kevin Oberman wrote: Looks like everything is back up again. Thanks for the good work. Yes, but don't bet that csup and cvs will be around long. I'm aware of this and I'm (adimttedly slowly) moving away from csup. The outage was the result of an intrusion into core FreeBSD systems. Please read the posting at http://www.freebsd.org/news/2012-compromise.html. Read that. It's really time to get away from CVS and I suspect it will be going away sooner than had been planned. I notice that no response has confirmed whether it will be available for 9.1, probably because the security team is still evaluating the situation. Simply out of curiosity, I wonder why csup/cvsup/cvs are less secure than alternatives, say SVN. Why would this compromise be impossible without cvs? Any link on this? bye Thanks av. ___ 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: confirm that csup is still usable fos the new 9.1
On 11/16/12 18:08, Eitan Adler wrote: There are known problems with the cluster at this time. The machines were recently moved, upgraded, and generally manipulated. We are working to fix this as fast as possible. Looks like everything is back up again. Thanks for the good work. bye av. ___ 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: statd/lockd startup failure
On 02/17/11 22:06, Andrea Venturoli wrote: I seem to remember a similar problem I had a long time ago. I opted to use a consistent, not-used port and haven't seen the problem since (this was years ago, so I can't remember if the error you're seeing was identical to mine). /etc/rc.conf: rpc_statd_flags=-p 898 rpc_lockd_flags=-p 4045 I have: rpc_statd_flags=-p 918 rpc_lockd_flags=-p 868 Still statd occasionally fails to start. It might be that something else has already bound to port 918, though I don't know what. I'll check as soon as I have the chance. It happened this morning: lockd could not start and I verified it was an NFS mount which used port 868 as a client. Now I'm trying the noresvport to mount_nfs... bye av. ___ 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: statd/lockd startup failure
On 02/17/11 04:28, Jeremy Chadwick wrote: On Wed, Feb 16, 2011 at 09:46:37PM -0500, Michael Proto wrote: On Wed, Feb 9, 2011 at 9:20 AM,george+free...@m5p.com wrote: Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up (with rpc.statd and rpc.lockd enabled in rc.conf), I get: Feb 4 07:31:11 wonderland rpc.statd: bindresvport_sa: Address already in use Feb 4 07:31:11 wonderland root: /etc/rc: WARNING: failed to start statd and slightly later: Feb 4 07:31:36 wonderland kernel: NLM: unexpected error contacting NSM, stat=5, errno=35 I can start rpc.statd and rpc.lockd manually at this point (and I have to start them to run firefox and mail with my NFS-mounted home directory and mail spool). But what might cause the above errors? -- George Mitchell ___ 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 Don't rpc.statd and lockd try to choose a random port upon startup? Yes, by default. I seem to remember a similar problem I had a long time ago. I opted to use a consistent, not-used port and haven't seen the problem since (this was years ago, so I can't remember if the error you're seeing was identical to mine). /etc/rc.conf: rpc_statd_flags=-p 898 rpc_lockd_flags=-p 4045 I have: rpc_statd_flags=-p 918 rpc_lockd_flags=-p 868 Still statd occasionally fails to start. It might be that something else has already bound to port 918, though I don't know what. I'll check as soon as I have the chance. Locking down the port numbers as you showed is the best choice, plus allows for proper firewall rules to be added. However, be aware not all daemons support this. Reliable firewall rules for NFS = good luck. Since I put the above in rc.conf, I've had more problems with NFS and ipfw. I also vaguely remember some daemons having hooks to open ipfw ports dinamically. bye Thanks av. ___ 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: statd/lockd startup failure
On 02/09/11 15:20, george+free...@m5p.com wrote: Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up (with rpc.statd and rpc.lockd enabled in rc.conf), I get: Feb 4 07:31:11 wonderland rpc.statd: bindresvport_sa: Address already in use Feb 4 07:31:11 wonderland root: /etc/rc: WARNING: failed to start statd and slightly later: Feb 4 07:31:36 wonderland kernel: NLM: unexpected error contacting NSM, stat=5, errno=35 I can start rpc.statd and rpc.lockd manually at this point (and I have to start them to run firefox and mail with my NFS-mounted home directory and mail spool). But what might cause the above errors? -- George Mitchell FWIW I'm seeing this on 8.1 too. statd won't start and after KDE login it's no use anymore starting it manually: I have to reboot. The exact message I get is slightly different, though (no bindresvport_sa, but something else I don't remember). I'll paste it when I'll see it again. bye av. ___ 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: HEADS UP: Major CAM performance regression
Scott Long ha scritto: Hello. The following configurations are known to be affected: VMWare ESX VMWare Fusion (using bt or lsilogic controller options) HP CISS RAID Some MPT-SAS combinations with SATA drives attached (Includes Dell SAS5/ir, but not PERC5/PERC6). Does it holds for any of these? Or do you require a combination of factors? I ask because I have two identical HP machines, one running 7.1p2/amd64, the other still at 7.1-PRERELEASE/amd64 and on both I get: # camcontrol tags da0 (pass1:ciss0:0:0:0): device openings: 254 So it looks like I'm not affected, although I have a ciss RAID. ??? bye Thanks av. ___ 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
NFS Rename problem
Don't know if this is the right place to post: I encountered a non critical error on a 6.2 i386 box and I found no reference to it on the web. Here's the log: Aug 1 10:33:28 soth kernel: kdb_backtrace(e8f18848,c053df25,c0663543,c0663590,cbace6cc,...) at kdb_backtrace+0x29 Aug 1 10:33:28 soth kernel: vfs_badlock(c0663543,c0663590,cbace6cc) at vfs_badlock+0x11 Aug 1 10:33:28 soth kernel: assert_vop_unlocked(cbace6cc,c0663590) at assert_vop_unlocked+0x4d Aug 1 10:33:28 soth kernel: vop_rename_pre(e8f188dc) at vop_rename_pre+0x5f Aug 1 10:33:28 soth kernel: VOP_RENAME_APV(c06a5840,e8f188dc) at VOP_RENAME_APV+0x7a Aug 1 10:33:28 soth kernel: nfsrv_rename(c8d77a00,c6ada080,c6743000,e8f18c98) at nfsrv_rename+0x760 Aug 1 10:33:28 soth kernel: nfssvc_nfsd(c6743000) at nfssvc_nfsd+0x3d9 Aug 1 10:33:28 soth kernel: nfssvc(c6743000,e8f18d04) at nfssvc+0x18c Aug 1 10:33:28 soth kernel: syscall(3b,3b,3b,1,0,...) at syscall+0x25b Aug 1 10:33:28 soth kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Aug 1 10:33:28 soth kernel: --- syscall (155, FreeBSD ELF32, nfssvc), eip = 0x280bd1b7, esp = 0xbfbfeb1c, ebp = 0xbfbfeb38 --- Aug 1 10:33:28 soth kernel: vop_rename: fdvp locked: 0xcbace6cc is locked but should not be What I was trying to do was moving some file through NFS (the logs come from the server); I typed: mv foo/ . The problem was that in foo there was another directory named foo. In case anyone is interested... bye av. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR #193
Kostik Belousov wrote: In a previous (quite old) thread it was in fact suggested I might be seeing some LOR, but only recently I activated all the debugging stuff. The (usual) consequence of the LOR is lock up. Mhh, yes, that's right. But I stopped having locks during file system snapshooting after I upgraded from 5.x to 6.x. What's the risk of running the suggested patch on a (quite critical) production server? It shall be safe unless you run filesystems compiled as modules, that where not built against patched kernel (patch changes the kernel binary interface). Ok, that's not my case. I'll try the patch, but probabily not so soon. bye Thanks av. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR #193
Hello. I'm experiencing the above mentioned LOR on a 6.2p1/amd64 box (running gmirror and SMP if that matters). With reference to your question on http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/031048.html: What application you run that triggers the LOR ? Bacula, I guess. I'm taking filesystem snapshots, running the backup job and deleting the snapshots. In fact I've always seen some problems with some files in the snapshots not being accessible to bacula-fd. In a previous (quite old) thread it was in fact suggested I might be seeing some LOR, but only recently I activated all the debugging stuff. What's the risk of running the suggested patch on a (quite critical) production server? BTW: Sometimes, upon reboot, delayed fscks start and say that the filesystem cannot be fixed with -p and I should run a full fsck. If I reboot in single user mode and run a full fsck, it will find no errors. Also, I have a couple of other boxes on which I run bacula this way and I never experienced this problem: they are respectively i386/gmirror/UP and amd64/hardware RAID/SMP; so, might the combination of amd64/gmirror or gmirror/SMP be in the way? bye Thanks av. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
