date:20141004

Re: About pmap_mapdev() & pmap_unmapdev()

2014-10-04 Thread Kohji Okuno

Hi, Konstantin,

Thank you for your comment.
And, your change is better than mine.

> Do you mean that this panic is related to missed pmap_remove() ?
> I doubt it, since pmap_mapdev() does not establish managed mappings.

Yes, pmap_mapdev() does not establish managed mappings. But, if
kernel_pmap.pm_stats.resident_count is zero, then any managed pages
(for example pipe_map, exec_map, or etc.) are not able to change
unmanaged status, because pmap_remove() returns without calling
pmap_remove_pte().

In this result, I encounterd the panic. Could you refer the following?

Regards,
 Kohji Okuno

int
vm_map_delete(vm_map_t map, vm_offset_t start, vm_offset_t end)
{
 >> SNIP <<
   /** this pmap_remove() does not change for mappings! **/
   pmap_remove(map->pmap, entry->start, entry->end);

/*
 * Delete the entry only after removing all pmap
 * entries pointing to its pages.  (Otherwise, its
 * page frames may be reallocated, and any modify bits
 * will be set in the wrong object!)
 */

/** this calls vm_page_free_toq() and causes panic! **/
vm_map_entry_delete(map, entry);
entry = next;
}
return (KERN_SUCCESS);
}

> On Fri, Oct 03, 2014 at 05:25:33PM +0900, Kohji Okuno wrote:
>> Hi,
>> 
>> At least in i386 && 9-stable, when we call pmap_mapdev() and
>> pmap_unmapdev(), kernel_pmap.pm_stats.resident_count is decreased
>> incorrectly.
>> 
>> pmap_mapdev_attr()->pmap_kenter_attr():
>> In this path, kernel_pmap.pm_stats.resident_count is not increlmented.
>> 
>> pmap_unmapdev()->kmem_free(kernel_map)->vm_map_remove()->pmap_remove():
>> But, in this path, kernel_pmap.pm_stats.resident_count is decreased in
>> pmap_remove_pte().
>> 
>> While I called pmap_mapdev() and pmap_unmapdev() repeatedly and
>> kernel_pmap.pm_stats.resident_count became `0', since pmap_remove()
>> returned without removing ptes, I encountered various kernel panics.
> I think you are right.
> 
> The problem seems to be fixed in HEAD and 10, since mapdev was switched
> to use kva_alloc/kva_free.  I added stable@ to Cc:.
> 
>> 
>> And, when I enabled INVARIANTS, I looked the following panic message.
>> panic: vm_page_free_toq: freeing mapped page 0x.
> Do you mean that this panic is related to missed pmap_remove() ?
> I doubt it, since pmap_mapdev() does not establish managed mappings.
> 
>> 
>> I think, I should change the following.
>> What do you think about this?
>> 
>> 
>> diff --git a/sys/i386/i386/pmap.c b/sys/i386/i386/pmap.c
>> index 2adc6f8..a0998e8 100644
>> --- a/sys/i386/i386/pmap.c
>> +++ b/sys/i386/i386/pmap.c
>> @@ -5061,6 +5061,7 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int 
>> mode)
>>  {
>>  vm_offset_t va, offset;
>>  vm_size_t tmpsize;
>> +int kmem_allocated = 0;
>>  
>>  offset = pa & PAGE_MASK;
>>  size = roundup(offset + size, PAGE_SIZE);
>> @@ -5068,13 +5069,18 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int 
>> mode)
>>  
>>  if (pa < KERNLOAD && pa + size <= KERNLOAD)
>>  va = KERNBASE + pa;
>> -else
>> +else {
>>  va = kmem_alloc_nofault(kernel_map, size);
>> +kmem_allocated = 1;
> 
> You could just do
>   PMAP_LOCK(kernel_pmap);
>   kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size);
>   PMAP_UNLOCK(kernel_pmap);
> there.  And, the same fix is needed for amd64.
> 
>> +}
>>  if (!va)
>>  panic("pmap_mapdev: Couldn't alloc kernel virtual memory");
>>  
>> -for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE)
>> +for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) {
>>  pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode);
>> +if (kmem_allocated)
>> +kernel_pmap.pm_stats.resident_count++;
>> +}
>>  pmap_invalidate_range(kernel_pmap, va, va + tmpsize);
>>  pmap_invalidate_cache_range(va, va + size);
>>  return ((void *)(va + offset));
>> ___
>> 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"
___
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: About pmap_mapdev() & pmap_unmapdev()

2014-10-04 Thread Konstantin Belousov

On Sat, Oct 04, 2014 at 05:00:36PM +0900, Kohji Okuno wrote:
> Hi, Konstantin,
> 
> Thank you for your comment.
> And, your change is better than mine.
At the end of the mail is commit candidate.  I did not even compiled this.
Can you test and report back, please ?

> 
> > Do you mean that this panic is related to missed pmap_remove() ?
> > I doubt it, since pmap_mapdev() does not establish managed mappings.
> 
> Yes, pmap_mapdev() does not establish managed mappings. But, if
> kernel_pmap.pm_stats.resident_count is zero, then any managed pages
> (for example pipe_map, exec_map, or etc.) are not able to change
> unmanaged status, because pmap_remove() returns without calling
> pmap_remove_pte().
> 
> In this result, I encounterd the panic. Could you refer the following?
Yes, kmem_back() indeed uses managed mapping.

Index: amd64/amd64/pmap.c
===
--- amd64/amd64/pmap.c  (revision 272506)
+++ amd64/amd64/pmap.c  (working copy)
@@ -5040,6 +5040,9 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in
pa = trunc_page(pa);
for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE)
pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode);
+   PMAP_LOCK(kernel_pmap);
+   kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size);
+   PMAP_UNLOCK(kernel_pmap);
pmap_invalidate_range(kernel_pmap, va, va + tmpsize);
pmap_invalidate_cache_range(va, va + tmpsize);
return ((void *)(va + offset));
Index: i386/i386/pmap.c
===
--- i386/i386/pmap.c(revision 272506)
+++ i386/i386/pmap.c(working copy)
@@ -5066,10 +5066,14 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in
size = roundup(offset + size, PAGE_SIZE);
pa = pa & PG_FRAME;
 
-   if (pa < KERNLOAD && pa + size <= KERNLOAD)
+   if (pa < KERNLOAD && pa + size <= KERNLOAD) {
va = KERNBASE + pa;
-   else
+   } else {
va = kmem_alloc_nofault(kernel_map, size);
+   PMAP_LOCK(kernel_pmap);
+   kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size);
+   PMAP_UNLOCK(kernel_pmap);
+   }
if (!va)
panic("pmap_mapdev: Couldn't alloc kernel virtual memory");
 
___
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: i915 driver update testing

2014-10-04 Thread Ranjan1018 .

2014-10-03 19:02 GMT+02:00 Konstantin Belousov :

> Please find at the
> https://kib.kiev.ua/kib/drm/i915.1.patch
> a patch which provides some updates to the i915 driver. At large, this
> is import of the batch of Linux commits, and as such, it is interesting
> mostly as attempt to restart the race to get us more up to date Linux code
> imported. It might provide some bug fixes, most likely for IvyBridge.
> Interesting from the development PoV is the update of the GEM i/o ioctl
> code path to mimic Linux code structure.
>
> I am asking _only_ for reports of regressions with the patch applied,
> comparing with the code which is currently in HEAD. I will not debug
> any existing bugs, my goal right now is to commit this update, which is
> needed for further work. I.e., only when you get an issue with the patch
> applied, but cannot reproduce the problem without the patch, please
> prepare a bug report.
>
> FYI, the driver will attach to haswell gfx, but I am not interested in
> reports about this (see above paragraph). On my test box, which is Core
> i7 4770S, the mode-setting and front-buffer rendering works, but Mesa
> immediately cause renderer to bug out.
>
> Work was sponsored by The FreeBSD Foundation, both by time and hardware,
> and Intel provided access to the documentation.
> ___
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org"
>

On a Samsung ATIV Book 2 15.6” Notebook - NP270E5E, specs,
 the patch
does not works.
The result of the command

# kldload i915kms
is a blank screen.

After rebooting the notebook, in /var/log/messages I can read:
Oct  4 08:12:44 ativ kernel: info: [drm] Initialized drm 1.1.0 20060810
Oct  4 08:12:45 ativ kernel: drmn0:  on vgapci0
Oct  4 08:12:45 ativ kernel: info: [drm] MSI enabled 1 message(s)
Oct  4 08:12:45 ativ kernel: info: [drm] AGP at 0xe000 256MB
Oct  4 08:12:45 ativ kernel: iicbus0:  on iicbb0 addr 0xff
Oct  4 08:12:45 ativ kernel: iic0:  on iicbus0
Oct  4 08:12:45 ativ kernel: iic1:  on iicbus1
Oct  4 08:12:45 ativ kernel: iicbus2:  on iicbb1 addr 0x0
Oct  4 08:12:45 ativ kernel: iic2:  on iicbus2
Oct  4 08:12:45 ativ kernel: iic3:  on iicbus3
Oct  4 08:12:45 ativ kernel: iicbus4:  on iicbb2 addr 0x0
Oct  4 08:12:45 ativ kernel: iic4:  on iicbus4
Oct  4 08:12:45 ativ kernel: iic5:  on iicbus5
Oct  4 08:12:45 ativ kernel: iicbus6:  on iicbb3 addr 0x0
Oct  4 08:12:45 ativ kernel: iic6:  on iicbus6
Oct  4 08:12:45 ativ kernel: iic7:  on iicbus7
Oct  4 08:12:45 ativ kernel: iicbus8:  on iicbb4 addr 0x0
Oct  4 08:12:45 ativ kernel: iic8:  on iicbus8
Oct  4 08:12:45 ativ kernel: iic9: 
Oct  4 08:12:45 ativ kernel: on iicbus9
Oct  4 08:12:45 ativ kernel: iicbus10:  on iicbb5 addr 0x0
Oct  4 08:12:45 ativ kernel: iic10:  on iicbus10
Oct  4 08:12:45 ativ kernel: iic11:  on iicbus11
Oct  4 08:12:45 ativ kernel: info: [drm] Supports vblank timestamp caching
Rev 1 (10.10.2010).
Oct  4 08:12:45 ativ kernel: info: [drm] Driver supports precise vblank
timestamp query.

Regards
Maurizio
___
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: About pmap_mapdev() & pmap_unmapdev()

2014-10-04 Thread Kohji Okuno

Hi, Konstantin,

> At the end of the mail is commit candidate.  I did not even compiled this.
> Can you test and report back, please ?

Could you check the following?
(1) should use kernel_pmap->pm_stats.resident_count
  ^^^
I'm sorry. My patch was wrong. 

(2) should use pmap_resident_count_inc() in amd64.


I will test, later.

In addtion, I have one question.
In current and 10-stable, is vm_map_delete() called by kva_free()?
If vm_map_delete() is called, this fix is needed in current and
10-stable, I think.

Regards,
 Kohji Okuno

> On Sat, Oct 04, 2014 at 05:00:36PM +0900, Kohji Okuno wrote:
>> Hi, Konstantin,
>> 
>> Thank you for your comment.
>> And, your change is better than mine.
> At the end of the mail is commit candidate.  I did not even compiled this.
> Can you test and report back, please ?
> 
>> 
>> > Do you mean that this panic is related to missed pmap_remove() ?
>> > I doubt it, since pmap_mapdev() does not establish managed mappings.
>> 
>> Yes, pmap_mapdev() does not establish managed mappings. But, if
>> kernel_pmap.pm_stats.resident_count is zero, then any managed pages
>> (for example pipe_map, exec_map, or etc.) are not able to change
>> unmanaged status, because pmap_remove() returns without calling
>> pmap_remove_pte().
>> 
>> In this result, I encounterd the panic. Could you refer the following?
> Yes, kmem_back() indeed uses managed mapping.
> 
> Index: amd64/amd64/pmap.c
> ===
> --- amd64/amd64/pmap.c(revision 272506)
> +++ amd64/amd64/pmap.c(working copy)
> @@ -5040,6 +5040,9 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in
>   pa = trunc_page(pa);
>   for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE)
>   pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode);
> + PMAP_LOCK(kernel_pmap);
> + kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size);
> + PMAP_UNLOCK(kernel_pmap);
>   pmap_invalidate_range(kernel_pmap, va, va + tmpsize);
>   pmap_invalidate_cache_range(va, va + tmpsize);
>   return ((void *)(va + offset));
> Index: i386/i386/pmap.c
> ===
> --- i386/i386/pmap.c  (revision 272506)
> +++ i386/i386/pmap.c  (working copy)
> @@ -5066,10 +5066,14 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in
>   size = roundup(offset + size, PAGE_SIZE);
>   pa = pa & PG_FRAME;
>  
> - if (pa < KERNLOAD && pa + size <= KERNLOAD)
> + if (pa < KERNLOAD && pa + size <= KERNLOAD) {
>   va = KERNBASE + pa;
> - else
> + } else {
>   va = kmem_alloc_nofault(kernel_map, size);
> + PMAP_LOCK(kernel_pmap);
> + kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size);
> + PMAP_UNLOCK(kernel_pmap);
> + }
>   if (!va)
>   panic("pmap_mapdev: Couldn't alloc kernel virtual memory");
>  
> ___
> 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: About pmap_mapdev() & pmap_unmapdev()

2014-10-04 Thread Konstantin Belousov

On Sat, Oct 04, 2014 at 05:53:26PM +0900, Kohji Okuno wrote:
> Hi, Konstantin,
> 
> > At the end of the mail is commit candidate.  I did not even compiled this.
> > Can you test and report back, please ?
> 
> Could you check the following?
> (1) should use kernel_pmap->pm_stats.resident_count
>   ^^^
> I'm sorry. My patch was wrong. 
As well as mine.

> 
> (2) should use pmap_resident_count_inc() in amd64.
Correct.

> 
> 
> I will test, later.
> 
> In addtion, I have one question.
> In current and 10-stable, is vm_map_delete() called by kva_free()?
No, kva_free() only releases the vmem backing, leaving the page
tables intact.  This is why I only did the stable/9 patch.

> If vm_map_delete() is called, this fix is needed in current and
> 10-stable, I think.

Updated patch below.

Index: amd64/amd64/pmap.c
===
--- amd64/amd64/pmap.c  (revision 272506)
+++ amd64/amd64/pmap.c  (working copy)
@@ -5040,6 +5040,9 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in
pa = trunc_page(pa);
for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE)
pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode);
+   PMAP_LOCK(kernel_pmap);
+   pmap_resident_count_inc(kernel_pmap, OFF_TO_IDX(size));
+   PMAP_UNLOCK(kernel_pmap);
pmap_invalidate_range(kernel_pmap, va, va + tmpsize);
pmap_invalidate_cache_range(va, va + tmpsize);
return ((void *)(va + offset));
Index: i386/i386/pmap.c
===
--- i386/i386/pmap.c(revision 272506)
+++ i386/i386/pmap.c(working copy)
@@ -5066,10 +5066,14 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in
size = roundup(offset + size, PAGE_SIZE);
pa = pa & PG_FRAME;
 
-   if (pa < KERNLOAD && pa + size <= KERNLOAD)
+   if (pa < KERNLOAD && pa + size <= KERNLOAD) {
va = KERNBASE + pa;
-   else
+   } else {
va = kmem_alloc_nofault(kernel_map, size);
+   PMAP_LOCK(kernel_pmap);
+   kernel_pmap->pm_stats.resident_count += OFF_TO_IDX(size);
+   PMAP_UNLOCK(kernel_pmap);
+   }
if (!va)
panic("pmap_mapdev: Couldn't alloc kernel virtual memory");
 
___
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: i915 driver update testing

2014-10-04 Thread Johannes Dieterich

Dear all,

sorry for cross-posting (I am not subscribed to x11@).

Same behavior for me (i5-3320M on a Thinkpad T430s w/ Optimus support) as
reported by Maurizio.

When boot switches to graphics from text mode, display remains black with
backlight on. I am running the experimental xorg-stack from
https://trillian.chruetertee.ch/svn/ports/branches/experimental which works
with an unmodified r272482 w/o problem (minus the Optimus, obviously).

No entry in Xorg.0.log. /var/log/messages only contains output from
consolekit, saying it waits for a native display on tty 9.

Please let me know if you want me to test anything further.

Best

Johannes

On Fri, Oct 3, 2014 at 7:02 PM, Konstantin Belousov 
wrote:

> Please find at the
> https://kib.kiev.ua/kib/drm/i915.1.patch
> a patch which provides some updates to the i915 driver. At large, this
> is import of the batch of Linux commits, and as such, it is interesting
> mostly as attempt to restart the race to get us more up to date Linux code
> imported. It might provide some bug fixes, most likely for IvyBridge.
> Interesting from the development PoV is the update of the GEM i/o ioctl
> code path to mimic Linux code structure.
>
> I am asking _only_ for reports of regressions with the patch applied,
> comparing with the code which is currently in HEAD. I will not debug
> any existing bugs, my goal right now is to commit this update, which is
> needed for further work. I.e., only when you get an issue with the patch
> applied, but cannot reproduce the problem without the patch, please
> prepare a bug report.
>
> FYI, the driver will attach to haswell gfx, but I am not interested in
> reports about this (see above paragraph). On my test box, which is Core
> i7 4770S, the mode-setting and front-buffer rendering works, but Mesa
> immediately cause renderer to bug out.
>
> Work was sponsored by The FreeBSD Foundation, both by time and hardware,
> and Intel provided access to the documentation.
> ___
> 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"

sh.core in HOME of the user on system shutdown

2014-10-04 Thread Matthias Apitz


Hello,

I run 11-CURRENT r269739 on my i386 netbook.

After (clean) shutdown I always have a core file 'sh.core' in the (only)
logged in users HOME; the backtrace is ofc unuseable:

(gdb) bt
#0  0x282152f8 in fwrite () from /lib/libc.so.7
#1  0x280978db in el_gets () from /lib/libedit.so.7
#2  0x28099746 in el_gets () from /lib/libedit.so.7
#3  0x080536a1 in ?? ()
#4  0x2880d300 in ?? ()
#5  0x08066ac8 in _CurrentRuneLocale ()
#6  0x53f564a4 in ?? ()
#7  0x in ?? ()

Is it a known issue or is it worth to compile the libs with -g?
Thx

matthias

-- 
Matthias Apitz   |  /"\   ASCII Ribbon Campaign:
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
 | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
___
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: About pmap_mapdev() & pmap_unmapdev()

2014-10-04 Thread Kohji Okuno

Hi Konstantin,

Thank you for your prompt response.
I will test and report from next monday.

>> In addtion, I have one question.
>> In current and 10-stable, is vm_map_delete() called by kva_free()?
> No, kva_free() only releases the vmem backing, leaving the page
> tables intact.  This is why I only did the stable/9 patch.

Where are PTEs allocated by pmap_mapdev() freed in current and 10-stable?
Could you please explain me?

Regards,
 Kohji Okuno

> On Sat, Oct 04, 2014 at 05:53:26PM +0900, Kohji Okuno wrote:
>> Hi, Konstantin,
>> 
>> > At the end of the mail is commit candidate.  I did not even compiled this.
>> > Can you test and report back, please ?
>> 
>> Could you check the following?
>> (1) should use kernel_pmap->pm_stats.resident_count
>>   ^^^
>> I'm sorry. My patch was wrong. 
> As well as mine.
> 
>> 
>> (2) should use pmap_resident_count_inc() in amd64.
> Correct.
> 
>> 
>> 
>> I will test, later.
>> 
>> In addtion, I have one question.
>> In current and 10-stable, is vm_map_delete() called by kva_free()?
> No, kva_free() only releases the vmem backing, leaving the page
> tables intact.  This is why I only did the stable/9 patch.
> 
>> If vm_map_delete() is called, this fix is needed in current and
>> 10-stable, I think.
> 
> Updated patch below.
> 
> Index: amd64/amd64/pmap.c
> ===
> --- amd64/amd64/pmap.c(revision 272506)
> +++ amd64/amd64/pmap.c(working copy)
> @@ -5040,6 +5040,9 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in
>   pa = trunc_page(pa);
>   for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE)
>   pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode);
> + PMAP_LOCK(kernel_pmap);
> + pmap_resident_count_inc(kernel_pmap, OFF_TO_IDX(size));
> + PMAP_UNLOCK(kernel_pmap);
>   pmap_invalidate_range(kernel_pmap, va, va + tmpsize);
>   pmap_invalidate_cache_range(va, va + tmpsize);
>   return ((void *)(va + offset));
> Index: i386/i386/pmap.c
> ===
> --- i386/i386/pmap.c  (revision 272506)
> +++ i386/i386/pmap.c  (working copy)
> @@ -5066,10 +5066,14 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in
>   size = roundup(offset + size, PAGE_SIZE);
>   pa = pa & PG_FRAME;
>  
> - if (pa < KERNLOAD && pa + size <= KERNLOAD)
> + if (pa < KERNLOAD && pa + size <= KERNLOAD) {
>   va = KERNBASE + pa;
> - else
> + } else {
>   va = kmem_alloc_nofault(kernel_map, size);
> + PMAP_LOCK(kernel_pmap);
> + kernel_pmap->pm_stats.resident_count += OFF_TO_IDX(size);
> + PMAP_UNLOCK(kernel_pmap);
> + }
>   if (!va)
>   panic("pmap_mapdev: Couldn't alloc kernel virtual memory");
>  
> ___
> 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"

HEADS UP: Merging projects/ipfw to HEAD

2014-10-04 Thread Alexander V. Chernikov


Hi,

I'm going to merge projects/ipfw branch to HEAD in the middle of next week.

What has changed:

Main user-visible changes are related to tables:

* Tables are now identified by names, not numbers. There can be up to 
65k tables with up to 63-byte long names.
* Tables are now set-aware (default off), so you can switch/move them 
atomically with rules.
* More functionality is supported (swap, lock, limits, user-level 
lookup, batched add/del) by generic table code.
* New table types are added (flow) so you can match multiple packet 
fields at once.
* Ability to add different type of lookup algorithms for particular 
table type has been added.
* New table algorithms are added (cidr:hash, iface:array, number:array 
and flow:hash) to make certain types of lookup more effective.
* Table value are now capable of holding multiple data fields for 
different tablearg users


Some examples (see ipfw(8) manual page for the description):

  0:02 [2] zfscurr0# ipfw table fl2 create type 
flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib

   0:02 [2] zfscurr0# ipfw table fl2 info
   +++ table(fl2), set(0) +++
kindex: 0, type: flow:src-ip,proto,dst-port
valtype: number, references: 0
algorithm: flow:hash
items: 0, size: 280
   0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12
   0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13
   0:02 [2] zfscurr0# ipfw table fl2 list
   +++ table(fl2), set(0) +++
   2a02:6b8::333,6,443 45000
   10.0.0.92,6,80 22000
   0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 
flow 'table(fl2)'


   ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64"
   ipfw table mi_test add 10.0.0.8/30
   ipfw table mi_test add 2a02:6b8:b010::1/64 25

   # ipfw table si add 1.1.1.1/32  2.2.2.2/32 
   added: 1.1.1.1/32 
   added: 2.2.2.2/32 
   # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 
   exists: 2.2.2.2/32 2200
   added: 4.4.4.4/32 
   ipfw: Adding record failed: record already exists
   ^ Returns error but keeps inserted items
   # ipfw table si list
   +++ table(si), set(0) +++
   1.1.1.1/32 
   2.2.2.2/32 
   4.4.4.4/32 
   # ipfw table si atomic add 3.3.3.3/32  4.4.4.4/32 4400 
5.5.5.5/32 

   added(reverted): 3.3.3.3/32 
   exists: 4.4.4.4/32 4400
   ignored: 5.5.5.5/32 
   ipfw: Adding record failed: record already exists
   ^ Returns error and reverts added records

Performance changes:
* Main ipfw lock was converted to rmlock
* Rule counters were separated from rule itself and made per-cpu.
* Radix table entries fits into 128 bytes
* struct ip_fw is now more compact so more rules will fit into 64 bytes
* interface tables uses array of existing ifindexes for faster match

ABI changes:
All functionality supported by old ipfw(8) remains functional. Old & new 
binaries can work together with the following restrictions:
* Tables named other than ^\d+$ are shown as table(65535) in ruleset in 
old binaries
* I'm a bit unsure about "lookup src-port|dst-port N" case, something 
may be broken here. Anyway, this can be fixed for MFC


Internal changes:.
Changing table ids to numbers resulted in format modification for most 
sockopt codes.
Old sopt format was compact, but very hard to extend (no versioning, 
inability to add more opcodes), so
* All relevant opcodes were converted to TLV-based versioned 
IP_FW3-based codes.
* The remaining opcodes were also converted to be able to eliminate all 
older opcodes at once
* All IP_FW3 handlers uses special API instead of calling sooptcopy* 
directly to ease adding another communication methods

* struct ip_fw is now different for kernel and userland
* tablearg value has been changed to 0 to ease future extensions
* table "values" are now indexes in special value array which holds 
extended data for given index

* Batched add/delete has been added to tables code
* Most changes has been done to permit batched rule addition.
* interface tracking API has been added (started on demand) to permit 
effective interface tables operations
* O(1) skipto cache, currently turned off by default at compile-time 
(eats 512K).


* Several steps has been made towards making libipfw:
  * most of new functions were separated into "parse/prepare/show and 
actuall-do-stuff" pieces (already merged).
  * there are separate functions for parsing text string into "struct 
ip_fw" and printing "struct ip_fw" to supplied buffer (already merged).

* Probably some more less significant/forgotten features

___
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: About pmap_mapdev() & pmap_unmapdev()

2014-10-04 Thread Konstantin Belousov

On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote:
> Hi Konstantin,
> 
> Thank you for your prompt response.
> I will test and report from next monday.
> 
> >> In addtion, I have one question.
> >> In current and 10-stable, is vm_map_delete() called by kva_free()?
> > No, kva_free() only releases the vmem backing, leaving the page
> > tables intact.  This is why I only did the stable/9 patch.
> 
> Where are PTEs allocated by pmap_mapdev() freed in current and 10-stable?
> Could you please explain me?
They are not freed. The removal of the vmem which covers the address
space managed by corresponding ptes, allows the reuse of both KVA region
and corresponding PTEs in the tables. The only concern with the resident
page tables is to avoid two kva_alloc() to step over each other, and
this is ensured by vmem.
___
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"

CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

2014-10-04 Thread O. Hartmann

Recent sources (Revision: 272529) fail to compile:

[...]
cc -m32 -march=native -DCOMPAT_32BIT  -isystem 
/usr/obj/usr/src/lib32/usr/include/
-L/usr/obj/usr/src/lib32/usr/lib32  -B/usr/obj/usr/src/lib32/usr/lib32  -O2 
-pipe -O3 -O3
-pipe  -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 
-fstack-protector
-Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch
-Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments
-c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- all_subdir_libproc --- 
---
libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping
incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for
-lctf /usr/obj/usr/src/tmp/usr/bin/ld: skipping
incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.a when searching for
-lctf /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lctf cc: error: linker 
command failed
with exit code 1 (use -v to see invocation) *** [libproc.so.3] Error code 1

make[5]: stopped in /usr/src/lib/libproc
--- libproc.a ---
ranlib -D libproc.a
[...]

oh


signature.asc
Description: PGP signature

Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

2014-10-04 Thread Mark Johnston

On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote:
> Recent sources (Revision: 272529) fail to compile:
> 
> [...]
> cc -m32 -march=native -DCOMPAT_32BIT  -isystem 
> /usr/obj/usr/src/lib32/usr/include/
> -L/usr/obj/usr/src/lib32/usr/lib32  -B/usr/obj/usr/src/lib32/usr/lib32  -O2 
> -pipe -O3 -O3
> -pipe  -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 
> -fstack-protector
> -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body 
> -Wno-string-plus-int
> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
> -Wno-switch
> -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses 
> -Qunused-arguments
> -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- all_subdir_libproc 
> --- ---
> libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping
> incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for

I'm confused by this message. Are you building with -DNO_CLEAN? Do you
have anything in make.conf or src.conf, especially anything that's
changed since libctf was rebuilt?

You might try rebuilding libctf with

$ cd /usr/src
$ make -C cddl/lib/libctf clean all

but I'm not sure why ld is ignoring the existing libctf.so.

> -lctf /usr/obj/usr/src/tmp/usr/bin/ld: skipping
> incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.a when searching for
> -lctf /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lctf cc: error: linker 
> command failed
> with exit code 1 (use -v to see invocation) *** [libproc.so.3] Error code 1
> 
> make[5]: stopped in /usr/src/lib/libproc
> --- libproc.a ---
> ranlib -D libproc.a
> [...]
> 
> oh


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

bwn(4) testing

2014-10-04 Thread Justin Hibbits

Since I don't have a machine that successfully suspends/resumes, can
someone test the patch at https://reviews.freebsd.org/D802 ?  It
shouldn't be any functional change, just removing code duplicated by
bus_generic_* functions.

Thanks,
Justin


signature.asc
Description: PGP signature

Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support

2014-10-04 Thread Craig Wiesen

Yonghyeon PYUN  gmail.com> writes:

> 
> On Wed, Oct 01, 2014 at 10:36:37AM +0900, Yonghyeon PYUN wrote:
> > On Tue, Sep 30, 2014 at 10:57:41AM +0900, Yonghyeon PYUN wrote:
> > > Hi,
> > > I've added support for QAC AR816x/AR817x ethernet controllers.  It
> > > passed my limited testing and I need more testers.  You can find
> > > patches from the following URLs.
> > > 
> > > http://people.freebsd.org/~yongari/alc/pci.quirk.diff
> > > and
> > > http://people.freebsd.org/~yongari/alc/alc.diff.20140930
> > > 
> > > pci.qurik.diff is to workaround silicon bug of AR816x. Without it
> > > MSI/MSIX interrupt wouldn't work.  If you just want to use
> > > legacy INTx interrupt you don't have to apply it but you have to
> > > tell alc(4) not to use MSI/MSIX interrupt with tunables(
> > > hw.alc.msi.disable and hw.alc.msix_disable).
> > > 
> > > alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172
> > > and E2200 controllers.  It supports all hardware features except
> > > RSS.  If you have any QAC AR816x/AR817x or old AR813x/AR815x
> > > controllers please test and report how the diff works for you.
> > > Thanks.
> > 
> > http://people.freebsd.org/~yongari/alc/pci.quirk.diff
> > http://people.freebsd.org/~yongari/alc/alc.diff.20141001
> > 
> > Patch updated to address link establishment issue.
> 
> http://people.freebsd.org/~yongari/alc/alc.diff.20141002
> Patch updated again to correct wrong lock assertion.
> ___



Hi-


I can add that I tested your patches on a 9.3 Stable machine.
The motherboard is a GA-Z77-D3H (rev. 1.1) with onboard Atheros AR816x.
I did have to apply one of the patch hunks by hand, see below.
I am able to ssh into the machine, and remotely access apache/poudriere.
I have not seen any problems so far.
I've included a few outputs for you to examine.


# uname -a
FreeBSD desktop.home.org 9.3-STABLE FreeBSD 9.3-STABLE #0 r272523M: Sat Oct  
4 11:50:08 CDT 2014 
r...@desktop.home.org:/usr/obj/usr/src/sys/SANDYBRIDGE  amd64


# ifconfig -a
em0: flags=8843 metric 0 mtu 1500
options=4219b
ether 68:05:ca:xx:xx:xx
inet 127.0.0.1 netmask 0xff00 broadcast 127.255.255.255
nd6 options=29
media: Ethernet autoselect
status: no carrier


alc0: flags=8843 metric 0 mtu 1500
options=c319a
ether 90:2b:34:xx:xx:xx
inet 192.168.100.48 netmask 0xff00 broadcast 192.168.100.255
inet6 -redacted-%alc0 prefixlen 64 scopeid 0x4 
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active

I left em0 above for comparison:


Rejected hunk:
# cat if_alc.c.rej
***
*** 831,843 
CSR_WRITE_4(sc, ALC_PCIE_PHYMISC2, val);
}
/* Disable ASPM L0S and L1. */
-   cap = CSR_READ_2(sc, base + PCIER_LINK_CAP);
if ((cap & PCIEM_LINK_CAP_ASPM) != 0) {
-   ctl = CSR_READ_2(sc, base + PCIER_LINK_CTL);
if ((ctl & PCIEM_LINK_CTL_RCB) != 0)
sc->alc_rcb = DMA_CFG_RCB_128;
if (bootverbose)
-   device_printf(dev, "RCB %u bytes\n",
sc->alc_rcb == DMA_CFG_RCB_64 ? 64 : 
128);
state = ctl & PCIEM_LINK_CTL_ASPMC;
if (state & PCIEM_LINK_CTL_ASPMC_L0S)
--- 1279,1291 
CSR_WRITE_4(sc, ALC_PCIE_PHYMISC2, val);
}
/* Disable ASPM L0S and L1. */
+   cap = CSR_READ_2(sc, sc->alc_expcap + PCIER_LINK_CAP);
if ((cap & PCIEM_LINK_CAP_ASPM) != 0) {
+   ctl = CSR_READ_2(sc, sc->alc_expcap + 
PCIER_LINK_CTL);
if ((ctl & PCIEM_LINK_CTL_RCB) != 0)
sc->alc_rcb = DMA_CFG_RCB_128;
if (bootverbose)
+   device_printf(sc->alc_dev, "RCB %u 
bytes\n",
sc->alc_rcb == DMA_CFG_RCB_64 ? 64 : 
128);
state = ctl & PCIEM_LINK_CTL_ASPMC;
if (state & PCIEM_LINK_CTL_ASPMC_L0S)


>From verbose boot log:
pcib5:  irq 18 at device 28.6 on pci0
pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib5
pcib0: allocated type 3 (0xf790-0xf79f) for rid 20 of pcib5
pcib5:   domain0
pcib5:   secondary bus 5
pcib5:   subordinate bus   5
pcib5:   I/O decode0xd000-0xdfff
pcib5:   memory decode 0xf790-0xf79f
pci5:  on pcib5
pci5: domain=0, physical bus=5
found-> vendor=0x1969, dev=0x1091, revid=0x10
domain=0, bus=5, slot=0, func=0
class=02-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=11
powerspec 3  supports D0 D3  cur

Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

2014-10-04 Thread O. Hartmann

Am Sat, 4 Oct 2014 11:33:38 -0700
Mark Johnston  schrieb:

> On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote:
> > Recent sources (Revision: 272529) fail to compile:
> > 
> > [...]
> > cc -m32 -march=native -DCOMPAT_32BIT  -isystem 
> > /usr/obj/usr/src/lib32/usr/include/
> > -L/usr/obj/usr/src/lib32/usr/lib32  -B/usr/obj/usr/src/lib32/usr/lib32  -O2 
> > -pipe -O3
> > -O3 -pipe  -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99
> > -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body
> > -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare
> > -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
> > -Wno-enum-conversion
> > -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses
> > -Qunused-arguments -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o ---
> > all_subdir_libproc --- --- libproc.so.3 --- 
> > /usr/obj/usr/src/tmp/usr/bin/ld: skipping
> > incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for
> 
> I'm confused by this message. Are you building with -DNO_CLEAN? Do you
> have anything in make.conf or src.conf, especially anything that's
> changed since libctf was rebuilt?

I do not build with -DNO_CLEAN. I use a script which kills everything in 
/usr/obj/ and
build then from scratch. 

> 
> You might try rebuilding libctf with
> 
> $ cd /usr/src
> $ make -C cddl/lib/libctf clean all

I can build libctf.so that way, also installation is no problem, but next time 
when I
buildworld, I run into the same situation.

> 
> but I'm not sure why ld is ignoring the existing libctf.so.

Me either.

> 
> > -lctf /usr/obj/usr/src/tmp/usr/bin/ld: skipping
> > incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.a when searching for
> > -lctf /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lctf cc: error: linker 
> > command
> > failed with exit code 1 (use -v to see invocation) *** [libproc.so.3] Error 
> > code 1
> > 
> > make[5]: stopped in /usr/src/lib/libproc
> > --- libproc.a ---
> > ranlib -D libproc.a
> > [...]
> > 
> > oh




signature.asc
Description: PGP signature

Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

2014-10-04 Thread Ryan Stone

On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston  wrote:
> On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote:
>> Recent sources (Revision: 272529) fail to compile:
>>
>> [...]
>> cc -m32 -march=native -DCOMPAT_32BIT  -isystem 
>> /usr/obj/usr/src/lib32/usr/include/
>> -L/usr/obj/usr/src/lib32/usr/lib32  -B/usr/obj/usr/src/lib32/usr/lib32  -O2 
>> -pipe -O3 -O3
>> -pipe  -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 
>> -fstack-protector
>> -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body 
>> -Wno-string-plus-int
>> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
>> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
>> -Wno-switch
>> -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses 
>> -Qunused-arguments
>> -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- all_subdir_libproc 
>> --- ---
>> libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping
>> incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for
>
> I'm confused by this message. Are you building with -DNO_CLEAN? Do you
> have anything in make.conf or src.conf, especially anything that's
> changed since libctf was rebuilt?
>
> You might try rebuilding libctf with
>
> $ cd /usr/src
> $ make -C cddl/lib/libctf clean all
>
> but I'm not sure why ld is ignoring the existing libctf.so.

The failure is coming while building the lib32 compat libraries.  Are
we not currently building a lib32 libctf.so?
___
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: Looping during boot-up process in FreeBSD-11 current

2014-10-04 Thread Alexander V. Chernikov

On 01.10.2014 02:02, Mike. wrote:
> On 9/30/2014 at 7:25 PM JosÃ© PÃ©rez Arauzo wrote:
> 
> 
> |[snip]
> |Try the 271146,
> |[snip]
>  =

This might be related with r271207.
Can you try r271206 (or any recent HEAD with reverted r271207) ?

> 
> 
> I installed the 10.0 release CD.
> 
> Then (after installing pkg, svn, etc.):
> 
> 
> cd /usr/src
> 
> svn update -r271146
> 
> make buildkernel
> 
> make installkernel
> 
> reboot
> 
> 
> I got to the login prompt, so it did not exhibit the looping issue
> I've experienced.
> 
> /usr/src/UPDATING shows  20140708 p7  as the latest patch for the
> source.
> 
> dmesg (with boot -v) follows:
> (note: when I boot 11.0-current with boot -v, the looping begins
> right after the place where the "GEOM: new disk cd0" line appears in
> the dmesg below)
> 
> 
> 
> 
> Copyright (c) 1992-2014 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> 1994
>   The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 10.0-RELEASE-p7 #0 r271146: Tue Sep 30 16:38:12 EDT 2014
> root@a31pf:/usr/obj/usr/src/sys/GENERIC i386
> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
> Preloaded elf kernel "/boot/kernel/kernel" at 0xc1678000.
> Calibrating TSC clock ... TSC clock: 1698592154 Hz
> CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz (1698.59-MHz 686-class
> CPU)
>   Origin = "GenuineIntel"  Id = 0xf24  Family = 0xf  Model =
> 0x2  Stepping = 4
>   Features=0x3febf9ff E,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM>
> 
> Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 64
> entries
> Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries
> 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64
> byte line size
> Trace cache: 12K-uops, 8-way set associative
> 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64
> byte line size
> real memory  = 1073741824 (1024 MB)
> Physical memory chunk(s):
> 0x1000 - 0x0009dfff, 643072 bytes (157 pages)
> 0x0010 - 0x003f, 3145728 bytes (768 pages)
> 0x01826000 - 0x3ee0efff, 1029607424 bytes (251369
> pages)
> avail memory = 1029230592 (981 MB)
> XEN: CPU 0 has VCPU ID 4294967295
> bios32: Found BIOS32 Service Directory header at 0xc00f7030
> bios32: Entry = 0xfd7e0 (c00fd7e0)  Rev = 0  Len = 1
> pcibios: PCI BIOS entry at 0xfd770+0x18e
> pnpbios: Found PnP BIOS data at 0xc00f7090
> pnpbios: Entry = f:9d76  Rev = 1.0
> pnpbios: Event flag at 4b4
> Other BIOS signatures found:
> ULE: setup cpu 0
> wlan: <802.11 Link Layer>
> snd_unit_init() u=0x00ff8000 [512] d=0x7c00 [32]
> c=0x03ff [1024]
> feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5
> feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25
> Hardware, VIA Nehemiah Padlock RNG: VIA Padlock RNG not present
> Hardware, Intel IvyBridge+ RNG: RDRAND is not present
> kbd: new array size 4
> kbd1 at kbdmux0
> mem: 
> Pentium Pro MTRR support enabled
> nfslock: pseudo-device
> null: 
> Falling back to  random adaptor
> random:  initialized
> VESA: INT 0x10 vector 0xc000:0x206c
> VESA: information block
>    56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00
> 0010   00 01 ff 03 00 01 19 01 00 01 2f 01 00 01 34 01
> 0020   00 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01
> 0030   94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01
> 0040   b2 01 b3 01 b4 01 b5 01 b6 01 c2 01 c3 01 c4 01
> 0050   c5 01 c6 01 00 01 83 01 84 01 85 01 86 01 01 01
> 0060   10 01 11 01 12 01 21 01 03 01 13 01 14 01 15 01
> 0070   22 01 05 01 16 01 17 01 18 01 23 01 07 01 19 01
> 0080   1a 01 1b 01 24 01 40 01 41 01 42 01 43 01 44 01
> 0090   72 01 73 01 74 01 75 01 76 01 ff ff 00 00 00 00
> 00a0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00b0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00c0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00d0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00e0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00f0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0100   41 54 49 20 4d 4f 42 49 4c 49 54 59 20 52 41 44
> 0110   45 4f 4e 20 37 35 30 30 00 41 54 49 20 54 65 63
> 0120   68 6e 6f 6c 6f 67 69 65 73 20 49 6e 63 2e 00 50
> 0130   37 20 20 00 30 31 2e 30 30 00 00 00 00 00 00 00
> 0140   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0150   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0160   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0170   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0180   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0190   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 01a0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 01b0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 01c0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 01d0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 01e0   00 00 00 00

Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

2014-10-04 Thread Mark Johnston

On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote:
> On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston  wrote:
> > On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote:
> >> Recent sources (Revision: 272529) fail to compile:
> >>
> >> [...]
> >> cc -m32 -march=native -DCOMPAT_32BIT  -isystem 
> >> /usr/obj/usr/src/lib32/usr/include/
> >> -L/usr/obj/usr/src/lib32/usr/lib32  -B/usr/obj/usr/src/lib32/usr/lib32  
> >> -O2 -pipe -O3 -O3
> >> -pipe  -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 
> >> -fstack-protector
> >> -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body 
> >> -Wno-string-plus-int
> >> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
> >> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
> >> -Wno-switch
> >> -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses 
> >> -Qunused-arguments
> >> -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- 
> >> all_subdir_libproc --- ---
> >> libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping
> >> incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for
> >
> > I'm confused by this message. Are you building with -DNO_CLEAN? Do you
> > have anything in make.conf or src.conf, especially anything that's
> > changed since libctf was rebuilt?
> >
> > You might try rebuilding libctf with
> >
> > $ cd /usr/src
> > $ make -C cddl/lib/libctf clean all
> >
> > but I'm not sure why ld is ignoring the existing libctf.so.
> 
> The failure is coming while building the lib32 compat libraries.  Are
> we not currently building a lib32 libctf.so?

No, we do. One thing I've noticed is that cddl/lib is built after lib/
when compiling 32-bit libs, whereas cddl/lib is built first when building
natively. But that doesn't cause any problems for me. I also don't see
why ld would be searching /usr/obj/usr/src/tmp for a 32-bit lib.
___
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: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

2014-10-04 Thread Mark Johnston

On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston  wrote:
> On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote:
>> On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston  wrote:
>> > On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote:
>> >> Recent sources (Revision: 272529) fail to compile:
>> >>
>> >> [...]
>> >> cc -m32 -march=native -DCOMPAT_32BIT  -isystem 
>> >> /usr/obj/usr/src/lib32/usr/include/
>> >> -L/usr/obj/usr/src/lib32/usr/lib32  -B/usr/obj/usr/src/lib32/usr/lib32  
>> >> -O2 -pipe -O3 -O3
>> >> -pipe  -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 
>> >> -fstack-protector
>> >> -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body 
>> >> -Wno-string-plus-int
>> >> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
>> >> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
>> >> -Wno-switch
>> >> -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses 
>> >> -Qunused-arguments
>> >> -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- 
>> >> all_subdir_libproc --- ---
>> >> libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping
>> >> incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for
>> >
>> > I'm confused by this message. Are you building with -DNO_CLEAN? Do you
>> > have anything in make.conf or src.conf, especially anything that's
>> > changed since libctf was rebuilt?
>> >
>> > You might try rebuilding libctf with
>> >
>> > $ cd /usr/src
>> > $ make -C cddl/lib/libctf clean all
>> >
>> > but I'm not sure why ld is ignoring the existing libctf.so.
>>
>> The failure is coming while building the lib32 compat libraries.  Are
>> we not currently building a lib32 libctf.so?
>
> No, we do. One thing I've noticed is that cddl/lib is built after lib/
> when compiling 32-bit libs, whereas cddl/lib is built first when building
> natively.

Sorry, that's not even true. I misread a part of Makefile.inc1.

I'm still not able to reproduce the problem, but it seems that the
patch here is appropriate:
http://people.freebsd.org/~markj/patches/libctf_prebuild.diff

Oliver, could you give this a try?
___
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: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

2014-10-04 Thread Russell L. Carter

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 10/04/14 15:58, Mark Johnston wrote:
> On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston 
> wrote:
>> On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote:
>>> On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston
>>>  wrote:
 On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote:
> Recent sources (Revision: 272529) fail to compile:
> 
> [...] cc -m32 -march=native -DCOMPAT_32BIT  -isystem
> /usr/obj/usr/src/lib32/usr/include/ 
> -L/usr/obj/usr/src/lib32/usr/lib32
> -B/usr/obj/usr/src/lib32/usr/lib32  -O2 -pipe -O3 -O3 -pipe
> -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99
> -fstack-protector -Wsystem-headers -Werror
> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
> -Wno-unused-const-variable -Wno-tautological-compare
> -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-enum-conversion -Wno-switch 
> -Wno-switch-enum -Wno-knr-promoted-parameter
> -Wno-parentheses -Qunused-arguments -c
> /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o ---
> all_subdir_libproc --- --- libproc.so.3 ---
> /usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible
> /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for
 
 I'm confused by this message. Are you building with
 -DNO_CLEAN? Do you have anything in make.conf or src.conf,
 especially anything that's changed since libctf was rebuilt?
 
 You might try rebuilding libctf with
 
 $ cd /usr/src $ make -C cddl/lib/libctf clean all
 
 but I'm not sure why ld is ignoring the existing libctf.so.
>>> 
>>> The failure is coming while building the lib32 compat
>>> libraries.  Are we not currently building a lib32 libctf.so?
>> 
>> No, we do. One thing I've noticed is that cddl/lib is built after
>> lib/ when compiling 32-bit libs, whereas cddl/lib is built first
>> when building natively.
> 
> Sorry, that's not even true. I misread a part of Makefile.inc1.
> 
> I'm still not able to reproduce the problem, but it seems that the 
> patch here is appropriate: 
> http://people.freebsd.org/~markj/patches/libctf_prebuild.diff
> 
> Oliver, could you give this a try?

Even poudriere can't get past this one.

Russell
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUMIWTAAoJEFnLrGVSDFaEPNkP/i0eo+rmHzyT9qH7F+iJOn8r
2WbN7OKT8Q086nI/rtHAqEeOiIUkXPhxfQiU2zrjXt551zgrAsfdqe39P6kLm1ha
L3yA3joVkjLdWwpDMKEUtm9EChVG//rM258xWKhSTnGBnw4Qvtzy458SdAIXap3J
HjTMJfZ95QuWanoK0HIN0glVoXdO/gVjmifm4CMmRKpKESjsU3vvCckbqDBim0Vi
kmSWhL+dHucaX4b/8hQ/Csn6AKIZoo6LNw8cphZGS9dAvf+0f4PKCZ2KJhwV61TE
rCi5AstFYoWgCk3LKAxMR4bquvtNusTvT5YokDQ4qMwwpihNR8PL6C5IP3bo/RkI
tp4x959Yq5b7RVmmU7IDTQlWA5WoiQMYDGj/HC4iMkfBHzf7Cxl4sl4/HZwJ3fXu
TkCm/EKKyah3heS/wF4tKx4npjBLu6+rWJLFdhCTLS2PWmdMNzBUB65vFrvdTEZl
EFWpiITuV0Dd3Kb46s/Jm/26X1UMZRnKDJEMGtEauJj7hfwoR35+ym/WxI0PnMsz
b4x+NxdPWQbOlRX3pnumcGVI1fuaRMJ8Dbdof7r/CXQITzZjHgbXVvZ0nnAh67L3
Om1G8be2w0jXfTPDI7qQxHIQfoua95VYMdvOcq48mnq3kDSuU+y3BUXamnqsrWqT
K3N72p7T3F/8TsmiFzAI
=IbPc
-END PGP SIGNATURE-
___
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 Failure

2014-10-04 Thread Shawn Webb

It looks like buildworld is failing when building the rescue binaries. I'm
not sure which commit broke it. Log is here:
http://0xfeedface.org/~shawn/2014-10-04-build.txt

Thanks,

Shawn
___
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: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

2014-10-04 Thread Mark Johnston

On Sat, Oct 04, 2014 at 04:41:07PM -0700, Russell L. Carter wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> 
> On 10/04/14 15:58, Mark Johnston wrote:
> > On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston 
> > wrote:
> >> On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote:
> >>> On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston
> >>>  wrote:
>  On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote:
> > Recent sources (Revision: 272529) fail to compile:
> > 
> > [...] cc -m32 -march=native -DCOMPAT_32BIT  -isystem
> > /usr/obj/usr/src/lib32/usr/include/ 
> > -L/usr/obj/usr/src/lib32/usr/lib32
> > -B/usr/obj/usr/src/lib32/usr/lib32  -O2 -pipe -O3 -O3 -pipe
> > -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99
> > -fstack-protector -Wsystem-headers -Werror
> > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
> > -Wno-unused-const-variable -Wno-tautological-compare
> > -Wno-unused-value -Wno-parentheses-equality
> > -Wno-unused-function -Wno-enum-conversion -Wno-switch 
> > -Wno-switch-enum -Wno-knr-promoted-parameter
> > -Wno-parentheses -Qunused-arguments -c
> > /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o ---
> > all_subdir_libproc --- --- libproc.so.3 ---
> > /usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible
> > /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for
>  
>  I'm confused by this message. Are you building with
>  -DNO_CLEAN? Do you have anything in make.conf or src.conf,
>  especially anything that's changed since libctf was rebuilt?
>  
>  You might try rebuilding libctf with
>  
>  $ cd /usr/src $ make -C cddl/lib/libctf clean all
>  
>  but I'm not sure why ld is ignoring the existing libctf.so.
> >>> 
> >>> The failure is coming while building the lib32 compat
> >>> libraries.  Are we not currently building a lib32 libctf.so?
> >> 
> >> No, we do. One thing I've noticed is that cddl/lib is built after
> >> lib/ when compiling 32-bit libs, whereas cddl/lib is built first
> >> when building natively.
> > 
> > Sorry, that's not even true. I misread a part of Makefile.inc1.
> > 
> > I'm still not able to reproduce the problem, but it seems that the 
> > patch here is appropriate: 
> > http://people.freebsd.org/~markj/patches/libctf_prebuild.diff
> > 
> > Oliver, could you give this a try?
> 
> Even poudriere can't get past this one.

Sorry, it was incomplete. It's been updated:
http://people.freebsd.org/~markj/patches/libctf_prebuild.diff
___
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"

BAFUG Oct 9: Kyua and jenkins testing framework

2014-10-04 Thread Craig Rodrigues

Hi,

On October 9, 2014, in Mountain View, California, I will be giving a brief
tech tech on:

"Kyua and Jenkins: Testing Framework for BSD"

Here are more details on the tak, plus directions to the location:

http://www.meetup.com/BAFUG-Bay-Area-FreeBSD-User-Group/events/209548642/

Feel free to sign up on the meetup site and attend if you are in the area,
so that the organizers can get a big enough room.

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

Jenkins and LLVM clang analyzer on FreeBSD

2014-10-04 Thread Craig Rodrigues

Hi,

FYI, Li-Wen Hsu  has set up this Jenkins job which
builds FreeBSD
with the clang analyzer (
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-scan-build/ ):

https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-scan-build/

This job runs once a week.  Please view the results of this job, and provide
feedback to:  freebsd-test...@freebsd.org.

Also, if you can see any bugs in FreeBSD identified by this tool,
please feel free to submit patches to fix them! :)

Thank you Li-Wen, for setting this up!!
--
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: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

2014-10-04 Thread Arseny Nasokin

Mark,

Thank you for patch, I encounter same error and this patch works for me.

✪


-- Eir Nym

On 5 October 2014 04:43, Mark Johnston  wrote:

> On Sat, Oct 04, 2014 at 04:41:07PM -0700, Russell L. Carter wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> >
> >
> > On 10/04/14 15:58, Mark Johnston wrote:
> > > On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston 
> > > wrote:
> > >> On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote:
> > >>> On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston
> > >>>  wrote:
> >  On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote:
> > > Recent sources (Revision: 272529) fail to compile:
> > >
> > > [...] cc -m32 -march=native -DCOMPAT_32BIT  -isystem
> > > /usr/obj/usr/src/lib32/usr/include/
> > > -L/usr/obj/usr/src/lib32/usr/lib32
> > > -B/usr/obj/usr/src/lib32/usr/lib32  -O2 -pipe -O3 -O3 -pipe
> > > -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99
> > > -fstack-protector -Wsystem-headers -Werror
> > > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> > > -Wno-unused-const-variable -Wno-tautological-compare
> > > -Wno-unused-value -Wno-parentheses-equality
> > > -Wno-unused-function -Wno-enum-conversion -Wno-switch
> > > -Wno-switch-enum -Wno-knr-promoted-parameter
> > > -Wno-parentheses -Qunused-arguments -c
> > > /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o ---
> > > all_subdir_libproc --- --- libproc.so.3 ---
> > > /usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible
> > > /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for
> > 
> >  I'm confused by this message. Are you building with
> >  -DNO_CLEAN? Do you have anything in make.conf or src.conf,
> >  especially anything that's changed since libctf was rebuilt?
> > 
> >  You might try rebuilding libctf with
> > 
> >  $ cd /usr/src $ make -C cddl/lib/libctf clean all
> > 
> >  but I'm not sure why ld is ignoring the existing libctf.so.
> > >>>
> > >>> The failure is coming while building the lib32 compat
> > >>> libraries.  Are we not currently building a lib32 libctf.so?
> > >>
> > >> No, we do. One thing I've noticed is that cddl/lib is built after
> > >> lib/ when compiling 32-bit libs, whereas cddl/lib is built first
> > >> when building natively.
> > >
> > > Sorry, that's not even true. I misread a part of Makefile.inc1.
> > >
> > > I'm still not able to reproduce the problem, but it seems that the
> > > patch here is appropriate:
> > > http://people.freebsd.org/~markj/patches/libctf_prebuild.diff
> > >
> > > Oliver, could you give this a try?
> >
> > Even poudriere can't get past this one.
>
> Sorry, it was incomplete. It's been updated:
> http://people.freebsd.org/~markj/patches/libctf_prebuild.diff
> ___
> 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: About pmap_mapdev() & pmap_unmapdev()

2014-10-04 Thread Kohji Okuno

Hi,

> On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote:
>> Hi Konstantin,
>> 
>> Thank you for your prompt response.
>> I will test and report from next monday.
>> 
>> >> In addtion, I have one question.
>> >> In current and 10-stable, is vm_map_delete() called by kva_free()?
>> > No, kva_free() only releases the vmem backing, leaving the page
>> > tables intact.  This is why I only did the stable/9 patch.
>> 
>> Where are PTEs allocated by pmap_mapdev() freed in current and 10-stable?
>> Could you please explain me?
> They are not freed. The removal of the vmem which covers the address
> space managed by corresponding ptes, allows the reuse of both KVA region
> and corresponding PTEs in the tables. The only concern with the resident
> page tables is to avoid two kva_alloc() to step over each other, and
> this is ensured by vmem.

I agree that normal pages are reusable. But, since the pages mapped by
pmap_mapdev() are concerned with the physicall address of device (For
example: video memory), these PTEs aren't reusable, I think.
So, should we free these PTEs by pmap_unmapdev()?

Best regards,
 Kohji Okuno

___
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: About pmap_mapdev() & pmap_unmapdev()

Re: About pmap_mapdev() & pmap_unmapdev()

Re: i915 driver update testing

Re: About pmap_mapdev() & pmap_unmapdev()

Re: About pmap_mapdev() & pmap_unmapdev()

Re: i915 driver update testing

sh.core in HOME of the user on system shutdown

Re: About pmap_mapdev() & pmap_unmapdev()

HEADS UP: Merging projects/ipfw to HEAD

Re: About pmap_mapdev() & pmap_unmapdev()

CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

bwn(4) testing

Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support

Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

Re: Looping during boot-up process in FreeBSD-11 current

Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

Buildworld Failure

Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

BAFUG Oct 9: Kyua and jenkins testing framework

Jenkins and LLVM clang analyzer on FreeBSD

Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]

Re: About pmap_mapdev() & pmap_unmapdev()

26 matches

Site Navigation

Mail list logo

Footer information