Re: panic: pmap_promote_pde: page table page is out of range in r235646
El día Monday, May 20, 2013 a las 02:29:30PM -0400, John Baldwin escribió: > > panic: pmap_promote_pde: page table page is out of range > > couid = 0 > > KDB: enter: panic > > [ thread pid 1397 tid 100119 ] > > Stopped at kdb_enter+0x3a: movl $0, kdb_why > > db> > > > > which makes it impossible to install the packages on it (xorg, ... etc. > > all compiled on my "master site"; > > > > what can I do? The only diff between the computers real difference > > between the computers is that this 4th one has 2 CPU... > > Is there a chance you have a hardware issue (bad RAM, etc.)? I have update to r250588 and installed around 800 ports (xorg, KDE3, firefox), and no more PANICs anymore. matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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"
tws(4) kernel panic on boot
On migrating one of my servers to -current, I discovered that the tws driver panics on boot; I will follow up with a full backtrace once I have a chance to extract it. In the meantime, there is a PR about a very similar error in twa - 177020. Is it possible those are related, and the same sort of change needs to be made to tws? ~Andreas Turriff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Building current no longer possible on 8.2, worked 7 days ago
On Mon, 2013-05-20 at 23:06:40 +0200, Matthias Andree wrote: > Am 20.05.2013 15:49, schrieb Ulrich Spörlein: > > Hey all, > > > > I'm running the coverity builds/scan on a 8.2 VM, buildworld was fine 7d > > ago, now it's kaput: > > ... > > > This is on src r250825 and the host is running > > FreeBSD scan.freebsd.your.org 8.2-STABLE FreeBSD 8.2-STABLE #2 r223420: Wed > > Jun 22 11:15:56 UTC 2011 > > u...@scan.freebsd.your.org:/usr/obj/usr/src/sys/GENERIC amd64 > > In case you haven't noticed, FreeBSD 8.2 went out of support end of July > 2012, i. e. 10 months ago... Just updated to 8-STABLE and the same build error occurs. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A PRIV_* flag for /dev/mem?
I pointed Robert and Pawel at your discussion on creating a new PRIV_KMEM and adding a check for it in memopen(). I am of the opinion that this is a good idea, but I am hoping that one of Robert or Pawel will comment since they are much more active in this area. Kirk McKusick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fix amd64 ddb hardware watchpoints for SMP
On 5/20/13 6:48 AM, John Baldwin wrote: On Thursday, May 16, 2013 2:41:27 am Konstantin Belousov wrote: The ddb use of hardware watchpoints on the x86 architectures is known to be lacking. There are at least two known problems. One is the improper interaction with the user-mode debuggers which use debug registers. Another is that ddb only loads the debug registers for the watchpoint into the CPU which is executing ddb code, not setting up non-current processors. Not touching the first problem for now, I want to fix the second issue, since as is, hardware watchpoints are useless on SMP. Patch below makes the stopped processors to load the debug registers after resuming from the stop handler, if directed by ddb. Also the patch contains two other commands for ddb which made my exprerience with debugger on amd64 better. The 'show pginfo[/p] addr' command dumps the vm_page_t information, either by vm_page address, or, if the /p modifier is specified, by the physical page address. The 'show phys2dmap addr' command translates physical address into the directly mapped address, which can be accessed from ddb then. This looks fine to me. It would be nice to fix i386 as well to be consistent. I would commit the new DDB commands as a separate patch from the watchpoint fixes. the big test is to add the support in the gdb stub to use these.. :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Building current no longer possible on 8.2, worked 7 days ago
Am 20.05.2013 15:49, schrieb Ulrich Spörlein: > Hey all, > > I'm running the coverity builds/scan on a 8.2 VM, buildworld was fine 7d > ago, now it's kaput: ... > This is on src r250825 and the host is running > FreeBSD scan.freebsd.your.org 8.2-STABLE FreeBSD 8.2-STABLE #2 r223420: Wed > Jun 22 11:15:56 UTC 2011 > u...@scan.freebsd.your.org:/usr/obj/usr/src/sys/GENERIC amd64 In case you haven't noticed, FreeBSD 8.2 went out of support end of July 2012, i. e. 10 months ago... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-HEAD gets stuck on vnode operations
On Tuesday, May 14, 2013 1:15:47 pm Roger Pau Monné wrote: > On 14/05/13 18:31, Konstantin Belousov wrote: > > On Tue, May 14, 2013 at 06:08:45PM +0200, Roger Pau Monn? wrote: > >> On 13/05/13 17:00, Konstantin Belousov wrote: > >>> On Mon, May 13, 2013 at 04:33:04PM +0200, Roger Pau Monn? wrote: > On 13/05/13 13:18, Roger Pau Monn? wrote: > >> > >> Thanks for taking a look, > >> > I would like to explain this a little bit more, the syncer process > doesn't get blocked on the _mtx_trylock_flags_ call, it just continues > looping forever in what seems to be an endless loop around > mnt_vnode_next_active/ffs_sync. Also while in this state there is no > noticeable disk activity, so I'm unsure of what is happening. > >>> How many CPUs does your VM have ? > >> > >> 7 vCPUs, but I've also seen this issue with 4 and 16 vCPUs. > >> > >>> > >>> The loop you describing means that other thread owns the vnode > >>> interlock. Can you track what this thread does ? E.g. look at the > >>> vp->v_interlock.mtx_lock, which is basically a pointer to the struct > >>> thread owning the mutex, clear low bits as needed. Then you can > >>> inspect the thread and get a backtrace. > >> > >> There are no other threads running, only syncer is running on CPU 1 (see > >> ps in previous email). All other CPUs are idle, and as seen from the ps > >> quite a lot of threads are blocked in vnode related operations, either > >> "*Name Cac", "*vnode_fr" or "*vnode in". I've also attached the output > >> of alllocks in the previous email. > > This is not useful. You need to look at the mutex which fails the > > trylock operation in the mnt_vnode_next_active(), see who owns it, > > and then 'unwind' the locking dependencies from there. > > Sorry, now I get it, let's see if I can find the locked vnodes and the > thread that owns them... You can use 'show lock v_interlock>' to find an owning thread and then use 'show sleepchain '. If you are using kgdb on the live system (probably easier) then you can grab my scripts at www.freebsd.org/~jhb/gdb/ (do 'cd /path/to/scripts; source gdb6'). You can then find the offending thread and do 'mtx_owner &vp->v_interlock' and then 'sleepchain ' -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: pmap_promote_pde: page table page is out of range in r235646
On Sunday, May 12, 2013 1:13:45 pm Matthias Apitz wrote: > > Hello, > > I have r235646 in three laptops at home running without any problem, one > is the master site where an USB key was produced to install all others; > as I said all three fine; > > today I installed a 4th one and I'm facing frequent PANIC's all of the > same type: > > panic: pmap_promote_pde: page table page is out of range > couid = 0 > KDB: enter: panic > [ thread pid 1397 tid 100119 ] > Stopped at kdb_enter+0x3a: movl $0, kdb_why > db> > > which makes it impossible to install the packages on it (xorg, ... etc. > all compiled on my "master site"; > > what can I do? The only diff between the computers real difference > between the computers is that this 4th one has 2 CPU... Is there a chance you have a hardware issue (bad RAM, etc.)? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: files disappearing from ls on NFS
On Wednesday, May 15, 2013 4:38:38 am Hartmut Brandt wrote:
> On Wed, 15 May 2013, Rick Macklem wrote:
>
> RM>Well, getdents() basically just calls kern_getdirentries() and it calls
> RM>VOP_READDIR() { which is called nfs_readdir() in the NFS clients }.
> RM>nfs_readdir() calls ncl_bioread() to do the real work of finding the
> RM>buffer cache blocks and copying the data out of them.
> RM>One thing you might check via printf()s is whether the buffer cache
> RM>has the zero'd data in it before it copies it to userland.
>
> I now dump the data just before the call to vn_io_fault_iomove in
> ncl_bioread(). So what I do:
>
> 1. reboot
> 2. login
> 3. ls
>-> I see that it is moving 4 blocks 4k each to the user and they look
> fine
> 4. wait half an hour
> 5. ls
>-> now there is only one block, which contains zeros starting from
> 0x200.
>
> Note that I don't do anything else on that machine during that time.
To be clear, you are still seeing zero'd data in your printfs? Also, it seems
like it is passing the wrong size now? Can you output the various size fields
(b_resid, n, n_direofoffset, uio_offset, and uio_resid)?
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fix amd64 ddb hardware watchpoints for SMP
On Thursday, May 16, 2013 2:41:27 am Konstantin Belousov wrote: > The ddb use of hardware watchpoints on the x86 architectures is known to > be lacking. There are at least two known problems. One is the improper > interaction with the user-mode debuggers which use debug registers. > Another is that ddb only loads the debug registers for the watchpoint > into the CPU which is executing ddb code, not setting up non-current > processors. > > Not touching the first problem for now, I want to fix the second issue, > since as is, hardware watchpoints are useless on SMP. Patch below makes > the stopped processors to load the debug registers after resuming from > the stop handler, if directed by ddb. > > Also the patch contains two other commands for ddb which made my > exprerience with debugger on amd64 better. The 'show pginfo[/p] addr' > command dumps the vm_page_t information, either by vm_page address, or, > if the /p modifier is specified, by the physical page address. The 'show > phys2dmap addr' command translates physical address into the directly > mapped address, which can be accessed from ddb then. This looks fine to me. It would be nice to fix i386 as well to be consistent. I would commit the new DDB commands as a separate patch from the watchpoint fixes. -- 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"
buildworld with WITHOUT_CLANG_IS_CC= ?
Hello, how do I do a buildworld these days with this option set: WITHOUT_CLANG_IS_CC= iow, without clang as default compiler? I fail on amd64 and powerpc64 when it comes to build the 32-bit libs. It fails because it can not find header files like math.h The behaviour started with http://svnweb.freebsd.org/changeset/base/250659 Any ideas how to solve that? TIA, Andreas ___ 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"
Building current no longer possible on 8.2, worked 7 days ago
Hey all, I'm running the coverity builds/scan on a 8.2 VM, buildworld was fine 7d ago, now it's kaput: >>> Building an up-to-date make(1) >>> World build started on Mon May 20 13:43:09 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims -- cd /data/src/freebsd-head; MAKEOBJDIRPREFIX=/usr/obj/data/src/freebsd-head/tmp INSTALL="sh /data/src/freebsd-head/tools/install.sh" PATH=/usr/obj/data/src/freebsd-head/tmp/legacy/usr/sbin:/usr/obj/data/src/freebsd-head/tmp/legacy/usr/bin:/usr/obj/data/src/freebsd-head/tmp/legacy/usr/games:/usr/obj/data/src/freebsd-head/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/data/src/freebsd-head/tmp VERSION="FreeBSD 8.2-STABLE amd64 802508" MAKEFLAGS="-m /data/src/freebsd-head/tools/build/mk -m /data/src/freebsd-head/share/mk" COMPILER_TYPE=gcc /usr/obj/data/src/freebsd-head/make.amd64/make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=802508 SSP_CFLAGS= -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC -DNO_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD legacy ===> tools/build (obj,includes,depend,all,install) /usr/obj/data/src/freebsd-head/tmp/data/src/freebsd-head/tools/build created for /data/src/freebsd-head/tools/build set -e; cd /data/src/freebsd-head/tools/build; /usr/obj/data/src/freebsd-head/make.amd64/make buildincludes; /usr/obj/data/src/freebsd-head/make.amd64/make installincludes rm -f .depend mkdep -f .depend -a -I/data/src/freebsd-head/tools/build/../../contrib/libc-pwcache -I/data/src/freebsd-head/tools/build/../../lib/libc/include -I/data/src/freebsd-head/tools/build/../../contrib/libc-vis -I/data/src/freebsd-head/tools/build/../../lib/libc/include -I/usr/obj/data/src/freebsd-head/tmp/legacy/usr/include -std=gnu99 /data/src/freebsd-head/tools/build/../../contrib/libc-pwcache/pwcache.c /data/src/freebsd-head/tools/build/../../contrib/libc-vis/vis.c cc -O2 -pipe -I/data/src/freebsd-head/tools/build/../../contrib/libc-pwcache -I/data/src/freebsd-head/tools/build/../../lib/libc/include -I/data/src/freebsd-head/tools/build/../../contrib/libc-vis -I/data/src/freebsd-head/tools/build/../../lib/libc/include -std=gnu99 -I/usr/obj/data/src/freebsd-head/tmp/legacy/usr/include -c /data/src/freebsd-head/tools/build/../../contrib/libc-pwcache/pwcache.c -o pwcache.o cc -O2 -pipe -I/data/src/freebsd-head/tools/build/../../contrib/libc-pwcache -I/data/src/freebsd-head/tools/build/../../lib/libc/include -I/data/src/freebsd-head/tools/build/../../contrib/libc-vis -I/data/src/freebsd-head/tools/build/../../lib/libc/include -std=gnu99 -I/usr/obj/data/src/freebsd-head/tmp/legacy/usr/include -c /data/src/freebsd-head/tools/build/../../contrib/libc-vis/vis.c -o vis.o building static egacy library ranlib /data/src/freebsd-head/tools/build/libegacy.a sh /data/src/freebsd-head/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /usr/obj/data/src/freebsd-head/tmp/legacy/usr/lib install: libegacy.a: No such file or directory *** Error code 71 This is on src r250825 and the host is running FreeBSD scan.freebsd.your.org 8.2-STABLE FreeBSD 8.2-STABLE #2 r223420: Wed Jun 22 11:15:56 UTC 2011 u...@scan.freebsd.your.org:/usr/obj/usr/src/sys/GENERIC amd64 src.conf is empty, make.conf just has PERL_VERSION set. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [analyzed] bmake (installed as default make): make: illegal option -- J
On Mon, May 20, 2013 at 01:53:28PM +0400, Boris Samorodov wrote:
> 17.05.2013 23:45, Florent Peterschmitt ??:
> > ...
> > Then install new world, reboot and so:
> >
> > $ cd /usr/src
> > $ make -j4 kernel
> > --- buildkernel ---
> > make: illegal option -- J
> ...
> > Can someone help ?
>
> Seems to be a feature of the CURRENT build infrastructure.
>
> I have got almost two identical systems FreeBSD 10-amd64
> which I update several times a week. One is affected while
> the other is not.
>
> I managed to build/install world/kernel without '-j' option.
> But this did not help to recover '-j' option. Here is my further
> investigation.
> ...
> So, if there is a file /usr/obj/usr/src/make.amd64/make, it is
> launched. And if this make file is of the wrong version, it boils out.
>
OK; generalized a bit to "${MAKEOBJDIRPREFIX}/usr/src/make.`uname -p`/make",
I find that my systems that had been affected as above were (also)
restored to handling -j4 properly once I removed the offending file.
Thank you!
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Taliban: Evil men with guns afraid of truth from a 14-year old girl.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgpsjN1320NmM.pgp
Description: PGP signature
[analyzed] bmake (installed as default make): make: illegal option -- J
17.05.2013 23:45, Florent Peterschmitt пишет:
> Hi,
>
> With the r250749 revision of head, rebuilt world with make -j4
> buildworld, all was fine.
>
> Then install new world, reboot and so:
>
> $ cd /usr/src
> $ make -j4 kernel
> --- buildkernel ---
> make: illegal option -- J
> usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable]
> [-d flags] [-E variable] [-f makefile] [-I directory]
> [-j max_jobs] [-m directory] [-V variable]
> [variable=value] [target ...]
> *** [buildkernel] Error code 2
>
> make: stopped in /usr/src
> 1 error
>
> make: stopped in /usr/src
>
> It's not from bmake itself because if I build something anywhere (like
> bmake itself), -jx works.
>
> I tried to look in Makefile* and a grep -rn "JFLAG" in /usr/share/mk/,
> but I really don't know where and what to search, sorry :(
>
> Can someone help ?
Seems to be a feature of the CURRENT build infrastructure.
I have got almost two identical systems FreeBSD 10-amd64
which I update several times a week. One is affected while
the other is not.
I managed to build/install world/kernel without '-j' option.
But this did not help to recover '-j' option. Here is my further
investigation.
At the affected system I run "make -j 5" under ktrace. Here is the
relevant part of kdump:
-
[...]
38629 sh CALL read(0,0x624100,0x400)
38629 sh GIO fd 0 read 247 bytes
"{ cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `if [ -x
/usr/obj/usr/src/make.amd64/make ]; then echo /usr/obj/usr/src/make.a"
38629 sh RET read 247/0xf7
[...]
38629 sh CALL wait4(0x,0x7fffd5f4,0<>0,0)
38631 sh CALL execve(0x801889778,0x8018898a0,0x8018898e8)
38631 sh NAMI "/usr/obj/usr/src/make.amd64/make"
38631 make RET execve 0
[...]
38631 make CALL write(0x2,0x7fffbe80,0x1a)
38631 make GIO fd 2 wrote 26 bytes
"make: illegal option -- J
"
[...]
-
So, if there is a file /usr/obj/usr/src/make.amd64/make, it is
launched. And if this make file is of the wrong version, it boils out.
The affected system:
-
% uname -a
FreeBSD BB049.int.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #24 r250806:
Sun May 19 15:08:43 SAMT 2013
b...@bb049.int.wart.ru:/usr/obj/usr/src/sys/BB64X amd64
% LANG=C ls -l /usr/obj/usr/src/make.amd64
total 1476
-rwxr-xr-x 1 bsam wheel 751094 May 17 14:52 bmake
-rwxr-xr-x 1 bsam wheel 686618 May 15 23:31 make
drwxr-xr-x 3 bsam wheel 512 Dec 9 12:19 usr
% /usr/obj/usr/src/make.amd64/make -V MAKE_VERSION
10201205300
-
Not affected system:
-
% uname -a
FreeBSD bsam.int.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #22 r250806:
Sun May 19 22:07:39 SAMT 2013
b...@bsam.int.wart.ru:/usr/obj/usr/src/sys/BB64X amd64
% LANG=C ls -l /usr/obj/usr/src/make.amd64
total 1543
-rwxr-xr-x 1 bsam wheel 751094 May 17 14:52 bmake
-rwxr-xr-x 1 bsam wheel 751060 May 19 16:31 make
drwxr-xr-x 3 bsam wheel 3 Jan 5 02:18 usr
% /usr/obj/usr/src/make.amd64/make -V MAKE_VERSION
20130330
-
So, the affected system has and uses the wrong version of
/usr/obj/usr/src/make.amd64/make. And it even is not
overritten while building (at least without -j option).
Sure, if this file is removed, the whole status-quo is restored
(i.e. the build with '-j' option proceeds).
Well, where this behaviuor is expected or not remains a question
I have no answer to.
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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"
