NULL check is needed for bus_dmamap_unload() too.
No, buf_addr should only be set if bus_dmamap_load() was called.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubsc
Eric van Gyzen wrote this message on Mon, Jun 23, 2014 at 08:57 -0500:
> On 06/23/2014 08:44, John-Mark Gurney wrote:
> > So, when I try to eject a ESATA card, the machine panics... I am able
> > to successfully eject other cards, an ethernet (re) and a serial card
> > (uart)
it the deadc0de address, to print up a
special message or something? At least flag it, or do we not get
the faulting address?
This is HEAD as of r266429.
Let me know if there is anything else you need to know.
Thanks.
--
John-Mark Gurney Voice: +1 415 225 5579
t all. As far as I remember there was
> always a minimum set of nodes in there, like ttys etc.
>
> What happened? Which changes did I miss?
We use devfs, so you don't need anything in /dev... when the system
boots, it'll automatically mount /dev for you..
--
John-Mark Gurney
On Wednesday, June 18, 2014 4:36:24 pm Hans Petter Selasky wrote:
> On 06/18/14 15:44, John Baldwin wrote:
> > On Wednesday, June 18, 2014 7:36:53 am Hans Petter Selasky wrote:
> >> Hi,
> >>
> >> Sometimes sysctl's default value needs to be setup at boot
On Wednesday, June 18, 2014 2:46:09 pm Edward Tomasz Napierała wrote:
> On 0618T1303, John Baldwin wrote:
> > On Wednesday, June 18, 2014 12:13:15 pm Edward Tomasz Napierała wrote:
> > > On 0618T0947, John Baldwin wrote:
> > > > On Monday, June 16, 2014 3:21:55 pm
On Wednesday, June 18, 2014 12:13:15 pm Edward Tomasz Napierała wrote:
> On 0618T0947, John Baldwin wrote:
> > On Monday, June 16, 2014 3:21:55 pm Edward Tomasz Napierała wrote:
> > > Hi. Patch below should fix a problem where USB stops working after
> > > _second_ su
he CTLFLAG_TUN flag for cases you aren't
sure about for now. It probably makes sense to do these changes in stages.
I was going to suggest using sbuf() for building the tunable name, but that
doesn't work since you have to build it in reverse.
--
John Baldwin
_
tipass
suspend/resume in that ACPI buses (e.g. acpi_pci and acpi0 itself) should be
turning on any power sources associated with an ACPI device during the
bus_resume_child() callback.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
ht
l/kernel. (You can
set things like KERNCONF to pick an alternate kernel config just as with
normal 'make buildkernel'.)
(Your attachment was size zero for me btw)
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.fr
Hans Petter Selasky wrote this message on Thu, Jun 12, 2014 at 21:06 +0200:
> On 06/12/14 20:52, John-Mark Gurney wrote:
> >So, I'm trying to get USB functional on an old i386 machine that only
> >supports USB 1.0... It works, but when I try to plug in a hub I get
> >
ports, and works..
Let me know if there is anything more info I can provide.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
freebsd-c
Alexander V. Chernikov wrote this message on Tue, Jun 10, 2014 at 21:33 +0400:
> On 10.06.2014 20:24, John-Mark Gurney wrote:
> >Alexander V. Chernikov wrote this message on Tue, Jun 10, 2014 at 13:17
> >+0400:
> >>On 10.06.2014 07:03, Bryan Venteicher wrote:
> >&
from
> >earlier in the year showing an absurd amount of time spent in bpf_mtap():
> Can you briefly describe test setup?
For mine, one machine is sink:
nc -l 2387 > /dev/null
The machine w/ dhclient is source:
nc carbon 2387 < /dev/zero
> (Actually I'm interested in ov
14
r...@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
WARNING: WITNESS option enabled, expect reduced performance.
CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (1995.05-MHz K8-class CPU)
Origin="G
f you care about performance, don't run dhclient...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
freebsd-current@freebsd.org mailing list
On Saturday, June 07, 2014 4:47:39 am Edward Tomasz Napierała wrote:
> On 0604T1036, John Baldwin wrote:
> > On Monday, June 02, 2014 5:32:13 pm Edward Tomasz Napierała wrote:
> > > Some machines, including ThinkPad T61, emit the following error message
> > > early dur
ws-what but apparently triggers one of the local APIC local interrupts
while it is configured with an invalid vector (e.g. 0).
--
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"
Pawel Jakub Dawidek wrote this message on Mon, Jun 02, 2014 at 22:26 +0200:
> On Mon, Jun 02, 2014 at 11:01:08AM -0700, John-Mark Gurney wrote:
> > Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400:
> > > On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone
0-0xc0ff mem
0xe004-0xe0040fff irq 71 at device 1.0 on pci192
If it works fine on ia64 it will probably work at least as well under amd64.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
ot;bind" the two together so
that when one opens, the other doesn't disappear... The problem is
that geom views them as two separate disks when in fact they are the
same... someone who knows geom well should think about how to solve
this problem, as diskid isn'
pters in a single box.
Please be sure to test with INVARIANTS and INVARIANT_SUPPORT enabled.
http://people.FreeBSD.org/~jhb/patches/hpt27xx_locking.patch
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis
On Thursday, May 29, 2014 5:46:05 pm Adrian Chadd wrote:
> On 29 May 2014 14:29, John Baldwin wrote:
> > On Thursday, May 29, 2014 5:09:05 pm Adrian Chadd wrote:
> >> On 29 May 2014 13:18, John Baldwin wrote:
> >>
> >> >> anyway. Besides all
On Thursday, May 29, 2014 5:09:05 pm Adrian Chadd wrote:
> On 29 May 2014 13:18, John Baldwin wrote:
>
> >> anyway. Besides all of this - I'm thinking of just introducing:
> >>
> >> typedef uint32_t cpuid_t;
> >>
> >> .. then once we'
On Thursday, May 29, 2014 3:27:57 pm Konstantin Belousov wrote:
> On Thu, May 29, 2014 at 02:44:19PM -0400, John Baldwin wrote:
> > On Thursday, May 29, 2014 2:24:45 pm Adrian Chadd wrote:
> > > On 29 May 2014 10:18, John Baldwin wrote:
> > >
> > > >>
On Thursday, May 29, 2014 4:05:49 pm Adrian Chadd wrote:
> On 29 May 2014 11:44, John Baldwin wrote:
> > On Thursday, May 29, 2014 2:24:45 pm Adrian Chadd wrote:
> >> On 29 May 2014 10:18, John Baldwin wrote:
> >>
> >> >> > It costs wired memory
On Thursday, May 29, 2014 2:24:45 pm Adrian Chadd wrote:
> On 29 May 2014 10:18, John Baldwin wrote:
>
> >> > It costs wired memory to increase it for the kernel. The userland set
> >> > size
> >> > can be increased rather arbitrarily, so we don't
On Thursday, May 29, 2014 12:53:54 pm Adrian Chadd wrote:
> On 28 May 2014 10:58, John Baldwin wrote:
> > On Wednesday, May 28, 2014 1:51:28 pm Adrian Chadd wrote:
> >> On 28 May 2014 06:56, John Baldwin wrote:
> >>
> >>
> >> > User
to disturb him unnecessarily.
>
> And yes, as Alexander points out, zfs is also a possibility.
ZFS is almost certainly the cause of the wired memory usage.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mai
On Thursday, May 29, 2014 9:57:22 am Alexander Kabaev wrote:
> On Thu, 29 May 2014 09:08:10 -0400
> John Baldwin wrote:
>
> > On Thursday, May 29, 2014 5:41:03 am Beeblebrox wrote:
> > > uname: FreeBSD 11.0-CURRENT #0 r266393M: Sun May 18 13:04:00 2014
> > > amd6
memory
>
> I don't know if the lsof dump in single user mode will be of any help, but
> it seems like lib/libc.so.7 has something to do with it:
Why do you think libc.so.7 has anything to do with this? wired memory is
usually only allocated in the kernel, so if anything you are
On Wednesday, May 28, 2014 1:51:28 pm Adrian Chadd wrote:
> On 28 May 2014 06:56, John Baldwin wrote:
>
>
> > Userland cpusets only default to 128 (CPU_MAXSIZE in ).
> > Changing MAXCPU to even 128 is unfortunately a potential KBI change since it
> > changes the
On Friday, May 23, 2014 4:39:39 pm Poul-Henning Kamp wrote:
> In message <201405231605.26312@freebsd.org>, John Baldwin writes:
>
> >In essence, top will consider any thread that has run on a CPU
> >since the last update as non-idle.
>
> Sounds a lot more usa
On Wednesday, May 28, 2014 8:20:35 am Jamie Landeg-Jones wrote:
> John, the changes are good.
>
> The "'trickling' but still not idle" processes now show up as they should.
>
> However, it has exposed one quirk in the display:
>
> Sorting is done
thing we could do safely is bump the userland cpuset size to 256 in 10.
It's really only MAXCPU that is problematic.
In particular, I propose we bump the userland cpuset_t size to 256 now (and
go ahead and merge that to 10). In HEAD only we can bump MAXCPU for amd64
to 256.
--
John Bald
On Sunday, May 25, 2014 3:11:05 am Kubilay Kocak wrote:
> On 24/05/2014 7:22 AM, Allan Jude wrote:
> > On 2014-05-23 16:05, John Baldwin wrote:
> >> Right now, when top is set to not display idle processes or threads, it
> >> only
> >> displays processe
still.
I also adopted phk@'s suggestion of counting changes in ru_nvcsw/ru_nivcsw
as evidence of running.
http://people.freebsd.org/~jhb/patches/top_pctcpu.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"
On Friday, May 23, 2014 4:39:39 pm Poul-Henning Kamp wrote:
> In message <201405231605.26312@freebsd.org>, John Baldwin writes:
>
> >In essence, top will consider any thread that has run on a CPU
> >since the last update as non-idle.
>
> Sounds a lot more usa
splay. Personally, I find
this more useful (and find the current implementation completely useless).
The patch is at http://people.freebsd.org/~jhb/patches/top_idle.patch
Comments?
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
_cis() can do a bus_alloc_resource()
for SYS_RES_MEMORY rid 0 of a pccard device concurrently with
pccard_function_init(). Hans patch might be along the right track, though
we might want to make /dev/pccard.X block until pccard_function_init()
finishes rather than causing pccard_s
R
These are probably not related. These man that your BIOS explicitly told the
OS to power down these devices (PEG_ is probably your GPU, and EXP[1-5] are
probably PCI-PCI bridges that represent the downstream ports of your PCI-e
root complex) in the D2 st
t in theory it works more often. The
ACPI_PM setting to the kernel module along with removing VESA would seem
like your best bet, but I see in follow-ups that that wasn't completely
reliable. However, you can try using ACPI_PM with syscons, no need to
use vt.
--
John Baldwin
.
The trace will tell you where the second resource_list_add() is
occurring. Some tracing should let you see where the first one occurs.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
xporting Intel C3 as C2, but do not advertise Intel
C6/C7 as C3 until you enable that in the BIOS.
> http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e3-1200v3-vol-1-datasheet.pdf
>
> How is our support for the newer Cx States introduced in Haswell,
rivers or per-CPU swi threads) from the
default cpuset so that they don't break 'cpuset -l 0 -s 1'. Providing some
sort of way to disable the pinning for now should be good, but I think I'd
eventually prefer the former suggestion.
--
John Baldwin
_
Thanks,
To be clear, are you going to commit the change to bind all but CPU 0
to their CPU but let the "default" swi float for now? I think that is
fine to commit, but I wouldn't want to bind the "default" swi for now.
> -a
>
>
> On 20 February 2014 13:48, Ad
P4 laptop where this is the case, I think Pentium-M is too
new to need this.) If we keep TCC at all, it should not be tied into cpufreq
but be a separate thing that only acpi_thermal.c uses.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
ht
hough there is a kernel option
to disable diskid's (which would solve the ZFS on root problem) for
all devices.. search the archives as you're not the first one to raise
this issue...
--
John-Mark Gurney
On Saturday, March 29, 2014 8:23:44 pm Adrian Chadd wrote:
> ... nope, just had a process die from SIGFPE.
Does it still trigger SIGFPE if you suspend/resume a UP kernel?
> -a
>
>
> On 29 March 2014 07:32, Adrian Chadd wrote:
> > Hi!
> >
> > On 26 Marc
Drive (C:)*
>
> *gptzfsboot: error 1 lba 32*
>
> *gptzfsboot: error 1 lba 1*
>
> *g**ptzfsboot: No ZFS pools located, can't boot*
>
>
> A workaround is
> http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026624.html
I believe the proper fix for that bug was committed here:
http://svnweb.freebsd.org/base?view=revision&revision=243025
--
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"
her algorithms
to OpenCrypto...
If you let me know more about what you're trying to do, I'll help you..
Thanks.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
Konstantin Belousov wrote this message on Wed, Apr 02, 2014 at 15:07 +0300:
> On Wed, Apr 02, 2014 at 04:06:16PM +0900, Kohji Okuno wrote:
> > From: John-Mark Gurney
> > Date: Tue, 1 Apr 2014 23:15:51 -0700
> > > Kohji Okuno wrote this message on Wed, Apr 02, 2014 at 11:
and then you can print
it out yourself...
I'm going to take a look at this a bit more later... I'm thinking of
using dtrace to collect the stacks where filt_signal is called, and
match them up... dtrace might even be able to get us the note's data
upon return helping to make sure thing
On Monday, March 31, 2014 10:20:53 pm Kevin Lo wrote:
> On 2014/03/28 00:21, John Baldwin wrote:
> > On Thursday, March 27, 2014 5:32:16 am Kevin Lo wrote:
> >>>>> Are you interested in working on these and report back?
> >>>> The revised patch is avai
Willy Offermans wrote this message on Thu, Mar 27, 2014 at 15:46 +0100:
> Hello John-Mark and FreeBSD friends,
>
> On Wed, Mar 26, 2014 at 04:04:27PM -0700, John-Mark Gurney wrote:
> > Willy Offermans wrote this message on Wed, Mar 26, 2014 at 18:22 +0100:
> > > Hel
third version of the udp-lite patch:
> http://people.freebsd.org/~kevlo/udplite.diff
Ok, I would say that udp_common_init() is actually a better name if you keep
the macro (which I think is fine) rather than udp_udplite_init() as the macro
is not specific to UDP Lite. However,
> Philipp
>
> PS: I have a custom kernel with VIMAGE which I use with the jail
Can you get a crashdump when it crashes? Also, I thought that
VIMAGE + pf is known to be unstable?
--
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"
Willy Offermans wrote this message on Wed, Mar 26, 2014 at 18:22 +0100:
> Hello John-Mark and FreeBSD friends,
>
> On Wed, Mar 26, 2014 at 09:20:35AM -0700, John-Mark Gurney wrote:
> > Willy Offermans wrote this message on Wed, Mar 26, 2014 at 12:17 +0100:
> > > On Tue, Ma
On Wednesday, March 26, 2014 1:43:22 pm John Baldwin wrote:
> On Tuesday, March 25, 2014 5:38:50 pm Adrian Chadd wrote:
> > On 25 March 2014 12:46, John Baldwin wrote:
> > > On Sunday, March 23, 2014 4:41:24 pm Adrian Chadd wrote:
> > >> [snip]
> > >>
UDPLite applications), test with vimage, etc:
> >
> > http://people.freebsd.org/~kevlo/udplite.diff
> > http://people.freebsd.org/~kevlo/udp-v.diff
> >
> > Are you interested in working on these and report back?
>
> The revised patch is available at:
> http://people.freebsd.org/~kevlo/udplite.diff
A few suggestions:
- I would just drop the INP lock and return EOPNOTSUPP directly rather
than using goto's to 'bad_setoptname' and 'bad_getoptname' so the
UDP-lite options are self-contained.
- I'm not a super big fan of all the udp_common_* macros only because
I think it obfuscates things. At the very least, please move these
things out of the header and into udp_usrreq.c so they are closer
to the implementation. I would even suggest making them inline
functions instead of macros.
However, I think the patch generally looks ok.
--
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"
On Tuesday, March 25, 2014 5:38:50 pm Adrian Chadd wrote:
> On 25 March 2014 12:46, John Baldwin wrote:
> > On Sunday, March 23, 2014 4:41:24 pm Adrian Chadd wrote:
> >> [snip]
> >>
> >> Hi,
> >>
> >> As part of this thread, a whole lot of stu
is litterally only mail with
attachments and not large emails w/o attachments, then it's definately
not that issue..He could just disable path_mtu on the server:
sysctl net.inet.tcp.path_mtu_discovery=0
to test this, but I'd be surprised if it allows email through, since
he's al
Willy Offermans wrote this message on Wed, Mar 26, 2014 at 12:17 +0100:
> On Tue, Mar 25, 2014 at 09:43:16AM -0700, John-Mark Gurney wrote:
> > Willy Offermans wrote this message on Tue, Mar 25, 2014 at 11:39 +0100:
> > > I'm not an expert in tcpdump. Can anyone make se
ed the first patch I posted here earlier when I first
posted it 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"
issue w/ FreeBSD not
sending out the last frame after ack? With out knowing what the last
packet contains, it's hard to say...
> 11:25:27.975453 IP ActualSmarthost.com.smtp > MyServer.MyDomain.com.51274:
> Flags [.], ack 17495, win 65160, length 0
> 11:25:43.535093 IP MyServer.My
cpflow to capture the flows for myprovider.com and look
at them...
Though you are seeing a timeout, so it sounds like myprovider.com isn't
reading your message in a timely fasion..
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has b
Warner Losh wrote this message on Thu, Mar 20, 2014 at 11:30 -0600:
>
> On Mar 20, 2014, at 8:25 AM, David Chisnall wrote:
>
> > On 20 Mar 2014, at 14:08, John Baldwin wrote:
> >
> >> No, the compiler should provide a working "wmmintrin.h" header
Ian Lepore wrote this message on Thu, Mar 20, 2014 at 08:29 -0600:
> On Thu, 2014-03-20 at 10:08 -0400, John Baldwin wrote:
> > On Tuesday, March 18, 2014 6:20:50 pm Bjoern A. Zeeb wrote:
> > >
> > > On 18 Mar 2014, at 22:01 , John-Mark Gurney wrote:
> > >
On Wednesday, March 19, 2014 4:28:15 pm Warren Block wrote:
> On Wed, 19 Mar 2014, John Baldwin wrote:
>
> > On Wednesday, March 19, 2014 12:38:57 am Warren Block wrote:
> >> On Tue, 18 Mar 2014, John Baldwin wrote:
> >>
> >>> On Monday, March 17, 2014 7:
On Tuesday, March 18, 2014 6:20:50 pm Bjoern A. Zeeb wrote:
>
> On 18 Mar 2014, at 22:01 , John-Mark Gurney wrote:
>
> > Lev Serebryakov wrote this message on Wed, Mar 19, 2014 at 01:37 +0400:
> >> I did't build my NanoBSD images for almost year, and in this t
if (offset == 0) {
*paddr = vtophys(spp->stat);
+ mtx_unlock(&devstat_mutex);
return (0);
}
offset -= PAGE_SIZE;
}
+ mtx_unlock(&devstat_mutex);
reference. Another is to expect the application to call fileno() and not
> return the descriptor from the new function.
I would prefer the latter of requiring the application to use fileno().
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
h
On Wednesday, March 19, 2014 12:38:57 am Warren Block wrote:
> On Tue, 18 Mar 2014, John Baldwin wrote:
>
> > On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote:
> >> Hi,
> >>
> >> After our previous discuss [1] I prepare fdclosedir(3) function w
Bjoern A. Zeeb wrote this message on Tue, Mar 18, 2014 at 22:20 +:
>
> On 18 Mar 2014, at 22:01 , John-Mark Gurney wrote:
>
> > Lev Serebryakov wrote this message on Wed, Mar 19, 2014 at 01:37 +0400:
> >> I did't build my NanoBSD images for almost year,
our tool chain doesn't have the necessary support for
AES-NI... Are you using gcc as cc? If so, do you have the necessary
tool chain work that I did in r255185 in your local tree?
Can you compile this test program?
-- tsse.c start
#include
__m128i foo;
-- tsse.c end --
With the
ons
Currently newcons does not support VESA mode changing for it's standard vga
backend AFAIK. The default 80x25 console is fine on an Nvidia card (it's what
I used to test the 10 MFC), but it is slow.
--
John Baldwin
___
free
There is a dedicated lock profiler (LOCK_PROFILING) in the kernel. A
previous GSoC student from an earlier year has already re-implemented both
LOCK_PROFILING and WITNESS for pthreads.
--
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"
t;>
> >> #define vm_min_offset header.start /* (c) */
> >> #define vm_max_offset header.end /* (c) */
> >>
> >> Am I missing something?
> >
> > A simpler fix is probably to put the #define's under #ifdef _KERNEL.
> >
> > --
> >
The
.Fn fclose
-function
+and
+.Fn fdclose
+functions
does not handle NULL arguments; they will result in a segmentation
violation.
This is intentional - it makes it easier to make sure programs written
"do not handle".
--
John Baldwin
___
free
Looks great! Thanks as always for the work. I do have one question (below).
On Mar 17, 2014, at 11:21 AM, Baptiste Daroussin wrote:
> - Remove support for PACKAGESITE
There are two cases where I still define PACKAGESITE in the environment,
specifically when building new jails or VM images. Can
d
downstream.
>
> I would suggest renaming those defines to:
>
> #define vm_min_offset header.start/* (c) */
> #define vm_max_offset header.end /* (c) */
>
> Am I missing something?
A simpler fix is probably to put the #define
;s
> >appropriate.
>
> This is how I envision it too. The idea is not to have libcrypt depend on
> libutil, but rather the opposite. Currently, there are at least two places
> where this code is being used, and in my opinion, libcrypt would be a
> better place for it.
>
On Tuesday, March 04, 2014 4:50:01 pm Bruce Evans wrote:
> On Tue, 4 Mar 2014, John Baldwin wrote:
> % Index: i386/i386/swtch.s
> % ===
> % --- i386/i386/swtch.s (revision 262711)
> % +++ i386/i386/swtch.s
rg)
> 150 {
> 151
> 152 vt_late_window_switch((struct vt_window *)arg);
> 153 }
> 154
> (kgdb) p *0x80d3adc0
> $2 = -2133611368
> (kgdb) quit
> # ^D
> Script done on Sun Mar 9 20:27:43 2014
>
> Thoughts?
This has been reported multiple times by both adrian@ and myself. I would try
disabling vt switching during suspend as a workaround for now. I found that
only ttyv0's timer object is zero'd when this happens. The timers for the
other VTY's are all fine.
--
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"
By my understanding, you can't, since often the VM isn't aware
of the parent, so doesn't know when to stop the clock when it isn't
running...
Unless I'm missing something, you really can't do any cpu or profiling
on a VM and trust the resul
uested
> for various password manipulating tools to reduce duplicated code.
So, the current code in pam_unix is:
login_setcryptfmt which calls crypt_set_format as necessary
makesalt
crypt
So, we could expand crypt_set_format to understand the two, and keep
a copy of the rounds data, or we cou
Xin Li wrote this message on Fri, Mar 07, 2014 at 16:43 -0800:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 03/07/14 15:07, John-Mark Gurney wrote:
> > Allan Jude wrote this message on Fri, Mar 07, 2014 at 17:53 -0500:
> >> On 2014-03-07 17
it would allow an
automatic increase in security as faster CPUs are used...
Anyways, how many people are still using passwords instead of ssh keys?
Setting the time to be something like 100ms may seem long, but
considering few people should be using passwords these days, it's less
of
On Friday, March 07, 2014 10:34:40 am Tom Evans wrote:
> On Fri, Mar 7, 2014 at 2:13 PM, John Baldwin wrote:
> > On Wednesday, March 05, 2014 3:09:30 pm Matthew Rezny wrote:
> >> > > Password expiry is an orthogonal issue and should be up to
> >> >
ion it doesn't work. (You would at least want a warning
about the hash being expired on login via another mechanism.)
--
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"
27;statfoo' is a pretty silly name? (This is detailed in another
subthread, did you not read that?)
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail
On Wednesday, March 05, 2014 6:07:23 am Konstantin Belousov wrote:
> On Wed, Mar 05, 2014 at 11:41:24AM +0200, Andriy Gapon wrote:
> > on 04/03/2014 18:45 John Baldwin said the following:
> > > So I'm not sure how to fix this. The crash is in this code in
>
On Monday, March 03, 2014 9:49:39 pm Bryan Drewery wrote:
> On 3/3/2014 12:06 PM, John Baldwin wrote:
> > On Sunday, March 02, 2014 10:58:45 am Bryan Drewery wrote:
> >> On 2/28/2014 3:18 PM, John Baldwin wrote:
> >>> On Friday, February 28, 2014 9:18:51 am Bryan Dre
set CPUTYPE
so that your userland binaries do not use the FPU, you can probably resume
just fine without this fix.
> -a
>
>
> On 3 March 2014 11:11, John Baldwin wrote:
> > On Friday, February 28, 2014 9:00:57 pm Adrian Chadd wrote:
> >> On 28 February 2014 15:35, Adrian Ch
in the serial console. How can I do this?
> Or do I need to disable vt for this?
This sounds normal for the console being on the VGA console and not serial.
I've no idea how close ia64's boot loader is to x86's in that regard. Marcel
is probably the right person to ask.
On Sunday, March 02, 2014 10:58:45 am Bryan Drewery wrote:
> On 2/28/2014 3:18 PM, John Baldwin wrote:
> > On Friday, February 28, 2014 9:18:51 am Bryan Drewery wrote:
> >> While using poudriere:
> >>
> >>> Unread portion of the kernel message buffer:
>
eventual expiration of non-migrated accounts gives a false
sense of security. Any admin worth his/her salt is going to want the option
of enforcing that sort of policy along with the transparent update. They
should really be implemented together is all.
--
John Baldwin
_
tested) here:
http://www.FreeBSD.org/~jhb/patches/i386_fpu_suspend.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"
Florian Smeets wrote this message on Sat, Mar 01, 2014 at 16:28 +0100:
> On 01/03/14 02:16, John-Mark Gurney wrote:
> > Dimitry Andric wrote this message on Fri, Feb 28, 2014 at 20:22 +0100:
> >>
> >> For building the sparc64 kernel, there is one open issue left, whi
ns... We use
PCPU_SET(mem, PCPU_GET(mem) + val) for PCPU_ADD, not great, but it's
no worse than what we were previously using..
Until we get a proper fix which involves mapping all the cpu's PCPU
data on all CPUs, this will have to sufice..
This patch is based upo
801 - 900 of 4747 matches
Mail list logo
