Inconsistent behavior with dd(1)

2014-08-15 Thread William Orr 
Hey,

I found some inconsistent behavior with dd(1) when it comes to specifying 
arguments in -CURRENT.

 [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null 
count=18446744073709551616
dd: count: Result too large
 [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null 
count=18446744073709551617
dd: count: Result too large
 [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null 
count=18446744073709551615
dd: count cannot be negative
 [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null 
count=-18446744073709551615
1+0 records in
1+0 records out
512 bytes transferred in 0.000373 secs (1373071 bytes/sec)
 [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null count=-1
dd: count cannot be negative

—

Any chance someone has the time and could take a look? 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191263

Thanks,
William Orr

—

Here’s the patch:

Index: bin/dd/args.c
===
--- bin/dd/args.c   (revision 267712)
+++ bin/dd/args.c   (working copy)
@@ -186,46 +186,31 @@
 static void
 f_bs(char *arg)
 {
-   uintmax_t res;
-
-   res = get_num(arg);
-   if (res  1 || res  SSIZE_MAX)
-   errx(1, bs must be between 1 and %jd, (intmax_t)SSIZE_MAX);
-   in.dbsz = out.dbsz = (size_t)res;
+   in.dbsz = out.dbsz = get_num(arg);
+   if (in.dbsz  1 || out.dbsz  1)
+   errx(1, bs must be between 1 and %ju, (uintmax_t)-1);
 }
 
 static void
 f_cbs(char *arg)
 {
-   uintmax_t res;
-
-   res = get_num(arg);
-   if (res  1 || res  SSIZE_MAX)
-   errx(1, cbs must be between 1 and %jd, (intmax_t)SSIZE_MAX);
-   cbsz = (size_t)res;
+   cbsz = get_num(arg);
+   if (cbsz  1)
+   errx(1, cbs must be between 1 and %ju, (uintmax_t)-1);
 }
 
 static void
 f_count(char *arg)
 {
-   intmax_t res;
-
-   res = (intmax_t)get_num(arg);
-   if (res  0)
-   errx(1, count cannot be negative);
-   if (res == 0)
-   cpy_cnt = (uintmax_t)-1;
-   else
-   cpy_cnt = (uintmax_t)res;
+   cpy_cnt = get_num(arg);
 }
 
 static void
 f_files(char *arg)
 {
-
files_cnt = get_num(arg);
if (files_cnt  1)
-   errx(1, files must be between 1 and %jd, (uintmax_t)-1);
+   errx(1, files must be between 1 and %ju, (uintmax_t)-1);
 }
 
 static void
@@ -241,14 +226,10 @@
 static void
 f_ibs(char *arg)
 {
-   uintmax_t res;
-
if (!(ddflags  C_BS)) {
-   res = get_num(arg);
-   if (res  1 || res  SSIZE_MAX)
-   errx(1, ibs must be between 1 and %jd,
-   (intmax_t)SSIZE_MAX);
-   in.dbsz = (size_t)res;
+   in.dbsz = get_num(arg);
+   if (in.dbsz  1)
+   errx(1, ibs must be between 1 and %ju, (uintmax_t)-1);
}
 }
 
@@ -262,14 +243,10 @@
 static void
 f_obs(char *arg)
 {
-   uintmax_t res;
-
if (!(ddflags  C_BS)) {
-   res = get_num(arg);
-   if (res  1 || res  SSIZE_MAX)
-   errx(1, obs must be between 1 and %jd,
-   (intmax_t)SSIZE_MAX);
-   out.dbsz = (size_t)res;
+   out.dbsz = get_num(arg);
+   if (out.dbsz  1)
+   errx(1, obs must be between 1 and %ju, (uintmax_t)-1);
}
 }
 
@@ -378,11 +355,14 @@
uintmax_t num, mult, prevnum;
char *expr;
 
+   if (val[0] == '-')
+   errx(1, %s: cannot be negative, oper);
+
errno = 0;
num = strtouq(val, expr, 0);
if (errno != 0) /* Overflow or underflow. */
err(1, %s, oper);
-   
+
if (expr == val)/* No valid digits. */
errx(1, %s: illegal numeric value, oper);
 
Index: bin/dd/dd.c
===
--- bin/dd/dd.c (revision 267712)
+++ bin/dd/dd.c (working copy)
@@ -284,8 +284,6 @@
 
for (;;) {
switch (cpy_cnt) {
-   case -1:/* count=0 was specified */
-   return;
case 0:
break;
default:




signature.asc
Description: Message signed with OpenPGP using GPGMail

gcc / clang std::locale issue on non-glibc platforms

2014-08-15 Thread Alexander Pyhalov 

Hello.
I just stumped on the following gcc bug - 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15992 (std::locale is not 
working for non-C locales).


It seems to affect all non-glibc platforms (reproducible on FreeBSD and 
illumos). Tried the same test with clang - no difference (as affected 
code is in libstdc++). Simple test case:


$ cat t.cpp
#include locale

int main (int argc, char *argv[])
{
for (int i = 1; i  argc; ++i) {
try {
const std::locale loc (argv [i]);
}
catch (std::exception e) {
printf (exception: %s: %s\n, argv [i], e.what ());
}
}
}

$ g++ -o locale t.cpp   # or clang++ -o locale t.cpp , doesn't matter
 ./locale en_US.UTF-8
exception: en_US.UTF-8: locale::facet::_S_create_c_locale name not valid

--
Best regards,
Alexander Pyhalov,
system administrator of Computer Center of Southern Federal University
___
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: gcc / clang std::locale issue on non-glibc platforms

2014-08-15 Thread Alexander Pyhalov 

On 08/15/2014 12:31, Alexander Pyhalov wrote:

Hello.
I just stumped on the following gcc bug -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15992 (std::locale is not
working for non-C locales).



Related libstdc++ bug - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41495


--
Best regards,
Alexander Pyhalov,
system administrator of Computer Center of Southern Federal University
___
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

ARM LINT kernel build failure

2014-08-15 Thread Bjoern A. Zeeb 
Started recently (within the last day or so).


--
 Kernel build for LINT started on Fri Aug 15 11:08:29 UTC 2014
--
=== LINT
--
 stage 2.3: build tools
--

--
 stage 3.2: building everything
--
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15691: warning: duplicate script for target timer.ln ignored
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15530: warning: using previous script for timer.ln defined here
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15694: warning: duplicate script for target timer.o ignored
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15534: warning: using previous script for timer.o defined here
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15695: warning: duplicate script for target timer.o ignored
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15534: warning: using previous script for timer.o defined here
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15978: warning: duplicate script for target obio.ln ignored
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15859: warning: using previous script for obio.ln defined here
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15981: warning: duplicate script for target obio.o ignored
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15863: warning: using previous script for obio.o defined here
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15982: warning: duplicate script for target obio.o ignored
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15863: warning: using previous script for obio.o defined here
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15985: warning: duplicate script for target obio_space.ln ignored
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15866: warning: using previous script for obio_space.ln defined here
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15988: warning: duplicate script for target obio_space.o ignored
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15870: warning: using previous script for obio_space.o defined here
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15989: warning: duplicate script for target obio_space.o ignored
bmake: /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT/Makefile 
line 15870: warning: using previous script for obio_space.o defined here
bmake: don't know how to make 
/scratch/tmp/bz/head.svn/sys/arm/at91/at91_pinctrl.c (continuing)

bmake: stopped in /storage/head/obj/arm.arm/scratch/tmp/bz/head.svn/sys/LINT
--- buildkernel ---
*** [buildkernel] Error code 2

bmake: stopped in /scratch/tmp/bz/head.svn
--- buildkernel ---
*** [buildkernel] Error code 1

bmake: stopped in /scratch/tmp/bz/head.svn

— 
Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983

___
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: Inconsistent behavior with dd(1)

2014-08-15 Thread Alan Somers 
On Thu, Aug 14, 2014 at 11:55 PM, William Orr w...@worrbase.com wrote:
 Hey,

 I found some inconsistent behavior with dd(1) when it comes to specifying 
 arguments in -CURRENT.

  [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null 
 count=18446744073709551616
 dd: count: Result too large
  [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null 
 count=18446744073709551617
 dd: count: Result too large
  [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null 
 count=18446744073709551615
 dd: count cannot be negative
  [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null 
 count=-18446744073709551615
 1+0 records in
 1+0 records out
 512 bytes transferred in 0.000373 secs (1373071 bytes/sec)
  [ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null count=-1
 dd: count cannot be negative

 —

 Any chance someone has the time and could take a look? 
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191263

 Thanks,
 William Orr

 —


IMHO, this is a bug in strtouq(3), not in dd(1).  Why should it parse
negative numbers at all, when there is stroq(3) for that purpose?  The
standard is clear that it must, though.  Oddly enough, stroq would
probably not accept -18446744073709551615, even though strtouq does.
Specific comments on your patch below:



 Here’s the patch:

 Index: bin/dd/args.c
 ===
 --- bin/dd/args.c   (revision 267712)
 +++ bin/dd/args.c   (working copy)
 @@ -186,46 +186,31 @@
  static void
  f_bs(char *arg)
  {
 -   uintmax_t res;
 -
 -   res = get_num(arg);
 -   if (res  1 || res  SSIZE_MAX)
 -   errx(1, bs must be between 1 and %jd, (intmax_t)SSIZE_MAX);
 -   in.dbsz = out.dbsz = (size_t)res;
 +   in.dbsz = out.dbsz = get_num(arg);
 +   if (in.dbsz  1 || out.dbsz  1)

Why do you need to check both in and out?  Aren't they the same?
Also, you eliminated the check for overflowing SSIZE_MAX.  That's not
ok, because these values get passed to places that expect signed
numbers, for example in dd.c:303.

 +   errx(1, bs must be between 1 and %ju, (uintmax_t)-1);
  }

  static void
  f_cbs(char *arg)
  {
 -   uintmax_t res;
 -
 -   res = get_num(arg);
 -   if (res  1 || res  SSIZE_MAX)
 -   errx(1, cbs must be between 1 and %jd, (intmax_t)SSIZE_MAX);
 -   cbsz = (size_t)res;
 +   cbsz = get_num(arg);
 +   if (cbsz  1)
 +   errx(1, cbs must be between 1 and %ju, (uintmax_t)-1);
  }

Again, you eliminated the check for SSIZE_MAX, but cbsz must be signed.


  static void
  f_count(char *arg)
  {
 -   intmax_t res;
 -
 -   res = (intmax_t)get_num(arg);
 -   if (res  0)
 -   errx(1, count cannot be negative);
 -   if (res == 0)
 -   cpy_cnt = (uintmax_t)-1;

This is a special case.  See dd_in().  I think that eliminating this
special case will have the unintended effect of breaking count=0.

 -   else
 -   cpy_cnt = (uintmax_t)res;
 +   cpy_cnt = get_num(arg);
  }

  static void
  f_files(char *arg)
  {
 -
 files_cnt = get_num(arg);
 if (files_cnt  1)
 -   errx(1, files must be between 1 and %jd, (uintmax_t)-1);
 +   errx(1, files must be between 1 and %ju, (uintmax_t)-1);

Good catch.

  }

  static void
 @@ -241,14 +226,10 @@
  static void
  f_ibs(char *arg)
  {
 -   uintmax_t res;
 -
 if (!(ddflags  C_BS)) {
 -   res = get_num(arg);
 -   if (res  1 || res  SSIZE_MAX)
 -   errx(1, ibs must be between 1 and %jd,
 -   (intmax_t)SSIZE_MAX);
 -   in.dbsz = (size_t)res;
 +   in.dbsz = get_num(arg);
 +   if (in.dbsz  1)
 +   errx(1, ibs must be between 1 and %ju, 
 (uintmax_t)-1);

Again, you eliminated the check for SSIZE_MAX, but dbsz must be signed.

 }
  }

 @@ -262,14 +243,10 @@
  static void
  f_obs(char *arg)
  {
 -   uintmax_t res;
 -
 if (!(ddflags  C_BS)) {
 -   res = get_num(arg);
 -   if (res  1 || res  SSIZE_MAX)
 -   errx(1, obs must be between 1 and %jd,
 -   (intmax_t)SSIZE_MAX);
 -   out.dbsz = (size_t)res;
 +   out.dbsz = get_num(arg);
 +   if (out.dbsz  1)
 +   errx(1, obs must be between 1 and %ju, 
 (uintmax_t)-1);
 }
  }

Again, you eliminated the check for SSIZE_MAX, but dbsz must be signed.


 @@ -378,11 +355,14 @@
 uintmax_t num, mult, prevnum;
 char *expr;

 +   if (val[0] == '-')
 +   errx(1, %s: cannot be negative, oper);
 +

In general, I like this part of the diff.  Every user of get_num
checks for negative values, so why not move the check into get_num
itself?  But you changed it from a numeric check to a text check, and
writing text parsers makes me nervous.  I can't see any problems,
though.

Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?

2014-08-15 Thread Craig Rodrigues 
On Wed, Aug 13, 2014 at 6:34 PM, Russell L. Carter rcar...@pinyon.org wrote:

 I love this idea.  I recently moved back to FreeBSD after 14 years on
 debian, and was shocked at how great poudriere + pkg is for
 maintaining a consistent set of packages for a cluster of systems. (I
 know it's pitiful compared to the cloud, but I've got 3 FreeBSD and 3
 debian-testing atm, and two of those debians are in danger of forced
 religious conversion. :-) The main reason I moved to debian in the
 first place is I was working in high user-space and I needed office
 apps (egads) working consistently and reliably through upgrades, and
 the ports system then was not up to the job.  It is now!  Basically,
 poudriere + pkg is debian apt-file + apt-cache + apt-get + approx with
 the added benefit of site specific, port-specific options.  Maybe like
 arch?

 So I would be very willing to contribute to this project, if that
 makes sense.


Wow, it's great to read about your experience.
We need to get more experiences like yours mentioned online in blogs,
tweets, etc.
so that when people go to www.freebsd.org, or do a web search,
they can see nice stories like yours.

I guess we can move this conversation to the freebsd-doc@ mailing
list, as David Chisnall suggested.

One complaint I have about the FreeBSD project, is that the core
project contributors and developers rely too much on
e-mail for communication.  This certainly works, and I use it too, but
new and casual users getting into FreeBSD
may get lost in the maze of FreeBSD mailing lists.  It would be nice
if more of the core project contributors
used the web forums ( http://forums.freebsd.org ), since stuff like
that shows up nicely in web searches, and it is easier
for newcomers to find stuff, and jump in and contribute to threads,
versus mailing lists.

--
Craig
___
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: r269471 make unusable VT console

2014-08-15 Thread Aleksandr Rybalko 
On Tue, 12 Aug 2014 23:28:07 +0200
Carlos Jacobo Puga Medina c...@fbsd.es wrote:

  I believe it's still broken. There's a related PR at 
  http://bugs.freebsd.org/192452 and, I suspect, 192456. Aleksandr, would 
  you mind reverting this reversion? It seems to have created a lot of 
  problems.
  -Nathan
 
 Yes, I think that ray@ is around here somewhere to fix this :P
 
 Regards,
 -- 
 Carlos Jacobo Puga Medina c...@fbsd.es

Hi guys!

Sorry for delay.
Carlos, can you please share picture of such bad behaviuor?
Looks like this mode almost unused novadays, so modern hardware have problems
in implementations of this mode.

Thanks!

WBW
-- 
Aleksandr Rybalko r...@ddteam.net
___
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: r269471 make unusable VT console

2014-08-15 Thread Adrian Chadd 
keep in mind that the vt_vga code will be used for new VGA bring-up on
hardware that exposes legacy VGA bits and pieces, at least until EFI
booting is guaranteed everywhere. Trying to do development on the
console of something using the current vt_vga in order to bring up
things like an ethernet driver will be .. special.


-a


On 15 August 2014 15:14, Aleksandr Rybalko r...@ddteam.net wrote:
 On Tue, 12 Aug 2014 23:28:07 +0200
 Carlos Jacobo Puga Medina c...@fbsd.es wrote:

  I believe it's still broken. There's a related PR at
  http://bugs.freebsd.org/192452 and, I suspect, 192456. Aleksandr, would
  you mind reverting this reversion? It seems to have created a lot of
  problems.
  -Nathan

 Yes, I think that ray@ is around here somewhere to fix this :P

 Regards,
 --
 Carlos Jacobo Puga Medina c...@fbsd.es

 Hi guys!

 Sorry for delay.
 Carlos, can you please share picture of such bad behaviuor?
 Looks like this mode almost unused novadays, so modern hardware have problems
 in implementations of this mode.

 Thanks!

 WBW
 --
 Aleksandr Rybalko r...@ddteam.net
 ___
 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
___
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: r269471 make unusable VT console

2014-08-15 Thread Nathan Whitehorn 
It also has bad effects on boot time. My desktop takes something like 3 
times as long to boot after r269471. If it can't be fixed quickly, it 
needs to be reverted.

-Nathan

On 08/15/14 15:27, Adrian Chadd wrote:

keep in mind that the vt_vga code will be used for new VGA bring-up on
hardware that exposes legacy VGA bits and pieces, at least until EFI
booting is guaranteed everywhere. Trying to do development on the
console of something using the current vt_vga in order to bring up
things like an ethernet driver will be .. special.


-a


On 15 August 2014 15:14, Aleksandr Rybalko r...@ddteam.net wrote:

On Tue, 12 Aug 2014 23:28:07 +0200
Carlos Jacobo Puga Medina c...@fbsd.es wrote:


I believe it's still broken. There's a related PR at
http://bugs.freebsd.org/192452 and, I suspect, 192456. Aleksandr, would
you mind reverting this reversion? It seems to have created a lot of
problems.
-Nathan

Yes, I think that ray@ is around here somewhere to fix this :P

Regards,
--
Carlos Jacobo Puga Medina c...@fbsd.es

Hi guys!

Sorry for delay.
Carlos, can you please share picture of such bad behaviuor?
Looks like this mode almost unused novadays, so modern hardware have problems
in implementations of this mode.

Thanks!

WBW
--
Aleksandr Rybalko r...@ddteam.net
___
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


___
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 active 0xfffff8002d2ae9f8

2014-08-15 Thread Bryan Drewery 

On 2014-08-13 10:38, Bryan Drewery wrote:

On 6/24/2014 4:28 PM, Craig Rodrigues wrote:

Hi,

I have a system running CURRENT at r266925 from May 31.

While doing some software builds using poudriere, the system
panicked.  Unfortunately this system was not configured with
swap space, so I cannot do a kernel dump.

The system is currently at the ddb prompt.
Here is the backtrace:


Here is the backtrace from ddb:

panic: pmap active 0xf8002d2ae9f8
cpuid = 5
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe183958a7d0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe183958a880
vpanic() at vpanic+0x126/frame 0xfe183958a8c0
kassert_panic() at kassert_panic+0x139/frame 0xfe183958a930
pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe183958aa20
vmspace_exit() at vmspace_exit+0xa1/frame 0xfe183958aa60
exit1() at exit1+0x541/frame 0xfe183958aad0
sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe183958aae0
amd64_syscall() at amd64_syscall+0x25a/frame 0xfe183958abf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe183958abf0
--- syscall (1, FreeBSD ELF64, sys_sys_exit), rip - 0x800b195aa, rsp -
0x7ffe3e8, rbp = 0x7e400
KDB: enter: panic
[ thread pid 94762 tid 101570 ]
Stopped at   kdb_enter+0x3e: movq$0.kdb_why
db


Is this a known problem?
Are there other commands I should type at the ddb prompt?
--
Craig


I have run into this as well on r269147:


panic: pmap active 0xf80035f422f8
cpuid = 10
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe124852b7d0

kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe124852b880
vpanic() at vpanic+0x126/frame 0xfe124852b8c0
kassert_panic() at kassert_panic+0x139/frame 0xfe124852b930
pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe124852ba20
vmspace_exit() at vmspace_exit+0x9c/frame 0xfe124852ba60
exit1() at exit1+0x541/frame 0xfe124852bad0
sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe124852bae0
ia32_syscall() at ia32_syscall+0x270/frame 0xfe124852bbf0
Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe124852bbf0
--- syscall (1, FreeBSD ELF32, sys_sys_exit), rip = 0x297e386f, rsp = 
0xd7ac, rbp = 0xd7b8 ---

KDB: enter: panic
[ thread pid 85335 tid 101517 ]
Stopped at  kdb_enter+0x3e: movq$0,kdb_why
db call doadump

Dump failed. Partition too small.
= 0


Got it again on recent r269950 while building with poudriere:

panic: pmap active 0xf8113c3c6d78
cpuid = 10
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe1248acc7d0

kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1248acc880
vpanic() at vpanic+0x126/frame 0xfe1248acc8c0
kassert_panic() at kassert_panic+0x139/frame 0xfe1248acc930
pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe1248acca20
vmspace_exit() at vmspace_exit+0x9c/frame 0xfe1248acca60
exit1() at exit1+0x541/frame 0xfe1248accad0
sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe1248accae0
amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1248accbf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1248accbf0
--- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x80387fadc, rsp = 
0x7fffd4e8, rbp = 0x7fffd5a0 ---

KDB: enter: panic
[ thread pid 84433 tid 101503 ]
Stopped at  kdb_enter+0x3e: movq$0,kdb_why
db call doadump

Dump failed. Partition too small.
= 0

--
Regards,
Bryan Drewery
___
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