[Bug 197336] find command cannot see more than 32765 subdirectories when using ZFS
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: "
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
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
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
[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
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
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
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
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
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
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
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
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
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
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
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"