gnatcross-sysroot-aarch64

[M - Krasznai András]

Hi


I use FreeBSD on a laptop with intel I3 CPU.


I installed the base system, and a set of packages to make it a desktop system 
(xorg server, internet browser, libreoffice, gimp, rawtherapee, kdenlive, some 
pdf viewers, etc. pkg installs their dependencies automatically.


The above package is installed on my freebsd-current as a dependency - I did 
not specify it in my install scripts . The strange is that pkg autoremove 
deletes it every time as an unnecessairy package.


I would like to get rid of this package, how could I prevent it from installing?


best regards


András Krasznai



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

13-stable compile error when drm-kmod installed

[M - Krasznai András]

Good morning!

Since the end of January I experience the following problems:


1.)I need to use the drm-kmod package to reach the normal  screen 
resolution. If this package is installed then I am not able to compile the 
kernel after upgrading /usr/src, I get a "macro redefinition" error. If I 
remove the drm-kmod package with its dependencies then I can compile and 
install the kernel, and after this I can reinstall drm-kmod and everything 
works fine again.



2.)several applications (multitail just to mention one of them) complain 
about missing ncurses libraries, e.g. libpanelw.so.5, etc. which are not 
missing from the january-29 snapshot of FreeBSD 13-stable, that is after 
installing from the snapshot and installing the usual set of applications they 
do not complain about the missing libraries before updating world and the 
kernel.



Üdvözlettel

Krasznai András
rendszermérnök

[M_logo]
1136 Budapest, Pannónia utca 11.
Tel:  +36 1 703 2923
Mobil: +36 30 703 2923
Központ:  +36 1 703 2920
Fax:  +36 1 703 2949
email: krasznai.and...@mands.hu

___
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: svnlite behaviour changed?

[M - Krasznai András]

Thanks!

I did not make it very clear but the whole thing started when I used 
FreeBSD-CURRENT - that is sometime in December I observed that although the 
revision number is increased, there are no updates listed; the fact that the 
revision number is the revision of the whole repository and not the revision of 
the branch I follow explains. There was some kind of source freeze of the 
CURRENT branch if I recollect correctly the release schedule. A week ago I 
installed FreeBSD-12.2-RELEASE, but its source changes rather rarely so I again 
I got only increasing revision numbers.

Thanks again!

best regards

András Krasznai
 

 

From: David Wolfskill 
Sent: Tuesday, January 26, 2021 12:55 PM
To: M - Krasznai András
Cc: freebsd-current
Subject: Re: svnlite behaviour changed?

On Tue, Jan 26, 2021 at 09:52:15AM +, M - Krasznai András wrote:
> Good morning!
>
> I regularly sync my FreeBSD source tree with the central repository using svn 
> update. I use a one-lis script to synchonize, which  sends the output of svn 
> to a file, and also copies to the console. This list contained - according to 
> the 'svn help update' - one line for any item which was updated or inserted, 
> deleted etc and at the end it shows the (new) revision number of the 
> repository.
>
> Some time ago during december this changed: the svn output contained one line 
> only, which informed me the new revision number but I did not get listing of 
> the updated items. If there are no updated items then why is the revision 
> number increasing, or if there are updates the why aren't they listed?
>
> A week ago I installed FreeBSD-12.2-RELEASE, and now I saw the same: svn 
> update changes the revision number of the source tree, and the newly compiled 
> kernel has that revision number, but no listing of updates.  svn checkout 
> listed the files as they were read from the central repository.
>
> Is this a change of svn while the help text remained the old one,  or there 
> is a change in the svn repositories, or is this part of the move to git?
> Üdvözlettel
>
> Krasznai András
> rendszermérnök

First, please note that this list is "freebsd-current@" -- by
definition, a "release" (such as FreeBSD-12.2-RELEASE) is not "current."

Second, the revision number at the end of "svn update" is the last
revision for the entire repository -- which is NOT the same thing as
"the last revision for the branch" (that you are using).

Thus, if there are changes to other branches (but not the one you are
tracking), the revision number reported will continue to go up, but
there will be no changes to the files in your branch.

Finally, please be aware that the svn repository is no longer the
"Source of Truth" for FreeBSD.  Rather, for (recent) stable branches (<=
12), committed changes to the Source of Truth are subsequently
"replayed" into the subversion repository.  As I understand it, there
are no plans to provide this for stable/13 or subsequent branches (or
for current).

Peace,
david
--
David H. Wolfskill  da...@catwhisker.org
Some "Republicans" seem bound and determined to turn the party known for
touting "law and order" into one that supports mob rule and insurrection.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
___
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"

svnlite behaviour changed?

[M - Krasznai András]

Good morning!

I regularly sync my FreeBSD source tree with the central repository using svn 
update. I use a one-lis script to synchonize, which  sends the output of svn to 
a file, and also copies to the console. This list contained - according to the 
'svn help update' - one line for any item which was updated or inserted, 
deleted etc and at the end it shows the (new) revision number of the repository.

Some time ago during december this changed: the svn output contained one line 
only, which informed me the new revision number but I did not get listing of 
the updated items. If there are no updated items then why is the revision 
number increasing, or if there are updates the why aren't they listed?

A week ago I installed FreeBSD-12.2-RELEASE, and now I saw the same: svn update 
changes the revision number of the source tree, and the newly compiled kernel 
has that revision number, but no listing of updates.  svn checkout listed the 
files as they were read from the central repository.

Is this a change of svn while the help text remained the old one,  or there is 
a change in the svn repositories, or is this part of the move to git?
Üdvözlettel

Krasznai András
rendszermérnök

[M_logo]
1136 Budapest, Pannónia utca 11.
Tel:  +36 1 703 2923
Mobil: +36 30 703 2923
Központ:  +36 1 703 2920
Fax:  +36 1 703 2949
email: krasznai.and...@mands.hu

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

dma-resv.c: make does not know, how to compile

[M - Krasznai András]

Hi

in the last two days I was not able to compile FreeBSD-CURRENT, make stopped 
with error:

does not know, how to compile dma-resv.c

I did not find the above file in a freshly synchromized source tree (dma-resv.h 
file does exist).



Üdvözlettel / with regards

Krasznai András
rendszermérnök

[M_logo]
1136 Budapest, Pannónia utca 11.
Tel:  +36 1 703 2923
Mobil: +36 30 703 2923
Központ:  +36 1 703 2920
Fax:  +36 1 703 2949
email: krasznai.and...@mands.hu

___
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: users of drm-legacy-kmod or drm drivers from base

[M - Krasznai András]

Hi

I am experiencing the following: Firefox, Chrome, LibreOffice freezes my 
FreeBSD-CURRENT after a few seconds (the disk is used intensivey but nor 
keyboard nor mouse is working, I can move the mouse pointer but nothing happens 
when I click with any of the buttons), nothing is written on the screen. As the 
mouse seems to not work I am not able to start any other application after 
starting the above programs. before starting those programs xterm, clang, etc 
is running correctly.

Ctrl-Alt-Del kills the xorg server, and the laptop returns to the character 
based screen. I can start X again with startx, and  it behaves in the same 
manner. 

A week ago when the above first happened then (as it was recommended in 
pkg-message) recompiling xorg-server with the FIXDRM option corrected the 
problem, but as FIXDRM is now removed I am not able to use those applications.

I tried to force the usage of dri3 as recommended, but did not help.

The system is a Lenovo T510 laptop, Intel I5-M520 CPU, integrated Intel 
Graphics , FreeBSD-CURRENT #358833, ports installed from pkg repository. 




best regards

Andras Krasznai





-Eredeti üzenet-
Feladó: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Niclas Zeising
Küldve: 2020. március 8. 20:34
Címzett: x...@freebsd.org; curr...@freebsd.org; sta...@freebsd.org; 
po...@freebsd.org
Tárgy: users of drm-legacy-kmod or drm drivers from base

[ This is cross-posted across several mailing lists for maximum 
visibility.  Please respect reply-to and keep replies to x...@freebsd.org 
. Thank you! ]

In order to improve support for the new lkpi based graphics drivers 
(drm-kmod) and to improve the graphics stack we have switched mesa to 
prefer DRI3 over DRI2.  This was done in r528071.  For those using 
drm-kmod, this should improve performance somewhat, and more importantly 
alleviate the use of the FIXDRM option (now removed) in xorg-server.

However, for those of you using graphics/drm-legacy-kmod or the drm 
drivers in base, this change can cause issues.  If you are experiencing 
problems when running OpenGL applications, you can force the use of the 
DRI2 backend.

To force mesa to use DRI2, set the environment variable 
LIBGL_DRI3_DISABLE to 1 before starting any OpenGL application.  The 
easiest way to accomplish this is by adding it to either your shell 
startup file or ~/.xinitrc.

As an example, for users of [t]csh, put
setenv LIBGL_DRI3_DISABLE 1
in ~/.cshrc.

For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put
export LIBGL_DRI3_DISABLE=1
in ~/.profile

If you are using these legacy drivers, I'm also very interested in 
hearing what issues you are facing that prevents you from using the new 
lkpi based drivers.

Regards
-- 
Niclas Zeising
FreeBSD Graphics Team
___
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"

RE: DRM (i915kms) panic on r353303

[M - Krasznai András]

Hi

after the patch my X server on FreeBSD-13 works again, thanks!

best regards

András Krasznai

-Eredeti üzenet-
Feladó: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Mateusz Guzik
Küldve: 2019. október 8. 15:15
Címzett: Renato Botelho
Másolatot kap: freebsd-current
Tárgy: Re: DRM (i915kms) panic on r353303

Try this:

https://people.freebsd.org/~mjg/pmap-nosparse.diff

On 10/8/19, Renato Botelho  wrote:
> I'm not sure which revision I was before it broke.  I can try to bisect
> if necessary.
>
> I'm getting a panic as you can see on these pictures [1] after I
> upgraded my ThinkPad x230 to r353303.
>
> drm-current-kmod is in the last version and I already tried to rebuild
> it just to be sure.
>
> Any help would be much appreciated.
>
> [1] https://imgur.com/a/JmZ4uTv
> --
> Renato Botelho
>
> ___
> 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"
>


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

RE: Panic on boot with r353298 (last known working r35295)

[M - Krasznai András]

Hi

r353298 running on lenovo T510. Panics after starting X session, the panic is

panic: vm_fault, fault on nofault entry, addr: 0xfe00821a000

It is preceded by several error messages referring to 

drm_modeset_is_locked  failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm_atomic_helper.c:577. 
then line 622 and then line 821 of the same 
drm_atomic_helper.c module.


best regards

Andras Krasznai

-Eredeti üzenet-
Feladó: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Evilham
Küldve: 2019. október 8. 11:00
Címzett: FreeBSD Current
Tárgy: Panic on boot with r353298 (last known working r35295)

Hey, just a heads up that on a Lenovo A485 (AMD Ryzen processor), 
r353298 panics somewhat late in the boot process. r352925 is my 
last known working build.
I am building GENERIC-NODEBUG.

Sadly my pulse is shaky and I can't properly read the picture I 
took, it appears to say:

Fatal trap 32: page fault while in kernel mode
*something, something*
fault mode = supervisor read data, page not present

Will try to get more details and a proper dump when I have some 
time off (hopefully later today), just thought I'd warn before.
--
Evilham
___
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"

error message during "mergemaster"

[M - Krasznai András]

In FreeBSD 13.0 when I update the kernel and world I receive the following 
error message during mergemaster:

ka-freebsd:/usr/src# mergemaster



*** Creating the temporary root environment in /var/tmp/temproot

*** /var/tmp/temproot ready for use

*** Creating and populating directory structure in /var/tmp/temproot



make[4]: "/usr/src/lib/libc/net/Makefile.inc" line 130: warning: duplicate 
script for target "afterinstallconfig" ignored

make[4]: "/usr/src/lib/libc/gen/Makefile.inc" line 554: warning: using previous 
script for "afterinstallconfig" defined here



I looks like the generated kernel correctly works but the error message should 
not be there...

What can be the cuase and how can I repair it?


Best regards

Krasznai András
rendszermérnök

[M_logo]
1136 Budapest, Pannónia utca 11.
Tel:  +36 1 703 2923
Mobil: +36 30 703 2923
Központ:  +36 1 703 2920
Fax:  +36 1 703 2949
email: krasznai.and...@mands.hu

___
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: undefined symbol: random_source_register during kernel compilation

[M - Krasznai András]

Good morning!
I found a problem rather quickly: the compilation complains about a missing 
libcasper.h file. (/usr/include/capsicum_helpers.h references libcasper.h, and 
not from the sources but from the installed system.

The problem is that casper is a feature which can be switched off (and on 
again) in /etc/src.conf, but I suppose that if I switch it BACK, thatis if I 
want it to compile casper again (remove the WITHOUT_CASPER=YES line from 
src.conf, e.g.), then the sources for casper should be there somewhere in my 
freshly synchonized source tree.

(and it is: libcasper.h is in /usr/src/lib/libcasper/libcasper  but compilation 
supposes that it has already been installed into /usr/include).

Now I try to compile GENERIC with my original src.conf, which switches off the 
CASPER, and see what happens.

rgds
Andras Krasznai





-Eredeti üzenet-
Feladó: Pete Wright [mailto:p...@nomadlogic.org] 
Küldve: 2019. július 18. 19:10
Címzett: M - Krasznai András; freebsd-current@freebsd.org
Tárgy: Re: undefined symbol: random_source_register during kernel compilation



On 7/18/19 5:21 AM, M - Krasznai András wrote:
> Hi
>
>
> I have been trying to compile a freebsd-current kernel since the 16th of 
> July, and keep getting the following error during "make buildkernel":
>
>
> Building /usr/obj/usr/src/amd64.amd64/sys/G13NEW/kernel.full
> linking kernel.full
> ld: error: undefined symbol: random_source_register
>>>> referenced by ivy.c:108 (/usr/src/sys/dev/random/ivy.c:108)
>>>>ivy.o:(rdrand_modevent)
> ld: error: undefined symbol: random_source_deregister
>>>> referenced by ivy.c:115 (/usr/src/sys/dev/random/ivy.c:115)
>>>>ivy.o:(rdrand_modevent)
> ld: error: undefined symbol: random_source_register
>>>> referenced by nehemiah.c:124 (/usr/src/sys/dev/random/nehemiah.c:124)
>>>>nehemiah.o:(nehemiah_modevent)
> ld: error: undefined symbol: random_source_deregister
>>>> referenced by nehemiah.c:133 (/usr/src/sys/dev/random/nehemiah.c:133)
>>>>nehemiah.o:(nehemiah_modevent)
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/G13NEW
> .ERROR_TARGET='kernel.full'
> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/sys/G13NEW/kernel.full.meta'
> .MAKE.LEVEL='2'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose 
> curdirOk=
> yes'
>
> I deleted and resynchronized the source tree and emptied the /usr/obj 
> directory, but it did not help.
>
> How could I get kernel compilation work again? I would like to say that the 
> make.conf, src.conf files as well as my kernel configuration file was not 
> changed since a couple of months (since I installed freebsd-current).
are you able to build GENERIC?  if so might be worth looking at the 
delta's b/w GENERIC and your custom configuration and trying to zero in 
on what may be causing this to fail.

-p

-- 
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: undefined symbol: random_source_register during kernel compilation

[M - Krasznai András]

Hi, thanks for the advice.

Now I emptied the /usr/src and /usr/obj directories, downloaded the CURRENT 
sources again, and removed the /etc/src.conf file. 
I compile the GENERIC kernel now, /etc/make.conf contains 


KERNCONF=GENERIC
MK_PROFILE=NO
DEFAULT_VERSIONS+=linux=c6
MALLOC_PRODUCTION=YES
INSTALL_NODEBUG=YES
WITH_FAST_DEPEND=YES

Compilation takes a few hours usually, I will tell you the result.

best regards

Andras Krasznai



-Eredeti üzenet-
Feladó: Pete Wright [mailto:p...@nomadlogic.org] 
Küldve: 2019. július 18. 19:10
Címzett: M - Krasznai András; freebsd-current@freebsd.org
Tárgy: Re: undefined symbol: random_source_register during kernel compilation



On 7/18/19 5:21 AM, M - Krasznai András wrote:
> Hi
>
>
> I have been trying to compile a freebsd-current kernel since the 16th of 
> July, and keep getting the following error during "make buildkernel":
>
>
> Building /usr/obj/usr/src/amd64.amd64/sys/G13NEW/kernel.full
> linking kernel.full
> ld: error: undefined symbol: random_source_register
>>>> referenced by ivy.c:108 (/usr/src/sys/dev/random/ivy.c:108)
>>>>ivy.o:(rdrand_modevent)
> ld: error: undefined symbol: random_source_deregister
>>>> referenced by ivy.c:115 (/usr/src/sys/dev/random/ivy.c:115)
>>>>ivy.o:(rdrand_modevent)
> ld: error: undefined symbol: random_source_register
>>>> referenced by nehemiah.c:124 (/usr/src/sys/dev/random/nehemiah.c:124)
>>>>nehemiah.o:(nehemiah_modevent)
> ld: error: undefined symbol: random_source_deregister
>>>> referenced by nehemiah.c:133 (/usr/src/sys/dev/random/nehemiah.c:133)
>>>>nehemiah.o:(nehemiah_modevent)
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/G13NEW
> .ERROR_TARGET='kernel.full'
> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/sys/G13NEW/kernel.full.meta'
> .MAKE.LEVEL='2'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose 
> curdirOk=
> yes'
>
> I deleted and resynchronized the source tree and emptied the /usr/obj 
> directory, but it did not help.
>
> How could I get kernel compilation work again? I would like to say that the 
> make.conf, src.conf files as well as my kernel configuration file was not 
> changed since a couple of months (since I installed freebsd-current).
are you able to build GENERIC?  if so might be worth looking at the 
delta's b/w GENERIC and your custom configuration and trying to zero in 
on what may be causing this to fail.

-p

-- 
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

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

undefined symbol: random_source_register during kernel compilation

[M - Krasznai András]

Hi


I have been trying to compile a freebsd-current kernel since the 16th of July, 
and keep getting the following error during "make buildkernel":


Building /usr/obj/usr/src/amd64.amd64/sys/G13NEW/kernel.full
linking kernel.full
ld: error: undefined symbol: random_source_register
>>> referenced by ivy.c:108 (/usr/src/sys/dev/random/ivy.c:108)
>>>   ivy.o:(rdrand_modevent)

ld: error: undefined symbol: random_source_deregister
>>> referenced by ivy.c:115 (/usr/src/sys/dev/random/ivy.c:115)
>>>   ivy.o:(rdrand_modevent)

ld: error: undefined symbol: random_source_register
>>> referenced by nehemiah.c:124 (/usr/src/sys/dev/random/nehemiah.c:124)
>>>   nehemiah.o:(nehemiah_modevent)

ld: error: undefined symbol: random_source_deregister
>>> referenced by nehemiah.c:133 (/usr/src/sys/dev/random/nehemiah.c:133)
>>>   nehemiah.o:(nehemiah_modevent)
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/G13NEW
.ERROR_TARGET='kernel.full'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/sys/G13NEW/kernel.full.meta'
.MAKE.LEVEL='2'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose 
curdirOk=
yes'

I deleted and resynchronized the source tree and emptied the /usr/obj 
directory, but it did not help.

How could I get kernel compilation work again? I would like to say that the 
make.conf, src.conf files as well as my kernel configuration file was not 
changed since a couple of months (since I installed freebsd-current).

rgds

?





___
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: kernel panic in wireless-related sysctl walk

[M - Krasznai András]

Hi

I have a Lenovo T510 running FreeBSD-12 STABLE. After configuring for lagg 
interface (combined from em - Intel gigabit ethernet adapter and iwn - intel 
wireless adapter) I can cause the system to panic with sysctl -a.
Using either the em interface or the wireless I can safely use sysctl -a, the 
system does not panic.

best regards

András Krasznai

-Original Message-
From: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of O. Hartmann
Sent: Thursday, January 10, 2019 10:22 PM
To: Cy Schubert
Cc: Michael Zhilin; Michael Butler; freebsd-current
Subject: Re: kernel panic in wireless-related sysctl walk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Thu, 10 Jan 2019 12:02:15 -0800
Cy Schubert  schrieb:

> I'm not able to reproduce this at the moment.
> 
> 

I have a oldish Lenovo R500 Notebook running FreeBSD-12 STABLE. I'm not sure 
what WiFi Interface driver the system is using right now; the WiFi is combined 
with the NIC to form a lagg-interface. I can 100% reproduce the crash described 
above via "sysctl -a". Just in case the phenomenon I discovered shortly after 
Christmas is of the same source as the initial poster has reported, how can I 
be of help? The system is a "pkg system"
completely, so I have to switch on debugging without kernel rebuilds. Any 
advice?

Kind regards,

O. Hartmann

- --
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke 
oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXDe3mAAKCRA4N1ZZPba5
R27kAQD7rB6h7Y21ycCWxAjYDb98x2k+y/uWsoBCXBfRAvpYswEA7yO9cj7wno8L
05KxBEbLbrUjn8cLhowYwe0d14EMeAE=
=5VUr
-END PGP SIGNATURE-
___
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"

RE: Another recent WITH_META_MODE= gotcha ": handling svn commit: r334008 - head/bin/sh

[M - Krasznai András]

Hi

I use meta mode and ccache for compile.

I had WITHOUT_RESCUE= in /etc/src.conf.

Then I renamed (thatis practically removed) /etc/src.conf, and removed the 
KERNCONF=mykernel from make.conf to compile GENERIC. 

After this I found the error described. 

N.B. I went back to my original setup (src.conf with WITHOUT_RESCUE and 
mykernel as KERNCONF) and got the same. 

The next thing I will test compiling without meta mode a GENERIC kernel.

rgds

András Krasznai

-Original Message-
From: Bryan Drewery [mailto:bdrew...@freebsd.org] 
Sent: Friday, May 25, 2018 6:33 PM
To: M - Krasznai András; Mark Millard; FreeBSD Current
Cc: cy.schub...@cschubert.com; O. Hartmann
Subject: Re: Another recent WITH_META_MODE= gotcha ": handling svn commit: 
r334008 - head/bin/sh

On 5/25/2018 2:49 AM, M - Krasznai András wrote:
> Hi
> 
> I found another problem with compiling FreeBSD-CURRENT
> 
> when I tried to compile GENERIC instead of my custom I run into the following:
> 
> make installworld fails with
> 
> /bin/sh: /usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue: not found 
> rescue/sh check failed, installation aborted.
> 
> I used originally a customized src.conf which - among others - specifies 
> WITHOUT_RESCUE.
> When trying to compile GENERIC I removed src.conf and I thought I would get a 
> complete FreeBSD-CURRENT with GENERIC, with rescue files, etc. 
> 

Unclear to me. You did buildworld with WITHOUT_RESCUE=yes set and then removed 
'WITHOUT_RESCUE' from your src.conf (by removing src.conf), and then did 
buildworld and then installworld and hit this issue? All with 
WITH_META_MODE=yes? Or did you disable META_MODE at some point?

> The source tree is at r334200
> 
> 
> best regards
> 
> András Krasznai


--
Regards,
Bryan Drewery

___
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: Another recent WITH_META_MODE= gotcha ": handling svn commit: r334008 - head/bin/sh

[M - Krasznai András]

Hi

I found another problem with compiling FreeBSD-CURRENT

when I tried to compile GENERIC instead of my custom I run into the following:

make installworld fails with 

/bin/sh: /usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue: not found
rescue/sh check failed, installation aborted. 

I used originally a customized src.conf which - among others - specifies 
WITHOUT_RESCUE.
When trying to compile GENERIC I removed src.conf and I thought I would get a 
complete FreeBSD-CURRENT with GENERIC, with rescue files, etc. 

The source tree is at r334200


best regards

András Krasznai


-Eredeti üzenet-
Feladó: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Bryan Drewery
Küldve: 2018. május 24. 20:50
Címzett: Mark Millard; FreeBSD Current
Másolatot kap: cy.schub...@cschubert.com; O. Hartmann
Tárgy: Re: Another recent WITH_META_MODE= gotcha ": handling svn commit: 
r334008 - head/bin/sh

On 5/21/2018 10:17 PM, Mark Millard wrote:
> Attempting to build head -r334014 from -r333947 includes the code from 
> -r334008, and for which I get:
> 
> --- parser.o ---
> /usr/src/bin/sh/parser.c:1440:9: error: use of undeclared identifier 'CQNL'
> case CQNL:
>  ^
> 1 error generated.
> 
> for what was added in -r334008.
> 
> # grep -r CQNL /usr/src/* | more
> /usr/src/bin/sh/mksyntax.c: { "CQNL",   "newline character in quotes" 
> },
> /usr/src/bin/sh/mksyntax.c: add("\n", "CQNL");
> /usr/src/bin/sh/mksyntax.c: add("\n", "CQNL");
> /usr/src/bin/sh/mksyntax.c: add("\n", "CQNL");
> /usr/src/bin/sh/parser.c:   case CQNL:
> /usr/src/contrib/libarchive/libarchive/test/test_read_format_rar_binar
> y_data.rar.uu:M+M7)?9;.A%CQNL-+4::&_UJQ*P"PPW:>)I5*8)7^>6(\]!Q"^9YCE>>
> `9OG8
> 
> Apparently this is something WITH_META_MODE= does not deal with.
> Rebuilding after:
> 
> rm -fr /usr/obj/amd64_clang/*
> 
> (here I normally have the build materials) built fine.
> 
> (The "Making top.local.h from /usr/src/contrib/top/top.local.hs"
> change to no longer have top.local.h or top.local.hs was another
> example: for a while top.local.h was still referenced and old ones 
> would still be used if present.)
> 

It was a bug with the rescue build with dependency handling. I've fixed it in 
r334177.


--
Regards,
Bryan Drewery

___
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: [RFC] Deprecation and removal of the drm2 driver

[M - Krasznai András]

hi

I am using a Lenovo T510 laptop with FreeBSD-CURRENT.

It contains Intel I5 processor and integrated Intel graphics adapter.

I tried to set it to drm-stable-kmod as well as to drm-next-kmod, none was 
working, I got a fatal trap, kernel panic during boot.

Compiling the packages on my system did not help. The graphics adapter can be 
old for drm--kmod packages.

Drm2 from the base works correctly on my laptop.

rgds

Andras Krasznai




-Eredeti üzenet-
Feladó: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Philip Homburg
Küldve: 2018. május 23. 11:49
Címzett: Rodney W. Grimes
Másolatot kap: K. Macy; A. Wilcox; FreeBSD Current
Tárgy: Re: [RFC] Deprecation and removal of the drm2 driver 

>Also as the Moore's law curve flattens expect the life of these
>older, but not so old, machines to live quiet some time.  I
>believe we are talking sandy bridge and earlier?  If that is
>corret Sandy bridge is still a very viable system.

I noticed this lack of love for older systems recently. 

I wanted to use an older Dell server to test the 11.2 BETAs and RCs.

Turns out, you can't install FreeBSD using a USB stick image because the
BIOS only support MBR. No idea why MBR support was dropped for the USB images.

In the end I had to find a CD burner, and after a couple of tries managed to
install from CD.

After that, my ansible playbooks started failing because /boot/loader.conf 
is absent if you boot from zfs in combination with MBR.

Pity. This older server hardware is great for trying out new releases, play 
with zfs, etc.
___
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"

RE: Call for Testing: UEFI Changes

[M - Krasznai András]

Hi

I found this problem today morning. Fortunately I can copy the efi.4th file 
back to /boot from /usr/src/stand/forth

On the other hand, removing the reference to efi.4th from loader.rc causes the 
boot stop at the loader prompt

rgds
András Krasznai


-Eredeti üzenet-
Feladó: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Toomas Soome
Küldve: 2018. március 22. 11:52
Címzett: FreeBSD Current
Tárgy: Re: Call for Testing: UEFI Changes



> On 22 Mar 2018, at 12:13, Jakob Alvermark  wrote:
> 
> Hi!
> 
> 
> Just updated to r331345.
> 
> Two problems:
> 
> 1. boot/efi.4th is added to /usr/src/ObsoleteFiles.inc but still included in 
> loader.rc. Loader fails to load it and subsequently fails to load modules. 
> Reinstalling efi.4th problem 2 appears.
> 
> 
> 2. Fixing problem 1 and adding efirt_load="YES" to /boot/loader.conf 
> makes the kernel panic instantly. Photo of panic: 
> https://photos.app.goo.gl/ph3yQukOAUdQpsvK2
> 
> 
> Jakob

The efi.4th was introduced and later removed by Warner, a bit too hastily 
perhaps… but perhaps it is better to note the partial revert of the removal or 
something like that:)

rgds,
toomas


> 
> 
> On 03/22/18 01:45, Kyle Evans wrote:
>> Hello!
>> 
>> A number of changes have gone in recently pertaining to UEFI booting 
>> and UEFI runtime services. The changes with the most damaging 
>> potential are:
>> 
>> We now put UEFI runtime services into virtual address mode, fixing 
>> runtime services with U-Boot/UEFI as well as the firmware 
>> implementation in many Lenovos. The previously observed behavior was 
>> a kernel panic upon invocation of efibootmgr/efivar, or a kernel 
>> panic just loading efirt.ko or compiling EFIRT into the kernel.
>> 
>> Graphics mode selection is now done differently to avoid regression 
>> caused by r327058 while still achieving the same effect. The observed 
>> regression was that the kernel would usually end up drawing 
>> incorrectly at the old resolution on a subset of the screen, due to 
>> incorrect framebuffer information.
>> 
>> Explicit testing of these changes, the latest of which happened in 
>> r331326, and any feedback from this testing would be greatly 
>> appreciated. Testing should be done with either `options EFIRT` in 
>> your kernel config or efirt.ko loaded along with updated bootloader 
>> bits.
>> 
>> I otherwise plan to MFC commits involved with the above-mentioned 
>> changes by sometime in the first week of April, likely no earlier 
>> than two (2) weeks from now on April 4th.
>> 
>> Thanks,
>> 
>> Kyle Evans
>> ___
>> 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"

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

RE: Panic on Boot - Current AMD64

[M - Krasznai András]

Hi

yesterday I experienced the problem, but after completely synchronizing the src 
tree (deleting the content of the /usr/src folder and svnlite checkout etc.) 
and recompiling the kernel I can boot my FreeBSD-CURRENT (12.0, amd64, r328967) 
with the default setting (64) for vm.boot_pages.

rgds
András Krasznai



-Eredeti üzenet-
Feladó: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Juan Ramón Molina Menor
Küldve: 2018. február 7. 12:18
Címzett: freebsd-current@freebsd.org
Másolatot kap: manfredan...@gmail.com; gleb...@freebsd.org
Tárgy: Panic on Boot - Current AMD64

>> I get panic on boot from current kernel.
>> Since last night - changes to vm system ?
>> World is Current as of this morning
>>
>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 12.0-CURRENT #0 r328948: Tue Feb  6 11:30:57 PST 2018
>>  root at pozo.com
>> :/usr/src
>> /sys/amd64/compile/pozo amd64 FreeBSD clang version 6.0.0 
>> (branches/release_60 324090) (based on LLVM 6.0.0) Table 'FACP' at 
>> 0xdfbc57e8 Table 'APIC' at 0xdfbc585c Table 'ASF!' at 0xdfbc58e0 
>> Table 'MCFG' at 0xdfbc5943 Table 'TCPA' at 0xdfbc597f Table 'SLIC' at 
>> 0xdfbc59b1 Table 'HPET' at 0xdfbc5b27
>> ACPI: No SRAT table found
>> panic: UMA: Increase vm.boot_pages
>> cpuid = 0
>> time = 1
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
>> 0x820bc820
>> vpanic() at vpanic+0x18d/frame 0x820bc880
>> panic() at panic+0x43/frame 0x820bc8e0
>> startup_alloc() at startup_alloc+0x19c/frame 0x820bc940
>> keg_alloc_slab() at keg_alloc_slab+0xef/frame 0x820bc9c0
>> keg_fetch_slab() at keg_fetch_slab+0x128/frame 0x820bca20
>> zone_fetch_slab() at zone_fetch_slab+0x69/frame 0x820bca50
>> zone_import() at zone_import+0x5a/frame 0x820bcaa0
>> zone_alloc_item() at zone_alloc_item+0x3b/frame 0x820bcae0
>> uma_startup() at uma_startup+0x3d3/frame 0x820bcbd0
>> vm_page_startup() at vm_page_startup+0x338/frame 0x820bcc20
>> vm_mem_init() at vm_mem_init+0x1d/frame 0x820bcc50
>> mi_startup() at mi_startup+0x118/frame 0x820bcc70
>> btext() at btext+0x2c
>> KDB: enter: panic
>> [ thread pid 0 tid 0 ]
>> Stopped at  kdb_enter+0x3b: movq$0,kdb_why
>> db> bt
>> Tracing pid 0 tid 0 td 0x80ff1240
>> kdb_enter() at kdb_enter+0x3b/frame 0x820bc820
>> vpanic() at vpanic+0x1aa/frame 0x820bc880
>> panic() at panic+0x43/frame 0x820bc8e0
>> startup_alloc() at startup_alloc+0x19c/frame 0x820bc940
>> keg_alloc_slab() at keg_alloc_slab+0xef/frame 0x820bc9c0
>> keg_fetch_slab() at keg_fetch_slab+0x128/frame 0x820bca20
>> zone_fetch_slab() at zone_fetch_slab+0x69/frame 0x820bca50
>> zone_import() at zone_import+0x5a/frame 0x820bcaa0
>> zone_alloc_item() at zone_alloc_item+0x3b/frame 0x820bcae0
>> uma_startup() at uma_startup+0x3d3/frame 0x820bcbd0
>> vm_page_startup() at vm_page_startup+0x338/frame 0x820bcc20
>> vm_mem_init() at vm_mem_init+0x1d/frame 0x820bcc50
>> mi_startup() at mi_startup+0x118/frame 0x820bcc70
>> btext() at btext+0x2c
>> db>
> 
> 
> Same panic here with HEAD from this afternoon in a Lenovo ThinkPad 
> S440 with 4 GB.
> 
> Workaround: break into the loader prompt and:
> 
> set vm.boot_pages=120
> boot
> 
> When booting kernel.old, vm.boot_pages is 64.
> 
> There is something wrong with r328916.
> 
> Hope it helps,
> Juan

Hi!

Recent commits 328955, 328953 and 328952 by glebius@ do not resolve the issue 
here.

Hope it helps,
Juan
___
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"

RE: Failover Mode Between Ethernet and Wireless Interfaces broken on >= 11

[M - Krasznai András]

Good morning!

With em0 and iwn I have the same working configuration for failover between 
wireless interface and ethernet  adapter. I run FreeBSD-12. 

There was some change introduced with FreeBSD-11 in the syntax how to specify 
the mac address for the wireless interface (old - FreeBSD-10  working form: 
ifconfig_iwn0="ether ", the new is 
create_args_wlan0="wlanaddr ". The "new" mac address is 
identical with the ethernet adapter's mac address. 

best regards

András Krasznai


-Eredeti üzenet-
Feladó: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Cy Schubert
Küldve: 2017. június 22. 7:40
Címzett: Sean Bruno
Másolatot kap: Renato Botelho; freebsd-current@freebsd.org
Tárgy: Re: Failover Mode Between Ethernet and Wireless Interfaces broken on >= 
11

In message , Sean Bruno write
s:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) 
> --XuprkQPPD5E0VHaDeuAKBatHWCR01xNcA
> Content-Type: multipart/mixed; 
> boundary="fPqiMVoTg6hr4JdbiP1DBOlOppEsSDgjw";
>  protected-headers="v1"
> From: Sean Bruno 
> To: Renato Botelho , freebsd-current@freebsd.org
> Message-ID: 
> Subject: Re: Failover Mode Between Ethernet and Wireless Interfaces 
> broken on  >= 11
> References: <1c1e5c6f-35e5-ca14-2e23-5e33d86a5...@freebsd.org>
> In-Reply-To: <1c1e5c6f-35e5-ca14-2e23-5e33d86a5...@freebsd.org>
> 
> --fPqiMVoTg6hr4JdbiP1DBOlOppEsSDgjw
> Content-Type: text/plain; charset=utf-8
> Content-Language: en-US
> Content-Transfer-Encoding: quoted-printable
> 
> 
> 
> On 06/21/17 11:48, Renato Botelho wrote:
> > I've already sent it to net, but I suspect this is the appropriate 
> > plac=
> e
> > to discuss this subject.
> >=20
> > Last night I was configuring a new laptop and decided to give it [1] 
> >a  try. I figured out this section of handbook (similar instructions 
> >are o=
> n
> > lagg(4) manpage) is outdated, based on FreeBSD 10.x.
> >=20
> > Then I modified a bit the commands and tried to get it configured on  
> >12-CURRENT, without success. I spoke with adrian@, who told me this  
> >setup doesn't work on FreeBSD > 10, because on newer versions 
> >Wireless  interfaces mac address cannot be changed.
> >=20
> > My next attempt was to do the other way round and make lagg to use 
> >wlan=
> 0
> > mac address instead of em0's. but even doing this my wireless 
> > interface=
> 
> > ended up not working.
> >=20
> > After further investigation I noted that a simple command:
> >=20
> > # ifconfig wlan0 ether $wlan0_current_mac_address
> >=20
> > is enough to break it on 12-CURRENT.
> >=20
> > I've checked if_setlladdr() source code and noted it always replace 
> >the=
> 
> > mac address, even if the same is already configured on the 
> > interface. I=
> s
> > it the expected behavior?
> >=20
> > Just as a PoC I've applied the following patch to if_setlladdr():
> >=20
> > Index: sys/net/if.c
> > 
> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> 3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > --- sys/net/if.c(revision 320097)
> > +++ sys/net/if.c(working copy)
> > @@ -3519,6 +3519,10 @@
> > ifa_free(ifa);
> > return (EINVAL);
> > }
> > +   if (memcmp(lladdr, LLADDR(sdl), len) =3D=3D 0) {
> > +   ifa_free(ifa);
> > +   return (0);
> > +   }
> > switch (ifp->if_type) {
> > case IFT_ETHER:
> > case IFT_FDDI:
> >=20
> > And configured it to use wlan0 mac address on rc.conf:
> >=20
> > ifconfig_em0=3D"ether 60:67:20:c5:2d:48 up"
> > wlans_iwn0=3D"wlan0"
> > ifconfig_wlan0=3D"WPA"
> > cloned_interfaces=3D"lagg0"
> > ifconfig_lagg0=3D"up laggproto failover laggport em0 laggport wlan0 
> >DHC=
> P"
> >=20
> > and it's now working as expected.
> >=20
> > Other than that, I believe if wlan interfaces cannot have their mac  
> >address changed, ifconfig should return an error when user attempts 
> >to  do it, and if_setlladdr() should do the same.
> >=20
> > Thoughts?
> >=20
> > [1]
> > 
> >https://www.freebsd.org/doc/handbook/network-aggregation.html#network
> >in=
> g-lagg-wired-and-wireless
> >=20
> 
> 
> Maybe this is a "iflib" problem.  em(4) and igb(4) are pretty 
> different now in head.  Can you shove it into bugzilla with a test 
> case (copy/paste your email) and tag me on it?

As a late comer to this thread, I don't have any issues either. I too have a 
bge interface and iwn set up as follows:

ifconfig_lagg0="laggproto failover laggport bge0 laggport wlan0 DHCP"


--
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list 

RE: INO64 Effecting Firefox

[M - Krasznai András]

Hi,

Since last Thursday's update of Freebsd-12-current kernel, world (and 
precompiled packeges with pkg update/upgrade) I experience rather large number 
of Firefox crashes. Sometimes it crashes without opening any pages (I just 
started and left firefox for a few minutes, it crashes with the same error: 

A coding exception was thrown and uncaught in a Task.

Full message: TypeError: malformed UTF-8 charachter sequence at offset 0
etc. ) 


Version numbers:

FreeBSD-12-0-CURRENT #318917; firefox-53.0.3,1

best regards

András Krasznai

-Original Message-
From: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Oleg V. Nauman
Sent: Sunday, May 28, 2017 6:45 PM
To: freebsd-current@freebsd.org
Subject: Re: INO64 Effecting Firefox

On Sunday 28 May 2017 18:09:19 O. Hartmann wrote:
> Am Sun, 28 May 2017 08:54:35 -0700
> 
> Pete Wright  schrieb:
> > Hi all,
> > 
> > I can't imagine that this is related to INO64, but since upgrading 
> > my world and kernel on drm-next (which merged upstream CURRENT as of 
> > May 27 which should include the ino64 work) I am having segfaults 
> > running firefox.  Previous to this firefox was very stable for 
> > work/personal daily use.
> > 
> > The error I'm seeing is:
> > Full message: TypeError: malformed UTF-8 character sequence at 
> > offset 0
> > 
> > Firefox does start and I can load a page or two before it sefaults.
> > 
> > The full console output is here:
> > 
> > https://gist.github.com/anonymous/555202b1452503ad9e26750168f87d5f
> > 
> > 
> > Posting this here in the off chance that it's either related to 
> > ino64, or some other recent change has caused this problem.
> > 
> > Cheers!
> > 
> > -pete
> 
> I see similar problems. Out of the blue, firefox crashes.
> But in my case, firefox is "old", since it doesn't compile with 
> WITH_LLD_IS_LD due to a very strange error (Bug 218808).
> 
> The binary I run und CURRENT (FreeBSD 12.0-CURRENT #8 r319001: Sun May 
> 28
> 00:21:16 CEST 2017 amd64, WITH_LLD_IS_LD=yes) if as of
> 
> firefox-53.0_2,1
> Name   : firefox
> Version: 53.0_2,1
> Installed on   : Sun Apr 16 10:17:14 2017 CEST
> Origin : www/firefox
> Architecture   : FreeBSD:12:amd64
> 
> I got a kind of relief (means: the frequence of crashes is reduced) 
> when starting to rebuild all ports again (I'm staying with make and 
> portmaster) to meet ABI requirements after ino64 has been introduced.
> 
> Another strange behaviour is: firefox crashes very likely very often 
> when started. Once it has run a while, I can consider it "stable". It 
> doen not crash then.

 Please try to rebuild firefox. It helps me today with firefox-esr segfaulting 
on my desktop running 12.0-CURRENT r318856  From my limited understanding of 
stacktraces it was related to libthr changes.

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

RE: dchlient does not autostart anymore?

[M - Krasznai András]

Hi
I am on r315901 and still have the problem.  

I am using an aggregate interface lagg0 created from my Ethernet adapter and my 
WiFi; I use this configuration since a few months without any change and 
without problems. dhclient still does not start automatically for lagg0 since 
Thursday morning update.


Of course I can start dhclient manually after logging in, and get IP address.

best regards

András Krasznai


- Original Message-
From: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Warner Losh
Sent: Friday, March 24, 2017 6:07 PM
To: Vladimir Zakharov
Cc: Jung-uk Kim; Kirill Ponomarev; FreeBSD Current
Subject: Re: dchlient does not autostart anymore?

On Fri, Mar 24, 2017 at 10:53 AM, Vladimir Zakharov  
wrote:
> On Fri, Mar 24, 2017, Jung-uk Kim wrote:
>> On 03/24/2017 11:20, Kirill Ponomarev wrote:
>> > On 03/24, Vladimir Zakharov wrote:
>> >> Hello!
>> >>
>> >> After upgrading from r315544 to r315880 network interface doesn't 
>> >> get IP address using DHCP on boot anymore.
>> >>
>> >> $ grep re0 /etc/rc.conf | grep -v "^#"
>> >> ifconfig_re0="DHCP"
>> >>
>> >> "service netif restart" doesn't help either. Only manual dhclient 
>> >> starting.
>> >
>> > Same issues here with today CURRENT, r315896.
>>
>> FYI, r315901 fixed the issue for me.
>
> For me too. Thanks.

Yea, sorry about the brief breakage... I didn't notice until after I'd 
committed Ian's much improved version there'd been a problem. Stupid mistake on 
my part committing out of the wrong tree for the change that caused problems.

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

RE: dchlient does not autostart anymore?

[M - Krasznai András]

It seems that usb mouse port has been changed from /dev/psm0 to /dev/ums0; 
loading ums.ko  with kldload and restarting the mouse with 

moused -p /dev/ums0 

makes the mouse work again (but now the touchpad is not working; I can survive 
that).

rgds

András Krasznai



-Eredeti üzenet-
Feladó: Ruslan Makhmatkhanov [mailto:r...@freebsd.org] 
Küldve: 2017. március 24. 12:04
Címzett: FreeBSD Current
Másolatot kap: M - Krasznai András
Tárgy: Re: dchlient does not autostart anymore?

The same for me (usb mouse + dhclient) on r315874. Touchpad is working.

-- 
Regards,
Ruslan

T.O.S. Of Reality
___
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: dchlient does not autostart anymore?

[M - Krasznai András]

Hi,

FreeBSD-current, r315895 also experiences the same problem. The problem started 
after updating my laptop yesterday morning. I can get an IP address after 
manually starting dhclient.

I have an additional anomaly: the USB mouse does not work (touchpad works) on a 
Lenovo T510 laptop. dmesg shows the correct vendor and type for the mouse.

rgds

András Krasznai



-Eredeti üzenet-
Feladó: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Mark Millard
Küldve: 2017. március 24. 9:57
Címzett: zakharov...@gmail.com; FreeBSD Current
Tárgy: Re: dchlient does not autostart anymore?

Vladimir Zakharov zakharov.vv at gmail.com  wrote on Fri Mar 24 08:20:34 UTC 
2017:

> After upgrading from r315544 to r315880 network interface doesn't get 
> IP address using DHCP on boot anymore.
> 
> $ grep re0 /etc/rc.conf | grep -v "^#"
> ifconfig_re0="DHCP"
> 
> "service netif restart" doesn't help either. Only manual dhclient 
> starting.

I have just updated two contexts to -r315870 just a bit ago and they both got 
that behavior as well:

A) An amd64 context (FreeBSD client in VirtualBox under macOS)
B) An arm64 context (pine64+ 2GB with -mcpu=cortex-a53 )

Later I'll be updating powerpc64, powerpc, and armv6 (with
-mcpu=cortex-a7 ) contexts but I'd expect they will all match the behavior.

(I started from earlier than -r315544 so your report provides a better lower 
bound -r315544. I ended earlier and so my report provides a better upper bound 
-r315870.)

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

USB_ERR_TIMEOUT, USB_ERR_IOERROR in Freebsd-current

[M - Krasznai András]

Hello



I tried both patches (separately) which were suggested in



https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215898





on FreeBSD-current r312404 today, and now I can confirm that both solved the 
original problem, the patched kernel boots and no USB_ERR_TIMEOUT nor 
USB_ERR_IOERROR messages were shown.



best regards / Üdvözlettel:

Krasznai András
rendszermérnök
M Informatikai Zrt.
1136 Budapest, Pannónia u. 11.
Tel: +36 (1) 703-2923
Fax: +36 (1) 703-2949
Mobil: +36 (30) 703-2923
E-mail: krasznai.and...@mands.hu

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

USB_ERR_TIMEOUT, USB_ERR_IOERROR in Freebsd-current

[M - Krasznai András]

Hi

I have FreeBSD-current on a Lenovo T510 laptop.

Since a few weeks I observe the following error messages during boot:

usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored)
uhub2: 8 ports with 8 removable, self powered
usb_alloc_device: set address 3 failed (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 3 failed, 
USB_ERR_IOERROR
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_TIMEOUT
sdhci_pci0-slot0:  Controller timeout
sdhci_pci0-slot0: == REGISTER DUMP ==
sdhci_pci0-slot0: Sys addr: 0x | Version:  0x0400
sdhci_pci0-slot0: Blk size: 0x | Blk cnt:  0x
sdhci_pci0-slot0: Argument: 0x | Trn mode: 0x
sdhci_pci0-slot0: Present:  0x01ff | Host ctl: 0x0001
sdhci_pci0-slot0: Power:0x000f | Blk gap:  0x
sdhci_pci0-slot0: Wake-up:  0x | Clock:0x4007
sdhci_pci0-slot0: Timeout:  0x000e | Int stat: 0x0001
sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb
sdhci_pci0-slot0: AC12 err: 0x | Slot int: 0x0001
sdhci_pci0-slot0: Caps: 0x01e032b2 | Max curr: 0x0040
sdhci_pci0-slot0: ===
usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 3 failed, 
USB_ERR_IOERROR


The error slows down the boot process, otherwise I did not observe other 
problems.

The same laptop did not show similar error messages with FreeBSD-11, nor with 
any earlier version.

I attached the dmesg output, kernel configuration and pciconf -lv output.

Did anybody experience similar things?

best regards

Üdvözlettel:

Krasznai András
rendszermérnök
M Informatikai Zrt.
1136 Budapest, Pannónia u. 11.
Tel: +36 (1) 703-2923
Fax: +36 (1) 703-2949
Mobil: +36 (30) 703-2923
E-mail: krasznai.and...@mands.hu



GEN12
Description: GEN12


pciconf.out
Description: pciconf.out


dmesg.out
Description: dmesg.out
___
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: freebsd-current compile with clang & ccache

[M - Krasznai András]

Hi

I am now reading the manual pages for src.conf. 

Src.conf should only be used to specify variables for make, e.g. 
WITHOUT_PROFILE, or WITH_CCACHE_BUILD. Man src.conf does not say much more 
about ccache, but ccache-howto-freebsd says that WITH_CCACHE_BUILD is only for 
building ports with ccache; for world and kernel you should set CC and CXX 
variables within make.conf following the advice in ccache-howto 

("To use ccache for ports, just add WITH_CCACHE_BUILD=yes to /etc/make.conf.

To use ccache for base add the following to /etc/make.conf:

.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
CC:=${CC...

")

I do not copy here the full howto

My problem is that after a successful compile of base - world and kernel - 
using ccache I run make installkernel correctly, but after reboot and 
mergemaster -p I got a lot of ccache error messages during make installworld. 
They complain ebout not finding compiler cc in path although cc -v gives the 
clang version number, so cc IS on the path.

Best regards

András Krasznai





-Original Message-
From: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Rainer Hurling
Sent: 2015. november 25. 20:48
To: Bryan Drewery; FreeBSD-Current
Subject: Re: freebsd-current compile with clang & ccache

Am 25.11.15 um 20:37 schrieb Bryan Drewery:
> On 11/25/2015 11:34 AM, Rainer Hurling wrote:
>> Am 25.11.15 um 19:50 schrieb Bryan Drewery:
>>> On 11/25/2015 10:09 AM, Juan Molina wrote:
>>>>> On 11/24/2015 1:31 AM, M - Krasznai András wrote:
>>>>>> /What can I do to eliminate the ccache error during installworld
>>>>> apart from not using ccache? /
>>>>> I would recommend not setting CC or CCACHE_PATH in make.conf and 
>>>>> using the new WITH_CCACHE_BUILD=yes option instead.
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Bryan Drewery
>>>>
>>>> Hi.
>>>>
>>>> I'm seeing the same ccache errors and I do not have CC or 
>>>> CCACHE_PATH defined anywhere. Only WITH_CCACHE_BUILD and WITH_FAST_DEPEND 
>>>> in src.conf.
>>>>
>>>
>>> WITH_FAST_DEPEND is not related.
>>>
>>> Are you building and installing as a different user? Using a 
>>> different MAKEOBJDIRPREFIX in build and install?
>>>
>>> Do you have CCACHE_PATH in your environment?
>>>
>>> Run 'make ccache-print-options|grep path'. It should have no value.
>>>
>>
>> Is there any possibility to redirect the .ccache directory, something 
>> like CCACHE_PATH for userland?
>>
>> I am asking, because in my attempts to build base with 
>> WITH_CCACHE_BUILD and WITH_FAST_DEPEND enabled, it breaks with error 
>> message 'file system full'. My root partition has only 1GB and ccache 
>> itself seems to need more than 800MB in /root/.ccache.
>>
> 
> You want to modify CCACHE_DIR. You can do this in make.conf or the 
> environment.
> 
> I tend to just symlink /root/.ccache to somewhere else though and let 
> the default work via the symlink.
> 
> Also see 'man src.conf' (WITH_CCACHE_BUILD section) and 'man ccache'.
> 

Oops, I should have looked into man src.conf before asking here, sorry.

And many thanks for the quick and helpful answer.
___
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"

RE: freebsd-current compile with clang & ccache

[M - Krasznai András]

Hi

I now modified my setup according to the links you provided I and compile a 
freshly updated base of FreeBSD-Current.

I will report when finshed.

Rgds

András


-Original Message-
From: NGie Cooper [mailto:yaneurab...@gmail.com] 
Sent: 2015. november 26. 8:36
To: M - Krasznai András
Cc: Bryan Drewery; freebsd-current@freebsd.org
Subject: Re: freebsd-current compile with clang & ccache


> On Nov 25, 2015, at 23:21, M - Krasznai András <krasznai.and...@mands.hu> 
> wrote:
> 
> Thanks, but as far as I know WITH_CCACHE_BUILD is only for ports compilation 
> and novadays I use binary ports wherever I can.

It’s available in recent versions of FreeBSD CURRENT [1], [2] .
Cheers,
-NGie

1. https://lists.freebsd.org/pipermail/freebsd-arch/2015-November/017472.html
2. https://svnweb.freebsd.org/changeset/base/290526
___
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: freebsd-current compile with clang & ccache

[M - Krasznai András]

Thanks, but as far as I know WITH_CCACHE_BUILD is only for ports compilation 
and novadays I use binary ports wherever I can.

rgds

András



-Original Message-
From: Bryan Drewery [mailto:bdrew...@freebsd.org] 
Sent: Wednesday, November 25, 2015 5:35 PM
To: M - Krasznai András <krasznai.and...@mands.hu>; 
freebsd-current@freebsd.org
Subject: Re: freebsd-current compile with clang & ccache

On 11/24/2015 1:31 AM, M - Krasznai András wrote:
> What can I do to eliminate the ccache error during installworld apart from 
> not using ccache?

I would recommend not setting CC or CCACHE_PATH in make.conf and using the new 
WITH_CCACHE_BUILD=yes option instead.

--
Regards,
Bryan Drewery

___
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 compile with clang & ccache

[M - Krasznai András]

Good morning!

I experience the following errors:


after setting up ccache according to the howto I tried to compile world and 
kernel.



make buildworld



runs correctly, takes appr. 3 hours to finish for the first run. Repeating it 
finishes in a little less than 1 hour.



Make -j5 buildworld



also finishes correctly and takes about 23 minutes.



After finishing the kernel compile



Make installkernel

Reboot



Then



make installworld



gives a lot of error messages:



ccache: error: Could not find compiler "cc" in PATH



but finishes, and the system appears to be working, but I think there must be 
some problem what I could not find.





Compilation and installation finishes correctly if i do not use ccache but 
rather slow.



The system has been reinstalled from scratch, source tree was downloaded on 
Friday and updated few minutes before compile on Monday.

The kernel config is a stripped down GENERAL (I left out those drivers and 
kernel modules which handle hardware not present in my laptop).

I use src.conf to eliminate compiling such components which I do not use 
(BLUETOOTH, IPX/SPX, etc). COMPILER_TYPE is set in my .cshrc to clang.



What can I do to eliminate the ccache error during installworld apart from not 
using ccache?





Best regards



András Krasznai








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