Re: VirtualBox network connectivity broken on recent -CURRENT

[Otacílio]

Em 04/06/2016 23:04, Randy Westlund escreveu:

On Fri, Jun 03, 2016 at 05:11:24PM -0700, Don Lewis wrote:

It looks like something changed in -CURRENT to break network
connectivity to VirtualBox guests.  This was last known to work with
r299139 (May 6th) and is definitely broken with r301229.

I've been having VirtualBox networking problems as well.  I can't get my
VMs on the network recently, but I don't recall when it last worked.
Everything looks right from the guest (the arp cache shows the
VirtualBox NAT router), but tcpdump on the host shows no traffic.  I
haven't had time to investigate further :/


I'm running rev 301210 guest and here looks working.

[ota@nostromo /usr/home/ota]$ uname -a
FreeBSD nostromo 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #0 r301210: Fri Jun  3 
01:24:19 BRT 2016 ota@nostromo:/usr/obj/usr/src/sys/NOSTROMO  amd64

[ota@nostromo /usr/home/ota]$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=54 time=91.683 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=67.433 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=52.106 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=153.091 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 52.106/91.078/153.091/38.483 ms
[ota@nostromo /usr/home/ota]$ wget
bash: wget: comando não encontrado
[ota@nostromo /usr/home/ota]$ telnet www.google.com 80
Trying 216.58.218.4...
Connected to www.google.com.
Escape character is '^]'.
GET index.html
HTTP/1.0 404 Not Found
Content-Type: text/html; charset=UTF-8
Content-Length: 1561
Date: Sun, 05 Jun 2016 03:01:55 GMT



  
  

  Error 404 (Not Found)!!1
  

Re: VirtualBox network connectivity broken on recent -CURRENT

[Matthew Macy]

  On Sat, 04 Jun 2016 19:04:42 -0700 Randy Westlund  
wrote  
 > On Fri, Jun 03, 2016 at 05:11:24PM -0700, Don Lewis wrote: 
 > > It looks like something changed in -CURRENT to break network 
 > > connectivity to VirtualBox guests.  This was last known to work with 
 > > r299139 (May 6th) and is definitely broken with r301229. 
 >  
 > I've been having VirtualBox networking problems as well.  I can't get my 
 > VMs on the network recently, but I don't recall when it last worked. 
 > Everything looks right from the guest (the arp cache shows the 
 > VirtualBox NAT router), but tcpdump on the host shows no traffic.  I 
 > haven't had time to investigate further :/ 
 > 

The odds of it being fixed will increase greatly if someone would do a bisect 
and test.
-M

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: VirtualBox network connectivity broken on recent -CURRENT

[Randy Westlund]

On Fri, Jun 03, 2016 at 05:11:24PM -0700, Don Lewis wrote:
> It looks like something changed in -CURRENT to break network
> connectivity to VirtualBox guests.  This was last known to work with
> r299139 (May 6th) and is definitely broken with r301229.

I've been having VirtualBox networking problems as well.  I can't get my
VMs on the network recently, but I don't recall when it last worked.
Everything looks right from the guest (the arp cache shows the
VirtualBox NAT router), but tcpdump on the host shows no traffic.  I
haven't had time to investigate further :/


signature.asc
Description: PGP signature

Re: VirtualBox network connectivity broken on recent -CURRENT

[Don Lewis]

On  4 Jun, Alan Somers wrote:
> On Fri, Jun 3, 2016 at 6:43 PM, Don Lewis  wrote:
>> On  3 Jun, Don Lewis wrote:
>>> It looks like something changed in -CURRENT to break network
>>> connectivity to VirtualBox guests.  This was last known to work with
>>> r299139 (May 6th) and is definitely broken with r301229.  The VirtualBox
>>> port revisions are:
>>>   virtualbox-ose-4.3.38_1
>>>   virtualbox-ose-kmod-4.3.38
>>> It looks like there was one change to the VirtualBox on May 9th, but it
>>> looks unlikely to be the cause of the problem.
>>>
>>> The network settings are:
>>>   Attached to: Bridged Adapter
>>>   Name: re0
>>>   Adapter Type: Paravirtualized Network (virtio-net)
>>>   Promiscuous Mode: Deny
>>>   MAC Address: [snip]
>>> Ifconfig says that the interface is up, but I am unable to ping either
>>> the host or anything else on the LAN from the guest.  It looks like the
>>> problem is with outbound traffic.  If I attempt to ping the guest, the
>>> source IP address and MAC address show up in the guest's arp table, but
>>> ping reports:
>>>   ping: sendto: Host is down
>>> That makes me think that the arp responses from the guest are not
>>> getting transmitted.  None of the machines involved are running
>>> firewalls.  If I ping from the guest, I don't see any arp requests on
>>> the wire and the arp command shows the table entry as incomplete.
>>>
>>> The problem shows up with both FreeBSD -CURRENT and Debian guests.
>>
>> I see the same behaviour if I set:
>> Attached to: NAT
>> or
>> Adapter Type: 82540EM
>>
> 
> Might be related to this routing bug:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207831

Doesn't look like it.  The questionable commit there seems to be
r293159.  I didn't see breakage until after r299139.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: VirtualBox network connectivity broken on recent -CURRENT

[Alan Somers]

On Fri, Jun 3, 2016 at 6:43 PM, Don Lewis  wrote:
> On  3 Jun, Don Lewis wrote:
>> It looks like something changed in -CURRENT to break network
>> connectivity to VirtualBox guests.  This was last known to work with
>> r299139 (May 6th) and is definitely broken with r301229.  The VirtualBox
>> port revisions are:
>>   virtualbox-ose-4.3.38_1
>>   virtualbox-ose-kmod-4.3.38
>> It looks like there was one change to the VirtualBox on May 9th, but it
>> looks unlikely to be the cause of the problem.
>>
>> The network settings are:
>>   Attached to: Bridged Adapter
>>   Name: re0
>>   Adapter Type: Paravirtualized Network (virtio-net)
>>   Promiscuous Mode: Deny
>>   MAC Address: [snip]
>> Ifconfig says that the interface is up, but I am unable to ping either
>> the host or anything else on the LAN from the guest.  It looks like the
>> problem is with outbound traffic.  If I attempt to ping the guest, the
>> source IP address and MAC address show up in the guest's arp table, but
>> ping reports:
>>   ping: sendto: Host is down
>> That makes me think that the arp responses from the guest are not
>> getting transmitted.  None of the machines involved are running
>> firewalls.  If I ping from the guest, I don't see any arp requests on
>> the wire and the arp command shows the table entry as incomplete.
>>
>> The problem shows up with both FreeBSD -CURRENT and Debian guests.
>
> I see the same behaviour if I set:
> Attached to: NAT
> or
> Adapter Type: 82540EM
>

Might be related to this routing bug:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207831
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: repeatable panic on pageout with 945GM

[Michael Butler]

On 06/04/16 15:02, Konstantin Belousov wrote:
> On Sat, Jun 04, 2016 at 02:59:01PM -0400, Michael Butler wrote:
>> On 06/04/16 13:47, Konstantin Belousov wrote:
>>
>>  [ .. snip .. ]
>>
>>> I believe that this is a bug in amd64 pmap. Fictitious pages are not
>>> promoted, in particular, the pv_table array does not span over the
>>> dynamically registered fictitious ranges. As result, pa_to_pvh() returns
>>> garbage and pvh must not be accessed in the case of 'small_mappings' in
>>> several pmap functions.  It is typically not accessed, except in case
>>> when we have to drop and reacquire pv lock, to avoid LOR with pmap.
>>>
>>> i386 does not have the issue, due to pvh_global_lock.
>>>
>>> Below is the supposed fix (not tested).
>>
>>  [ .. snip .. ]
>>
>> Is this something I should test and, should it not introduce any other
>> issues, might get committed?
> 
> Would be nice to test.  I expect that this patch is going to be committed,
> after the review.
> 

I will do so this evening and add a kprintf to the previous band-aid to
see if it prevents the problematic condition from occurring.

If it counts, my test laptop has a Core-2 Duo so it is entirely possible
that multiple threads are running concurrently,

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: repeatable panic on pageout with 945GM

[Konstantin Belousov]

On Sat, Jun 04, 2016 at 02:59:01PM -0400, Michael Butler wrote:
> On 06/04/16 13:47, Konstantin Belousov wrote:
> 
>  [ .. snip .. ]
> 
> > I believe that this is a bug in amd64 pmap. Fictitious pages are not
> > promoted, in particular, the pv_table array does not span over the
> > dynamically registered fictitious ranges. As result, pa_to_pvh() returns
> > garbage and pvh must not be accessed in the case of 'small_mappings' in
> > several pmap functions.  It is typically not accessed, except in case
> > when we have to drop and reacquire pv lock, to avoid LOR with pmap.
> > 
> > i386 does not have the issue, due to pvh_global_lock.
> > 
> > Below is the supposed fix (not tested).
> 
>  [ .. snip .. ]
> 
> Is this something I should test and, should it not introduce any other
> issues, might get committed?

Would be nice to test.  I expect that this patch is going to be committed,
after the review.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: repeatable panic on pageout with 945GM

[Michael Butler]

On 06/04/16 13:47, Konstantin Belousov wrote:

 [ .. snip .. ]

> I believe that this is a bug in amd64 pmap. Fictitious pages are not
> promoted, in particular, the pv_table array does not span over the
> dynamically registered fictitious ranges. As result, pa_to_pvh() returns
> garbage and pvh must not be accessed in the case of 'small_mappings' in
> several pmap functions.  It is typically not accessed, except in case
> when we have to drop and reacquire pv lock, to avoid LOR with pmap.
> 
> i386 does not have the issue, due to pvh_global_lock.
> 
> Below is the supposed fix (not tested).

 [ .. snip .. ]

Is this something I should test and, should it not introduce any other
issues, might get committed?

imb

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: repeatable panic on pageout with 945GM

[Matthew Macy]

 >  
 > I believe that this is a bug in amd64 pmap. Fictitious pages are not 
 > promoted, in particular, the pv_table array does not span over the 
 > dynamically registered fictitious ranges. As result, pa_to_pvh() returns 
 > garbage and pvh must not be accessed in the case of 'small_mappings' in 
 > several pmap functions.  It is typically not accessed, except in case 
 > when we have to drop and reacquire pv lock, to avoid LOR with pmap. 
 
Cool. Thanks for explaining that.

-M


 > i386 does not have the issue, due to pvh_global_lock. 
 >  
 > Below is the supposed fix (not tested). 
 >  
 > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c 
 > index 7a93e76..e514b07 100644 
 > --- a/sys/amd64/amd64/pmap.c 
 > +++ b/sys/amd64/amd64/pmap.c 
 > @@ -3947,12 +3947,14 @@ small_mappings: 
 >  while ((pv = TAILQ_FIRST(>md.pv_list)) != NULL) { 
 >  pmap = PV_PMAP(pv); 
 >  if (!PMAP_TRYLOCK(pmap)) { 
 > -pvh_gen = pvh->pv_gen; 
 > +if ((m->flags & PG_FICTITIOUS) == 0) 
 > +pvh_gen = pvh->pv_gen; 
 >  md_gen = m->md.pv_gen; 
 >  rw_wunlock(lock); 
 >  PMAP_LOCK(pmap); 
 >  rw_wlock(lock); 
 > -if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) { 
 > +if (((m->flags & PG_FICTITIOUS) == 0 && 
 > +pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) { 
 >  rw_wunlock(lock); 
 >  PMAP_UNLOCK(pmap); 
 >  goto retry; 
 > @@ -5775,13 +5777,14 @@ small_mappings: 
 >  TAILQ_FOREACH(pv, >md.pv_list, pv_next) { 
 >  pmap = PV_PMAP(pv); 
 >  if (!PMAP_TRYLOCK(pmap)) { 
 > -pvh_gen = pvh->pv_gen; 
 > +if ((m->flags & PG_FICTITIOUS) == 0) 
 > +pvh_gen = pvh->pv_gen; 
 >  md_gen = m->md.pv_gen; 
 >  rw_wunlock(lock); 
 >  PMAP_LOCK(pmap); 
 >  rw_wlock(lock); 
 > -if (pvh_gen != pvh->pv_gen || 
 > -md_gen != m->md.pv_gen) { 
 > +if (((m->flags & PG_FICTITIOUS) == 0 && 
 > +pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) { 
 >  PMAP_UNLOCK(pmap); 
 >  rw_wunlock(lock); 
 >  goto retry_pv_loop; 
 > @@ -5985,12 +5988,14 @@ small_mappings: 
 >  pvf = pv; 
 >  pmap = PV_PMAP(pv); 
 >  if (!PMAP_TRYLOCK(pmap)) { 
 > -pvh_gen = pvh->pv_gen; 
 > +if ((m->flags & PG_FICTITIOUS) == 0) 
 > +pvh_gen = pvh->pv_gen; 
 >  md_gen = m->md.pv_gen; 
 >  rw_wunlock(lock); 
 >  PMAP_LOCK(pmap); 
 >  rw_wlock(lock); 
 > -if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) { 
 > +if (((m->flags & PG_FICTITIOUS) == 0 && 
 > +pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) { 
 >  PMAP_UNLOCK(pmap); 
 >  goto retry; 
 >  } 
 > @@ -6248,11 +6253,13 @@ small_mappings: 
 >  pmap = PV_PMAP(pv); 
 >  if (!PMAP_TRYLOCK(pmap)) { 
 >  md_gen = m->md.pv_gen; 
 > -pvh_gen = pvh->pv_gen; 
 > +if ((m->flags & PG_FICTITIOUS) == 0) 
 > +pvh_gen = pvh->pv_gen; 
 >  rw_wunlock(lock); 
 >  PMAP_LOCK(pmap); 
 >  rw_wlock(lock); 
 > -if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) { 
 > +if (((m->flags & PG_FICTITIOUS) == 0 && 
 > +pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) { 
 >  PMAP_UNLOCK(pmap); 
 >  goto restart; 
 >  } 
 > 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: repeatable panic on pageout with 945GM

[Konstantin Belousov]

On Sat, Jun 04, 2016 at 10:02:33AM -0700, Matthew Macy wrote:
> 
> 
> 
>  
>  >  
>  > This "band-aid" seems to have worked. I haven't had a single panic since 
>  > - Thanks! :-) 
>  >  
>  > I tried to compile with -O0 but, for some reason, it panics in the sound 
>  > driver with a double-fault. When I get time, I'll recompile only the 
>  > files involved and see if I can't get a decent trace (and dump) to 
>  > identify the cause, 
>  
> No need. Based on the line that it crashed at, the problem is that with no 
> mappings no pv_entry has been allocated. Somehow on your laptop you're able 
> to get in to a situation where fictitious pages have been added to the object 
> that don't get mapped. This isn't a strange situation in and of itself, but 
> you seem to be the only hitting this. 
> 
> In any event, the DRM 4.6 port will support AGP in about a week. It will 
> probably have bugs, but this one isn't in any of its code paths.
> 
> 
> I'm glad your system works a bit better now.
> 

I believe that this is a bug in amd64 pmap. Fictitious pages are not
promoted, in particular, the pv_table array does not span over the
dynamically registered fictitious ranges. As result, pa_to_pvh() returns
garbage and pvh must not be accessed in the case of 'small_mappings' in
several pmap functions.  It is typically not accessed, except in case
when we have to drop and reacquire pv lock, to avoid LOR with pmap.

i386 does not have the issue, due to pvh_global_lock.

Below is the supposed fix (not tested).

diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 7a93e76..e514b07 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
@@ -3947,12 +3947,14 @@ small_mappings:
while ((pv = TAILQ_FIRST(>md.pv_list)) != NULL) {
pmap = PV_PMAP(pv);
if (!PMAP_TRYLOCK(pmap)) {
-   pvh_gen = pvh->pv_gen;
+   if ((m->flags & PG_FICTITIOUS) == 0)
+   pvh_gen = pvh->pv_gen;
md_gen = m->md.pv_gen;
rw_wunlock(lock);
PMAP_LOCK(pmap);
rw_wlock(lock);
-   if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) {
+   if (((m->flags & PG_FICTITIOUS) == 0 &&
+   pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) {
rw_wunlock(lock);
PMAP_UNLOCK(pmap);
goto retry;
@@ -5775,13 +5777,14 @@ small_mappings:
TAILQ_FOREACH(pv, >md.pv_list, pv_next) {
pmap = PV_PMAP(pv);
if (!PMAP_TRYLOCK(pmap)) {
-   pvh_gen = pvh->pv_gen;
+   if ((m->flags & PG_FICTITIOUS) == 0)
+   pvh_gen = pvh->pv_gen;
md_gen = m->md.pv_gen;
rw_wunlock(lock);
PMAP_LOCK(pmap);
rw_wlock(lock);
-   if (pvh_gen != pvh->pv_gen ||
-   md_gen != m->md.pv_gen) {
+   if (((m->flags & PG_FICTITIOUS) == 0 &&
+   pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) {
PMAP_UNLOCK(pmap);
rw_wunlock(lock);
goto retry_pv_loop;
@@ -5985,12 +5988,14 @@ small_mappings:
pvf = pv;
pmap = PV_PMAP(pv);
if (!PMAP_TRYLOCK(pmap)) {
-   pvh_gen = pvh->pv_gen;
+   if ((m->flags & PG_FICTITIOUS) == 0)
+   pvh_gen = pvh->pv_gen;
md_gen = m->md.pv_gen;
rw_wunlock(lock);
PMAP_LOCK(pmap);
rw_wlock(lock);
-   if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) {
+   if (((m->flags & PG_FICTITIOUS) == 0 &&
+   pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) {
PMAP_UNLOCK(pmap);
goto retry;
}
@@ -6248,11 +6253,13 @@ small_mappings:
pmap = PV_PMAP(pv);
if (!PMAP_TRYLOCK(pmap)) {
md_gen = m->md.pv_gen;
-   pvh_gen = pvh->pv_gen;
+   if ((m->flags & PG_FICTITIOUS) == 0)
+   pvh_gen = pvh->pv_gen;
rw_wunlock(lock);
PMAP_LOCK(pmap);
rw_wlock(lock);
-   if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) {
+   if (((m->flags & PG_FICTITIOUS) == 0 &&
+   pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) {
   

Re: svn commit: r301394 - head [If X_COMPILER_TYPE is defined, do not use it, otherwise use it?]

[Bryan Drewery]

On 6/4/2016 10:35 AM, Mark Millard wrote:
> From the commit report:
> 
>> +.if defined(X_COMPILER_TYPE)
>>  CROSSENV+=  COMPILER_VERSION=${COMPILER_VERSION} \
>>  COMPILER_TYPE=${COMPILER_TYPE} \
>>  COMPILER_FREEBSD_VERSION=${COMPILER_FREEBSD_VERSION}
> 
> This does not use X_COMPILER_TYPE when it is defined.
> 
>> +.else
>> +CROSSENV+=  COMPILER_VERSION=${X_COMPILER_VERSION} \
>> +COMPILER_TYPE=${X_COMPILER_TYPE} \
>> +COMPILER_FREEBSD_VERSION=${X_COMPILER_FREEBSD_VERSION}
> 
> This tries to use the undefined X_COMPILER_TYPE.
> 
>> +.endif
> 
> 
> 
> Overall:
> 
> A not seems to be missing or instead the nested code blocks need to be 
> swapped.
> 

I'm an idiot, thanks.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

svn commit: r301394 - head [If X_COMPILER_TYPE is defined, do not use it, otherwise use it?]

[Mark Millard]

>From the commit report:

> +.if defined(X_COMPILER_TYPE)
>  CROSSENV+=   COMPILER_VERSION=${COMPILER_VERSION} \
>   COMPILER_TYPE=${COMPILER_TYPE} \
>   COMPILER_FREEBSD_VERSION=${COMPILER_FREEBSD_VERSION}

This does not use X_COMPILER_TYPE when it is defined.

> +.else
> +CROSSENV+=   COMPILER_VERSION=${X_COMPILER_VERSION} \
> + COMPILER_TYPE=${X_COMPILER_TYPE} \
> + COMPILER_FREEBSD_VERSION=${X_COMPILER_FREEBSD_VERSION}

This tries to use the undefined X_COMPILER_TYPE.

> +.endif



Overall:

A not seems to be missing or instead the nested code blocks need to be swapped.


===
Mark Millard
markmi at dsl-only.net

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r300951: mountroot: waiting for device /dev/ad4s1a...

[Warren Block]

On Sat, 4 Jun 2016, Matthias Apitz wrote:


El día Saturday, June 04, 2016 a las 02:41:48PM +0200, Michael Gmelin escribió:


It's also covered in UPDATING:

20151011:
Compatibility shims for legacy ATA device names have been
removed. It includes ATA_STATIC_ID kernel option,
kern.cam.ada.legacy_aliases and kern.geom.raid.legacy_aliases
loader tunables, kern.devalias.* environment variables, /dev/ad*
and /dev/ar* symbolic links.



Next time I will do read UPDATING. Thanks for your help.


Use labels so there are no static device names at all.  With MBR, the 
options are limited, but UFS labels work and have no metadata problems:


http://www.wonkity.com/~wblock/docs/html/labels.html

GPT has very nice partition labels that can be set with gpart -l.  It 
works with i386 and BIOS booting.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64]

[Bryan Drewery]

On 6/4/2016 12:17 AM, Mark Millard wrote:
> On 2016-Jun-2, at 12:36 PM, Bryan Drewery  wrote:
> 
>> On 6/1/2016 6:39 PM, Mark Millard wrote:
>>> while filemon.ko now exists:
 # ls -l /boot/*/filemon*
 -r-xr-xr-x  1 root  wheel  32064 Jun  1 17:59 /boot/kernel/filemon.ko
>>> it does not load:
 # kldload -n filemon
 kldload: can't load filemon: No such file or directory
 # dmesg | grep link_elf
 link_elf: symbol elf64_freebsd_sysvec undefined
>>> So no WITH_META_MODE=yes yet for powerpc64.
>>
>>
>> Please try this patch: http://dpaste.com/37VP5MD.txt
>>
>> And once you have filemon loaded please run this basic test script.  It
>> should return no output and a zero exit status.
>>
>> http://dpaste.com/23NTA0A.txt
>>
>> Just sh file it.
>>
>> -- 
>> Regards,
>> Bryan Drewery
> 
> Unfortunately other things interfered and I was unable to do this before 
> temporarily losing access to the powerpc and powerpc64 boxes --for what will 
> probably be weeks or months.
> 

No problem...

> So for now it is the end of my native-testing for powerpc64 and powerpc.
> 
> I do not know if anyone else has an appropriate context and willingness to do 
> this specific test or not.
> 
> For the duration I should still be able to do amd64 -> powerpc64 or powerpc 
> cross builds (buildworld buildkernel), although likely with less time and 
> more delay for doing so.
> 
> I am hoping to still have rpi2 access for armv6/v7 native use. But I've yet 
> to make the soft-float to hard-float leap: I focused primarily on the 
> powerpc64 and powerpc use, knowing up front of the pending 
> temporarily-unavailable status.
> 
> 
> 
> Thanks for all the work on the build system by you and others. Originally I 
> had a bunch of workarounds in my src.conf files to avoid problems that 
> occurred for the likes of a libc++-based, xtoolchain-based so-called "cross 
> build" (self-hosted), powerpc64 environment (no gcc 4.2.1 and clang not 
> working for such yet). Far more works implicitly in src.conf files for such a 
> context now.
> 

Thanks for all of the testing and feedback!


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: latest memstick image fails to mountroot by default on Thinkpad e565

[Matthew Macy]

  On Sat, 04 Jun 2016 06:03:49 -0700 Edward Tomasz Napierała 
 wrote  
 > Dnia 04.06.2016 o godz. 07:52 Matthew Macy  napisał(a):
 > 
 > > 
 > > In order to boot USB reliably on recent laptop hardware (both my thinkpad  
 > > and XPS13 need this) you need to add the following to the installer images 
 > > loader.conf:
 > > 
 > > kern.cam.boot_delay="1"
 > > kern.cam.scsi_delay="3000"
 > 
 > What happens when you don't?  I mean, what are the console messages?
 
It times out on mountroot. It doesn't do it every time. The first time I tried 
to reproduce this morning it actually worked. I've attached an image.

-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: repeatable panic on pageout with 945GM

[Matthew Macy]

 
 >  
 > This "band-aid" seems to have worked. I haven't had a single panic since 
 > - Thanks! :-) 
 >  
 > I tried to compile with -O0 but, for some reason, it panics in the sound 
 > driver with a double-fault. When I get time, I'll recompile only the 
 > files involved and see if I can't get a decent trace (and dump) to 
 > identify the cause, 
 
No need. Based on the line that it crashed at, the problem is that with no 
mappings no pv_entry has been allocated. Somehow on your laptop you're able to 
get in to a situation where fictitious pages have been added to the object that 
don't get mapped. This isn't a strange situation in and of itself, but you seem 
to be the only hitting this. 

In any event, the DRM 4.6 port will support AGP in about a week. It will 
probably have bugs, but this one isn't in any of its code paths.


I'm glad your system works a bit better now.

Cheers.

-M

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r300951: mountroot: waiting for device /dev/ad4s1a...

[Matthias Apitz]

El día Saturday, June 04, 2016 a las 02:41:48PM +0200, Michael Gmelin escribió:

> It's also covered in UPDATING:
> 
> 20151011:
> Compatibility shims for legacy ATA device names have been
> removed. It includes ATA_STATIC_ID kernel option,
> kern.cam.ada.legacy_aliases and kern.geom.raid.legacy_aliases
> loader tunables, kern.devalias.* environment variables, /dev/ad*
> and /dev/ar* symbolic links.
> 

Next time I will do read UPDATING. Thanks for your help.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
"Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer 
Gesellschaft bzw.
sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." 
(jW 19.05.2016)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: PostgreSQL performance on FreeBSD

[John Baldwin]

On Friday, June 03, 2016 11:29:03 AM Adrian Chadd wrote:
> On 3 June 2016 at 11:27, Adrian Chadd  wrote:
> 
> > That and the other NUMA stuff is something to address in -12.
> 
> And, I completely welcome continued development in NUMA scaling in
> combination with discussion. The iterator changes I committed are a
> more generic version of a patch people were applying on top of -10 and
> -head for at least what, three years now? Maybe more if -9 also just
> did round-robin and not first-touch?

8 and 9 did first-touch.  Only 10 did round-robin.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: repeatable panic on pageout with 945GM

[Michael Butler]

On 06/02/16 22:31, Matthew Macy wrote:
> Tell me if that makes any difference.
> 
> -M
> 
> 
>   On Thu, 02 Jun 2016 16:55:53 -0700 K. Macy  wrote 
>  
>  > It looks like it might be trying to remove mappings for a page that 
> doesn't 
>  > have any. It's a bit odd. Likely a bug in cdev_pager_free_page or gem 
>  > release mmap. Compile the kernel and driver with -O0 and look at the page. 
>  > It's too bad I don't support AGP yet with DRM 4.6. Maybe in a week or two. 
> 
> 
> 
>  diff --git a/sys/vm/device_pager.c b/sys/vm/device_pager.c
> index 013f0d5..917ece7 100644
> --- a/sys/vm/device_pager.c
> +++ b/sys/vm/device_pager.c
> @@ -211,7 +211,8 @@ cdev_pager_free_page(vm_object_t object, vm_page_t m)
> VM_OBJECT_ASSERT_WLOCKED(object);
> if (object->type == OBJT_MGTDEVICE) {
> KASSERT((m->oflags & VPO_UNMANAGED) == 0, ("unmanaged %p", 
> m));
> -   pmap_remove_all(m);
> +   if (pmap_page_is_mapped(page))
> +   pmap_remove_all(m);
> vm_page_lock(m);
> vm_page_remove(m);
> vm_page_unlock(m);
> 

This "band-aid" seems to have worked. I haven't had a single panic since
- Thanks! :-)

I tried to compile with -O0 but, for some reason, it panics in the sound
driver with a double-fault. When I get time, I'll recompile only the
files involved and see if I can't get a decent trace (and dump) to
identify the cause,

imb


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: latest memstick image fails to mountroot by default on Thinkpad e565

[Edward Tomasz Napierała]

Dnia 04.06.2016 o godz. 07:52 Matthew Macy  napisał(a):

> 
> In order to boot USB reliably on recent laptop hardware (both my thinkpad  
> and XPS13 need this) you need to add the following to the installer images 
> loader.conf:
> 
> kern.cam.boot_delay="1"
> kern.cam.scsi_delay="3000"

What happens when you don't?  I mean, what are the console messages?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r300951: mountroot: waiting for device /dev/ad4s1a...

[Michael Gmelin]

On Sat, 4 Jun 2016 14:01:34 +0200
Matthias Apitz  wrote:

> El día Saturday, June 04, 2016 a las 01:54:30PM +0200, Michael Gmelin
> escribió:
> 
> > 
> > On Sat, 4 Jun 2016 13:48:52 +0200
> > Matthias Apitz  wrote:
> >   
> > > > Did you do a full clean build?
> > > > GENERIC or custom kernel config?
> > > 
> > > yes, clean 'make buildkernel KERNCONF=GENERIC'  
> > And then 'make installkernel KERNCONF=GENERIC' I suppose.  
> 
> yes, ofc :-)
> 
> > > interestingly: I can type at the prompt 'mountroot> ' into the
> > > dark and always when I press Ctrl the chars are written to the
> > > screen and so I can specify 'ufs:/dev/ad4s1a' which than leads to
> > > the same error 19.  
> > 
> > Did you try ufs:/dev/ada0s1a?  
> 
> no, but now and it worked; I will adjust /etc/fstab; but why is this?
> 

The SATA subsystem was changed to use cam back in 2012 [1], which
changed device numbering from adX to ada0, ada1.

Back then, a sysctl called kern.cam.ada.legacy_aliases, which is
enabled by default, was provided for backwards compatibility.

Some research shows that this feature was removed in r289137 [2]

It's also covered in UPDATING:

20151011:
Compatibility shims for legacy ATA device names have been
removed. It includes ATA_STATIC_ID kernel option,
kern.cam.ada.legacy_aliases and kern.geom.raid.legacy_aliases
loader tunables, kern.devalias.* environment variables, /dev/ad*
and /dev/ar* symbolic links.

- Michael

[1] https://www.freebsd.org/releases/9.0R/relnotes-detailed.html
(see 3.2.3)
[2] https://svnweb.freebsd.org/base?view=revision=289137

-- 
Michael Gmelin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r300951: mountroot: waiting for device /dev/ad4s1a...

[Matthias Apitz]

El día Saturday, June 04, 2016 a las 01:54:30PM +0200, Michael Gmelin escribió:

> 
> On Sat, 4 Jun 2016 13:48:52 +0200
> Matthias Apitz  wrote:
> 
> > > Did you do a full clean build?
> > > GENERIC or custom kernel config?  
> > 
> > yes, clean 'make buildkernel KERNCONF=GENERIC'
> And then 'make installkernel KERNCONF=GENERIC' I suppose.

yes, ofc :-)

> > interestingly: I can type at the prompt 'mountroot> ' into the dark
> > and always when I press Ctrl the chars are written to the screen and
> > so I can specify 'ufs:/dev/ad4s1a' which than leads to the same error
> > 19.
> 
> Did you try ufs:/dev/ada0s1a?

no, but now and it worked; I will adjust /etc/fstab; but why is this?

Thanks

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
"Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer 
Gesellschaft bzw.
sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." 
(jW 19.05.2016)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r300951: mountroot: waiting for device /dev/ad4s1a...

[Michael Gmelin]

On Sat, 4 Jun 2016 13:48:52 +0200
Matthias Apitz  wrote:

> Hi Michael,
> 
> El día Saturday, June 04, 2016 a las 01:40:46PM +0200, Michael Gmelin
> escribió:
> 
> > Hi Matthias,
> > 
> > Did you try to connect an external USB keyboard?  
> 
> no; it uses the laptop onboard keyboard;
> 
> > i386 or amd64?  
> 
> i386;
> 
> > Did you do a full clean build?
> > GENERIC or custom kernel config?  
> 
> yes, clean 'make buildkernel KERNCONF=GENERIC'
And then 'make installkernel KERNCONF=GENERIC' I suppose.

> 
> interestingly: I can type at the prompt 'mountroot> ' into the dark
> and always when I press Ctrl the chars are written to the screen and
> so I can specify 'ufs:/dev/ad4s1a' which than leads to the same error
> 19.

Did you try ufs:/dev/ada0s1a?

-m

> 
> I can as well boot an USB key with the old kernel r269739, mount
> /dev/ad4s1a to /mnt, all fine; I did even a fsck while booted from USB
> on /dev/ad4s1a. The FS is clean.
> 
>   matthias
> 



-- 
Michael Gmelin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD_amd64_gcc - Build #1274 - Failure

[jenkins-admin]

FreeBSD_HEAD_amd64_gcc - Build #1274 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1274/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1274/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1274/console

Change summaries:

301309 by arybchik:
sfxge(4): always be ready to receive batched events

When the low-latency firmware variant is running, it is reported as not
being capable of batching RX events, but it can still do so if the
FORCE_EV_MERGING flag is set on an RXQ.  Therefore we need to handle
batched RX events even if the capability isn't set.

If this bug is fixed in the firmware such that the capability is set
even when running the low-latency firmware variant, it will almost
always be reported so I don't think we lose much by removing the check.

Submitted by:   Mark Spender 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week
Differential Revision:  https://reviews.freebsd.org/D6705

301308 by arybchik:
sfxge(4): add helper to compute timer quantum

This also adjusts the timer values used to match the Linux net
driver implementation:
a) non-zero time intervals should result in at least one quantum
b) timer load/reload values are only zero biased for Falcon/Siena

Submitted by:   Andy Moreton 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  1 week
Differential Revision:  https://reviews.freebsd.org/D6704

301307 by adrian:
[ath] remove now unused parameters.

These will move to being part of the driver btcoex stuff I'm working
on, since the HAL doesn't know what to do with them.

301306 by andrew:
Use the UEFI event timer to update the time on arm and arm64. The current
code uses the GetTime function from the Runtime Service, however this has
been shown to not return a useable time on many arm64 UEFI implementations.

Reviewed by:jhb, smh
Sponsored by:   ABT Systems Ltd
Differential Revision:  https://reviews.freebsd.org/D6709

301305 by adrian:
[ath_hal] add STOMP_AUDIO for AR9462/QCA9565.

Obtained from:  Linux ath9k

301304 by adrian:
[ath_hal] add placeholders for AUDIO stomp for Kite/Kiwi.

It just stomps all; which is enough for some testing.

301303 by adrian:
[ath_hal] add BTCOEX_STOMP_AUDIO; delete unused methods.

301302 by adrian:
[run] fix TSF locking in RX radiotap.

Submitted by:   Imre Vadasz 

301300 by cem:
ioat(4): Always log capabilities on attach

Different, relatively recent Intel Xeon hardware support radically different
features.  E.g., BDX support CRC32 while BDX-DE does not.

Reviewed by:rpokala (spiritually)
Sponsored by:   EMC / Isilon Storage Division

301297 by cem:
ioat(4): Export the number of available channels

Sponsored by:   EMC / Isilon Storage Division

301296 by cem:
ioat(4): Make channel indices unsigned

Sponsored by:   EMC / Isilon Storage Division

301295 by cy:
Enable daily_ntpd_leapfile_enable by default. Otherwise an expired
leapfile will be ignored and ntpd will behave as if it has no
leapfile.

While here, remove an extraneous blank line.

Suggested by:   ache
MFC after:  1 week

301293 by mav:
When negotiating NTB_SB01BASE_LOCKUP workaround, don't try to limit the
BAR size to 1MB.  According to Xeon v3 specifications and my tests, that
size register is write-once and so not writeable after BIOS written it.

Instead of that, make the code work with BAR of any sufficient size,
properly calculating offset within its base.  It also simplifies the code.

Discussed with: cem
MFC after:  2 weeks
Sponsored by:   iXsystems, Inc.

301292 by mav:
When negotiating MSIX parameters, give other head time to see our
NTB_MSIX_RECEIVED status, before making upper layers overwrite it.

This is not completely perfect, but now it works better then before.

MFC after:  2 weeks
Sponsored by:   iXsystems, Inc.

301291 by pfg:
libiberty: prevent integer overflow.

Take care of very old bug leading to heap-buffer overflow by
processing certain file headers via bfd binary.

PR: 200888
Obtained from:  OpenBSD
MFC after:  2 weeks

301290 by bdrewery:
WITH_META_MODE: Avoid "building" .depend if there is nothing to do.

This avoids 'Building /path/.depend' when it will not actually produce a
file.

Sponsored by:   EMC / Isilon Storage Division

301289 by pfg:
MFV r300961:
one-true-awk: replace 0 with NULL for pointers

Also remove a redundant semicolon.

301288 by pfg:
tegra124: use roundup/rounddown macros from .

301287 by bdrewery:
WITHOUT_CROSS_COMPILER: Fix installworld.

Since no WORLDTMP/usr/bin/cc is created, cc cannot be found
during installworld time since /usr/bin is not in the PATH.
Pass along the known compiler metadata to allow installworld
to work.  The same fix was used for WITH_SYSTEM_COMPILER.

A better route would be to store a cookie in buildworld
containing this compiler metadata and then using that
at install time, rather than rerunning cc.

Reported by:Mark Millard

Re: r300951: mountroot: waiting for device /dev/ad4s1a...

[Matthias Apitz]

Hi Michael,

El día Saturday, June 04, 2016 a las 01:40:46PM +0200, Michael Gmelin escribió:

> Hi Matthias,
> 
> Did you try to connect an external USB keyboard?

no; it uses the laptop onboard keyboard;

> i386 or amd64?

i386;

> Did you do a full clean build?
> GENERIC or custom kernel config?

yes, clean 'make buildkernel KERNCONF=GENERIC'

interestingly: I can type at the prompt 'mountroot> ' into the dark and
always when I press Ctrl the chars are written to the screen and so I can
specify 'ufs:/dev/ad4s1a' which than leads to the same error 19.

I can as well boot an USB key with the old kernel r269739, mount
/dev/ad4s1a to /mnt, all fine; I did even a fsck while booted from USB
on /dev/ad4s1a. The FS is clean.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
"Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer 
Gesellschaft bzw.
sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." 
(jW 19.05.2016)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r300951: mountroot: waiting for device /dev/ad4s1a...

[Michael Gmelin]

Hi Matthias,

Did you try to connect an external USB keyboard?
i386 or amd64?
Did you do a full clean build?
GENERIC or custom kernel config?

- m

On Sat, 4 Jun 2016 13:28:06 +0200
Matthias Apitz  wrote:

> El día Saturday, June 04, 2016 a las 12:18:26PM +0200, Matthias Apitz
> escribió:
> 
> > 
> > Hello,
> > 
> > I'm trying to update my laptop Acer Aspire One D250 from r269739 to
> > r300951. After 'make installkernel' it hangs for ever on reboot,
> > waiting for the device /dev/ad4s1a. The old kernel boots fine.  
> 
> short before mounting root are two error messages:
> 
> taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0
> taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0
> Timecounter "TSC" frequency 1596219540 Hz quality 1000
> Trying to mount root drom ufs:/dev/ad4s1a [rw]...
> mountroot: waiting for device /dev/ad4s1a ...
> Mounting from ufs:/dev/ad4s1a failed with error 19.
> 
> Than it goes into the manual dialog to specify the root device but at
> the prompt 
> 
> mountroot>  
> 
> the kernel does not echo any typed chars;
> 
>   matthias



-- 
Michael Gmelin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r300951: mountroot: waiting for device /dev/ad4s1a...

[Matthias Apitz]

El día Saturday, June 04, 2016 a las 12:18:26PM +0200, Matthias Apitz escribió:

> 
> Hello,
> 
> I'm trying to update my laptop Acer Aspire One D250 from r269739 to
> r300951. After 'make installkernel' it hangs for ever on reboot, waiting
> for the device /dev/ad4s1a. The old kernel boots fine.

short before mounting root are two error messages:

taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0
taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0
Timecounter "TSC" frequency 1596219540 Hz quality 1000
Trying to mount root drom ufs:/dev/ad4s1a [rw]...
mountroot: waiting for device /dev/ad4s1a ...
Mounting from ufs:/dev/ad4s1a failed with error 19.

Than it goes into the manual dialog to specify the root device but at
the prompt 

mountroot>

the kernel does not echo any typed chars;

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
"Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer 
Gesellschaft bzw.
sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." 
(jW 19.05.2016)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r300951: mountroot: waiting for device /dev/ad4s1a...

[Matthias Apitz]

Hello,

I'm trying to update my laptop Acer Aspire One D250 from r269739 to
r300951. After 'make installkernel' it hangs for ever on reboot, waiting
for the device /dev/ad4s1a. The old kernel boots fine.

What can I do?
Thx

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
"Die Verkaufsschlager des Buchmarkts geben Auskunft über den Zustand einer 
Gesellschaft bzw.
sind, was diese Zeiten angeht, Gradmesser fortschreitenden Schwachsinns. ..." 
(jW 19.05.2016)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: thread suspension when dumping core

[Konstantin Belousov]

On Fri, Jun 03, 2016 at 07:23:47PM -0700, Mark Johnston wrote:
> Hi,
> 
> I've recently observed a hang in a multi-threaded process that had hit
> an assertion failure and was attempting to dump core. One thread was
> sleeping interruptibly on an advisory lock with TDF_SBDRY set (our
> filesystem sets VFCF_SBDRY). SIGABRT caused the receipient thread to
> suspend other threads with thread_single(SINGLE_NO_EXIT), which fails
> to interrupt the sleeping thread, resulting in the hang.
> 
> My question is, why does the SA_CORE handler not force all threads to
> the user boundary before attempting to dump core? It must do so later
> anyway in order to exit. As I understand it, TDF_SBDRY is intended to
> avoid deadlocks that can occur when stopping a process, but in this
> case we don't stop the process with the intention of resuming it, so it
> seems erroneous to apply this flag.

Does your fs both set TDF_SBDRY and call lf_advlock()/lf_advlockasync() ?
This cannot work, regardless of the mode of single-threading.  TDF_SBDRY
makes such sleep non-interruptible by any single-threading request, on
the promise that the thread owns some resources (typically vnode locks).
I.e. changing the mode would not help.

I see two reasons to use SINGLE_NO_EXIT for coredumping.  It allows
coredump writer to record more exact state of the process into the notes.

Another one is that SINGLE_NO_EXIT is generally faster and more
reliable than SINGLE_BOUNDARY. Some states are already good enough for
SINGLE_NO_EXIT, while require more work to get into SINGLE_BOUNDARY. In
other words, core dump write starts earlier.

It might be not very significant reasons. 

>From what I see in the code, our NFS client has similar issue of calling
lf_advlock() with TDF_SBDRY set.  Below is the patch to fix that.
Similar bug existed in our fifofs, see r277321.

diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c
index 2a8afa9..98625ee 100644
--- a/sys/fs/nfsclient/nfs_clvnops.c
+++ b/sys/fs/nfsclient/nfs_clvnops.c
@@ -2992,7 +2992,7 @@ nfs_advlock(struct vop_advlock_args *ap)
struct proc *p = (struct proc *)ap->a_id;
struct thread *td = curthread;  /* XXX */
struct vattr va;
-   int ret, error = EOPNOTSUPP;
+   int sbdry, ret, error = EOPNOTSUPP;
u_quad_t size;

if (NFS_ISV4(vp) && (ap->a_flags & (F_POSIX | F_FLOCK)) != 0) {
@@ -3087,7 +3087,10 @@ nfs_advlock(struct vop_advlock_args *ap)
if ((VFSTONFS(vp->v_mount)->nm_flag & NFSMNT_NOLOCKD) != 0) {
size = VTONFS(vp)->n_size;
NFSVOPUNLOCK(vp, 0);
+   sbdry = sigallowstop();
error = lf_advlock(ap, &(vp->v_lockf), size);
+   if (sbdry)
+   sigdeferstop();
} else {
if (nfs_advlock_p != NULL)
error = nfs_advlock_p(ap);
@@ -3114,7 +3117,7 @@ nfs_advlockasync(struct vop_advlockasync_args *ap)
 {
struct vnode *vp = ap->a_vp;
u_quad_t size;
-   int error;
+   int error, sbdry;

if (NFS_ISV4(vp))
return (EOPNOTSUPP);
@@ -3124,7 +3127,10 @@ nfs_advlockasync(struct vop_advlockasync_args *ap)
if ((VFSTONFS(vp->v_mount)->nm_flag & NFSMNT_NOLOCKD) != 0) {
size = VTONFS(vp)->n_size;
NFSVOPUNLOCK(vp, 0);
+   sbdry = sigallowstop();
error = lf_advlockasync(ap, &(vp->v_lockf), size);
+   if (sbdry)
+   sigdeferstop();
} else {
NFSVOPUNLOCK(vp, 0);
error = EOPNOTSUPP;
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r301305: buildkernel fails in ATH driver: if_ath_btcoex.c:237:9: error: no member named 'bt_period' in 'HAL_BT_COEX_INFO

[O. Hartmann]

Am Sat, 4 Jun 2016 01:56:40 -0700
Adrian Chadd  schrieb:

> Fixed!
> 
> 
> -a
> 
> 
> On 4 June 2016 at 01:11, O. Hartmann  wrote:
> > r301305 fails to buildkernel this morning with the lates updates.
> >
> > See below
> >
> >  [...]
> > cc  -O2 -pipe -O3 -O3 -pipe -march=native  -fno-strict-aliasing -Werror 
> > -D_KERNEL
> > -DKLD_MODULE -nostdinc  -I. -I/usr/src/sys/modules/ath/../../dev/ath
> > -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -I.
> > -I/usr/src/sys/modules/ath/../../contrib/dev/ath/ath_hal/ 
> > -DHAVE_KERNEL_OPTION_HEADERS
> > -include /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I/usr/src/sys 
> > -fno-common
> > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
> > -I/usr/obj/usr/src/sys/THOR  -MD
> > -MF.depend.if_ath_btcoex_mci.o -MTif_ath_btcoex_mci.o -mcmodel=kernel 
> > -mno-red-zone
> > -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
> > -ffreestanding -fwrapv
> > -fstack-protector -Wall -Wredundant-decls -Wnested-externs 
> > -Wstrict-prototypes
> > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
> > -Wno-pointer-sign
> > -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
> > -fdiagnostics-show-option
> > -Wno-unknown-pragmas  -Wno-error-tautological-compare -Wno-error-empty-body
> > -Wno-error-parentheses-equality -Wno-error-unused-function  
> > -Wno-error-pointer-sign
> > -Wno-error-shift-negative-value  -mno-aes -mno-avx  -std=iso9899:1999
> > -c /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex_mci.c -o 
> > if_ath_btcoex_mci.o
> > --- if_ath_btcoex.o --- 
> > /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex.c:236:9:
> > error: no member named 'bt_dutyCycle' in 'HAL_BT_COEX_INFO' 
> > btinfo.bt_dutyCycle = 55;
> > ~~ ^ /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex.c:237:9: 
> > error: no
> > member named 'bt_period' in 'HAL_BT_COEX_INFO' btinfo.bt_period = 40; 
> > ~~ ^ 2
> > errors generated.
> >
> >
> > Regards,
> >
> > o.h.  
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Great! Thank you.


pgpQIX9mYHF9o.pgp
Description: OpenPGP digital signature

Re: r301305: buildkernel fails in ATH driver: if_ath_btcoex.c:237:9: error: no member named 'bt_period' in 'HAL_BT_COEX_INFO

[Adrian Chadd]

Fixed!


-a


On 4 June 2016 at 01:11, O. Hartmann  wrote:
> r301305 fails to buildkernel this morning with the lates updates.
>
> See below
>
>  [...]
> cc  -O2 -pipe -O3 -O3 -pipe -march=native  -fno-strict-aliasing -Werror 
> -D_KERNEL
> -DKLD_MODULE -nostdinc  -I. -I/usr/src/sys/modules/ath/../../dev/ath
> -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -I.
> -I/usr/src/sys/modules/ath/../../contrib/dev/ath/ath_hal/ 
> -DHAVE_KERNEL_OPTION_HEADERS
> -include /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I/usr/src/sys -fno-common
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
> -I/usr/obj/usr/src/sys/THOR  -MD
> -MF.depend.if_ath_btcoex_mci.o -MTif_ath_btcoex_mci.o -mcmodel=kernel 
> -mno-red-zone
> -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
> -ffreestanding -fwrapv
> -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
> -Wno-pointer-sign
> -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
> -fdiagnostics-show-option
> -Wno-unknown-pragmas  -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function  
> -Wno-error-pointer-sign
> -Wno-error-shift-negative-value  -mno-aes -mno-avx  -std=iso9899:1999
> -c /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex_mci.c -o 
> if_ath_btcoex_mci.o ---
> if_ath_btcoex.o --- 
> /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex.c:236:9: error:
> no member named 'bt_dutyCycle' in 'HAL_BT_COEX_INFO' btinfo.bt_dutyCycle = 
> 55; ~~
> ^ /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex.c:237:9: error: no 
> member named
> 'bt_period' in 'HAL_BT_COEX_INFO' btinfo.bt_period = 40; ~~ ^ 2 errors 
> generated.
>
>
> Regards,
>
> o.h.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r301305: buildkernel fails in ATH driver: if_ath_btcoex.c:237:9: error: no member named 'bt_period' in 'HAL_BT_COEX_INFO

[O. Hartmann]

r301305 fails to buildkernel this morning with the lates updates.

See below

 [...]
cc  -O2 -pipe -O3 -O3 -pipe -march=native  -fno-strict-aliasing -Werror 
-D_KERNEL
-DKLD_MODULE -nostdinc  -I. -I/usr/src/sys/modules/ath/../../dev/ath
-I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -I.
-I/usr/src/sys/modules/ath/../../contrib/dev/ath/ath_hal/ 
-DHAVE_KERNEL_OPTION_HEADERS
-include /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I/usr/src/sys -fno-common
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I/usr/obj/usr/src/sys/THOR  -MD
-MF.depend.if_ath_btcoex_mci.o -MTif_ath_btcoex_mci.o -mcmodel=kernel 
-mno-red-zone
-mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding 
-fwrapv
-fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option
-Wno-unknown-pragmas  -Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign
-Wno-error-shift-negative-value  -mno-aes -mno-avx  -std=iso9899:1999
-c /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex_mci.c -o 
if_ath_btcoex_mci.o ---
if_ath_btcoex.o --- 
/usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex.c:236:9: error:
no member named 'bt_dutyCycle' in 'HAL_BT_COEX_INFO' btinfo.bt_dutyCycle = 55; 
~~
^ /usr/src/sys/modules/ath/../../dev/ath/if_ath_btcoex.c:237:9: error: no 
member named
'bt_period' in 'HAL_BT_COEX_INFO' btinfo.bt_period = 40; ~~ ^ 2 errors 
generated.


Regards,

o.h.


pgphmgZw8IGRa.pgp
Description: OpenPGP digital signature

Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads

[Maxim Sobolev]

Yeah, indeed false positive, app error. Sorry for noise and thanks for
feedback.

-Max
On Jun 3, 2016 10:18 AM, "Konstantin Belousov"  wrote:

> On Fri, Jun 03, 2016 at 08:04:29AM -0700, Maxim Sobolev wrote:
> > Konstantin,
> >
> > Thanks for taking your time looking into it and sorry for somewhat messy
> > problem report. I've been trying to fix that problem all day yesterday
> > thinking it's just application logic that is broken and indeed has been
> > able to find some bigger issues that were obscuring this one. But it got
> > very frustrating when the bug popped out anew at a seemingly lower level
> > now. The issue that triggered this is in some high level python code.
> Which
> > makes it quite difficult to narrow and isolate. There is still slight
> > chance that it's something about threading within the python that screws
> > this up somehow, however I don't quite see how that could lead to a
> > consistent result that is just off by few hundred microseconds and not in
> > some random garbage.
> >
> > So, I take from you message, that high level
> > clock_gettime(CLOCK_MONOTONIC*) is supposed to be monotonic with respect
> to
> > the wall time even when called in different threads? I always though it
> is,
> > but was not 100% sure about that and wanted to confirm it before I dive
> > deeper into this and spend more time writing a test case to expose this.
> Yes, CLOCK_MONOTONIC should be monotonic across all processors.
> Until the time travel is made possible, of course.
>
> > The test case you gave me is interesting, but somewhat low-level. What I
> > would do if it comes to it, is to make something that uses pthreads and
> > plain clock_gettime(2). Should not be too difficult to reproduce if it's
> > real issue.
> The test I give you verifies clock_gettime() in several threads going
> backward.
>
> >
> > P.S. I've also tried kern.timecounter.fast_gettime=0, made no difference.
> > Assuming it does not take a reboot to test it. Neither does
> > switching kern.timecounter.hardware, I've tested TSC-low(1000)
> > ACPI-fast(900) HPET(950) i8254(0), all are the same.
> I am almost sure this is app-level issue.
>
> To make me confident, run the test I provided.
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64]

[Mark Millard]

On 2016-Jun-2, at 12:36 PM, Bryan Drewery  wrote:

> On 6/1/2016 6:39 PM, Mark Millard wrote:
>> while filemon.ko now exists:
>>> # ls -l /boot/*/filemon*
>>> -r-xr-xr-x  1 root  wheel  32064 Jun  1 17:59 /boot/kernel/filemon.ko
>> it does not load:
>>> # kldload -n filemon
>>> kldload: can't load filemon: No such file or directory
>>> # dmesg | grep link_elf
>>> link_elf: symbol elf64_freebsd_sysvec undefined
>> So no WITH_META_MODE=yes yet for powerpc64.
> 
> 
> Please try this patch: http://dpaste.com/37VP5MD.txt
> 
> And once you have filemon loaded please run this basic test script.  It
> should return no output and a zero exit status.
> 
> http://dpaste.com/23NTA0A.txt
> 
> Just sh file it.
> 
> -- 
> Regards,
> Bryan Drewery

Unfortunately other things interfered and I was unable to do this before 
temporarily losing access to the powerpc and powerpc64 boxes --for what will 
probably be weeks or months.

So for now it is the end of my native-testing for powerpc64 and powerpc.

I do not know if anyone else has an appropriate context and willingness to do 
this specific test or not.

For the duration I should still be able to do amd64 -> powerpc64 or powerpc 
cross builds (buildworld buildkernel), although likely with less time and more 
delay for doing so.

I am hoping to still have rpi2 access for armv6/v7 native use. But I've yet to 
make the soft-float to hard-float leap: I focused primarily on the powerpc64 
and powerpc use, knowing up front of the pending temporarily-unavailable status.



Thanks for all the work on the build system by you and others. Originally I had 
a bunch of workarounds in my src.conf files to avoid problems that occurred for 
the likes of a libc++-based, xtoolchain-based so-called "cross build" 
(self-hosted), powerpc64 environment (no gcc 4.2.1 and clang not working for 
such yet). Far more works implicitly in src.conf files for such a context now.

===
Mark Millard
markmi at dsl-only.net

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Latest freebsd installer memstick image fails to mountroot by default on Thinkpad e565

[K. Macy]

Just to clarify I'm talking about BSD install images, not my i915 tester.

On Friday, June 3, 2016, Matthew Macy  wrote:

>
> In order to boot USB reliably on recent laptop hardware (both my thinkpad
> and XPS13 need this) you need to add the following to the installer images
> loader.conf:
>
> kern.cam.boot_delay="1"
> kern.cam.scsi_delay="3000"
>
> ___
> freebsd-current@freebsd.org  mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
> "
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"