Re: Panic - ffs_valloc: dup alloc

[AN]

On Sat, 10 Aug 2013, Adrian Chadd wrote:


On 10 August 2013 19:19, AN  wrote:

Hi All:

I am having a major problem on current at the moment, and I could really use
some help.  I am at R253966 on amd64, my problem is the machine is panicing
with: ffs_valloc: dup alloc

I have booted into single user mode and run fsck, it reports that it has
fixed the file system but I still am getting the panic.  I did an svn update
to 254204 and tried to buildworld and the machine panics and reboots. If I
try startx the machine reboots with no message on the console.  Please let
me know what info to provide to troubleshoot this. Any help is greatly
appreciated.


Have you run it twice, so it definitely doesn't use the journal?



-adrian



Hi Adrian:

Thanks for replying.  Yes, I rebooted to single user mode and did a full 
fsck _without_ using the journal, it found some problems and fixed them.  I 
rebooted and am now rebuilding world.  It seems to be working now.  If I 
have any more problems I'll report back.  Thanks for the response and 
info.


Cheers!

Andy
___
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 - ffs_valloc: dup alloc

[Adrian Chadd]

On 10 August 2013 19:19, AN  wrote:
> Hi All:
>
> I am having a major problem on current at the moment, and I could really use
> some help.  I am at R253966 on amd64, my problem is the machine is panicing
> with: ffs_valloc: dup alloc
>
> I have booted into single user mode and run fsck, it reports that it has
> fixed the file system but I still am getting the panic.  I did an svn update
> to 254204 and tried to buildworld and the machine panics and reboots. If I
> try startx the machine reboots with no message on the console.  Please let
> me know what info to provide to troubleshoot this. Any help is greatly
> appreciated.

Have you run it twice, so it definitely doesn't use the journal?



-adrian
___
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"

Panic - ffs_valloc: dup alloc

[AN]

Hi All:

I am having a major problem on current at the moment, and I could really 
use some help.  I am at R253966 on amd64, my problem is the machine is 
panicing with: ffs_valloc: dup alloc


I have booted into single user mode and run fsck, it reports that it has 
fixed the file system but I still am getting the panic.  I did an svn 
update to 254204 and tried to buildworld and the machine panics and 
reboots. If I try startx the machine reboots with no message on the 
console.  Please let me know what info to provide to troubleshoot this. 
Any help is greatly appreciated.


Thanks in advance.
___
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: Light humour

[Sam Fourman Jr.]

On Sat, Aug 10, 2013 at 7:07 PM, Sam Fourman Jr.  wrote:
> On Sat, Apr 27, 2013 at 6:31 PM, Paul Webster
>  wrote:
>> Just got this link on IRC, (freenode/##freebsd) was so funny I thought
>> I would see if I could get any of you guys to spit out you're coffee
>> :)
>>
>> http://antibsd.wordpress.com/
>> ___
>
>
> Sorry I am REALLY late to this party, but wow this site made me laugh :)
> I straight up choked on my soda..
> --
>
> Sam Fourman Jr.

he changed the link...
http://aboutthebsds.wordpress.com/


-- 

Sam Fourman Jr.
___
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: Light humour

[Sam Fourman Jr.]

On Sat, Apr 27, 2013 at 6:31 PM, Paul Webster
 wrote:
> Just got this link on IRC, (freenode/##freebsd) was so funny I thought
> I would see if I could get any of you guys to spit out you're coffee
> :)
>
> http://antibsd.wordpress.com/
> ___


Sorry I am REALLY late to this party, but wow this site made me laugh :)
I straight up choked on my soda..
-- 

Sam Fourman Jr.
___
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: CFT: PCI Command Register fixups

[Marius Strobl]

On Fri, Aug 09, 2013 at 09:56:48PM -0600, Scott Long wrote:
> All,
> 
> Subversion rev 250418 affected approximately 63 drivers by making them 
> vulnerable to resource allocation failures on motherboards with buggy BIOSes. 
>  The revision itself is good, but it needs to address these drivers and bring 
> them up to what is, in effect, a modified way for drivers to manage their PCI 
> resources.  If you've been seeing something like the following message since 
> June 24/27, then you need this patch:
> 
> mps0:  port 0xd000-0xd0ff mem 0xfb79c000-0xfb79 irq 19 at 
> device 0.0 on pci4
> mps0: PCI memory window not available
> device_attach: mps0 attach returned 6
> 
> The patch originated from John Baldwin, I merely fixed up a few nits and am 
> passing it around for review and testing.  Please find it here:
> 
> http://people.freebsd.org/~scottl/pci_command_fixes.patch
> 

In mpt_pci.c, there's a style nit/inconsistency regarding the other
drivers touched by the above patch; if after these fixes, a driver
still fiddles with PCIR_COMMAND, it should be just fine to also OR
in PCIM_CMD_BUSMASTEREN as part of that and to not additionally call
pci_enable_busmaster().
Apart from that, the patch looks good to me.

Marius

___
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: FYI: Advanced USB compliance testing tool now in the tree (10-current only)

[Kevin Oberman]

On Fri, Aug 9, 2013 at 1:33 PM, Hans Petter Selasky  wrote:

> Hi,
>
> For those of you that want to make sure your USB mass storage device
> behaves correctly when using FreeBSD, typically for critical applications,
> I've just added an advanced USB testing tool to the FreeBSD source tree. It
> can be used to stress your USB mass storage device in ways that are beyond
> what "bonnie" will do. See tools/tools/usbtest or the following commit:
>
> http://svnweb.freebsd.org/**changeset/base/254159
>
> --HPS


Looks very nice. While it is now only in head, is there a reason it could
not be built and used on a 9.2-BETA system? (I have not tried. Just
wondering if I should.)
-- 
R. Kevin Oberman, Network Engineer
E-mail: rkober...@gmail.com
___
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 on boot with fresh current

[Bryan Drewery]

On 8/10/2013 1:21 PM, Konstantin Belousov wrote:
> On Sat, Aug 10, 2013 at 08:45:47PM +0300, Konstantin Belousov wrote:
>> On Sat, Aug 10, 2013 at 08:44:07PM +0300, Konstantin Belousov wrote:
>>> On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote:
 On 8/10/2013 11:44 AM, Bryan Drewery wrote:
> On 8/10/2013 6:24 AM, Joel Dahl wrote:
>> panic: witness_init: pending locks list is too small, increase
>> WITNESS_PENDLIST
> I also get this. The last stable revision for me was r254150

 r254150 stable, r254171 panic.

 backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg
>>>
>>> So could you point to exact commit which causes panic ?
>> It is r254167, right ?
>>
> So I cannot reproduce it locally.  The problem is that r254167 moved sleepq
> initialization before witness is operational, and witness has a backlog
> of locks initialized before witness init.  The backlog overflown.
> 
> The right fix looks to be just what the panic message told, please try
> this:


Yup this patch fixed it, as stated.

Thank you for looking at this.


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

Re: panic on boot with fresh current

[Adrian Chadd]

Hi,

I can reproduce it locally, purely by booting an unchanged amd64 GENERIC.

Are you testing it against an _unmodified_ GENERIC, on amd64?

If it doesn't panic for you but it does panic for me (and I'll go and
get the svn version once I reboot to the old kernel and test) then
there may be a hidden problem here that needs solving as this could
vary based upon the machine it's happening on.

Thanks,


-adrian
___
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 on boot with fresh current

[Bryan Drewery]

On 8/10/2013 12:45 PM, Konstantin Belousov wrote:
> On Sat, Aug 10, 2013 at 08:44:07PM +0300, Konstantin Belousov wrote:
>> On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote:
>>> On 8/10/2013 11:44 AM, Bryan Drewery wrote:
 On 8/10/2013 6:24 AM, Joel Dahl wrote:
> panic: witness_init: pending locks list is too small, increase
> WITNESS_PENDLIST
 I also get this. The last stable revision for me was r254150
>>>
>>> r254150 stable, r254171 panic.
>>>
>>> backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg
>>
>> So could you point to exact commit which causes panic ?
> It is r254167, right ?
> 

That was my guess based on the stack trace. I will try your patch.

-- 
Regards,
Bryan Drewery
bdrewery@freenode/EFNet
___
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"

Entropy harvesting sysctl error messages as of r254181

[Raphael Kubo da Costa]

After updating -CURRENT from a one or two-month old checkout, I get the
following messages when /etc/rc.d/initrandom is run:

  Entropy harvesting:sysctl: unknown oid 'kern.random.sys.harvest.interrupt': 
No such file or directory
  interruptssysctl: unknown oid 'kern.random.sys.harvest.ethernet': No such 
file or directory
  ethernetsysctl: unknown oid 'kern.random.sys.harvest.point_to_point': No such 
file or directory
  point_to_point kickstart

Is there something fishy I should look for? kern.random.adaptors is set
to "rdrandyarrow", and this is an IvyBridge laptop running amd64.

___
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 on boot with fresh current

[Raphael Kubo da Costa]

Konstantin Belousov  writes:

> The right fix looks to be just what the panic message told, please try
> this:

The patch managed to fix the crash here at least.

___
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: crash with cpucontrol/microcode update : Today's -CURRENT

[Larry Rosenman]

On 2013-08-10 15:02, Konstantin Belousov wrote:


Try this.

diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c
index 742ef0db..4e5abb2 100644
--- a/sys/dev/cpuctl/cpuctl.c
+++ b/sys/dev/cpuctl/cpuctl.c
@@ -346,8 +346,7 @@ update_intel(int cpu, cpuctl_update_args_t *args,
struct thread *td)
else
ret = EEXIST;
 fail:
-   if (ptr != NULL)
-   contigfree(ptr, args->size, M_CPUCTL);
+   free(ptr, M_CPUCTL);
return (ret);
 }

@@ -476,8 +475,7 @@ update_via(int cpu, cpuctl_update_args_t *args,
struct thread *td)
else
ret = 0;
 fail:
-   if (ptr != NULL)
-   contigfree(ptr, args->size, M_CPUCTL);
+   free(ptr, M_CPUCTL);
return (ret);
 }

Fixed it.

# service microcode_update onestart
Updating cpucodes...
/usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl0 
from rev 0x60c to rev 0x60f... done.
/usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl1 
from rev 0x60c to rev 0x60f... done.
/usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl2 
from rev 0x60c to rev 0x60f... done.
/usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl3 
from rev 0x60c to rev 0x60f... done.
/usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl4 
from rev 0x60c to rev 0x60f... done.
/usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl5 
from rev 0x60c to rev 0x60f... done.
/usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl6 
from rev 0x60c to rev 0x60f... done.
/usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl7 
from rev 0x60c to rev 0x60f... done.

Done.
# ^D$

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org
US Mail: 108 Turvey Cove, Hutto, TX 78634-5688
___
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: crash with cpucontrol/microcode update : Today's -CURRENT

[Konstantin Belousov]

On Sat, Aug 10, 2013 at 02:06:10PM -0500, Larry Rosenman wrote:
> I'm getting the following @R254183:
> when I try to run the microcode_update.
> 
> Just started with yesterday's -CURRENT.

> (kgdb) #0  doadump (textdump=) at pcpu.h:236
> #1  0x8051d6f0 in kern_reboot (howto=260)
>  at /usr/src/sys/kern/kern_shutdown.c:447
> #2  0x8051da77 in panic (fmt=)
>  at /usr/src/sys/kern/kern_shutdown.c:754
> #3  0x80780d9a in trap_fatal (frame=,
>  eva=) at /usr/src/sys/amd64/amd64/trap.c:873
> #4  0x80781199 in trap_pfault (frame=0x0, usermode=0)
>  at /usr/src/sys/amd64/amd64/trap.c:731
> #5  0x80780792 in trap (frame=0xff900d55c7b0)
>  at /usr/src/sys/amd64/amd64/trap.c:463
> #6  0x8076ad02 in calltrap ()
>  at /usr/src/sys/amd64/amd64/exception.S:232
> #7  0x80709be9 in vm_page_unwire (m=0x0, activate=0)
>  at /usr/src/sys/vm/vm_page.c:2356
> #8  0x806fb4ed in kmem_unback (object=0x80c57550,
>  addr=, size=4096) at /usr/src/sys/vm/vm_kern.c:404
> #9  0x806fb5a4 in kmem_free (vmem=0x80bd7780,
>  addr=18446741884987129872, size=4096) at /usr/src/sys/vm/vm_kern.c:421
> #10 0x80506597 in contigfree (addr=0x0, size=4048,
>  type=0x812d5ea0) at /usr/src/sys/kern/kern_malloc.c:435
> #11 0x812d5a79 in cpuctl_ioctl (dev=,
>  cmd=, data=0xfe000d2a2f80 "0?c",
>  flags=, td=)
>  at /usr/src/sys/modules/cpuctl/../../dev/cpuctl/cpuctl.c:480
> #12 0x8041962f in devfs_ioctl_f (fp=0xfe001e68cbe0,
>  com=399396, data=0xfe000d2a2f80, cred=,
>  td=0xfe0252ebd490) at /usr/src/sys/fs/devfs/devfs_vnops.c:757
> #13 0x8056b3be in kern_ioctl (td=0xfe0252ebd490,
>  fd=, com=0) at file.h:306
> #14 0x8056b13f in sys_ioctl (td=0xfe0252ebd490,
>  uap=0xff900d55cb80) at /usr/src/sys/kern/sys_generic.c:693
> #15 0x80781697 in amd64_syscall (td=0xfe0252ebd490, traced=0)
>  at subr_syscall.c:134
> #16 0x8076afeb in Xfast_syscall ()
>  at /usr/src/sys/amd64/amd64/exception.S:391

Try this.

diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c
index 742ef0db..4e5abb2 100644
--- a/sys/dev/cpuctl/cpuctl.c
+++ b/sys/dev/cpuctl/cpuctl.c
@@ -346,8 +346,7 @@ update_intel(int cpu, cpuctl_update_args_t *args, struct 
thread *td)
else
ret = EEXIST;
 fail:
-   if (ptr != NULL)
-   contigfree(ptr, args->size, M_CPUCTL);
+   free(ptr, M_CPUCTL);
return (ret);
 }
 
@@ -476,8 +475,7 @@ update_via(int cpu, cpuctl_update_args_t *args, struct 
thread *td)
else
ret = 0;
 fail:
-   if (ptr != NULL)
-   contigfree(ptr, args->size, M_CPUCTL);
+   free(ptr, M_CPUCTL);
return (ret);
 }
 


pgpTGC3OzzH_B.pgp
Description: PGP signature

Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression)

[Glen Barber]

On Sat, Aug 10, 2013 at 02:11:52PM -0400, Glen Barber wrote:
> On Sat, Aug 10, 2013 at 01:09:20PM -0500, Dan Mack wrote:
> > It looks like you are doing the first [! -z '"${svnversion}"' ]
> > before $svnversion is being set.   In the old version, this was
> > being set via:
> > 
> > if [ -x /usr/bin/svnliteversion ] ; then
> > svnversion=/usr/bin/svnliteversion
> > fi
> > 
> > But I'm not sure if that's intentional or not ...
> > 
> 
> Ugh.  No, this was not intentional.  I'll have this fixed shortly.
> 

Fixed in r254184.  The problem is that I was evaluating ${svnversion}
being set before looking for /usr/bin/svnliteversion; however when
_running_ /usr/bin/svnliteversion, it was being run as
/usr/bin/svnversion by mistake.

Thank you for the reports, and Dan, thank you for your help.

Glen



pgpB4p2lnx78G.pgp
Description: PGP signature

Re: panic on boot with fresh current

[Konstantin Belousov]

On Sat, Aug 10, 2013 at 08:45:47PM +0300, Konstantin Belousov wrote:
> On Sat, Aug 10, 2013 at 08:44:07PM +0300, Konstantin Belousov wrote:
> > On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote:
> > > On 8/10/2013 11:44 AM, Bryan Drewery wrote:
> > > > On 8/10/2013 6:24 AM, Joel Dahl wrote:
> > > >> panic: witness_init: pending locks list is too small, increase
> > > >> WITNESS_PENDLIST
> > > > I also get this. The last stable revision for me was r254150
> > > 
> > > r254150 stable, r254171 panic.
> > > 
> > > backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg
> > 
> > So could you point to exact commit which causes panic ?
> It is r254167, right ?
> 
So I cannot reproduce it locally.  The problem is that r254167 moved sleepq
initialization before witness is operational, and witness has a backlog
of locks initialized before witness init.  The backlog overflown.

The right fix looks to be just what the panic message told, please try
this:

diff --git a/sys/kern/subr_witness.c b/sys/kern/subr_witness.c
index 3b4d7a2..37e8cf2 100644
--- a/sys/kern/subr_witness.c
+++ b/sys/kern/subr_witness.c
@@ -135,7 +135,7 @@ __FBSDID("$FreeBSD$");
 #defineWITNESS_COUNT   1024
 #defineWITNESS_CHILDCOUNT  (WITNESS_COUNT * 4)
 #defineWITNESS_HASH_SIZE   251 /* Prime, gives load factor < 2 
*/
-#defineWITNESS_PENDLIST768
+#defineWITNESS_PENDLIST1024
 
 /* Allocate 256 KB of stack data space */
 #defineWITNESS_LO_DATA_COUNT   2048

If this does not help, try to increse PENDLIST even more.  But, sleepq
uses 256 elements, which means that my increase should be enough.


pgplJa4OJUjKh.pgp
Description: PGP signature

Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression)

[Glen Barber]

On Sat, Aug 10, 2013 at 01:09:20PM -0500, Dan Mack wrote:
> It looks like you are doing the first [! -z '"${svnversion}"' ]
> before $svnversion is being set.   In the old version, this was
> being set via:
> 
> if [ -x /usr/bin/svnliteversion ] ; then
> svnversion=/usr/bin/svnliteversion
> fi
> 
> But I'm not sure if that's intentional or not ...
> 

Ugh.  No, this was not intentional.  I'll have this fixed shortly.

Thank you for the report and the investigation.

Glen



pgpuiL2yYxXQL.pgp
Description: PGP signature

Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression)

[Dan Mack]

Here's the before and after looks like FWIW:

'
+ LC_ALL=C
+ export LC_ALL
+ [ ! -r version ]
+ echo 0
+ touch version
+ cat version
+ pwd
+ hostname
+ date
+ v=0 u=root d=/usr/src/sys/conf h=borg.macktronics.com t='Sat Aug 10 
12:59:21 CDT 2013'

+ make -V KERN_IDENT
+ i=''
+ make -V CC
+ grep version
+ cc -v
+ compiler_v='FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 
20130610'

+ [ -x /usr/bin/svnliteversion ]
+ svnversion=/usr/bin/svnliteversion
+ [ ! -z /usr/bin/svnliteversion ]
+ break
+ [ -x /usr/bin/p4 ]
+ [ -x /usr/local/bin/p4 ]
+ [ -d ./../../.git ]
+ [ -n /usr/bin/svnliteversion ]
+ cd ./..
+ /usr/bin/svnliteversion
+ svn=253918
+ svn=' r253918'
+ [ -n '' ]
+ [ -n '' ]
+ cat
+ echo 1

BAD:

'
+ LC_ALL=C
+ export LC_ALL
+ [ ! -r version ]
+ echo 0
+ touch version
+ cat version
+ pwd
+ hostname
+ date
+ v=0 u=root d=/usr/src/sys/conf h=olive.macktronics.com t='Sat Aug 10 
12:58:47 CDT 2013'

+ make -V KERN_IDENT
+ i=''
+ make -V CC
+ grep version
+ cc -v
+ compiler_v='FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 
20130610'

+ [ ! -z '' ]
+ [ -x /usr/bin/svnversion ]
+ [ ! -z '' ]
+ [ -x /usr/local/bin/svnversion ]
+ [ -z '' ]
+ [ -x /usr/bin/svnliteversion ]
+ basename newvers.sh
+ /usr/bin/svnversion newvers.sh
+ [ 127 -eq 0 ]
+ svnversion=''
+ [ -x /usr/bin/p4 ]
+ [ -x /usr/local/bin/p4 ]
+ [ -d ./../../.git ]
+ [ -n '' ]
+ [ -n '' ]
+ [ -n '' ]
+ cat
+ echo 1


It looks like you are doing the first [! -z '"${svnversion}"' ] before 
$svnversion is being set.   In the old version, this was being set via:


if [ -x /usr/bin/svnliteversion ] ; then
svnversion=/usr/bin/svnliteversion
fi

But I'm not sure if that's intentional or not ...

Dan

On Sat, 10 Aug 2013, Dan Mack wrote:

Same problems here ... sometime after 10.0-CURRENT r253918 ... Two other 
systems stopped working and they have a mixture of svn / svnlite version 
combinations:


working system:

#1: ports svn installed at newer version
root@borg:/usr/src # svnversion ; svnversion --version | head -1
253918
svnversion, version 1.8.0 (r1490375)
root@borg:/usr/src # svnliteversion ; svnliteversion --version | head -1
253918
svnversion, version 1.8.1 (r1503906)
root@borg:/usr/src # uname -a
FreeBSD borg.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r253918: Sat 
Aug  3 15:16:58 CDT 2013 r...@borg.example.com:/usr/obj/usr/src/sys/MACKGEN 
amd64


Systems not working:

#2: no ports svn installed
root@olive:/usr/src # uname -a
FreeBSD olive.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #5: Sat Aug 10 
08:30:25 CDT 2013 r...@olive.example.com:/usr/obj/usr/src/sys/MACKGEN amd64 
root@olive:/usr/src # svnversion ; svnversion --version | head -1

svnversion: Command not found.
svnversion: Command not found.
root@olive:/usr/src # svnliteversion ; svnliteversion --version | head -1
254178
svnversion, version 1.8.1 (r1503906)

#3: ports version installed at newer version
root@darkstor:/usr/src # uname -a
FreeBSD darkstor.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #7: Sat Aug 10 
08:35:47 CDT 2013 r...@darkstor.example.com:/usr/obj/usr/src/sys/MACKGEN 
amd64

root@darkstor:/usr/src # svnversion ; svnversion --version | head -1
254178
svnversion, version 1.8.0 (r1490375)
root@darkstor:/usr/src # svnliteversion ; svnliteversion --version | head -1
254178
svnversion, version 1.8.1 (r1503906)

Dan

On Sat, 10 Aug 2013, Lev Serebryakov wrote:


Hello, Glen.
You wrote 10 ??? 2013 ?., 18:13:24:

GB> Hmm.  I suspect r254094 is to blame here, although I did extensive
GB> testing with different svn versions before the commit.  :(
GB> I'll take another look at this, in case I missed an edge case.
It doesn't look like edge case...

Sources in /data/src. It is SVN WC.

# cd /data/src && svnversion
254178M
# cd /data/src && svnliteversion
254178M
#


"host" system is -CURRENT too, already without revision in uname -a output
(!), from Sat Jul 20.

System is built with nanobsd script, but it looks like nanobsd.sh doesn't
do any special here. It sets MAKEOBJDIRPREFIX to /data/obj.nano/gateway.v2
and call:

env TARGET_ARCH=amd64 make -j4 
__MAKE_CONF=/some/path/to/generated/make.conf buildworld


Generated make.conf looks like:
===
XCC=/usr/bin/cc
XCXX=/usr/bin/c++
XCPP=/usr/bin/cpp
COMPILER_TYPE=clang
MALLOC_PRODUCTION=yes
BOOT_COMCONSOLE_SPEED=115200
BOOT_COMCONSOLE_PORT=0x2E8
WITHOUT_ACCT=yes
WITHOUT_ACPI=yes
WITHOUT_AMD=yes
WITHOUT_APM=yes
WITHOUT_ATM=yes
WITHOUT_AUDIT=yes
WITHOUT_AUTHPF=yes
WITHOUT_BIND_DNSSEC=yes
WITHOUT_CALENDAR=yes
WITHOUT_CDDL=yes
WITHOUT_CLANG=yes
WITHOUT_CROSS_COMPILER=yes
WITHOUT_CTM=yes
WITHOUT_DICT=yes
WITHOUT_EXAMPLES=yes
WITHOUT_FLOPPY=yes
WITHOUT_FREEBSD_UPDATE=yes
WITHOUT_GAMES=yes
WITHOUT_GCC=yes
WITHOUT_GCOV=yes
WITHOUT_GDB=yes
WITHOUT_GPIB=yes
WITHOUT_GPIO=yes
WITHOUT_GROFF=yes
WITHOUT_GSSAPI=yes
WITHOUT_HTML=yes
WITHOUT_INFO=yes
WITHOUT_IPFILTER=yes
WITHOUT_IPX=yes
WITHOUT_JAIL=yes
WITHOUT_LEGACY_CONSOLE=yes
WITHOUT_LIB32

Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression)

[Dan Mack]

Same problems here ... sometime after 10.0-CURRENT r253918 ... 
Two other systems stopped working and they have a mixture of svn / 
svnlite version combinations:


working system:

#1: ports svn installed at newer version
root@borg:/usr/src # svnversion ; svnversion --version | head -1
253918
svnversion, version 1.8.0 (r1490375)
root@borg:/usr/src # svnliteversion ; svnliteversion --version | head -1
253918
svnversion, version 1.8.1 (r1503906)
root@borg:/usr/src # uname -a
FreeBSD borg.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r253918: Sat Aug  
3 15:16:58 CDT 2013 r...@borg.example.com:/usr/obj/usr/src/sys/MACKGEN  amd64

Systems not working:

#2: no ports svn installed
root@olive:/usr/src # uname -a
FreeBSD olive.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #5: Sat Aug 10 08:30:25 CDT 2013 r...@olive.example.com:/usr/obj/usr/src/sys/MACKGEN 
amd64 root@olive:/usr/src # svnversion ; svnversion --version | head -1

svnversion: Command not found.
svnversion: Command not found.
root@olive:/usr/src # svnliteversion ; svnliteversion --version | head -1
254178
svnversion, version 1.8.1 (r1503906)

#3: ports version installed at newer version
root@darkstor:/usr/src # uname -a
FreeBSD darkstor.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #7: Sat Aug 10 
08:35:47 CDT 2013 r...@darkstor.example.com:/usr/obj/usr/src/sys/MACKGEN  amd64
root@darkstor:/usr/src # svnversion ; svnversion --version | head -1
254178
svnversion, version 1.8.0 (r1490375)
root@darkstor:/usr/src # svnliteversion ; svnliteversion --version | head -1
254178
svnversion, version 1.8.1 (r1503906)

Dan

On Sat, 10 Aug 2013, Lev Serebryakov wrote:


Hello, Glen.
You wrote 10 ??? 2013 ?., 18:13:24:

GB> Hmm.  I suspect r254094 is to blame here, although I did extensive
GB> testing with different svn versions before the commit.  :(
GB> I'll take another look at this, in case I missed an edge case.
It doesn't look like edge case...

Sources in /data/src. It is SVN WC.

# cd /data/src && svnversion
254178M
# cd /data/src && svnliteversion
254178M
#


"host" system is -CURRENT too, already without revision in uname -a output
(!), from Sat Jul 20.

System is built with nanobsd script, but it looks like nanobsd.sh doesn't
do any special here. It sets MAKEOBJDIRPREFIX to /data/obj.nano/gateway.v2
and call:

env TARGET_ARCH=amd64 make -j4 __MAKE_CONF=/some/path/to/generated/make.conf 
buildworld

Generated make.conf looks like:
===
XCC=/usr/bin/cc
XCXX=/usr/bin/c++
XCPP=/usr/bin/cpp
COMPILER_TYPE=clang
MALLOC_PRODUCTION=yes
BOOT_COMCONSOLE_SPEED=115200
BOOT_COMCONSOLE_PORT=0x2E8
WITHOUT_ACCT=yes
WITHOUT_ACPI=yes
WITHOUT_AMD=yes
WITHOUT_APM=yes
WITHOUT_ATM=yes
WITHOUT_AUDIT=yes
WITHOUT_AUTHPF=yes
WITHOUT_BIND_DNSSEC=yes
WITHOUT_CALENDAR=yes
WITHOUT_CDDL=yes
WITHOUT_CLANG=yes
WITHOUT_CROSS_COMPILER=yes
WITHOUT_CTM=yes
WITHOUT_DICT=yes
WITHOUT_EXAMPLES=yes
WITHOUT_FLOPPY=yes
WITHOUT_FREEBSD_UPDATE=yes
WITHOUT_GAMES=yes
WITHOUT_GCC=yes
WITHOUT_GCOV=yes
WITHOUT_GDB=yes
WITHOUT_GPIB=yes
WITHOUT_GPIO=yes
WITHOUT_GROFF=yes
WITHOUT_GSSAPI=yes
WITHOUT_HTML=yes
WITHOUT_INFO=yes
WITHOUT_IPFILTER=yes
WITHOUT_IPX=yes
WITHOUT_JAIL=yes
WITHOUT_LEGACY_CONSOLE=yes
WITHOUT_LIB32=yes
WITHOUT_LOCALES=yes
WITHOUT_LOCATE=yes
WITHOUT_LPR=yes
WITHOUT_KERBEROS=yes
WITHOUT_KERBEROS_SUPPORT=yes
WITHOUT_MAN=yes
WITHOUT_NCP=yes
WITHOUT_NDIS=yes
WITHOUT_NIS=yes
WITHOUT_NLS=yes
WITHOUT_NLS_CATALOGS=yes
WITHOUT_NS_CACHING=yes
WITHOUT_OBJC=yes
WITHOUT_PC_SYSINSTALL=yes
WITHOUT_PF=yes
WITHOUT_PORTSNAP=yes
WITHOUT_PROFILE=yes
WITHOUT_QUOTAS=yes
WITHOUT_RCMDS=yes
WITHOUT_RCS=yes
WITHOUT_ROUTED=yes
WITHOUT_SHAREDOCS=yes
WITHOUT_SVNLITE=yes
WITHOUT_SYSCONS=yes
WITHOUT_ZFS=yes
SRCCONF=/dev/null
===

--
// Black Lion AKA Lev Serebryakov 

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



dan
--
Dan Mack

___
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 on boot with fresh current

[Konstantin Belousov]

On Sat, Aug 10, 2013 at 08:44:07PM +0300, Konstantin Belousov wrote:
> On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote:
> > On 8/10/2013 11:44 AM, Bryan Drewery wrote:
> > > On 8/10/2013 6:24 AM, Joel Dahl wrote:
> > >> panic: witness_init: pending locks list is too small, increase
> > >> WITNESS_PENDLIST
> > > I also get this. The last stable revision for me was r254150
> > 
> > r254150 stable, r254171 panic.
> > 
> > backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg
> 
> So could you point to exact commit which causes panic ?
It is r254167, right ?



pgpN3VVMpSXEV.pgp
Description: PGP signature

Re: panic on boot with fresh current

[Konstantin Belousov]

On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote:
> On 8/10/2013 11:44 AM, Bryan Drewery wrote:
> > On 8/10/2013 6:24 AM, Joel Dahl wrote:
> >> panic: witness_init: pending locks list is too small, increase
> >> WITNESS_PENDLIST
> > I also get this. The last stable revision for me was r254150
> 
> r254150 stable, r254171 panic.
> 
> backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg

So could you point to exact commit which causes panic ?


pgpci7am3AOaR.pgp
Description: PGP signature

Fun with nvi

[Peter Wemm]

I've been tinkering with the nvi refresh from the GSoC in 2011, aka nvi2.

https://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1
https://github.com/lichray/nvi2

The goal was to update the multibyte handling in nvi-1.79 (the one we
have in our tree) in such a way we could import it.

Anyway.. an early WIP:   http://people.freebsd.org/~peter/nvi2.tgz

peter@overcee[ 9:37AM]~/head/contrib/nvi/catalog-1643> echo $LANG
en_US.UTF-8
peter@overcee[ 9:38AM]~/head/contrib/nvi/catalog-1644> vi -c 'set
fileencoding=GB2312' zh_CN.GB2312.base

.. leads to fun things like:
http://people.freebsd.org/~peter/nvi2-transcoding.png
that's editing the file in GB2312 format, but converting to utf-8 on
the fly for my terminal.

This is with the WITH_ICONV=yes in make.conf.  nvi2 will build without
it but obviously won't be able to work with non-default encoding
methods.

In straight up UTF-8 mode: http://people.freebsd.org/~peter/nvi2-utf8-4.png

How to use the tarball..
1) rm -rf contrib/nvi usr.bin/vi
2) extract tarball into src tree
3) patch -p0 < nvi.diff  (this adds a built-tool to world)

Note that I haven't actually done a buildworld yet. I've just been
building it directly from src/usr.bin/vi with
make obj && make depend && make all && make install
.. to save time.

But you'll need to have WITH_ICONV=yes in make.conf to do the fancy
stuff.  Note that the ports tree is a long way from being
WITH_ICONV=yes safe, so don't do this on an important machine.  An
example of the tweaks to make ports happier:
http://people.freebsd.org/~peter/iconv.diff - that's not complete.
Most of the ports tree was updated to use Mk/Uses/iconv.mk but there's
still some oddballs scattered around in weird places.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.
 ZFS must be the bacon of file systems. "everything's better with ZFS"
___
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 on boot with fresh current

[Bryan Drewery]

On 8/10/2013 11:44 AM, Bryan Drewery wrote:
> On 8/10/2013 6:24 AM, Joel Dahl wrote:
>> panic: witness_init: pending locks list is too small, increase
>> WITNESS_PENDLIST
> I also get this. The last stable revision for me was r254150

r254150 stable, r254171 panic.

backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg


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

Re: panic on boot with fresh current

[Bryan Drewery]

On 8/10/2013 6:24 AM, Joel Dahl wrote:
> Hi,
> 
> I just rebuilt a fresh current on my laptop. It panics on boot with:
> 
> panic: witness_init: pending locks list is too small, increase
> WITNESS_PENDLIST
> 
> I'm in a hurry right now so I can't gather much more info at the moment, but I
> thought I'd mention it.
> 

I also get this. The last stable revision for me was r254150

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

Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression)

[Lev Serebryakov]

Hello, Glen.
You wrote 10 августа 2013 г., 18:13:24:

GB> Hmm.  I suspect r254094 is to blame here, although I did extensive
GB> testing with different svn versions before the commit.  :(
GB> I'll take another look at this, in case I missed an edge case.
 It doesn't look like edge case...

 Sources in /data/src. It is SVN WC.

# cd /data/src && svnversion
254178M
# cd /data/src && svnliteversion
254178M
#


 "host" system is -CURRENT too, already without revision in uname -a output
(!), from Sat Jul 20.

 System is built with nanobsd script, but it looks like nanobsd.sh doesn't
do any special here. It sets MAKEOBJDIRPREFIX to /data/obj.nano/gateway.v2
and call:

env TARGET_ARCH=amd64 make -j4 __MAKE_CONF=/some/path/to/generated/make.conf 
buildworld

Generated make.conf looks like:
===
XCC=/usr/bin/cc
XCXX=/usr/bin/c++
XCPP=/usr/bin/cpp
COMPILER_TYPE=clang
MALLOC_PRODUCTION=yes
BOOT_COMCONSOLE_SPEED=115200
BOOT_COMCONSOLE_PORT=0x2E8
WITHOUT_ACCT=yes
WITHOUT_ACPI=yes
WITHOUT_AMD=yes
WITHOUT_APM=yes
WITHOUT_ATM=yes
WITHOUT_AUDIT=yes
WITHOUT_AUTHPF=yes
WITHOUT_BIND_DNSSEC=yes
WITHOUT_CALENDAR=yes
WITHOUT_CDDL=yes
WITHOUT_CLANG=yes
WITHOUT_CROSS_COMPILER=yes
WITHOUT_CTM=yes
WITHOUT_DICT=yes
WITHOUT_EXAMPLES=yes
WITHOUT_FLOPPY=yes
WITHOUT_FREEBSD_UPDATE=yes
WITHOUT_GAMES=yes
WITHOUT_GCC=yes
WITHOUT_GCOV=yes
WITHOUT_GDB=yes
WITHOUT_GPIB=yes
WITHOUT_GPIO=yes
WITHOUT_GROFF=yes
WITHOUT_GSSAPI=yes
WITHOUT_HTML=yes
WITHOUT_INFO=yes
WITHOUT_IPFILTER=yes
WITHOUT_IPX=yes
WITHOUT_JAIL=yes
WITHOUT_LEGACY_CONSOLE=yes
WITHOUT_LIB32=yes
WITHOUT_LOCALES=yes
WITHOUT_LOCATE=yes
WITHOUT_LPR=yes
WITHOUT_KERBEROS=yes
WITHOUT_KERBEROS_SUPPORT=yes
WITHOUT_MAN=yes
WITHOUT_NCP=yes
WITHOUT_NDIS=yes
WITHOUT_NIS=yes
WITHOUT_NLS=yes
WITHOUT_NLS_CATALOGS=yes
WITHOUT_NS_CACHING=yes
WITHOUT_OBJC=yes
WITHOUT_PC_SYSINSTALL=yes
WITHOUT_PF=yes
WITHOUT_PORTSNAP=yes
WITHOUT_PROFILE=yes
WITHOUT_QUOTAS=yes
WITHOUT_RCMDS=yes
WITHOUT_RCS=yes
WITHOUT_ROUTED=yes
WITHOUT_SHAREDOCS=yes
WITHOUT_SVNLITE=yes
WITHOUT_SYSCONS=yes
WITHOUT_ZFS=yes
SRCCONF=/dev/null
===

-- 
// Black Lion AKA Lev Serebryakov 

___
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: loader don't load loader.conf if device.hints has errors

[Lev Serebryakov]

Hello, Lev.
You wrote 10 августа 2013 г., 15:01:57:

LS> Hello, Current.

LS> I've make simple mistake (DOS-style EOL) in /boot/device.hints and
LS> /boot/loader.conf was skipped too with strange (device.hints-related)
LS> message:

LS> FreeBSD/x86 bootstrap loader, Revision 1.1
LS> (r...@fbsd-c-64.vm.home.serebryakov.spb.ru, Sat Aug 10 14:02:41 MSK 2013)
LS> Loading /boot/defaults/loader.conf
LS> Warning: syntax error on file /boot/device.hints
LS> hint.uart.0.flags="0x00"
LS> ^
LS> Warning: syntax error on file /boot/loader.conf
LS> hint.uart.0.flags="0x00"
LS> ^
LS> /boot/kernel/kernel text=0x5dfed8 data=0x69078+0xd6b10 
syms=[0x8+0x9cd50+0x8+0x930ab]
 Also, loader doesn't say anything about reading "/boot/device.hints" and
 "/boot/loader.conf", but it reads them for sure:


FreeBSD/x86 bootstrap loader, Revision 1.1
(r...@fbsd-c-64.vm.home.serebryakov.spb.ru, Sat Aug 10 18:35:18 MSK 2013)
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0x5e5fb0 data=0x69cf8+0xd6c10 
syms=[0x8+0x9db48+0x8+0x93be1]
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
GDB: no debug ports present

-- 
// Black Lion AKA Lev Serebryakov 

___
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: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression)

[Glen Barber]

Hmm.  I suspect r254094 is to blame here, although I did extensive
testing with different svn versions before the commit.  :(

I'll take another look at this, in case I missed an edge case.

Glen

On Sat, Aug 10, 2013 at 07:03:29AM -0700, Adrian Chadd wrote:
> Try running the svnlite version of svn upgrade.
> 
> (svnlite upgrade)
> 
> 
> 
> -adrian
> 
> On 10 August 2013 07:02, Lev Serebryakov  wrote:
> > Hello, Freebsd-current.
> > You wrote 10 августа 2013 г., 15:18:46:
> >
> > LS>>  Latest revisions of -CURRENT built with "nanobsd" script haven't 
> > revision
> > LS>>  in "uname -a" output:
> > LS>> FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD
> > LS>> 10.0-CURRENT #0: Sat Aug 10 14:17:32 MSK 2013
> > LS>> 
> > r...@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v2/data/src/sys/D2500CC
> >  amd64
> > LS>>  System was built from "/data/src" directory, which IS subversion 
> > working
> > LS>> copy and `svn' and `svnversion' PRESENTS in $PATH.
> > LS>  Ok, problem is, that "svnliteversion" presents too, but WC version is 
> > old
> > LS> one (for 1.7.x). I'm not sure, is this bug worth fixing.
> >  Nope, upgrading working copy doesn't help :(((
> >
> > --
> > // Black Lion AKA Lev Serebryakov 
> >
> > ___
> > 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"


pgpjmgC96mkNb.pgp
Description: PGP signature

Re: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression)

[Adrian Chadd]

Try running the svnlite version of svn upgrade.

(svnlite upgrade)



-adrian

On 10 August 2013 07:02, Lev Serebryakov  wrote:
> Hello, Freebsd-current.
> You wrote 10 августа 2013 г., 15:18:46:
>
> LS>>  Latest revisions of -CURRENT built with "nanobsd" script haven't 
> revision
> LS>>  in "uname -a" output:
> LS>> FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD
> LS>> 10.0-CURRENT #0: Sat Aug 10 14:17:32 MSK 2013
> LS>> 
> r...@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v2/data/src/sys/D2500CC
>  amd64
> LS>>  System was built from "/data/src" directory, which IS subversion working
> LS>> copy and `svn' and `svnversion' PRESENTS in $PATH.
> LS>  Ok, problem is, that "svnliteversion" presents too, but WC version is old
> LS> one (for 1.7.x). I'm not sure, is this bug worth fixing.
>  Nope, upgrading working copy doesn't help :(((
>
> --
> // Black Lion AKA Lev Serebryakov 
>
> ___
> 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: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression)

[Lev Serebryakov]

Hello, Freebsd-current.
You wrote 10 августа 2013 г., 15:18:46:

LS>>  Latest revisions of -CURRENT built with "nanobsd" script haven't revision
LS>>  in "uname -a" output:
LS>> FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD
LS>> 10.0-CURRENT #0: Sat Aug 10 14:17:32 MSK 2013
LS>> 
r...@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v2/data/src/sys/D2500CC
 amd64
LS>>  System was built from "/data/src" directory, which IS subversion working
LS>> copy and `svn' and `svnversion' PRESENTS in $PATH.
LS>  Ok, problem is, that "svnliteversion" presents too, but WC version is old
LS> one (for 1.7.x). I'm not sure, is this bug worth fixing.
 Nope, upgrading working copy doesn't help :(((

-- 
// Black Lion AKA Lev Serebryakov 

___
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: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[O. Hartmann]

On Sat, 10 Aug 2013 15:39:48 +0200
Gary Jennejohn  wrote:

> On Sat, 10 Aug 2013 14:59:22 +0200
> "O. Hartmann"  wrote:
> 
> > On Sat, 10 Aug 2013 11:31:19 +0200
> > Gary Jennejohn  wrote:
> > 
> > > On Sat, 10 Aug 2013 11:10:40 +0200
> > > Rainer Hurling  wrote:
> > > 
> > > > Yes, I can confirm, that it builds, installs and runs fine for
> > > > me.
> > > > 
> > > > The patch should be placed as
> > > > x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it?
> > > > 
> > > > Many thanks for this work.
> > > > 
> > > 
> > > Thanks for testing.
> > > 
> > > Yes, putting the patch into files/ with that name works also and
> > > is much simpler than the steps I outlined.
> > > 
> > 
> > 
> > Placing the patch in files as recommended here doesn't play well
> > with the obvious intention of the REINPLACE command:
> > 
> > the patch only applies to 319.25.
> > 
> > I use the cutting edge 325.15. The patch doesn't apply since some
> > lines shifted - here comes the tricky REINPLACE part of the
> > Makefile in place.
> > 
> > I simply adapted your patches discussed and introduced here and
> > "adapted" the REINPLACE statements/pattern around line 160 in the
> > toplevel Makefile of port x11/nvidia-driver.
> > 
> > Find the patch attached - I forgot to raise PORTREVISION=1.
> > 
> > I'm now sending this email from the prior crashing box with the
> > patch discussed applied via the Makefile to 325.15.
> > 
> > Thanks a lot for the fast help.
> > 
> 
> Yes, this is a better approach.  I made my patch before realizing
> that the REINPLACE_CMD was the source of the errors.
> 
> Any real advantage to using 325.15?

Well, nvidia claims they have fixed bugs and it is the successor in
line after 319.25. It is stable, it is the newest, it is so far nice :-)

> 
> You should submit a PR with this patch.
> 

Well, I do. I thought it isn't my honour since I simply made a profit
from the labor of others here and I simply picked up crumps.

Well, I added a followup to port/181144.

Oliver



signature.asc
Description: PGP signature

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Gary Jennejohn]

On Sat, 10 Aug 2013 14:59:22 +0200
"O. Hartmann"  wrote:

> On Sat, 10 Aug 2013 11:31:19 +0200
> Gary Jennejohn  wrote:
> 
> > On Sat, 10 Aug 2013 11:10:40 +0200
> > Rainer Hurling  wrote:
> > 
> > > Yes, I can confirm, that it builds, installs and runs fine for me.
> > > 
> > > The patch should be placed as
> > > x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it?
> > > 
> > > Many thanks for this work.
> > > 
> > 
> > Thanks for testing.
> > 
> > Yes, putting the patch into files/ with that name works also and
> > is much simpler than the steps I outlined.
> > 
> 
> 
> Placing the patch in files as recommended here doesn't play well with
> the obvious intention of the REINPLACE command:
> 
> the patch only applies to 319.25.
> 
> I use the cutting edge 325.15. The patch doesn't apply since some lines
> shifted - here comes the tricky REINPLACE part of the Makefile in place.
> 
> I simply adapted your patches discussed and introduced here and
> "adapted" the REINPLACE statements/pattern around line 160 in the
> toplevel Makefile of port x11/nvidia-driver.
> 
> Find the patch attached - I forgot to raise PORTREVISION=1.
> 
> I'm now sending this email from the prior crashing box with the patch
> discussed applied via the Makefile to 325.15.
> 
> Thanks a lot for the fast help.
> 

Yes, this is a better approach.  I made my patch before realizing
that the REINPLACE_CMD was the source of the errors.

Any real advantage to using 325.15?

You should submit a PR with this patch.

-- 
Gary Jennejohn
___
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: Problems with usb bluetooth device

[Lars Engels]

On Sat, Mar 28, 2009 at 11:00:32AM +0100, Hans Petter Selasky wrote:
> On Saturday 28 March 2009, Lars Engels wrote:
> > Hi all,
> >
> > yesterday I bought a shiny new hama usb bluetooth dongle but I am having
> > some problems using it:
> >
> > before loading ng_ubt:
> >   usb2_alloc_device:1480: set address 2 failed (ignored)
> >   usb2_alloc_device:1516: getting device descriptor at addr 2 failed!
> >   usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored)
> >   usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed!
> >   usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored)
> >   usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed!
> >   ugen0.2: <> at usbus0 (disconnected)
> > after loading ng_ubt:
> >   uhub_reattach_port:413: could not allocate new device!
> >   ubt0:  > 2.00/1.00, addr 2> on usbus2 ^^
> >   internal bluetooth device
> >   WARNING: attempt to net_add_domain(bluetooth) after domainfinalize()
> >   WARNING: attempt to net_add_domain(netgraph) after domainfinalize()
> >   ugen0.2:  at usbus0
> >   ubt1:  > 2.00/48.39, addr 2> on usbus0 ubt1: ubt_bulk_read_callback:837: bulk-in
> > transfer failed: USB_ERR_STALLED ubt1: ubt_intr_read_callback:741:
> > interrupt transfer failed: USB_ERR_STALLED ubt1: at uhub0, port 1, addr 2
> > (disconnected)
> >   ugen0.2:  at usbus0 (disconnected)
> > device re-inserted:
> >   usb2_alloc_device:1480: set address 2 failed (ignored)
> >   usb2_alloc_device:1516: getting device descriptor at addr 2 failed!
> >   usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored)
> >   usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed!
> >   usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored)
> >   usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed!
> >   ugen0.2: <> at usbus0 (disconnected)
> >   uhub_reattach_port:413: could not allocate new device!
> >
> > So the device is no longer recognized after I re-connect it. usbconfig does
> > not show it: ugen0.1:  at usbus0, cfg=0 md=HOST
> > spd=FULL (12Mbps) pwr=ON ugen1.1:  at usbus1, cfg=0
> > md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1:  at usbus2,
> > cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1:  at
> > usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1:  > Intel> at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen2.2:  > Bluetooth 2.0 plus EDR Broadcom Corp> at usbus2, cfg=0 md=HOST spd=FULL
> > (12Mbps
> > pwr=ON
> >
> > It only lists the internal device...
> >
> > My CURRENT was compiled two days ago, so I should be up-to-date.
> 
> Does it work when you use an external USB HUB?
> 
> Does this device have some kind of autoinstall on it?
> 
> You could try enabling uhci/ehci debugging.
> sysctl hw.usb2.uhci.debug = 15
> 
> Then we would know the exact cause of the error.

Just for your info:
Aug 10 15:21:45 milhouse kernel: ubt1:  on usbus3
Aug 10 15:21:45 milhouse devd: Executing '/etc/rc.d/bluetooth quietstart ubt1'


After 4 years, the device now works without an external hub. ;-))

Lars



pgptpC7GOmMki.pgp
Description: PGP signature

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[O. Hartmann]

On Sat, 10 Aug 2013 11:31:19 +0200
Gary Jennejohn  wrote:

> On Sat, 10 Aug 2013 11:10:40 +0200
> Rainer Hurling  wrote:
> 
> > Yes, I can confirm, that it builds, installs and runs fine for me.
> > 
> > The patch should be placed as
> > x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it?
> > 
> > Many thanks for this work.
> > 
> 
> Thanks for testing.
> 
> Yes, putting the patch into files/ with that name works also and
> is much simpler than the steps I outlined.
> 


Placing the patch in files as recommended here doesn't play well with
the obvious intention of the REINPLACE command:

the patch only applies to 319.25.

I use the cutting edge 325.15. The patch doesn't apply since some lines
shifted - here comes the tricky REINPLACE part of the Makefile in place.

I simply adapted your patches discussed and introduced here and
"adapted" the REINPLACE statements/pattern around line 160 in the
toplevel Makefile of port x11/nvidia-driver.

Find the patch attached - I forgot to raise PORTREVISION=1.

I'm now sending this email from the prior crashing box with the patch
discussed applied via the Makefile to 325.15.

Thanks a lot for the fast help.

Regards,
Oliver 
diff -Nur nvidia-driver.orig/Makefile nvidia-driver/Makefile
--- nvidia-driver.orig/Makefile 2013-08-10 14:46:08.0 +0200
+++ nvidia-driver/Makefile  2013-08-10 14:41:52.0 +0200
@@ -158,8 +158,8 @@
 .endif
 # Catch up with KVA space allocation API changes in recent -CURRENT
 .if ${OSVERSION} > 140
-   ${REINPLACE_CMD} -e 's/kmem_free(kernel_map,/kva_free(/ ; \
-   /kmem_alloc_contig/s/map/arena/' ${WRKSRC}/src/nvidia_subr.c
+   ${REINPLACE_CMD} -e 's/kmem_free(kernel_map,/kmem_free(kmem_arena,/ ; \
+   /kmem_alloc_contig/s/kernel_map/kmem_arena/' 
${WRKSRC}/src/nvidia_subr.c
 .endif
 # Process OPTIONS
 .if ${PORT_OPTIONS:MFREEBSD_AGP}


signature.asc
Description: PGP signature

panic on boot with fresh current

[Joel Dahl]

Hi,

I just rebuilt a fresh current on my laptop. It panics on boot with:

panic: witness_init: pending locks list is too small, increase
WITNESS_PENDLIST

I'm in a hurry right now so I can't gather much more info at the moment, but I
thought I'd mention it.

-- 
Joel
___
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: nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression)

[Lev Serebryakov]

Hello, Lev.
You wrote 10 августа 2013 г., 15:08:49:

LS>  Latest revisions of -CURRENT built with "nanobsd" script haven't revision
LS>  in "uname -a" output:

LS> FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD
LS> 10.0-CURRENT #0: Sat Aug 10 14:17:32 MSK 2013
LS> 
r...@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v2/data/src/sys/D2500CC
 amd64

LS>  System was built from "/data/src" directory, which IS subversion working
LS> copy and `svn' and `svnversion' PRESENTS in $PATH.
 Ok, problem is, that "svnliteversion" presents too, but WC version is old
one (for 1.7.x). I'm not sure, is this bug worth fixing.

-- 
// Black Lion AKA Lev Serebryakov 

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

nanobsd-built system doesn't have SVN revision in "uname" (and it looks like regression)

[Lev Serebryakov]

Hello, Freebsd-embedded.

 Latest revisions of -CURRENT built with "nanobsd" script haven't revision
 in "uname -a" output:

FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #0: 
Sat Aug 10 14:17:32 MSK 2013 
r...@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v2/data/src/sys/D2500CC
  amd64

 System was built from "/data/src" directory, which IS subversion working
copy and `svn' and `svnversion' PRESENTS in $PATH.

 It is r254177, really.

 I don't remeber exactly, but I have feeling, that earlier revisions didn't
have this problem.

-- 
// Black Lion AKA Lev Serebryakov 

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

loader don't load loader.conf if device.hints has errors

[Lev Serebryakov]

Hello, Current.

I've make simple mistake (DOS-style EOL) in /boot/device.hints and
/boot/loader.conf was skipped too with strange (device.hints-related)
message:

FreeBSD/x86 bootstrap loader, Revision 1.1
(r...@fbsd-c-64.vm.home.serebryakov.spb.ru, Sat Aug 10 14:02:41 MSK 2013)
Loading /boot/defaults/loader.conf
Warning: syntax error on file /boot/device.hints
hint.uart.0.flags="0x00"
^
Warning: syntax error on file /boot/loader.conf
hint.uart.0.flags="0x00"
^
/boot/kernel/kernel text=0x5dfed8 data=0x69078+0xd6b10 
syms=[0x8+0x9cd50+0x8+0x930ab]

Is it Ok?

-- 
// Black Lion AKA Lev Serebryakov 

___
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: Fixing X220 Video The Right Way

[matt]

Not sure that it did :)

I tried it once early on, and it concerned me enough I never tried
again. It was clearly in a violently erroneous state!

At one point, X *could* resume the display. This makes me think the
problem is solved via the graphics "chip" state, but it could be an
acpi thing.

I can't remember if I ever tried to startx after the resume on the
"blind" console.

Matt

On 08/09/13 23:00, Adrian Chadd wrote:
> when did it start working?
> 
> 
> -adrian
> 
> On 9 August 2013 20:10, matt  wrote:
>> hw.acpi.reset_video used to send this machine X220 into a reboot
>> loop, with flashing thinklight. Interesting that it no longer
>> causes this problem. I kind of paused since the trackpad sucks so
>> much in X.
>> 
>> I think since ssh still works, that just the display or graphics
>> port is off.
>> 
>> It may be worth trying to do some acpi_calls via ssh to try to
>> hack the display back on...
>> 
>> Matt
>> 
>> On 08/09/13 08:57, John Baldwin wrote:
>>> On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote:
 Hi!
 
 Hm, resurrecting this thread, I'll try this on my X230
 tomorrow and see if it makes the (non-xorg, console only)
 video work on resume.
 
 If it does, what will it take to automatically determine
 that this kind of work-around is needed?
>>> 
>>> 
>>> This does not affect suspend/resume.  It only fixes LCD
>>> brightness handling via acpi_video(4).
>>> 
>> 
> 

___
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: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Gary Jennejohn]

On Sat, 10 Aug 2013 11:10:40 +0200
Rainer Hurling  wrote:

> Yes, I can confirm, that it builds, installs and runs fine for me.
> 
> The patch should be placed as
> x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it?
> 
> Many thanks for this work.
> 

Thanks for testing.

Yes, putting the patch into files/ with that name works also and
is much simpler than the steps I outlined.

-- 
Gary Jennejohn
___
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: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Rainer Hurling]

Am 10.08.2013 10:37, schrieb Gary Jennejohn:
> On Fri, 9 Aug 2013 10:12:37 -0700
> David Wolfskill  wrote:
> 
>> On Fri, Aug 09, 2013 at 07:32:51AM +0200, O. Hartmann wrote:
>>> ...
> On 8 August 2013 11:10, O. Hartmann 
> wrote:
>> The most recent CURRENT doesn't work with the x11/nvidia-driver
>> (which is at 319.25 in the ports and 325.15 from nVidia).
>>
>> After build- and installworld AND successfully rebuilding port
>> x11/nvidia-driver, the system crashes immediately after a reboot
>> as soon the kernel module nvidia.ko seems to get loaded (in my
>> case, I load nvidia.ko via /etc/rc.conf.local since the nVidia
>> BLOB doesn't load cleanly everytime when loaded
>> from /boot/loader.conf).
>>
>> The crash occurs on systems with default compilation options set
>> while building world and with settings like -O3 -march=native. It
>> doesn't matter.
>>
>> FreeBSD and the port x11/nvidia-driver has been compiled with
>> CLANG.
>>
>> Most recent FreeBSD revision still crashing is r254097.
>>
>> When vmcore is saved, I always see something like
>>
>> savecore: reboot after panic: vm_radix_insert: key 23c078 is
>> already present
>>
>>
>> Does anyone has any idea what's going on?
>>
>> Thanks for helping in advance,
>>
>> Oliver

 I'm seeing a complete deadlock on my T520 with today's current and
 latest portsnap'd versions of ports for the nvidia-driver updates.

 A little bisection and help from others seems to point the finger at
 Jeff's r254025

 I'm getting a complete deadlock on X starting, but loading the module
 seems to have no ill effects.

 Sean
>>>
>>> Rigth, I loaded the module also via /boot/loader.conf and it loads
>>> cleanly. I start xdm and then the deadlock occurs.
>>>
>>> I tried recompiling the whole xorg suite via "portmaster -f xorg xdm",
>>> it took a while, but no effect, still dying.
>>> .
>>
>> Sorry to be rather late to the party; the Internet connection I'm using
>> at the moment is a bit flaky.  (I'm out of town.)
>>
>> I managed to get head/i386 @r254135 built and booting ... by removing
>> the "options DEBUG_MEMGUARD" from my kernel.
>>
>> However, that merely prevented a (very!) early panic, and got me to the
>> point where trying to start xdm with the x11/nvidia-driver as the
>> display driver causes an immediate reboot (no crash dump, despite
>> 'dumpdev="AUTO"' in /etc/rc.conf).  No drop to debugger, either.
>>
>> Booting & starting xdm with the nv driver works -- that's my present
>> environment as I am typing this.
>>
>> However, the panic with DEBUG_MEMGUARD may offer a clue.  Unfortunately,
>> it's early enough that screen lock/scrolling doesn't work, and I only
>> had the patience to write down partof the panic information.  (This is
>> on my laptop; no serial console, AFAICT -- and no device to capture the
>> output if I did, since I'm not at home.)
>>
>> The top line of the screen (at the panic) reads:
>>
>> s/kern/subr_vmem.c:1050
>>
>> The backtrace has the expected stuff near the top (about kbd, panic, and
>> memguard stuff); just below that is:
>>
>> vmem_alloc(c1226100,6681000,2,c1820cc0,3b5,...) at 
>> 0xc0ac5673=vmem_alloc+0x53/frame 0xc1820ca0
>>
>> Caveat: that was hand-transcribed from the screen to papaer, then
>> hand-transcribed from paper to this email message.  And my highest grade
>> in "Penmanship" was a D+.
>>
>> Be that as it may, here's the relevant section of subr_vmem.c with line
>> numbers (cut/pasted, so tabs get munged):
>>
>>1039 /*
>>1040  * vmem_alloc: allocate resource from the arena.
>>1041  */
>>1042 int
>>1043 vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, vmem_addr_t 
>> *addrp)
>>1044 {
>>1045 const int strat __unused = flags & VMEM_FITMASK;
>>1046 qcache_t *qc;
>>1047 
>>1048 flags &= VMEM_FLAGS;
>>1049 MPASS(size > 0);
>>1050 MPASS(strat == M_BESTFIT || strat == M_FIRSTFIT);
>>1051 if ((flags & M_NOWAIT) == 0)
>>1052 WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, 
>> "vmem_alloc");
>>1053
>>1054 if (size <= vm->vm_qcache_max) {
>>1055 qc = &vm->vm_qcache[(size - 1) >> 
>> vm->vm_quantum_shift];
>>1056 *addrp = (vmem_addr_t)uma_zalloc(qc->qc_cache, 
>> flags);
>>1057 if (*addrp == 0)
>>1058 return (ENOMEM);
>>1059 return (0);
>>1060 }
>>1061
>>1062 return vmem_xalloc(vm, size, 0, 0, 0, VMEM_ADDR_MIN, 
>> VMEM_ADDR_MAX,
>>1063 flags, addrp);
>>1064 }
>>
>>
>> This is at r254025.
>>
> 
> The REINPLACE_CMD at line 160 of nvidia-driver/Makefile is incorrect.
> 
> How do I know that?  Because I made a patch which results in a working
> nvidia-driver-319.32 with r254050. 

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Gary Jennejohn]

On Fri, 9 Aug 2013 10:12:37 -0700
David Wolfskill  wrote:

> On Fri, Aug 09, 2013 at 07:32:51AM +0200, O. Hartmann wrote:
> > ...
> > > > On 8 August 2013 11:10, O. Hartmann 
> > > > wrote:
> > > > > The most recent CURRENT doesn't work with the x11/nvidia-driver
> > > > > (which is at 319.25 in the ports and 325.15 from nVidia).
> > > > >
> > > > > After build- and installworld AND successfully rebuilding port
> > > > > x11/nvidia-driver, the system crashes immediately after a reboot
> > > > > as soon the kernel module nvidia.ko seems to get loaded (in my
> > > > > case, I load nvidia.ko via /etc/rc.conf.local since the nVidia
> > > > > BLOB doesn't load cleanly everytime when loaded
> > > > > from /boot/loader.conf).
> > > > >
> > > > > The crash occurs on systems with default compilation options set
> > > > > while building world and with settings like -O3 -march=native. It
> > > > > doesn't matter.
> > > > >
> > > > > FreeBSD and the port x11/nvidia-driver has been compiled with
> > > > > CLANG.
> > > > >
> > > > > Most recent FreeBSD revision still crashing is r254097.
> > > > >
> > > > > When vmcore is saved, I always see something like
> > > > >
> > > > > savecore: reboot after panic: vm_radix_insert: key 23c078 is
> > > > > already present
> > > > >
> > > > >
> > > > > Does anyone has any idea what's going on?
> > > > >
> > > > > Thanks for helping in advance,
> > > > >
> > > > > Oliver
> > > 
> > > I'm seeing a complete deadlock on my T520 with today's current and
> > > latest portsnap'd versions of ports for the nvidia-driver updates.
> > > 
> > > A little bisection and help from others seems to point the finger at
> > > Jeff's r254025
> > > 
> > > I'm getting a complete deadlock on X starting, but loading the module
> > > seems to have no ill effects.
> > > 
> > > Sean
> > 
> > Rigth, I loaded the module also via /boot/loader.conf and it loads
> > cleanly. I start xdm and then the deadlock occurs.
> > 
> > I tried recompiling the whole xorg suite via "portmaster -f xorg xdm",
> > it took a while, but no effect, still dying.
> > .
> 
> Sorry to be rather late to the party; the Internet connection I'm using
> at the moment is a bit flaky.  (I'm out of town.)
> 
> I managed to get head/i386 @r254135 built and booting ... by removing
> the "options DEBUG_MEMGUARD" from my kernel.
> 
> However, that merely prevented a (very!) early panic, and got me to the
> point where trying to start xdm with the x11/nvidia-driver as the
> display driver causes an immediate reboot (no crash dump, despite
> 'dumpdev="AUTO"' in /etc/rc.conf).  No drop to debugger, either.
> 
> Booting & starting xdm with the nv driver works -- that's my present
> environment as I am typing this.
> 
> However, the panic with DEBUG_MEMGUARD may offer a clue.  Unfortunately,
> it's early enough that screen lock/scrolling doesn't work, and I only
> had the patience to write down partof the panic information.  (This is
> on my laptop; no serial console, AFAICT -- and no device to capture the
> output if I did, since I'm not at home.)
> 
> The top line of the screen (at the panic) reads:
> 
> s/kern/subr_vmem.c:1050
> 
> The backtrace has the expected stuff near the top (about kbd, panic, and
> memguard stuff); just below that is:
> 
> vmem_alloc(c1226100,6681000,2,c1820cc0,3b5,...) at 
> 0xc0ac5673=vmem_alloc+0x53/frame 0xc1820ca0
> 
> Caveat: that was hand-transcribed from the screen to papaer, then
> hand-transcribed from paper to this email message.  And my highest grade
> in "Penmanship" was a D+.
> 
> Be that as it may, here's the relevant section of subr_vmem.c with line
> numbers (cut/pasted, so tabs get munged):
> 
>1039 /*
>1040  * vmem_alloc: allocate resource from the arena.
>1041  */
>1042 int
>1043 vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, vmem_addr_t 
> *addrp)
>1044 {
>1045 const int strat __unused = flags & VMEM_FITMASK;
>1046 qcache_t *qc;
>1047 
>1048 flags &= VMEM_FLAGS;
>1049 MPASS(size > 0);
>1050 MPASS(strat == M_BESTFIT || strat == M_FIRSTFIT);
>1051 if ((flags & M_NOWAIT) == 0)
>1052 WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, 
> "vmem_alloc");
>1053
>1054 if (size <= vm->vm_qcache_max) {
>1055 qc = &vm->vm_qcache[(size - 1) >> 
> vm->vm_quantum_shift];
>1056 *addrp = (vmem_addr_t)uma_zalloc(qc->qc_cache, flags);
>1057 if (*addrp == 0)
>1058 return (ENOMEM);
>1059 return (0);
>1060 }
>1061
>1062 return vmem_xalloc(vm, size, 0, 0, 0, VMEM_ADDR_MIN, 
> VMEM_ADDR_MAX,
>1063 flags, addrp);
>1064 }
> 
> 
> This is at r254025.
> 

The REINPLACE_CMD at line 160 of nvidia-driver/Makefile is incorrect.

How do I know that?  Because I made a patch which results in a working
nvidia-driver-319.32 with r254050.  That's what