from:"John"

This patch adds locking to spic(4) and marks it MPSAFE.  The patch 
is against HEAD but probably applies to 9 and 10 as well.

http://people.freebsd.org/~jhb/patches/spic_locking.patch

-- 
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

[PATCH] Lock scsi_low, ct(4), ncv(4), nsp(4), stg(4)

This patch adds locking to the scsi_low subsystem and the drivers that use it: 
ct(4), ncv(4), nsp(4), and stg(4).  The drivers are all marked MPSAFE.  The 
patch is against HEAD but probably applies to 9 and 10 as well.

http://people.freebsd.org/~jhb/patches/scsi_low_locking.patch

-- 
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

[PATCH] Various fixes to wl(4)

This patch fixes various issues in wl(4) including:

 - Use bus_space instead of inb/outb.
 - Use device_printf() and if_printf()
 - Use callout(9) instead of timeout(9)
 - Don't hold the driver lock across sleeping actions like
   bus_teardown_intr(), subyte(), etc.
 - Don't recurse on the driver lock.

The patch is against HEAD but probably applies to 9 and 10 as well.

http://people.freebsd.org/~jhb/patches/wl_cleanup.patch

-- 
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

[PATCH] Convert bluetooth from timeout(9) to callout(9)

This patch converts the netgraph bluetooth codee from timeout(9) to 
callout(9).  The patch is against HEAD but probably applies to 9 and 10 as 
well.

http://people.freebsd.org/~jhb/patches/bluetooth_callout.patch

-- 
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

[PATCH] Fix si(4) to use bus_space

This patch fixes the si(4) driver to use the bus_space methods to access 
memory and I/O resources instead of directly calling inb()/outb() and using 
rman_get_virtual().  The patch is against HEAD but probably applies to 9 and 
10 as well.

http://people.freebsd.org/~jhb/patches/si_bus_space.patch

-- 
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

[PATCH] Lock scd(4)

This patch adds locking to scd(4) and marks it MPSAFE.  It also uses bus_*() 
instead of bus_space_*().  The patch is against HEAD but probably applies to 9 
and 10 as well.

http://people.freebsd.org/~jhb/patches/scd_locking.patch

-- 
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

[PATCH] Convert tws(4) from timeout(9) to callout(9)

This patch converts tws(4) from timeout(9) to callout(9).  It also fixes a few 
places that were tearing down and setting up in the interrupt handler where it 
was not safe to do so and adds some missing teardown actions.  The patch is 
against HEAD but probably applies to 9 and 10 as well.

http://people.freebsd.org/~jhb/patches/tws_callout.patch

-- 
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

[PATCH] Fix callouts in rp(4)

This patch converts rp(4) from timeout(9) to callout(9).  To do this cleanly, 
it replaces a single, global timer that walks tables of controllers and ports 
to a per-controller timer.  This works much better with locking (since the 
locks are per-controller) and removes the need for various global lookup 
tables in the driver.  The patch is against HEAD but probably applies to 9 and 
10 as well.

http://people.freebsd.org/~jhb/patches/rp_callout.patch

-- 
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

[PATCH] Lock wds(4)

This patch adds locking to wds(4) and marks it MPSAFE.  It also includes 
several other cleanups such as using bus_space instead of inb/outb.  The patch 
is against HEAD but probably applies to 9 and 10 as well.

http://people.freebsd.org/~jhb/patches/wds_locking.patch

-- 
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

Re: libthr and main thread stack size

On Tuesday, September 16, 2014 11:13:24 AM Konstantin Belousov wrote:
 On Mon, Sep 15, 2014 at 03:47:41PM -0600, Justin T. Gibbs wrote:
  On Aug 8, 2014, at 5:22 AM, Konstantin Belousov kostik...@gmail.com
  wrote:
  
  ?
  
   Below is the patch which adds environment variable
   LIBPTHREAD_BIGSTACK_MAIN. Setting it to any value results in the
   main thread stack left as is, and other threads allocate stack
   below the area of RLIMIT_STACK. Try it. I do not want to set this
   behaviour as default.
  
  Is there a reason this should not be the default? Looking at the
  getrlimit() page on the OpenGroup?s site they say:
  
  RLIMIT_STACK This is the maximum size of the initial thread's stack,
  in bytes. The implementation does not automatically grow the stack
  beyond this limit. If this limit is exceeded, SIGSEGV shall be
  generated for the thread. If the thread is blocking SIGSEGV, or the
  process is ignoring or catching SIGSEGV and has not made arrangements
  to use an alternate stack, the disposition of SIGSEGV shall be set to
  SIG_DFL before it is generated.
  
  Does posix say something different?
  
  I ran into this issue when debugging a segfault on Postgres when
  running an (arguably quite bogus) query that should have fit within
  both the configured stack rlimit and Postgres? configured stack limit.
  The Postgres backend is really just single threaded, but happens
  to pull in libpthread due to the threading support in some of the
  libraries it uses. The segfault definitely violates POLA.
  
  ? Justin
 
 I am conservative to not disturb the address space layout in single go.
 If enough people test this setting, I can consider flipping the default
 to the reverse.
 
 I am still curious why the things were done in this way, but nobody
 replied.

I suspect it was done out of reasons of being overly conservative in 
interpreting RLIMIT_STACK.  I think it is quite surprising behavior though and 
would rather we make your option the default and implement what the Open Group 
says above.

-- 
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

[PATCH] Lock mse(4)

This patch adds locking to mse(4) and marks it MPSAFE.  It also adds some 
other cleanups such as using bus_*() instead of bus_space_*() and 
consolidating duplicate copies of its detach routine.  The patch is against 
HEAD but probably applies to 9 and 10 as well.

http://people.freebsd.org/~jhb/patches/mse_locking.patch

-- 
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

Re: Xorg causes panics with multiple drivers (Was: panic: resource_list_alloc: resource entry is busy)

2014-09-15 Thread John Baldwin

On Saturday, September 13, 2014 10:57:53 AM d...@gmx.com wrote:
 John Baldwin wrote on 09/12/2014 23:06:
  X loaded i915kms automatically and
  i915 and i915kms do not get along.  i915 had already allocated the IRQ
  when i915kms tried to alloc the same IRQ causing the issue.
 
 Who is to blame? The user who tried to manually load an unsupported
 combination of modules, or the system, which should have handled things
 gracefully (whether by automatically unloading the first driver, or
 producing a soft-error upon loading the 2nd driver)?
 
 On a side-note, I also had a resource_list_alloc: resource entry is busy
 panic right after switching from the 10.0-supported Xorg to the new Xorg;
 I exited Xorg, enabled FreeBSD_new_Xorg, ran pkg upgrade, then ran
 startx, and got the panic. Surely this wasn't my fault!

I can turn the panic into a resource allocation failure, but specifically with 
KMS I am unsure if it will actually be better.  It depends on when the driver 
does this IRQ allocation.   You may very well end up with a black screen and a 
seemingly hung system (though it would not actually be hung).

I do think we should fix i915kms to fail fast if i915 is loaded, or more 
likely I think we should probably look at removing the old i915 driver from 
HEAD entirely so that 11 doesn't ship with it.  It won't work with the Xorg we 
are shipping with 11, so it's really dead code at this point.

The proposed diff would be:

Index: subr_bus.c
===
--- subr_bus.c  (revision 271627)
+++ subr_bus.c  (working copy)
@@ -3301,7 +3301,10 @@ resource_list_alloc(struct resource_list *rl, devi
rle-flags |= RLE_ALLOCATED;
return (rle-res);
}
-   panic(resource_list_alloc: resource entry is busy);
+   device_printf(bus,
+   resource entry %#x type %d for child %s is busy\n, *rid,
+   type, device_get_nameunit(child));
+   return (NULL);
}
 
if (isdefault) {

-- 
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

Re: panic: resource_list_alloc: resource entry is busy

2014-09-15 Thread John Baldwin

On Friday, September 12, 2014 10:03:26 PM Marcin Cieslak wrote:
 On Fri, 12 Sep 2014, John Baldwin wrote:
  Please note I originally loaded i915.ko, not i915kms.ko
  
  Oh, that is probably your problem.  X loaded i915kms automatically and
  i915 and i915kms do not get along.  i915 had already allocated the IRQ
  when i915kms tried to alloc the same IRQ causing the issue.
 
 Would that be possible to fail with EBUSY or something instead of panic?

Yes, though in this case you probably will end up with a black screen and an 
apparent hang due to how KMS works which wouldn't be a lot better. :(

-- 
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

Re: Driver-specific debugging in buildkernel?

2014-09-15 Thread John Baldwin

On Sunday, September 14, 2014 07:56:16 PM Thomas Mueller wrote:
 I want to build a kernel with debugging for a specific device, rather than
 for everything.
 
 Device of interest is re (Ethernet driver), also rsu (USB wlan adapter).
 
 I looked in Makefiles, also NOTES files, found some DEBUG options but
 nothing really general that could be applied to any desired device in
 kernel or module.
 
 Then I would need to know how to find this debugging information.

There isn't a generic debugging for driver X knob.  You can enable global 
debugging (e.g. INVARIANTS).  Some drivers may have their own internal knobs, 
but most drivers depend on the global knobs.  If you are debugging a driver as 
a module, you can build the kernel with INVARIANT_SUPPORT and just the driver 
with INVARIANTS.  However, drivers invariably make calls into other subsystems 
in the kernel and that setup will not include checking for driver misbehavior 
in its interfacing with those subsystems, so I would generally recommend just 
enabling INVARIANTS globally.

-- 
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

Re: panic: resource_list_alloc: resource entry is busy

2014-09-12 Thread John Baldwin

On Friday, September 12, 2014 05:45:31 PM Marcin Cieslak wrote:
 On Wed, 10 Sep 2014, John Baldwin wrote:
  On Wednesday, September 10, 2014 12:45:08 PM Marcin Cieslak wrote:
  On my CURRENT as of 6 Sep (r271197):
  
  What I did was that:
  
  - kldload i915
  
  - startx
  
  During X server start I get the following:
  
  #10 0x808c2947 in resource_list_alloc (rl=value optimized out,
  bus=value optimized out, child=value optimized out, type=value
  optimized out,
  
   rid=value optimized out, start=value optimized out, end=value
  
  optimized out, count=value optimized out, flags=value optimized out)
  
   at /usr/src/sys/kern/subr_bus.c:3304
  
  #11 0x8061ddae in pci_alloc_resource (dev=value optimized out,
  child=value optimized out, type=value optimized out, rid=value
  optimized out,
  
   start=value optimized out, end=value optimized out, count=value
  
  optimized out, flags=value optimized out) at
  /usr/src/sys/dev/pci/pci.c:4604 #12 0x808c4420 in
  bus_alloc_resource (dev=0xf800026d8800, type=1,
  rid=0x811effc8,
  start=632, end=18446744071580876744, count=464, flags=100707968) at
  bus_if.h:284
  #13 0x80626092 in vga_pci_alloc_resource (dev=0xf800026d8800,
  child=value optimized out, type=1, rid=0xf80008c0b2d4, start=0,
  
   end=value optimized out, count=18446744071580876744, flags=value
  
  optimized out) at /usr/src/sys/dev/pci/vga_pci.c:318
  
  Can you load the core dump in kgdb and run 'f 13' and 'p *rid'?
 
 Sure, here it goes:
 
 (kgdb) f 13
 #13 0x80626092 in vga_pci_alloc_resource (
  dev=0xf800026d8800, child=value optimized out, type=1,
  rid=0xf80008c0b2d4, start=0, end=value optimized out,
  count=18446744071580876744, flags=value optimized out)
  at /usr/src/sys/dev/pci/vga_pci.c:318
 318   return (bus_alloc_resource(dev, type, rid, start, end, count, 
flags));
 Current language:  auto; currently minimal
 (kgdb) p *rid
 $1 = 0

Hmm, type 1 is SYS_RES_IRQ.  IRQ resources should not be marked reserved.

Oh, some other child of vgapci has already allocated the IRQ.  That seems odd.

Can you get 'devinfo -r' output before you kldload i915kms and again after 
doing the kldload?  (No need to run startx)

-- 
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

Re: panic: resource_list_alloc: resource entry is busy

2014-09-12 Thread John Baldwin

On Friday, September 12, 2014 08:57:55 PM Marcin Cieslak wrote:
 On Fri, 12 Sep 2014, John Baldwin wrote:
   at /usr/src/sys/dev/pci/vga_pci.c:318
  
  318return (bus_alloc_resource(dev, type, rid, start, end, 
  count,
  
  flags));
  
  Current language:  auto; currently minimal
  (kgdb) p *rid
  $1 = 0
  
  Hmm, type 1 is SYS_RES_IRQ.  IRQ resources should not be marked reserved.
  
  Oh, some other child of vgapci has already allocated the IRQ.  That seems
  odd.
  
  Can you get 'devinfo -r' output before you kldload i915kms and again after
  doing the kldload?  (No need to run startx)
 
 Please note I originally loaded i915.ko, not i915kms.ko

Oh, that is probably your problem.  X loaded i915kms automatically and
i915 and i915kms do not get along.  i915 had already allocated the IRQ
when i915kms tried to alloc the same IRQ causing the issue.

-- 
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

UEFI cd boots, what it installs doesn't

2014-09-11 Thread John

Hello Currents,

I grabbed FreeBSD-11.0-CURRENT-amd64-20140903-r270990-disc1.iso, burned
it to disk then booted from it. It boots up fine, and it goes through
the install routine fine. The problem is, after the install is finished,
when I try to boot the installed system, it gives me the option to
select 0 or 1. Whatever I select, I get a flashing cursor then nothing.
If I leave it at nothing eventually the bios asks what the problem is.

What am I doing wrong? The board is an Asus Z87-PRO and the disks are
Hitatchi 3TB drives. I'm trying to install to ad1, ad0 is a SSD. I've
tried ad0 ad2 and ad3 to no avail.

PC-BSD will install if the default options are chosen. It installs GRUB.
Ubuntu 14 and Mint 17 also install. I don't want pc-bsd because it
imposes zfs, all I need is freebsd with ufs and gconcat and also /var
and /tmp on the ssd.

thanks,
-- 
John
___
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: UEFI display frozen on Retina MacBook Pro

2014-09-10 Thread John Baldwin

On Wednesday, September 10, 2014 08:03:47 AM Adrian Chadd wrote:
 Would you or someone else please file a PR with that patch? That way
 it doesn't get lost.
 
 https://bugs.freebsd.org/submit/
 
 Thanks!

Please assign it to emaste@ as he had volunteered to commit the patch 
previously.

Also, Ed, regarding the earlier thread about this, I think instead of hacking 
up the EFI headers, we should use the stock headers and adjust our code to use 
whatever naming contentions (CamelCase, etc.) those use.  This is what we do 
with ACPICA for example.

-- 
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

Re: panic: resource_list_alloc: resource entry is busy

2014-09-10 Thread John Baldwin

On Wednesday, September 10, 2014 12:45:08 PM Marcin Cieslak wrote:
 On my CURRENT as of 6 Sep (r271197):
 
 What I did was that:
 
 - kldload i915
 
 - startx
 
 During X server start I get the following:
 
 #10 0x808c2947 in resource_list_alloc (rl=value optimized out,
 bus=value optimized out, child=value optimized out, type=value
 optimized out,
  rid=value optimized out, start=value optimized out, end=value
 optimized out, count=value optimized out, flags=value optimized out)
  at /usr/src/sys/kern/subr_bus.c:3304
 #11 0x8061ddae in pci_alloc_resource (dev=value optimized out,
 child=value optimized out, type=value optimized out, rid=value
 optimized out,
  start=value optimized out, end=value optimized out, count=value
 optimized out, flags=value optimized out) at
 /usr/src/sys/dev/pci/pci.c:4604 #12 0x808c4420 in
 bus_alloc_resource (dev=0xf800026d8800, type=1, rid=0x811effc8,
 start=632, end=18446744071580876744, count=464, flags=100707968) at
 bus_if.h:284
 #13 0x80626092 in vga_pci_alloc_resource (dev=0xf800026d8800,
 child=value optimized out, type=1, rid=0xf80008c0b2d4, start=0,
  end=value optimized out, count=18446744071580876744, flags=value
 optimized out) at /usr/src/sys/dev/pci/vga_pci.c:318

Can you load the core dump in kgdb and run 'f 13' and 'p *rid'?

-- 
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

Re: UEFI display frozen on Retina MacBook Pro

2014-09-09 Thread John Nielsen

On Sep 8, 2014, at 7:21 AM, Anders Bolt Evensen andersb...@icloud.com wrote:

On 05.09.14 19:37, John Nielsen wrote:
On Sep 5, 2014, at 11:30 AM, Glen Barber g...@freebsd.org wrote:

On Fri, Sep 05, 2014 at 11:20:21AM -0600, John Nielsen wrote:
I have a MacBook Pro Retina, Mid 2012 (MacBookPro10,1) on which I'd like
to be able to boot FreeBSD from an external USB drive. For testing I've
been using the mini-memstick images from the -CURRENT snapshots, most
recently the one from 20140903.

I am able to select EFI Boot on the USB device from the Mac's boot menu,
and it does _something_, but the screen never changes--the image of the
boot menu is displayed indefinitely. I think it is actually booting since
there is drive activity and the caps lock key indicator starts working a
few seconds in, but the screen just stays the same. Thinking the
resolution of the Retina display may have been an issue, I tried booting
with it disabled (lid closed) and an external monitor and keyboard. The
result was the same--Mac boot menu frozen on the external display.

Is there anything I should try to troubleshoot or debug this issue?
Anything else I should include in a PR? I can test patches if needed
(probably after building an image including the patch from a VM).

To be clear, which boot menu do you see? If you see the FreeBSD loader
menu, escape to the loader prompt and try:

set kern.vty=vt
set hw.vga.textmode=1
boot

I am a bit unclear under which conditions 'hw.vga.textmode=1' is
required, though.
No, I don't ever see the FreeBSD loader. I see the menu you get on a Mac
when you hold down the option (alt) key while booting--big disk icons
representing the bootable disks/partitions in the system. In my case it was
the Macintosh HD volume (Mac OS Mavericks), my Windows partition, and the
USB stick with the FreeBSD memstick image on it, which the Mac just called
EFI Boot (and the icon was that of a USB disk). There is also a little
section at the bottom that allows wifi network booting (if you've done all
the black magic (not PXE) to get that to happen). It shows a circular
activity animation while it scans for wireless networks. That animation
stops when I select the USB EFI icon and press enter (and that is the only
visual indication I get that I made a selection).

To see the FreeBSD (U)EFI boot loader on the Mac, you need to install an EFI
shell like rEFIt on either your hard drive or a HFS formatted memory stick:
1) Download the rEFIt installer from here:
http://downloads.sourceforge.net/project/refit/rEFIt/0.14/rEFIt-0.14.dmg?r=http%3A%2F%2Frefit.sourceforge.net%2Fts=1410181876use_mirror=optimate
2) Open the downloaded file
3) Run the following command from the terminal: sudo installer -pkg
/Volumes/rEFIt/rEFIt.mpkg -tgt /Volumes/memstick (in this example, I'm using
an HFS formatted memory stick).
4) Run the command sudo /Volumes/memstick/efi/enable.sh
5) When you reboot your Mac, when you hold down the alt key, choose rEFIt on
the startup menu. Then, choose the BOOTx64.efi from … option
If everything now goes as it should, you should see the FreeBSD loader. When
the Press enter to boot or any other key to go to loader in X seconds (or
whatever it says), press a random key. Then try to type the commands
suggested by [Glen Barber].

Thanks all, made _some_ progress.

I installed rEFInd on my internal hard drive and now I can get to (and see!)
the FreeBSD EFI loader. Unfortunately that's about as far as it gets. Once I
tell the loader to boot it displays the EFI framebuffer information and then
nothing else. This happens with 'kern.vty=vt' set and with or without
'hw.vga.textmode=1'.

Screenshot here: https://blog.jnielsen.net/images/efiloader.jpg

What should the next troubleshooting steps be?

___
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: ddb_enable=YES by default?

2014-09-05 Thread John Baldwin

On Thursday, September 04, 2014 8:02:55 pm Craig Rodrigues wrote:
 Brooks,
 
 In r178450, you set the default of ddb_enable to NO:
 
 
 r178450 | brooks | 2008-04-23 15:40:59 -0700 (Wed, 23 Apr 2008) | 4 lines
 Changed paths:
M /head/etc/defaults/rc.conf
 
 Revert rev 1.332 and keep ddb scripts off by default for now.  Minidumps
 are more flexable and much text-dump like output can be produced from
 them so there's a good argument they are a better default.
 
 Index: head/etc/defaults/rc.conf
 ===
 --- head/etc/defaults/rc.conf(revision 178449)
 +++ head/etc/defaults/rc.conf(revision 178450)
 @@ -33,7 +33,7 @@
  apm_enable=NO# Set to YES to enable APM BIOS functions (or NO).
  apmd_enable=NO# Run apmd to handle APM event from userland.
  apmd_flags=# Flags to apmd (if enabled).
 -ddb_enable=YES# Load ddb scripts at boot.
 +ddb_enable=NO# Set to YES to load ddb scripts at boot.
  ddb_config=/etc/ddb.conf# ddb(8) config file.
  devd_enable=YES # Run devd, to trigger programs on device tree changes.
  devd_flags=# Additional flags for devd(8).
 
 
 
 Do you think this is OK to enable by default now?
 Developers who know what they are doing can turn it off in /etc/rc.conf.
 
 For the average end-user, this is super useful, because
 it loads the ddb rules in /etc/ddb.conf, which do
 useful things like enable textdumps, show all the locks, show all the
 locked vnodes,
 and reboots the box.
 
 This will allow end-users who have a problem in the field with FreeBSD,
 and are not kernel debugging experts, to get a lot of useful diagnostic
 info that can be reported back to developers on the mailing lists.
 
 Right now, a lot of times, people take camera pictures of their screen at the
 ddb prompt.  That's pretty painful. :)

Probably at least 50% of the time when I work with a user on a bug report,
I ask them to go into kgdb and run specific commands to extract more detailed
info (print some struct, etc.).  You can'd do that with text dumps.  All that
info is thrown away when the machine reboots.  OTOH, /var/crash/core.txt.N
provides much of the same information automatically from a minidump (and I've
seen users posting URLs to the file).  You can also implement many of the
more advanced ddb commands like 'show lockedvnodes' using gdb scripts against
a minidump (see 'lockedvnodes' command in www.freebsd.org/~jhb/gdb/gdb6).

In short, minidumps still provide far more information and can almost completely
replicate the functionality of textdumps.

-- 
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

request for documentation of m_uiotombuf and m_mbuftouio...

2014-09-05 Thread John-Mark Gurney

If someone would like to write a man page for these functions, I'll
fix them up and commit them...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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

UEFI display frozen on Retina MacBook Pro

2014-09-05 Thread John Nielsen

I have a MacBook Pro Retina, Mid 2012 (MacBookPro10,1) on which I'd like to 
be able to boot FreeBSD from an external USB drive. For testing I've been using 
the mini-memstick images from the -CURRENT snapshots, most recently the one 
from 20140903.

I am able to select EFI Boot on the USB device from the Mac's boot menu, and 
it does _something_, but the screen never changes--the image of the boot menu 
is displayed indefinitely. I think it is actually booting since there is drive 
activity and the caps lock key indicator starts working a few seconds in, but 
the screen just stays the same. Thinking the resolution of the Retina display 
may have been an issue, I tried booting with it disabled (lid closed) and an 
external monitor and keyboard. The result was the same--Mac boot menu frozen on 
the external display.

Is there anything I should try to troubleshoot or debug this issue? Anything 
else I should include in a PR? I can test patches if needed (probably after 
building an image including the patch from a VM).

Thanks,

JN

___
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: UEFI display frozen on Retina MacBook Pro

2014-09-05 Thread John Nielsen

On Sep 5, 2014, at 11:30 AM, Glen Barber g...@freebsd.org wrote:

 On Fri, Sep 05, 2014 at 11:20:21AM -0600, John Nielsen wrote:
 I have a MacBook Pro Retina, Mid 2012 (MacBookPro10,1) on which I'd like 
 to be able to boot FreeBSD from an external USB drive. For testing I've been 
 using the mini-memstick images from the -CURRENT snapshots, most recently 
 the one from 20140903.
 
 I am able to select EFI Boot on the USB device from the Mac's boot menu, 
 and it does _something_, but the screen never changes--the image of the boot 
 menu is displayed indefinitely. I think it is actually booting since there 
 is drive activity and the caps lock key indicator starts working a few 
 seconds in, but the screen just stays the same. Thinking the resolution of 
 the Retina display may have been an issue, I tried booting with it disabled 
 (lid closed) and an external monitor and keyboard. The result was the 
 same--Mac boot menu frozen on the external display.
 
 Is there anything I should try to troubleshoot or debug this issue? Anything 
 else I should include in a PR? I can test patches if needed (probably after 
 building an image including the patch from a VM).
 
 
 To be clear, which boot menu do you see?  If you see the FreeBSD loader
 menu, escape to the loader prompt and try:
 
set kern.vty=vt
set hw.vga.textmode=1
boot
 
 I am a bit unclear under which conditions 'hw.vga.textmode=1' is
 required, though.

No, I don't ever see the FreeBSD loader. I see the menu you get on a Mac when 
you hold down the option (alt) key while booting--big disk icons representing 
the bootable disks/partitions in the system. In my case it was the Macintosh 
HD volume (Mac OS Mavericks), my Windows partition, and the USB stick with the 
FreeBSD memstick image on it, which the Mac just called EFI Boot (and the 
icon was that of a USB disk). There is also a little section at the bottom that 
allows wifi network booting (if you've done all the black magic (not PXE) to 
get that to happen). It shows a circular activity animation while it scans for 
wireless networks. That animation stops when I select the USB EFI icon and 
press enter (and that is the only visual indication I get that I made a 
selection).

JN

___
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: ddb_enable=YES by default?

2014-09-05 Thread John Baldwin

On Friday, September 05, 2014 5:08:07 pm Peter Wemm wrote:
 On Friday 05 September 2014 13:51:24 Craig Rodrigues wrote:
  On Fri, Sep 5, 2014 at 7:54 AM, John Baldwin j...@freebsd.org wrote:
   Probably at least 50% of the time when I work with a user on a bug report,
   I ask them to go into kgdb and run specific commands to extract more
   detailed info (print some struct, etc.).
  
  Sure, I understand, but you are not working with every user who
  encounters a kernel panic in FreeBSD.  For the average or casual
  FreeBSD user, such as desktop
  users of FreeBSD or PC-BSD, wouldn't it be better
  to have ddb_enable=YES be the default in FreeBSD?  The ddb script
  there does a fairly reasonable
  job of gathering some useful info which can be analyzed later, and
  then rebooting the box.
  
  For more expert users, or people developing products, they can set
  ddb_enable=NO
  and do more advanced debugging.  Or hook into /etc/rc.d/ddb and define
  a different
  ddb script which doesn't do textdumps on kernel panic.
 
 I think what John was saying was at that point it's too late.  The loss of 
 the 
 crash dump means the one shot at getting more information is gone.
 
 For reproducable crashes, yes, an end user could just flip the bit.  But for 
 a 
 one-off, it's too late.

Also, crashinfo is already enabled by default.  If a user enables crash dumps
in the installer, they will have a nice /var/crash/core.txt.N that they can
post to the mailing lists just as easily as the text dump you envision.  And in
fact, I've seen our users already doing this.  (Have you looked at a
/var/crash/core.txt.N file yet?)

-- 
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

Re: [RFC] Patch to improve TSO limitation formula in general

2014-09-05 Thread John-Mark Gurney

Hans Petter Selasky wrote this message on Fri, Sep 05, 2014 at 20:37 +0200:
 I've tested the attached patch with success and would like to have some 
 feedback from other FreeBSD network developers. The problem is that the 
 current TSO limitation only limits the number of bytes that can be 
 transferred in a TSO packet and not the number of mbuf's.
 
 The current solution is to have a quick and dirty custom m_dup() in the 
 TX path to re-allocate the mbuf chains into 4K ones to make it simple. 
 All of this hack can be avoided if the definition of the TSO limit can 
 be changed a bit, like shown here:
 
 
  /*
 + * Structure defining hardware TSO limits.
 + */
 +struct if_tso_limit {
 +   u_int raw_value[0]; /* access all fields as one */
 +   u_char frag_count;  /* maximum number of fragments: 1..255 */
 +   u_char frag_size_log2;  /* maximum fragment size: 2 ** (12..16) */
 +   u_char hdr_size_log2;   /* maximum header size: 2 ** (2..8) */
 +   u_char reserved;/* zero */
 +};

Please make this a union if you really need to access the raw_value,
or just drop it...  Is this done to fit in the u_int t_tsomax that
is in tcpcb?  Also, I couldn't find code, but if the tcp connection
needs to be sent out a different interface that has more restrictive
tso requirements, do we properly handle this case?  My quick reading
of the code seems to imply that we only get the TSO requirements on
connection and never update it...

As these are per if, saving memory by packing them isn't really that
effective these days...  Per the later comments, yes, a shift MAY be
faster than a full mul/div by a cycle or two, but this won't make that
huge of a difference when dealing with it..  If the programmer has to
use crazy macros or do the math EVERY time they use the fields, this
will end up w/ less readable/maintainable code at the cost of improving
performance by maybe .001%, so my vote is for u_int's instead, and
convert to their sizes properly...

Comments on the patch:
You can drop the .reserve initalization...  It is common C knowlege
that unassigned members are assigned zero...

The IF_TSO_LIMIT_CMP macros seems excesive... Do you ever see a need
to use other operators? and if so, would they be useful?  I'd just
convert it to:
#define IF_TSO_LIMIT_EQ(a, b)   ((a)-raw_value[0] == (b)-raw_value[0])

I am a bit puzzled by this code:
+   /* Check if fragment limit will be exceeded */
+   if (cur_frags = rem_frags) {
+   max_len += min(cur_length, rem_frags  
if_hw_tsomax.frag_size_log2);
+   break;
+   }

specificly the max_len += line...  The code seems to say if we would
overrun the remaining frags (maybe you want a  instead of =) we
increase max_len...  seems like if we include this frag that would
put us over the limit that we should just skip it?  (break w/o increasing
max_len)..

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: [PATCH]Modify do_exec() handler to deal with multiple imgact handlers

2014-09-03 Thread John Baldwin

On Tuesday, September 02, 2014 03:59:17 PM Sean Bruno wrote:
 https://reviews.freebsd.org/D696
 
 I found that the binmisc handler was not executing if the shell handler
 fired.  Both were using the same intepreted flag to determine if they
 should run.
 
 This change modifies struct image_params.interpreted to be a bitfield
 instead of a bool flag and assigns one bit to each image activator.
 
 Comments?
 
 sean
 
 Index: sys/kern/imgact_binmisc.c
 ===
 --- sys/kern/imgact_binmisc.c
 +++ sys/kern/imgact_binmisc.c
 @@ -600,12 +600,12 @@
   }
 
   /* No interpreter nesting allowed. */
 - if (imgp-interpreted) {
 + if (imgp-interpreted  IMGACT_BINMISC) {
   mtx_unlock(interp_list_mtx);
   return (ENOEXEC);
   }
 
 - imgp-interpreted = 1;
 + imgp-interpreted |= IMGACT_BINMISC;
 
   if (imgp-args-fname != NULL) {
   fname = imgp-args-fname;
 Index: sys/kern/imgact_shell.c
 ===
 --- sys/kern/imgact_shell.c
 +++ sys/kern/imgact_shell.c
 @@ -115,10 +115,10 @@
* Don't allow a shell script to be the shell for a shell
*  script. :-)
*/
 - if (imgp-interpreted)
 + if (imgp-interpreted  IMGACT_SHELL)
   return (ENOEXEC);
 
 - imgp-interpreted = 1;
 + imgp-interpreted |= IMGACT_SHELL;
 
   /*
* At this point we have the first page of the file mapped.
 Index: sys/sys/imgact.h
 ===
 --- sys/sys/imgact.h
 +++ sys/sys/imgact.h
 @@ -61,7 +61,9 @@
   unsigned long entry_addr; /* entry address of target executable */
   unsigned long reloc_base; /* load address of image */
   char vmspace_destroyed; /* flag - we've blown away original vm space */
 - char interpreted;   /* flag - this executable is interpreted */
 +#define IMGACT_SHELL 0x1
 +#define IMGACT_BINMISC   0x2
 + unsigned char interpreted;  /* mask of interpretes that have run */

s/interpretes/interpreters/

Other than that I think this is fine, though I wonder if it will result
in some unexpected effects (you probably want to be able to use a binmisc
binary as the #! interpreter for a script, but I'm not sure the opposite
is true.

-- 
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

Re: Kernel page fault with non-sleepable locks held error with kernel r270837

2014-08-31 Thread John-Mark Gurney

 Analog Mic) at nid 24 on hdaa0
 random: unblocking device.
 usbus0: 12Mbps Full Speed USB v1.0
 usbus1: 12Mbps Full Speed USB v1.0
 usbus2: 12Mbps Full Speed USB v1.0
 usbus3: 12Mbps Full Speed USB v1.0
 usbus4: 480Mbps High Speed USB v2.0
 ugen4.1: Intel at usbus4
 uhub0: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus4
 ugen3.1: Intel at usbus3
 uhub1: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus3
 ugen2.1: Intel at usbus2
 uhub2: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2
 ugen1.1: Intel at usbus1
 uhub3: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1
 ugen0.1: Intel at usbus0
 uhub4: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0
 uhub1: 2 ports with 2 removable, self powered
 uhub2: 2 ports with 2 removable, self powered
 uhub3: 2 ports with 2 removable, self powered
 uhub4: 2 ports with 2 removable, self powered
 ada0 at ata0 bus 0 scbus0 target 0 lun 0
 ada0: WDC WD1600BEVT-22ZCT0 11.01A11 ATA-8 SATA 2.x device
 ada0: Serial Number WD-WXE908P42038
 ada0: 150.000MB/s transfers (SATA, UDMA5, PIO 8192bytes)
 ada0: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C)
 ada0: Previously was known as ad0
 SMP: AP CPU #1 Launched!
 WARNING: WITNESS option enabled, expect reduced performance.
 Root mount waiting for: usbus4
 Root mount waiting for: usbus4
 uhub0: 8 ports with 8 removable, self powered
 Root mount waiting for: usbus4
 ugen4.2: SuYin at usbus4
 Trying to mount root from ufs:/dev/ada0p2 [rw]...
 ugen4.3: UFD 2.0 at usbus4
 umass0: UFD 2.0 Silicon-Power32G, class 0/0, rev 2.00/1.00, addr 3 on usbus4
 umass0:  SCSI over Bulk-Only; quirks = 0x4100
 umass0:2:0: Attached to scbus2
 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
 da0: UFD 2.0 Silicon-Power32G PMAP Removable Direct Access SCSI-4 device 
 da0: Serial Number 12060164020E60026880FB18954
 da0: 40.000MB/s transfers
 da0: 29557MB (60532992 512 byte sectors: 255H 63S/T 3768C)
 da0: quirks=0x2NO_6_BYTE

 ___
 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

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: Kernel page fault with non-sleepable locks held error with kernel r270837

2014-08-31 Thread John-Mark Gurney

Hiroo Ono () wrote this message on Sun, Aug 31, 2014 at 20:43 +0900:
 Thank you for taking a look into this.
 
 2014-08-31 15:47 GMT+09:00 John-Mark Gurney j...@funkthat.com:
  Hiroo Ono () wrote this message on Sun, Aug 31, 2014 at 14:01 
  +0900:
  During upgrading world and kernel from r26939 to r270837, I got the
  following problem.
  a) the arch is i386
  b) kernel is of r270837, userland is of r26939 (make kernel is done
  and rebooted, make installworld not yet).
  c) booting in single user mode is OK.
  d) during startup of multi-user mode, when dhclient is run, the
  following message appears, and the system freezes:
 
  Starting devd.
  wlan0: link state changed to UP
  Starting webcamd.
  Attached to ugen4.2[0]
  Starting webcready running for ugen4.2.0
  /usr/local/etc/rc.d/webcamd: WARNING: failed to start webcamd
  Starting dhclient.
  DHCPREQUEST on wlan0 to 255.255.255.255 port 67
  DHCPACK from 192.168.8.2
  Kernel page fault with the following non-sleepable locks held:
  exclusive sleep mutex so_rcv (so_rcv) r = 0 (0xc713f078) locked @
  /usr/src/sys/kern/kern_event.c:2005
 
  I'm puzzled by this line number...  This line number doesn't do any
  locks, it is in the function knlist_remove_inevent...
 
 The line 2005 is mtx_lock((struct mtx *)arg); of knlist_mtx_lock()
 https://svnweb.freebsd.org/base/head/sys/kern/kern_event.c?revision=268843view=markup#l2005
 
 this function is assigned to (struct knlist *)-kn_lock in knlist_init()
 https://svnweb.freebsd.org/base/head/sys/kern/kern_event.c?revision=268843view=markup#l2058

Sorry, turns out I had a local patch to my kern_event.c...

Can you find out what line the filt_soread is on?  This will help figure
out if it's kn or so...  If you could get the address of the page fault,
that would also be helpful...

Ok, a similar fix was committed in r133794, and a quick look at the code
doesn't show any knote's that are allocated on the stack anymore...

  KDB stack backtrace:
   rapper+0x2d/frame 0xe8f42710
  kdb_backtrace(c11aaf80,0,c713f078,c119a9e8,7d5,...) at 0xc0b4b160 =
  kdb_backtrace+0x30/frame 0xe8f42778
  witness_warn(5,0,c136b0a0,76fb000,c1833d58,...) at 0xc8b68a52 =
  witness_warn+0x402/frame 0xe8f427c8
  trap_pfault(18,3fd,c0dcc2d0,c1f64a80,c75fa000,...) at 0xc102f46b =
  trap_pfault+0x5b/frame 0xe8f42840
  trap(e8f42988) at 0xc102edcf = trap+0x6cf/frame 0xe8f4297c
  calltrap() at 0xc1017c4c = calltrap+0x6/frame 0xe8f4297c
  filt_soread(c75f7828,0,c119a9e8,48d,0,...) at 0xc0b9837d =
  filt_soread+0x9d/frame 0xe8f429f0
  kqueue_register(c6f59310,1,1,4f5,0,...) at 0xc0ad1457 =
  kqueue_register+0x807/frame 0xe8f42a68
  kern_kevent(c6f59310,7,12c217ce1 = Xint0x80), eip =
 
 calltrap() seems to be invoked by
 SOCKBUF_LOCK_ASSERT(so-so_rcv);
 of filt_soread() in sys/kern/uipc_socket.c
 https://svnweb.freebsd.org/base/head/sys/kern/uipc_socket.c?revision=270664view=markup#l3250
 
 but I do not know where so-so_rcv was previously locked.
 knlist_init_mtx (which then calls knlist_init) is called with
 so-so_rcv in sys/kern/uipc_socket.c in
 line 517: socreate()
 https://svnweb.freebsd.org/base/head/sys/kern/uipc_socket.c?revision=270664view=markup#l517
 and
 line 606: sonewconn()
 https://svnweb.freebsd.org/base/head/sys/kern/uipc_socket.c?revision=270664view=markup#l606
 
 so the problem may be around there.
 but, I cannot track any further.  the system freezes, so I cannot deal with 
 ddb.
 
  But notice the knlist_remove_inevent doesn't appear in the back
  trace...
 
  Can you confirm that your kern_event.c is:
  __FBSDID($FreeBSD: head/sys/kern/kern_event.c 268843 2014-07-18 14:27:04Z 
  bapt
  $);
 
 I checked that it was this revision.
 
  instruction poi = 0x28:0xe8f429f0 fff, type 0x1b
  DHCPREQUEST on wlan0 to 255.255.255.255 port 67
  DHCPACK from 192.168.8.2
 
  e) kernel configuration differs from GENERIC on the following point
  options  VIMAGE
  options  DDB_NUMSYM
  nocpuI486_CPU
  nooptions  VESA
 
 ___
 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

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))

2014-08-26 Thread John Baldwin

On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote:
 On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin j...@freebsd.org wrote:
  On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote:
   Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime):
   Please check in this patch:
   http://www.freebsd.org/cgi/query-pr.cgi?pr=181741
   Please MFC into 9.X
  
   Description of the problem is within PR.
  
   Thanks,
   Yuri
 
  Hello,
 
  I guess this fix should make it into 10.1.
  Can someone check please?
 
  A fix has to make into HEAD first.  I've cc'd Alan who responded to the bug.
  Alan, note that glebius@ already committed the test case to HEAD a while 
  ago.
 
 First, Gleb's testcase needs to be converted to ATF.  This would be a
 good exercise for anybody who's new to ATF and wants some practice.
 Anybody interested?

While that would be nice, I don't know that it's quite fair to require the
test to be converted before working on a possible fix.  The existing test
doesn't seem that hard to run by hand:

% cd work/freebsd/head/tools/regression/sockets/unix_passfd/
% make
...
%  ./unix_passfd 
beginning test1-simplesendfd
test1-simplesendfd passed
...
beginning test8-rigths+creds+payload
unix_passfd: test8-rigths+creds+payload: recvmsg: 24 bytes received

I only say this because in the bug followup you seemed to have described a
possible solution so it seems that you would be able to develop a fix quicker
than other folks since you are already familiar with the issues involved.
(Also, you've fixed other related issues recently.)

-- 
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

Re: gbde destroy doesn't match man page?

2014-08-26 Thread John Baldwin

On Tuesday, August 26, 2014 2:23:12 am Poul-Henning Kamp wrote:
 
 In message 2945485.zemf81r...@ralph.baldwin.cx, John Baldwin writes:
 On Saturday, August 23, 2014 10:16:42 AM Poul-Henning Kamp wrote:
  
  In message 20140820215522.ga92...@bewilderbeast.blackhelicopters.org,
  Michae
  l W. Lucas writes:
  Playing with GBDE for my FreeBSD disk book, on:
  
  # uname -a
  FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23
  11:13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC  amd64
  
  According to the man page, I should be able to destroy all copies of
  the key with gbde destroy device -n -1. It's in the examples. When I
  
  try it I get:
  I think that is an oversight in the code.
 
 Can you expand on this?  I.e. what should the code do if it is fixed?
 
 Hmm, now that I think about it, -n doesn't make sense because any 
 one of the four keys can open the volume as needed to blow away the
 masterkey.
 
 The manual page should just be fixed.

Should the '-n -1' just be removed?  I.e., is 'gbde destroy' sufficient to 
destroy all copies of the key?

-- 
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

Re: did tar(1) loose xz compression support in 11?

2014-08-26 Thread John-Mark Gurney

Chris H wrote this message on Tue, Aug 26, 2014 at 16:32 -0700:
  Chris H bsd-li...@bsdforge.com writes:
 
  On 8/26/14 11:05 AM, Chris H wrote:
  Greetings,
  I'm currently testing 11. My build / install is from about 2 days ago.
  I generally use xz compression, when creating archives. But when I
  attempt the following:
 
  tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file
 
  it returns the following:
 
  tar: Undefined option: `xz:9'
 
  This has always worked in previous versions. Has the syntax changed,
  and the man(1) pages just haven't caught up?
 
  I use:
  tar -cJ --options xz:compression-level=1
  .. on head. Are you using the right syntax?
  Apparently not. Using your example works as expected.
  RELENG_8, and RELENG_9 use short-hand;
  tar -cvJ --options xz:9
 
  Why/when the change to long-hand? Seems a shame. Now I
  get to modify all my scripts, and such. :P Altho I
  don't suppose it'd be a big deal to back out (revert) the
  changes made to tar(1). :)
 
  I can't find any changes that would make the syntax change.  At least,
  not in quite a long while.  Therefore, this change may not be
  intentional. However, I looked at the the manual page from 9.3, and its
  description of the features looks the same as on the latest HEAD, and
  *doesn't* look like leaving out a key (in this case,
  compression-level) is ever compliant.
 
  You might try the latest (or older) libarchive from the ports, and
  compare its behaviour. Also, there are a number (amusingly many, in
  fact) of other ways of specifying these parameters that may be more
  convenient for you, so another look throught the tar(1) manual might
  save you a few minutes.
 Thank you, Lowell. For your extremely informative reply.
 Curious. The man page I read from my freshly built 11-CURRENT indicates
 the following:
 
 xz:compression-level
  A decimal integer from 0 to 9 specifying the xz compres-
  sion level.
 
 As I have always read that (interpreted it). It meant:
 xz:decimal-number (0-9)
 Which is what I've always used. I haven't grepped ports||src
 yet. But if it makes any difference, it came from src -- build/install
 world.
 I'll do some poking around. But all my other boxes (RELENG_8  RELENG_9)
 use xz:decimal-number.
 
 Thanks again, Lowell. For taking the time to respond. Greatly appreciated.

Could it be that previous versions were ignoring the option and not
giving you an error?

It looks like that was the case on my 9.1-PR box:
$tar -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz
-rw---  1 jmg  wheel  38956 Aug 26 17:33 test.txz
$tar --options xz:9 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz
-rw---  1 jmg  wheel  38956 Aug 26 17:33 test.txz
$tar --options xz:1 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz
-rw---  1 jmg  wheel  38956 Aug 26 17:33 test.txz
$tar --options xz:compression-level=1 -cJf test.txz *.patch *.c testcrypt *.h; 
ls -l test.txz
-rw---  1 jmg  wheel  41772 Aug 26 17:34 test.txz
$tar --options xz:compression-level=9 -cJf test.txz *.patch *.c testcrypt *.h; 
ls -l test.txz
-rw---  1 jmg  wheel  38956 Aug 26 17:34 test.txz

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: mkimg used to create gpt image, problem booting

2014-08-25 Thread John-Mark Gurney

Andrey V. Elsukov wrote this message on Mon, Aug 25, 2014 at 19:02 +0400:
 On 25.08.2014 18:40, Marcel Moolenaar wrote:
  Also, now FreeBSD 11.0 uses different first usable LBA. By default it is
  4k aligned. And this creates some incompatibility with older versions.
  You can't do `gpart restore` and get the same table, as you had on older
  system.
  
  It sounds restore is broken then. The restore command
  cannot ever assume anything about the GPT. Including
  the tool that created the GPT. In order to restore a
  GPT, it must be properly backed-up. The backup header
  and table should suffice most of the time for that
  purpose as it's a replica, but as soon as meta-data is
  missing and the restore command has to guess, things
  will go wrong.
 
 `gpart restore` just uses a number of commands to geom_part(4) to create
 partition table similar to what was backed up. If your partition table
 on the old system had a partition that starts from LBA 34, now `gpart
 create` isn't able to create such partition table. Because by default
 the first usable LBA is 40.

Luckily, gpart restore won't work:
# gpart backup /dev/md0
GPT 4
1 freebsd-ufs  8 262144  
# gpart restore md1  /tmp/foob.gpt.back 
gpart: entries '4': Invalid argument

So, we're somewhat safe, guess gpart restore needs to learn how to
handle entries properly

We should fix this, since other OS's might not use 128 for entries..

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: Remove pty(4)

On Wednesday, August 20, 2014 11:00:14 AM Davide Italiano wrote:
 One of my personal goals for 11 is to get rid of cloning mechanism
 entirely, and pty(4) is one of the few in-kernel drivers still relying
 on such mechanism.
 It's not possible, at least to my understanding, converting pty(4) to
 cdevpriv(9) as happened with other drivers. This is mainly because we
 always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and
 userspace loops over ptyXX and after it successfully opens it tries to
 open the other one with the same suffix. So, having a single device is
 not really enough.
 My option, instead, is that of removing pty(4), which is nothing more
 than a compatibility driver, and move pmtx(4) code somewhere else.
 The main drawback of the removal of this is that it makes impossible
 to run FreeBSD = 7 jails and SSH into them. I personally don't
 consider this a huge issue, in light of the fact that FreeBSD-7 has
 been EOL for a long time, but I would like to hear other people
 comments.
 
 The code review for the proposed change can be found here:
 https://reviews.freebsd.org/D659
 
 If I won't get any objection I'll commit this in one week time, i.e.
 August 27th.

Why not just statically create the pairs in /dev?  Use some loader tunable 
(kern.ptymax) to set a count on the number of pre-created device pairs to 
create and then just explicitly create them in the mod_event handler?  It 
could default to 100 or so.

-- 
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

Re: gbde destroy doesn't match man page?

On Saturday, August 23, 2014 10:16:42 AM Poul-Henning Kamp wrote:
 
 In message 20140820215522.ga92...@bewilderbeast.blackhelicopters.org,
 Michae
 l W. Lucas writes:
 Playing with GBDE for my FreeBSD disk book, on:
 
 # uname -a
 FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23
 11:13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC  amd64
 
 According to the man page, I should be able to destroy all copies of
 the key with gbde destroy device -n -1. It's in the examples. When I
 
 try it I get:
 I think that is an oversight in the code.

Can you expand on this?  I.e. what should the code do if it is fixed?

-- 
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

Re: ktrace -c behavior

On Monday, August 25, 2014 09:21:48 AM Eric van Gyzen wrote:
 On 08/24/2014 19:53, John-Mark Gurney wrote:
  Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:26 -0400:
  On 08/22/2014 15:20, John-Mark Gurney wrote:
  Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400:
  What behavior would you expect from this sequence of commands?
  
  ktrace -tw -p 1234
  ktrace -c -p 1234
  
  Based on this...
  
   -c  Clear the trace points associated with the specified file
  
  or processes.
  
  and/or just add specified:
  Clear the specified trace points ...
  
  But what if I didn't specify them?
  
  You specified the default by not specificly specifing any different
  ones.. :)  Confused? :)
 
 Amused.  :)

Adding specified is the first thing that came to my mind as well.

  or maybe selected?
 
 Perhaps, but I didn't select them, either.  My original suggestion is
 more--dare I use this word again--specific.  It explains exactly how the
 command behaves.

But then do we need to annotate every place that uses trace points to add 
this language?  Note that the 'command' description uses the language John-
mark suggested:

 command
 Execute command with the specified trace flags.

My vote would be to add specified to the description of -c, but to improve 
the the description of -t itself from:

 -t trstr
 The string argument represents the kernel trace points, one per
 letter.  The following table equates the letters with the trace-
 points:


to:

 -t trstr
 Specify the list of trace points to enable or disable, one per
 letter.  If an explicit list is not specified, the default set
 of trace points is used.

 The following trace points are supported:


-- 
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

Re: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))

On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote:
  Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime):
  Please check in this patch:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=181741
  Please MFC into 9.X
  
  Description of the problem is within PR.
  
  Thanks,
  Yuri
 
 Hello,
 
 I guess this fix should make it into 10.1.
 Can someone check please?

A fix has to make into HEAD first.  I've cc'd Alan who responded to the bug.  
Alan, note that glebius@ already committed the test case to HEAD a while ago.

-- 
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

Re: mkimg used to create gpt image, problem booting

2014-08-24 Thread John-Mark Gurney

Craig Rodrigues wrote this message on Sun, Aug 24, 2014 at 15:37 -0700:
 On Sun, Aug 24, 2014 at 12:05 PM, Marcel Moolenaar mar...@xcllnt.net wrote:
 
  On Aug 24, 2014, at 9:59 AM, Craig Rodrigues rodr...@freebsd.org wrote:
 
  On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov bu7c...@yandex.ru 
  wrote:
 
  Yes, the problem is in the ptable_gptread() function. I'll commit the fix.
 
 
  Should mkimg be changed to create a partition table with 128 entries
  by default, to match older versions of FreeBSD which do not have this fix?
 
  Maybe. 128 is the suggested default. It's not a hard lower
  limit. Technically speaking, it's perfectly fine to create
  just enough entries to fill a single sector. Then again,
  code makes all kinds of assumptions or has all kinds of
  bugs -- just like the logic in the loader apparently.
 
  By having mkimg create a large table, even if it's knows
  up front that it doesn't have to may prevent broken code
  from tripping over, bit it surely bloats the image for
  no reason.
 
 I see what you are saying.  If you have a new device
 and do gpart create -s GPT, then this value in sys/geom/part/g_part_gpt.c:
 
  .gps_minent = 128,
 
 causes the logic in the g_part_ctl_create() function in sys/geom/part/g_part.c
 to set the number of partitions to 128, and then it calls g_part_ctl_create()
 which creates the partition table with 128 empty entries.
 
 gpart create doesn't know how many partitions you want, so it
 needs to allocate some space up front for the partition table,
 and then you can do gpart add to add the partitions later.
 
 With mkimg, you know exactly how many partitions you are creating
 , so you don't need to specify 128 as the number of partitions.

Though, w/ people dd'ing images onto disks, and using growfs to grow
as necessary, we might want to allocate a few more more than the
minimum...  I do agree that we want to keep sizes to a minimum...

 Since only gpart was available for creating GPT partitions, the side-effect
 of always having 128 partitions hid the bug in the loader.
 
 Hopefully Andrey's fix can be backported to at least stable/9, because
 the loader bug seems to have been there since at least 2012.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: ktrace -c behavior

2014-08-24 Thread John-Mark Gurney

Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:26 -0400:
 On 08/22/2014 15:20, John-Mark Gurney wrote:
  Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400:
  What behavior would you expect from this sequence of commands?
 
  ktrace -tw -p 1234
  ktrace -c -p 1234
 
  Based on this...
 
   -c  Clear the trace points associated with the specified file
  or processes.
  and/or just add specified:
  Clear the specified trace points ...
 
 But what if I didn't specify them?

You specified the default by not specificly specifing any different
ones.. :)  Confused? :)

or maybe selected?

  ...I would expect the second command to clear the trace point for
  context switches.  It doesn't.  I have to specify -tw with the -c to get
  that behavior.  This makes sense; it's just not what I was expecting.
 
  Assuming we want to keep this behavior, can we clarify the -c flag in
  man page?  I would suggest:
 
  If the -t flag is not specified, clear the default set of trace points.
  Maybe we should add a new trace point string that is a (for all).. so
  you can do ktrace -ta -c?
 
 That would be handy.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: ktrace -c behavior

2014-08-22 Thread John-Mark Gurney

Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400:
 What behavior would you expect from this sequence of commands?
 
 ktrace -tw -p 1234
 ktrace -c -p 1234
 
 Based on this...
 
  -c  Clear the trace points associated with the specified file
 or processes.

and/or just add specified:
Clear the specified trace points ...

 ...I would expect the second command to clear the trace point for
 context switches.  It doesn't.  I have to specify -tw with the -c to get
 that behavior.  This makes sense; it's just not what I was expecting.
 
 Assuming we want to keep this behavior, can we clarify the -c flag in
 man page?  I would suggest:
 
 If the -t flag is not specified, clear the default set of trace points.

Maybe we should add a new trace point string that is a (for all).. so
you can do ktrace -ta -c?

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: nscd not caching

2014-08-18 Thread John-Mark Gurney

Eggert, Lars wrote this message on Mon, Aug 18, 2014 at 07:42 +:
 The current NIS server is 25ms away, which is a pain. I'm trying to get a 
 local slave set up, which will make the need for nscd go away, but it would 
 sure be nice if it worked in the meantime.

Why not run a local slave on your server?

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: Inconsistent behavior with dd(1)

2014-08-16 Thread John-Mark Gurney

 in
that out.offset * out.dbsz may overflow and return incorrect results...
We should probably check that the output (cast to off_t) is greater than
both the inputs before calling ftruncate...  This is safe as both are
unsigned...

  }
   }
 
  @@ -262,14 +243,10 @@
   static void
   f_obs(char *arg)
   {
  -   uintmax_t res;
  -
  if (!(ddflags  C_BS)) {
  -   res = get_num(arg);
  -   if (res  1 || res  SSIZE_MAX)
  -   errx(1, obs must be between 1 and %jd,
  -   (intmax_t)SSIZE_MAX);
  -   out.dbsz = (size_t)res;
  +   out.dbsz = get_num(arg);
  +   if (out.dbsz  1)
  +   errx(1, obs must be between 1 and %ju, 
  (uintmax_t)-1);
  }
   }
 
 Again, you eliminated the check for SSIZE_MAX, but dbsz must be signed.
 
 
  @@ -378,11 +355,14 @@
  uintmax_t num, mult, prevnum;
  char *expr;
 
  +   if (val[0] == '-')
  +   errx(1, %s: cannot be negative, oper);
  +
 
 In general, I like this part of the diff.  Every user of get_num
 checks for negative values, so why not move the check into get_num
 itself?  But you changed it from a numeric check to a text check, and
 writing text parsers makes me nervous.  I can't see any problems,
 though.
 
  errno = 0;
  num = strtouq(val, expr, 0);
  if (errno != 0) /* Overflow or underflow. */
  err(1, %s, oper);
  -
  +
  if (expr == val)/* No valid digits. */
  errx(1, %s: illegal numeric value, oper);
 
  Index: bin/dd/dd.c
  ===
  --- bin/dd/dd.c (revision 267712)
  +++ bin/dd/dd.c (working copy)
  @@ -284,8 +284,6 @@
 
  for (;;) {
  switch (cpy_cnt) {
  -   case -1:/* count=0 was specified */
  -   return;
 
 Again, I don't think this will do what you want it to do.  Previously,
 leaving count unspecified resulted in cpy_cnt being 0, and specifying
 count=0 set cpy_cnt to -1.  With your patch, setting count=0 will have
 the same effect as leaving it unspecified.
 
  case 0:
  break;
  default:
 
 

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: PostgreSQL performance on FreeBSD

On Tuesday, August 12, 2014 5:36:26 pm Adrian Chadd wrote:
 On 12 August 2014 11:09, John Baldwin j...@freebsd.org wrote:
  On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
  Hi!
 
 
  On 16 July 2014 06:29, Konstantin Belousov kostik...@gmail.com wrote:
   On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote:
   Hi,
   I did some measurements and hacks to see about the performance and
   scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD
   Foundation.
  
   The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf.
   The uncommitted patches, referenced in the article, are available as
   https://kib.kiev.ua/kib/pig1.patch.txt
   https://kib.kiev.ua/kib/patch-2
  
   A followup to the original paper.
  
   Most importantly, I identified the cause for the drop on the graph
   after the 30 clients, which appeared to be the debugging version
   of malloc(3) in libc.
  
   Also there are some updates on the patches.
  
   New version of the paper is available at
   https://www.kib.kiev.ua/kib/pgsql_perf_v2.0.pdf
   The changes are marked as 'update for version 2.0'.
 
  Would you mind trying a default (non-PRODUCTION) build, but with junk
  filling turned off?
 
  adrian@adrian-hackbox:~ % ls -l /etc/malloc.conf
 
  lrwxr-xr-x  1 root  wheel  10 Jun 24 04:37 /etc/malloc.conf - junk:false
 
  That fixes almost all of the malloc debug performance issues that I
  see without having to recompile.
 
  I'd like to know if you see any after that.
 
  OTOH, I have actually seen junk profiling _improve_ performance in certain
  cases as it forces promotion of allocated pages to superpages since all 
  pages
  are dirtied.  (I have a local hack that adds a new malloc option to 
  explicitly
  memset() new pages allocated via mmap() that gives the same benefit without
  the junking overheadon each malloc() / free(), but it does increase physical
  RAM usage.)
 
 Hm. this isn't a jemalloc config option?

No, jemalloc does have a 'zero fill' option, but that runs on every malloc so
it is just as expensive as junking.  What my hack does is only zero the pages
when they are first mmap'd, so subsequent free() / malloc() cycles that reuse
the pages do not do any zeroing.

-- 
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

Re: PostgreSQL performance on FreeBSD

On Wednesday, August 13, 2014 1:00:22 pm Alan Cox wrote:
 On Tue, Aug 12, 2014 at 1:09 PM, John Baldwin j...@freebsd.org wrote:
 
  On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
   Hi!
  
  
   On 16 July 2014 06:29, Konstantin Belousov kostik...@gmail.com wrote:
On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote:
Hi,
I did some measurements and hacks to see about the performance and
scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD
Foundation.
   
The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf.
The uncommitted patches, referenced in the article, are available as
https://kib.kiev.ua/kib/pig1.patch.txt
https://kib.kiev.ua/kib/patch-2
   
A followup to the original paper.
   
Most importantly, I identified the cause for the drop on the graph
after the 30 clients, which appeared to be the debugging version
of malloc(3) in libc.
   
Also there are some updates on the patches.
   
New version of the paper is available at
https://www.kib.kiev.ua/kib/pgsql_perf_v2.0.pdf
The changes are marked as 'update for version 2.0'.
  
   Would you mind trying a default (non-PRODUCTION) build, but with junk
   filling turned off?
  
   adrian@adrian-hackbox:~ % ls -l /etc/malloc.conf
  
   lrwxr-xr-x  1 root  wheel  10 Jun 24 04:37 /etc/malloc.conf - junk:false
  
   That fixes almost all of the malloc debug performance issues that I
   see without having to recompile.
  
   I'd like to know if you see any after that.
 
  OTOH, I have actually seen junk profiling _improve_ performance in certain
  cases as it forces promotion of allocated pages to superpages since all
  pages
  are dirtied.  (I have a local hack that adds a new malloc option to
  explicitly
  memset() new pages allocated via mmap() that gives the same benefit without
  the junking overheadon each malloc() / free(), but it does increase
  physical
  RAM usage.)
 
 
 
 John,
 
 A couple small steps have been taken toward eliminating the need for this
 hack: the addition of the page size index field to struct vm_page and the
 addition of a similarly named parameter to pmap_enter().  However, at the
 moment, the only tangible effect is in the automatic prefaulting by
 mmap(2).  Instead of establishing 96 4KB page mappings, the automatic
 prefaulting establishes 96 page mappings whose size is determined by the
 size of the physical pages that it finds in the vm object.  So, the
 prefaulting overhead remains constant, but the coverage provided by the
 automatic prefaulting will vary with the underlying page size.

Yes, I think what we might actually want is what I mentioned in person at
BSDCan: some sort of flag to mmap() that malloc() could use to assume that any
reservations are fully used when they are reserved.  This would avoid the need
to wait for all pages to be dirtied before promotion provides a superpage
mapping and would avoid demotions while still allowing the kernel to gracefully
fall back to regular pages if a reservation can't be made.

-- 
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

[PATCH] Add locking to mcd(4)

This patch adds locking to mcd(4) and marks it MPSAFE.  This patch is against 
HEAD but probably applies to 9 and 10 as well.  Please enable INVARIANTS while 
testing.

http://www.FreeBSD.org/~jhb/patches/mcd_locking.patch

-- 
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

[PATCH] Replace timeout(9) with callout(9) in ips(4)

This patch converts the ips(4) driver to the callout(9) API and adds 
additional locking to remove its use of Giant.  The patch is against HEAD but 
probably applies to 9 and 10 as well.  Please test with INVARIANTS enabled.

http://www.FreeBSD.org/~jhb/patches/ips_callout.patch

-- 
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

[PATCH] Switch ofw_console(4) to callout(9)

This patch switches the ofw_console driver from timeout(9) to callout(9).  The 
patch is against HEAD but it probably applies to 9 and 10.  Please test with 
INVARIANTS enabled.

http://www.FreeBSD.org/~jhb/patches/ofw_console_callout.patch

-- 
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

[PATCH] Add locking to iir(4)

This patch fixes various issues in the iir(4) driver and adds locking to make 
it MPSAFE.  The patch is against HEAD though I expect it probably applies to 
9 and 10 as well.  Please test with INVARIANTS enabled.

http://www.FreeBSD.org/~jhb/patches/iir_locking.patch

-- 
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

[PATCH] Add locking to mly(4)

This patch adds locking to mly(4) and marks it MPSAFE.  This patch is against 
HEAD but probably applies to 9 and 10 as well.  Please enable INVARIANTS while 
testing.

http://www.FreeBSD.org/~jhb/patches/mly_locking.patch

-- 
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

[PATCH] Switch pst(4) to callout(9)

This patch switches the pst(4) driver from timeout(9) to callout(9).  It also 
cleans up detach a bit.  The patch is against HEAD but probably applies to 9 
and 10.  Please test with INVARIANTS enabled.

http://www.FreeBSD.org/~jhb/patches/pst_callout.patch

-- 
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

Re: Booting a SuperMicro Superserver

2014-08-12 Thread John Nielsen

On Aug 12, 2014, at 10:32 AM, Barney Cordoba barney_cord...@yahoo.com wrote:

 A continuing issue (with 9.1 previously and now 10) is that FreeBSD 
 occasionally (or always) seems to boot from the 2nd installed drive
 rather than the first. I'd be happy to debug this, but I have no idea if it's 
 bootcode or a BIOS issue. Supermicro pleads innocent, but their bios
 guys are hard to work with and fairly arrogant if you don't specifically 
 isolate something.
 
 The scenario occurs when ada0 is upgraded and has an incompatible kernel with 
 other code on drive ada1.  (note that ada1 is a backup of the pre-upgrade 
 ada0, so it's fstab points to ada0 for mount points). The system will boot 
 and then modules will fail to load. It loads the kernel from
  ada1 and then mounts partitions from ada0; old kernel and newer modules.
 
 The problem is resolved by popping the 2nd drive. So there is nothing wrong 
 with ada0 to cause it to bounce to ada1.
 
 My question: What would cause the system to boot from ada1 instead of ada0? 
 Bios or Bootcode?

BIOS, most likely. If the disk controller in question is onboard you should be 
able to specify which disk(s) and what order they will be booted from. If not, 
you'll need to just say disk controller in the BIOS boot order then go to the 
controllers BIOS to say which disk(s) to boot from and in what order. I have 
recent experience with a SuperMicro box and an LSI controller; the latter 
allows you to specify a (b)oot drive and an (a)lternate. Yes, b comes before a. 
:)

JN

___
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: Booting a SuperMicro Superserver

2014-08-12 Thread John Nielsen

On Aug 12, 2014, at 12:09 PM, Barney Cordoba barney_cord...@yahoo.com wrote:

 On Tuesday, August 12, 2014 1:16 PM, John Nielsen li...@jnielsen.net wrote:
 
 On Aug 12, 2014, at 10:32 AM, Barney Cordoba barney_cord...@yahoo.com 
 wrote:
 
 A continuing issue (with 9.1 previously and now 10) is that FreeBSD 
 occasionally (or always) seems to boot from the 2nd installed drive rather 
 than the first. I'd be happy to debug this, but I have no idea if it's 
 bootcode or a BIOS issue. Supermicro pleads innocent, but their bios guys 
 are hard to work with and fairly arrogant if you don't specifically isolate 
 something.
 
 The scenario occurs when ada0 is upgraded and has an incompatible kernel 
 with other code on drive ada1.  (note that ada1 is a backup of the 
 pre-upgrade ada0, so it's fstab points to ada0 for mount points). The 
 system will boot and then modules will fail to load. It loads the kernel 
 from ada1 and then mounts partitions from ada0; old kernel and newer 
 modules.
 
 The problem is resolved by popping the 2nd drive. So there is nothing wrong 
 with ada0 to cause it to bounce to ada1.
 
 My question: What would cause the system to boot from ada1 instead of ada0? 
 Bios or Bootcode?
 
 BIOS, most likely. If the disk controller in question is onboard you should 
 be able to specify which disk(s) and what order they will be booted from. If 
 not, you'll need to just say disk controller in the BIOS boot order then 
 go to the controllers BIOS to say which disk(s) to boot from and in what 
 order. I have recent experience with a SuperMicro box and an LSI controller; 
 the latter allows you to specify a (b)oot drive and an (a)lternate. Yes, b 
 comes before a. :)
 
 The bios only gives you one choice for HDD. You can't select one of the 4 
 drives to boot from. You can specify USB or CD or HDD, but Not HDD2 or HDD3.

There may be a separate option controlling hard drive boot order, and/or 
there may be a completely separate BIOS program for your drive controller with 
its own hotkey.

JN

___
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: PostgreSQL performance on FreeBSD

2014-08-12 Thread John Baldwin

On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
 Hi!
 
 
 On 16 July 2014 06:29, Konstantin Belousov kostik...@gmail.com wrote:
  On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote:
  Hi,
  I did some measurements and hacks to see about the performance and
  scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD
  Foundation.
 
  The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf.
  The uncommitted patches, referenced in the article, are available as
  https://kib.kiev.ua/kib/pig1.patch.txt
  https://kib.kiev.ua/kib/patch-2
 
  A followup to the original paper.
 
  Most importantly, I identified the cause for the drop on the graph
  after the 30 clients, which appeared to be the debugging version
  of malloc(3) in libc.
 
  Also there are some updates on the patches.
 
  New version of the paper is available at
  https://www.kib.kiev.ua/kib/pgsql_perf_v2.0.pdf
  The changes are marked as 'update for version 2.0'.
 
 Would you mind trying a default (non-PRODUCTION) build, but with junk
 filling turned off?
 
 adrian@adrian-hackbox:~ % ls -l /etc/malloc.conf
 
 lrwxr-xr-x  1 root  wheel  10 Jun 24 04:37 /etc/malloc.conf - junk:false
 
 That fixes almost all of the malloc debug performance issues that I
 see without having to recompile.
 
 I'd like to know if you see any after that.

OTOH, I have actually seen junk profiling _improve_ performance in certain 
cases as it forces promotion of allocated pages to superpages since all pages 
are dirtied.  (I have a local hack that adds a new malloc option to explicitly 
memset() new pages allocated via mmap() that gives the same benefit without 
the junking overheadon each malloc() / free(), but it does increase physical 
RAM usage.)

-- 
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

Re: bsd.sys.mk [-Wno-uninitialized]

2014-08-12 Thread John Baldwin

On Tuesday, July 15, 2014 5:25:50 am Hans Petter Selasky wrote:
 On 07/05/14 15:10, David Chisnall wrote:
  On 5 Jul 2014, at 14:07, Dimitry Andric d...@freebsd.org wrote:
 
  Interestingly, -Wno-uninitialized has been in bsd.sys.mk since r76861,
  and the accompanying comment (XXX Delete -Wuninitialized by default for
  now -- the compiler doesn't always get it right) has never been
  changed. :-)
 
  It is probably time to re-enable that warning after 13 years, at least.
 
  It probably only wants enabling for clang.  GCC (at least, GCC 4.2.1) 
performs this analysis based on analyses run by the optimisers and so the 
warnings are dependent on optimisation level.
 
  David
 
 Hi,
 
 Is someone working on this?

If not, at least add a PR so it is harder to drop?

-- 
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

Re: Problems with zpool upgrade embedded_data, and rebooting

2014-08-08 Thread John-Mark Gurney

Daniel Peyrolon wrote this message on Sat, Aug 09, 2014 at 00:41 +0200:
 Hello everyone,
 
 I just would like to gratuitously rant about something that happened on my
 machine.
 
 Basically, I upgraded my zpool to use embedded_data, since it would be more
 efficient, and rebooted. (I installed the system with zfs using bsdinstall).
 It turned out that gptzfsboot wasn't able to load that filesystem, so I
 tried to get it working from a live system that I have on a USB drive.
 It didn't work on that particular live system, but, fortunately, someone
 could do me a favor and download the latest snapshot, and burn it to my USB
 drive.
 
 From there, it was a matter of importing zroot, mounting it at /mnt, and
 taking a look at the code of bsdinstall, trying to find the actual command
 to update the bootloader.
 I could manage to find it, and hopefully, everything worked again. Thanks
 to those who helped me :)
 
 What would be the better way to avoid this happening in the future?

Didn't you get the following warning:
# zpool upgrade -a
This system is currently running ZFS pool version 28.

Successfully upgraded 'tank'

If you boot from pool 'tank', don't forget to update boot code.
Assuming you use GPT partitioning and da0 is your boot disk
the following command will do it:

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

Or something similar?

If you didn't follow the warnings, how else can we help you?

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: m4 still broken on gcc platforms

2014-08-07 Thread John Hay

On Thu, Jul 31, 2014 at 08:15:32AM +, Bjoern A. Zeeb wrote:
 Hi,
 
 I am still seeing this with arm/power/sparc/mips.  Can somene please fix it?

Did this get fixed because I still see it on -current while trying to
build armeb for the AVILA and CAMBRIA boards.

Regards

John
-- 
John Hay -- j...@meraka.csir.co.za / j...@meraka.org.za

 
 
 
 === usr.bin/m4/tests (all)
 cc1: warnings being treated as errors
 /scratch/tmp/bz/head.svn/usr.bin/m4/misc.c: In function 'm4errx':
 /scratch/tmp/bz/head.svn/usr.bin/m4/misc.c:268: warning: declaration of 
 'eval' shadows a global declaration
 /scratch/tmp/bz/head.svn/usr.bin/m4/extern.h:40: warning: shadowed 
 declaration is here
 --- misc.o ---
 *** [misc.o] Error code 1
 
 bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin/m4
 cc1: warnings being treated as errors
 /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_remove':
 /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:123: warning: cast discards 
 qualifiers from pointer target type
 /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_find':
 /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:144: warning: cast discards 
 qualifiers from pointer target type
 /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_next':
 /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:183: warning: cast discards 
 qualifiers from pointer target type
 --- ohash.o ---
 *** [ohash.o] Error code 1
 
 bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin/m4
 --- all_subdir_m4 ---
 *** [all_subdir_m4] Error code 1
 
 bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin
 === usr.bin/mail (all)
 
 
 ? 
 Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983
 

___
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: m4 still broken on gcc platforms

2014-08-07 Thread John Hay

On Thu, Aug 07, 2014 at 10:23:46AM +0200, Baptiste Daroussin wrote:
 On Thu, Aug 07, 2014 at 10:15:51AM +0200, John Hay wrote:
  On Thu, Jul 31, 2014 at 08:15:32AM +, Bjoern A. Zeeb wrote:
   Hi,
   
   I am still seeing this with arm/power/sparc/mips.  Can somene please fix 
   it?
  
  Did this get fixed because I still see it on -current while trying to
  build armeb for the AVILA and CAMBRIA boards.
  
 It has ben fixed last week

It is still broken for me. Maybe it is my environment. The last time I have
updated my source tree was about 2 weeks ago and with that I could build
working AVILA and CAMBRIA boards. I have updated now so that I could get
the interrupt fixes that Ian committed a few hours ago. My tree is at
svn 269656.

The machine I am building on is running 10-stable from around 30 March,
if that makes a difference.

Regards

John
-- 
John Hay -- j...@meraka.csir.co.za / j...@meraka.org.za
___
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: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]

2014-08-05 Thread John Baldwin


On Aug 5, 2014, at 7:29 AM, David Wolfskill da...@catwhisker.org wrote:

 On Mon, Aug 04, 2014 at 12:47:59PM -0700, David Wolfskill wrote:
 ...
 I was unable to get a crash dump, and I only recorded the offsets in the
 backtrace (no arguments; sorry -- I was expecting the build machine to
 allow me to investigate on a machine with a serial console):
 
 ...
 SMP: AP CPU #1 Launched!
 panic: aatpic_assign_cpu: bad cookie
 cpuid=0
 atpic_assign_cpu(...) at atpic_assign_cpu+0x1a/frame 0xc2820d0c
 intr_shuffle_irqs(...) at intr_shuffle_irqs+0x97/frame 0xc2820d30
 mi_startup(...) at mi_startup+0xe7/frame 0xc2820d58
 begin(...) at begin+0x2c
 db 
 
 So... what can I do to help figure out what went wrong?  As noted, I
 have no serial console on the laptop, and while I have captured crash
 dumps in the past, I'm guessing that at the point the above happens, the
 machine has yet to obtain a clue about where it might put a dump if one
 were created.
 
 (No problems with stable/9 (@r269499) or stable/10 (@r269498) on the
 same hardware.)
 
 
 By booting from the previously-built kernel:
 
 FreeBSD 11.0-CURRENT #1327  r269469M/269469:1100028: Sun Aug  3 06:16:24 PDT 
 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386
 
 I was able to update sources to r269580  rebuild (successfully -- both
 userland  kernel); the resulting kernel, however, exhibited the same
 symptoms -- panic: aatpic_assign_cpu: bad cookie, with a similar (if
 not identical -- I couldn't refer to the previous one while I was
 observing the current panic) backtrace.
 
 I'm willing to try hacking at code (if necessary) to figure out what's
 wrong  fix it; I'll need some guidance, though.
 
 Given that my build machine did not exhibit the symptoms, and given the
 references to atpic, it may be relevant to point out that the machine
 where I see the panic is a Dell Precision M4400 laptop.

My guess is that the recent Xen changes tickled something.  However, can you 
capture a verbose dmesg from your working kernel?

-- 
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

Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]

2014-08-05 Thread John Baldwin


On Aug 5, 2014, at 2:29 PM, Michael Butler i...@protected-networks.net wrote:

 On 08/05/14 16:56, Michael Butler wrote:
 On 08/05/14 16:02, John Baldwin wrote:
 
 My guess is that the recent Xen changes tickled something.
 
 I can confirm this on a kernel which is otherwise up to date ..
 
 FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD
 11.0-CURRENT #2 r269608M: Tue Aug  5 16:48:12 EDT 2014
 
 I backed out all of SVN r269507 through r269515.
 
 Now working ..
 
 [ .. snip .. ]
 
 Now to see if it's related to the other machine's disk woes (it's a
 single-core device),
 
 And it fixes the inability to probe disks on my single-core machine :-)

It looks like the MADT code to probe the I/O APICs isn't working so it's trying 
to fall back to using the ATPIC while using SMP (which doesn't work).  I know 
it's a pain on a laptop, but if it is at all possible to capture either a 
verbose or non-verbose dmesg that would really help narrow it down.

Also, if anyone can try reverting just the MADT-related changes in the recent 
Xen changes to see if you can narrow down which exact one triggers the panic 
that would be really helpful.

-- 
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

Re: domain_add(xxx) after domainfinalize...

2014-08-02 Thread John-Mark Gurney

Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 15:20 +0200:
 Well, I did not look at network stack for long time, so the following
 things could be obsolete now, but at least:
 
 (1) There is some room left in mbuf header on its allocation, so protocols
 (link) headers can be added in the front of data without need of
 reallocation or data copying. The size of the room is evaluated from all
 domains at boot time.
 
 (2) All network address masks are shared among domains and protocols in
 mask radix tree. The tree is created with particular key size, which is
 again evaluated from all domains as maximal size of all known addresses.
 
 So, if new domain added after these evaluations does not break both them
 and some other things, there is no problem. Otherwise, some warnings are
 always nice if things go bad.

But would anyone who sees these issues know that this is the problem?
And what would they do, report the problem?  We'd say, yeh, we know,
but do you hit this every day?  Nope, ok, we won't fix it...

 Maybe some function which examine new domain and say there is no risk to
 add it would be nice.

I agree...  These things should have been done in the first place, but
clearly this warning wasn't enough to cause anyone to fix it.. :)

 On Sat, Aug 2, 2014 at 12:21 AM, John-Mark Gurney j...@funkthat.com wrote:
 
  Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 00:05 +0200:
   Just what I've got in January 2011:
  
  http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034037.html
 
  Sadly, after three (or six+) years, it is clear that these bugs will
  not be fixed, and this warning message is not useful, since no one has
  stepped up to fix them..
 
  btw, you might want to create a bug w/ the information you tracked down
  to hopefully help the person that decides to finally fix them, though
  I doubt they will ever be fixed as people apparently don't see bad
  behavior...
 
  Unless someone fixes the bugs in the next few days, I will commit the
  following patch:
  Index: uipc_domain.c
  ===
  --- uipc_domain.c   (revision 266964)
  +++ uipc_domain.c   (working copy)
  @@ -227,15 +227,10 @@
  printf(WARNING: attempt to domain_add(%s) before 
  domaininit()\n, dp-dom_name);
   #endif
  -#ifdef notyet
  -   KASSERT(domain_init_status  2,
  -   (attempt to domain_add(%s) after domainfinalize(),
  -   dp-dom_name));
  -#else
  -   if (domain_init_status = 2)
  -   printf(WARNING: attempt to domain_add(%s) after 
  -   domainfinalize()\n, dp-dom_name);
  -#endif
  +   /*
  +* XXX - there are bugs WRT to adding domain after domain_finalize
  is
  +* called
  +*/
  mtx_unlock(dom_mtx);
   }
 
 
   On Fri, Aug 1, 2014 at 9:34 PM, John-Mark Gurney j...@funkthat.com
  wrote:
  
So, I have a laptop that devd loads the bluetooth module every time..
   
This means I get the following error on every boot:
WARNING: attempt to domain_add(bluetooth) after domainfinalize()
WARNING: attempt to domain_add(netgraph) after domainfinalize()
   
Is there any real benefit to this warning?  I just looked at the code,
and the domain gets added despite the warning...
   
Also, it looks like the pervious warning, we should just make that an
if/panic since it's clearly a programming bug, or kill the ifndef
INVARIANTS...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: domain_add(xxx) after domainfinalize...

2014-08-02 Thread John-Mark Gurney

Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 21:27 +0200:
 On Sat, Aug 2, 2014 at 8:32 PM, John-Mark Gurney j...@funkthat.com wrote:
 
  Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 15:20 +0200:
   Well, I did not look at network stack for long time, so the following
   things could be obsolete now, but at least:
  
   (1) There is some room left in mbuf header on its allocation, so
  protocols
   (link) headers can be added in the front of data without need of
   reallocation or data copying. The size of the room is evaluated from all
   domains at boot time.
  
   (2) All network address masks are shared among domains and protocols in
   mask radix tree. The tree is created with particular key size, which is
   again evaluated from all domains as maximal size of all known addresses.
  
   So, if new domain added after these evaluations does not break both them
   and some other things, there is no problem. Otherwise, some warnings are
   always nice if things go bad.
 
  But would anyone who sees these issues know that this is the problem?
  And what would they do, report the problem?  We'd say, yeh, we know,
  but do you hit this every day?  Nope, ok, we won't fix it...
 
   Maybe some function which examine new domain and say there is no risk to
   add it would be nice.
 
  I agree...  These things should have been done in the first place, but
  clearly this warning wasn't enough to cause anyone to fix it.. :)
 
 You are right, but the warning is remainder that there is something
 unresolved. Remove the warning and forget, imho, it's not well.

Sorry, nine years[1] of the warning existing yet no fix clearly
demonstrates that it's already been forgoten, otherwise it would have
been fixed by now..

Also, a bug report or XXX comment is enough IMO, and will probably
receive the same amount of attention over the next nine years...

[1] https://svnweb.freebsd.org/changeset/base/138239

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: Future of pf / firewall in FreeBSD ? - does it have one ?

Cy Schubert wrote this message on Wed, Jul 23, 2014 at 09:18 -0700:
 In message CAJ-Vmo=_vLkMZn02EPUmpvqugcT8ga1_Kqs=XU49SGUNGEO0Pw@mail.gmail.c
 om
 , Adrian Chadd writes:
  On 18 July 2014 07:34, krad kra...@gmail.com wrote:
   that is true and I have not problem using man pages, however thats not the
   way most of the world work and search engines arent exactly new either. We
   should be trying to engage more people not less, and part of that is
   reaching out.
  
  Then do the port and maintain it.
  
  The problem isn't the desire to keep things up to date, it's a lack of
  people who want that _and_ are willing/able to do it _and_ are funded
  somehow.
 
 Funding is the issue. Sure, some of us maintain software because a personal 
 need however without funding one has to fit maintaining software into 
 whatever time is left. For those of us who do this without funding you 
 manage to squeeze in an hour here or there.

Then write a proposal and submit it to the Foundation..  If you don't
ask for funding, it rarely shows up...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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

domain_add(xxx) after domainfinalize...

So, I have a laptop that devd loads the bluetooth module every time..

This means I get the following error on every boot:
WARNING: attempt to domain_add(bluetooth) after domainfinalize()
WARNING: attempt to domain_add(netgraph) after domainfinalize()

Is there any real benefit to this warning?  I just looked at the code,
and the domain gets added despite the warning...

Also, it looks like the pervious warning, we should just make that an
if/panic since it's clearly a programming bug, or kill the ifndef
INVARIANTS...

Index: uipc_domain.c
===
--- uipc_domain.c   (revision 266964)
+++ uipc_domain.c   (working copy)
@@ -227,15 +227,6 @@
printf(WARNING: attempt to domain_add(%s) before 
domaininit()\n, dp-dom_name);
 #endif
-#ifdef notyet
-   KASSERT(domain_init_status  2,
-   (attempt to domain_add(%s) after domainfinalize(),
-   dp-dom_name));
-#else
-   if (domain_init_status = 2)
-   printf(WARNING: attempt to domain_add(%s) after 
-   domainfinalize()\n, dp-dom_name);
-#endif
mtx_unlock(dom_mtx);
 }
 

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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

comments on vt as console...

So, I decided to play around w/ vt after the recent UTF-8 discussion,
and noticed some issues w/ it...

First, if you load the gallant font, things don't look very good...  This
is probably because of the fact that I'm using the vga driver:
VT: running with driver vga.

and the default resolution is 640x480... The gallant font is probably
much higher res, and when I load it, the text screen size drops to
53x21, and the text is all chopped off.  This is probably due to bad
calculation on scaling...

Second, once one vty has the gallant font loaded, if you switch vty's,
it can occure that the new vty does not display ANY text..  The display
is mostly blank...

Third, w/ the other font loaded, the border doesn't always properly
get cleared...

Fourth, when switching screens, there is a brief flash of vertical
stripes before the new screen comes on...  Can we do something to make
sure that this transition is clean?  Either a completely blank screen,
or ideally, no blank screen, but the new text appearing?

$ sysctl kern.vt
kern.vt.enable_altgr: 1
kern.vt.debug: 0
kern.vt.deadtimer: 15
kern.vt.suspendswitch: 1
$ uname -a
FreeBSD pciehp 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r267710M: Thu Jul 31 
21:39:53 ICT 2014 
jmg@pciehp:/usr/home/jmg/freebsd.pciehp/sys/amd64/compile/GENERIC  amd64

Let me know if you need any more info.

Thanks.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: domain_add(xxx) after domainfinalize...

Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 00:05 +0200:
 Just what I've got in January 2011:
 http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034037.html

Sadly, after three (or six+) years, it is clear that these bugs will
not be fixed, and this warning message is not useful, since no one has
stepped up to fix them..

btw, you might want to create a bug w/ the information you tracked down
to hopefully help the person that decides to finally fix them, though
I doubt they will ever be fixed as people apparently don't see bad
behavior...

Unless someone fixes the bugs in the next few days, I will commit the
following patch:
Index: uipc_domain.c
===
--- uipc_domain.c   (revision 266964)
+++ uipc_domain.c   (working copy)
@@ -227,15 +227,10 @@
printf(WARNING: attempt to domain_add(%s) before 
domaininit()\n, dp-dom_name);
 #endif
-#ifdef notyet
-   KASSERT(domain_init_status  2,
-   (attempt to domain_add(%s) after domainfinalize(),
-   dp-dom_name));
-#else
-   if (domain_init_status = 2)
-   printf(WARNING: attempt to domain_add(%s) after 
-   domainfinalize()\n, dp-dom_name);
-#endif
+   /*
+* XXX - there are bugs WRT to adding domain after domain_finalize is
+* called
+*/
mtx_unlock(dom_mtx);
 }
 

 On Fri, Aug 1, 2014 at 9:34 PM, John-Mark Gurney j...@funkthat.com wrote:
 
  So, I have a laptop that devd loads the bluetooth module every time..
 
  This means I get the following error on every boot:
  WARNING: attempt to domain_add(bluetooth) after domainfinalize()
  WARNING: attempt to domain_add(netgraph) after domainfinalize()
 
  Is there any real benefit to this warning?  I just looked at the code,
  and the domain gets added despite the warning...
 
  Also, it looks like the pervious warning, we should just make that an
  if/panic since it's clearly a programming bug, or kill the ifndef
  INVARIANTS...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: domain_add(xxx) after domainfinalize...

Adrian Chadd wrote this message on Fri, Aug 01, 2014 at 16:25 -0700:
 On 1 August 2014 15:55, Marko Zec z...@fer.hr wrote:
  On Fri, 1 Aug 2014 15:42:30 -0700
  Adrian Chadd adr...@freebsd.org wrote:
 
  I'd just make it a panic.  :)
 
  Are you prepared to say goodbye to kldloading netgraph at runtime?
 
 Well, why is it saying that? is there actually a problem?

Please read the thread.  Thanks.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: [ANNOUNCEMENT] pkg 1.3.0 out!

2014-07-26 Thread John Hay

On Sat, Jul 26, 2014 at 11:39:46AM -0700, Nathan Whitehorn wrote:
 On 07/24/14 23:56, John Hay wrote:
  On Wed, Jul 23, 2014 at 04:42:51PM +0200, Baptiste Daroussin wrote:
  Hi all,
 
  I'm very please to announce the release of pkg 1.3.0
  This version is the result of almost 9 month of hard work
 
  ...
  Thank you to all contributors:
  Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis,
  Bryan Drewery, Dag-Erling Sm?rgrav, Dmitry Marakasov, Elvira Khabirova, 
  Jamie
  Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold,
  Matthew Seaman, Maximilian Ga?, Michael Gehring, Michael Gmelin, Nicolas 
  Szalay,
  Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. 
  Putrya,
  Vsevolod Stakhov, Xin Li, coctic
 
  Regards,
  Bapt on behalf of the pkg@
  Version 1.3 does better on armeb. It does not crash while installing
  itself, but still complains and get the architecture wrong:
 
 
 [snip]
 
 Would it make sense to get the architecture from the kernel, with a 
 manual override for cross-installs? It seems like that would prevent 
 cases like this permanently.

If a file has to be checked, what about the same mechanism that file
(libmagic) use? It seems to get it right:

root@cambria-build # file /bin/sh
/bin/sh: ELF 32-bit MSB executable, ARM, EABI4 version 1 (SYSV), dynamically 
linked (uses shared libs), FreeBSD-style, for FreeBSD 11.0 (1100028), stripped

John
-- 
John Hay -- j...@meraka.csir.co.za / j...@meraka.org.za
___
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: [ANNOUNCEMENT] pkg 1.3.0 out!

2014-07-25 Thread John Hay

On Wed, Jul 23, 2014 at 04:42:51PM +0200, Baptiste Daroussin wrote:
 Hi all,
 
 I'm very please to announce the release of pkg 1.3.0
 This version is the result of almost 9 month of hard work
 
...
 Thank you to all contributors:
 Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis,
 Bryan Drewery, Dag-Erling Sm?rgrav, Dmitry Marakasov, Elvira Khabirova, Jamie
 Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold,
 Matthew Seaman, Maximilian Ga?, Michael Gehring, Michael Gmelin, Nicolas 
 Szalay,
 Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya,
 Vsevolod Stakhov, Xin Li, coctic
 
 Regards,
 Bapt on behalf of the pkg@

Version 1.3 does better on armeb. It does not crash while installing
itself, but still complains and get the architecture wrong:


root@cambria-build:/usr/ports/ports-mgmt/pkg # make install
===  Installing for pkg-1.3.0
===  Checking if ports-mgmt/pkg already installed
pkg-static: failed to find the version elf note
===   Registering installation for pkg-1.3.0
pkg-static: failed to find the version elf note
pkg-static: failed to find the version elf note
If you are upgrading from the old package format, first run:

  # pkg2ng

root@cambria-build:/usr/ports/ports-mgmt/pkg # pkg info pkg
pkg: failed to find the version elf note
pkg-1.3.0
Name   : pkg
Version: 1.3.0
Installed on   : Fri Jul 25 06:36:42 UTC 2014
Origin : ports-mgmt/pkg
Architecture   :  ??
Prefix : /usr/local
Categories : ports-mgmt
Licenses   : BSD2CLAUSE
Maintainer : port...@freebsd.org
WWW: http://wiki.freebsd.org/pkgng
Comment: Package manager
Flat size  : 7.14MiB
Description:
Package management tool

WWW: http://wiki.freebsd.org/pkgng

root@cambria-build:/usr/ports/ports-mgmt/pkg # uname -a
FreeBSD cambria-build 11.0-CURRENT FreeBSD 11.0-CURRENT #13 r269057M: Thu Jul 
24 15:54:38 SAST 2014 
j...@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/CAMBRIA
  arm
root@cambria-build:/usr/ports/ports-mgmt/pkg # uname -p
armeb
root@cambria-build:/usr/ports/ports-mgmt/pkg # uname -m
arm
root@cambria-build:/usr/ports/ports-mgmt/pkg
###

On the previous pkg, I used a small crow-bar patch (attached) then it did
install properly and its architecture looked like this:

###
 % pkg info pkg
pkg-1.2.7_3
Name   : pkg
Version: 1.2.7_3
Installed on   : Thu Jul 17 15:15:05 SAST 2014
Origin : ports-mgmt/pkg
Architecture   : freebsd:11:arm:32:eb:eabi:softfp
Prefix : /usr/local
Categories : ports-mgmt
Licenses   : BSD2CLAUSE
Maintainer : port...@freebsd.org
WWW: http://wiki.freebsd.org/pkgng
Comment: Package manager
Shared Libs required:
libpkg.so.1
Flat size  : 6.48MiB
Description:
Package management tool

WWW: http://wiki.freebsd.org/pkgng
###

Regards

John
-- 
John Hay -- j...@meraka.csir.co.za / j...@meraka.org.za


--- libpkg/pkg_elf.c.orig   2014-03-15 13:15:46.0 +
+++ libpkg/pkg_elf.c2014-06-23 17:41:35.0 +
@@ -636,6 +636,12 @@
int ret = EPKG_OK;
int i;
const char *arch, *abi, *endian_corres_str, *wordsize_corres_str, *fpu;
+   const char *path;
+   char localname[] = freebsd;
+
+   path = getenv(ABI_FILE);
+   if (path == NULL)
+   path = _PATH_BSHELL;
 
if (elf_version(EV_CURRENT) == EV_NONE) {
pkg_emit_error(ELF library initialization failed: %s,
@@ -643,7 +649,7 @@
return (EPKG_FATAL);
}
 
-   if ((fd = open(_PATH_BSHELL, O_RDONLY))  0) {
+   if ((fd = open(path, O_RDONLY))  0) {
pkg_emit_errno(open, _PATH_BSHELL);
snprintf(dest, sz, %s, unknown);
return (EPKG_FATAL);
@@ -687,6 +693,7 @@
break;
src += note.n_namesz + note.n_descsz;
}
+#if 0
if ((uintptr_t)src = ((uintptr_t)data-d_buf + data-d_size)) {
ret = EPKG_FATAL;
pkg_emit_error(failed to find the version elf note);
@@ -698,7 +705,10 @@
version = be32dec(src);
else
version = le32dec(src);
-
+#else
+   osname = localname;
+   version = 11 * 10;
+#endif
for (i = 0; osname[i] != '\0'; i++)
osname[i] = (char)tolower(osname[i]);
 
___
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] Allow m_dup() to use JUMBO clusters

2014-07-23 Thread John-Mark Gurney

Rick Macklem wrote this message on Tue, Jul 08, 2014 at 16:10 -0400:
 I tried:
   m = m_getjcl(M_NOWAIT..M_JUMPAGESIZE);
   if (m == NULL)
m = getjcl(M_WAITOK..MCLBYTES);
 when I was experimenting with MJUMPAGESIZE clusters for NFS and what happened
 was the thread looped in the first m_getjcl() instead of returning NULL.
 It is about 12 layers of function calls deep and most fail/return NULL, but
 somewhere one of them decides to try again. I didn't locate the location
 of that and don't know if it would be safe to change it so that m_getjcl()
 returns NULL for this case.

So, I took a quick look at this, and I see a weird issue...

In mb_ctor_mbuf in kern_mbuf.c, the how argument is passed to m_init
instead of flags...  how and flags SHOULD be the same, but it could be
that uma could change how to something else and we are loosing _NOWAIT..

Also, m_getjcl is calling two different uma_zalloc_arg's, know which
one would be useful...

You should be able to verify this w/ dtrace pretty easily in your case..

Brief call path:
m_getjcl - uma_zalloc_arg - mb_ctor_mbuf - m_init - m_pkthdr_init -
mac_mbuf_init - m_tag_get or mac_mbuf_tag_init...

I didn't trace it down beyond mac_mbuf_init..  Verifying that
mac_mbuf_init still has M_NOWAIT would be good...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: Boot loader too large

2014-07-15 Thread John Baldwin

On Friday, July 11, 2014 6:50:43 pm Matthew D. Fuller wrote:
 On Fri, Jul 11, 2014 at 03:38:56PM -0700 I heard the voice of
 Nathan Whitehorn, and lo! it spake thus:
 
  I don't honestly remember where that number came from. It's at line
  72 of usr.sbin/bsdinstall/partedit/partedit_x86.c. If 128 works
  better, I'm happy to change it, but it would be nice to know what
  the actual bounds here are before putting in a new arbitrary number.
 
 src/sys/boot/i386/pmbr/pmbr.s says
 
 -
 next_boot:. incl (%si). .   .   # Next LBA
 .   .   adcl $0,4(%si)
 .   .   mov %es,%ax..   .   # Adjust segment for next
 .   .   addw $SECSIZE/16,%ax.   .   #  sector
 .   .   cmp $0x9000,%ax..   .   # Don't load past 0x9,
 .   .   jae err_big..   .   #  545k should be enough for
 .   .   mov %ax,%es..   .   #  any boot code. :)
 -
 
 (err_big being printing the Boot loader too large message).  Though
 0x9 is actually 576k, not 545, but presumably there's some other
 adjustment lopping off bits somewhere; that's 62 sectors diff.

The boot code is not loaded at offset 0, it is loaded at offset 0x7c00 (the
same address the BIOS loads boot loaders):

.set LOAD,0x7c00# Load address
...
#
# We found a boot partition.  Load it into RAM starting at 0x7c00.
#
movw %bx,%di# Save partition pointer in %di
leaw PART_START_LBA(%di),%si
movw $LOAD/16,%bx

 Regardless, I settled on 512k for my boot partitions (after finding
 the above error when I previously decided it's a few dozen k, I'll
 just set aside a meg to be safe and then discovered the whole
 not-booting thing that caused.

512k should be fine even if it is a bit excessive.  Also, larger partitions
might actually increase boot time, but perhaps not noticably.

-- 
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

Re: Boot loader too large

2014-07-11 Thread John Baldwin

On Friday, July 04, 2014 7:07:20 am Alie Tan wrote:
 On Fri, Jul 4, 2014 at 5:57 PM, Alie Tan a...@afflemedialab.com wrote:
 
  Hi,
 
  I am getting Boot loader too large message while using
  FreeBSD-11.0-CURRENT-i386-20140701-r268111-disc1.iso
 
  Is there any way to solve this issue?
 
 Strange, resizing the freebsd-boot to 128k solved my issue. why default
 slice size making such issue?

Good question.  Perhaps Nathan (cc'd) knows?

-- 
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

Re: 10.0-RELEASE BTX halted on DELL R900

2014-07-11 Thread John Baldwin

On Saturday, July 05, 2014 8:57:45 am Dimitry Andric wrote:
  Just in case, you could try the patch attached to this bug:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176748
  
  The patch was compiled for 9-STABLE; if it does not apply to the 10.0
  sources, then drop me a line so I can adapt it.
 
 I tried this patch on a few FreeBSD VMs, and each of them stopped being
 able to mount the root filesystem because of it.  I don't really know
 what the explanation is...

That patch is just wrong.  I've updated the PR with something that is probably
similar to your patch (explicitly ignore a size of zero back from EDD).

-- 
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

Re: [RFC] Allow m_dup() to use JUMBO clusters

2014-07-07 Thread John-Mark Gurney

Hans Petter Selasky wrote this message on Mon, Jul 07, 2014 at 10:12 +0200:
 I'm asking for some input on the attached m_dup() patch, so that 
 existing functionality or dependencies are not broken. The background 
 for the change is to allow m_dup() to defrag long mbuf chains that 
 doesn't fit into a specific hardware's scatter gather entries, typically 
 when doing TSO.
 
 In my case the HW limit is 16 entries of length 4K for doing a 64KByte 
 TSO packet. Currently m_dup() is at best producing 32 entries of each 2K 
 for a 64Kbytes TSO packet.
 
 By allowing m_dup() to get JUMBO clusters when allocating mbufs, we 
 avoid creating a new function, specific to the hardware, to defrag some 
 rare-occurring very long mbuf chains into a mbuf chain below 16 entries.

Please no... Until we get a better allocator, we should not use jumbo
(page sized) mbufs otherwise we will quickly fail to allocate mbufs
after a machine has been up for a long while causing other failures...

Unless of course if the code fails to allocate the largest cluster it
falls through to trying to allocate the next smaller size, that might
be better...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: keyboard break to debugger broken?

2014-07-05 Thread John-Mark Gurney

Peter Jeremy wrote this message on Fri, Jul 04, 2014 at 21:27 +1000:
 On 2014-Jul-04 02:28:48 -0700, John-Mark Gurney j...@funkthat.com wrote:
 So, I recently tried to break into the debugger w/ the various key
 sequences that I know about, and none of them worked... I've tried
 CTRL-ESC, ALT-ESC, CTRL-ALT-ESC, CTRL-PRTSCR, ALT-PRTSCR and
 CTRL-ALT-PRTSCR, and many other different ones...   I've verified that
 I can sysctl debug.kdb.enter=1 to enter the debugger, and the
 CTRL-ALT-PAUSE works to suspend the machine, and CTRL-ALT-DEL works
 to reboot...
 
 Does anyone know if this works?
 
 It works for me on 10.0.  Do you have debug.kdb.break_to_debugger=1
 and hw.syscons.kbd_debug=1 (if you're using syscons)?

Turns out I didn't... and you didn't need to...  emaste helped me
the other night discover this..  Apparently rwatson changed this and
the docs never got updated...  I saw BREAK_TO_DEBUGGER, bug it was
documented as being *serial* only, not syscons...

I've updated NOTES and added an entry for defaults/loader.conf, but
more docs need to be updated that BREAK_TO_DEBUGGER or the tunable
or sysctl needs to be set before if works..

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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

keyboard break to debugger broken?

2014-07-04 Thread John-Mark Gurney

So, I recently tried to break into the debugger w/ the various key
sequences that I know about, and none of them worked... I've tried
CTRL-ESC, ALT-ESC, CTRL-ALT-ESC, CTRL-PRTSCR, ALT-PRTSCR and
CTRL-ALT-PRTSCR, and many other different ones...   I've verified that
I can sysctl debug.kdb.enter=1 to enter the debugger, and the
CTRL-ALT-PAUSE works to suspend the machine, and CTRL-ALT-DEL works
to reboot...

Does anyone know if this works?

Thanks for the pointers...

btw, I'm having trouble on 9stable too.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: Fix Emulex oce driver in CURRENT

2014-06-30 Thread John Baldwin

On Monday, June 30, 2014 12:36:22 pm Stefano Garzarella wrote:
 Hello,
 I had problems during some experiments with Emulex and oce driver in
 CURRENT.
 I found several bugs in the oce driver and this patch fixes them.
 
 - oce_multiq_start(): if the link is down returns ENXIO without consuming
 the mbuf.
   A trivial fix is to remove the initial error check, since
 oce_multiq_transmit() which is
   called next handles the link down situation correctly.
 - oce_multiq_transmit(): there is an extra call to drbr_enqueue() causing
 the
   mbuf to be enqueued twice when the NIC's queue is full.
 - oce_multiq_transmit(): same problem fixed recently in ixgbe (r267187) and
 other drivers:
   if the mbuf is enqueued, the proper return value is 0
 
 This patch has been reviewed by luigi (in cc).
 
 If someone could have a look on this and give me some feedback it would be
 great.

I think these sound fine, but I've cc'd Xin Li (delphij@) who has worked with
folks at Emulex to maintain this driver.  He is probably the best person to
review this.

 Regards,
 Stefano Garzarella
 
 
 
  diff --git a/sys/dev/oce/oce_if.c b/sys/dev/oce/oce_if.c
  index 70d6393..af57491 100644
  --- a/sys/dev/oce/oce_if.c
  +++ b/sys/dev/oce/oce_if.c
  @@ -563,9 +563,6 @@ oce_multiq_start(struct ifnet *ifp, struct mbuf *m)
  int queue_index = 0;
  int status = 0;
 
  -   if (!sc-link_status)
  -   return ENXIO;
  -
  if ((m-m_flags  M_FLOWID) != 0)
  queue_index = m-m_pkthdr.flowid % sc-nwqs;
 
  @@ -1274,7 +1271,6 @@ oce_multiq_transmit(struct ifnet *ifp, struct mbuf
 *m, struct oce_wq *wq)
  drbr_putback(ifp, br, next);
  wq-tx_stats.tx_stops ++;
  ifp-if_drv_flags |= IFF_DRV_OACTIVE;
  -   status = drbr_enqueue(ifp, br, next);
  }
  break;
  }
  @@ -1285,7 +1281,7 @@ oce_multiq_transmit(struct ifnet *ifp, struct mbuf
 *m, struct oce_wq *wq)
  ETHER_BPF_MTAP(ifp, next);
  }
 
  -   return status;
  +   return 0;
   }
 ___
 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
 

-- 
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

Re: vmmapi.h

2014-06-30 Thread John Baldwin

On Monday, June 30, 2014 2:03:35 pm Bruno Lauzé wrote:
 
 building from trunk:
 usr.sbin/bhyve/pci_emul.c is picking up old vmmapi.h from 
/usr/include/vmmapi.h instead source one:
 for me it results vm_get_lowmem_size and vm_get_highmem_size missing... 
 any ideas? I think we need to include lib/libvmmapi folder so includes are 
kept from /usr/include ones.

Are you using 'make buildworld'?  'make buildworld' will not use /usr/include 
(it builds a new one).  If you have updated your source tree and are just 
trying to do 'make' in usr.sbin/bhyve that is indeed not going to work.  Use 
buildworld instead.

-- 
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

Re: PostgreSQL performance on FreeBSD

2014-06-27 Thread John Baldwin

On Friday, June 27, 2014 8:56:13 am Konstantin Belousov wrote:
 Hi,
 I did some measurements and hacks to see about the performance and
 scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD
 Foundation.
 
 The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf.
 The uncommitted patches, referenced in the article, are available as
 https://kib.kiev.ua/kib/pig1.patch.txt
 https://kib.kiev.ua/kib/patch-2

Did you run the same benchmark on the same hardware with any other OS's to 
compare results?

-- 
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

Re: do we have a generic string-number sysctl mapping library ?

2014-06-27 Thread John Baldwin

On Friday, June 27, 2014 5:14:59 am Luigi Rizzo wrote:
 Hi,
 I have frequently found myself using sysctls to control some kernel
 feature where a string would be a better (and sometimes the only)
 option than using a numeric value, yet the internal representation
 should be numeric for speed and robustness.
 Examples are the kern.timecounter, the default scheduler in dummynet,
 and now in netmap the selection between native and emulated mode.
 I am sure many of you can come up with other cases.
 
 I wonder if we have some support for that already in the sysctl code,
 or i should build a generic one next time i need to do that.
 
 Feel free to criticise the approach and suggest better ones.
 Right now i am using sysctls because i have a set of macros
 and wrapper functions that let me convert them to sysfs
 entries when building kernel code on linux, so I have a
 portable solutions.
 
 For the details, I'd like to have a mechanism that requires the
 kernel programmer supply a (possibly extensible) table of
 supported values, and matching constants to be used within
 the kernel. A single declaration should generate entries
 to get/set the current value as well as list options.
 We can discuss frills (such as wildcards, multiple values,etc).

I am not aware of such a beast.  Even just supporting a simple table to map 
labels to indices would be nice and would handle many cases.  I.e. if you
had something like:

struct sysctl_table vals[] = {
   foo,  (void *)1,
   bar,  (void *)2,
   NULL, NULL
};

static int myval;

static int
my_sysctl(SYSCTL_HANDLER_ARGS)
{
void *val;
int error;

val = (void *)myval;
error = sysctl_handle_table(oidp, vals, val, req);
if (error || req-newptr == NULL)
   return (error);
myval = (intptr_t)val;
return (0);
}

sysctl_handle_table() would use the initial value to find a suitable string 
from the table for the old string, etc.  Using void * for the value would 
let you store arbitrary data, etc.

-- 
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

Re: Solved: Re: Problem with tagged vlan after upgrading

2014-06-25 Thread John Baldwin

On Wednesday, June 25, 2014 9:45:55 am Ricardo Campos Passanezi wrote:
 On Wed, Jun 25, 2014 at 10:32:45AM -0300, Ricardo Campos Passanezi wrote:
  
  Some more info I've forgotten to add:
  
  - If I listen the vlan interfaces (tcpdump -i vlanX), the traffic is
there.
  
  - I've tested the scenario:
  
- delete the inet from em0;
- create a vlan2 with th IP used by em0
- enable the vlan tag in the switch
- now, I can use the vlan1 (10.0.0.0/8)o
 
 
 
 
 
 The problem has been solved by issuing a ifconfig em0 -vlanhwtag.
 
 After that eveything is working.

Please submit a bug report for this and cc it to j...@freebsd.org.  The 
vlanhwtag stuff should work properly.

-- 
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

Re: ahci panics when detaching...

2014-06-24 Thread John Baldwin

On Monday, June 23, 2014 9:06:26 pm John-Mark Gurney wrote:
 John Baldwin wrote this message on Mon, Jun 23, 2014 at 10:49 -0400:
  On Monday, June 23, 2014 9:44:08 am John-Mark Gurney wrote:
   So, when I try to eject a ESATA card, the machine panics...  I am able
   to successfully eject other cards, an ethernet (re) and a serial card
   (uart), and both handle the removal of their device w/o issue and with
   out crashes...
   
   When I try w/ ahci, I get a panic...  The panic backtrace is:
   #8  0x80ced4e2 in calltrap () at 
  ../../../amd64/amd64/exception.S:231
   #9  0x8093d037 in rman_get_rid (r=0xf800064c9380)
   at ../../../kern/subr_rman.c:979
   #10 0x8092b888 in resource_list_release_active 
  (rl=0xf80006d39c08,
   bus=0xf80002cd9000, child=0xf80006b6d700, type=3)
   at ../../../kern/subr_bus.c:3419
   #11 0x8065d7a1 in pci_child_detached (dev=0xf80002cd9000,
   child=0xf80006b6d700) at ../../../dev/pci/pci.c:4133
   ---Type return to continue, or q return to quit---
   #12 0x80929708 in device_detach (dev=0xf80006b6d700)
   at bus_if.h:181
   #13 0x8065f9f7 in pci_delete_child (dev=0xf80002cd9000,
   child=0xf80006b6d700) at ../../../dev/pci/pci.c:4710
   
   In frame 9:
   (kgdb) fr 9
   #9  0x8093d037 in rman_get_rid (r=0xf800064c9380)
   at ../../../kern/subr_rman.c:979
   979 return (r-__r_i-r_rid);
   (kgdb) print r
   $1 = (struct resource *) 0xf800064c9380
   (kgdb) print/x *r
   $4 = {__r_i = 0xdeadc0dedeadc0de, r_bustag = 0xdeadc0dedeadc0de, 
 r_bushandle = 0xdeadc0dedeadc0de}
   
   So, looks like something is corrupted the resource data...
  
  This is the malloc junking on free.  However, I wonder if the
  problem is that the resource was freed without being properly
  cleared from the resource_list in the PCI ivars.  Is this with local
  patches that you have?
 
 Yes, but I didn't patch any of the pci code, or the resource code, so
 this bug is in the original code...  My patches only effect the attach
 case, don't touch the detach case...

What did you change in attach? :)  If the resource list isn't setup the same 
then that could cause this.  In particular, the PCI bus pre-reserves resources
for BARs so that they are allocated even if a driver hasn't allocated them.
 
-- 
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

Re: ahci panics when detaching...

2014-06-24 Thread John-Mark Gurney

John Baldwin wrote this message on Tue, Jun 24, 2014 at 09:51 -0400:
 On Monday, June 23, 2014 9:06:26 pm John-Mark Gurney wrote:
  John Baldwin wrote this message on Mon, Jun 23, 2014 at 10:49 -0400:
   On Monday, June 23, 2014 9:44:08 am John-Mark Gurney wrote:
So, when I try to eject a ESATA card, the machine panics...  I am able
to successfully eject other cards, an ethernet (re) and a serial card
(uart), and both handle the removal of their device w/o issue and with
out crashes...

When I try w/ ahci, I get a panic...  The panic backtrace is:
#8  0x80ced4e2 in calltrap () at 
   ../../../amd64/amd64/exception.S:231
#9  0x8093d037 in rman_get_rid (r=0xf800064c9380)
at ../../../kern/subr_rman.c:979
#10 0x8092b888 in resource_list_release_active 
   (rl=0xf80006d39c08,
bus=0xf80002cd9000, child=0xf80006b6d700, type=3)
at ../../../kern/subr_bus.c:3419
#11 0x8065d7a1 in pci_child_detached (dev=0xf80002cd9000,
child=0xf80006b6d700) at ../../../dev/pci/pci.c:4133
---Type return to continue, or q return to quit---
#12 0x80929708 in device_detach (dev=0xf80006b6d700)
at bus_if.h:181
#13 0x8065f9f7 in pci_delete_child (dev=0xf80002cd9000,
child=0xf80006b6d700) at ../../../dev/pci/pci.c:4710

In frame 9:
(kgdb) fr 9
#9  0x8093d037 in rman_get_rid (r=0xf800064c9380)
at ../../../kern/subr_rman.c:979
979 return (r-__r_i-r_rid);
(kgdb) print r
$1 = (struct resource *) 0xf800064c9380
(kgdb) print/x *r
$4 = {__r_i = 0xdeadc0dedeadc0de, r_bustag = 0xdeadc0dedeadc0de, 
  r_bushandle = 0xdeadc0dedeadc0de}

So, looks like something is corrupted the resource data...
   
   This is the malloc junking on free.  However, I wonder if the
   problem is that the resource was freed without being properly
   cleared from the resource_list in the PCI ivars.  Is this with local
   patches that you have?
  
  Yes, but I didn't patch any of the pci code, or the resource code, so
  this bug is in the original code...  My patches only effect the attach
  case, don't touch the detach case...
 
 What did you change in attach? :)  If the resource list isn't setup the same 
 then that could cause this.  In particular, the PCI bus pre-reserves resources
 for BARs so that they are allocated even if a driver hasn't allocated them.

What I mean by that is that I setup a few things in pci_attach_common,
like if the device has a slot that can hotplug, I attach an interrupt,
enable interrupts and a couple bookkeeping items... But that code
shouldn't change anything for ahci..

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: No devices/nodes/files in /dev after building and installing world

Mattia Rossi wrote this message on Mon, Jun 23, 2014 at 12:48 +0200:
 I'm currently stuck on the following. Haven't built HEAD in a while, and 
 now after a
 
 make buildworld kernel installworld distrib-dirs distribution
 
 I don't have any nodes in /dev at all. As far as I remember there was 
 always a minimum set of nodes in there, like ttys etc.
 
 What happened? Which changes did I miss?

We use devfs, so you don't need anything in /dev... when the system
boots, it'll automatically mount /dev for you..

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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

ahci panics when detaching...

So, when I try to eject a ESATA card, the machine panics...  I am able
to successfully eject other cards, an ethernet (re) and a serial card
(uart), and both handle the removal of their device w/o issue and with
out crashes...

When I try w/ ahci, I get a panic...  The panic backtrace is:
#8  0x80ced4e2 in calltrap () at ../../../amd64/amd64/exception.S:231
#9  0x8093d037 in rman_get_rid (r=0xf800064c9380)
at ../../../kern/subr_rman.c:979
#10 0x8092b888 in resource_list_release_active (rl=0xf80006d39c08,
bus=0xf80002cd9000, child=0xf80006b6d700, type=3)
at ../../../kern/subr_bus.c:3419
#11 0x8065d7a1 in pci_child_detached (dev=0xf80002cd9000,
child=0xf80006b6d700) at ../../../dev/pci/pci.c:4133
---Type return to continue, or q return to quit---
#12 0x80929708 in device_detach (dev=0xf80006b6d700)
at bus_if.h:181
#13 0x8065f9f7 in pci_delete_child (dev=0xf80002cd9000,
child=0xf80006b6d700) at ../../../dev/pci/pci.c:4710

In frame 9:
(kgdb) fr 9
#9  0x8093d037 in rman_get_rid (r=0xf800064c9380)
at ../../../kern/subr_rman.c:979
979 return (r-__r_i-r_rid);
(kgdb) print r
$1 = (struct resource *) 0xf800064c9380
(kgdb) print/x *r
$4 = {__r_i = 0xdeadc0dedeadc0de, r_bustag = 0xdeadc0dedeadc0de, 
  r_bushandle = 0xdeadc0dedeadc0de}

So, looks like something is corrupted the resource data...


Attach dmesg:
atapci0: JMicron JMB363 UDMA133 controller at device 0.0 on pci2
ahci1: JMicron JMB363 AHCI SATA controller at channel -1 on atapci0
ahci1: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported
ahci1: quirks=0x1NOFORCE
ahcich6: AHCI channel at channel 0 on ahci1
ahcich7: AHCI channel at channel 1 on ahci1
ata2: ATA channel at channel 0 on atapci0
[eject card]
ahcich6: stopping AHCI engine failed
ahcich6: stopping AHCI FR engine failed
ahcich6: detached
ahcich7: stopping AHCI engine failed
ahcich7: stopping AHCI FR engine failed
ahcich7: detached
ahci1: detached
ata2: detached
atapci0: detached


Fatal trap 9: general protection fault while in kernel mode

Also, has anyone thought about adding a case in your trap
handler that when we hit the deadc0de address, to print up a
special message or something?  At least flag it, or do we not get
the faulting address?

This is HEAD as of r266429.

Let me know if there is anything else you need to know.

Thanks.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: ahci panics when detaching...

Eric van Gyzen wrote this message on Mon, Jun 23, 2014 at 08:57 -0500:
 On 06/23/2014 08:44, John-Mark Gurney wrote:
  So, when I try to eject a ESATA card, the machine panics...  I am able
  to successfully eject other cards, an ethernet (re) and a serial card
  (uart), and both handle the removal of their device w/o issue and with
  out crashes...
 
  When I try w/ ahci, I get a panic...  The panic backtrace is:
  #8  0x80ced4e2 in calltrap () at 
  ../../../amd64/amd64/exception.S:231
  #9  0x8093d037 in rman_get_rid (r=0xf800064c9380)
  at ../../../kern/subr_rman.c:979
  #10 0x8092b888 in resource_list_release_active 
  (rl=0xf80006d39c08,
  bus=0xf80002cd9000, child=0xf80006b6d700, type=3)
  at ../../../kern/subr_bus.c:3419
  #11 0x8065d7a1 in pci_child_detached (dev=0xf80002cd9000,
  child=0xf80006b6d700) at ../../../dev/pci/pci.c:4133
  ---Type return to continue, or q return to quit---
  #12 0x80929708 in device_detach (dev=0xf80006b6d700)
  at bus_if.h:181
  #13 0x8065f9f7 in pci_delete_child (dev=0xf80002cd9000,
  child=0xf80006b6d700) at ../../../dev/pci/pci.c:4710
 
  In frame 9:
  (kgdb) fr 9
  #9  0x8093d037 in rman_get_rid (r=0xf800064c9380)
  at ../../../kern/subr_rman.c:979
  979 return (r-__r_i-r_rid);
  (kgdb) print r
  $1 = (struct resource *) 0xf800064c9380
  (kgdb) print/x *r
  $4 = {__r_i = 0xdeadc0dedeadc0de, r_bustag = 0xdeadc0dedeadc0de, 
r_bushandle = 0xdeadc0dedeadc0de}
 
  So, looks like something is corrupted the resource data...
 
 The resource data has been freed.

Well, that is a type of corruption.. :)  If we free it, why wasn't
it removed from the list? or properly NULL'd out?

  Attach dmesg:
  atapci0: JMicron JMB363 UDMA133 controller at device 0.0 on pci2
  ahci1: JMicron JMB363 AHCI SATA controller at channel -1 on atapci0
  ahci1: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported
  ahci1: quirks=0x1NOFORCE
  ahcich6: AHCI channel at channel 0 on ahci1
  ahcich7: AHCI channel at channel 1 on ahci1
  ata2: ATA channel at channel 0 on atapci0
  [eject card]
  ahcich6: stopping AHCI engine failed
  ahcich6: stopping AHCI FR engine failed
  ahcich6: detached
  ahcich7: stopping AHCI engine failed
  ahcich7: stopping AHCI FR engine failed
  ahcich7: detached
  ahci1: detached
  ata2: detached
  atapci0: detached
 
 
  Fatal trap 9: general protection fault while in kernel mode
 
  Also, has anyone thought about adding a case in your trap
  handler that when we hit the deadc0de address, to print up a
  special message or something?  At least flag it, or do we not get
  the faulting address?
 
  This is HEAD as of r266429.
 
  Let me know if there is anything else you need to know.
 
 The full stack trace might be useful.

I could give it to you, but it contains code I can't release (at
least not yet)...  It's basicly an interrupt that calls
pci_delete_child, so there isn't anymore useful information there..

I'm just puzzled why uart and re don't have this same problem..

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: Latest -current panic in uaudio_detach() / bus_dmamem_free()

2014-06-23 Thread John Baldwin

On Monday, June 23, 2014 12:03:20 am Andrey Chernov wrote:
 On 23.06.2014 6:46, Alexander Kabaev wrote:
  Please provide us with the information on the actual audio hardware
  you are using, preferably in form of a dmesg output. 
 
 uaudio0: vendor 0x046d product 0x0990, class 239/2, rev 2.00/0.05, addr 7 
on usbus3
 uaudio0: No playback.
 uaudio0: Record: 16000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
 uaudio0: No MIDI sequencer.
 pcm7: USB audio on uaudio0
 uaudio0: No HID volume keys found.
 
 Thanx, after backing out the patch below this panic is gone. Probably even 
 additional b-dmatag NULL check is needed for bus_dmamap_unload() too.

No, buf_addr should only be set if bus_dmamap_load() was called.

-- 
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

Re: ahci panics when detaching...

2014-06-23 Thread John Baldwin

On Monday, June 23, 2014 9:44:08 am John-Mark Gurney wrote:
 So, when I try to eject a ESATA card, the machine panics...  I am able
 to successfully eject other cards, an ethernet (re) and a serial card
 (uart), and both handle the removal of their device w/o issue and with
 out crashes...
 
 When I try w/ ahci, I get a panic...  The panic backtrace is:
 #8  0x80ced4e2 in calltrap () at 
../../../amd64/amd64/exception.S:231
 #9  0x8093d037 in rman_get_rid (r=0xf800064c9380)
 at ../../../kern/subr_rman.c:979
 #10 0x8092b888 in resource_list_release_active 
(rl=0xf80006d39c08,
 bus=0xf80002cd9000, child=0xf80006b6d700, type=3)
 at ../../../kern/subr_bus.c:3419
 #11 0x8065d7a1 in pci_child_detached (dev=0xf80002cd9000,
 child=0xf80006b6d700) at ../../../dev/pci/pci.c:4133
 ---Type return to continue, or q return to quit---
 #12 0x80929708 in device_detach (dev=0xf80006b6d700)
 at bus_if.h:181
 #13 0x8065f9f7 in pci_delete_child (dev=0xf80002cd9000,
 child=0xf80006b6d700) at ../../../dev/pci/pci.c:4710
 
 In frame 9:
 (kgdb) fr 9
 #9  0x8093d037 in rman_get_rid (r=0xf800064c9380)
 at ../../../kern/subr_rman.c:979
 979 return (r-__r_i-r_rid);
 (kgdb) print r
 $1 = (struct resource *) 0xf800064c9380
 (kgdb) print/x *r
 $4 = {__r_i = 0xdeadc0dedeadc0de, r_bustag = 0xdeadc0dedeadc0de, 
   r_bushandle = 0xdeadc0dedeadc0de}
 
 So, looks like something is corrupted the resource data...

This is the malloc junking on free.  However, I wonder if the
problem is that the resource was freed without being properly
cleared from the resource_list in the PCI ivars.  Is this with local
patches that you have?

-- 
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

Re: ahci panics when detaching...

John Baldwin wrote this message on Mon, Jun 23, 2014 at 10:49 -0400:
 On Monday, June 23, 2014 9:44:08 am John-Mark Gurney wrote:
  So, when I try to eject a ESATA card, the machine panics...  I am able
  to successfully eject other cards, an ethernet (re) and a serial card
  (uart), and both handle the removal of their device w/o issue and with
  out crashes...
  
  When I try w/ ahci, I get a panic...  The panic backtrace is:
  #8  0x80ced4e2 in calltrap () at 
 ../../../amd64/amd64/exception.S:231
  #9  0x8093d037 in rman_get_rid (r=0xf800064c9380)
  at ../../../kern/subr_rman.c:979
  #10 0x8092b888 in resource_list_release_active 
 (rl=0xf80006d39c08,
  bus=0xf80002cd9000, child=0xf80006b6d700, type=3)
  at ../../../kern/subr_bus.c:3419
  #11 0x8065d7a1 in pci_child_detached (dev=0xf80002cd9000,
  child=0xf80006b6d700) at ../../../dev/pci/pci.c:4133
  ---Type return to continue, or q return to quit---
  #12 0x80929708 in device_detach (dev=0xf80006b6d700)
  at bus_if.h:181
  #13 0x8065f9f7 in pci_delete_child (dev=0xf80002cd9000,
  child=0xf80006b6d700) at ../../../dev/pci/pci.c:4710
  
  In frame 9:
  (kgdb) fr 9
  #9  0x8093d037 in rman_get_rid (r=0xf800064c9380)
  at ../../../kern/subr_rman.c:979
  979 return (r-__r_i-r_rid);
  (kgdb) print r
  $1 = (struct resource *) 0xf800064c9380
  (kgdb) print/x *r
  $4 = {__r_i = 0xdeadc0dedeadc0de, r_bustag = 0xdeadc0dedeadc0de, 
r_bushandle = 0xdeadc0dedeadc0de}
  
  So, looks like something is corrupted the resource data...
 
 This is the malloc junking on free.  However, I wonder if the
 problem is that the resource was freed without being properly
 cleared from the resource_list in the PCI ivars.  Is this with local
 patches that you have?

Yes, but I didn't patch any of the pci code, or the resource code, so
this bug is in the original code...  My patches only effect the attach
case, don't touch the detach case...

I was hoping someone who knows the code was like, yeh, I do remeber
that place in the code where we free something, but don't properly
NULL out the pointer, etc...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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: [patch] USB after second suspend/resume on ThinkPads.

On Monday, June 16, 2014 3:21:55 pm Edward Tomasz Napierała wrote:
 Hi.  Patch below should fix a problem where USB stops working after
 _second_ suspend/resume, which happens on various ThinkPad models.
 Please test, and report both success stories and failures.  If nothing
 comes up, I'll commit it in a week or so.

Good find.  Have you thought about a more generic fix for this wherein you 
track power resources and flip them on during resume in ACPI before doing
DEVICE_RESUME() on the root bus?

Alternatively, this probably meshes well with Justin's work on multipass 
suspend/resume in that ACPI buses (e.g. acpi_pci and acpi0 itself) should be 
turning on any power sources associated with an ACPI device during the 
bus_resume_child() callback.

-- 
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

Re: [RFC] Huge sysctl patch for the kernel coming - work in progress

On Wednesday, June 18, 2014 7:36:53 am Hans Petter Selasky wrote:
 Hi,
 
 Sometimes sysctl's default value needs to be setup at boot time and not 
 when the rc.d/sysctl is running. Currently this is done by having two 
 statements in the kernel:
 
 TUNABLE_INT(net.graph.mppe.log_max_rekey, mppe_log_max_rekey);
 SYSCTL_INT(_net_graph_mppe, OID_AUTO, log_max_rekey, CTLFLAG_RW,
 
 I want to simplify this to:
 
 SYSCTL_INT(_net_graph_mppe, OID_AUTO, log_max_rekey, CTLFLAG_RWTUN,
 
 In other words if the existing CTLFLAG_TUN is set, the sysctl will 
 automatically be pre-loaded with values from /boot/loader.conf.
 
 The reason we don't want the current approach is:
 
 1) It duplicates the sysctl path in the TUNABLE statement.
 2) It does not work very well for dynamically attached sysctls. There is 
 a lot of code overhead computing the TUNABLE() path before the TUNABLE() 
 can be fetched.
 
 Here is a work in progress:
 
 http://home.selasky.org:8192/sysctl_tunable.diff
 
 In most cases my patch is fine, but in some other cases I need some 
 input, like in the VM subsystem when doing init, I'm not sure if the 
 SYSINIT() for subsystem SI_SUB_KMEM, which sysctl's are using, has 
 already been executed.

I think this is a good idea, but it's also true you can just leave separate
TUNABLE_ statements without setting the CTLFLAG_TUN flag for cases you aren't
sure about for now.  It probably makes sense to do these changes in stages.

I was going to suggest using sbuf() for building the tunable name, but that
doesn't work since you have to build it in reverse.

-- 
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

Re: [patch] USB after second suspend/resume on ThinkPads.

On Wednesday, June 18, 2014 12:13:15 pm Edward Tomasz Napierała wrote:
 On 0618T0947, John Baldwin wrote:
  On Monday, June 16, 2014 3:21:55 pm Edward Tomasz Napierała wrote:
   Hi.  Patch below should fix a problem where USB stops working after
   _second_ suspend/resume, which happens on various ThinkPad models.
   Please test, and report both success stories and failures.  If nothing
   comes up, I'll commit it in a week or so.
  
  Good find.  Have you thought about a more generic fix for this wherein you 
  track power resources and flip them on during resume in ACPI before doing
  DEVICE_RESUME() on the root bus?
 
 Thing is, after resume this device claims to be on already.  The following
 simple hack was enough to make it work:

Ahh, I think I see.  Try this instead:

Index: sys/dev/acpica/acpi_powerres.c
===
--- acpi_powerres.c (revision 267550)
+++ acpi_powerres.c (working copy)
@@ -645,7 +645,7 @@ acpi_pwr_switch_power(void)
  acpi_name(rp-ap_resource), status));
/* XXX is this correct?  Always switch if in doubt? */
continue;
-   } else if (rp-ap_state == ACPI_PWR_UNK)
+   } else
rp-ap_state = cur;
 
/*
@@ -689,7 +689,7 @@ acpi_pwr_switch_power(void)
  acpi_name(rp-ap_resource), status));
/* XXX is this correct?  Always switch if in doubt? */
continue;
-   } else if (rp-ap_state == ACPI_PWR_UNK)
+   } else
rp-ap_state = cur;
 
/*

(We were ignoring what _STA told us and believed it was ON because we had
 cached that state previously.)

-- 
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

Re: [patch] USB after second suspend/resume on ThinkPads.

On Wednesday, June 18, 2014 2:46:09 pm Edward Tomasz Napierała wrote:
 On 0618T1303, John Baldwin wrote:
  On Wednesday, June 18, 2014 12:13:15 pm Edward Tomasz Napierała wrote:
   On 0618T0947, John Baldwin wrote:
On Monday, June 16, 2014 3:21:55 pm Edward Tomasz Napierała wrote:
 Hi.  Patch below should fix a problem where USB stops working after
 _second_ suspend/resume, which happens on various ThinkPad models.
 Please test, and report both success stories and failures.  If nothing
 comes up, I'll commit it in a week or so.

Good find.  Have you thought about a more generic fix for this wherein 
you 
track power resources and flip them on during resume in ACPI before 
doing
DEVICE_RESUME() on the root bus?
   
   Thing is, after resume this device claims to be on already.  The following
   simple hack was enough to make it work:
  
  Ahh, I think I see.  Try this instead:
  
  Index: sys/dev/acpica/acpi_powerres.c
  ===
  --- acpi_powerres.c (revision 267550)
  +++ acpi_powerres.c (working copy)
  @@ -645,7 +645,7 @@ acpi_pwr_switch_power(void)
acpi_name(rp-ap_resource), status));
  /* XXX is this correct?  Always switch if in doubt? */
  continue;
  -   } else if (rp-ap_state == ACPI_PWR_UNK)
  +   } else
  rp-ap_state = cur;
   
  /*
  @@ -689,7 +689,7 @@ acpi_pwr_switch_power(void)
acpi_name(rp-ap_resource), status));
  /* XXX is this correct?  Always switch if in doubt? */
  continue;
  -   } else if (rp-ap_state == ACPI_PWR_UNK)
  +   } else
  rp-ap_state = cur;
   
  /*
  
  (We were ignoring what _STA told us and believed it was ON because we had
   cached that state previously.)
 
 Works!

Hmmm.  If we go this route, ap_state is actually useless and should just be
removed.  Here is an updated version that does that.  If this works as well
then this is probably a commit candidate.

Index: acpi_powerres.c
===
--- acpi_powerres.c (revision 267550)
+++ acpi_powerres.c (working copy)
@@ -64,7 +64,6 @@ ACPI_MODULE_NAME(POWERRES)
 /* Return values from _STA on a power resource */
 #define ACPI_PWR_OFF   0
 #define ACPI_PWR_ON1
-#define ACPI_PWR_UNK   (-1)
 
 /* A relationship between a power resource and a consumer. */
 struct acpi_powerreference {
@@ -90,7 +89,6 @@ struct acpi_powerresource {
 ACPI_HANDLEap_resource;
 UINT64 ap_systemlevel;
 UINT64 ap_order;
-intap_state;
 };
 
 static TAILQ_HEAD(acpi_powerresource_list, acpi_powerresource)
@@ -173,7 +171,6 @@ acpi_pwr_register_resource(ACPI_HANDLE res)
 }
 rp-ap_systemlevel = obj-PowerResource.SystemLevel;
 rp-ap_order = obj-PowerResource.ResourceOrder;
-rp-ap_state = ACPI_PWR_UNK;
 
 /* Sort the resource into the list */
 status = AE_OK;
@@ -638,7 +635,6 @@ acpi_pwr_switch_power(void)
continue;
}
 
-   /* We could cache this if we trusted it not to change under us */
status = acpi_GetInteger(rp-ap_resource, _STA, cur);
if (ACPI_FAILURE(status)) {
ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, can't get status of %s - %d\n,
@@ -645,8 +641,7 @@ acpi_pwr_switch_power(void)
  acpi_name(rp-ap_resource), status));
/* XXX is this correct?  Always switch if in doubt? */
continue;
-   } else if (rp-ap_state == ACPI_PWR_UNK)
-   rp-ap_state = cur;
+   }
 
/*
 * Switch if required.  Note that we ignore the result of the switch
@@ -653,7 +648,7 @@ acpi_pwr_switch_power(void)
 * effort; we don't know what to do if it fails, so checking wouldn't
 * help much.
 */
-   if (rp-ap_state != ACPI_PWR_ON) {
+   if (cur != ACPI_PWR_ON) {
status = AcpiEvaluateObject(rp-ap_resource, _ON, NULL, NULL);
if (ACPI_FAILURE(status)) {
ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS,
@@ -661,7 +656,6 @@ acpi_pwr_switch_power(void)
 acpi_name(rp-ap_resource),
 AcpiFormatException(status)));
} else {
-   rp-ap_state = ACPI_PWR_ON;
ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, switched %s on\n,
 acpi_name(rp-ap_resource)));
}
@@ -682,7 +676,6 @@ acpi_pwr_switch_power(void)
continue;
}
 
-   /* We could cache this if we trusted it not to change under us */
status = acpi_GetInteger(rp-ap_resource, _STA, cur);
if (ACPI_FAILURE(status)) {
ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, can't get status of %s - %d\n,
@@ -689,8 +682,7 @@ acpi_pwr_switch_power(void

Re: [RFC] Huge sysctl patch for the kernel coming - work in progress