[Bug 197336] find command cannot see more than 32765 subdirectories when using ZFS

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197336

Andrey V. Elsukov  changed:

   What|Removed |Added

 CC||a...@freebsd.org

--- Comment #2 from Andrey V. Elsukov  ---
Add link to the explanation from bde@
https://lists.freebsd.org/pipermail/freebsd-bugs/2015-February/060317.html

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 197756] System stops booting with "ACPI APIC Table: "

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197756

Bug ID: 197756
   Summary: System stops booting with "ACPI APIC Table: "
   Product: Base System
   Version: 11.0-CURRENT
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: zap...@berentweb.com

* I'm PXE/diskless booting a Samsung RS40 Laptop (Intel i3 CPU, Radeon
Manhattan Mobility HD-5400 GPU 3GB RAM)
* I built a new kernel yesterday and got this error. The kernel I was using
from Feb.04.2015 did not have this problem (so it's a recent event).
* Same kernel on my other hardware (not laptops) does not encounter this
problem.
* Problem possibly similar to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196542
* Booting halts and system hangs with:

ACPI APIC Table: 
panic: Failed to deliver first STARTUP IPI to APIC 1
cpuid=0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x81bd4af0
vpanic() at vpanic+0x189/frame 0x81bd4b70
panic() at panic+0x43/frame 0x81bd4bd0
ipi_startup() at ipi_startup+0x5b/frame 0x81bd4bf0
native_start_all_apps() at native_start_all_apps+0x232/frame 0x81bd4c40
cpu_mp_start() at cpu_mp_start+0x342/frame 0x81bd4c70
mp_start() at mp_start+0x3d/frame 0x81bd4c90
mi_startup() at mi_startup+0x118/frame 0x81bd4cb0
btext() at btext+0x2c
KDB: enter: panic  /EOF

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 191359] [memguard] [panic] Memory modified after free w/MEMGUARD build

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191359

Garrett Cooper,425-314-3911  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|n...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 191359] [memguard] [panic] Memory modified after free w/MEMGUARD build

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191359

--- Comment #5 from Garrett Cooper,425-314-3911  ---
CR: https://reviews.freebsd.org/D1865

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


Aerospace Segway Technology Mono Air

2015-02-17 Thread ImporterDeals
   [1]Importer Dealer
   [wheel.jpg]
   HOT PRODUCT
   CLEARANCE SALE

Air Wheel Bike

   [wheel.png]

Only

$499.00

Was $1299.00

   Buy Now

Details

   Airwheel is the state-of-the-art means of transportation adopting
   aerospace attitude control theory, software algorithm and gyroscope
   system to maintain balance by...

   View

240 Watt Solar Folding
Only $290.00

   View More

Safe Wash
Only $299.00

   Watch Video

   [2]Visit our website | QLD Australia

 This email was sent by ImporterDeals, Brisbane QLD 4000 to
  freebsd-bugs@freebsd.org
   [3]Unsubscribe

References

   Visible links
   1. http://www.vision6.com.au/ch/44773/f1m4x/1738543/29763b93r.html
   2. http://www.vision6.com.au/ch/44773/f1m4x/1738542/2976316zf9.html
   3. http://www.vision6.com.au/forms/u/67cf575/44773/12196938.html

   Hidden links:
   5. http://www.vision6.com.au/ch/44773/f1m4x/1887167/29763z74p.html
   6. http://www.vision6.com.au/ch/44773/f1m4x/1887167/29763z74p-1.html
   7. http://www.vision6.com.au/ch/44773/f1m4x/1887168/2976359dz.html
   8. http://www.vision6.com.au/ch/44773/f1m4x/1887169/2976349sh.html
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 197336] find command cannot see more than 32765 subdirectories when using ZFS

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197336

--- Comment #3 from Will Dormann  ---
> It is impossible for the other file systems to work much better.  Perhaps
> they work up to 65535, or have the correct {LINK_MAX} and the python script
> is smart enough to avoid it.  I doubt that python messes with {LINK_MAX},
> but creation of subdirectories should stop when the advertized limit is
> hit, and python or the script should handle that, possibly just by
> stopping.


I don't know what to say about it being impossible that other filesystems work
better.   Because FreeBSD doesn't support R/W ReiserFS, I used a USB thumb
drive both formatted and populated (with the python script) on a Linux system. 
 And with the case of unionfs, I simply had a FreeBSD Jail that shared the
underlying ZFS directory structure.

In both cases, the find command successfully reported the existence of all
300,000 subdirectories.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 197535] [re] [panic] if_re (Realtek 8168) causes memory write after free and kernel panic

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535

--- Comment #7 from luca.pizzamig...@gmail.com ---
I tested disabling super pages and I get the same behavior. I verified the
sysctl bit and it was disabled.
I tested disabling tso (as suggested on mailing list, despite tso was already 
disabled) and I get the same behavior.

I would love to implement the API to load this firmware blob, to test it. It
could take some time but it seems doable. Firmware blobs are not GPLed, they're
distributed as binary permitted by the vendor. BTW, I would just test it.

In parallel, I'll try to understand where this new rx_desc are written, if
there's a logical connection with the loaded DMA maps.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 197764] bsd.dep.mk appears to missing a .ORDER: directive

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197764

Bug ID: 197764
   Summary: bsd.dep.mk appears to missing a .ORDER: directive
   Product: Base System
   Version: 11.0-CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: misc
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: catte...@thebarn.com

While working with a beforedepends target we notices that in some cases the 
files generated by the beforedpends were not showing up in time for the
depends phase to find the generated files.

By adding a sleep to the beforedepends rule is was easy to see that the
actually depends phase was not waiting for the beforedepends to finish.

This look to be a simple omission of an .ORDER: 

iff --git a/share/mk/bsd.dep.mk b/share/mk/bsd.dep.mk
index cbbb4d6..db5ddd7 100644
--- a/share/mk/bsd.dep.mk
+++ b/share/mk/bsd.dep.mk
@@ -122,6 +122,7 @@ ${_YC:R}.o: ${_YC}
 .if !target(depend)
 .if defined(SRCS)
 depend: beforedepend ${DEPENDFILE} afterdepend
+.ORDER: beforedepend ${DEPENDFILE} afterdepend

 # Different types of sources are compiled with slightly different flags.
 # Split up the sources, and filter out headers and non-applicable flags.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 197766] [patch] GEOM_MAP does not build

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197766

Bug ID: 197766
   Summary: [patch] GEOM_MAP does not build
   Product: Base System
   Version: 9.3-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: eu...@grosbein.net

Created attachment 153111
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=153111&action=edit
patch for geom_map.c, NOTES and options

geom_map(4) is present in kernel source since 9.0-RELEASE but is not included
in sys/conf/options and does not build for amd64 due to printf format bugs. The
following patch makes it possible to use "options GEOM_MAP" in a kernel
configuration file, includes GEOM_MAP to the NOTES and fixes format bugs.

The patch is production-tested with amd64 platform and compile-tested with
i386.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 197535] [re] [panic] if_re (Realtek 8168) causes memory write after free and kernel panic

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535

ohart...@zedat.fu-berlin.de changed:

   What|Removed |Added

 CC||ohart...@zedat.fu-berlin.de

--- Comment #8 from ohart...@zedat.fu-berlin.de ---
See also Bug 193743 - RTL8111/8168B PCI Express Gigabit Ethernet controller:
doesn't work properly, problems getting UP automatically

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 197769] env cores for a pretty simple expression

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197769

Bug ID: 197769
   Summary: env cores for a pretty simple expression
   Product: Base System
   Version: 10.0-STABLE
  Hardware: i386
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: kevin.braunsdorf+freeb...@gmail.com

XXX=-u env -v -u NAME -S '${XXX}\_NAME'

drops core.  I don't think it should drop core.

That is reduced from a much longer expression, of course.

--ksb

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 145590] [kernel] [patch] SIG_ATOMIC_{MIN,MAX} does not match sig_atomic_t on 64-bit archs

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=145590

Jilles Tjoelker  changed:

   What|Removed |Added

 CC||jil...@freebsd.org
 Status|In Progress |Closed
 Resolution|--- |FIXED

--- Comment #2 from Jilles Tjoelker  ---
This was fixed in 10-current by SVN r227474 and in 9-stable by SVN r263539.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 197773] [snd_hda][patch] Sending a devctl notifications when headphones are connected/disconnected

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197773

Bug ID: 197773
   Summary: [snd_hda][patch] Sending a devctl notifications when
headphones are connected/disconnected
   Product: Base System
   Version: 10.1-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: e...@inbox.ru

It would be nice to have devctl/devd notifications when headphones are
connected/disconnected.

E.g.,
cat /var/run/devd.pipe
!system=SND_HDA subsystem=headphones type=connection state=disconnected
!system=SND_HDA subsystem=headphones type=connection state=connected

So, with some devd.conf-magic one could easily preserve and restore mixer (or
hw.snd.default_unit) settings.

Maybe, something like this:
Index: /usr/src/sys/dev/sound/pci/hda/hdaa.c
===
*** /usr/src/sys/dev/sound/pci/hda/hdaa.c(revision 278924)
--- /usr/src/sys/dev/sound/pci/hda/hdaa.c(working copy)
***
*** 381,394 
--- 381,397 
  struct hdaa_devinfo *devinfo = w->devinfo;
  struct hdaa_audio_as *as = &devinfo->as[w->bindas];
  struct hdaa_widget *w1;
  struct hdaa_audio_ctl *ctl;
  uint32_t val;
  int j, connected = w->wclass.pin.connected;

+ devctl_notify("SND_HDA", "headphones", "connection", 
+ connected ? "state=connected" : "state=disconnected");
+ 
  HDA_BOOTVERBOSE(
  device_printf((as->pdevinfo && as->pdevinfo->dev) ?
  as->pdevinfo->dev : devinfo->dev,
  "Redirect output to: %s\n",
  connected ? "headphones": "main");
  );
  /* (Un)Mute headphone pin. */

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 197778] Implement the AT_EMPTY_PATH race free Linux extension

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197778

Bug ID: 197778
   Summary: Implement the AT_EMPTY_PATH race free Linux extension
   Product: Base System
   Version: 11.0-CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: s_bugzi...@nedprod.com

Related: #197695

Due to only accepting paths, POSIX makes it hard to unlink and rename files
without creating race conditions. For example to unlink a file as safely as is
possible under POSIX:

1. Get one of the current paths of the open file descriptor using any facility
provided if #197695 were implement.

2. Open its containing directory.

3. Do a fstatat() on the containing directory for the leafname of the open file
descriptor, checking if the device ids and inodes match the ones for our file
descriptor.

4. If they match, do an unlinkat() to remove the leafname. NOTE THIS IS RACY as
another program could swap our leafname for another between the fstatat and the
unlinkat.

This raciness is disagreeable in this modern day and age. Moreover, Linux has
partially added an extension via the AT_EMPTY_PATH flag which enables the
XXXat() suite of functions work directly with the file descriptor. At the time
of writing (Feb 2015), Linux implements the AT_EMPTY_PATH extension for:

linkat(), fchownat(), fstatat(), name_to_handle_at().

The AT_EMPTY_PATH extension works as follows, so to create a new hard link for
some file descriptor:

linkat(fd, "", dirh, "name", AT_EMPTY_PATH)

Note the empty path, and the passing in of a file descriptor which may or may
not refer to a directory as the olddirh fd normally must.

There are some obviously useful missing functions which could do with the
AT_EMPTY_PATH extension:

unlinkat(), renameat().

I have filed a feature request for those with the Linux kernel at
https://bugzilla.kernel.org/show_bug.cgi?id=93441. Note that because Linux
allows the direct opening of symlinks via the flag O_PATH, on Linux you can use
linkat() to duplicate a symlink race free. As FreeBSD doesn't provide the
ability to directly open symlinks, I'd actually make the total list of
functions which this request asks for the AT_EMPTY_PATH extension upon to be:

linkat(), fchownat(), fstatat(), unlinkat(), renameat(), symlinkat(),
faccessat(), fchmodat().

Of these, renameat() and symlinkat() currently do not take a flags parameter.
You could varargs those, or else enable the above functions to treat a null
path fragment as equivalent to the dirh being the source filing system entry
being modified i.e. a null path fragment = AT_EMPTY_PATH semantics.

Or indeed additional f* variants of the non-at functions could be added which
consume file descriptors instead of paths e.g. the oft wished for flink() (more
discussion is at http://lwn.net/Articles/562488/). The point here is making it
possible to use the filing system without any possibility of race conditions,
something only Microsoft Windows currently permits.

Some may observe that all this is a potential security hole e.g. child
processes supposedly sandboxed could unlink or cause mischief with file
descriptors they inherit, or otherwise destroy data. A similar argument could
be fielded against #197695, except that every major OS except for FreeBSD has
provided fd to path reading for years and I am unaware of any security issues
which have emerged. For obvious reasons any of the above functions should fail
if their path based equivalent would fail from the privileges available to a
child process.

Niall

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 197695] Add facility to retrieve a canonical path for a currently open file descriptor

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197695

Niall Douglas  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=1977
   ||78

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 197778] Implement the AT_EMPTY_PATH race free Linux extension

2015-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197778

Niall Douglas  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=1976
   ||95

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"