In FreeBSD 9, examining the VM map of a process (with e.g. 'procstat
-v') with a tmpfs file mapped showed a VNODE type and displayed the file
path. In 10.0 up to CURRENT (I believe this started at r250030), instead
SWAP is shown without a filepath.
This has some unfortunate consequences; I dis
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.
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 fac
On 02/03/2015 02:33 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&#
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
Using log(9) when no process is reading the log results in the message
going only to the console (contrast with printf(9), which goes to the
console and to the kernel message buffer in this case). I believe it is
truer to the semantics of logging for messages to *always* go to the
message buffe
On 04/06/2015 04:11 PM, Poul-Henning Kamp wrote:
In message <2033248.eu3rhs8...@ralph.baldwin.cx>, John Baldwin writes:
I think phk@ broke this back in 70239. Before that the log() function did
this:
log()
{
/* log to the msg buffer */
kvprintf(fmt, msglogchar, ...);
Hi Ryan and -current,
During IOV config, when setting up VF bars, several calls are made to
'pci_read_bar' (in sys/dev/pci/pci.c) in order to size VF BARs, which causes
memory decoding to be turned off temporarily for the PF associated with those
VFs. I'm finding that this can interfere with an
On 05/06/15 13:33, John Baldwin wrote:
On Wednesday, May 06, 2015 02:24:24 PM Ryan Stone wrote:
On Wed, May 6, 2015 at 11:45 AM, John Baldwin wrote:
There are some devices with BARs in non-standard locations. :( If there is
a flag to just disable the VF bar decoding, then ideally we should j
ng initialization a
couple of extra register accesses are irrelevant anyway.
On Wed, May 6, 2015 at 2:58 PM, Eric Badger
mailto:eric.bad...@compellent.com>> wrote:
Does the disabling of VF MSE in pci_iov_config actually protect
anything else beyond what happens in pci_read_bar?
Hi there,
Since r226435, output from kernel printf/log functions is not appended
to the message buffer when in ddb. The commit message doesn't call this
out specifically; instead it appears to have been to address double
printing to the console while in ddb. I noticed this because a ddb
scrip
On 08/03/2015 03:21 PM, Marcel Moolenaar wrote:
On Aug 3, 2015, at 12:59 PM, Eric Badger wrote:
Hi there,
Since r226435, output from kernel printf/log functions is not appended to the message
buffer when in ddb. The commit message doesn't call this out specifically; instead it
appea
On 12/20/2016 15:29, Steve Kargl wrote:
> Anyone know how to kill firefox?
>
> last pid: 69652; load averages: 0.49, 0.27, 0.24 up 1+02:40:06
> 13:16:02
> 126 processes: 1 running, 121 sleeping, 4 stopped
> CPU: 0.8% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
> Mem: 20
Hi there,
There seems to be some racy code in kern_event.c which is causing me to
run into some crashes. I’ve attached the test program used to generate
these crashes (build it and run the “go” script). They were produced in
a VM with 4 cores on 11 Alpha 3 (and originally 10.3). The crashes I’
Oops, I don't think my attachment worked. This should do the trick:
https://drive.google.com/open?id=0B8Lj3D-GnaCcS0taVVNlQktQRkk
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, se
15 matches
Mail list logo
