Re: panic: vtopde on a uva/gpa 0x1030000 @r325228 (amd64)

2017-11-01 Thread Andriy Gapon 
On 01/11/2017 09:33, O. Hartmann wrote:
> I have the same (or similar) probleme here on two boxes now, maybe more to 
> come
> as I start updating CURRENT cyclic.
> 
> Reverting r325227 solves to problem for now.

Oliver,

David and I have been working on this and a fix is coming soon.
Sorry for the trouble and thanks for the report.

-- 
Andriy Gapon
___
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: pcsc-lite hangs up after unplugging an USB card reader

2017-11-01 Thread Hans Petter Selasky 

On 11/01/17 12:05, Jairo Montes González wrote:

Jairo Montes schrieb am 01.11.2017 11:04
_

The output from "procstat -ak" is attached to this email.



Here are the relevant bits:

  898 100592 pcscd   -   mi_switch sleepq_switch sleepq_catch_signals sleepq_timedwait_sig _cv_timedwait_sig_sbt seltdwait kern_select sys_select amd64_syscall Xfast_syscall 
  898 100699 pcscd   -   mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread kern_readv sys_read amd64_syscall Xfast_syscall 
  898 100700 pcscd   -   mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait __umtx_op_wait amd64_syscall Xfast_syscall 
  898 100702 pcscd   -   mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_poll sys_poll amd64_syscall Xfast_syscall 



BTW: I see no USB processes hanging.

It looks like pcscd is stuck:

1) waiting for select to complete (normal)

2) waiting on a mutex operation (might be an indication of deadlock)

Try to do:

thread 100700
bt

I'm not sure how you can extend the backtrace into userspace.

Maybe you need to do:

gdb -p 898
thread 100700
bt

To figure out where this software is stuck.

It might look like a missed mutex unlock in some error path inside pcscd.

--HPS
___
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: vtopde on a uva/gpa 0x1030000 @r325228 (amd64)

2017-11-01 Thread O. Hartmann 
On Tue, 31 Oct 2017 06:02:41 -0700
David Wolfskill  wrote:

> On Tue, Oct 31, 2017 at 02:35:19PM +0200, Andriy Gapon wrote:
> > On 31/10/2017 14:32, David Wolfskill wrote:  
> > > Andriy, I "cloned" the slice before doing the above, so I can poke
> > > at this a bit more (e.g., try to get a crash dump), if that would
> > > still be useful.  
> > 
> > Yes, it would be, as I currently do not see what the problem with r325227
> > is.   
> 
> OK; please see 
> for:
> 
> Icon  NameLast modified  Size
> Description[PARENTDIR] Parent Directory -   
> [TXT] core.txt.5  2017-10-31 12:52  201K  
> [   ] core.txt.5.gz   2017-10-31 12:52   43K  
> [   ] info.5  2017-10-31 12:52  524   
> [   ] info.5.gz   2017-10-31 12:52  363   
> [   ] vmcore.52017-10-31 12:52  1.3G  
> [   ] vmcore.5.gz 2017-10-31 12:52  493M  
> 
> As noted earlier in the thread, there's a verbose dmesg.boot available
> from  (as well as a
> few other bits).
> 
> Peace,
> david

I have the same (or similar) probleme here on two boxes now, maybe more to come
as I start updating CURRENT cyclic.

Reverting r325227 solves to problem for now.

Kind regards,
Oliver
___
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: Segfault in _Unwind_* code called from pthread_exit

2017-11-01 Thread Tijl Coosemans 
On Tue, 31 Oct 2017 22:52:33 +0100 Andreas Tobler  
wrote:
> On 31.10.17 22:36, Gerald Pfeifer wrote:
>> On Tue, 31 Oct 2017, Andreas Tobler wrote:
>> Those possibly still stuck on obsolete versions of FreeBSD don't
>> need/want fancy new compilers and GCC 4.9 is still available for
>> use and does not exhibit this issue, correct?  (If it does, nobody
>> reported any problems.)
> 
> It is limited to gcc >=5, gcc-4.9 does not have the 
> MD_FALLBACK_FRAME_STATE_FOR defined.
> 
>>> I can 'ifdef' the new code and in the 'else' case we fall back to
>>> the already existing path.
>> 
>> If it's "cheap", that might be nice.
> 
> Attached, the test is running on gcc trunk and gcc-6. gcc-6 is the last 
> one with java support and there we have quite extensive test cases which 
> really test for this MD_FALLBACK_FRAME_STATE_FOR macro. These test 
> cases, Throw_2 and co do pass. So I think the new bits should be fine.
> Also some coming asan test cases do pass with this addition too.

Please commit it to the ports tree as well, because there are reports
that ftp/curl can trigger the problem.
___
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: pcsc-lite hangs up after unplugging an USB card reader

2017-11-01 Thread Jairo Montes González 

Jairo Montes schrieb am 01.11.2017 11:04
_

The output from "procstat -ak" is attached to this email.


As you might see, I'm trying to debug it, but this is my first time using

the GDB debugger, so I'm a bit lost with it's usage and I believe I'm not

doing a good job with it. All I've found so far is that it keeps looping

in somewhere and does not return correctly.


I forgot to mention in my first email that I added the lines to

/etc/devd.conf that the pcsc-lite installation tells you to add for USB

cardreaders. I also added /usr/local/etc/devd/pcscd.conf, attached here

too, just in case it produces any kind of conflict.


On 10/30/2017 18:12, Hans Petter Selasky wrote:

On 10/30/17 18:10, Jairo Montes González wrote:

Jairo Montes schrieb am 30.10.2017 17:09
_

Hi people!

My problem appears only when unplugging one device. I can have more than
one connected, but when I disconnect one, an error occurs, and if I 
plug in
a device, even the same I just unplugged, it won't be loaded. I don't 
know

if the problem comes from pcsc-lite or FreeBSD (libusb).


Information requested for support at:
http://pcsclite.alioth.debian.org/ccid.html#support

Versions:
- ccid-1.4.27
- pcsc-lite-1.8.22,2
- Inside Secure AT90SCR200
- Enabled features: FreeBSD amd64-portbld-freebsd12.0 serial usb libusb
 usbdropdir=/usr/local/lib/pcsc/drivers/ ipcdir=/var/run/pcscd
 configdir=/usr/local/etc/reader.conf.d

Platform:
- FreeBSD 10.4-STABLE and 12.0-CURRENT r323761 amd64
- Standard compatible PC (Intel i5-6500)
- No card involved. It does the same with or without a card.
- SCM Microsystems Inc. SCR 335,  Inside Secure AT90SCR200.

The output of pcscd is attached to this email.

Any thoughts on this? Thanks in advance people.



Check the output from "procstat -ak".

--HPS



BALLY WULFF Games & Entertainment GmbH, Maybachufer 48-51, 12045 Berlin, 
Postanschrift: Postfach 44 01 57, 12001 Berlin Tel.: 030-620 02-0 FAX: 030-620 
02-200, Geschaeftsfuehrer: Thomas Niehenke, Lars Rogge, Wolfram Seiffert, Thomas 
Wendt, Amtsgericht Berlin-Charlottenburg HRB 139020 B, UST-IdNr. DE815328376
_
Dieses E-Mail ist nur fuer den Empfaenger bestimmt, an den es gerichtet
ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes
Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungs-
aeusserung ist die des Autors und stellt nicht notwendigerweise die
Ansicht oder Meinung von Bally Wulff Games & Entertainment GmbH dar.
Sind Sie nicht der Empfaenger, so haben Sie diese E-Mail irrtuemlich
erhalten und jegliche Verwendung, Veroeffentlichung, Weiterleitung,
Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt.

Weder Bally Wulff Games & Entertainment GmbH noch der Absender
uebernehmen die Haftung fuer Viren. Es obliegt Ihrer Verantwortung,
die E-Mail und deren Anhaenge auf Viren zu pruefen.
2 Anhaenge:
procstat_output.txt
pcscd.conf
_
Versand am 01.11.2017 11:04 von Montes Jairo

  PIDTID COMMTDNAME  KSTACK 
  
0 10 kernel  swapper mi_switch sleepq_switch 
sleepq_timedwait _sleep swapper btext 
0 18 kernel  thread taskqmi_switch sleepq_switch 
sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 
0 19 kernel  aiod_kick taskq mi_switch sleepq_switch 
sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 
0 100011 kernel  kqueue_ctx taskqmi_switch sleepq_switch 
sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 
0 100013 kernel  if_config_tqg_0 mi_switch sleepq_switch 
sleepq_wait msleep_spin_sbt gtaskqueue_thread_loop fork_exit fork_trampoline 
0 100014 kernel  if_io_tqg_0 mi_switch sleepq_switch 
sleepq_wait msleep_spin_sbt gtaskqueue_thread_loop fork_exit fork_trampoline 
0 100015 kernel  if_io_tqg_1 mi_switch sleepq_switch 
sleepq_wait msleep_spin_sbt gtaskqueue_thread_loop fork_exit fork_trampoline 
0 100016 kernel  if_io_tqg_2 mi_switch sleepq_switch 
sleepq_wait msleep_spin_sbt gtaskqueue_thread_loop fork_exit fork_trampoline 
0 100017 kernel  if_io_tqg_3 mi_switch sleepq_switch 
sleepq_wait msleep_spin_sbt gtaskqueue_thread_loop fork_exit fork_trampoline 
0 100018 kernel  softirq_0   mi_switch sleepq_switch 
sleepq_wait msleep_spin_sbt gtaskqueue_thread_loop fork_exit fork_trampoline 
0 100019 kernel  softirq_1   mi_switch sleepq_switch 
sleepq_wait msleep_spin_sbt gtaskqueue_thread_loop fork_exit fork_trampoline 
0 100020 kernel  softirq_2

Re: panic: vtopde on a uva/gpa 0x1030000 @r325228 (amd64)

2017-11-01 Thread Andriy Gapon 
On 01/11/2017 10:12, Andriy Gapon wrote:
> On 01/11/2017 09:33, O. Hartmann wrote:
>> I have the same (or similar) probleme here on two boxes now, maybe more to 
>> come
>> as I start updating CURRENT cyclic.
>>
>> Reverting r325227 solves to problem for now.
> 
> Oliver,
> 
> David and I have been working on this and a fix is coming soon.
> Sorry for the trouble and thanks for the report.
> 

Committed as r325272.

-- 
Andriy Gapon
___
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: Segfault in _Unwind_* code called from pthread_exit

2017-11-01 Thread Gerald Pfeifer 
On Wed, 1 Nov 2017, Tijl Coosemans wrote:
> Please commit it to the ports tree as well, because there are reports
> that ftp/curl can trigger the problem.

What Andreas and me usually are doing is that he commits fixes 
upstream (from HEAD down to release branches), I pick them up when 
updating the gcc*-devel ports, and if important he temporarily adds
patches to the gcc* ports until the next release obsoletes them.

Andreas, I can take of the gcc* ports this time once you have 
pushed things upstream.

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

system stuck on bios splash after reboot only

2017-11-01 Thread far...@t-online.de 
Firstly, I couldn't find an answer for this specific problem, so I
apologize when this is a common problem.

Recently I installed FreeBSD again on a new laptop (Thinkpad T470
20HES2SF00). On my desktop, the OS runs without problems with Xorg.

I have chosen FreeBSD 12.0-CURRENT for that, because I need support for
the iwm 8265 device + kabylake support via drm-next-kmod.

Booting into the OS after the installation works (I use ZFS + GELI
encryption), but when I reboot via reboot(8)


 
 or shutdown -r now I'm stuck on the BIOS splash screen.

Shutting down the computer and do a fresh boot works as expected, only
rebooting doesn't work. The OS before (void linux, and well the
preinstalled windows 10) didn't have that problem. Furthermore, the
reboot is stuck only when fully logged in on the system before,
rebooting from the FreeBSD bootloader works without problems.

FreeBSD 11.1-RELEASE is stuck on reboot too.

BIOS is version 1.30. Boot order is primary the SSD (I deactivated all
others to test) UEFI boot, tried with/-out secure boot and old bios
boot too.

Is this a known problem? How can i fix it? Or how can I debug the
problem, I would be thankful for some pointers.

FreeBSD is pretty new to me, using it for some month as a second system
on my desktop computer, but using GNU/Linux for over a decade and use
the terminal extensively, so I hope I'm not completely incapable to fix
the problem with some help!

Hope it was understandable and thanks in advance!
 

 
copy of https://forums.freebsd.org/threads/63050/

___
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: system stuck on bios splash after reboot only

2017-11-01 Thread Toomas Soome 


> On 1 Nov 2017, at 19:37, far...@t-online.de wrote:
> 
>Firstly, I couldn't find an answer for this specific problem, so I
>apologize when this is a common problem.
> 
>Recently I installed FreeBSD again on a new laptop (Thinkpad T470
>20HES2SF00). On my desktop, the OS runs without problems with Xorg.
> 
>I have chosen FreeBSD 12.0-CURRENT for that, because I need support for
>the iwm 8265 device + kabylake support via drm-next-kmod.
> 
>Booting into the OS after the installation works (I use ZFS + GELI
>encryption), but when I reboot via reboot(8)
>
> 
>  
> or shutdown -r now I'm stuck on the BIOS splash screen.
> 
>Shutting down the computer and do a fresh boot works as expected, only
>rebooting doesn't work. The OS before (void linux, and well the
>preinstalled windows 10) didn't have that problem. Furthermore, the
>reboot is stuck only when fully logged in on the system before,
>rebooting from the FreeBSD bootloader works without problems.
> 
>FreeBSD 11.1-RELEASE is stuck on reboot too.
> 
>BIOS is version 1.30. Boot order is primary the SSD (I deactivated all
>others to test) UEFI boot, tried with/-out secure boot and old bios
>boot too.
> 
>Is this a known problem? How can i fix it? Or how can I debug the
>problem, I would be thankful for some pointers.
> 
>FreeBSD is pretty new to me, using it for some month as a second system
>on my desktop computer, but using GNU/Linux for over a decade and use
>the terminal extensively, so I hope I'm not completely incapable to fix
>the problem with some help!
> 
>Hope it was understandable and thanks in advance!
> 
> 
> 
> copy of https://forums.freebsd.org/threads/63050/
> 

This sounds like that system needs more serious resetting; The reboot from boot 
loader can work because boot loader does not really touch the hardware much - 
the boot loader only is using firmware services and those (probably) do not 
change the hardware state that much.

Still the first thing to check is the firmware/bios update….

rgds,
toomas


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

make -C weirdness

2017-11-01 Thread Sergey V. Dyatko 
Hi,

Long time ago I wrote 2 simple aliases to my .cshrc:

search_key  make -C /usr/ports/ search key='!*' display=name,path,info
search_name make -C /usr/ports/ search name='!*' display=port,path,info

it works fine starting from 7-CURRENT  IIRC. 
Today   I tried to find some (existing) port and can't, for example:
[tiger@laptop]:/>make -C /usr/ports/ search name=teeworlds
display=name,path,info
[tiger@laptop]:/>
but
[tiger@laptop]:/>cd /usr/ports/
[tiger@laptop]:/usr/ports>make search name=teeworlds display=name,path,info
Port:   teeworlds-0.6.4_4 
Path:   /usr/ports/games/teeworlds 
Info:   Platform game featuring buggers equipped with
weapons

it is  on 12.0-CURRENT r324493
I missed something or it is a bug?

--
wbr, Sergey

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

r325288: Changed OBJDIR paths /usr/obj[/amd64.amd64]/usr/src -> /usr/obj/usr/src/amd64.amd64/ (always target now)

2017-11-01 Thread Bryan Drewery 
FYI after r325288 the OBJDIR path used has changed to:
MAKEOBJDIRPREFIX/SRCTOP/TARGET.TARGET_ARCH/RELDIR.

Meaning something like this:
/usr/obj/usr/src/amd64.amd64/bin/sh

This pattern is used for cross, native, and sub-directory builds.
You can try moving your old object directories to the new paths or just
remove them.  META_MODE users may not rename the old directories, they
need to just be removed due to changed build commands due to use of
absolute OBJDIRS in the build (which I have opened review D12839 to
address later).

This can be disabled with WITHOUT_UNIFIED_OBJDIR=yes in
/etc/src-env.conf (not /etc/src.conf), but the option is planned to be
removed for 12.0 release.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: r325288: Changed OBJDIR paths /usr/obj[/amd64.amd64]/usr/src -> /usr/obj/usr/src/amd64.amd64/ (always target now)

2017-11-01 Thread Bryan Drewery 
On 11/1/2017 2:28 PM, Bryan Drewery wrote:
> FYI after r325288 the OBJDIR path used has changed to:
> MAKEOBJDIRPREFIX/SRCTOP/TARGET.TARGET_ARCH/RELDIR.
> 
> Meaning something like this:
> /usr/obj/usr/src/amd64.amd64/bin/sh
> 
> This pattern is used for cross, native, and sub-directory builds.
> You can try moving your old object directories to the new paths or just
> remove them.  META_MODE users may not rename the old directories, they
> need to just be removed due to changed build commands due to use of
> absolute OBJDIRS in the build (which I have opened review D12839 to
> address later).
> 
> This can be disabled with WITHOUT_UNIFIED_OBJDIR=yes in
> /etc/src-env.conf (not /etc/src.conf), but the option is planned to be
> removed for 12.0 release.
> 

I forgot to mention that I've also added a 'make cleanuniverse' which
does what it sounds like.  Cleans up after a 'make universe' or 'make
tinderbox' (it removes all objects built from the source directory).
This is much simpler now with this pattern.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature