Re[2]: pf reply-to malfunction after r258468 (seems r258479)
Dear Gleb, Yesterday I (finally) got my server back to work and the problem disappear. Can't reproduce it anymore on r258865. On Tue, Dec 03, 2013 at 07:54:08PM +0200, Vladimir Sharun wrote: V Dear Gleb, V Unfortunately can't boot both revisions kernel, it hangs on trying to mount root from ssdzfs (which is my zfs root). V Vladimir, You can run the kernel that boots, but update only sys/netpfil/pf directory to suspected revision(s), if you think this is related to changes in pf. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-BETA{3,4} - Consistent Kernel Panics (pf_ioctl.c:1289)
On Tue, Dec 03, 2013 at 11:21:09PM -0800, Craig Rodrigues wrote: C KERNCONF: C C options VIMAGE C C makeoptions DEBUG=-g C C device pf C device pflog C device pfsync C device carp C C C How badly do you need VIMAGE in your kernel config? C There are multiple known problems with VIMAGE + pf. See: C http://lists.freebsd.org/pipermail/freebsd-virtualization/2013-December/001787.html C C We need to fix all these problems in FreeBSD, of course, but someone C needs to spend the time on it. Right now we've got some improvements in the projects/pf branch. As soon as Nikos finished his round of pf+vimage cleanups, I'll merge that to head. However, this particular bug report hasn't yet proved to be tied to vimage. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pf reply-to malfunction after r258468 (seems r258479)
On Wed, Dec 04, 2013 at 10:14:09AM +0200, Vladimir Sharun wrote: V Dear Gleb, V Yesterday I (finally) got my server back to work and the problem disappear. Can't reproduce it anymore on r258865. That is strange. Ok, let's count issue as resolved if it doesn't show up again. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: making PANIC_REBOOT_WAIT_TIME a tunable
On Mon, Dec 2, 2013, at 2:26, Colin Percival wrote: Hi all, It seems that PANIC_REBOOT_WAIT_TIME has been a compile-time setting forever; and I can't see any reason for this, but I assume there was one... at some point in the distant past. The attached patch makes it a loader tunable and sysctl. My reason for wanting this is to make EC2 images reboot faster after a panic (not that it happens very often, of course) -- there's no point waiting for a key press at the console because the EC2 console is output-only. Any objections? I tend to cheat this problem by using watchdog on my hardware servers. This sounds quite convenient as I can't use watchdog in VMs... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] how to get the size of a malloc(9) block ?
On Friday, November 29, 2013 6:16:01 am David Chisnall wrote: On 28 Nov 2013, at 15:13, jb jb.1234a...@gmail.com wrote: Luigi Rizzo rizzo at iet.unipi.it writes: ... But I don't understand why you find ksize()/malloc_usable_size() dangerous. ... The original crime is commited when *usable size* (an implementation detail) is exported (leaked) to the caller. To be blunt, when a caller requests memory of certain size, and its request is satisfied, then it is not its business to learn details beyond that (and they should not be offered as well). The API should be sanitized, in kernel and user space. Otherwise, all kind of charlatans will try to play hair-raising games with it. If the caller wants to track the *requested size* programmatically, it is its business to do it and it can be done very easily. Some of these guys got it perfectly right: http://stackoverflow.com/questions/5813078/is-it-possible-to-find-the-memory-allocated-to-the-pointer-without-searching-fo I disagree. I've encountered several occasions where either locality doesn't matter so much or I know the pointer is aliased, and I'd like increase the size of a relatively large allocation. I have two choices: - Call realloc(), potentially copying a lot of data - Call malloc(), and chain two (or more) allocations together. What I'd like to do is call realloc() if it's effectively free, or call malloc() in other cases. The malloc_useable_size() API is wrong though. In the kernel, realloc() already takes a flag and a M_DONTALLOCATE would make more sense, enlarging the allocation if it can be done without doing the allocate-copy-free dance, but returning NULL and leaving the allocation unmodified if not. This sounds sensible to me. There might be cases where you'd like to know how much you can grow an allocation by for free, and M_DONTALLOCATE doesn't help you with that. In general, I don't like malloc_usable_size(). OTOH, this is C, not C# or Python. Foot-shooting is permitted. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
unbound is extremely slow
So I have unbound running in a vnet jail. Doing a lookup with `host` is pretty responsive, but Chromium's lookups are extremely slow (taking around 30 seconds to resolve). I'm running pretty much a stock config. I've tried turning off DNSSEC, but that doesn't help any. I have num-threads set to 4, though I have 8 cores on this box. I've pasted my config below. Thanks, Shawn server: username: unbound directory: /var/unbound chroot: /var/unbound pidfile: /var/run/local_unbound.pid #auto-trust-anchor-file: /var/unbound/root.key logfile: /var/unbound/unbound.log log-time-ascii: yes log-queries: yes verbosity: 2 interface: 0.0.0.0 interface: ::0 access-control: 0.0.0.0/0 allow access-control: ::0/0 allow prefetch: yes num-threads: 4 include: /var/unbound/forward.conf ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic on sparc64 running 10-beta4
I installed a sparc V120 (4GB memory, dual 72GB disks) with the 10-beta4 install image today. Installation went fine. I rebooted the machine, and then went to get a fresh ports tree, and the machine panic'd: root@host:/usr/ports # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching public key from your-org.portsnap.freebsd.org... done. Fetching snapshot tag from your-org.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Tue Dec 3 19:06:18 EST 2013: 43b6803c6d94efd5b2e2bc9df0b66a84b75417fa3c1728100% of 69 MB 3225 kBps 00m22s Extracting snapshot... done. Verifying snapshot integrity... panic: trap: illegal instruction (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc08836d4 at trap+0x554 Uptime: 6m59s Dumping 4096 MB (4 chunks) chunk at 0: 1073741824 bytes ... ok chunk at 0x4000: 1073741824 bytes ... ok chunk at 0x8000: 1073741824 bytes ... ok chunk at 0xc000: 1073741824 bytes ... ok Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... And then it panic'd again when attempting to run 'savecore'! (I typed a ctrl-t after it printed out the line about writing the core file, that's where the load: 0.72 ... line came from...) savecore: reboot after panic: trap: illegal instruction (kernel) Dec 4 10:49:45 host savecore: reboot after panic: trap: illegal instruction (kernel) savecore: writing core to /var/crash/vmcore.0 load: 0.72 cmd: savecore 906 [physrd] 13.66r 2.75u 2.31s 27% 3192k vmcore.0 6.5% panic: trap: fast data access mmu miss (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc08836d4 at trap+0x554 Uptime: 1m58s Dumping 4096 MB (4 chunks) chunk at 0: 1073741824 bytes ... ok chunk at 0x4000: 1073741824 bytes ... ok chunk at 0x8000: 1073741824 bytes ... ok chunk at 0xc000: 1073741824 bytes ... ok Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Something's rotten with the 10-beta4 binaries for sparc64. -Kurt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: unbound is extremely slow
On 12/4/13, 11:42 PM, Shawn Webb wrote: So I have unbound running in a vnet jail. Doing a lookup with `host` is pretty responsive, but Chromium's lookups are extremely slow (taking around 30 seconds to resolve). I'm running pretty much a stock config. I've tried turning off DNSSEC, but that doesn't help any. I have num-threads set to 4, though I have 8 cores on this box. I've pasted my config below. get a Ktrace of the unbount process along with a a matching simultaneous tcpdump of whatever interface your packets are coming in through. by matching the incoming and outgoing packets with the socket activity, you should be able to isolate what component is taking all the time. Thanks, Shawn server: username: unbound directory: /var/unbound chroot: /var/unbound pidfile: /var/run/local_unbound.pid #auto-trust-anchor-file: /var/unbound/root.key logfile: /var/unbound/unbound.log log-time-ascii: yes log-queries: yes verbosity: 2 interface: 0.0.0.0 interface: ::0 access-control: 0.0.0.0/0 allow access-control: ::0/0 allow prefetch: yes num-threads: 4 include: /var/unbound/forward.conf ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Hyper-V Drivers Not Included in i386 ISO
Hi folks, It appears that Hyper-V drivers are not part of the FreeBSD 10 i386 ISO by default. Please could someone help us include the attached patch in FreeBSD 10? This will save a lot of time and headache for FreeBSD 10 i386 users. We have built a private ISO and have tested the patch locally and it seems to work. Unfortunately we do not have a committed maintainer at our end so are looking for some help. Please let us know if someone could lend a hand. Thanks, Abhishek i386_patch.patch Description: i386_patch.patch ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Request for testing an alternate branch
I've been working on the projects/pmac_pmu branch for some time now to add suspend/resume as well as CPU speed change for certain PowerPC machines, about a year since I created the branch, and now it's stable enough that I want to merge it into HEAD, hence this request. However, it does touch several drivers, turning them into early drivers, such that they can be initialized, and suspended and resumed at a different time. Saying that, I do need testing from other architectures, to make sure I haven't broken anything. The technical details: To get proper ordering, I've extended the bus_generic_suspend() and bus_generic_resume() to do multiple passes. Devices which cannot be enabled or disabled at the current pass level would return an EAGAIN. This could possibly cause problems, since it's an addition to an existing API rather than a new API to run along side it, so it needs a great deal of testing. It works fine on PowerPC, but I don't have any i386/amd64 or sparc64 hardware to test it on, so would like others who do to test it. I don't think that it would impact x86 at all (testing is obviously required), because the nexus is not an EARLY_DRIVER_MODULE, so all devices would be handled at the same pass. But, I do know the sparc64 has an EARLY_DRIVER_MODULE() nexus, so that will likely be impacted. Also, any comments are of course welcome. Technical concerns are obviously welcome, and I will try to address everything. Thanks, Justin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org