Re: Massive libxo-zation that breaks everything
On Wednesday, March 04, 2015 10:35:34 AM Alfred Perlstein wrote: On 3/4/15 8:21 AM, John Baldwin wrote: I would probably want pciconf -l in that case to dump the entire PCI header (right now the human-readable pciconf -l only dumps a subset), and I would want it to dump fields in capabilities that we don't currently bother printing (and that I don't think the human-readable output should print due to it being too obscure, etc.) I actually agree on this and this is why I was upset that the more straightforward GSoC code was shot down in favor of this. That said don't we all need to look at the greater good when making software and we have some consensus on this so its worth going forward imo. We can agree on something even though it might make hairs stand up or we just stagnate. I think there might some cases where converting the existing output directly is fine (netstat -s comes to mind), but I think we should not be opposed to the idea that some utilities should output a different set of data for machine -readable. Put another way, in my mind something like pciconf -l is a presentation layer, and it's just one way of representing the data involved. Ideally, something like pciconf -l could be rewritten as a consumer of the raw, machine-readable data (I'm not sure I would rewrite it, but in theory the data flow should be something like raw data in kernel - machine-readable format - presentation.) For example, pciconf -l currently has the misfeature that it is a flat listing and doesn't properly communicate the hierarchy that you can see in devinfo (and often times that hiearchy does matter). I would want a machine-readable schema for PCI devices to describe the hierarcy so that you could implement multiple views of the data (think lspci -t vs pciconf -l). However, I think that requires designing the schema in terms of the data you are describing, not based on one extant view/presentation. To expend this further, suppose that pciconf supported multiple views like lspci, would you want that to translate into multiple machine-readable schemas? -- 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] load network config file from netif init script
On Monday, February 02, 2015 12:21:19 PM Roger Pau Monné wrote: Hello, r272959 broke compatibility with mfsBSD that stores the default network config file in /etc/rc.conf.d/network. In order to fix that load the network config file from netif also. I'm attaching a patch to restore previous functionality, but since I'm not an expert on rc.d init scripts I would like some feedback on whether this is the right approach or not. Thanks, Roger. If you are still looking for review, you can try freebsd-rc@ perhaps? -- 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: r279278 failed to build (yacc: maximum table size exceeded)
On Wednesday, February 25, 2015 03:15:36 PM Jung-uk Kim wrote:
On 02/25/2015 14:59, Arseny Nasokin wrote:
On 25 February 2015 at 22:14, Jung-uk Kim j...@freebsd.org
mailto:j...@freebsd.org wrote:
On 02/25/2015 14:05, Glen Barber wrote:
On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org
mailto:j...@freebsd.org
wrote:
Your installed yacc(1) is too old, i.e., your world was
built from head before r274460. FYI, this commit fixes the
above problem for building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to
manually bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc make clean cleandepend make all
make install make clean cleandepend cd /usr/src make
buildworld
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap
build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506 _yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes
only!!! _yacc= lib/liby \
This can be set to 1001507 now; __FreeBSD_version was bumped
earlier today.
Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10
and __FreeBSD_version was bumped to reflect it.
https://svnweb.freebsd.org/changeset/base/277087
Jung-uk Kim
Jung,
I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and
invalid YACC. So This conditional expression must be fixed to check
if this 11.x and yacc is not changed.
Wow, that's more than 9-month old now.
In my hypothetical patch I set OSRELDATE to invalid abstract
future version, because it's only concept and I have no time to fix
it correctly now.
If you insist, you can try this:
--- Makefile.inc1
+++ Makefile.inc1
@@ -1274,7 +1274,8 @@
_awk=usr.bin/awk
.endif
-.if ${BOOTSTRAPPING} 1001506
+.if ${BOOTSTRAPPING} 1001506 || \
+(${BOOTSTRAPPING} = 110 ${BOOTSTRAPPING} 1100046)
_yacc= lib/liby \
usr.bin/yacc
(but I won't commit it.)
Maybe just make the check always be 1100046? It doesn't really hurt to
build yacc on more recent 10 stable does it?
--
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: bombarded with LOR's with recent install
On Wednesday, February 25, 2015 10:19:32 AM Chris H wrote: On Wed, 25 Feb 2015 09:42:54 -0800 Chris H bsd-li...@bsdforge.com wrote On Wed, 25 Feb 2015 08:56:14 -0800 Chris H bsd-li...@bsdforge.com wrote I see somebody also reported something along these lines, recently; http://freebsd.1045724.n5.nabble.com/ufs-devfs-quot-lock-order-reversal-qu ot- on-poweroff-td5989901.html But there was no reported resolution. and again in January, as well. https://www.mail-archive.com/freebsd-current@freebsd.org/msg158784.html Is there any way to switch off WITNESS, INVARIANTS SKIPSPIN in the GENERIC that is installed, outside of building a new kernel? The VFS ones are more complicated. You can add options 'WITNESS_NO_VNODE' to your kernel config to limit the noise. (Someone should turn that into a sysctl/tunable so it can be enabled in a stock 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: msk0 watchdog timeout Marvel 88E8071
On Monday, February 23, 2015 09:00:24 AM David Demelier wrote: Le 21/02/2015 23:46, Roosevelt Littleton a écrit : My msk0 is not even functional and my wifi is my only usable connection to the internet. I have the same problem with my Marvell Yukon 2. Working fine in 10.0, now broken in 10.1. Can you narrow down the commit that broke it for you? I know there were some msk(4) changes merged between 10.0 and 10.1 that fixed msk(4) for some other folks. -- 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: Questions on adding backlight support for the i915 driver
On 1/30/15 6:16 PM, Adrian Chadd wrote: Hi, Which chipset is it? Loading acpi_video causes a handful of interconnected pieces to shift (as IIRC at that point acpi_video also states that it wishes to take control of video setting, not just leave it all up to ACPI to drive itself.) There's a bunch of discussion / code churn in the linux dri2/i915 code (/past/ the point in 2012 that our code is currently synced to) about how to manage backlights. A lot of it seems due to ridiculously large variations in how backlights are actually managed. So, if we're going to do this, I think we should actually have a generic backlight thing that figures out if the right thing to do is talk to the underlying device/panel, rather than hang backlight controls off of each driver. It may not always be off of drm. :( There's also stuff surrounding locking and state changes, as well as restoring backlight values after a suspend/resume cycle. That kind of weird crap. I think we should get a few examples working so we have multiple things to generalize from. Also, so far the focus has only been on laptop LCDs. I've no idea if any external monitors support software backlight control. If they do, then that might put another wrinkle in, as what you really want is something like hw.backlight.monitor to hang control nodes off of (or you want to do it in userland). (Ideally we'd use the same labels for monitor that xrandr uses for outputs. I think the drm2 drivers are also using those labels for some controls now.) For now I would start with Elizabeth's current patch of exposing the raw i915 stuff via a sysctl. We can always remove this later if need be. -- 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: PSA: If you run -current, beware!
On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote: On Thursday, February 5, 2015, Peter Wemm pe...@wemm.org wrote: On Wednesday, February 04, 2015 04:29:41 PM Konstantin Belousov wrote: On Tue, Feb 03, 2015 at 01:33:15PM -0800, Peter Wemm wrote: Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been introduced to 11.x/head/-current.With HZ=1000 (the default for bare metal, not for a vm); the clocks stop just after 24 days of uptime. This means things like cron, sleep, timeouts etc stop working. TCP/IP won't time out or retransmit, etc etc. It can get ugly. The problem is NOT in 10.x/-stable. We hit this in the freebsd.org cluster, the builds that we used are: FreeBSD 11.0-CURRENT #0 r275684: Wed Dec 10 20:38:43 UTC 2014 - fine FreeBSD 11.0-CURRENT #0 r276779: Wed Jan 7 18:47:09 UTC 2015 - broken If you are running -current in a situation where it'll accumulate uptime, you may want to take precautions. A reboot prior to 24 days uptime (as horrible a workaround as that is) will avoid it. Yes, this is being worked on. So the issue is reproducable in 3 minutes after boot with the following change in kern_clock.c: volatile int ticks = INT_MAX - (/*hz*/1000 * 3 * 60); It is fixed (in the proper meaning of the word, not like worked around, covered by paper) by the patch at the end of the mail. We already have a story trying to enable much less ambitious option -fno-strict-overflow, see r259045 and the revert in r259422. I do not see other way than try one more time. Too many places in kernel depend on the correctly wrapping 2-complement arithmetic, among others are callweel and scheduler. Rather than depending on a compiler option, wouldn't it be better/more robust to change ticks to unsigned, which has specified wrapping behavior? Yes, but non-trivial. It's also not limited to ticks. Since the compiler knows when it would apply these optimizations, it would be nice if it could warn instead (GCC apparently has a warning, but clang does not). Having people do a manual audit of every signed integer expression in the tree will take a long time. -- 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: Filepaths in VM map for tmpfs files
On Thursday, February 05, 2015 10:37:55 AM Konstantin Belousov wrote: On Wed, Feb 04, 2015 at 10:15:04AM -0500, John Baldwin wrote: On Tuesday, February 03, 2015 10:33:36 PM Konstantin Belousov wrote: On Mon, Feb 02, 2015 at 09:50:22PM -0600, Eric Badger wrote: On 02/02/2015 03:30 AM, Konstantin Belousov wrote: On Sun, Feb 01, 2015 at 08:38:29PM -0600, Eric Badger wrote: On 01/31/2015 09:36 AM, Konstantin Belousov wrote: First, shouldn't the kve_type changed to KVME_TYPE_VNODE as well ? My thinking is no, because KVME_TYPE_SWAP is in fact the correct type; I'd opine that it is better to be transparent than make it look like there is an OBJT_VNODE object there. It may be that some programs would be confused by VNODE info returned on a SWAP type mapping, though I know that dtrace handles it OK. kve_vn_* and kve_path fields are defined only for KVME_TYPE_VNODE kve_type. So this is in fact a bug in whatever used the API to access kve_path for KVE_TYPE_SWAP. Hmm, is that documented anywhere? I think it's fair to assume that kve_vn* applies only to the VNODE type, but I know there are several in-tree users that reference kve_path regardless of type (ostensibly relying on the default of an empty string). Maybe one could determine the validity of the kve_vn* fields by inspecting the kve_vn_type (not sure of all the consequences of that)? Or change it to KVME_TYPE_VNODE and deal with the below problem... There is no useful documentation for the kern.proc. sysctls. My word (and statements from other involved developers) could be considered as close to the truth as it can be. Somebody taking the efforts to document the stuff would make very valuable contribution. I think that kve_path should be valid for all types (e.g. shm_open() is not a vnode but has a pathname, and that should be fixed to display if possible). In the equivalent for files (kinfo_file), the pathname is type-independent and always valid. Well, this means that it should be valid for vnodes and shm. My point is that kvme_vn_path should be used only after the check for type. We can and do set it to nul string, but using the path unconditionally is a bug in the user code. The problem is that shm's can have different types (DEFAULT vs SWAP vs PHYS). :) For kinfo_file, tools like fstat always print kf_path regardless of type. I do think it would be more consistent if the path in a kvme worked the same way. Then you don't have to update all the tools each time a type starts populating the path. That said, I think tmpfs nodes should be exposed as files. It is an implementation detail of tmpfs that they are swap-backed, but from a user's perspective these are files, and if you want to expose other vnode-specific fields than just the path, KVME_TYPE_VNODE would be more correct. I agree, but doing it is not easy, since there might be no vnode to get the required information from. We do know that this swap object is for tmpfs node, but currently we only store pointer to object in the node, not pointer to node from the object. When the vnode exists, pointer to vnode is stored in the object. To fix the issue, we should store pointer to node. Code was not done this way, because VM code which handles special-case for OBJT_TMPFS, would need to know tmpfs internals. Right now, code knows about vnodes anyway, so object-vnode does not bring tmpfs internals into vm. I'm more arguing in support of your original proposal. Doing a best effort if the vnode exists would certainly be an improvement over what we have now. -- 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: PSA: If you run -current, beware!
On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote: On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote: On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote: ... It is fixed (in the proper meaning of the word, not like worked around, covered by paper) by the patch at the end of the mail. We already have a story trying to enable much less ambitious option -fno-strict-overflow, see r259045 and the revert in r259422. I do not see other way than try one more time. Too many places in kernel depend on the correctly wrapping 2-complement arithmetic, among others are callweel and scheduler. Rather than depending on a compiler option, wouldn't it be better/more robust to change ticks to unsigned, which has specified wrapping behavior? Yes, but non-trivial. It's also not limited to ticks. Since the compiler knows when it would apply these optimizations, it would be nice if it could warn instead (GCC apparently has a warning, but clang does not). Having people do a manual audit of every signed integer expression in the tree will take a long time. I think I misunderstood the problem as being limited to ticks, which is probably only one symptom of a fundamental change in behaviour of the compiler. Still, it might be worthwhile start looking at ints that ought to be implemented as u_int I actually agree, I just think we are stuck with -fwrapv in the interval, but it's probably not a short interval. I think converting ticks to unsigned would be a good first start. -- 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: Filepaths in VM map for tmpfs files
On Tuesday, February 03, 2015 10:33:36 PM Konstantin Belousov wrote: On Mon, Feb 02, 2015 at 09:50:22PM -0600, Eric Badger wrote: On 02/02/2015 03:30 AM, Konstantin Belousov wrote: On Sun, Feb 01, 2015 at 08:38:29PM -0600, Eric Badger wrote: On 01/31/2015 09:36 AM, Konstantin Belousov wrote: First, shouldn't the kve_type changed to KVME_TYPE_VNODE as well ? My thinking is no, because KVME_TYPE_SWAP is in fact the correct type; I'd opine that it is better to be transparent than make it look like there is an OBJT_VNODE object there. It may be that some programs would be confused by VNODE info returned on a SWAP type mapping, though I know that dtrace handles it OK. kve_vn_* and kve_path fields are defined only for KVME_TYPE_VNODE kve_type. So this is in fact a bug in whatever used the API to access kve_path for KVE_TYPE_SWAP. Hmm, is that documented anywhere? I think it's fair to assume that kve_vn* applies only to the VNODE type, but I know there are several in-tree users that reference kve_path regardless of type (ostensibly relying on the default of an empty string). Maybe one could determine the validity of the kve_vn* fields by inspecting the kve_vn_type (not sure of all the consequences of that)? Or change it to KVME_TYPE_VNODE and deal with the below problem... There is no useful documentation for the kern.proc. sysctls. My word (and statements from other involved developers) could be considered as close to the truth as it can be. Somebody taking the efforts to document the stuff would make very valuable contribution. I think that kve_path should be valid for all types (e.g. shm_open() is not a vnode but has a pathname, and that should be fixed to display if possible). In the equivalent for files (kinfo_file), the pathname is type-independent and always valid. That said, I think tmpfs nodes should be exposed as files. It is an implementation detail of tmpfs that they are swap-backed, but from a user's perspective these are files, and if you want to expose other vnode-specific fields than just the path, KVME_TYPE_VNODE would be more correct. -- 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: How to know the address ranges of kernel stacks, for user processes and kernel threads?
On 1/28/15 7:54 PM, Yue Chen wrote: How can we know the kernel stack ranges for user process and kernel threads under FreeBSD x86_64? It seems that each kernel stack has two pages (IA-32) to use. Does x86_64 still have two pages or more? And how can we find the address of these two pages from a kernel module? In 'struct thread' there is td_kstack_pages and td_kstack. If you grep for those and see where they are initialized that will lead you to find in the source what the defaults are for amd64 (and you can also use those in your kernel module). Note that some kthreads have a different sized stack, so using the members in struct thread is probably what you want to do regardless. -- 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: Questions on adding backlight support for the i915 driver
On 1/28/15 1:38 AM, Elizabeth Myers wrote: Hello, I want to add backlight support to the i915 driver in FreeBSD. It seems that two magic addresses are read and wrote from to change the backlight itself. It supports rather fine-level granularity all the way down to zero. Right now I use a hacked-up userland program that reads from/writes to these addresses, which is far from an ideal solution. I am interested in this because the acpi_video(4) driver does not support my backlight on my Dell Inspiron 15 3521 (not terribly suprising, on Linux I needed a special Dell-specific driver, and I'm not sure even that really used ACPI, I never really checked). My questions are really twofold: 1) How can this be exposed appropriately? I would prefer this be exposed generally so upower could grok it. As far as I can tell upower uses hw.acpi.video.lcd0 to control backlight. I am not sure that upower is doing the right thing here, though. 2) Where would the code go for this? The dri2 driver seems the most logical place, but maybe it belongs in X and exposed via a program? Or something else entirely that I'm not thinking of? I have experience developing PCI drivers and doing other PCI related doodads, and some kernel development experience, as well as general C experience, but I'm not by any means an expert on the matter. Humm. If the code is going to live in the drm driver, then I would start with hanging a sysctl off of the drm device itself. (Each new-bus device_t has a sysctl ctx you can get to hang new nodes off of the device's node.) -- 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: Questions on adding backlight support for the i915 driver
On Friday, January 30, 2015 04:45:45 PM Elizabeth Myers wrote: On 01/30/15 09:17, John Baldwin wrote: Humm. If the code is going to live in the drm driver, then I would start with hanging a sysctl off of the drm device itself. (Each new-bus device_t has a sysctl ctx you can get to hang new nodes off of the device's node.) I'm wondering if that's the correct place for it to live. So far it's the only real place it *can* live that makes logical sense imho, unless anyone has better ideas. This is awesome. As for upower, it should probably be patched to know about other types of brightness sysctls if/when this is implemented. For now I think hanging it off of the device_t is fine. It can be moved later if there is an urgent need. However, I suspect that tools like upower will need updating regardless of where it ends up living. -- 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] nmbclusters should be always positive
On Monday, January 19, 2015 6:12:25 pm Davide Italiano wrote:
Currently, the following is allowed in FreeBSD:
root@rabbit1:/home/davide/udp-clt # sysctl kern.ipc.nmbclusters=2147483647
kern.ipc.nmbclusters: 2036598 - -2147483648
The following is an attempt of fixing.
I also think nmbcluster should actually be u_int and not it, but this
is a discussion for another day, maybe.
diff --git a/sys/kern/kern_mbuf.c b/sys/kern/kern_mbuf.c
index 7ab6509..15b38a9 100644
--- a/sys/kern/kern_mbuf.c
+++ b/sys/kern/kern_mbuf.c
@@ -162,7 +162,7 @@ sysctl_nmbclusters(SYSCTL_HANDLER_ARGS)
newnmbclusters = nmbclusters;
error = sysctl_handle_int(oidp, newnmbclusters, 0, req);
if (error == 0 req-newptr newnmbclusters != nmbclusters) {
- if (newnmbclusters nmbclusters
+ if (newnmbclusters 0 newnmbclusters nmbclusters
nmbufs = nmbclusters + nmbjumbop + nmbjumbo9 +
nmbjumbo16) {
nmbclusters = newnmbclusters;
nmbclusters = uma_zone_set_max(zone_clust,
nmbclusters);
1) If you fix this one you need to fix the other handlers in this file (all
the jumbo ones, etc.)
2) Shouldn't the 'newnmbclusters nmbclusters' check catch this already?
That should fail right? Might be worth figuring out why it isn't.
--
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] Start SMP subsystem earlier
On 1/5/15 8:18 AM, Hans Petter Selasky wrote: Hi, There is a limitiation on the number of interrupt vectors available when only a single processor is running. To have more interrupts available we need to start SMP earlier when building a monotolith kernel and not loading drivers as modules. The driver in question is a network driver and because it cannot be started after SI_SUB_ROOT_CONF due to PXE support I see no other option than to move SI_SUB_SMP earlier. Suggested patch: Index: sys/kernel.h === --- sys/kernel.h(revision 276691) +++ sys/kernel.h(working copy) @@ -152,6 +152,7 @@ SI_SUB_KPROF= 0x900,/* kernel profiling*/ SI_SUB_KICK_SCHEDULER= 0xa00,/* start the timeout events*/ SI_SUB_INT_CONFIG_HOOKS= 0xa80,/* Interrupts enabled config */ +SI_SUB_SMP= 0xa85,/* start the APs*/ SI_SUB_ROOT_CONF= 0xb00,/* Find root devices */ SI_SUB_DUMP_CONF= 0xb20,/* Find dump devices */ SI_SUB_RAID= 0xb38,/* Configure GEOM classes */ @@ -165,7 +166,6 @@ SI_SUB_KTHREAD_BUF= 0xea0,/* buffer daemon*/ SI_SUB_KTHREAD_UPDATE= 0xec0,/* update daemon*/ SI_SUB_KTHREAD_IDLE= 0xee0,/* idle procs*/ -SI_SUB_SMP= 0xf00,/* start the APs*/ SI_SUB_RACCTD= 0xf10,/* start racctd*/ SI_SUB_LAST= 0xfff/* final initialization */ }; This fixes a problem for Mellanox drivers in the OFED layer. Possibly we need to move the SMP even earlier to not miss the generic FreeBSD PCI device enumeration or maybe this is not possible. Does anyone know how early we can start SMP? We need a lot more work before this is ready. This is one of the goals of the multipass new-bus stuff. In particular, we have to enumerate enough devices to bring event timer hardware up so that timer interrupts work so that tsleep() will actually sleep. In addition, we also need idle threads created and working before APs are started as otherwise they will have no thread to run initially. This is certainly a desired feature, but it is not as simple as moving the sysinit up I'm afraid. -- 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: Haswell CPU Feature
On 1/6/15 12:44 AM, Jia-Shiun Li wrote: On Tue, Jan 6, 2015 at 1:23 PM, Neel Natu neeln...@gmail.com wrote: Hi Sean, On Mon, Jan 5, 2015 at 6:34 PM, Sean Bruno sbr...@ignoranthack.me wrote: I'm thinking something like this: Index: sys/x86/x86/identcpu.c === - --- sys/x86/x86/identcpu.c(revision 276729) +++ sys/x86/x86/identcpu.c (working copy) @@ -781,7 +781,7 @@ \011TM2 /* Thermal Monitor 2 */ \012SSSE3 /* SSSE3 */ \013CNXT-ID /* L1 context ID available */ - - \014b11 + \014SDBG /* IA32_DEBUG_INTERFACE debug*/ \015FMA /* Fused Multiply Add */ \016CX16 /* CMPXCHG16B Instruction */ \017xTPR /* Send Task Priority Messages*/ Looks good. Maybe also this for completeness? # svnlite diff Index: sys/x86/include/specialreg.h === --- sys/x86/include/specialreg.h(revision 276737) +++ sys/x86/include/specialreg.h(working copy) @@ -154,6 +154,7 @@ #defineCPUID2_TM2 0x0100 #defineCPUID2_SSSE30x0200 #defineCPUID2_CNXTID 0x0400 +#defineCPUID2_SDBG 0x0800 #defineCPUID2_FMA 0x1000 #defineCPUID2_CX16 0x2000 #defineCPUID2_XTPR 0x4000 Yes, please include both. SDBG matches the label in the Intel SDM, so that's the preferred name. -- 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: any primer on running bhyve guests sharing disk with host ?
On 1/3/15 1:43 PM, Craig Rodrigues wrote:
On Sat, Jan 3, 2015 at 8:15 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
Hi,
in order to do some kernel testing, I would like to run bhyve guests
using (through NFS, probably) the host's file system.
diskless(8) is probably one way to go, i was wondering if
someone has instructions for that.
Specifically:
- how to bhyveload a kernel (rather than the full disk image);
as an alternative, given a kernel, something to build an image
that can be passed to bhyveload
- how to pass the necessary config (rootpath) to the client
without having to rely on a specialized dhcp server
I used to be familiar with diskless configs, so i can probably sort
out the server side myself.
Neel already covered -h with bhyveload which you can also use with -H
to vmrun.sh, though the other way I do this is to NFS export my work
tree from the host to the guest so I can run kgdb on the host but do the
build / install in the guest itself.
I don't think there is a way to do exactly what you want.
I would recommend doing the following:
(1) Enable bvmdebug in your kernel config:
https://wiki.freebsd.org/BHyVe/gdb
This allows you to do kgdb remote debugging into a bhyve VM.
At this point it is probably simpler to use the serial port instead. I
have hacked up vmrun.sh locally to always create a /dev/nmdmvmname2B
device hooked up to com2 and to add 0x80 to the flags for uart1 in
device.hints in all my VMs. You can then use kgdb from the host and
'target remote /dev/nmdmvmname2A'.
--- /usr/share/examples/bhyve/vmrun.sh 2014-11-20 18:38:34.0 -0500
+++ /home/john/bhyve/vmrun.sh 2015-01-06 09:54:47.0 -0500
@@ -230,6 +230,9 @@
nextslot=$(($nextslot + 1))
i=$(($i + 1))
done
+ if kldstat -qm nmdm; then
+ devargs=$devargs -l com2,/dev/nmdm${vmname}2B
+ fi
${FBSDRUN} -c ${cpus} -m ${memsize} ${apic_opt} -A -H -P\
-g ${gdbport} \
--
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] Start SMP subsystem earlier
On 1/6/15 10:55 AM, Ian Lepore wrote: On Tue, 2015-01-06 at 09:37 -0500, John Baldwin wrote: On 1/5/15 8:18 AM, Hans Petter Selasky wrote: Hi, There is a limitiation on the number of interrupt vectors available when only a single processor is running. To have more interrupts available we need to start SMP earlier when building a monotolith kernel and not loading drivers as modules. The driver in question is a network driver and because it cannot be started after SI_SUB_ROOT_CONF due to PXE support I see no other option than to move SI_SUB_SMP earlier. Suggested patch: [...] This fixes a problem for Mellanox drivers in the OFED layer. Possibly we need to move the SMP even earlier to not miss the generic FreeBSD PCI device enumeration or maybe this is not possible. Does anyone know how early we can start SMP? We need a lot more work before this is ready. This is one of the goals of the multipass new-bus stuff. In particular, we have to enumerate enough devices to bring event timer hardware up so that timer interrupts work so that tsleep() will actually sleep. In addition, we also need idle threads created and working before APs are started as otherwise they will have no thread to run initially. This is certainly a desired feature, but it is not as simple as moving the sysinit up I'm afraid. Just an FYI, the ARM world is now using the multipass newbus stuff. It works well, with some quirks... The predefined pass names don't always makes sense for the arm world. There aren't enough predefined pass names and even though the number space for them is 4 billion wide all the predefined names are in the range 100 and separated by only 10 so it's tricky to wedge things between the existing names. The strangest bit is when you have interdependent drivers at different early pass numbers. Sometimes it's necessary to do almost nothing in the attach() routine and do all the real attach-time type stuff in a bus_new_pass() routine after the pass number becomes high enough that your co-dependent driver peers are available. Yes, I almost want another downcall through the tree that is something like 'bus_pass_completed', though the original design was to override bus_new_pass as you have done. And yes, in many cases the logic needs to move out of attach. The pci bus will end up only doing enumeration but no resource assignment in its attach routine once things are fleshed out more for example. However, for now I've found that even on x86 I've had to add a new pass level for ACPI and some other things like acpi_sysresource. :( It almost wants more of a provides-requires setup than hardcoded pass levels, but that's more complicated to implement. -- 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: simple task to speed up booting
On Monday, December 22, 2014 12:05:43 am Ian Lepore wrote:
On Sun, 2014-12-14 at 10:32 +, Poul-Henning Kamp wrote:
The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
large part of our boot time on systems with slow-ish serial consoles.
I think right now it takes a step for each 512 byte read, reducing that
to once every 64kB or even 1MB would be an improvement with the kind of
kernel sizes we have today.
I investigated this a bit today. I instrumented the loader on arm to
count how many times twiddle() is called while loading a 5.5MB kernel.
When loading over NFS it was called 5580 times. When loading from an
sdcard it was called 284 times.
Poking around in the code, it looks like NFS calls twiddle() once per 1K
block read, CD9660 once per 2K block, and UFS and ext2fs once per
filesystem blocksize block. All of them have some other scattered
twiddle calls while navigating metadata that probably don't add up to
much compared to the bulk reading.
My amd64 kernel is twice as big even with lots of the generic devices
removed; that's a lot of IO. But one twiddle per filesystem block
shouldn't be so bad... let's call it 600 twiddles, each one writes 2
bytes to serial, so a total of ~1200mS at 9600bps. The same kernel
loaded over nfs would cost over 20 seconds in serial output.
So all in all it seems like different kinds of IO need different
throttling, something like the attached (which also still has some stats
output in it). I can't decide if it's worth committing... it'll have a
lot of value to someone with slow serial and netbooting, is that common?
9600 consoles are still fairly common, so if this makes a noticable difference
for NFS, by all means test it and get it in.
--
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: witness and modules.
On Wednesday, December 03, 2014 09:53:20 PM Julian Elischer wrote: On 12/3/14, 7:26 PM, Andriy Gapon wrote: On 03/12/2014 04:33, Julian Elischer wrote: On 12/3/14, 12:24 AM, Warner Losh wrote: On Dec 1, 2014, at 10:08 PM, Julian Elischer jul...@freebsd.org wrote: On 12/1/14, 11:39 PM, John Baldwin wrote: On Friday, November 28, 2014 11:08:35 PM Julian Elischer wrote: Do we need to compile all modules with witness definitions when linking with a kernel compiled with witness? This was true at one stage but I remember some work was done to make them compatible. You should not need this. modules always call functions in the kernel for lock operations and this functions are what invoke WITNESS. that's what I thought but empirical evidence disagrees. I'll try some more cases. I swap back and forth all the time between the two. Kernel modules don’t change when you compile them with WITNESS or without. not entirely.. hwpmc.ko: U witness_restore hwpmc.ko: U witness_save zfs.ko: U witness_restore zfs.ko: U witness_save Seems like the problem affects modules that use DROP_GIANT / PICKUP_GIANT. that's a good observation. I'll take a look a that later. Yes, that isn't really intended to be used publically. The pmc one is stale as system calls haven't run with Giant in several releases. All the ones for g_topology_lock() also seem to be broken-by-designed. There is no good reason I can think of for g_topology_lock() to assert that Giant isn't held. I suspect phk@ just wanted to force geom to be locked without Giant, but I'm not sure that is the best way to achieve that? Poul, is that correct? If you fix that you can remove almost all of the DROP_GIANT/PICKUP_GIANT in the tree. They should really only be in the _sleep() and cv_wait_*() functions where they are used to give Giant its special property of being dropped while asleep. -- 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: witness and modules.
On Friday, November 28, 2014 11:08:35 PM Julian Elischer wrote: Do we need to compile all modules with witness definitions when linking with a kernel compiled with witness? This was true at one stage but I remember some work was done to make them compatible. You should not need this. modules always call functions in the kernel for lock operations and this functions are what invoke WITNESS. -- 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]: further shrinking of boot2
On Friday, November 21, 2014 01:56:32 PM Roman Divacky wrote: Hi all! In an effort to help import clang3.5 I looked at squeezing a few more bytes from boot2. http://rys.vlakno.cz/~rdivacky/boot2.diet.patch Please test and review the patch. It survived my qemu boot attempt so it's not completely broken. But I would like to have some more testing and review comments before I move forward with this. Fwiw, it shrinks boot2 by 16 bytes when compiled with clang34 and by 28 bytes when compiled with clang35. I would prefer 'int k' over 'int i2/j2'. Also, do you really have to move the variable definitions to get the size change? I'd prefer to leave the variable declarations where they are if possible (and just add 'int k' or 'size_t k' in the existing variable blocks). -- 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]: further shrinking of boot2
On Friday, November 21, 2014 08:39:17 PM Roman Divacky wrote: Sure thing. Reload the patch from the same url. http://rys.vlakno.cz/~rdivacky/boot2.diet.patch Thanks. I haven't run tested it, but I'm ok with it otherwise. -- 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: r273918 buildworld broke at semaphore
On Tuesday, November 11, 2014 4:22:05 pm Henry Hu wrote: On Tue, Nov 11, 2014 at 1:33 PM, John Baldwin j...@freebsd.org wrote: On Friday, October 31, 2014 4:08:06 pm Beeblebrox wrote: First breakage in a long time. Error is: In file included from cancelpoints_sem_new.c:47: /usr/src/lib/libc/../../include/semaphore.h:41:16: error: field has incomplete type 'struct _usem2' struct _usem2 _kern; ^ /usr/src/lib/libc/../../include/semaphore.h:41:9: note: forward declaration of 'struct _usem2' struct _usem2 _kern; ^ cancelpoints_sem_new.c:66:33: error: use of undeclared identifier 'USEM_MAX_COUNT' _Static_assert(SEM_VALUE_MAX = USEM_MAX_COUNT, SEM_VALUE_MAX too large); ^ cancelpoints_sem_new.c:335:15: warning: implicit declaration of function 'USEM_COUNT' is invalid in C99 [-Wimplicit-function-declaration] *sval = (int)USEM_COUNT(sem-_kern._count); ^ cancelpoints_sem_new.c:342:23: error: use of undeclared identifier 'UMTX_OP_SEM2_WAKE' return _umtx_op(sem, UMTX_OP_SEM2_WAKE, 0, NULL, NULL); ^ cancelpoints_sem_new.c:361:23: error: use of undeclared identifier 'UMTX_OP_SEM2_WAIT' return _umtx_op(sem, UMTX_OP_SEM2_WAIT, 0, ^ cancelpoints_sem_new.c:445:14: error: use of undeclared identifier 'USEM_HAS_WAITERS' if (count USEM_HAS_WAITERS) ^ 1 warning and 5 errors generated. Seems like your tree is not fully up to date? The changes to sem_new.c were committed in the same commit as the changes to sys/umtx.h. Maybe it's another problem. buildworld may be picking up umtx.h from /usr/include which is the old version. 'make buildworld' should always populate an include tree under /usr/obj that is used instead of /usr/include. If this wasn't correct, then every change to add new constants, etc. to any header installed to /usr/include would fail to build. -- 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: r273918 buildworld broke at semaphore
On Friday, October 31, 2014 4:08:06 pm Beeblebrox wrote: First breakage in a long time. Error is: In file included from cancelpoints_sem_new.c:47: /usr/src/lib/libc/../../include/semaphore.h:41:16: error: field has incomplete type 'struct _usem2' struct _usem2 _kern; ^ /usr/src/lib/libc/../../include/semaphore.h:41:9: note: forward declaration of 'struct _usem2' struct _usem2 _kern; ^ cancelpoints_sem_new.c:66:33: error: use of undeclared identifier 'USEM_MAX_COUNT' _Static_assert(SEM_VALUE_MAX = USEM_MAX_COUNT, SEM_VALUE_MAX too large); ^ cancelpoints_sem_new.c:335:15: warning: implicit declaration of function 'USEM_COUNT' is invalid in C99 [-Wimplicit-function-declaration] *sval = (int)USEM_COUNT(sem-_kern._count); ^ cancelpoints_sem_new.c:342:23: error: use of undeclared identifier 'UMTX_OP_SEM2_WAKE' return _umtx_op(sem, UMTX_OP_SEM2_WAKE, 0, NULL, NULL); ^ cancelpoints_sem_new.c:361:23: error: use of undeclared identifier 'UMTX_OP_SEM2_WAIT' return _umtx_op(sem, UMTX_OP_SEM2_WAIT, 0, ^ cancelpoints_sem_new.c:445:14: error: use of undeclared identifier 'USEM_HAS_WAITERS' if (count USEM_HAS_WAITERS) ^ 1 warning and 5 errors generated. Seems like your tree is not fully up to date? The changes to sem_new.c were committed in the same commit as the changes to sys/umtx.h. -- 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: r273165. ZFS ARC: possible memory leak to Inact
On Wednesday, November 05, 2014 4:52:50 am Andriy Gapon wrote: On 04/11/2014 14:55, Steven Hartland wrote: This is likely spikes in uma zones used by ARC. The VM doesn't ever clean uma zones unless it hits a low memory condition, which explains why your little script helps. Check the output of vmstat -z to confirm. Steve, this is nonsense :-) You know perfectly well that UMA memory is Wired not Inactive. Grab the code at www.freebsd.org/~jhb/vm_objects/. Build and load the kld and then use the vm_objects binary to generate a list of the active VM objects in the system along with counts of how many active / inactive pages each object contains. For your case with lots of inactive memory, you probably want something like 'vm_objects | sort -n -k 2'. -- 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: Changing timezone without reboot/restarting each service?
On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote: After changing timezones in Russia (with replacing /etc/localtime with new file), I found that cron works in old timezone till restart. And all other services do the same, but cron is most obvious here :) Looks like libc reads timezone only once and it could not be chamged for process without restart (which leads to, effectivly, restart of whole server). Is it known problem? I think, it should be fixed somehow. I understand, that re-check timezone file on each time-related call could be expensive, though :( In practice, timezone changes are very rare, so rechecking the file is quite expensive to do. I think having to restart processes is fine for this. -- 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: Changing timezone without reboot/restarting each service?
On Tuesday, November 11, 2014 3:16:19 pm Charles Swiger wrote: On Nov 11, 2014, at 10:57 AM, John Baldwin j...@freebsd.org wrote: On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote: After changing timezones in Russia (with replacing /etc/localtime with new file), I found that cron works in old timezone till restart. And all other services do the same, but cron is most obvious here :) Looks like libc reads timezone only once and it could not be chamged for process without restart (which leads to, effectivly, restart of whole server). Is it known problem? I think, it should be fixed somehow. I understand, that re-check timezone file on each time-related call could be expensive, though :( In practice, timezone changes are very rare, so rechecking the file is quite expensive to do. I think having to restart processes is fine for this. In theory, timezone changes should be very rare. We've actually had about ten TZ updates in 2014; the most recent was FET - MSK for Belarus plus minor tweaks to IDT vs ICT. If you're working within the scope of a single country, I suspect that one could ignore the bulk of TZ updates and be fine most of the time. If you're world-wide, however, TZ update frequency becomes more noticeable The vast majority of updates are historical changes however. Having used a timezone-aware version of cron for an international company so we can schedule jobs across multiple timezones for a single machine (times N machines scattered around the globe) for the last 4 or 5 years, FET - MSK was the first time we had a timezone change in that span that actually impacted our operations (and we've just restarted cron / rebooted to cope). -- 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: junior kernel tasks
On Tuesday, October 28, 2014 7:07:31 pm Eitan Adler wrote: On 28 October 2014 15:14, Baptiste Daroussin b...@freebsd.org wrote: On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote: Quoting John Baldwin j...@freebsd.org: On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: Hello, In short, nice kernel tasks people with C language skills can do in few evenings. https://wiki.freebsd.org/JuniorJobs It is assumed you know how to obtain sources and build the kernel. What you can get in return: - your own code in FreeBSD tree - eternal glory [1] - fun [2] If you are not interested, but know someone who does, please pass it down. [1] - not really, no [2] - well, I guess that's subjective, so that's not a no Even though our bugmeisters have decided that we should not have wishlist items in our bug tracker, I really wish we could store the various idea lists (we have several) in an issue tracker instead. This would allow for folks to comment on ideas, vote for them, etc. It would also make it easier for more people to submit new ideas. Speaking not strictly with the bugmeister hat, but from experience, please do not let us go down the road of (ab)using a bug tracking solution as task and idea management system. I think that using the tasks feature of phabricator (our reviews instance) would provide better workflow support for those things, starting out from sketching out rough ideas, discussing them, breaking them up in seperate tasks (linked to and dependent on each other) and collaborating on them (take a look at https://developer.blender.org/T42339 for a brief example). Having said this, let's keep the bug tracker a bug tracker. Cheers Marcus I disabled the tasks on phabricator to avoid having it a duplicate of bugzilla, but if we have a use for it I can activate it! Actually I do like the idea of the bug tracker aka bugzilla being only for bugs and uxe phabricator for tracking the tasks having disparate trackers for wishlist and bugs is quite harmful and splits the conversations. It makes people learn multiple systems and search multiple places - especially if the feature ends up being submitted as a patch to the bug tracker. I'd rather keep wishlist items in the bug tracker than split them into two. (also, fwiw, I'd rather keep the tasks number space clean should we ever decide to import from bugzilla - phabricator) I'm not tied to a specific issue tracker to use for this and am happy to other folks debate which implementation is best, but what I would prefer is a system to let us manage ideas to implement like the ideas page for GSoC and this wiki page. The desired output is a list of vetted tasks. A task might start out as a wishlist entry, but someone has to step up and say yes, this is a good idea and I will review it / shepherd it, etc. for it to become a vetted task. Being able to store conversation about each task and tag it with other meta data (e.g. tagging the person who owns the task and will do the review / sheperding as well as being able to categorize them, etc.) However, I do think one important thing is that when a new idea is submitted, it has a built-in sunset. If no one grabs it after time X it becomes closed instead of remaining an open wishlist forever. Similarly if the owner of a task drops ownership, the timer would start while waiting for a new owner. However, this does feel very much like an issue tracker. -- 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: getting rid of oldnfs
On Saturday, October 25, 2014 6:24:16 pm Rick Macklem wrote: Kostik wrote: On Fri, Oct 24, 2014 at 04:43:28PM +0100, Robert Watson wrote: On Thu, 23 Oct 2014, Rick Macklem wrote: Someone just pinged me on this and I figured I should bring it up. 1 - Is anyone out there still using oldnfs due to unresolved problems with the new one? (I am not aware of any outstanding issues in the new nfs that don't exist in the oldnfs.) 2 - Does anyone see a problem with getting rid of oldnfs for FreebSD-11? 3 - If I get rid of it in -head, I can do it either in mid-December or mid-April. (I can't do commits during the winter.) Does anyone have a rough idea when the 11.0 release cycle will start, so I can choose which of the above would be preferable? (I figured I'd wait until after the last 10.n release that happens before 11.0, since it will be easier to MFC before the removal of oldnfs.) Thanks in advance for any comments, rick ps: John, I've cc'd you since I thought you are the guy most likely to need to do commits/MFCs to oldnfs. I think removing it is fine, but as early as possible (as John says) to give our -CURRENT users time to stop working around bugs and start reporting them :-). I remember the main reason for keeping oldnfs, both server and client, around in HEAD was to facilitate MFC of fixes to the branches which still use oldnfs, i.e. stable/8. If this reason is still valid, oldnfs have to stay in HEAD till stable/8 is supported or interested for developers. I usually do not like direct commits into the stable branches. Otherwise, I see no reason to keep oldnfs around. Well, the only commits I've done to old were bugfixes that applied to both old and new. John has been the main fix the old NFS guy lately. So, John, do you anticipate more patches to the old NFS that need to be MFC'd down? I do not, no. -- 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: Mounting ZFS with error 5 failed, since r271963 callout convert
On Monday, October 27, 2014 6:46:17 pm Michael Schmiedgen wrote: On 10/27/2014 22:29, Ryan Stone wrote: On Mon, Oct 27, 2014 at 4:21 PM, Michael Schmiedgen schmied...@gmx.net wrote: Hi List, my ZFS does not mount. I bifurcated to r271963 that does not work anymore. The commit seems not directly related to ZFS, but is rather a conversion from timeout(9) to callout(9). After booting the kernel it drops to the mount prompt, stating that ZFS cannot be mounted because of 'error 5'. Any hints? Can I provide some more information? Thanks, Michael The changes to the 3 files there look to be independent, so can you narrow this down further by applying the patch to only a single file? Of those three only ACPI looks like it could affect ZFS or disks, so this will be the patch to try first: https://svnweb.freebsd.org/base/head/sys/dev/acpica/acpi.c?view=patchr1=271889r2=271963pathrev=271963 If you can get a verbose boot log from the machine that would be helpful, but you'd need a serial console to capture that. I applied first acpi.c, then atkbd.c and at last kern_cons.c that triggered the error. https://svnweb.freebsd.org/base/head/sys/kern/kern_cons.c?r1=271963r2=271962pathrev=271963 In previous months I had already the same problem with ZFS if nvidia driver was loaded via /boot/loader.conf. It triggered the same error. So I loaded the driver on demand with kldload after login and everything (X + stuff) worked fine. Very strange... Does anyone have a clue what is going on here? So not loading the nvidia driver during boot fixed it? That seems odd indeed. Did you recompile the driver after updating? -- 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: junior kernel tasks
On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: Hello, In short, nice kernel tasks people with C language skills can do in few evenings. https://wiki.freebsd.org/JuniorJobs It is assumed you know how to obtain sources and build the kernel. What you can get in return: - your own code in FreeBSD tree - eternal glory [1] - fun [2] If you are not interested, but know someone who does, please pass it down. [1] - not really, no [2] - well, I guess that's subjective, so that's not a no Even though our bugmeisters have decided that we should not have wishlist items in our bug tracker, I really wish we could store the various idea lists (we have several) in an issue tracker instead. This would allow for folks to comment on ideas, vote for them, etc. It would also make it easier for more people to submit new ideas. It also provides a better place to store metadata about the issue itself (wikis are kind of poor for that). -- 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: getting rid of oldnfs
On Thursday, October 23, 2014 2:57:26 pm Rick Macklem wrote: Someone just pinged me on this and I figured I should bring it up. 1 - Is anyone out there still using oldnfs due to unresolved problems with the new one? (I am not aware of any outstanding issues in the new nfs that don't exist in the oldnfs.) 2 - Does anyone see a problem with getting rid of oldnfs for FreebSD-11? 3 - If I get rid of it in -head, I can do it either in mid-December or mid-April. (I can't do commits during the winter.) Does anyone have a rough idea when the 11.0 release cycle will start, so I can choose which of the above would be preferable? (I figured I'd wait until after the last 10.n release that happens before 11.0, since it will be easier to MFC before the removal of oldnfs.) Thanks in advance for any comments, rick ps: John, I've cc'd you since I thought you are the guy most likely to need to do commits/MFCs to oldnfs. I think it is fine to remove it from 11. I would do it sooner rather than later. -- 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 nfs
On Friday, October 17, 2014 11:11:26 PM Tobias C. Berner wrote: Hi For some days now I've had problems with my current (last test with r273178M). Sometimes when accessing a nfs-share there is a pagefault: ### Fatal trap 12: page fault while in kernel mode cpuid = 7; apic id = 07 fault virtual address = 0xfe07cfe60400 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80d4d4b6 stack pointer = 0x28:0xfe086088b380 frame pointer = 0x28:0xfe086088b3f0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 43868 (mplayer) #0 0x80926d29 in shutdown_nice (howto=1) at /usr/src/sys/kern/kern_shutdown.c:207 #1 0x80926a2d in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:444 #2 0x80926f80 in panic (fmt=0x104 Address 0x104 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:698 #3 0x8035f147 in panic_cmd_del (arg=0x0) at /usr/src/sys/ddb/db_command.c:244 #4 0x8035ed5d in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:439 #5 0x8035ead4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:488 #6 0x803615e0 in db_trap (type=value optimized out, code=0) at /usr/src/sys/ddb/db_main.c:247 #7 0x80966db1 in kdb_trap (type=12, code=0, tf=0xfe086088b2d0) at /usr/src/sys/kern/subr_kdb.c:626 #8 0x80d4f92c in trap_fatal (frame=0xfe086088b2d0, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:835 #9 0x80d4fcbc in trap_pfault (frame=0xfe086088b2d0, usermode=0) at atomic.h:161 #10 0x80d4f2de in trap (frame=0xfe086088b2d0) at /usr/src/sys/amd64/amd64/trap.c:594 #11 0x80d33822 in Xtss () at /usr/src/sys/amd64/amd64/exception.S:154 #12 0x80d4d4b6 in stack_save_td (st=value optimized out, td=value optimized out) at /usr/src/sys/amd64/amd64/stack_machdep.c:74 #13 0x809f30b2 in foffset_unlock (fp=value optimized out, val=value optimized out, flags=value optimized out) at /usr/src/sys/kern/vfs_vnops.c:700 #14 0x8082faad in ncl_bioread (vp=0xf80201dd7490, uio=0xfe086088b7d8, ioflag=value optimized out, cred=0xf8015816a600) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:511 #15 0x80e64381 in VOP_MARKATIME_APV (vop=value optimized out, a=0xfe086088b650) at vnode_if.c:856 #16 0x809f4dd5 in vn_read (fp=0xf80272490cd0, uio=0xfe086088b7d8, active_cred=0xf8015816a600, flags=128, td=0xf800) at vnode_if.h:859 #17 0x809f5502 in get_advice (fp=0xfe086088b730, uio=0x400) at /usr/src/sys/kern/vfs_vnops.c:729 #18 0x809f2b80 in vn_io_fault1 () at /usr/src/sys/kern/vfs_vnops.c:1058 #19 0x809f0d3b in vn_io_fault (fp=0xf80272490cd0, uio=0xfe086088b970, active_cred=0x400, flags=128, td=0xf800) at /usr/src/sys/kern/vfs_vnops.c:128 #20 0x80981d95 in freebsd6_pread (td=0xf802d93204a8, uap=0xf9fb094c00a8) at /usr/src/sys/kern/sys_generic.c:217 #21 0x80981ab8 in sys_cap_fcntls_get (td=value optimized out, uap=0x800) at /usr/src/sys/kern/sys_capability.c:576 #22 0x80981a43 in sys_cap_fcntls_get (td=value optimized out, uap=0x0) at sx.h:183 #23 0x80d503cb in amd64_syscall (td=0x45e400, traced=0) at subr_syscall.c:87 #24 0x80d33b0b in Xprot () at /usr/src/sys/amd64/amd64/exception.S:324 #25 0x000806a7fe6a in ?? () ## The functions in this stack trace don't make sense. It is as if you are running kgdb against the wrong 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: [PATCH] Lock scd(4): test or the driver will be removed
On Wednesday, October 08, 2014 8:23:54 pm Alfred Perlstein wrote: On 10/8/14 11:53 AM, John Baldwin wrote: 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 Note that this driver is using a deprecated API that will be removed in 11. If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. Hey John, which APIs are being used? timeout(9). However, we are eventually going to start requiring drivers to not use Giant either (and retiring timeout(9) is a step in that direction). Also, most of these drivers are for ancient hardware. scd(4) is support for a relatively rare pre-ATA CD controller. The much-more common matcd(4) driver (which is the driver used by my old SoundBlaster 16 card that provided a CD controller (not just sound, but data as well)) was removed back in 2002. -- 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: test or the driver will be removed
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 If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. -- 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): test or the driver will be removed
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 Note that this driver is using a deprecated API that will be removed in 11. If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. -- 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] nscd
-mp_query_timeout.tv_sec != 0) || (qstate-config_entry-mp_query_timeout.tv_usec != 0)) - memcpy(qstate-timeout, - qstate-config_entry-mp_query_timeout, - sizeof(struct timeval)); + qstate-timeout = qstate-config_entry-mp_query_timeout; } configuration_unlock_entry(qstate-config_entry, CELT_MULTIPART); Index: parser.c === --- parser.c(revision 272657) +++ parser.c(working copy) @@ -138,10 +138,8 @@ lifetime.tv_sec = ttl; entry = find_create_entry(config, entry_name); - memcpy(entry-positive_cache_params.max_lifetime, - lifetime, sizeof(struct timeval)); - memcpy(entry-mp_cache_params.max_lifetime, - lifetime, sizeof(struct timeval)); + entry-positive_cache_params.max_lifetime = lifetime; + entry-mp_cache_params.max_lifetime = lifetime; TRACE_OUT(set_positive_time_to_live); } @@ -161,8 +159,7 @@ entry = find_create_entry(config, entry_name); assert(entry != NULL); - memcpy(entry-negative_cache_params.max_lifetime, - lifetime, sizeof(struct timeval)); + entry-negative_cache_params.max_lifetime = lifetime; TRACE_OUT(set_negative_time_to_live); } Index: query.c === --- query.c (revision 272657) +++ query.c (working copy) @@ -451,9 +451,8 @@ if ((qstate-config_entry-common_query_timeout.tv_sec != 0) || (qstate-config_entry-common_query_timeout.tv_usec != 0)) - memcpy(qstate-timeout, - qstate-config_entry-common_query_timeout, - sizeof(struct timeval)); + qstate-timeout = + qstate-config_entry-common_query_timeout; } else write_response-error_code = -1; @@ -532,9 +531,8 @@ if ((qstate-config_entry-common_query_timeout.tv_sec != 0) || (qstate-config_entry-common_query_timeout.tv_usec != 0)) - memcpy(qstate-timeout, - qstate-config_entry-common_query_timeout, - sizeof(struct timeval)); + qstate-timeout = + qstate-config_entry-common_query_timeout; } else write_response-error_code = -1; @@ -806,9 +804,8 @@ if ((qstate-config_entry-common_query_timeout.tv_sec != 0) || (qstate-config_entry-common_query_timeout.tv_usec != 0)) - memcpy(qstate-timeout, - qstate-config_entry-common_query_timeout, - sizeof(struct timeval)); + qstate-timeout = + qstate-config_entry-common_query_timeout; } else read_response-error_code = -1; -- 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] Fix OACTIVE for an(4)
On Friday, October 03, 2014 12:13:28 PM Gleb Smirnoff wrote: On Thu, Oct 02, 2014 at 11:16:27AM -0400, John Baldwin wrote: J I haven't looked at the rest of the driver; is everything else around J OACTIVE locked correctly and consistently? J J As well as OACTIVE is for any other driver. Let me jump into this topic and discuss the if_drv_flags :) It seems to me that this in general was a wrong concept, both IFF_DRV_OACTIVE and IFF_DRV_RUNNING. The internal state of the driver can be known only to the driver itself and should be stored in the softc, covered with internal lock. There is simply no way to racelessly tell the state from the outside, without obtaining driver lock. In my ifnet plans I am considering to remove if_drv_flags. Can anyone convince me that this is a wrong idea and they should be kept? They used to be in if_flags. Robert moved them to if_drv_flags precisely so that drivers could control their synchronization instead of doing a crazy locking dance with the ifnet layer. They are still exported to userland as IFF_RUNNING and IFF_OACTIVE in if_flags, and they may still be somewhat useful for reporting that state to userland (and races in reading if_drv_flags for that reporting are harmless). That said, I think long term if we make the stack aware of multiple input queues we will certainly use something that does not have the same raciness as OACTIVE. Note, btw, you could fix OACTIVE in various drivers by simply grabbing the IF_LOCK on ifp-if_snd while setting or clearing OACTIVE to close the current OACTIVE race (you don't need it for all writes to if_drv_flags, you just want if_handoff() to read the current value of OACTIVE, so only locking writes to OACTIVE would be sufficient). -- 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] Fix OACTIVE for an(4)
On Wednesday, October 01, 2014 2:58:38 pm Adrian Chadd wrote:
Hi,
On 1 October 2014 07:14, John Baldwin j...@freebsd.org wrote:
This small patch correctly sets OACTIVE when an(4) gets backed up. Right
now
I believe it will never set the flag. It is only an optimization, it
should
not affect correctness.
Index: an/if_an.c
===
--- an/if_an.c (revision 270968)
+++ an/if_an.c (working copy)
@@ -2906,11 +2906,11 @@
CSR_WRITE_2(sc, AN_INT_EN(sc-mpi350), AN_INTRS(sc-
mpi350));
}
- if (m0 != NULL)
+ if (sc-an_rdata.an_tx_prod != idx) {
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
+ sc-an_rdata.an_tx_prod = idx;
+ }
- sc-an_rdata.an_tx_prod = idx;
-
return;
}
I haven't looked at the rest of the driver; is everything else around
OACTIVE locked correctly and consistently?
As well as OACTIVE is for any other driver.
There's no single-entry into if_start(). It can be called from
multiple paths at the same time.
Yes, I know. However, this bug is more that it will never set OACTIVE
currently (m0 is always set to NULL before it gets to this point).
This code in its stats timer is also dubious:
/* Don't do this while we're transmitting */
if (ifp-if_drv_flags IFF_DRV_OACTIVE) {
callout_reset(sc-an_stat_ch, hz, an_stats_update, sc);
return;
}
sc-an_stats.an_len = sizeof(struct an_ltv_stats);
sc-an_stats.an_type = AN_RID_32BITS_CUM;
if (an_read_record(sc, (struct an_ltv_gen *)sc-an_stats.an_len))
return;
callout_reset(sc-an_stat_ch, hz, an_stats_update, sc);
First, the callout_reset() can just be moved earlier.
Second, OACTIVE doesn't mean that anything is transmitting, it means the ring
is full (at least in terms of how all other drivers use it).
--
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] Fix OACTIVE for an(4)
On Thursday, October 02, 2014 1:24:22 pm Adrian Chadd wrote:
On 2 October 2014 08:16, John Baldwin j...@freebsd.org wrote:
On Wednesday, October 01, 2014 2:58:38 pm Adrian Chadd wrote:
Hi,
On 1 October 2014 07:14, John Baldwin j...@freebsd.org wrote:
This small patch correctly sets OACTIVE when an(4) gets backed up. Right
now
I believe it will never set the flag. It is only an optimization, it
should
not affect correctness.
Index: an/if_an.c
===
--- an/if_an.c (revision 270968)
+++ an/if_an.c (working copy)
@@ -2906,11 +2906,11 @@
CSR_WRITE_2(sc, AN_INT_EN(sc-mpi350), AN_INTRS(sc-
mpi350));
}
- if (m0 != NULL)
+ if (sc-an_rdata.an_tx_prod != idx) {
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
+ sc-an_rdata.an_tx_prod = idx;
+ }
- sc-an_rdata.an_tx_prod = idx;
-
return;
}
I haven't looked at the rest of the driver; is everything else around
OACTIVE locked correctly and consistently?
As well as OACTIVE is for any other driver.
There's no single-entry into if_start(). It can be called from
multiple paths at the same time.
Yes, I know. However, this bug is more that it will never set OACTIVE
currently (m0 is always set to NULL before it gets to this point).
This code in its stats timer is also dubious:
/* Don't do this while we're transmitting */
if (ifp-if_drv_flags IFF_DRV_OACTIVE) {
callout_reset(sc-an_stat_ch, hz, an_stats_update, sc);
return;
}
sc-an_stats.an_len = sizeof(struct an_ltv_stats);
sc-an_stats.an_type = AN_RID_32BITS_CUM;
if (an_read_record(sc, (struct an_ltv_gen *)sc-an_stats.an_len))
return;
callout_reset(sc-an_stat_ch, hz, an_stats_update, sc);
First, the callout_reset() can just be moved earlier.
Second, OACTIVE doesn't mean that anything is transmitting, it means the
ring
is full (at least in terms of how all other drivers use it).
yes, but if you don't absolutely handle it in a race-free situation,
you end up never having if_start() called.
IFQ_HANDOFF() - IFQ_HANDOFF_ADJ() - enqueue, then if it worked AND
OACTIVE==0, call if_start()
Then you hit the stupid situation where OACTIVE was set just long
enough for the queue to fill up without calling if_start(), then once
it's filled if_start() won't ever be called from the transmitter
context. It has to be called from the completion context or the
receive context. Or, well, anywhere.
All of that stuff needs to die.
Yes, but this is true of all if_start-using drivers currently, and it
cannot be fixed in the drivers themselves. It is orthogonal to
whether or not an(4) correctly sets OACTIVE.
--
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 OACTIVE for an(4)
This small patch correctly sets OACTIVE when an(4) gets backed up. Right now
I believe it will never set the flag. It is only an optimization, it should
not affect correctness.
Index: an/if_an.c
===
--- an/if_an.c (revision 270968)
+++ an/if_an.c (working copy)
@@ -2906,11 +2906,11 @@
CSR_WRITE_2(sc, AN_INT_EN(sc-mpi350), AN_INTRS(sc-mpi350));
}
- if (m0 != NULL)
+ if (sc-an_rdata.an_tx_prod != idx) {
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
+ sc-an_rdata.an_tx_prod = idx;
+ }
- sc-an_rdata.an_tx_prod = idx;
-
return;
}
--
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)
On Monday, September 15, 2014 11:25:47 AM John Baldwin wrote: 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. FYI, I wrote a test for the patch I sent to make this not panic and verified it worked ok and committed it. -- 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: [PATCHES] Convert various pc98 drivers from timeout() to callout()
On Thursday, September 25, 2014 11:15:51 am TAKAHASHI Yoshihiro wrote: In article 2960329.sjarrui...@ralph.baldwin.cx John Baldwin j...@freebsd.org writes: I have three patches to convert various pc98 drivers from timeout() to callout(). For the fdc driver I took a more drastic approach and have attempted to port the PC98 support into the main fdc driver: Great! Unfortunately, I don't have enough time to review and test your patches so please feel free to commit them. When I have time, I'll check. Thanks for your work. Ok. I'm mostly nervous about the fdc(4) patch, but I will move forward. Thanks! -- 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: Poor state of the build infrastructure.
On Wednesday, September 24, 2014 7:33:46 pm Marcel Moolenaar wrote: On Sep 24, 2014, at 12:54 PM, John Baldwin j...@freebsd.org wrote: On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: What is going on here? Are we still in some kind of flux and people aren't done yet or is this the intended state by virtue of noone having anything left on there TODO list? Sorry to ask a dumb question, but are you sure you did the make buildworld first? Shouldn't that have errored if it couldn't build crt1? The root cause problem was that MAKEOBJDIRPREFIX was not set to whatever it was set to during buildworld. That was easy enough to figure out when a bunch of things don't add up. Ok. But neither problem mentioned in the email had anything to do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE as part of an install is a bug. Entering a powerpc buildenv and having a compiler that builds for the host (or maybe just some default) is a regression. Agreed on COMPILER_TYPE, but I think the path thing has always been true in make buildenv because we don't build cross-tools for things like 'cp'. -- 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 ncr(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/ncr_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
[PATCHES] Convert various pc98 drivers from timeout() to callout()
I have three patches to convert various pc98 drivers from timeout() to callout(). For the fdc driver I took a more drastic approach and have attempted to port the PC98 support into the main fdc driver: http://people.FreeBSD.org/~jhb/patches/pc98_fdc.patch The pckbd driver needs a similar change to what I recently comitted to atkbd: http://people.FreeBSD.org/~jhb/patches/pckbd_callout.patch For the olpt driver, I just did a simple conversion: http://people.FreeBSD.org/~jhb/patches/olpt_callout.patch These patches are against HEAD but likely apply to 9 and 10 as well. -- 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 some timers in isp(4) from timeout(9) to callout(9)
This patch converts a few timers in isp(4) from timeout(9) to callout(9). It already used callout(9) for normal command timeouts. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/isp_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: Poor state of the build infrastructure.
On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: What is going on here? Are we still in some kind of flux and people aren't done yet or is this the intended state by virtue of noone having anything left on there TODO list? Sorry to ask a dumb question, but are you sure you did the make buildworld first? Shouldn't that have errored if it couldn't build crt1? I think if you haven't done a make buildworld/toolchain, then when you do make buildenv you will fall back to using the host tools: make TARGET=sparc64 buildenv Entering world for sparc64:sparc64 $ echo $PATH /usr/obj/sparc64.sparc64/usr/src/tmp/legacy/usr/sbin:/usr/obj/sparc64.sparc64/usr/src/tmp/legacy/usr/bin:/usr/obj/sparc64.sparc64/usr/src/tmp/legacy/usr/games:/usr/obj/sparc64.sparc64/usr/src/tmp/legacy/bin:/usr/obj/sparc64.sparc64/usr/src/tmp/usr/sbin:/usr/obj/sparc64.sparc64/usr/src/tmp/usr/bin:/usr/obj/sparc64.sparc64/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin $ which cc /usr/obj/sparc64.sparc64/usr/src/tmp/usr/bin/cc $ which cat /bin/cat -- 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] Various fixes to wl(4)
On Friday, September 19, 2014 03:47:16 PM Warner Losh wrote: I got rid of my pre-802.11 WaveLAN cards about 8 years go after not having them in a system at all for 8 years. And they were about 4 years obsolete when I took them out of service… I’m not even sure I have a machine with an ISA slot to test the card, even if I still had it. Sorry I can’t help more :) If no one tests them then I will happily toss the driver into the dustbin, just giving folks a chance to test patches before I do so. (I'm secretly hoping I can purge several old drivers during the current round of timeout() purging.) Warner On Sep 19, 2014, at 2:07 PM, John Baldwin j...@freebsd.org wrote: 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
Re: libthr and main thread stack size
On Sunday, September 21, 2014 09:36:25 PM Justin T. Gibbs wrote: On Sep 20, 2014, at 11:06 AM, Konstantin Belousov kostik...@gmail.com wrote: On Fri, Sep 19, 2014 at 03:27:25PM -0400, John Baldwin wrote: 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. Ok, below is the patch. I felt bad about adding yet another magic and undocumented tunable to our libthr. Since there seems to be no alternative than a tunable to enforce old behaviour, I documented the quirks I am aware of. Why do we need to support the old behavior? Any program that ran in the old model will run in the new. In the unlikely event that someone was using the old scheme for administrative control, there are other mechanisms for this already available that we can point them to instead. I agree with this. In my experience the issue it has always been the opposite (people having issues with the main stack shrinking). -- 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] Various fixes to wl(4)
On Monday, September 22, 2014 12:42:34 PM Adrian Chadd wrote: On 22 September 2014 12:20, John Baldwin j...@freebsd.org wrote: On Friday, September 19, 2014 03:47:16 PM Warner Losh wrote: I got rid of my pre-802.11 WaveLAN cards about 8 years go after not having them in a system at all for 8 years. And they were about 4 years obsolete when I took them out of service… I’m not even sure I have a machine with an ISA slot to test the card, even if I still had it. Sorry I can’t help more :) If no one tests them then I will happily toss the driver into the dustbin, just giving folks a chance to test patches before I do so. (I'm secretly hoping I can purge several old drivers during the current round of timeout() purging.) The wavelan/prism driver no longer works out of the box and hasn't since I took over the net80211 stack. TL;DR - some changes from sam and others a few years ago to do raw 802.11 frame transmit just doesn't work on all the wavelan cards that are in use. I've asked for someone interested to go through the changelog and back out those changes, making the driver again a straight 802.3 transmit driver - but noone has. :( So yes, you have a +1 to disconnect the wavelan driver from the build. I think you are referring to wi(4)? -- 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 spic(4)
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)
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
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?
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
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
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
Re: UEFI display frozen on Retina MacBook Pro
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
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: ddb_enable=YES by default?
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
Re: ddb_enable=YES by default?
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: [PATCH]Modify do_exec() handler to deal with multiple imgact handlers
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: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))
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?
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: 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: 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: PostgreSQL performance on FreeBSD
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]
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: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
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]
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: Boot loader too large
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
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
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: Fix Emulex oce driver in CURRENT
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
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
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 ?
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
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...
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
