Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3

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

Re: nvidia-driver build error (last ports, FreeBSD-HEAD)

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

Re: nvidia-driver build error (last ports, FreeBSD-HEAD)

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

Re: nvidia-driver build error (last ports, FreeBSD-HEAD)

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,

Re: emulators/qemu-user-static needs MAP_GUARD support

On 07/05/2017 13:47, Guy Yur wrote: > Hi Alan, > > On 1 July 2017 at 23:07, Alan Cox <alan.l@gmail.com> wrote: >> On Sat, Jul 1, 2017 at 2:46 PM, Guy Yur <guy...@gmail.com> wrote: >>> Hi, >>> >>> I tried to run armv6 /bin/sh in a chroot on

Re: running binary in chroot using qemu-arm-static fails to mmap after r320318

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

Re: Memory modified after free in "MAP ENTRY" zone (vm_map_entry_t->read_ahead)

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

Re: Panic from vesa_configure()

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:

Re: Panic from vesa_configure()

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 <j...@freebsd.org> wrote: >>> On Thursday, January 07, 2016 01:47:32 AM Cy Schubert wrote: >>>> In message >>>> <

Re: Panic from vesa_configure()

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()

Re: SVN r292469 breaks VirtualBox

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:

Re: SVN r292469 breaks VirtualBox

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 <a...@rice.edu> wrote: >> >> On 12/19/2015 19:00, Michael Butler wrote: >>> While

Re: Buf ring cleanups

On Thu, Jul 30, 2015 at 6:34 AM, Zbigniew Bodek z...@semihalf.com 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

Re: Turbulence in head @r282676.

This is fixed in r282706. On Sun, May 10, 2015 at 10:19 AM, David Wolfskill da...@catwhisker.org 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

Re: [patch] deadlock in vm_reserv_reclaim_contig()

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 few

Re: panic: Lock vm object not exclusively locked @ /usr/src/sys/vm/vm_page.c:2637

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: A A On Sun, Apr 05, 2015 at 06:37:58AM

Re: panic: Lock vm object not exclusively locked @ /usr/src/sys/vm/vm_page.c:2637

On 04/05/2015 19:49, Rui Paulo wrote: On Apr 5, 2015, at 13:07, Alan Cox a...@rice.edu 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 Sun, Apr 05, 2015 at 06:37:58AM -0700, David

Re: panic: Lock vm object not exclusively locked @ /usr/src/sys/vm/vm_page.c:2637

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 D Here's

Re: panic: Lock vm object not exclusively locked @ /usr/src/sys/vm/vm_page.c:2637

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 transition to multi-user mode, but A D prior

Re: [PATCH] Convert the VFS cache lock to an rmlock

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 from a profile of a parallel (-j7) buildworld

Re: [PATCH] Convert the VFS cache lock to an rmlock

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

Re: zfs recv hangs in kmem arena

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 server of

Re: zfs recv hangs in kmem arena

On Tue, Oct 21, 2014 at 5:03 PM, Alan Cox alan.l@gmail.com 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 memstick image of -CURRENT made from

Re: PostgreSQL performance on FreeBSD

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 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

Re: PostgreSQL performance on FreeBSD

On Wed, Aug 13, 2014 at 4:58 AM, David Chisnall thera...@freebsd.org wrote: On 12 Aug 2014, at 19:09, John Baldwin j...@freebsd.org wrote: OTOH, I have actually seen junk profiling _improve_ performance in certain cases as it forces promotion of allocated pages to superpages since all

Re: PostgreSQL performance on FreeBSD

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

Re: vm_reserv.c panic on sparc64 current

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 tid 100058

Re: Fix for sys_munlock(2) with racct

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: http://people.freebsd.org/~jlh/racct_munlock.diff This solves

Re: Fix for sys_munlock(2) with racct

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 for

Re: expanding past 1 TB on amd64

On Tue, Jul 16, 2013 at 7:08 AM, Kurt Lidl l...@pix.net wrote: On Wed, Jun 19, 2013 at 1:32 AM, Chris Torek chris.torek at gmail.com wrote: In src/sys/amd64/include/vmparam.**h is this handy map: * 0x - 0x7fff user map * 0x8000 -

Re: expanding past 1 TB on amd64

On Wed, Jun 19, 2013 at 1:32 AM, Chris Torek chris.to...@gmail.com wrote: In src/sys/amd64/include/vmparam.h is this handy map: * 0x - 0x7fff user map * 0x8000 - 0x7fff does not exist (hole) * 0x8000 - 0x804020100fff

Re: [RFC] small VM patch to review

On Wed, Mar 20, 2013 at 12:24 PM, Maksim Yevmenkin e...@freebsd.org 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

Re: Cleanup and untangling of kernel VM initialization

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). It is

Re: Cleanup and untangling of kernel VM initialization

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

Re: Trouble with recent auto-tuning changes

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 i...@freebsd.org 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

Re: Trouble with recent auto-tuning changes

On Sun, Jan 27, 2013 at 12:11 PM, Ian Lepore i...@freebsd.org 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):

Re: kmem_map auto-sizing and size dependencies

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

Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

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=-2014022336) at

Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

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: Fri Nov 23 17:00:40 CET 2012 a...@bbb.ccc

Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

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, 2012 at 12:26:44PM +0100, Andre Oppermann wrote: FreeBSD bbb.ccc

Re: link_elf_obj: symbol vm_page_lock_queues undefined

On 11/16/2012 20:54, Garrett Cooper wrote: On Fri, Nov 16, 2012 at 6:24 PM, AN a...@neu.net 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. #

Re: i386 pmap - missing sched_pin()?

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().

Re: less aggressive contigmalloc ?

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 allocations

Re: less aggressive contigmalloc ?

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

Re: less aggressive contigmalloc ?

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

Re: less aggressive contigmalloc ?

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

Re: less aggressive contigmalloc ?

On Wed, Aug 22, 2012 at 7:01 AM, Luigi Rizzo ri...@iet.unipi.it 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

Re: less aggressive contigmalloc ?

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 Rizzori...@iet.unipi.it wrote: I am trying to make netmap adapt the amount of memory it allocates to what is available. At its core, it uses contigmalloc

Re: less aggressive contigmalloc ?

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

Re: Time to bump default VM_SWZONE_SIZE_MAX?

On Sun, Aug 12, 2012 at 5:44 PM, Colin Percival cperc...@freebsd.orgwrote: 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

Re: kldload: can't load /boot/modules/vboxdrv.ko: Exec format error

On Sat, Jul 21, 2012 at 10:59 AM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Sat, Jul 21, 2012 at 10:11 AM, O. Hartmann ohart...@zedat.fu-berlin.de 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

Re: sleeping thread panic?

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

Re: panic after starting X with r238120

On Sun, Jul 8, 2012 at 3:16 AM, Jean-Sébastien Pédron dumbb...@freebsd.orgwrote: -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

Re: panic after starting X with r238120

On Wed, Jul 4, 2012 at 4:57 PM, Steve Wills swi...@freebsd.org 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

Re: panic with out of memory

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

Re: 10-CURRENT and swap usage

On Sat, Jun 9, 2012 at 9:26 PM, Garrett Cooper yaneg...@gmail.com 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,

Re: RFC: [PATCH] disabling buckets under low memory

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 ===

Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}

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:

Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}

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

Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}

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

Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}

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

Re: problem with 1GB pages?

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

Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]

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 Belousovkostik...@gmail.com wrote: On Fri

Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]

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 Belousovkostik...@gmail.com wrote: On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: Below is the KBI patch after vm_page_bits_t

Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3

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

Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3

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

Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3

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

Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3

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

Re: [head tinderbox] failure on ia64/ia64

On 6/20/2011 12:10 PM, m...@freebsd.org wrote: On Mon, Jun 20, 2011 at 11:40 AM, Garrett Cooperyaneg...@gmail.com wrote: On Mon, Jun 20, 2011 at 11:37 AM, FreeBSD Tinderbox tinder...@freebsd.org wrote: TB --- 2011-06-20 17:09:28 - tinderbox 2.7 running on freebsd-current.sentex.ca TB ---

Re: [head tinderbox] failure on ia64/ia64

On 6/20/2011 11:40 AM, Garrett Cooper wrote: On Mon, Jun 20, 2011 at 11:37 AM, FreeBSD Tinderbox tinder...@freebsd.org 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

Re: dsp mmap change

On Mon, May 9, 2011 at 8:45 AM, John Baldwin j...@freebsd.org 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

Re: r216763 panic while running smartd

On Tue, Dec 28, 2010 at 1:33 PM, Bartosz Stec bartosz.s...@it4pro.plwrote: 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

Re: 40 vs 44 bit memory addressing HP DL580/980

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 Baldwinj...@freebsd.org wrote: On Sunday, November 21

Re: 40 vs 44 bit memory addressing HP DL580/980

On Mon, Nov 22, 2010 at 6:59 AM, John Baldwin j...@freebsd.org 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

Re: 40 vs 44 bit memory addressing HP DL580/980

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 Baldwinj...@freebsd.org 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

Re: 256G Ram Panic

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

Re: minidump size on amd64

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

Re: minidump size on amd64

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

Re: limits to memory on amd64

Julian Elischer wrote: On 11/9/10 9:04 AM, Bakul Shah wrote: On Tue, 09 Nov 2010 08:45:14 PST Julian Elischerjul...@freebsd.org 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

Re: panic: invalid PDPE on recend amd64

Paul B Mahol wrote: On 11/6/10, Jia-Shiun Li jiash...@gmail.com 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

Re: minidump size on amd64

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

Re: panic: invalid PDPE on recend amd64

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

Re: minidump size on amd64

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

Re: Examining the VM splay tree effectiveness

On Thu, Sep 30, 2010 at 12:37 PM, Andre Oppermann an...@freebsd.org 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

Re: minidump size on amd64

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

Re: sched_pin() bug in SCHED_ULE

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

Re: Official request: Please make GNU grep the default

Dag-Erling Smørgrav wrote: Alan Cox a...@cs.rice.edu 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

Re: Official request: Please make GNU grep the default

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

Re: Official request: Please make GNU grep the default

2010/8/17 Dimitry Andric dimi...@andric.com On 2010-08-16 10:55, Dag-Erling Smørgrav wrote: Dimitry Andric dimi...@andric.com 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.

Re: Official request: Please make GNU grep the default

On Tue, Aug 17, 2010 at 10:45 AM, Kostik Belousov kostik...@gmail.comwrote: [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 dimi...@andric.com writes: - Uses plain file descriptors

Re: Official request: Please make GNU grep the default

On Tue, Aug 17, 2010 at 3:29 PM, Dimitry Andric dimi...@andric.com 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.patchhttp

Re: page fault in pmap_remove_all

On Tue, Aug 10, 2010 at 9:43 AM, Oliver Fromme o...@lurza.secnetix.dewrote: 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]

Re: tmpfs use of wired_count

On Wed, Jun 30, 2010 at 11:33 AM, Jeseem S jese...@gmail.com 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

Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and

On Sun, Jun 13, 2010 at 8:38 PM, Doug Barton do...@freebsd.org 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

Re: [sparc64] [panic] mutex vm object not owned

On Thu, Jun 10, 2010 at 7:16 AM, John Baldwin j...@freebsd.org 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

Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and

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

Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and

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

Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and

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

Re: kgdb unuseable with cores on current (for some people)

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

Re: kgdb unuseable with cores on current (for some people)

On 5/14/2010 1:44 AM, Benjamin Kaduk wrote: On Fri, 14 May 2010, Kostik Belousov wrote: On Fri, May 14, 2010 at 12:55:35AM -0400, Benjamin Kaduk wrote: Hi all, As was revealed in a recent thread here [1], several people have been unable to use kgdb on coredumps for the past few months (but

  1   2   >