Re[2]: pf reply-to malfunction after r258468 (seems r258479)

2013-12-04 Thread Vladimir Sharun
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)

2013-12-04 Thread Gleb Smirnoff
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)

2013-12-04 Thread Gleb Smirnoff
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

2013-12-04 Thread Mark Felder


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 ?

2013-12-04 Thread John Baldwin
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

2013-12-04 Thread Shawn Webb
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

2013-12-04 Thread Kurt Lidl

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

2013-12-04 Thread Julian Elischer

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

2013-12-04 Thread Abhishek Gupta (LIS)
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

2013-12-04 Thread Justin Hibbits
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