On Sat, Oct 24, 2020 at 2:38 PM Mark Johnston wrote:
> On Fri, Oct 23, 2020 at 06:32:25PM +0200, Michal Meloun wrote:
> >
> >
> > On 19.10.2020 22:39, Mark Johnston wrote:
> > > On Fri, Oct 16, 2020 at 11:53:56AM +0200, Michal Meloun wrote:
> > >>
> > >>
> > >> On 06.10.2020 15:37, Mark Johnston
On 08/22/2018 10:29, Alan Cox wrote:
> On 08/22/2018 08:48, tech-lists wrote:
>> On 22/08/2018 05:29, Manfred Antar wrote:
>>>> On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev
>>>> wrote:
>>>>
>>>> On Tue, Aug 21, 2018 at 11:22:56PM +07
On 08/22/2018 08:48, tech-lists wrote:
> On 22/08/2018 05:29, Manfred Antar wrote:
>>
>>> On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev
>>> wrote:
>>>
>>> On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote:
Перенаправленное сообщение
Тема: nvidia-driver buil
On 08/21/2018 23:29, Manfred Antar wrote:
>
>> On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev wrote:
>>
>> On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote:
>>> Перенаправленное сообщение
>>> Тема: nvidia-driver build error (last ports, FreeBSD-HEAD)
>>> Дата: Tue, 2
On Mon, Oct 9, 2017 at 4:22 AM, Oleg V. Nauman wrote:
> panic: freeing invalid range
> cpuid = 0
> time = 1507550062
> Uptime: 2s
> .
> #0 doadump (textdump=) at pcpu.h:232
> 232 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) #0 doadump (textdump=) at
> pcpu.h:232
>
On 07/05/2017 13:47, Guy Yur wrote:
> Hi Alan,
>
> On 1 July 2017 at 23:07, Alan Cox wrote:
>> On Sat, Jul 1, 2017 at 2:46 PM, Guy Yur wrote:
>>> Hi,
>>>
>>> I tried to run armv6 /bin/sh in a chroot on an
>>> amd64 host using qemu-ar
On Sat, Jul 1, 2017 at 2:46 PM, Guy Yur wrote:
> Hi,
>
> I tried to run armv6 /bin/sh in a chroot on an
> amd64 host using qemu-arm-static.
> It failed on invalid argument to mmap.
>
> # cp /usr/local/bin/qemu-arm-static /chroots/armv6/root/
> # chroot /chroots/armv6 /root/qemu-arm-static /bin/sh
On Sun, Feb 14, 2016 at 8:09 AM, Andriy Gapon wrote:
> On 10/02/2016 23:28, Andriy Gapon wrote:
> >
> > Over a span of approximately 3 weeks I have got two slightly different
> panics of
> > the same kind. The affected system is a several months old amd64 head.
>
> I added a small assertion and
On 01/09/2016 14:05, Alan Cox wrote:
> On 01/09/2016 13:48, Adrian Chadd wrote:
>> On 9 January 2016 at 11:30, John Baldwin wrote:
>>> On Thursday, January 07, 2016 01:47:32 AM Cy Schubert wrote:
>>>> In message
>>>> >>> om>
>>>&g
On 01/09/2016 13:48, Adrian Chadd wrote:
> On 9 January 2016 at 11:30, John Baldwin wrote:
>> On Thursday, January 07, 2016 01:47:32 AM Cy Schubert wrote:
>>> In message >> om>
>>> , Jeremie Le Hen writes:
On Mon, Dec 21, 2015 at 12:57 AM, Adrian Chadd
wrote
:
> can you copy/p
On Sat, Jan 9, 2016 at 12:44 AM, Adrian Chadd
wrote:
> It shouldn't have changed though; you're just requesting memory to use
> for x86bios calls.
>
> +jhb - any ideas?
>
>
Yes, there is insufficient free (or reclaimable) physical memory below 1MB,
so contigmalloc() fails.
This is almost certai
that I said, "vm_page_reclaim_contig", not
"vm_pageout_reclaim_contig". The function in FreeBSD is different from
that in NextBSD.
>> On Dec 19, 2015, at 7:45 PM, Alan Cox wrote:
>>
>> On 12/19/2015 19:00, Michael Butler wrote:
>>> While the kernel modules will
On 12/19/2015 19:00, Michael Butler wrote:
> While the kernel modules will build, they won't load ..
>
> kernel: linker_load_file: Unsupported file type
> kernel: link_elf_obj: symbol vm_pageout_grow_cache undefined
> kernel: linker_load_file: Unsupported file type
> kernel: KLD vboxnetflt.ko: depe
On Thu, Jul 30, 2015 at 6:34 AM, Zbigniew Bodek wrote:
> Hello,
>
> I'm writing to ensure what to do with that patch:
> https://reviews.freebsd.org/D1945
>
> It was created as a result of discussion related to this review:
> https://reviews.freebsd.org/D1833
> The patch (D1945) is still waiting t
This is fixed in r282706.
On Sun, May 10, 2015 at 10:19 AM, David Wolfskill
wrote:
> As noted yesterday, my laptop panicked trying to boot head/i386
> @r282676, but seemed OK withe head/amd64.
>
> That turns out to have been a bit optimistic: today, while performing a
> src update on the laptop
On 04/10/2015 04:11, Svatopluk Kraus wrote:
> Hi,
>
> my RPI-B has been stuck in vm_reserv_reclaim_contig() due to a bug
> within that function. I can reproduce that easily on my two-core
> pandaboard when I limit all memory in system to 128MiB and run "make
> -j16 kernel-toolchain". It happens in
On 04/05/2015 19:49, Rui Paulo wrote:
> On Apr 5, 2015, at 13:07, Alan Cox wrote:
>> On 04/05/2015 14:34, Gleb Smirnoff wrote:
>>> On Sun, Apr 05, 2015 at 12:45:00PM -0500, Alan Cox wrote:
>>> A> On 04/05/2015 10:47, Gleb Smirnoff wrote:
>>> A> > On
On 04/05/2015 15:17, Gleb Smirnoff wrote:
> On Sun, Apr 05, 2015 at 03:07:56PM -0500, Alan Cox wrote:
> A> On 04/05/2015 14:34, Gleb Smirnoff wrote:
> A> > On Sun, Apr 05, 2015 at 12:45:00PM -0500, Alan Cox wrote:
> A> > A> On 04/05/2015 10:47, Gleb Smirnoff wrote:
&g
On 04/05/2015 14:34, Gleb Smirnoff wrote:
> On Sun, Apr 05, 2015 at 12:45:00PM -0500, Alan Cox wrote:
> A> On 04/05/2015 10:47, Gleb Smirnoff wrote:
> A> > On Sun, Apr 05, 2015 at 06:37:58AM -0700, David Wolfskill wrote:
> A> > D> It ocurred rather late in the tran
On 04/05/2015 10:47, Gleb Smirnoff wrote:
> On Sun, Apr 05, 2015 at 06:37:58AM -0700, David Wolfskill wrote:
> D> It ocurred rather late in the transition to multi-user mode, but
> D> prior to starting xdm (on my laptop).
> D>
> D> Previous (working) head/i386 for this machine was r281074.
> D>
>
On 03/18/2015 12:58, Mateusz Guzik wrote:
> On Wed, Mar 18, 2015 at 10:17:22AM -0400, John Baldwin wrote:
>> On Friday, March 13, 2015 06:32:03 AM Mateusz Guzik wrote:
>>> On Thu, Mar 12, 2015 at 06:13:00PM -0500, Alan Cox wrote:
>>>> Below is partial results fro
Below is partial results from a profile of a parallel (-j7) "buildworld" on
a 6-core machine that I did after the introduction of pmap_advise, so this
is not a new profile. The results are sorted by total waiting time and
only the top 20 entries are listed.
max wait_max total wait_to
On Tue, Oct 21, 2014 at 5:03 PM, Alan Cox wrote:
> On Sun, Oct 19, 2014 at 10:30 AM, James R. Van Artsdalen <
> james-freebsd-...@jrv.org> wrote:
>
>> Removing kern.maxfiles from loader.conf still hangs in "kmem arena".
>>
>> I tried using a memst
On Sun, Oct 19, 2014 at 10:30 AM, James R. Van Artsdalen <
james-freebsd-...@jrv.org> wrote:
> Removing kern.maxfiles from loader.conf still hangs in "kmem arena".
>
> I tried using a memstick image of -CURRENT made from the release/
> process and this also hangs in "kmem arena"
>
> An uninvolved
On 08/14/2014 10:47, John Baldwin wrote:
> On Wednesday, August 13, 2014 1:00:22 pm Alan Cox wrote:
>> On Tue, Aug 12, 2014 at 1:09 PM, John Baldwin wrote:
>>
>>> On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
>>>> Hi!
>>>>
>>>
On Tue, Aug 12, 2014 at 1:09 PM, John Baldwin wrote:
> On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
> > Hi!
> >
> >
> > On 16 July 2014 06:29, Konstantin Belousov wrote:
> > > On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote:
> > >> Hi,
> > >> I did some measurem
On Wed, Aug 13, 2014 at 4:58 AM, David Chisnall
wrote:
> On 12 Aug 2014, at 19:09, John Baldwin wrote:
>
> > 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
On 01/19/2014 18:06, Manfred Antar wrote:
> vm_reserv.c starting with revision 25 causes panic on sparc64 (netra T1
> 200)
> version 259998 works
>
> backtrace:
> Starting apache22.
> panic: Bad link elm 0xf8007d4728f8 prev->next != elm
> cpuid = 0
> KDB: enter: panic
> [ thread pid 1965 t
On Jul 21, 2013, at 2:50 PM, Jeremie Le Hen wrote:
> On Sat, Jul 20, 2013 at 08:33:35PM -0700, Alan Cox wrote:
>>
>> On Jul 20, 2013, at 4:22 AM, Jeremie Le Hen wrote:
>>
>>> Hi Edward, Alan,
>>>
>>> I plan to commit the following patch:
>&
On Jul 20, 2013, at 4:22 AM, Jeremie Le Hen wrote:
> Hi Edward, Alan,
>
> I plan to commit the following patch:
> http://people.freebsd.org/~jlh/racct_munlock.diff
>
> This solves the following panic:
>
> panic: racct_sub: freeing 301989888 of resource 5, which is more than
> allocated 73728
On Tue, Jul 16, 2013 at 7:08 AM, Kurt Lidl wrote:
> On Wed, Jun 19, 2013 at 1:32 AM, Chris Torek
>> wrote:
>>
>> In src/sys/amd64/include/vmparam.**h is this handy map:
>>>
>>> * 0x - 0x7fff user map
>>> * 0x8000 - 0x7fff does not exist
On Wed, Jun 19, 2013 at 1:32 AM, Chris Torek wrote:
> In src/sys/amd64/include/vmparam.h is this handy map:
>
> * 0x - 0x7fff user map
> * 0x8000 - 0x7fff does not exist (hole)
> * 0x8000 - 0x804020100fff recursive page
On Wed, Mar 20, 2013 at 12:24 PM, Maksim Yevmenkin wrote:
> hello,
>
> would anyone object to the following small patch?
>
>
Yes, I don't think that we should entirely disable vm_lowmem events or
uma_reclaim() on pass == 0 calls to vm_pageout_scan(). However, I do
think it's reasonable to signi
On 03/08/2013 06:58, Andre Oppermann wrote:
> On 08.03.2013 10:16, Konstantin Belousov wrote:
>> On Thu, Mar 07, 2013 at 06:03:51PM +0100, Andre Oppermann wrote:
>>>pager_map: is used for pager IO to a storage media (disk). Not
>>>pageable. Calculation: MAXPHYS * min(max(nbuf/4, 16), 256).
On 02/01/2013 07:25, Andre Oppermann wrote:
> As an outcome of the recent problems with auto-sizing and auto-tuning of
> the various kernel subsystems and related memory structures I've taken a
> closer look at the whole KVM inner working and initialization process.
>
> I've found the VM and KVM in
On 01/28/2013 08:22, Ian Lepore wrote:
> On Mon, 2013-01-28 at 00:09 -0600, Alan Cox wrote:
>> On Sun, Jan 27, 2013 at 12:11 PM, Ian Lepore wrote:
>>
>>> I ran into a panic while attempting to un-tar a large file on a
>>> DreamPlug (arm-based system) running
On Sun, Jan 27, 2013 at 12:11 PM, Ian Lepore wrote:
> I ran into a panic while attempting to un-tar a large file on a
> DreamPlug (arm-based system) running -current. The source and dest of
> the un-tar is the root filesystem on sdcard, and I get this:
>
> panic: kmem_malloc(4096): kmem_map too
I'll follow up with detailed answers to your questions over the weekend.
For now, I will, however, point out that you've misinterpreted the
tunables. In fact, they say that your kmem map can hold up to 16GB and the
current used space is about 58MB. Like other things, the kmem map is
auto-sized ba
On 11/27/2012 12:43, Andre Oppermann wrote:
> On 27.11.2012 19:27, Alan Cox wrote:
>> On 11/27/2012 12:08, Andre Oppermann wrote:
>>> On 27.11.2012 17:42, Alan Cox wrote:
>>>> On 11/27/2012 09:06, Konstantin Belousov wrote:
>>>>> On Tue, Nov 27, 20
On 11/27/2012 12:08, Andre Oppermann wrote:
> On 27.11.2012 17:42, Alan Cox wrote:
>> On 11/27/2012 09:06, Konstantin Belousov wrote:
>>> On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
>>>> FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
>
On 11/27/2012 09:06, Konstantin Belousov wrote:
> On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
>> FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
>> Fri Nov 23 17:00:40 CET 2012
>> a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64
>>
>> #0 doadump (textdump=-201402233
On 11/16/2012 20:54, Garrett Cooper wrote:
> On Fri, Nov 16, 2012 at 6:24 PM, AN wrote:
>> FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r243165: Fri Nov 16
>> 20:53:48 EST 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64
>>
>> Vbox is broken for me after recent upgrade.
>>
>> # dm
On 10/23/2012 08:14, Konstantin Belousov wrote:
On Tue, Oct 23, 2012 at 02:36:07PM +0200, Svatopluk Kraus wrote:
Hi,
I'm just syncing my ARM pmap code (base on i386 one) with current
i386 pmap code. It looks that sched_pin() is missing after successful
rw_try_wlock() in pmap_protect().
Yes
On 08/27/2012 06:39, Luigi Rizzo wrote:
On Mon, Aug 27, 2012 at 02:42:28AM -0500, Alan Cox wrote:
...
this is dmesg when I add kdb_backtrace() at the start of vm_pageout_oom()
The '... netmap_finalize_obj_allocator... are from my calls to
contigmalloc, each one doing one-page alloca
On 08/26/2012 12:11, Luigi Rizzo wrote:
On Fri, Aug 24, 2012 at 11:56:06AM -0500, Alan Cox wrote:
On 08/24/2012 11:54, Luigi Rizzo wrote:
On Fri, Aug 24, 2012 at 11:12:51AM -0500, Alan Cox wrote:
On 08/24/2012 09:57, Luigi Rizzo wrote:
On Fri, Aug 24, 2012 at 12:43:33AM -0500, Alan Cox wrote
On 08/24/2012 11:54, Luigi Rizzo wrote:
On Fri, Aug 24, 2012 at 11:12:51AM -0500, Alan Cox wrote:
On 08/24/2012 09:57, Luigi Rizzo wrote:
On Fri, Aug 24, 2012 at 12:43:33AM -0500, Alan Cox wrote:
On 08/23/2012 12:45, Luigi Rizzo wrote:
On Thu, Aug 23, 2012 at 12:08:40PM -0500, Alan Cox wrote
On 08/24/2012 09:57, Luigi Rizzo wrote:
On Fri, Aug 24, 2012 at 12:43:33AM -0500, Alan Cox wrote:
On 08/23/2012 12:45, Luigi Rizzo wrote:
On Thu, Aug 23, 2012 at 12:08:40PM -0500, Alan Cox wrote:
...
yes i do see that.
Maybe less aggressive with M_NOWAIT but still kills processes.
Are you
On 08/23/2012 12:45, Luigi Rizzo wrote:
On Thu, Aug 23, 2012 at 12:08:40PM -0500, Alan Cox wrote:
...
yes i do see that.
Maybe less aggressive with M_NOWAIT but still kills processes.
Are you compiling world with MALLOC_PRODUCTION? The latest version of
whatever the default is. But
On 08/23/2012 11:31, Luigi Rizzo wrote:
On Thu, Aug 23, 2012 at 10:48:27AM -0500, Alan Cox wrote:
On Wed, Aug 22, 2012 at 7:01 AM, Luigi Rizzo wrote:
I am trying to make netmap adapt the amount of memory it allocates
to what is available. At its core, it uses contigmalloc() with
small chunks
On Wed, Aug 22, 2012 at 7:01 AM, Luigi Rizzo wrote:
> I am trying to make netmap adapt the amount of memory it allocates
> to what is available. At its core, it uses contigmalloc() with
> small chunks (even down to 1 page) to fetch memory.
>
> Problem is, i notice that before failing, contigmallo
On Sun, Aug 12, 2012 at 5:44 PM, Colin Percival wrote:
> Hi all,
>
> If I'm understanding things correctly, the "maxswzone" value -- set by the
> kern.maxswzone loader tunable or to VM_SWZONE_SIZE_MAX by default -- should
> be approximately 9 MiB per GiB of swap space.
>
> The current default for
On Sat, Jul 21, 2012 at 10:59 AM, Brandon Gooch wrote:
> On Sat, Jul 21, 2012 at 10:11 AM, O. Hartmann
> wrote:
> > On 07/21/12 16:53, O. Hartmann wrote:
> >> On FreeBSD 10.0-CURRENT #1 r238671: Sat Jul 21 16:21:32 CEST 2012
> >> (/usr/src recently update, is at Revision: 238672), VirtualBox see
On Sun, Jul 8, 2012 at 3:16 AM, Jean-Sébastien Pédron
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08.07.2012 05:14, Steve Wills wrote:
> > For what it's worth, I discovered that twm and xterm don't trigger
> > the issue, but konsole and other kde things do, which is what led
>
On 07/08/2012 11:59, Konstantin Belousov wrote:
On Sun, Jul 08, 2012 at 12:57:39PM -0400, Michael Butler wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/08/12 11:18, Michael Butler wrote:
On 07/08/12 10:31, Konstantin Belousov wrote:
Catch it next time ? This should be quite reprod
On Wed, Jul 4, 2012 at 4:57 PM, Steve Wills wrote:
> Setting kern.ipc.shm_use_phys back to 0 (the default) fixed it. I had set
> it to 1 for some reason that I can't recall.
>
>
That shouldn't cause a crash in pmap_enter(). What is line 3587 of pmap.c
in your sources? You mentioned DRM. Are yo
On 06/20/2012 08:25, Konstantin Belousov wrote:
On Wed, Jun 20, 2012 at 08:19:39AM -0400, John Baldwin wrote:
On Tuesday, June 19, 2012 9:30:59 pm Steve Wills wrote:
Hi,
I just got a panic out of my r237195 system. The panic looks like:
Sleeping thread (tid 173153, pid 42034) owns a non-sleep
On Sat, Jun 9, 2012 at 9:26 PM, Garrett Cooper wrote:
>I build out of my UFS-only VM in VMware Fusion from time to time,
> and it looks like there's a large chunk of processes that are swapped out
> when doing two parallel builds:
>
> last pid: 27644; load averages: 2.43, 0.94, 0.98
>
On Wed, May 23, 2012 at 1:05 PM, Maksim Yevmenkin <
maksim.yevmen...@gmail.com> wrote:
> hello,
>
> would anyone object to the following patch?
>
>
No objection. There shouldn't be any controversy here. Your patch is
correct. The existing code in UMA is doing the wrong comparison.
Alan
> ===
On 12/5/2011 4:38 PM, Andriy Gapon wrote:
on 06/12/2011 00:22 Alan Cox said the following:
On 12/5/2011 4:02 PM, Andriy Gapon wrote:
on 05/12/2011 19:58 Alan Cox said the following:
On 12/05/2011 07:56, Andriy Gapon wrote:
Pages should be marked busy only for some special occasions, wired
On 12/5/2011 4:02 PM, Andriy Gapon wrote:
on 05/12/2011 19:58 Alan Cox said the following:
On 12/05/2011 07:56, Andriy Gapon wrote:
Pages should be marked busy only for some special occasions, wired pages are not
normally busy; the correct explanation is quite a bit longer than this, the
On 12/05/2011 07:56, Andriy Gapon wrote:
on 05/12/2011 15:15 Bernhard Froehlich said the following:
On 05.12.2011 14:06, Andriy Gapon wrote:
on 05/12/2011 14:57 Bernhard Froehlich said the following:
On 02.12.2011 12:55, Bernhard Froehlich wrote:
Patch has been send upstream:
https://www.v
On 11/26/2011 06:44, Andriy Gapon wrote:
on 26/11/2011 14:19 Gustau Pérez said the following:
Starting Virtualbox in the console in headless mode allows to see what
happens
and get a dump of the panic.
The messages I got were not the cause problem. The panic I was able to get
shows this:
On 11/14/2011 03:19, Andriy Gapon wrote:
Please disregard my report.
I've tracked the problem to one of the new modules being faulty. But memtest86*
tools still don't detect any issues with it. Apparently FreeBSD is a much more
thorough memory tester than the specialized tools :-)
Apologies for
On 11/06/2011 06:43, Kostik Belousov wrote:
On Sat, Nov 05, 2011 at 03:00:58PM -0500, Alan Cox wrote:
On 11/05/2011 10:15, Kostik Belousov wrote:
On Sat, Nov 05, 2011 at 07:37:48AM -0700, m...@freebsd.org wrote:
On Sat, Nov 5, 2011 at 7:13 AM, Kostik Belousov
wrote:
On Fri, Nov 04, 2011 at
On 11/05/2011 10:15, Kostik Belousov wrote:
On Sat, Nov 05, 2011 at 07:37:48AM -0700, m...@freebsd.org wrote:
On Sat, Nov 5, 2011 at 7:13 AM, Kostik Belousov wrote:
On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote:
Below is the KBI patch after vm_page_bits_t merge is done.
Agai
On 11/04/2011 10:30, Kostik Belousov wrote:
On Fri, Nov 04, 2011 at 10:09:09AM -0500, Alan Cox wrote:
On 11/04/2011 05:08, Kostik Belousov wrote:
On Thu, Nov 03, 2011 at 12:51:10PM -0500, Alan Cox wrote:
I would suggest introducing the vm_page_bits_t change first. If, at the
same time, you
On 11/04/2011 05:08, Kostik Belousov wrote:
On Thu, Nov 03, 2011 at 12:51:10PM -0500, Alan Cox wrote:
On 11/03/2011 08:24, Kostik Belousov wrote:
On Thu, Nov 03, 2011 at 12:40:08AM -0500, Alan Cox wrote:
On 11/02/2011 05:32, Andriy Gapon wrote:
[restored cc: to the original poster]
As Bruce
On 11/03/2011 08:24, Kostik Belousov wrote:
On Thu, Nov 03, 2011 at 12:40:08AM -0500, Alan Cox wrote:
On 11/02/2011 05:32, Andriy Gapon wrote:
[restored cc: to the original poster]
As Bruce Evans has pointed to me privately [I am not sure why privately],
there
is already an example in i386 and
On 11/02/2011 05:32, Andriy Gapon wrote:
[restored cc: to the original poster]
on 02/11/2011 08:10 Benjamin Kaduk said the following:
I am perhaps confused. Last I checked, bsd.kmod.mk caused '-include
opt_global.h' to be passed on the command line. Is the issue just that the
opt_global.h use
On 6/20/2011 11:40 AM, Garrett Cooper wrote:
On Mon, Jun 20, 2011 at 11:37 AM, FreeBSD Tinderbox
wrote:
TB --- 2011-06-20 17:09:28 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-20 17:09:28 - starting HEAD tinderbox run for ia64/ia64
TB --- 2011-06-20 17:09:28 - cleaning t
On 6/20/2011 12:10 PM, m...@freebsd.org wrote:
On Mon, Jun 20, 2011 at 11:40 AM, Garrett Cooper wrote:
On Mon, Jun 20, 2011 at 11:37 AM, FreeBSD Tinderbox
wrote:
TB --- 2011-06-20 17:09:28 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-20 17:09:28 - starting HEAD tinderb
On Mon, May 9, 2011 at 8:45 AM, John Baldwin wrote:
> On Saturday, May 07, 2011 3:16:25 pm Kostik Belousov wrote:
> > On Fri, May 06, 2011 at 04:16:40PM -0400, John Baldwin wrote:
> > > On Friday, May 06, 2011 10:04:28 am Kostik Belousov wrote:
> > > > On Fri, May 06, 2011 at 04:38:00PM +0300, An
On Tue, Dec 28, 2010 at 1:33 PM, Bartosz Stec wrote:
> Hi there.
> Everything was fine with kernel dated 14.12, but now it's impossible to run
> smartd without panic. Smartmontools rebuilded with this release still
> produces panic. Everything else seems working fine.
> core.txt is here:
> http://
John Baldwin wrote:
On Monday, November 22, 2010 8:01:34 pm Alan Cox wrote:
On 11/22/2010 1:47 PM, John Baldwin wrote:
On Monday, November 22, 2010 1:37:45 pm Alan Cox wrote:
On Mon, Nov 22, 2010 at 6:59 AM, John Baldwin wrote:
On Sunday, November 21, 2010 8:05:26
On 11/22/2010 1:47 PM, John Baldwin wrote:
On Monday, November 22, 2010 1:37:45 pm Alan Cox wrote:
On Mon, Nov 22, 2010 at 6:59 AM, John Baldwin wrote:
On Sunday, November 21, 2010 8:05:26 pm Sean Bruno wrote:
Looks like these HP boxes have the capability to do 44 bit memory
addressing if
On Mon, Nov 22, 2010 at 6:59 AM, John Baldwin wrote:
> On Sunday, November 21, 2010 8:05:26 pm Sean Bruno wrote:
> > Looks like these HP boxes have the capability to do 44 bit memory
> > addressing if configured to do so from the BIOS.
> >
> > Is anyone interested in any data from that setting?
>
Sean Bruno wrote:
http://people.freebsd.org/~sbruno/256G_SMAP.png
http://people.freebsd.org/~sbruno/256G_panic1.png
http://people.freebsd.org/~sbruno/256G_panic2.png
Trying to get the HP DL980 online today and I see the following panic on
startup from the installer CD that I created from -CURRE
Andriy Gapon wrote:
on 09/11/2010 10:02 Alan Cox said the following:
The kernel portion of the patch looks correct. If I were to make one stylistic
suggestion, it would be to make the control flow of the outer and inner loops as
similar as possible, that is,
for (...
if ((pdp[i
Julian Elischer wrote:
On 11/9/10 9:04 AM, Bakul Shah wrote:
On Tue, 09 Nov 2010 08:45:14 PST Julian
Elischer wrote:
During the discussion at MeetBSD the question came up as to what the
real
limiting factors were with regard to how much RAM a system could have.
it was put to us that the limi
Andriy Gapon wrote:
So, here is the next version of the patch:
http://people.freebsd.org/~avg/amd64-minidump.4.diff
Changes since the last version:
1. libkvm - try to support both the new and the previous formats/versions of
amd64 minidump. I am not entirely sure about style in which I handled
Paul B Mahol wrote:
On 11/6/10, Jia-Shiun Li wrote:
Hi,
I got a similar panic on amd64. Looking into the source it hit
KASSERT((base & (len - 1))) in pmap_demote_DMAP(). I replaced it with
a printf to see what triggered the assertion and here is the output.
Combined with memcontrol output '
Andriy Gapon wrote:
on 03/11/2010 20:44 Alan Cox said the following:
[snip]
Thank you for the confirmation!
Andriy Gapon wrote:
P.S. is there a macro for extracting frame address from PDPE?
To a lower level page table page or to a 1GB physical page? For the latter, you
can
Please boot your i386 kernel and send me the output from "memcontrol list".
Alan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freeb
Andriy Gapon wrote:
on 01/10/2010 10:43 Andriy Gapon said the following:
The idea. We dump contiguously only pages with PDEs (which means both valid and
invalid PDEs), valid pages with PTEs are dumped the same way as data physical
pages (i.e. via dump_add_page, etc); no fake PTEs for 2MB pag
On Thu, Sep 30, 2010 at 12:37 PM, Andre Oppermann wrote:
> On 30.09.2010 18:37, Andre Oppermann wrote:
>
>> Just for the kick of it I decided to take a closer look at the use of
>> splay trees (inherited from Mach if I read the history correctly) in
>> the FreeBSD VM system suspecting an interest
On 9/29/2010 3:41 PM, Andriy Gapon wrote:
on 27/09/2010 20:54 Andriy Gapon said the following:
It seems that minidump on amd64 is always dumping at least about 1GB of data
regardless of actual memory size and usage and thus can be even larger than
regular dump.
Specifically, I suspect the foll
m...@freebsd.org wrote:
[snip]
I will test this patch out; thanks for the help!
Two questions:
1) How does a thread get moved between CPUs when it's not running? I
see that we change the runqueue for non-running threads that are on a
runqueue. Does the code always check for THREAD_CAN_SCHED w
Dag-Erling Smørgrav wrote:
Alan Cox writes:
Here is what actually puzzles me about these results. With
traditional I/O, even after the optimizations to bsdgrep, the system
time for gnugrep is still less than half that of the optimized
bsdgrep. I haven't looked at the changes, but I
Dimitry Andric wrote:
On 2010-08-17 23:24, Alan Cox wrote:
So normal mmap is ~3% slower, and prefault mmap does not seem to make
any measurable difference. I guess the added complexity is not really
worth it, for now.
Do you know what fraction of this time is being spent in the
On Tue, Aug 17, 2010 at 3:29 PM, Dimitry Andric wrote:
> On 2010-08-17 18:29, Alan Cox wrote:
> > Try it again on a memory resident file with the MAP_PREFAULT_READ option
> > that is provided by this patch:
> >
> > http://www.cs.rice.edu/~alc/MAP_PREFAULT_READ.patch<
On Tue, Aug 17, 2010 at 10:45 AM, Kostik Belousov wrote:
> [Cc: list sanitized]
>
> On Tue, Aug 17, 2010 at 05:28:08PM +0200, Dimitry Andric wrote:
> > On 2010-08-16 10:55, Dag-Erling Sm??rgrav wrote:
> > > Dimitry Andric writes:
> > >> - Uses plain file descriptors instead of struct FILE, since
2010/8/17 Dimitry Andric
> On 2010-08-16 10:55, Dag-Erling Smørgrav wrote:
> > Dimitry Andric writes:
> >> - Uses plain file descriptors instead of struct FILE, since the
> >> buffering is done manually anyway, and it makes it easier to support
> >> gzip and bzip2.
> > It might be worth a sh
On Tue, Aug 10, 2010 at 9:43 AM, Oliver Fromme wrote:
> Hi,
>
> This is i386 -current as of 2010-08-04.
> It was building the toolchain for amd64 when it happened.
> I'll keep the vmcore around, so I can dig more into it
> if someone tells me what to do.
>
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 200
On Wed, Jun 30, 2010 at 11:33 AM, Jeseem S wrote:
> hi,
> I am a newbie on freebsd kernel. Am currently trying to debug a scenario,
> where a custom driver I load uses a lot of static memory and hence lots of
> wired pages.
> The system still has a lot of free memory ( more than 200MB) and a fr
On Sun, Jun 13, 2010 at 8:38 PM, Doug Barton wrote:
> On 06/01/10 08:26, John Baldwin wrote:
>
>>
>> I've asked the driver author if the calls to vm_page_wire() and
>> vm_page_unwire() can simply be removed but have not heard back yet.
>>
>
> Is there any news on this? I have updated to the lates
On Thu, Jun 10, 2010 at 7:16 AM, John Baldwin wrote:
> On Wednesday 09 June 2010 5:27:47 pm Nathaniel W Filardo wrote:
> > Attempting to boot on (2-way SMP; SUN Fire V240) sparc64 a 9.0-CURRENT
> > kernel built on Jun 9 at 14:41, and fully csup'd before building (I don't
> > have the SVN revision
On 5/26/2010 2:56 PM, Ryan Stone wrote:
I'm by no means an expert in this area, but isn't removing the locking
on free a bad thing?
Looking at the code, it seems that vm_page_unwire() only requires the
page to be locked if it is managed. As it was acquired by
contigmalloc, the page should
Kostik Belousov wrote:
On Wed, May 26, 2010 at 11:23:02AM -0500, Alan Cox wrote:
Garrett Cooper wrote:
Just reporting the fact that nvidia-driver 195.22 is horribly
broken between r206173 and r208486 (my machine consistency livelocks
at X11 startup); the latest driver is still
Garrett Cooper wrote:
Just reporting the fact that nvidia-driver 195.22 is horribly
broken between r206173 and r208486 (my machine consistency livelocks
at X11 startup); the latest driver is still broken as well with the
same symptoms. I realize that's a huge revision difference, and I'll
def
Benjamin Kaduk wrote:
On Fri, 14 May 2010, Benjamin Kaduk wrote:
On Fri, 14 May 2010, Alan Cox wrote:
I suspect the following is needed:
Index: vm/vm_page.c
===
--- vm/vm_page.c(revision 207823)
+++ vm/vm_page.c
1 - 100 of 153 matches
Mail list logo
